DISEÑO DE SOFTWARE DISEÑO DE SOFTWARE UNIDAD I FUNDAMENTOS Y ELEMENTOS DEL DISEÑO DE SOFTWARE Sesión 2 Proceso del diseño de software

Proceso del Diseño Se ocupa del refinamiento de la representación arquitectónica que lleva a una estructura de datos detallada y a las representaciones algorítmicas del software Diseño Detallado. Se centra en la transformación de los requisitos en datos y la arquitectura del software Diseño preliminar: El Diseño de Software se desarrolla en dos pasos:

Criterios de Calidad Debe exhibir una organización jerárquicaEl diseño al igual que el software, debe ser modular Debe contener representaciones distintas y separadas de los datos y procedimientos Debe llevar a módulos que tenga características funcionales independientes Debe llevar a interfaces que reduzcan la complejidad de las conexiones entre los módulos y el entorno externo Debe obtenerse mediante un método reproducible y que esté conducido por la información recolectada en el análisis de requisitos

¿Qué es el diseño? Proceso por el que se genera una solución a un problema Descripción de la solución Significado de Diseño Fuente :

Diseño y especificación de Requerimientos Fuente :

Diseño y especificación de Requerimientos Fuente :

Niveles de Diseño

Proceso Genérico del Diseño

Etapas del Diseño Diseño Arquitectónico Arquitectura física Arquitectura lógica Modelo de datos Diseño detallado Diseño de módulos detallados Modelo de navegación del sistema Interfaces de usuario Diccionario de datos Documentos DDA-DDD(ESA)

Diseño de la arquitectura del software

Arquitectura Física Se trata de la forma en que se distribuye nuestra aplicación a nuestros usuarios finales en el se denotan los actores y el medio a través del cual se hace llegar la aplicación al computador y/o dispositivo del usuario Expresa cuáles son los componentes físicos (cliente, servidor, servidor Web, BD, etc) que participan en la solución, y la relación entre ellos. La especificación de la Arquitectura Física normalmente consta de uno o más diagramas, y la explicación de los mismos (actores y relaciones entre ellos). Típicamente, la arquitectura física es una formalización del ambiente operacional definido en el Documento de Requisitos. Fuente :

Arquitectura Física Arquitectura Informal Arquitectura Física de Tres Capas

Ejemplo

Arquitectura Lógica Es el diseño conceptual de nuestra aplicación. Aquí se agruparía la arquitectura de la información. Debemos pensar en las necesidades del usuario y en cómo interactuará con nuestra app. La Arquitectura Lógica expresa cuáles son los componentes lógicos (subsistemas, o macro- funciones) que participan en nuestra solución, y la relación entre ellos. La especificación de esta arquitectura, es similar a la arq. física. Se especifican actores y relaciones entre ellos, sólo que los actores ahora son: subsistemas de mi solución o macro- funciones de la misma. Fuente :

Arquitectura Lógica

Ejemplo Arquitectura Lógica

Modelado de Datos El modelo de datos consiste en identificar gráficamente las entidades (o tablas) que participan en mi sistema, ya sean nuevas o existentes Identificar la clave primaria y las claves foráneas de cada una. Podrían incluirse también otros campos...

Diseño Detallado El diseño detallado tiene que ver con el diseño de las micro- componentes de nuestro sistema. Obviamente, este diseño tiene que tener en cuenta los requisitos de software (última versión) y el Diseño arquitectónico. Para efectos del proyecto especificaremos el Diseño Detallado a través de los siguientes ítems: Diseño Detallado de Módulos Modelo de Navegación Interfaces de Usuario Diccionario de Datos Matriz de Trazado

Diseño detallado de Módulos

Diseño detallado de módulos Cada sistema o sub-sistema se debe descomponer en una serie de módulos interrelacionados. Se deben mantener las interfaces de entrada/salida. Cada uno de los módulos del sistema se debe tener un identificador, que luego será usado en el diccionario de datos, para especificar: ID, Nombre (o descripción), Subsistema, Función, Parámetros de Entrada, Parámetros de Salida.

Descomposición y Modularidad Determinar un conjunto de componentes e interfaces entre ellos, que satisfacen un conjunto especificado de requerimientos (De Marco 1982). Métodos de descomposición (Wasserman 1995) Modular (a partir de las funciones) A partir de los Datos A partir de Eventos (y transiciones de Estados) A partir de las Entradas (de afuera hacia adentro) Orientado a Objetos Sistema Modular: cuando cada una de las actividades la realiza exactamente un único componente donde además están bien definidas c/u de sus entradas y salidas. Fuente :

Proceso de Descomposición

Diseño detallado de Módulos

Modelo de Navegación del Sistema

Modelo de Navegación

Interfaz de Usuario Para la Interfaz de Usuario hay que definir: Patrón de interfaz a usar (si hay alguno) Diseño de cada Interfaz

