(c) P. Gomez-Gil, INAOE. 2008-2010 1
DISEÑO DE COMPONENTES DE SOFTWARE *
NOTAS DEL CURSO
Ingeniería de Software IDRA. MARIA DEL PILAR GÓMEZ GIL
INAOEP
V:18-11-2008
* Resumen del capítulo 10 de libro de
[Pressman 2010]
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-2010 2
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-2010 3
Ejemplo de elaboración de un componente de diseño
(c) P. Gomez-Gil, INAOE. 2008-2010 4
[Pressman 2005]
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-2010 5
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-2010 6
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-2010 7
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-2010 8
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-2010 9
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-2010 10
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-2010 11
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-2010 12
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-2010 13
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 componentec) Elabore atributos y defina tipos de datos y estructuras de
datos requeridas para implementarlasd) Describa el flujo de procesamiento de cada componente
en detalle
(c) P. Gomez-Gil, INAOE. 2008-2010 14
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-2010 15
Ejemplo de un diagrama de estados
(c) P. Gomez-Gil, INAOE. 2008-2010 16
[Pressman 2005]
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-2010 17
Ejemplo de una tabla de decisión
(c) P. Gomez-Gil, INAOE. 2008-2010 18
[Pressman 2005]
Ejemplo de un pseudocódigo
(c) P. Gomez-Gil, INAOE. 2008-2010 19
[Pressman 2005]
Top Related