(c) P. Gomez-Gil, INAOE. 2008-20101 DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP.

Presentación del tema: "(c) P. Gomez-Gil, INAOE. 2008-20101 DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP."— Transcripción de la presentación:

1 (c) P. Gomez-Gil, INAOE. 2008-20101 DISEÑO DE COMPONENTES DE SOFTWARE * NOTAS DEL CURSO Ingeniería de Software I DRA. MARIA DEL PILAR GÓMEZ GIL INAOEP V:18-11-2008 * Resumen del capítulo 10 de libro de [Pressman 2010]

2 Componente Bloque de construcción modular para software de computadora “Una parte modular, entregable y reemplazable de un sistema que encapsula su implementación y expone un conjunto de interfaces” según la OMG Unified Modeling Language Specification Se puede definir y usar componentes desde 3 puntos de vista: Orientado a Objetos “Convencional” Relacionado a procesos (c) P. Gomez-Gil, INAOE. 2008-20102

3 Punto de vista orientado a objetos Desde este punto de vista, un componente contiene un conjunto de clases que colaboran entre sí. El diseño de un componente implica añadir a la definición de clases en el análisis (dominio del problema) información para su implementación en software. (c) P. Gomez-Gil, INAOE. 2008-20103

4 Ejemplo de elaboración de un componente de diseño (c) P. Gomez-Gil, INAOE. 2008-20104 [Pressman 2005]

5 Punto de vista “convencional” Desde este punto de vista, un componente es un elemento funcional de un programa que incluye lógica de procesamiento, estructuras de datos internas requeridas para implementar dicha lógica y una interfaz que permite que el componente sea invocado y que se le puedan pasar datos. Normalmente llamado “módulo” (c) P. Gomez-Gil, INAOE. 2008-20105

6 Roles de un componente “convencional” Componente de control: Coordina el llamado a otros componentes del dominio del problema Componente del dominio del problema: implementa una función completa o parcial que es requerida por el usuario Componente de infraestructura: responsable de las funciones que apoyan el procesamiento requerido en el dominio del problema Utilizan cartas de estructura para describir sistemas (c) P. Gomez-Gil, INAOE. 2008-20106

7 Punto de vista relacionado al proceso Reutiliza software Cuando se desarrolla la arquitectura, se escogen componentes o patrones de diseño de un catálogo, los cuales fueron creados para ser reutilizados (c) P. Gomez-Gil, INAOE. 2008-20107

8 Diseñando componentes basados en clases Hay 4 principios básicos de diseño que se pueden aplicar: Principio “abierto-cerrado”: Un componente debe estar abierto a extensiones pero debe estar cerrado para modificaciones. El/la diseñador(a) debe especificar el componente de manera que puede extenderse sin necesidad de hacer modificaciones internas al código. (c) P. Gomez-Gil, INAOE. 2008-20108

9 Diseñando componentes basados en clases (2) Principio de substitución de Liskov: Las subclases deben ser sustituibles por sus clases bases. Cualquier clase derivada de una clase base debe cumplir con cualquier contrato implícito de la clase base con respecto a los componentes que la usan. Un “contrato” es una precondición que debe ser verdadera antes de que el componente use la clase base, y una post-condición debe ser verdadera después de que el componente usa la clase base. (c) P. Gomez-Gil, INAOE. 2008-20109

10 Diseñando componentes basados en clases (3) Principio de dependencia de inversión: “Se debe depender de abstracciones, no de eventos concretos” Principio de segregación de interfaces: “Varias interfaces dependientes del cliente son mejor que una interfaz de propósito general” (c) P. Gomez-Gil, INAOE. 2008-201010

11 Principios de empaquetado Principio de equivalencia de liberación y reuso: “La granularidad del reuso es la granularidad de liberación.” Agrupar clases reusables en paquetes que se puedan administrar y controlar cuando una nueva versión se genere. Principio de agrupamiento común: “Las clases que cambian al mismo tiempo deben agruparse” Principio de reuso común: “Las clases que no se reusan al mismo tiempo no deben agruparse” (c) P. Gomez-Gil, INAOE. 2008-201011

12 Guías de diseño Establecer convenciones para poner nombres Utilice notación de interfaces siempre que pueda, dibújelas en el lazo izquierdo de los diagramas y solo las que sean relevantes Modele las dependencias de izquierda a derecha y la herencia de abajo (clase derivada) hacia arriba (clase base) (c) P. Gomez-Gil, INAOE. 2008-201012

13 Cohesión y acoplamiento La cohesión implica que un componente o clase encapsula solo atributos y operaciones que están altamente relacionados entre ellas y con la clase. Se busca la máxima cohesión en una clase Acoplamiento es la medida cualitativa del grado en que una clase está conectada con otra. Se busca el mínimo acoplamiento entre clases (c) P. Gomez-Gil, INAOE. 2008-201013

14 Pasos para diseño de componentes 1. Identifique todas las clases de diseño que correspondan al dominio del problema 2. Identifique todas las clases de diseño que correspondan al dominio de la infraestructura (GUI, sistemas operativos, administración de datos etc.) 3. Elabore todas las clases que no provienen de clases reusadas a) Especifique detalles de los mensajes entre clases que colaboran b) Identifique las interfaces de cada componente c) Elabore atributos y defina tipos de datos y estructuras de datos requeridas para implementarlas d) Describa el flujo de procesamiento de cada componente en detalle (c) P. Gomez-Gil, INAOE. 2008-201014

15 Pasos para diseño de componentes (2) 4. Describa fuentes de datos persistentes (bases de datos y archivos) e identifique las clases requeridas para manipularlos 5. Desarrolle y elabore representaciones del comportamiento de una clase o componente (diagramas de estados) 6. Elabore diagramas de liberación (deployment) para dar detalles adicionales de implementación 7. Revise cada representación de diseño de los componentes y siempre considere alternativas (c) P. Gomez-Gil, INAOE. 2008-201015

16 Ejemplo de un diagrama de estados (c) P. Gomez-Gil, INAOE. 2008-201016 [Pressman 2005]

17 Diseñando componentes “convencionales” Hay 3 estructuras básicas: Secuencia, selección e iteración Los diagramas de flujo son los predecesores de los diagramas de actividades (ver figura 11.10) Las tablas de decisión se utilizan para definir procesos con una gran cantidad de condiciones y acciones Los lenguajes de diseño de programas (PDL) también llamados ingles estructurado o pseudocódigo permiten definir el detalle de un algoritmo (c) P. Gomez-Gil, INAOE. 2008-201017

18 Ejemplo de una tabla de decisión (c) P. Gomez-Gil, INAOE. 2008-201018 [Pressman 2005]

19 Ejemplo de un pseudocódigo (c) P. Gomez-Gil, INAOE. 2008-201019 [Pressman 2005]