Diseño del Software Requirements specification Design acti vities Architectural design Abstract specificatio n Interface design Component design Data structure design Algorithm design System architecture Software specification Interface specification Component specification Data structure specification Algorithm specification Design pr oducts
De la Arquitectura al Diseño ξ ω α(ω) (α σ) ε β(ε) ρ(ε) ε ε Ω φ(ε) 2.4 λ δ τ program pepe(); Diseño del Software Ingeniería del Software 1 2
Criterios Generales No existe el método ni el criterio general Hay criterios Uso de varias técnicas Formalidad vs. facilidad de instrumentos División en módulos para reducir la complejidad y prevenir cambios Diseño del Software Ingeniería del Software 1 3
Módulos: Visión estática De c/u de los subsistemas. El detalle hacia el código pueden estar divididos en submódulos no son rutinas pueden tener memoria persistente Herramienta para reagrupar tipos, estructuras de datos, subprogramas, etc. Porción de software que brinda recursos y servicios computacionales Diseño del Software Ingeniería del Software 1 4
Diseño Esta fase se refiere por lo tanto a la identificación de varios módulos y su interrrelación Diseño del Software Ingeniería del Software 1 5
Estrategias de Diseño Diseño funcional El sistema es diseñado desde un punto de vista funcional. El estado del sistema es centralizado y compartido entre las funciones que operan sobre el mismo. Diseño Orientado a Objetos El sistema es visto como una colección de objetos interactuando. El estado del sistema es decentralizado y cada objeto maneja su propio estado. Objetos pueden ser instancias de clases de objetos y pueden comunicarse a través de métodos. Diseño del Software Ingeniería del Software 1 6
Factores Principales Cohesión: unidad sustancialmente homogénea y que sea fácilmente comprendida Desacoplamiento entre módulos ser comprendidos mirando sólo a ellos Hacen a la independencia funcional Alta cohesión no implica alto desacoplamiento, ni viceversa Diseño del Software Ingeniería del Software 1 7
Niveles Cohesión Coincidental cohesion (débil) Las partes son unidas por coincidencia Logical association (débil) Componentes que realizan funciones similares son agrupadas Temporal cohesion (débil) Componentes que son activadas al mismo tiempo son agrupadas Procedural cohesion (débil) Los elementos en una misma secuencia son agrupados Diseño del Software Ingeniería del Software 1 8
Niveles de Cohesión Communicational cohesion (media) Todos los elementos de una misma componente operan sobre el mismo input o producen el mismo output Sequential cohesion (media) El output de una parte del componente es el input de otra parte Functional cohesion (fuerte) Cada parte de una componente es necesaria para la ejecución de una función Object cohesion (fuerte) Cada operación provee funcionalidades para modificar o inspeccionar los atributos de un objeto Diseño del Software Ingeniería del Software 1 9
Acoplamiento fuerte Module A Module B Module C Module D Shared data area Diseño del Software Ingeniería del Software 1 10
Acoplamiento débil Module A A s data Module B B s data Module C C s data Module D D s data Diseño del Software Ingeniería del Software 1 11
Hacia un Diseño Modular 5 Criterios Descomponibilidad Componibilidad Comprensibilidad Continuidad Protección 5 Reglas Mapeo Directo Pocas Interfaces Pequeñas interfaces Interfaces explícitas Information Hiding 5 Principios Unidad Lingüística Modular Autodocumentación Uniformidad de Acceso Abierto-Cerrado Simple Opción Diseño del Software Ingeniería del Software 1 12
Descomponibilidad Modular Un método de construcción satisface DM si ayuda en la tarea de descomposición del problema software en un número de problemas menos complejos conectados por una estructura simple y lo suficientemente independiente para permitir que el resto del trabajo proceda separadamente (B. Meyer) División de Trabajo Dependencias: pocas pero Conocidas Ej. Top-Down Design ContraEj.: Módulo global de inicialización buena cohesión temporal poca autonomía modular se rompe information hiding En OO cada módulo es responsable de su inicialización. Diseño del Software Ingeniería del Software 1 13
Componibilidad Modular Un método de construcción satisface CM si ayuda en la producción de elementos que pueden ser libremente compuestos uno con el otro para producir sistemas nuevos, posiblemente en un ambiente distinto del cual fue inicialmente desarrollado. Sacarlos del contexto original para ser reusados El sueño de la fábrica de ensamblaje Independiente de Descomponibilidad atención con Top-Down Design EJ.1.: librerías (B. Meyer) Ej.2: Shells Unix ContraEj.: Preprocesadores (c++) Diseño del Software Ingeniería del Software 1 14
Comprensibilidad Modular Un método de construcción satisface Comprensibilidad Modular si ayuda en la producción de software en la cual un lector humano puede entender cada módulo sin tener que conocer o examinar a ninguno del resto. Proceso de Mantenimiento ContraEj.: dependencia secuencial A!B!C (se entiende B sin A y C?) Documentación (B. Meyer) Diseño del Software Ingeniería del Software 1 15
Continuidad Modular Un método de construcción satisface Continuidad Modular, si en la arquitectura de software en la cual se basa, un pequeño problema en la especificaicón dispara un cambio de sólo un módulo o un pequeño grupo de módulos Extendibilidad No definible formalmente Ej.1.: Constantes simbólicas Ej.2.: Principio de Acceso Uniforme (a un objeto sea este un dato directo o algo a ser computado) ContraEj.1: Usar representaciones físicas (B. Meyer) ContraEj.2: Arrays estáticos Diseño del Software Ingeniería del Software 1 16
Protección Modular Un método de construcción satisface Protección Modular, si lleva a que en las arquitecturas en las que ocurre una condición anormal en run time en un módulo queden confinados al mismo, o a lo sumo sólo a pocos vecinos. (B. Meyer) Evitar propagación de Errores Runtime por hardware, mal input, falta de recursos como memoria, etc. Ej.: validar input en la fuente ContraEj.: Excepciones Indisciplinadas Diseño del Software Ingeniería del Software 1 17
Mapeo Directo Pocas Interfaces Una estructura modular definida en el proceso de construcción de un sistema software debe mantenerse compatible con toda estructura modular definida en el proceso de modelar el dominio del problema. Modelos (B. Meyer) Cada Módulo debe comunicarse con los menos posibles de otros (B. Meyer) Si hay n módulos en lo posible lo más cerca de n-1 conexiones y no a n(n-1)/2! Continuidad Componibilidad Continuidad Descomponibilidad (aprovechar lo hecho) Diseño del Software Ingeniería del Software 1 18
Pequeñas Interfaces Explícitas Si dos módulos se comunican, deberían intercambiar la menor cantidad de información posible. Continuidad Protección (B. Meyer) ContraEj.: Common de Fortran, Programación extremadamente estructurada (muchos parámetros) Cuando dos módulos A y B se comunican, esto debe ser obvio del texto código de ambos. Continuidad Componibilidad (B. Meyer) Descomponibilidad Comprensibilidad Problema con los acoplamientos indirectos como por Shared Memory Diseño del Software Ingeniería del Software 1 19
Information Hiding El diseñador de cada módulo debe seleccionar un subconjuto de propiedades del módulo como la información oficial sobre el mismo, para hacerlo disponible a los autores de los módulos clientes. Propiedades Publicas y Privadas (o secretas) Separación de funciones de implementación (TDA y OO) Interfaz --- Iceberg Continuidad Descomponibilidad (B. Meyer) Componibilidad No implica protección Encapsulamiento Comprensibilidad Ej.: procedimiento de acceso a una tabla indexada Diseño del Software Ingeniería del Software 1 20
Notación Sea M un conjunto de módulos: M = {m 1,m 2,...,m n } Una relación R sobre M es R M x M Un módulo m i está en relación R con m j ssi <m i,m j > R. Notación: m i Rm j Diseño del Software Ingeniería del Software 1 21
Representación en Grafo Grafo dirigido G = <N,A> A N x N a N M A R b e Ej: M = {a,b,c,d,e} R = {<a,b>,<a,e>,<b,c> <e,d>,<d,c>} c d Diseño del Software Ingeniería del Software 1 22
Características de la relación No puede ser reflexiva: <m i,m i > R puede ser simétrica y transitiva grafos acíclicos: Ej.: árboles si i <m i,m i > R* (clausura transitiva) directo y acíclico jerarquía muchos caminos entre dos nodos concepto de nivel Diseño del Software Ingeniería del Software 1 23
Distintos Niveles System level Sub-system level Diseño del Software Ingeniería del Software 1 24
La relación USA Describe las funcionalidades que brinda un módulo y cuales son las funcionalidades que un módulo necesita m i resulta ser un cliente de los servicios que provee m i esta en relación USA con m j (m i USA m j ) si para que el módulo m i sea correcto si necesita la correcta ejecución de m j. m j Diseño del Software Ingeniería del Software 1 25
La relación USA se define estáticamente describe el desacoplamiento llamadas a procedimientos no siempre implican USA y viceversa aciclicidad Casos extremos: USA = M x M USA = Indicaciones: minimizar arcos salientes maximizar arcos entrantes análisis por niveles de abstracción Diseño del Software Ingeniería del Software 1 26
La relación Es_Componente_De Relación en la dirección de refinamiento sucesivos (topdown) Debe ser una jerarquía (no necesariamente un árbol) Sólo las hojas se implementan efectivamente Los nodos internos son módulos lógicos Diseño del Software Ingeniería del Software 1 27
Indicaciones Redefinición de USA respecto a Es_Componenete_De Construcción Incremental Postergar las decisiones INFORMATION HIDING cajas negras definidas por los servicios que brindan Interfaz e Implementación Exportación e Importación principio de división de trabajo Qué esconder? Diseño del Software Ingeniería del Software 1 28
Descripciones de Diseño Notaciones Gráficas. Usadas para mostrar relaciones entre los componentes Lenguajes de descripción de Programas. Basados en lenguajes de prog. pero con más flexibilidad para representar conceptos abstractos. Texto informal Descripción en lenguaje natural Todas estas notaciones pueden ser usadas para diseñar sistemas grandes Diseño del Software Ingeniería del Software 1 29
Diseño Orientado a Objetos Estrategia de diseño basada en INFORMATION HIDING ABSTRACCION MODULARIDAD Crea una representación del mundo real y lo corresponde con una solución basada en los datos Diseño del Software Ingeniería del Software 1 30
Diseño OO El software es visto como un conjunto de objetos que interactúan, con su estado privado, en vez de un conjunto de funciones que comparten un estado global O1 estado 1 O2 estado 2 O3 estado 3 O4 estado 4 El mundo es visto como un conjunto... Diseño del Software Ingeniería del Software 1 31
Características Los objetos son abstracciones del mundo real o entidades del sistema que son responsables de manejar su estado privado y ofrecen servicios a otros objetos. Son un modelo de los objetos externos que pueblan el mundo en que actúa el programa. Los objetos son entidades independientes que pueden ser rápidamente cambiados por la información de la representación y el estado queda dentro del objeto. un objeto es caracterizado al exterior sólo por la interfaz que brinda, es decir el conjunto de recursos que pone a disposición. Diseño del Software Ingeniería del Software 1 32
Características La funcionalidad del sistema es expresada en términos de operaciones y servicios asociados con cada objeto. Áreas de datos compartidos son eliminados. Los objetos se comunican llamando los servicios ofrecidos en vez de compartir variables. Disminuye el acoplamiento Disminuye el riesgo de modificaciones a datos compartidos Los objetos pueden ser distribuidos y pueden ejecutarse en paralelo o concurrentemente. Estas decisiones no deben tomarse tempranamente. recordar: posponer lo mayor posible toda decisión trascendente de diseño. Diseño del Software Ingeniería del Software 1 33
No preguntes qué hace el sistema sino qué le hace a qué cosa OOD es el método que permite definir arquitecturas del software basados en los objetos que todo sistema o subsistema usa OOD es la construcción de sistemas software como una colección estructurada de TAD. Diseño del Software Ingeniería del Software 1 34
Criterios Descomponibilidad: facilidad de descomponer un gran problema en subproblemas Componibilidad: facilidad de reuso Comprensibilidad: facilidad de entender un módulo por sí solo Continuidad: pequeños cambios implican pocos cambios Protección: reducir efectos colaterales lo buscado por cualquier método de diseño Diseño del Software Ingeniería del Software 1 35
7 conceptos Object based modular structure: los sistemas están modularizados en base a su estructura de datos. Data abstraction: los objetos deberían ser descriptos como implementaciones de TADs. Automatic Memory Management: los objetos no usados deberían ser liberados por el lenguaje subyacente. Clases: cada tipo no primitivo es un módulo y cada módulo de alto nivel es un tipo. Diseño del Software Ingeniería del Software 1 36
7 conceptos Una clase puede ser definida como una extensión o una restricción sobre otras. Polimorfismo y Dynamic Binding: se deben permitir referencias a objetos de más de una clase y las operaciones deben poder realizarse en diferentes clases. Múltiple y repetida herencia: debe ser posible declarar una clase como herede de más de una clase o más veces de la misma. Diseño del Software Ingeniería del Software 1 37
Clases module exports La clase es el tipo del objeto Clase Persona atributos nombre: string; apellido: string; servicios presentate() implementation Francisca Verdi Mario Rossi Carla Bianchi clase persona: descripción de las características comunes a todos los objetos de tipo persona Diseño del Software Ingeniería del Software 1 38
HERENCIA En el mundo real los objetos son clasificados según características comunes Título del diagrama Vertebrados Peces Anfibios Reptiles Pájaros Mamíferos Corvinas Surubíes Carnívoros Herbívoros El mismo principio se puede aplicar a los objetos de un programa. La clasificación se hace definiendo un nuevo tipo como extensión de un tipo preexistente Diseño del Software Ingeniería del Software 1 39
La relación HEREDA_DE presentate() presentate() Persona Atributos nombre: string; apellido: string Estudiante Atributos matrícula: int; la clase (el módulo) estudiante extiende la clase (el módulo) persona: AGREGANDO un nuevo atributo (matrícula) REDEFINIENDO un servicio (presentate) Heredadas por por ser ser persona también nombre = Piero apellido = Fraternalli matricula = 585/96 presentate() = Buen día soy Fraternalli, estudiante 585/96 Diseño del Software Ingeniería del Software 1 40
HEREDA_DE => ES_UN (IS_A) nombre peso Persona unión existe vacío Conj. de Enteros Hombre Embarazada Mujer Conj. de Enteros Ordenados 1er Elem existe Diseño del Software Ingeniería del Software 1 41