Construcción de software

Ingeniería de Sistemas e Informática

•5
•1
Propósito y contenido de la sesión

Propósito de la sesión
• Identifica los cambios de que
se producirán en un sistema
de inventario de almacén.

Contenido de la sesión
• Anticipar los cambios,
construir para verificar,
utilizar estándares.
 Anticipar los cambios
Principios fundamentales de la construcción de software
 Anticipar los cambios

El sistema evoluciona.

El software es sometido a actividades de mantenimiento para

ajustarlo a nuevos requisitos o bien para eliminar errores.

Los cambios a menudo afectan a la documentación, el rediseño

y a los artefactos.

A veces se convertirte en potencial fuente de problemas.

El objetivo del proceso de construcción en
lo referente a los cambios

Aislar aquellas áreas más

inestables para que el
posible fallo afecte sólo a
unas pocas rutinas,
cuantas menos mejor.
Anticipar los cambios (McConnell, 2004)
(1)

Identificar elementos
susceptibles de cambiar.

Separar aquellos elementos

que es probable que cambien

Aislar los elementos que se

prevea puedan cambiar
 1. Identificar elementos susceptibles de
cambiar.
• Si se ha hecho un buen proceso de obtención y formalización de
requisitos:
• Documentado las posibles mejoras futuras y
• Las áreas en que periódicamente habrá que realizar ajustes.
• Algunas de las áreas más proclives a modificaciones son:
• Las que incluyen dependencias de hardware,
• Formatos de entrada-salida,
• Estructuras de datos complejas y
• Reglas de negocio.
• Todo proyecto tiene elementos que a priori no parecen proclives a
los cambios, pero que posteriormente pueden verse afectados.
• Para elementos no incluidos en la documentación de requisitos,
deben seguirse los pasos 2 y 3.
 2. Separar aquellos elementos que es
probable que cambien

Deben clasificarse de tal modo que cada

elemento de los identificados en el paso
anterior tenga su propia clase (POO).

Almacenar juntos en una clase todos

aquellos componentes que cambiaran a
la vez.
 3. Aislar los elementos que se prevea
puedan cambiar
• Diseñando las interfaces entre dichos elementos de modo que los
cambios dentro de un elemento queden circunscritos al mismo y no
se propaguen al resto de elementos con los que este interacciona.
• Lo ideal sería que una clase que utiliza otra que ha cambiado no
notase el cambio si la interfaz no ha cambiado.
• Cambiar un ratón mecánico por un ratón óptico.
• La tecnología que los hace funcionar es muy distinta, pero desde el punto de
vista del humano las operaciones no han cambiado: pulsar el botón
izquierdo, pulsar el botón derecho y desplazar.
 Áreas proclives a cambiar

Reglas de negocio

Dependencias del hardware

Entradas y salidas de la aplicación

Dependencias de las extensiones no estándar

Áreas de especial dificultad de diseño o construcción

Variables de estado

Limitaciones en el tamaño de los datos.

Construir para verificar
Principios fundamentales de la construcción de software
 Construir para verificar

Buscar y arreglar todos los errores que pudieran

generar fallos posteriores durante la ejecución.
• El empleo sistemático de pruebas de unidad,
• La organización del código para permitir pruebas
automatizadas,
• La utilización de métodos estandarizados que faciliten las
revisiones del código y
• El uso limitado de estructuras complejas de los lenguajes de
programación.
Uso sistemático de pruebas de unidad

Pequeños módulos auxiliares que se encargan de verificar el

funcionamiento de otras unidades lógicas del sistema.

Su objetivo es verificar que un componente funciona

correctamente por sí mismo, sin tener en cuenta las
relaciones que pueda tener con otras partes del sistema.

Su uso sistemático facilita la creación de software de

calidad.

En los métodos agiles, se recomienda desarrollar las

pruebas unitarias antes incluso que la propia unidad a
probar.
 Organización del código para permitir
pruebas automatizadas

Utilizar herramientas que faciliten la generación del código fuente

inicial de la prueba, o bien escribir la prueba completamente a mano.

Marcos de pruebas (frameworks): xUnit.

• Estos marcos de pruebas unitarias están formados por diversas clases que proporcionan
al desarrollador gran flexibilidad para escribir pruebas unitarias a partir de un código
previamente organizado a tal efecto.

Los elementos básicos son los casos de prueba y las colecciones de

prueba
 Casos de prueba y colecciones de prueba

Un caso de prueba
• Formado por clases que tienen una serie de
métodos que ejecutan los métodos de otra clase,
la cual es objeto de la prueba.
Colecciones de pruebas
• Conjuntos de casos de prueba sobre clases
funcionalmente relacionadas que pueden
automatizar el proceso.
 Métodos para la revisión del código

• También denominada inspección (walkthrough)

• Es una reunión en la que cierto componente software se presenta a
un conjunto de actores involucrados en el desarrollo, tales como
usuarios, clientes, gestores y otros interesados, para que estos
aporten sus comentarios, realicen críticas y en ultimo termino
comuniquen su aprobación o reprobación del código.
• Se realiza un análisis sistemático del código, intentando detectar
defectos en el mismo que hayan podido pasar inadvertidas.
• La detección y reparación de estos errores en una fase tan temprana
tiene un beneficioso efecto sobre la calidad final del producto
software desarrollado, pero también está orientada a la formación
del programador a través de la comprobación de los fallos que haya
podido cometer durante la codificación.
Clasificación de las revisiones de código

Revisiones
formales

Revisiones
ligeras
 Revisiones formales

