1 1 4.- Diseño del software

2 2 Diseño del software Diseño  Definición El proceso de definición de la arquitectura, componente, interfaces y otras características de un sistema o de un componente. El resultado de este proceso. IEEE std. 610.12-1990 Glossary of software engineering terminology El diseño del software comprende la descripción de la arquitectura del sistema con el nivel de detalle suficiente para guiar su construcción.  Descomposición del sistema  Organización entre los componentes del sistema  Interfaces entre los componentes

3 3 Diseño del software Diseño Diseño es la actividad del ciclo de vida en la que se analizan los requisitos del software para desarrollar una descripción de la estructura interna y la organización del sistema que servirá de base para su construcción. RequisitosDiseñoConstrucción

4 4 Diseño del software Diseño Una vez conocidas las necesidades de los usuarios es preciso diseñar una solución. Empleando el símil con la construcción de edificios, tras conocer cuales son las necesidades que se desean cubrir con un edificio (hotel, colegio, vivienda familiar, edificio de apartamentos…), es el momento de diseñar la solución. Las posibilidades son muchas, y exceptuando proyectos de tamaño mínimo, la complejidad de concebir todas las facetas e interacciones del sistema desborda la capacidad de abstracción mental para concebirlo en una única visión. Al mismo tiempo es necesario que todas las personas implicadas en el proyecto conozcan y compartan los “planos” de la solución. Así pues, las razones del diseño son:  Concepción u análisis de las posibles soluciones.  Apoyo metodológico para abordar la complejidad de la solución.  Registro documentado como medio de comunicación entre los participantes. Un modelo es una representación simplificada de la realidad. De igual forma que al concebir un edificio se divide la complejidad del sistema para hacerlo digerible, y se generan diversos modelos de los diferentes aspectos: planos de estructura, planos del subsistema de fontanería, del de electricidad, etc. los sistemas de software son también realidades complejas que es preciso conocer (modelizar) para llevar a cabo el diseño de su solución.  El diseño como creación de modelos

5 5 Diseño del software Actividades del diseño de software Descripción de la arquitectura general, identificación de sus componentes y su organización y relaciones en el sistema.  Diseño de la arquitectura del software El diseño del software comprende dos actividades intermedias entre la fase de requisitos y la de construcción:  Diseño detallado del software Definición y estructura de los componentes y datos. Definición de los interfaces Elaboración de las estimaciones de tiempo y tamaño. Considerando que la descripción del sistema (ConOps) dibuja una primera aproximación del sistema en su conjunto, algunos autores diferencian entre:  Diseño del sistema (la visión del documento de descripción del sistema).  Diseño de la arquitectura  Diseño del detallado del software

6 6 Diseño del software Razones del diseño del software  ¿Por qué? El resumen de las razones expuestas que hacen necesarias las tareas de diseño antes de comenzar la construcción de un sistema son:  Permite la descomposición del problema en partes y vistas de menor tamaño, más manejables para el trabajo intelectual del diseño de la solución.  Permite el desarrollo de modelos que se pueden analizar para determinar si cumplen los distintos requisitos.  Permite examinar soluciones alternativas.  Los modelos se pueden utilizar para planificar el desarrollo de las actividades, y son el punto de partida para empezar las actividades de codificación y pruebas.

7 7 Diseño del software Razones del diseño de software  Descomposición de la complejidad Class nombredeclase{ Public: funcion() {…} }

8 8 Diseño del software Razones del diseño de software  Análisis de soluciones posibles a través de su modelado.  Disponibilidad  Coste desarrollo  Coste mantenimiento  Robustez  Tiempos de respuesta  Hardware necesario  Etc. ? Requisitos

9 9 Diseño del software Razones del diseño de software  Elemento de comunicación, Base de planificación y del desarrollo

10 10 Diseño del software Fin del proceso de diseño  Todas las preguntas “ Como ” tienen respuesta  La descripci ó n del dise ñ o de la arquitectura est á completada  La revisi ó n del dise ñ o se ha completado y cada equipo/persona implicado est á de acuerdo con el dise ñ o.  Los borradores de manuales para mantenimiento y administraci ó n est á n realizados  Se ha realizado la trazabilidad del dise ñ o  Se ha revisado el dise ñ o de la arquitectura  Se ha verificado el dise ñ o de la arquitectura  Se ha escrito la planificaci ó n de la integraci ó n del software.  Se ha establecido la l í nea base del producto  Se considera que el proceso de diseño se ha completado cuando

