MODULO IV. Análisis y Diseño de Sistemas de Información INF-162 III. UML. 4.9 Diagramas de Componentes

Tamaño: px

Comenzar la demostración a partir de la página:

Download "MODULO IV. Análisis y Diseño de Sistemas de Información INF-162 III. UML. 4.9 Diagramas de Componentes"

Jaime Soriano Peralta
hace 6 años
Vistas:

1 MODULO IV Análisis y Diseño de Sistemas de Información INF-162 III. UML 4.9 Diagramas de Componentes Facilitador: Miguel Cotaña 30 de Noviembre

2 Componentes Pertenecen al mundo físico, es decir, representan un bloque de construcción al modelar aspectos físicos de un sistema. Una característica básica es que: debe definir una abstracción precisa con una interfaz bien definida, y permitiendo reemplazar fácilmente los componentes más viejos con otros más nuevos y compatibles. 2

3 Cada componente debe tener un nombre que lo distinga de los demás. Al igual que las clases los componentes pueden enriquecerse con compartimentos adicionales que muestran sus detalles. La representación extendida: Expresión.dll Calcula expresión lógica Calcula expresión aritmética 3

4 agentefraudes.dll agente.java Realiza AgenteFraudes PoliticaFraudes BuscarPatrones system::dialog.dll {version = 2.0.1} 4

5 Parecidos y diferencias con las clases Parecidos: ambos tienen nombres, pueden realizar interfaces, participan en relacionamientos, pueden anidarse, tener instancias, participar en interacciones; Diferencias: Las clases representan abstracciones lógicas y los componentes representan elementos físicos. Las clases tienen atributos y operaciones, mientras los componentes sólo tienen operaciones 5

6 Interfaces Tanto los servicios propio de una clase como los de un componente, se especifican a través de una Interfaz. Por ejemplo, todas las facilidades más conocidas de los sistemas operativos, basados en componentes (COM+, CORBA y los Enterprise Java Beans), utilizan las interfaces como lazo de unión entre unos componentes y otros. 6

7 La relación entre un componente y sus interfaces se puede representar de dos maneras diferentes, de forma icónica y expandida: Imagen.java Componente.java ObservadorDeImagen 7

8 Tipos de componentes De despliegue: componentes necesarios y suficientes para formar un sistema ejecutable, como pueden ser las bibliotecas dinámicas (DLLs) y ejecutables (EXEs). Componentes producto del trabajo: son básicamente productos que quedan al final del proceso de desarrollo. Consisten en cosas como archivos de código fuente y de datos a partir de los cuales se crean los componentes de 8 despliegue.

9 Componentes de ejecución: son componentes que se crean como consecuencia de un sistema en ejecución. Es el caso de un objeto COM+ que se instancia a partir de una DLL. 9

10 Organización de componentes Los componentes se pueden agrupar en paquetes de la misma forma que se organizan las clases. Además se pueden especificar entre ellos relaciones de dependencia, generalización, asociación (incluyendo agregación), y realización. 10

11 Estereotipos de componentes Executable: Componente que se puede ejecutar en un nodo; Library: Especifica una biblioteca de objetos estática o dinámica; Table: Componentes que representa una tabla de una base de datos; File: Componente que representa un documento que contiene código fuente o datos; Document: Componente que representa un documento. 11

12 Diagramas de componentes Un diagrama de componentes muestra la organización y las dependencias entre un conjunto de componentes. Para todo sistema OO se han de construir una serie de diagramas que modelan tanto la parte estática (diagrama de clases), como dinámica (diagramas de secuencia, colaboración, estados y actividades). 12

13 Pero llegado el momento todo esto se debe materializar en un sistema implementado que utilizará partes ya implementadas de otros sistemas, todo esto es lo que pretendemos modelar con los diagramas de componentes. 13

14 Algunos conceptos Muestra un conjunto de componentes y sus relaciones de manera gráfica a través del uso de nodos y arcos. Estos diagramas contienen: Componentes; Interfaces; Relaciones de dependencia, generalización, asociaciones y realización; Paquetes o subsistemas; Instancias de algunas clases. 14

15 Usos más comunes Los diagramas de componentes se utilizan para modelar la vista de implementación estática de un sistema. Esta vista se ocupa principalmente de la gestión de configuraciones de las partes de un sistema, formada por componentes que pueden ensamblarse de varias formas para producir un sistema ejecutable. 15

16 Cuando se modela la vista de implementación estática de un sistema, normalmente se utilizarán los diagramas de componentes de una de las 4 maneras siguientes: Código fuente; Versiones ejecutables; Bases de datos físicas; Sistemas adaptables. 16

17 Modelado de código fuente Los diagramas de componentes se pueden utilizar para modelar la gestión de la configuración de los archivos de código fuente, tomando como productos de trabajo precisamente estos ficheros. Esto resulta bastante útil por ejemplo cuando se han implementado unas partes con Java otras con C++, etc. 17

18 El resultado de esta implementación pueden ser multitud de ficheros ejecutables con características particulares, de manera que la mejor forma de controlarlos es estableciendo gestión de configuración. será necesario definir los estereotipos de ficheros que se quieren tener bajo control así como las relaciones entre dichos tipos de ficheros. 18

19 Para modelar el código fuente de un sistema: Hay que identificar el conjunto de archivos de código fuente de interés y modelarlos como componentes estereotipados como archivos; Si el sistema es grande es necesario utilizar los paquetes para agrupar los archivos de código fuente; Es necesario identificar la versión del componente. 19

20 Modelado de una versión ejecutable La utilización de los componentes para modelar versiones ejecutables se centra en la definición de todos los elementos que componen lo que se conoce como versión ejecutable, es decir la documentación, los ficheros que se entregan etc. 20

21 Para modelar una versión es preciso: Identificar el conjunto de componentes que se pretende modelar; Identificar el estereotipo de cada componente del conjunto seleccionado; Para cada componente de este conjunto hay que considerar las relaciones con los vecinos. Esto implica definir las interfaces importadas por ciertos componentes y las exportadas por otros. 21

22 Modelado de una base de datos física Puede ser vista como la realización concreta de un esquema, y que pertenece al mundo de los bits. Los esquemas ofrecen una API para la información persistente; el modelo de una BD física representa el almacenamiento de esa información en las tablas de una BD relacional o las páginas de una BDOO. 22

23 Para modelar una BD física: Identificar las clases del modelo que representan el esquema lógico de BD; Seleccionar una estrategia para hacer corresponder las clases con tablas. Así como la distribución física de BD; Para la correspondencia es necesario crear un diagrama de componentes que tenga componentes estereotipados como tablas; Utilizar herramientas que ayuden a 23 transformar diseño lógico en físico.

24 Modelado de sistemas adaptables Algunos sistemas son estáticos; sus componentes entran en escena, participan en la ejecución y desaparecen. Otros sistemas son más dinámicos, e implican agentes móviles o componentes que migran con el propósito de equilibrar la carga o la recuperación de fallos. 24

Documentos relacionados

Diagramas De Casos De Uso

Estáticos Diagramas De Casos De Uso Los diagramas de casos de uso documentan el comportamiento de un sistema desde el punto de vista del usuario.. Por lo tanto los casos de uso determinan los requisitos