DISEÑO DE COMPONENTES DE SOFTWARE *

Tamaño: px

Comenzar la demostración a partir de la página:

Download "DISEÑO DE COMPONENTES DE SOFTWARE *"

Joaquín Rodríguez Mora
hace 8 años
Vistas:

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

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

según la OMG Unified Modeling Language Specification Se puede definir y usar componentes desde 3

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

El diseño de un componente implica añadir a la definición de clases en el

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

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

requeridas para implementar dicha lógica y una interfaz que permite que el componente sea

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

el usuario Componente de infraestructura: responsable de las funciones que apoyan el procesamiento requerido en

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

componentes o patrones de diseño de un catálogo, los cuales

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

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

Cualquier clase derivada de una clase base debe cumplir con cualquier contrato implícito de la clase base con respecto a los

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

Principio de segregación de interfaces: Varias interfaces dependientes del

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

Agrupar clases reusables en paquetes que se puedan administrar y controlar cuando una nueva versión se genere.

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

las que sean relevantes Modele las dependencias de izquierda a derecha y la herencia

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

Se busca la máxima cohesión en una clase Acoplamiento es la medida cualitativa del grado en que

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

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

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

Desarrolle y elabore representaciones del comportamiento de una clase o componente (diagramas de estados) 6.

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

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

10) Las tablas de decisión se utilizan para definir procesos con una gran cantidad de condiciones y acciones Los

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

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

Documentos relacionados

Fundamentos del diseño 3ª edición (2002)

Unidades temáticas de Ingeniería del Software Fundamentos del diseño 3ª edición (2002) Facultad de Informática necesidad del diseño Las actividades de diseño afectan al éxito de la realización del software