11 11 Diseño del software Vistas del diseño de la arquitectura Un sistema de software es una entidad ortogonal que puede contemplarse o analizarse desde diferentes “ vistas ” : Puede enfocarse la atenci ó n en:  Distribuci ó n f í sica del software entre los diferentes elementos del sistema.  Descomposici ó n en las diferentes funcionalidades que realiza.  Estructuras de la informaci ó n que gestiona.  Etc. De esta forma el dise ñ o puede generar modelos para cada una de las diferentes vistas empleadas en su an á lisis (modelo f í sico, modelo de datos, modelo se procesos, etc.).

12 12 Diseño del software Notación empleada Si bien el concepto y la finalidad del dise ñ o o modelado de un sistema de software es siempre el mismo, las notaciones pueden variar en funci ó n de las caracter í sticas de cada proyecto o de los conocimientos o preferencias de las personas u organizaci ó n que lo realice. A trav é s del lenguaje de modelado empleado (UML, IDEF, Diagramas de flujo, etc.) se consiguen realizar dos tipo de descripciones:  Descripciones estructurales Las notaciones para descripciones estructurales suelen ser gr á ficas y representan los diferentes componentes y sus relaciones.  Lenguajes de descripci ó n de arquitecturas (ADL): AADL, AESOP, CODE, MetaH, Gestalt, Modechart, UML, Unicon, Modechart, etc.  Diagramas de clases y objetos  Diagramas de componentes  Diagramas entidad-relaci ó n  Lenguajes de descripci ó n de interfaz  Etc.  Descripciones de comportamiento  Diagramas de actividad  Diagramas de colaboraci ó n  Diagramas de flujo de datos  Diagramas de flujo  Pseudo-c ó digo y lenguajes de dise ñ o (PDL)  Diagramas de secuencia  Etc.

13 13 Diseño del software Estrategias y métodos para el diseño del software Las principales estrategias que suelen emplearse para el dise ñ o del software son:  Orientadas a funciones (estructurada)  Orientada a objetos (dise ñ o orientado a objetos)  Dise ñ o centrado en las estructuras de datos (menos empleado)  Diseño estructurado Esta es la aproximaci ó n cl á sica y se centra en la identificaci ó n y descomposici ó n de las principales funciones del sistema hacia niveles m á s detallados.  Diseño orientado a objetos Es la aproximaci ó n m á s popular actualmente, sobre la que se han desarrollado numerosos m é todos partiendo de su concepci ó n inicial en la d é cada de los 80 A través del diseño orientado a objetos (OOD), se desarrollan las especificaciones de sistemas como modelos de objetos (sistemas compuestos por conjuntos de objetos que interactúan entre ellos). que, expuesta de forma muy b á sica, identifica a los nombres como objetos, a los verbos como los comportamientos que pueden ofrecer y a los adjetivos como sus m é todos. Para cada estrategia hay numerosos m é todos (notaciones, lenguajes de modelado, t é cnicas).

14 14 Diseño del software El paradigma “00” Orientación a objetos OO no es una estrategia de dise ñ o. El paradigma de orientaci ó n a objetos es m á s amplio y abarca un enfoque general para conceptualizar, dise ñ ar y programar los sistemas de software.  Estrategias Las estrategias OO cubren tanto los requisitos como el an á lisis, dise ñ o y programaci ó n.  An á lisis Orientado a Objetos (OOA)  Dise ñ o Orientado a Objetos (OOD)  Programaci ó n Orientada a Objetos (OOP)  Métodos Las metodolog í as m á s importantes de an á lisis y dise ñ o de sistemas, orientado a objetos, han terminado confluyendo en lo que es el UML (www.uml.org), bajo el respaldo del Object Management Group (www.omg.org). Algunas de las principales metodolog í as, pioneras que han terminado confluyendo en el UML son:  Object-Oriented Design (OOD), Booch.  Object Modeling Technique (OMT), Rumbaugh.  Object Oriented Analysis (OOA), Coad/Yourdon.  Hierarchical Object Oriented Design (HOOD), ESA.  Object Oriented Structured Design (OOSD), Wasserman.  Object Oriented Systems Analysis (OOSA), Shaler y Mellor.  Responsibility Driven Design (RDD), Wirfs-Brock, entre otros.

15 15 Diseño del software El paradigma “00” Orientación a objetos  Enfoque OO Este paradigma centra su foco en el concepto Objeto. Objeto es aquello que tiene estado (propiedades más valores), comportamiento (acciones y reacciones a mensajes) e identidad (propiedad que lo distingue de los demás objetos). La estructura y comportamiento de objetos similares están definidos en su clase común; los términos instancia y objeto son intercambiables. Una clase es un conjunto de objetos que comparten una estructura y comportamiento común. La diferencia entre un objeto y una clase es que un objeto es una entidad concreta que existe en tiempo y espacio, mientras que una clase representa una abstracción, la "esencia" de un objeto, tal como son. De aquí que un objeto no es una clase, sin embargo, una clase puede ser un objeto.  Beneficios del enfoque OO Los beneficios señalados por Booch en 1986 son: Potencia, el uso del modelo OO ayuda a explotar el poder expresivo de los lenguajes de programación basados u orientados a objetos, como Smalltalk, Object Pascal, C++, CLOS, Ada, Java, C# Reutilización, el uso del modelo OO favorece la reutilización, no solo del software, sino de diseños completos. Mantenibilidad, produce sistemas que están construidos en formas intermedias estables y por ello son más resistentes al cambio en especificaciones y tecnología.

