Sesion 7 3 diseño diagramas de componentes

Preview:

Citation preview

Diseño:Diagrama de componentes

Lic. César Alcántara Loayza

2CAL/Fundamentos

Diagrama De Componentes

El propósito del diagrama de componentes es definir los módulos de software cualquiera sea su fuente, y sus relaciones entre si.

3CAL/Fundamentos

Diagrama De Componentes

Cada componente es un pedazo de código que reside en la memoria en un nodo del hardware. Cada componente debe definir una interface que permita al componente actuar recíprocamente con el sistema operativo y otros componentes. Se encapsulan la interface y la aplicación interior del componente en las clases que constituyen el componente.

4CAL/Fundamentos

Grupos De Componentes UML agrupa los componentes en tres

categorías amplias: Componentes desplegados, necesarios

para ejecutar el sistema, Componentes producto del trabajo

incluso modelos, código fuente, y archivos usados para crear los componentes de despliegue

Componentes de Ejecución, componentes creados para ejecutar la aplicación

5CAL/Fundamentos

Los componentes pueden depender entre si. Por ejemplo, un ejecutable puede requerir el acceso a una biblioteca de enlace dinámica (DLL). Los componentes pueden ser dependientes en clases. Por ejemplo, para compilar un archivo ejecutable, usted necesita proporcionar las clases fuente.

Dependencias de Componentes

6CAL/Fundamentos

Dado los elementos clave, componente, interface del componente y dependencias, usted puede describir la aplicación física de módulos de software y las relaciones entre ellos.

Dependencias de Componentes

7CAL/Fundamentos

Un componente es modelado como un rectángulo con dos rectángulos pequeños centrados en el borde izquierdo. El nombre se pone dentro del rectángulo tal como lo hacemos en el compartimiento de nombre de una clase.

Notación

8CAL/Fundamentos

Notación Notación de un componente

OrderEntry.exe

9CAL/Fundamentos

Estereotipos

Los componentes usan los estereotipos para proporcionar las pistas visuales a su papel dentro de la implementación. El UML define cinco tipos de estereotipos del componente: Executable: Un componente que corre en un

procesador Library: Un conjunto de recursos referenciados

por un ejecutable durante el tiempo de ejecución

10CAL/Fundamentos

Estereotipos Table: Un componente de la base de

datos accedido por un ejecutable File: Típicamente representa datos o

código fuente Document: Un documento tal como

una página insertada en una página web

11CAL/Fundamentos

Notación

Estereotipo <<executable>>

OrderEntry.exe<<EXE>>

12CAL/Fundamentos

Interface de Componente

Una interface de componente puede modelarse de dos maneras. Una manera es usar una clase con el estereotipo <<interface>> ligado al componente con una flecha de la dependencia. Usted puede usar un estereotipo de dependencia de <<Implements>> para mostrar que el componente implementa la interface.

13CAL/Fundamentos

Interface de Componente Interface Orden que implementa el

componente OrderEntry

OrderEntry.exe<<EXE>>

Order<<Interface>><<Implements>>

14CAL/Fundamentos

Interface de Componente

Una segunda técnica es usar un "chupetin" ligado al componente con una línea sólida, llamado una relación de la realización. Realizar la interface significa implementar la interface.

15CAL/Fundamentos

Interface de Componente

OrderEntry.exe<<EXE>>

Order

16CAL/Fundamentos

Interface de Componente Recuerde que la interface implementada

por un componente realmente se lleva a cabo por las clases dentro del componente. De modo que la interface ya debería estar definida en sus diagramas de clase.

17CAL/Fundamentos

Dependencias

las dependencias entre los componentes son representados con flechas discontinuas del componente dependiente al componente del que depende. Como con la dependencia de interface, pueden estereotiparse las dependencias entre los componentes.

18CAL/Fundamentos

Construir un Diagrama De Componentes

El estereotipo <<becomes>> muestra que el cosigo fuente se vuelve un componente ejecutable y que se ejecuta en una máquina diferente de la que reside el codigo fuente.

OrderEntry.exe<<EXE>>

OrderEntry<<File>>

Orders.dll<<DLL>>

Inventory.tbl<<Database>>

Orders.tbl<<Database>>

<<becomes>>

19CAL/Fundamentos

Construir un Diagrama De Componentes

El diagrama modela la aplicación de entrada de orden. La aplicación consiste en código fuente que se vuelve código ejecutable. El ejecutable maneja dos tablas de datos y un componente de biblioteca.

20CAL/Fundamentos

Tarea: Construir un DC Control de inventario: requerimientos

Los clientes usan una interface gráfica de usuario (GUI) de la aplicación receptor para recibir los productos en el inventario.

La interface de usuario cliente (UI) accede al componente receptor del servidor a través de una interface de orden de compra.

El componente ejecutable del servidor depende de tres bibliotecas de componentes: po.dll, product.dll, e inventory.dll.

21CAL/Fundamentos

Propuesta Solución La interface del usuario se modela como un componente.

La aplicación receptor del servidor es otro componente.

Receiving.exe<<EXE>>

UI.exe<<EXE>>

PurchaseOrder.dll<<Library>>

Product.dll<<Library>>

Inventory.dll<<Library>>

PO

22CAL/Fundamentos

Propuesta Solución El componente receptor del servidor

tiene una interface, el P.O. o interface de orden de compra. La interface se modela como un círculo pequeño con el nombre debajo de él. Una flecha sólida del componente receptor del servidor a la interface define la interface le pertenecer al componente servidor.

23CAL/Fundamentos

Propuesta Solución Cada uno de los componentes de

biblioteca se modela como un componente separado, cada uno conectado al servidor con una flecha discontinua de dependencia de la aplicación del servidor al componente de biblioteca.

Recommended