Construcción de softwar softwaree Ingeniería de Sistemas e Informática
•
•
Propósito y contenido de la sesión Propósito de la sesión • Identif Identifica ica los cambi cambios os de que que se producirán en un sistema de inventario de almacén.
Contenido de la sesión • Antici Anticipar par los cambio cambios, s, construir para verificar, utilizar estándares.
Propósito y contenido de la sesión Propósito de la sesión • Identif Identifica ica los cambi cambios os de que que se producirán en un sistema de inventario de almacén.
Contenido de la sesión • Antici Anticipar par los cambio cambios, s, 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 mantenimient mantenimiento o 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 artefact artefactos. os. A veces se conv convertirte ertirte 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: •
•
•
Algunas de las áreas más proclives a modificaciones son: •
•
•
•
•
•
Documentado las posibles mejoras futuras y Las áreas en que periódicamente habrá que realizar ajustes. 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 •
•
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 •
•
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.
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. • •
•
•
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. •
•
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 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: f or ( i = 0; 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] a[ 1] a[ 2] … a[ 8] a[ 9]
•
•
< 10; i ++)
= 0; = 1; = 2; = 8; = 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