16 16 Diseño del software El paradigma “00” Orientación a objetos  Principios del modelo OO  Abstracción. Simplificación en la descripción o especificación de un sistema consistente en enfatizar algunos detalles o propiedades del sistema, con detrimento o supresión de otros.  Encapsulación. Ocultación de los detalles de un objeto que no contribuyen a sus características esenciales.  Modularidad. Propiedad de un sistema que ha sido descompuesto en un conjunto de módulos coherentes e independientes.  Jerarquía o herencia. Orden de las abstracciones organizado por niveles.  Tipificación. Definición precisa de un objeto de forma tal que objetos de diferentes tipos no puedan ser intercambiados o, a lo sumo, pueden intercambiarse de manera muy restringida.  Concurrencia. Propiedad que distingue un objeto que está activo de uno que no lo está.  Persistencia. Propiedad de un objeto por la cual su existencia trasciende al tiempo (es decir, el objeto continua existiendo después de que su creador ha dejado de existir) y/o al espacio (es decir, la localización del objeto se mueve del espacio de dirección en que fue creado). Fundamentales: Abstracci ó n, encapsulaci ó n, modularidad y jerarqu í a. Booch afirma que un modelo en el que no est é presente alguno de estos principios NO es un modelo OO. Complementarios: Tipificaci ó n, concurrencia y persistencia

17 17 Diseño del software UML UML es un lenguaje de modelado que permite especificar, visualizar y documentar modelos de sistemas de software. Desde sus inicios fue concebido para ayudar a las tareas de an á lisis de los sistemas de software, y este es sin duda el á mbito de mayor utilizaci ó n, si bien es cierto que en la actualidad tambi é n se emplea en el modelado y dise ñ o de otros tipos de sistemas (modelos de negocio, producciones cinematogr á ficas, etc.)  Tipos de diagramas UML UML proporciona diagramas para representar modelos de las visiones est á ticas y din á micas del sistema, as í como de su modularizaci ó n. Estructura estáticaComportamiento dinámicoModularización REPRESENTACIONES  Diagrama de clases  Diagrama de objetos  Diagrama de componentes  Diagrama de despliegue  Diagrama de casos de uso  Diagrama de secuencia  Diagrama de colaboración  Diagrama de actividad  Diagrama de colaboración  Diagrama de estados  Paquetes  Subsistemas  Modelos

18 18 Diseño del software Descripción del diseño del software (SDD) El resultado del proceso de dise ñ o es la documentaci ó n denominada “ Descripci ó n del Dise ñ o del Software ”. Un est á ndar empleado para desarrollar esta documentaci ó n de forma normalizada es el IEEE Std. 1016-1998.  IEEE Std. 1016-1998 Describe pr á cticas recomendadas para describir los dise ñ os de software. Especifica la informaci ó n que debe contener, y recomienda c ó mo organizarla. Puede emplearse en software comercial, cient í fico o militar sin limitaciones por el tama ñ o, complejidad o nivel de criticidad. El est á ndar no establece ni limita determinadas metodolog í as de dise ñ o, gesti ó n de la configuraci ó n o aseguramiento de la calidad.

19 19 Diseño del software Descripción del diseño del software (SDD)  Ejemplo de una posible organización de la información en una SDD 1.- Introducci ó n 1.1 Prop ó sito 1.2 Alcance 1.3 Definiciones y acr ó nimos 2.- Referencias 3.- Descomposici ó n de la informaci ó n 3.1 Descomposici ó n modular 3.1.1. Descripci ó n del m ó dulo 1 3.1.2. Descripci ó n del m ó dulo 2 3.2 Descomposici ó n de los proceesos 3.2.1. Descomposici ó n del proceso 1 3.2.2. Descomposici ó n del proceso 2 3.3 Descomposici ó n de los datos 3.3.1. Descripci ó n de la entidad 1 3.3.2. Descripci ó n de la entidad 2 4.- Descripci ó n de las dependencias 4.1 Dependencias intermolulares 4.2 Dependencias inter-procesos 4.3 Dependencias de los datos 5.- Descripci ó n de interfaces 5.1 Interfaces entre m ó dulos 5.1.1 Interfaz del m ó dulo 1 5.1.2 Interfaz del m ó dulo 2 5.2 Interfaces entre procesos 5.2.1 Interfaz del proceso 1 5.2.2 Interfaz del proceso 2 6.- Dise ñ o detallado 6.1 Dise ñ o detallado de los m ó dulos 6.1.1 Detalle del m ó dulo 1 6.1.2 Detalle del m ó dulo 2 6.2 Dise ñ o detallado de los datos 6.1.1 Detalle de la entidad 1 6.1.2 Detalle de la entidad 2

