diseÑo de componentes de softwarepasos para diseño de componentes (2) 4. describa fuentes de datos...

(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


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.


Ejemplo de elaboración de un componente de diseño


[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”


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


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


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.


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.


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”


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”


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)


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


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


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


Ejemplo de un diagrama de estados


[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


[Pressman 2005]

Ejemplo de un pseudocódigo


[Pressman 2005]

diseÑo de componentes de softwarepasos para diseño de componentes (2) 4. describa fuentes de datos...

Documents