compendio de ingeniería del softwarecotana.informatica.edu.bo/downloads/diseno-componentes.pdf ·...
TRANSCRIPT
2.7 DISEÑO AL NIVEL DE COMPONENTES
MODULO II
Ingeniería de Software INF - 163
Resumen preparado por Miguel Cotaña 1
22/10/2012
Es un bloque de construcción
modular para el software de
computo.
Es una parte modular,
desplegable y reemplazable de
un sistema que encapsula
implementación y expone un
conjunto de interfaces. 2
QUÉ ES UN COMPONENTE?
Los componentes residen en el
interior de la arquitectura del
software, deben comunicarse y
colaborar con otros componentes
y con entidades (como otros
sistemas, dispositivos, personas)
que existen fuera de los límites
del software. 3
Szypersky: “Unidad de composición de aplicaciones de software, que posee un conjunto de interfaces y requisitos, y que ha de poder ser desarrollado, adquirido, incorporado al sistema y compuesto con otros componentes de forma independiente, en tiempo y espacio.”
5
Aislamiento: puede ser instalado de forma independiente de la plataforma.
Componibilidad: Un componente puede ser compuesto con otros para formar aplicaciones.
Opacidad: Un componente se maneja siempre de forma opaca, sin que los diseñadores de aplicaciones que lo manejan ni el entorno tengan que acceder a sus detalles internos para hacer uso de él.
6
7
Tipos de componentes
Por ejemplo: clientes solicitan
productos. La aplicación utiliza
un servicio de autorización de
tarjetas de crédito y autorizar
la venta. Una vez verificada la
tarjeta, se utiliza un servicio
de correo para organizar la
entrega de los productos. 8
Contiene un conjunto de clases
que colaboran entre sí.
Cada clase de un componente
se ha elaborado
completamente para incluir
todos los atributos y las
operaciones relevantes para su
implementación.
Componente Orientada a Objetos
9
Como parte de la elaboración
del diseño, también deben
definirse todas las interfaces
(mensajes). Ej.: Considerando un software para una
imprenta. Mostrar las necesidades del
cliente en un mostrador, cotizar un
trabajo de impresión y pasarlo a una
planta de producción automatizada. 10
La IS, ha destacado la necesidad
de construir sistemas que usen
los componentes de Sw
existentes.
Un catálogo de componentes
probados al nivel de diseño o de
código queda a disposición del
IS. Se eligen del catálogo.
Componente relacionado con el Proceso
11
Cuando se elige un método de
IS basado en componentes, el
diseño a nivel de estos se
concentra en la elaboración de
las clases de análisis y la
definición y la afinación de las
clases de infraestructura.
Diseño de Componentes basados en clases
12
principio abierto-cerrado (PAC):
un módulo debe estar abierto para
extensión, pero cerrado para
modificación;
principio de sustitución de
Liskov (PSL): debe tenerse la
opción de sustituirse las subclases
con sus clases principales;
Principios básicos de diseño
13
Principio de inversión de la
dependencia (PID): dependa de
las abstracciones; no de las
concreciones ;
Principio de segregación de la
interfaz (PSI): es mejor tener
muchas interfaces específicas del
cliente que una interfaz de propósito
general; 14
Principio de equivalencia entre
reutilización y versión (PER): la
esencia de la reutilización es la misma
que de la versión ;
Principio del cierre común (PCC):
Las clases que cambian juntas deben
permanecer juntas;
Principio común de la reutilización:
las clases que no se reutilizan juntas
no deben agruparse juntas. 15
Componentes: deben definirse
convenciones de asignación de
nombres para componentes
especificados como parte del
modelo arquitectónico, y luego
refinarse y elaborarse como
parte del diseño al nivel de
componentes.
Líneas generales de diseño al nivel de componentes
16
Interfaces: proporcionan
información importante acerca
de la comunicación y la
colaboración;
Dependencias y herencias:
modelar las dependencias de
izquierda a derecha y la herencia
de abajo hacia arriba. 17
En el contexto del diseño al nivel
de componentes para sistemas
OO, la cohesión implica que un
componente o una clase sólo
encapsula atributos y
operaciones relacionadas
estrechamente entre sí y con la
clase del propio componente.
Cohesión
18
Lethbridge, define varios tipos
de cohesión:
Funcional. Exhibido
principalmente para operaciones,
este grado de cohesión se
presenta cuando un módulo
realiza un solo cálculo y luego
devuelve un resultado; 19
De capa. Exhibido para
paquetes, componentes y clases,
este tipo de cohesión ocurre
cuando una capa superior tiene
acceso a los servicios de una
inferior, pero ésta no tiene
acceso a aquella;
20
De comunicación. Todas las
operaciones con acceso a los
mismos datos se definen dentro
de una clase.
Resulta relativamente fácil de
implementar, probar y mantener
las clases y los componentes que
muestran los 3 tipos anteriores. 21
Sin embargo, hay casos en que
se encuentran los siguientes
niveles inferiores de cohesión:
Secuencia;
Procedimental;
Temporal;
Utilitarias.
22
Es una medida cualitativa del
grado al que las clases se
conectan entre sí. A medida que
las clases (y los componentes)
se vuelven más
interdependientes, el
acoplamiento aumenta.
Acoplamiento
23
Lethbridge, define las siguientes
categorías de acoplamiento:
De contenido. Ocurre cuando
un componente “modifica
subrepticiamente datos internos
de otro”. Esto viola la ocultación
de la información, que es un
concepto básico del diseño; 24
Común. Ocurre cuando varios
componentes usan una variable
global. Puede llevar a la
propagación incontrolable de
errores.
De control. Se presenta cuando
la operación A() invoca a B() y
pasa una marca de control a B 25
De estampa;
De datos;
De llamada a rutina;
De uso de tipo;
De inclusión o importación;
Externo.
26