20 20 Diseño del software  Comprobación de que el diseño incluye todos lols requisitos  Comprobación de que el diseño no incluye funciones adicionales no especificadas en el SRS.  Los resultados de la trazabiliad del diseño deben estar documentados para la reunión de revisión del diseño  Trazabilidad del diseño Prácticas recomendadas  Reunión de revisión del diseño de la arquitectura Revisión del diseño de la arquitectura  Un equipo apropiado (Usuarios, cliente, ingeniero de soft) revisan el diseño.  Una vez aprobado este diseño de puede comenzar a realizar el diseño detallado.  Verificación del diseño de la arquitectura El diseño se verifica contra el SRS  El proceso de verificación analiza si el diseño es incompleto, incorrecto, ineficiente, difícil de mantener, presenta un interfaz de usuario difícil de utilizar o aprender, o la documentación es de baja calidad.  Se realiza un informe para documentar los posibles problemas encontrados y tomar nota de posibles incompatibilidades entre documentos. LÍNEA BASE DE REQUISITOS LÍNEA BASE DE DISEÑO QUÉ CÓMO

21 21 Diseño del software Base para las tareas de planificación La planificación comienza con la misma decisión de desarrollar un sistema de software, y es un esfuerzo continuo que termina cuando el proyecto ha concluido. La planificación consiste en la especificación de:  Metas y objetivos para el proyecto  Estrategias, “política”, y procedimientos Explicándolo de otra forma es la decisión de:  qué hacer  cómo hacerlo  cuando hacerlo  quien va a hacerlo. A lo largo del ciclo de vida, desde la concepción inicial del proyecto, la planificación se va revisando y depurando, y una vez obtenido el diseño se dispone de una base sólida. El diseño es la representación formal de “qué hacer” y “cómo hacerlo”, sobre la que se puede asignar “cúando” y “quién”.

22 22 Diseño del software Planificación = tareas de ingeniería del software y de gestión La planificación del proyecto está dividido entre dos componentes relacionados:  Planificación realizada por el gestor  Planificación realizada por el ingeniero de sistemas Qué tareas hay que realizar Orden y Dependencias de tareas Tamaño (Esfuerzo en horas) Solución técnica para la resolución del problema Qué herramientas de análisis y diseño hay que utilizar Riesgos técnicos El modelo de procesos (Técnicas) Actualizar la planificación cuando los requisitos o el entorno cambian. Ingeniero de Software decide: Las habilidades necesarias para realizar las tareas La agenda para terminar el proyecto El coste de esfuerzo Metodología para evaluar el estatus del proyecto Qué herramientas de planificación hay que utilizar Gestión de riesgos El modelo de procesos (Gestión) Actualizar la planificación cuando condiciones de gestión y entorno cambian. Gestor de Proyecto decide:

23 23 Diseño del software Consideraciones  El diseño es la estrategia de solución.  Las tareas de codificación, integración y mantenimiento del sistema son la táctica.  La estrategia debe ser adecuada a las necesidades de los usuarios (requisitos y atributos de calidad esperados).  No surge de procesos, herramientas o lenguajes de modelado.  Surge del talento de su creador.  Los procesos, las herramientas y los lenguajes de modelado pueden resultar útiles como ayuda para descomponer la complejidad, y para comunicar el diseño a los participantes del proyecto.  El talento de algunos profesionales les puede permitir manejar niveles de complejidad elevados sin necesitar apoyo de procesos, herramientas o lenguajes de modelado.  A través del código es posible ver el diseño y la arquitectura del sistema.  La documentación del código resulta útil para comunicar su diseño a través del espacio en sistemas en los que intervienen muchos desarrolladores, y del tiempo para facilitar su mantenimiento.  Al emplear documentación para la comunicación del diseño es necesario trabajar con procesos suficientes para garantizar su integridad y actualidad a través de los cambios.  El diseño no cumple su finalidad hasta que no queda plasmado en el código.  El resultado del diseño puede fallar tanto errores en su estrategia como por distorsiones introducidas en la codificación, integración y mantenimiento.