DISEO DE COMPONENTES DE SOFTWARE *

NOTAS DEL CURSO Ingeniera de Software I

DRA. MARIA DEL PILAR GMEZ GIL INAOEP
* Resumen del captulo 10 de libro de [Pressman 2010]
V:18-11-2008

(c) P. Gomez-Gil, INAOE. 2008-2010

Componente

Bloque de construccin modular para software de computadora Una parte modular, entregable y reemplazable de un sistema que encapsula su implementacin y expone un conjunto de interfaces segn 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 diseo de un componente implica aadir a la definicin de clases en el anlisis (dominio del problema) informacin para su implementacin en software.

(c) P. Gomez-Gil, INAOE. 2008-2010 3

Ejemplo de elaboracin de un componente de diseo

[Pressman 2005]
(c) P. Gomez-Gil, INAOE. 2008-2010 4

Punto de vista convencional

Desde este punto de vista, un componente es un elemento funcional de un programa que incluye lgica de procesamiento, estructuras de datos internas requeridas para implementar dicha lgica y una interfaz que permite que el componente sea invocado y que se le puedan pasar datos. Normalmente llamado mdulo

(c) P. Gomez-Gil, INAOE. 2008-2010

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 funcin 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 diseo de un catlogo, los cuales fueron creados para ser reutilizados

(c) P. Gomez-Gil, INAOE. 2008-2010

Diseando componentes basados en clases

Hay 4 principios bsicos de diseo que se pueden aplicar:

Principio abierto-cerrado: Un componente debe estar abierto a extensiones pero debe estar cerrado para modificaciones. El/la diseador(a) debe especificar el componente de manera que puede extenderse sin necesidad de hacer modificaciones internas al cdigo.
(c) P. Gomez-Gil, INAOE. 2008-2010 8

Diseando componentes basados en clases (2)

Principio de substitucin de Liskov: Las subclases deben ser sustituibles por sus clases bases. Cualquier clase derivada de una clase base debe cumplir con cualquier contrato implcito de la clase base con respecto a los componentes que la usan. Un contrato es una precondicin que debe ser verdadera antes de que el componente use la clase base, y una post-condicin debe ser verdadera despus de que el componente usa la clase base.

(c) P. Gomez-Gil, INAOE. 2008-2010

Diseando componentes basados en clases (3)

Principio de dependencia de inversin: Se debe depender de abstracciones, no de eventos concretos Principio de segregacin de interfaces: Varias interfaces dependientes del cliente son mejor que una interfaz de propsito general

(c) P. Gomez-Gil, INAOE. 2008-2010

10

Principios de empaquetado

Principio de equivalencia de liberacin y reuso: La granularidad del reuso es la granularidad de liberacin. Agrupar clases reusables en paquetes que se puedan administrar y controlar cuando una nueva versin se genere. Principio de agrupamiento comn: Las clases que cambian al mismo tiempo deben agruparse Principio de reuso comn: Las clases que no se reusan al mismo tiempo no deben agruparse
(c) P. Gomez-Gil, INAOE. 2008-2010 11

Guas de diseo

Establecer convenciones para poner nombres Utilice notacin de interfaces siempre que pueda, dibjelas 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

Cohesin y acoplamiento

La cohesin implica que un componente o clase encapsula solo atributos y operaciones que estn altamente relacionados entre ellas y con la clase. Se busca la mxima cohesin en una clase Acoplamiento es la medida cualitativa del grado en que una clase est conectada con otra. Se busca el mnimo acoplamiento entre clases

(c) P. Gomez-Gil, INAOE. 2008-2010

13

Pasos para diseo de componentes

1. 2.

3.

Identifique todas las clases de diseo que correspondan al dominio del problema Identifique todas las clases de diseo que correspondan al dominio de la infraestructura (GUI, sistemas operativos, administracin de datos etc.) Elabore todas las clases que no provienen de clases reusadas
a)

b)
c) d)

Especifique detalles de los mensajes entre clases que colaboran Identifique las interfaces de cada componente Elabore atributos y defina tipos de datos y estructuras de datos requeridas para implementarlas Describa el flujo de procesamiento de cada componente en detalle
(c) P. Gomez-Gil, INAOE. 2008-2010 14

Pasos para diseo de componentes (2)

4.

5.

6.

7.

Describa fuentes de datos persistentes (bases de datos y archivos) e identifique las clases requeridas para manipularlos Desarrolle y elabore representaciones del comportamiento de una clase o componente (diagramas de estados) Elabore diagramas de liberacin (deployment) para dar detalles adicionales de implementacin Revise cada representacin de diseo de los componentes y siempre considere alternativas

(c) P. Gomez-Gil, INAOE. 2008-2010

15

Ejemplo de un diagrama de estados

[Pressman 2005]
(c) P. Gomez-Gil, INAOE. 2008-2010 16

Diseando componentes convencionales

Hay 3 estructuras bsicas: Secuencia, seleccin e iteracin Los diagramas de flujo son los predecesores de los diagramas de actividades (ver figura 11.10) Las tablas de decisin se utilizan para definir procesos con una gran cantidad de condiciones y acciones Los lenguajes de diseo de programas (PDL) tambin llamados ingles estructurado o pseudocdigo permiten definir el detalle de un algoritmo
(c) P. Gomez-Gil, INAOE. 2008-2010 17

Ejemplo de una tabla de decisin

[Pressman 2005]
(c) P. Gomez-Gil, INAOE. 2008-2010 18

Ejemplo de un pseudocdigo

[Pressman 2005]
(c) P. Gomez-Gil, INAOE. 2008-2010 19