Diccionario de Datos El diccionario de datos tiene 2 componentes: Especificación de Procesos/Pág.Web: Por cada módulo especificado en el punto 3.1, se indica su función, los parámetros que recibe, y los parámetros que retorna. Especificación de Datos: Por cada tabla se especifican los campos y su formato. El diccionario de datos complementa el diseño mostrado en todos los puntos anteriores.

Ejemplo de Especificación de Procesos NOMBRE: Ingreso de Alumnos SUBSISTEMA: Administración de alumnos FUNCIÓN: Este módulo permite al alumno el ingreso/actualización de sus datos personales, por pantalla, a través de un browser. ENTRADAS: RUT (Char(13)). SALIDAS: No Hay. NOMBRE: Solicitud de Certificado SUBSISTEMA: Certificaciones FUNCIÓN: Este módulo permite al alumno solicitar un certificado´tipo A, B, y/o C, por pantalla, a través de un browser. ENTRADAS: Número de matrícula (Char(9)). SALIDAS: Número de solicitud (Entero Serial).

Especificación de Datos Por cada tabla se especifican los campos y su formato

Matriz de Trazado La matriz de trazado es un elemento de control. Su función principal es ver que el diseño refleja los requisitos especificados. Otra de sus funciones tiene que ver con el control de la calidad del diseño realizado. Este elemento es muy útil, si uno aprende a sacar provecho de él. La matriz de trazado debe ir completándose en la medida que el trabajo de diseño avanza. Esta es una actividad paralela a la del diseño.

Matriz de Trazado (cont.)

Matriz de Trazado Si se utiliza ReqAdmin la obtención de la matriz es automática.Se pueden sacar distintas matrices, por ej. Req. Usuarios VS Páginas Web/Componentes. Req. Software VS Páginas Web/Componentes. Casos de Prueba VS Req. Usuario/Software. Casos de Prueba VS Páginas Web/Componentes. Cada matriz tiene un rol distinto.

EJEMPLO PRÁCTICO Tomado de :

Por Donde Iniciar Habilidades valiosas ▫ Conocimiento del negocio ▫ Negociación, ▫ Comunicación, ▫ Validación, ▫ Ejecución ▫ Autoaprendizaje Errores comunes ▫ Pensar primero en implementación ▫ Suponer, no preguntar. ▫ No identificar y mitigar riesgos ▫ Pensar solo en el Happy path ▫ Minimizar la complejidad.

Diagrama de Contexto

Identificación de Sistemas Subsistemas: ▫ LDAPs, Filesystems, Base de datos, servers, Sistema de Generación de Documentos Datos físicos: ▫ IPs, puertos, dominio, Hardware, Instancias, tecnologías de integración, Ventanas de servicio, responsables, entornos previos, convivencia con otras aplicaciones.

Identificación de Interfaces Otros datos de importancia: ▫ Tecnología de integración, códigos de error, frecuencia, horario, volumen de datos, De escritura/Lectura. ▫ Tipo de comunicación: Online/Batch, Síncrona / Asíncrona, ▫ Nueva / A Reutilizar / A Modificar ▫ Restricciones de seguridad

Diagrama de Solución

Ejemplo de Restricciones De desarrollo ▫ El framework de desarrollo es Spring ▫ El código se versionará en un entorno dentro de la organización De seguridad ▫ Los datos sensibles de clientes no deben registrarse en logs De políticas internas ▫ La promoción de la aplicación, cambios por correcciones debe seguir la secuencia de entornos DES -> QA -> PRO De entorno ▫ No hay ambiente de pruebas para el Sistema de Procesamiento de Pago

Ejemplo de Riesgos La mitigación de riesgos frecuentemente modifica la solución, el plan y el alcance de la solución original

Herramientas del Arquitecto Experiencia Principios de Diseño ▫ Composición, Inversión de Control, Modularidad, Bajo acoplamiento, Alta cohesión, Open Closed Patrones de Diseño y Arquitecturales ▫ Patrones GOF: Patrones JEE, Ejemplo: Observer, Fachada ▫ Patrones de Integración, de Arquitectura Ejemplo: Layers, Model-View-Controller ▫ Antipatrones, Otros: ▫ Técnicas de descomposición funcional ▫ Técnicas de estimación de complejidad ▫ Matrices de Decisión ▫ Plantillas

Diagrama de Componentes

Matriz de tecnologías por fila y capa de AutoSeguroWeb

Ejemplo de cambios a mitad del camino Cambio por mejora de performance Problema: La consulta de Catálogos desde el front es tardada ¿Qué opciones de mejora se tienen? Cambio por necesidad de negocio Cambio: La lógica de Cotización y Contratación se requiere que pueda ser consumida por otros sistemas sin depender del front actual.

Diagrama de Componentes

Bibliografía Pressman, R. (2010). Ingeniería de software: Un enfoque práctico. 7 ed. México. Mc Graw Hill. p 805 Sommerville, Ian. "Ingeniería del Software", Capítulo 11. 7ª Edición, Pearson-Addison Wesley, Fuentes :