(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