AddendadelaasignaturaAn\u00e1lisis,Dise\u00f1oyMantenimiento delSoftware.pdf - Addenda de la asignatura An\u00e1lisis Dise\u00f1o y Mantenimiento del Software Manuel

AddendadelaasignaturaAnálisis,DiseñoyMantenimiento delSoftware.pdf

This preview shows page 1 out of 193 pages.

You've reached the end of your free preview.

Want to read all 193 pages?

Unformatted text preview: Addenda de la asignatura Análisis, Diseño y Mantenimiento del Software Manuel Arias Calleja Dpto. de Inteligencia Articial - ETSI Informática - UNED Actualizada en agosto de 2007 II Índice general 1. Contexto de la asignatura en la Ingeniería de Software 1 1.1. 1 1.2. 1.3. 2. 1.1.1. Sistemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1.2. La crisis del software . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.3. Denición de metodología . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1.4. Finalidad de una metodología . . . . . . . . . . . . . . . . . . . . . . 3 1.1.5. Taxonomía de las metodologías . . . . . . . . . . . . . . . . . . . . . 3 Ciclo de vida del software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1. Ciclos de vida en cascada 1.2.2. Modelo de ciclo de vida en espiral . . . . . . . . . . . . . . . . . . . . 10 1.2.3. Ciclos de vida orientados a objetos . . . . . . . . . . . . . . . . . . . . 13 Notaciones de especicación y diseño (UML) . . . . . . . . . . . . . . . . . . 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3.1. Introducción 1.3.2. Modelo de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.3.3. Modelo estructural estático . . . . . . . . . . . . . . . . . . . . . . . . 19 1.3.4. Modelo de comportamiento . . . . . . . . . . . . . . . . . . . . . . . 30 1.3.5. Modelo estructural de implementación . . . . . . . . . . . . . . . . . . 36 Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Fase de especicación 41 2.1. 3. Necesidad de una metodología . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Obtención de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 2.1.1. Introducción 41 2.1.2. Técnicas de obtención de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 2.2. Análisis de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 2.3. Representación de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.4. Análisis orientado a objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 2.5. Bases de documentación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Fase de diseño 65 3.1. Conceptos y elementos del diseño . . . . . . . . . . . . . . . . . . . . . . . . III 65 Índice general IV 3.1.1. Patrones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 3.2. Diseño estructurado . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 3.3. Diseño orientado a objetos 72 3.4. Validación y conrmación del diseño . . . . . . . . . . . . . . . . . . . . . . . 75 3.4.1. Revisión del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 3.4.2. Vericación del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . 75 3.4.3. Validación del diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Documentación: especicación del diseño . . . . . . . . . . . . . . . . . . . . 75 Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Fase de implementación 79 4.1. Técnicas de depuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.2. Documentación del código 79 3.5. 4. Tipos de comentarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 4.2.2. Consideraciones generales . . . . . . . . . . . . . . . . . . . . . . . . 80 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Fases de pruebas Técnicas y métodos de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . 83 5.2. Documentación de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Fase de entrega y mantenimiento 89 6.1. 89 6.2. 6.3. 7. 83 5.1. Ejercicios 6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1. Ejercicios 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Finalización del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.1.1. Aceptación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 6.1.2. Informe de cierre del proyecto . . . . . . . . . . . . . . . . . . . . . . 90 6.1.3. Indicadores del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . 90 Planicación de revisiones y organización del mantenimiento . . . . . . . . . . 92 . . . . . . . . . . . . . . . . . 92 6.3.1. Recopilación y organización de documentación Motivos de la documentación . . . . . . . . . . . . . . . . . . . . . . 92 6.3.2. Directrices que se deben seguir para la redacción de un documento . . . 93 6.3.3. Tipos de documentos . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 6.3.4. Manual de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 6.3.5. Manual del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 6.3.6. Manual de mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . 100 Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Metodologías de desarrollo 103 7.1. 7.2. Introducción a las metodologías de desarrollo Proceso unicado de Rational 7.2.1. Introducción . . . . . . . . . . . . . . . . . . 103 . . . . . . . . . . . . . . . . . . . . . . . . . . 103 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Índice general 7.3. 7.4. 7.5. 8. V 7.2.2. Las cuatro “P”: Personas, Proyecto, Producto y Proceso 7.2.3. Proceso dirigido por casos de uso . . . . . . . . 106 . . . . . . . . . . . . . . . . . . . . 107 7.2.4. Proceso centrado en la arquitectura . . . . . . . . . . . . . . . . . . . 108 7.2.5. Proceso iterativo e incremental . . . . . . . . . . . . . . . . . . . . . . 109 7.2.6. Captura de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 7.2.7. Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 7.2.8. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120 7.2.9. Prueba 122 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 7.3.1. Método extreme programming Historias de usuario . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 7.3.2. Plan de publicación de versiones . . . . . . . . . . . . . . . . . . . . 125 7.3.3. Tarjetas CRC: Clases, Responsabilidades y Colaboraciones . . . . . . . 126 7.3.4. Planicación de cada iteración . . . . . . . . . . . . . . . . . . . . . . 126 7.3.5. Integración 127 7.3.6. Codicación de cada unidad . . . . . . . . . . . . . . . . . . . . . . . 128 7.3.7. Recomendaciones generales . . . . . . . . . . . . . . . . . . . . . . . 130 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 Métrica 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.4.1. Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7.4.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7.4.3. Estructura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132 7.4.4. Planicación de Sistemas de Información . . . . . . . . . . . . . . . . 133 7.4.5. Estudio de la viabilidad del sistema . . . . . . . . . . . . . . . . . . . 135 7.4.6. Análisis del sistema de información . . . . . . . . . . . . . . . . . . . 136 7.4.7. Diseño del sistema de información . . . . . . . . . . . . . . . . . . . . 138 7.4.8. Construcción del sistema de información . . . . . . . . . . . . . . . . 141 7.4.9. Implantación y Aceptación del Sistema . . . . . . . . . . . . . . . . . 143 7.4.10. Mantenimiento de Sistemas de Información . . . . . . . . . . . . . . . 144 Métodos de software libre: “cathedral” vs. “bazaar” . . . . . . . . . . . . . . . 154 7.5.1. La catedral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 7.5.2. El bazar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155 Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Herramientas de desarrollo y validación 159 8.1. 8.2. Herramientas CASE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 8.1.1. Funciones de las herramientas CASE . . . . . . . . . . . . . . . . . . 159 8.1.2. Clasicación de las herramientas CASE . . . . . . . . . . . . . . . . . 160 Gestión de la conguración . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 8.2.1. Terminología y deniciones básicas . . . . . . . . . . . . . . . . . . . 162 8.2.2. Identicación de la conguración . . . . . . . . . . . . . . . . . . . . 163 8.2.3. Control de cambios . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 8.2.4. Generación de informes de estado . . . . . . . . . . . . . . . . . . . . 165 8.2.5. Auditoría de la conguración . . . . . . . . . . . . . . . . . . . . . . . 166 Índice general VI 8.3. 8.2.6. Plan de gestión de la conguración . . . . . . . . . . . . . . . . . . . 166 8.2.7. Herramientas de la Gestión de la Conguración . . . . . . . . . . . . . 167 8.2.8. Software libre 169 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Entornos de desarrollo de interfaces . . . . . . . . . . . . . . . . . . . . . . . 171 8.3.1. Introducción 8.3.2. Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 8.3.3. Creación de interfaces de usuario 8.3.4. Metodología 8.3.5. Heurísticas de usabilidad . . . . . . . . . . . . . . . . . . . . . . . . 175 8.3.6. Glade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 8.3.7. GTK+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 8.3.8. Anjuta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Ejercicios y actividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 174 Bibliografía 181 Índice alfabético 182 Capítulo 1 Contexto de la asignatura en la Ingeniería de Software 1.1. Necesidad de una metodología El proceso de construcción del software requiere, como en cualquier otra ingeniería, identicar las tareas que se han de realizar sobre el software y aplicar esas tareas de una forma ordenada y efectiva. Adicionalmente y aunque no es el objeto principal de esta asignatura, el desarrollo del software es realizado por un conjunto coordinado de personas simultáneamente y, por lo tanto, sus esfuerzos deben estar dirigidos por una misma metodología que estructure las diferentes fases del desarrollo. En temas posteriores, en primer lugar se explicarán en detalle las mencionadas fases y a continuación las metodologías usuales que las gestionan. En esta asignatura se hará especial énfasis en los temas relacionados con el análisis, diseño y mantenimiento del software, mencionando apenas los temas especícos de la organización y gestión de proyectos que conciernen a la distribución de medios y tareas entre las personas a cargo del desarrollo, ya que estos últimos temas son objeto de otras asignaturas de la titulación. 1.1.1. Sistemas La Ingeniería de Sistemas es el contexto genérico en que se sitúan las herramientas y metodologías usadas para crear sistemas. Un sistema puede estar formado por subsistemas de diferentes tipos. La ingeniería de sistemas constituye el primer paso de toda ingeniería: proporciona una visión global de un sistema en su conjunto para que, posteriormente, cada uno de sus subsistemas se analice con la rama de la ingeniería adecuada. Una de esas ramas es la ingeniería del software. La Ingeniería del Software trata, según Bauer [Bau72], del establecimiento de los principios y métodos de la ingeniería, orientados a obtener software económico, que sea able y funcione de manera eciente sobre máquinas reales. El sistema es un conjunto de elementos que cooperan entre sí para proporcionar una funcionalidad. En el caso de un sistema informático, consta de dos tipos de elementos: hardware y software. 1 2 Contexto de la asignatura en la Ingeniería de Software 1.1.2. La crisis del software Desde el momento en que se introdujeron computadores con capacidad para soportar aplicaciones de tamaño considerable (años 60), las técnicas de desarrollo para los hasta entonces pequeños sistemas dejaron progresivamente de ser válidas. Estas técnicas consistían básicamente en codicar y corregir (code-and-x) que se resume en lo siguiente: No existe necesariamente una especicación del producto nal, en su lugar se tienen algunas anotaciones sobre las características generales del programa. Inmediatamente se empieza la codicación y simultáneamente se va depurando. Cuando el programa cumple con las especicaciones y parece que no tiene errores se entrega. La ventaja de este enfoque es que no se gasta tiempo en planicación, gestión de los recursos, documentación, etc. Si el proyecto es de un tamaño muy pequeño y lo realiza un equipo pequeño (una sola persona o dos) no es un mal sistema para producir un resultado pronto. Hoy en día es un método de desarrollo que se usa cuando hay plazos muy breves para entregar el producto nal y no existe una exigencia explícita por parte de la dirección de usar alguna metodología de ingeniería del software. Puede dar resultado, pero la calidad del producto es imprevisible. Las consecuencias de este tipo de desarrollo son: 1. El costo es mucho mayor de lo originalmente previsto. 2. El tiempo de desarrollo excede lo proyectado. 3. La calidad del código producido es imprevisible y en promedio baja. Aunque se han desarrollado técnicas para paliar estos problemas, hoy en día aún se considera normal que una aplicación rebase sus proyecciones iniciales de tiempo y dinero y que se descubran bugs (errores informáticos) en su ejecución. Esto se debe a que todavía no se aplica de un modo sistemático la ingeniería del software durante el desarrollo. 1.1.3. Denición de metodología En la literatura sobre este tema existen muchas deniciones sobre lo que es una metodología. El común denominador de todas ellas es la siguiente lista de características: 1. Dene cómo se divide un proyecto en fases y las tareas que se deben realizar en cada una de ellas. 2. Especica para cada una de las fases cuáles son las entradas que recibe y las salidas que produce. 3. Establece alguna forma de gestionar el proyecto. Resumiendo lo anterior denimos metodología como un modo sistemático de producir software. 1.1 Necesidad de una metodología 1.1.4. 3 Finalidad de una metodología La diferencia entre code-and-x (no usar ninguna metodología) y usar una es que se pueden alcanzar los siguientes atributos en el producto nal: 1. Adecuación: el sistema satisface las expectativas del usuario. 2. Mantenibilidad: facilidad para realizar cambios una vez que el sistema está funcionando en la empresa del cliente. 3. Usabilidad: facilidad de aprender a manejar el sistema por parte de un usuario que no tiene por qué ser informático. La resistencia de los usuarios a aceptar un sistema nuevo será mayor cuanto peor sea la usabilidad. 4. Fiabilidad: capacidad de un sistema de funcionar correctamente durante un intervalo de tiempo dado. La diferencia con la corrección es que en este atributo interesa el tiempo, es decir, no se trata del número absoluto de defectos en el sistema sino de los que se maniestan en un intervalo de tiempo. Interesan sobre todo: a) MTBF (Mean Time Between Failures): tiempo medio entre fallos. b) Disponibilidad: probabilidad de que el sistema esté funcionando en un instante dado. 5. Corrección: baja densidad de defectos. 6. Eciencia: capacidad del sistema de realizar su tarea con el mínimo consumo de recursos necesario. 1.1.5. Taxonomía de las metodologías Existen dos grupos de metodologías en función de la mentalidad con la que aborda un problema: metodología estructurada y metodología orientada a objetos. Metodología estructurada Constituyó la primera aproximación al problema del desarrollo de software. Está orientada a procesos, es decir, se centra en especicar y descomponer la funcionalidad del sistema. Se utilizan varias herramientas: Diagramas de ujo de datos (DFD): representan la forma en que los datos se mueven y se transforman. Incluyen: • • • Procesos Flujos de datos Almacenes de datos Los procesos individuales se pueden a su vez ”explosionar” en otros DFD de mayor nivel de detalle. 4 Contexto de la asignatura en la Ingeniería de Software Alta/Baja Película Gestionar Altas/Bajas Películas Disponibles Pedido Película Gestionar Pedidos Gestionar Devoluciones Devolución Película Figura 1.1: Ejemplo de DFD Especicaciones de procesos: descripciones de los procesos denidos en un DFD que no se puede descomponer más. Pueden hacerse en pseudocódigo, con tablas de decisión o en un lenguaje de programación. Diccionario de datos: nombres de todos los tipos de datos y almacenes de datos junto con sus deniciones. Diagramas de transición de estados: modelan procesos que dependen del tiempo. Diagramas entidad-relación: los elementos del modelo E/R se corresponden con almacenes de datos en el DFD. En este diagrama se muestran las relaciones entre dichos elementos. Los lenguajes de programación también reejan esta dicotomía que existe entre las metodologías; así, existen lenguajes para la programación estructurada. Los más famosos son: Cobol (destinado a aplicaciones nancieras, en su mejor momento el 90 % del código estaba escrito en este lenguaje), Fortran (usado en aplicaciones matemáticas), C (aplicaciones de propósito general en los años 80), Pascal y Modula 2. Metodología orientada a objetos Constituye una aproximación posterior. Cuenta con mayor número de desarrolladores y es previsible que termine sustituyendo a la anterior. Además, es ampliamente admitido que proporciona estas ventajas: 1. Está basada en componentes, lo que signica que facilita la reutilización de código. De todos modos hay que añadir que la reutilización de código es un tema complejo y que requiere en cualquier caso un diseño muy cuidadoso. Una metodología orientada a objetos no garantiza por si misma la producción de código reutilizable, aunque lo facilita. 2. Simplica el mantenimiento debido a que los cambios están más localizados. La mentalidad que subyace al diseño estructurado es: ¿Cómo se puede dividir el sistema en partes más pequeñas que puedan ser resueltas por algoritmos sencillos y qué información se intercambian?. En el diseño orientado a objetos la idea es sin embargo: ¿Cuáles son los tipos de datos que hay que utilizar, qué características tienen y cómo se relacionan?. 1.2 Ciclo de vida del software 5 La orientación a objetos supone un paradigma distinto del tradicional (no necesariamente mejor o peor) que implica focalizar la atención en las estructuras de datos. El concepto de objetos tuvo sus orígenes en la inteligencia articial como un modo de representación del conocimiento. El primer lenguaje orientado a objetos fue Simula67, desarrollado por Kristen Nggaard y Ole-Johan Dahl en el Centro de Cálculo noruego, pero el que se considera el primer lenguaje orientado a objetos puro fue Smaltalk, donde todos los elementos del lenguaje son objetos. El lenguaje C++ fue una ampliación de C para que soportara objetos; resultó muy eciente pero también muy complejo. Java es otro lenguaje orientado a objetos derivado del C++ pero más sencillo y concebido con la idea de minimizar los errores relativos a punteros. Objetos y clases Un objeto consta de una estructura de datos y de una colección de métodos (antes llamados procedimientos o funciones) que manipulan esos datos. Los datos denidos dentro de un objeto son sus atributos. Un objeto sólo pu...
View Full Document

  • Winter '20
  • The American, Comunicación, Ingeniería de software, Estructura de datos

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture

  • Left Quote Icon

    Student Picture