Se llevan a cabo en más de una

sesión.

Es un proceso detallado de
búsqueda de errores y discusión
sobre el código «línea por línea».
Lista de comprobación para las revisiones
formales de código
 Revisiones ligeras (1)

Las revisiones ligeras son más informales,

pero no tienen por qué ser menos
efectivas.

No se plantea como una actividad separada

de la codificación, sino que forman parte
del propio proceso de programación.
 Revisiones ligeras (1)

• Circulación de código nuevo mediante correo electrónico

• Se envían código fuente por correo electrónico a otros desarrolladores tras
ser implementados e introducidos en la herramienta de control de versiones.
Quienes reciben el código, lo revisan y envían sus comentarios al autor
original, también por correo electrónico.
• Programación por parejas
• Técnica de desarrollo que consiste en codificar en equipos de dos
programadores: mientras uno escribe el código, el otro lo lee y hace
comentarios.
• La tarea que cada uno desempeña no es fija, y de hecho, se suelen cambiar
frecuentemente los papeles.
• Uso de herramientas de revisión
• Detectan de forma automatizada algunos de los problemas.
• Revisiones «por encima del hombro»
• Sugerencias informales de mejora y a los comentarios hechos por otros
desarrolladores que leen el código a medida que se está construyendo.
 Uso limitado de estructuras complejas del
lenguaje (1)
• Tiene un impacto negativo el uso de elementos del lenguaje
complejos o difíciles de entender. Sobre todo, cuando existen
alternativas de menor complejidad.
• El abuso de la aritmética de punteros en lenguajes como C,
• Utilización de complicadas estructuras recursivas de datos (cuando no son
estrictamente necesarias), o
• La innecesaria complejidad derivada del uso extremo de técnicas de
afinación del código.
• La elección del lenguaje de programación a utilizar durante la
construcción, por ejemplo, es una decisión importante que tiene un
impacto directo en la futura verificación del software.
• La programación a bajo nivel puede llevar al desarrollo de programas con una
mayor tasa de error.
• Mito: un código fuente más corto genera código maquina más
eficiente que uno largo.
 Uso limitado de estructuras complejas del
lenguaje (2)
• En Java:
for (i = 0; i < 10; i++)
a[i] = i;
• Se ejecuta en 5,588 microsegundos en un PC con procesador Intel Core 2
Duo T5600 a 1.83 GHz y 2GB de RAM.
a[0] = 0;
a[1] = 1;
a[2] = 2;
…
a[8] = 8;
a[9] = 9;

• Tarda un 15% menos en hacer el mismo trabajo. 4,749 microsegundos para

ser exactos.
• Casi siempre es preferible, por una cuestión de estilo y legibilidad, utilizar
la primera opción.
 Utilizar estándares
Principios fundamentales de la construcción de software
 Utilización de estándares

Un conjunto de especificaciones técnicas documentadas

que regulan la realización de un proceso o la fabricación
de un producto.

El objetivo de la estandarización es fundamentalmente la

interoperabilidad entre artículos construidos por
diferentes fabricantes.

La elaboración de un estándar es un proceso que conlleva

tiempo y en el que intervienen muchas personas y
organizaciones diferentes.
 Como surge los estándares

El uso generalizado de un producto hace surgir consorcios y asociaciones de

usuarios, tras un periodo de utilización promueven la normalización
mediante la elaboración de documentos técnicos cuyo objeto es sistematizar
el uso del producto entre sus miembros.
• Estos documentos, con frecuencia de carácter interno, suelen denominarse especificaciones.
• IETF (Internet Engineering Task Force), OMG (Object Management Group), o W3C (World. Wide
Web Consortium).

A partir de una o más especificaciones sobre el mismo producto,

organizaciones de certificación tales como IEEE, AENOR, CEN o ISO, y con el
concurso de expertos en la materia, mejoran la especificación para cubrir las
necesidades de todos los usuarios y fabricantes potenciales del producto.
Estándares en la construcción de software

Métodos de comunicación (estándares sobre el

formato y contenido de los documentos, de
legibilidad, etc.).

Lenguajes de programación (escritura de código

estándar Java, C, etc.).

Plataformas.

Notaciones de representación y herramientas.

 Profesionales en construcción de software

Las personas que se enfrentan a

la construcción de software
deben conocer los estándares,
especificaciones y
procedimientos por los que
deben regirse.
Clasificación de los estándares

Estándares
externos.

Estándares
internos.
 Estándares externos

Dentro de estos podemos agrupar las

especificaciones de interfaces publicadas
por organismos nacionales e
internacionales de estandarización tales
como ISO, IEEE, IETF (Internet Engineering
Task Force), OMG (Object Management
Group), W3C (World Wide Web
Consortium) y otros.
 Estándares internos

Afectan a la construcción de software dentro de la

organización de desarrollo.

Pueden ser reglas internas de obligado cumplimiento, o

simples recomendaciones de cara a la construcción.

Casi todas las compañías de desarrollo (por supuesto todas

las importantes) cuentan con su estándar de construcción.
Ejemplo de estándar interno
Microsoft
Algunos prefijos de tipo según la notación
húngara
Combinación de prefijos de tipo en
notación húngara
Comentario al principio del código fuente
Ejemplo de estándar interno
Sun Microsystems
Convenciones de nombres para Java
Inventario de almacén
Actividad colaborativa
 Actividad colaborativa

Identifique los cambios

de que se producirán
en un sistema de
inventario de almacén
Inventario de almacén
Preguntas
¿Qué hemos aprendido?
Reflexionemos