UML parte 1

UML UNIFIED MODELING LANGUAJE – LENGUAJE UNIFICADO DE MODELADO I.

INTRODUCCIÓN

UML (Unified Modeling Language) es un lenguaje que permite modelar, construir y documentar los elementos que forman un sistema software orientado a objetos. Se ha convertido en el estándar de facto de la industria, debido a que ha sido impulsado por los autores de los tres métodos más usados de orientación a objetos: Grady Booch, Ivar Jacobson y Jim Rumbaugh.

Estos autores fueron contratados por la empresa Rational Software Co. para crear una notación unificada en la que basar la construcción de sus herramientas CASE. En el proceso de creación de UML han participado, no obstante, otras empresas de gran peso en la industria como Microsoft, Hewlett-Packard, Oracle o IBM, así como grupos de analistas y desarrolladores.

Esta notación ha sido ampliamente aceptada debido al prestigio de sus creadores y debido a que incorpora las principales ventajas de cada uno de los métodos particulares en los que se basa (principalmente Booch, OMT y OOSE). UML ha puesto fin a las llamadas “guerras de métodos” que se han mantenido a lo largo de los 90, en las que los principales métodos sacaban nuevas versiones que incorporaban las técnicas de los demás. Con UML se fusiona la notación de estas técnicas para formar una herramienta compartida entre todos los ingenieros software que trabajan en el desarrollo orientado a objetos.

Uno de los objetivos principales de la creación de UML era posibilitar el intercambio de modelos entre las distintas herramientas CASE orientadas a objetos del mercado. Para ello era necesario

definir una notación y semántica común. En la Figura 2 se puede ver cuál ha sido la evolución de UML hasta la creación de UML 1.3, en el que se basa este documento. Hay que tener en cuenta que el estándar UML no define un proceso de desarrollo específico, tan solo se trata de una notación. En este curso se sigue el método propuesto por Craig Larman [Larman99] que se ajusta a un ciclo de vida iterativo e incremental dirigido por casos de uso.

En la parte II de este texto se expone la notación y semántica básica de UML, en la parte III se presentan conceptos avanzados de la notación UML, mientras que en la parte IV se presenta el método de desarrollo orientado a objetos de Larman, que se sirve de los modelos de UML que se han visto anteriormente.

II.

NOTACIÓN BÁSICA UML

II.1. MODELOS Un modelo representa a un sistema software desde una perspectiva específica. Al igual que la planta y el alzado de una figura en dibujo técnico nos muestran la misma figura vista desde distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema.

Los modelos de UML que se tratan en esta parte son los siguientes: • Diagrama de Estructura Estática.

• Diagrama de Casos de Uso. • Diagrama de Secuencia.

• Diagrama de Colaboración.

• Diagrama de Estados.

II.2. ELEMENTOS COMUNES A TODOS LOS DIAGRAMAS II.2.1 Notas Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama. Es un modo de indicar información en un formato libre, cuando la notación del diagrama en cuestión no nos permite expresar dicha información de manera adecuada. Una nota se representa como un rectángulo con una esquina doblada con texto en su interior. Puede aparecer en un diagrama tanto sola como unida a un elemento por medio de una línea discontinua. Puede contener restricciones, comentarios, el cuerpo de un procedimiento, etc.

II.2.2 Dependencias La relación de dependencia entre dos elementos de un diagrama significa que un cambio en el elemento destino puede implicar un cambio en el elemento origen (por tanto, si cambia el elemento destino habría que revisar el elemento origen). Una dependencia se representa por medio de una línea de trazo discontinuo entre los dos elementos con una flecha en su extremo.

El elemento dependiente es el origen de la flecha y el elemento del que depende es el destino (junto a él está la flecha).

II.3. DIAGRAMAS DE ESTRUCTURA ESTÁTICA Los Diagramas de Estructura Estática de UML se van a utilizar para representar tanto Modelos Conceptuales (ver sección IV.3.2) como Diagramas de Clases de Diseño (ver sección IV.4.4).

Ambos usos son distintos conceptualmente, mientras los primeros modelan elementos del dominio los segundos presentan los elementos de la solución software. Ambos tipos de diagramas comparten una parte de la notación para los elementos que los forman (clases y objetos) y las relaciones que existen entre los mismos (asociaciones). Sin embargo, hay otros elementos de notación que serán exclusivos de uno u otro tipo de diagrama.

II.3.1 Clases Una clase se representa mediante una caja subdividida en tres el nombre de la clase, en la media los atributos y en la inferior representarse de forma esquemática, con los atributos y entonces tan solo un rectángulo con el nombre de la clase.

partes: En la superior se muestra las operaciones. Una clase puede operaciones suprimidos, siendo En la Figura 5 se ve cómo una

misma clase puede representarse a distinto nivel de detalle según interese, y según la fase en la que se esté.

II.3.2 Objetos Un objeto se representa de la misma forma que una clase. En el compartimento superior aparecen el nombre del objeto junto con el nombre de la clase subrayados, según la siguiente sintaxis: nombre_del_objeto: nombre_de_la_clase Puede representarse un objeto sin un nombre específico, entonces sólo aparece el nombre de la clase.

II.3.3 Asociaciones Las asociaciones entre dos clases se representan mediante una línea que las une. La línea puede tener una serie de elementos gráficos que expresan características particulares de la asociación. A continuación se verán los más importantes de entre dichos elementos gráficos.

II.3.3.1 Nombre de la Asociación y Dirección El nombre de la asociación es opcional y se muestra como un texto que está próximo a la línea.

Se puede añadir un pequeño triángulo negro sólido que indique la dirección en la cual leer el nombre de la asociación. En el ejemplo de la Figura 7 se puede leer la asociación como “Director manda sobre Empleado”.

Los nombres de las asociaciones normalmente se incluyen en los modelos para aumentar la legibilidad. Sin embargo, en ocasiones pueden hacer demasiado abundante la información que se presenta, con el consiguiente riesgo de saturación. En ese caso se puede suprimir el nombre de las asociaciones consideradas como suficientemente conocidas. En las asociaciones de tipo agregación y de herencia no se suele poner el nombre.

II.3.3.2 Multiplicidad

La multiplicidad es una restricción que se pone a una asociación, que limita el número de instancias de una clase que pueden tener esa asociación con una instancia de la otra clase.

Puede expresarse de las siguientes formas: • Con un número fijo: 1.

• Con un intervalo de valores: 2..5.

• Con un rango en el cual uno de los extremos es un asterisco. Significa que es un intervalo abierto. Por ejemplo, 2..* significa 2 o más.

• Con una combinación de elementos como los anteriores separados por comas: 1, 3..5, 7, 15..*.

• Con un asterisco: * . En este caso indica que puede tomar cualquier valor (cero o más).

II.3.3.3 Roles Para indicar el papel que juega una clase en una asociación se puede especificar un nombre de rol.

Se representa en el extremo de la asociación junto a la clase que desempeña dicho rol.

II.3.3.4 Agregación El símbolo de agregación es un diamante colocado en el extremo en el que está la clase que representa el “todo”.

II.3.3.5 Clases Asociación Cuando una asociación tiene propiedades propias se representa como una clase unida a la línea de la asociación por medio de una línea a trazos. Tanto la línea como el rectángulo de clase representan el mismo elemento conceptual: la asociación. Por tanto ambos tienen el mismo nombre, el de la asociación. Cuando la clase asociación sólo tiene atributos el nombre suele ponerse sobre la línea (como ocurre en el ejemplo de la Figura 11). Por el contrario, cuando la clase asociación tiene alguna operación o asociación propia, entonces se pone el nombre en la clase asociación y se puede quitar de la línea.

II.3.3.6 Asociaciones N-Arias En el caso de una asociación en la que participan más de dos clases, las clases se unen con una línea a un diamante central. Si se muestra multiplicidad en un rol, representa el número potencial de tuplas de instancias en la asociación cuando el resto de los N-1 valores están fijos.

En la Figura 12 se ha impuesto la restricción de que un jugador no puede jugar en dos equipos distintos a lo largo de una temporada, porque la multiplicidad de “Equipo” es 1 en la asociación ternaria.

II.3.3.7 Navegabilidad En un extremo de una asociación se puede indicar la navegabilidad mediante una flecha.

Significa que es posible "navegar" desde el objeto de la clase origen hasta el objeto de la clase destino. Se trata de un concepto de diseño, que indica que un objeto de la clase origen conoce al (los) objeto(s) de la clase destino, y por tanto puede llamar a alguna de sus operaciones.

II.3.4 Herencia La relación de herencia se representa mediante un triángulo en el extremo de la relación que corresponde a la clase más general o clase “padre”.

Si se tiene una relación de herencia con varias clases subordinadas, pero en un diagrama concreto no se quieren poner todas, esto se representa mediante puntos suspensivos. En el ejemplo de la Figura 13, sólo aparecen en el diagrama 3 tipos de departamentos, pero con los puntos suspensivos se indica que en el modelo completo (el formado por todos los diagramas) la clase “Departamento” tiene subclases adicionales, como podrían ser “Recursos Humanos” y “Producción”.

II.3.5 Elementos Derivados

Un elemento derivado es aquel cuyo valor se puede calcular a partir de otros elementos presentes en el modelo, pero que se incluye en el modelo por motivos de claridad o como

decisión de diseño. Se representa con una barra “/” precediendo al nombre del elemento derivado.

II.4. DIAGRAMA DE CASOS DE USO Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea. En la Figura 15 se muestra un ejemplo de Diagrama de Casos de Uso para un cajero automático.

II.4.1 Elementos Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso.

II.4.1.1 Actores Un actor es algo con comportamiento, como una persona (identificada por un rol), un sistema informatizado u organización, y que realiza algún tipo de interacción con el sistema.. Se

representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores.

II.4.1.2 Casos de Uso Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica.

Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema.

II.4.1.3 Relaciones entre Casos de Uso Un caso de uso, en principio, debería describir una tarea que tiene un sentido completo para el usuario. Sin embargo, hay ocasiones en las que es útil describir una interacción con un alcance menor como caso de uso. La razón para utilizar estos casos de uso no completos en algunos casos, es mejorar la comunicación en el equipo de desarrollo, el manejo de la documentación de casos de uso. Para el caso de que queramos utilizar estos casos de uso más pequeños, las relaciones entre estos y los casos de uso ordinarios pueden ser de los siguientes tres tipos: • Incluye (<>): Un caso de uso base incorpora explícitamente a otro caso de uso en un lugar especificado en dicho caso base. Se suele utilizar para encapsular un comportamiento parcial común a varios casos de uso. En la Figura 16 se muestra cómo el caso de uso Realizar Reintegro puede incluir el comportamiento del caso de uso Autorización.

Figura 16 - Ejemplo de Relación <> • Extiende (<>): Cuando un caso de uso base tiene ciertos puntos (puntos de extensión) en los cuales, dependiendo de ciertos criterios, se va a realizar una interacción adicional. El caso de uso que extiende describe un comportamiento opcional del sistema (a diferencia de la relación incluye que se da siempre que se realiza la interacción descrita) En la Figura 17 se muestra como el caso de uso Comprar Producto permite explicitamente extensiones en el siguiente punto de extensión: info regalo. La interacción correspondiente a establecer los detalles sobre un producto que se envía como regalo están descritos en el caso de uso Detalles Regalo.

Figura 17 - Ejemplo de Relación <> Ambos tipos de relación se representan como una dependencia etiquetada con el estereotipo correspondiente (<> o <>), de tal forma que la flecha indique el sentido en el que debe leerse la etiqueta. Junto a la etiqueta <> se puede detallar el/los puntos de extensión del caso de uso base en los que se aplica la extensión. • Generalización ( ): Cuando un caso de uso definido de forma abstracta se particulariza por medio de otro caso de uso más específico. Se representa por una línea continua entre los dos casos de uso, con el triángulo que simboliza generalización en UML (usado también para denotar la herencia entre clases) pegado al extremo del caso de uso más general. Al igual que en la herencia entre clases, el caso de uso hijo hereda las asociaciones y características del caso de uso padre. El caso de uso padre se trata de un caso de uso abstracto, que no está definido completamente. Este tipo de relación se utiliza mucho menos que las dos anteriores.

II.5. DIAGRAMAS DE INTERACCIÓN En los diagramas de interacción se muestra un patrón de interacción entre objetos. Hay dos tipos de diagrama de interacción, ambos basados en la misma información, pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas de Colaboración.

II.5.1 Diagrama de Secuencia Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interacción y los mensajes que intercambian ordenados según su secuencia en el tiempo. El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes en la interacción, sin un orden prefijado. Cada objeto o actor tiene una línea vertical, y los mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren.

Figura 18 Diagrama de Secuencia II.5.2 Diagrama de Colaboración Un Diagrama de Colaboración muestra una interacción organizada basándose en los objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se refiere). A diferencia de los Diagramas de Secuencia, los Diagramas de Colaboración muestran las relaciones entre los roles de los objetos. La secuencia de los mensajes y los flujos de ejecución concurrentes deben determinarse explícitamente mediante números de secuencia.

En cuanto a la representación, un Diagrama de Colaboración muestra a una serie de objetos con los enlaces entre los mismos, y con los mensajes que se intercambian dichos objetos. Los mensajes son flechas que van junto al enlace por el que “circulan”, y con el nombre del mensaje y los parámetros (si los tiene) entre paréntesis. Cada mensaje lleva un número de secuencia que denota cuál es el mensaje que le precede, excepto el mensaje que inicia el diagrama, que no lleva número de secuencia. Se pueden indicar alternativas con condiciones entre corchetes (por ejemplo 3 [condición_de_test] : nombre_de_método() ), tal y como aparece en el ejemplo de la Figura 19. También se puede mostrar el anidamiento de mensajes con números de secuencia como 2.1, que significa que el mensaje con número de secuencia 2 no acaba de ejecutarse hasta que no se han ejecutado todos los 2. x.

II.6. DIAGRAMAS DE ESTADO Un Diagrama de Estados muestra la secuencia de estados por los que pasa bien un caso de uso, bien un objeto a lo largo de su vida, o bien todo el sistema. En él se indican qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que genera.

En cuanto a la representación, un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos.

Un estado se representa como una caja redondeada con el nombre del estado en su interior.

Una transición se representa como una flecha desde el estado origen al estado destino.

La caja de un estado puede tener 1 o 2 compartimentos. En el primer compartimento aparece el nombre del estado. El segundo compartimento es opcional, y en él pueden aparecer acciones de entrada, de salida y acciones internas.

Una acción de entrada aparece en la forma entrada/acción_asociada donde acción_asociada es el nombre de la acción que se realiza al entrar en ese estado. Cada vez que se entra al estado por medio de una transición la acción de entrada se ejecuta.

Una acción de salida aparece en la forma salida/acción_asociada. Cada vez que se sale del estado por una transición de salida la acción de salida se ejecuta.

Una acción interna es una acción que se ejecuta cuando se recibe un determinado evento en ese estado, pero que no causa una transición a otro estado. Se indica en la forma nombre_de_evento/acción_asociada.

Un diagrama de estados puede representar ciclos continuos o bien una vida finita, en la que hay un estado inicial de creación y un estado final de destrucción (finalización del caso de uso o destrucción del objeto). El estado inicial se muestra como un círculo sólido y el estado final como un círculo sólido rodeado de otro círculo. En realidad, los estados inicial y final son pseudoestados, pues un objeto no puede “estar” en esos estados, pero nos sirven para saber cuáles son las transiciones inicial y final(es).

III.

NOTACION AVANZADA UML

III.1. MODELADO DINÁMICO III.1.1 Diagramas De Actividades Vamos a recordar los diferentes modelos que sirven para representar el aspecto dinámico de un sistema: • Diagramas de secuencia • Diagramas de colaboración • Diagramas de estados • Diagramas de casos de uso • Diagramas de actividades En este capítulo nos centraremos en los diagramas de actividades que sirven fundamentalmente para modelar el flujo de control entre actividades. La idea es generar una especie de diagrama Pert, en el que se puede ver el flujo de actividades que tienen lugar a lo largo del tiempo, así como las tareas concurrentes que pueden realizarse a la vez. El diagrama de actividades sirve para representar el sistema desde otra perspectiva, y de este modo complementa a los anteriores diagramas vistos. Gráficamente un diagrama de actividades será un conjunto de arcos y nodos. Desde un punto de vista conceptual, el diagrama de actividades muestra cómo

fluye el control de unas clases a otras con la finalidad de culminar con un flujo de control total que se corresponde con la consecución de un proceso más complejo. Por este motivo, en un diagrama de actividades aparecerán acciones y actividades correspondientes a distintas clases.

Colaborando todas ellas para conseguir un mismo fin. Ejemplo: Hacer un pedido.

III.1.2 Contenido del diagrama de actividades Básicamente un diagrama de actividades contiene: • Estados de actividad • Estados de acción • Transiciones • Objetos III.1.2.1 Estados de actividad y estados de acción La representación de ambos es un rectángulo con las puntas redondeadas, en cuyo interior se representa bien una actividad o bien una acción. La forma de expresar tanto una actividad como una acción, no queda impuesta por UML, se podría utilizar lenguaje natural, una especificación formal de expresiones, un metalenguaje, etc. La idea central es la siguiente: “Un estado que represente una acción es atómico, lo que significa que su ejecución se puede considerar instantánea y no puede ser interrumpida” En la Figura 21, podemos ver ejemplos de estados de acción.

Figura 21 Estados de Acción En cambio un estado de actividad, sí puede descomponerse en más sub-actividades representadas a través de otros diagramas de actividades. Además estos estados sí pueden ser interrumpidos y tardan un cierto tiempo en completarse. En los estados de actividad podemos encontrar otros elementos adicionales como son: acciones de entrada (entry) y de salida (exit) del estado en cuestión, así como definición de submáquinas, como podemos ver en la Figura.

Figura 22 Estado de Actividad

III.1.2.2 Transiciones Las transiciones reflejan el paso de un estado a otro, bien sea de actividad o de acción. Esta transición se produce como resultado de la finalización del estado del que parte el arco dirigido que marca la transición. Como todo flujo de control debe empezar y terminar en algún momento, podemos indicar esto utilizando dos disparadores de inicio y fin tal y como queda reflejado en el ejemplo de la Figura 23.

Figura 23 Transiciones sin disparadores

III.1.2.3 Bifurcaciones Un flujo de control no tiene porqué ser siempre secuencial, puede presentar caminos alternativos. Para poder representar dichos caminos alternativos o bifurcación se utilizará como símbolo el rombo. Dicha bifurcación tendrá una transición de entrada y dos o más de salida. En cada transición de salida se colocará una expresión booleana que será evaluada una vez al llegar a la bifurcación, las guardas de la bifurcación han de ser excluyentes y contemplar todos los casos ya que de otro modo la ejecución del flujo de control quedaría interrumpida. Para poder cubrir todas las posibilidades se puede utilizar la palabra ELSE, para indicar una transición obligada a un determinado estado cuando el resto de guardas han fallado. En la Figura 24 podemos ver un ejemplo de bifurcación.

Figura 24 Bifurcación

III.1.2.4 División y unión No sólo existe el flujo secuencial y la bifurcación, también hay algunos casos en los que se requieren tareas concurrentes.

UML representa gráficamente el proceso de división, que representa la concurrencia, y el momento de la unión de nuevo al flujo de control secuencial, por una línea horizontal ancha. En la Figura 25 podemos ver cómo se representa gráficamente.

Figura 25 División y unión

III.1.2.5 Calles Cuando se modelan flujos de trabajo de organizaciones, es especialmente útil dividir los estados de actividades en grupos, cada grupo tiene un nombre concreto y se denominan calles.

Cada calle representa a la parte de la organización responsable de las actividades que aparecen en esa calle. Gráficamente quedaría como se muestra en la Figura 26.

Figura 26 Calles

III.2. MODELADO FÍSICO DE UN SISTEMA OO III.2.1 Componentes Los 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 de un componente 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.”

En UML todos los elementos físicos se modelan como componentes. UML proporciona una representación gráfica para estos como se puede ver en la Figura 27, en la que XXXX.dll, es el nombre del componente.

Figura 27 Representación de un componente 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, como se puede ver en la Figura 28.

Figura 28 Representación extendida de un componente Vamos a ver con más detalle cuáles son los parecidos y las diferencias entre los componentes y las clases.

PARECIDOS Ambos tienen nombre Ambos pueden realizar un conjunto de interfaces.

Pueden participar en relaciones de dependencia, generalización y asociación.

Ambos pueden anidarse Ambos pueden tener instancias Ambos pueden participar en interacciones DIFERENCIAS Las Clases Los Componentes Representan abstracciones lógicas Representan elementos físicos Es decir los componentes pueden estar en nodos y las clases no Pueden tener atributos y operacionesdirectamente accesibles. Sólo tienen operaciones y estas son alcanzables a través de la interfaz del componente.

III.2.1.1 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, etc.), utilizan las interfaces como lazo de unión entre unos componentes y otros. La relación entre un componente y sus interfaces se puede representar de dos maneras diferentes, de forma icónica como se indica en la Figura 29, y de forma expandida como se muestra en la Figura 30.

Figura 29 Componentes e interfaces, formato icónico

Figura 30 Componentes e interfaces, formato extendido III.2.1.2 Tipos de componentes Existen básicamente tres tipos de componentes: - 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: estos componentes 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 despliegue.

- 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.

III.2.1.3 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.

III.2.1.4 Estereotipos de componentes UML define cinco estereotipos estándar que se aplican a los componentes: executable Componente que se puede ejecutar en un nodo. library 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.

UML no especifica iconos predefinidos para estos estereotipos.

III.2.2 Despliegue III.2.2.1 Nodos Al igual que los componentes los nodos pertenecen al mundo material.

Vamos a definir un nodo como un elemento físico, que existe en tiempo de ejecución y representa un recurso computacional que generalmente tiene alguna memoria y capacidad de procesamiento. Los nodos sirven para modelar la topología del hardware sobre el que se ejecuta el sistema.

Un nodo representa normalmente un procesador o un dispositivo sobre el que se pueden desplegar los componentes. Un nodo debe tener un nombre asignado que lo distinga del resto de nodos. Además los nodos se representan gráficamente como se indica en la Figura 31.

Figura 31 Nodos

III.2.2.2 Nodos y componentes En muchos aspectos los nodos y los componentes tienen características parecidas. Vamos a ver con más detalle cuales son los parecidos y las diferencias entre los componentes y los nodos.

PARECIDOS Ambos tienen nombre Pueden participar en relaciones de dependencia, generalización y asociación.

Ambos pueden anidarse Ambos pueden tener instancias Ambos pueden participar en interacciones DIFERENCIAS Los Nodos Los Componentes Son los elementos donde se ejecutan los componentes. Son los elementos que participan en la ejecución de un sistema.

Representan el despliegue físico de los componentes. Representan el empaquetamiento físico de los elementos lógicos.

La relación entre un nodo y los componentes que despliega se pueden representar mediante una relación de dependencia como se indica en la Figura 32.

Los nodos se pueden agrupar en paquetes igual que los las clases y los componentes.

Los tipos de relación más común entre nodos es la asociación. Una asociación entre nodos viene a representar una conexión física entre nodos como se puede ver en la Figura 33.

Figura 32 Relación entre nodos y componentes

Figura 33 Conexiones entre nodos Existen dos tipos de diagramas que sirven para modelar los aspectos físicos de un sistema orientado a objetos: • Diagramas de Componentes • Diagramas de Despliegue Seguidamente veremos para qué sirve cada uno de ellos y cual es su representación gráfica.

III.2.3 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 de actividades), 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.

III.2.3.1 Algunos conceptos Un diagrama de componentes muestra un conjunto de componentes y sus relaciones de manera gráfica a través del uso de nodos y arcos entre estos. Normalmente los diagramas de componentes contienen: • Componentes • Interfaces • Relaciones de dependencia, generalización, asociaciones y realización.

• Paquetes o subsistemas • Instancias de algunas clases Visto de otro modo un diagrama de componentes puede ser un tipo especial de diagrama de clases que se centra en los componentes físicos del sistema.

III.2.3.2 Usos más comunes a) 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. 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.

Para poder llevar a cabo esta gestión con éxito será necesario definir los estereotipos de ficheros que se quieren tener bajo control así como las relaciones entre dichos tipos de ficheros.

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 muy grande es necesario utilizar los paquetes para agrupar los archivos de código fuente.

• Es necesario identificar la versión del componente. b) Modelado de una versión ejecutable y bibliotecas.

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.

Para modelar una versión ejecutable 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. c) Modelado de una base de datos física.

Para modelar una base de datos física es necesario: • Identificar las clases del modelo que representan el esquema lógico de la base de datos.

• Seleccionar una estrategia para hacer corresponder las clases con tablas. Así como la distribución física de la/s base/s de datos.

• Para poder visualizar, especificar, construir y documentar dicha correspondencia es necesario crear un diagrama de componentes que tenga componentes estereotipados como tablas.

• Donde sea posible es aconsejable utilizar herramientas que ayuden a transformar diseño lógico en físico.

III.2.4 Diagramas de Despliegue III.2.4.1 Técnicas más comunes de modelado a) Modelado de un sistema empotrado El desarrollo de un sistema empotrado es más que el desarrollo de un sistema software. Hay que manejar el mundo físico. Los diagramas de despliegue son útiles para facilitar la comunicación entre los ingenieros de hardware y los de software. Para modelar un sistema empotrado es necesario: • Identificar los dispositivos y nodos propios del sistema.

• Proporcionar señales visuales, sobre todo para los dispositivos poco usuales.

• Modelar las relaciones entre esos procesadores y dispositivos en un diagrama de despliegue.

• Si es necesario hay que detallar cualquier dispositivo inteligente, modelando su estructura en un diagrama de despliegue más pormenorizado. b) Modelado de un sistema cliente servidor La división entre cliente y servidor en un sistema es complicada ya que implica tomar algunas decisiones sobre dónde colocar físicamente sus componentes software, qué cantidad de software debe residir en el cliente, etc. Para modelar un sistema cliente/servidor hay que hace lo siguiente: • Identificar los nodos que representan los procesadores cliente y servidor del sistema.

• Destacar los dispositivos relacionados con el comportamiento del sistema.

• Proporcionar señales visuales para esos procesadores y dispositivos a través de estereotipos.

• Modelar la tipología de esos nodos mediante un diagrama de despliegue.

III.2.5 Arquitectura del Sistema

III.2.5.1 Arquitectura de tres niveles La llamada “Arquitectura en Tres Niveles”, es la más común en sistemas de información que además de tener una interfaz de usuario contemplan la persistencia de los datos. Una descripción de los tres niveles sería la siguiente: Nivel 1: Presentación – ventanas, informes, etc.

Nivel 2: Lógica de la Aplicación – tareas y reglas que gobiernan el proceso.

Nivel 3: Almacenamiento – mecanismo de almacenamiento.

III.2.5.2 Arquitectura de tres niveles orientadas a objetos a) Descomposición del nivel de lógica de la aplicación En el diseño orientado a objetos, el nivel de lógica de la aplicación se descompone en subniveles que son los siguientes: Objetos del Dominio: son clases que representan objetos del dominio. Por ejemplo en un problema de ventas, una “Venta” sería un objeto del dominio.

Servicios: se hace referencia a funciones de interacción con la base de datos, informes, comunicaciones, seguridad, etc.

III.2.5.3 Arquitectura MULTI-nivel La arquitectura de tres niveles puede pasar a llamarse de Múltiples Niveles si tenemos en cuenta el hecho de que todos los niveles de la arquitectura de tres niveles se pueden descomponer cada uno de ellos cada vez más. Por ejemplo el nivel de Servicios, se puede descomponer en servicios de alto y de bajo nivel, identificando como de alto nivel los servicios de generación de informes y como de bajo nivel los de manejo de ficheros de entrada y salida.

El motivo que lleva a descomponer la arquitectura del sistema en diferentes niveles es múltiple: • Separación de la lógica de la aplicación en componentes separados que sean más fácilmente reutilizables.

• Distribución de niveles en diferentes nodos físicos de computación.

• Reparto de recursos humanos en diferentes niveles de la arquitectura.

III.2.5.4 Paquetes La forma que tiene UML de agrupar elementos en subsistemas es a través del uso de Paquetes, pudiéndose anidar los paquetes formando jerarquías de paquetes. De hecho un sistema que no tenga necesidad de ser descompuesto en subsistemas se puede considerar como con un único paquete que lo abarca todo.

Gráficamente un paquete viene representado como se indica en la Figura 34.

Figura 34 Representación de un paquete en UML

En la Figura 35, vemos cómo se representa la arquitectura del sistema con la notación de paquetes.

Figura 35 Arquitectura de un sistema utilizando paquetes

III.2.5.5 Identificación de Paquetes Vamos a definir una serie de reglas que nos pueden ser de utilidad a la hora de agrupar los diferentes elementos en paquetes.

• Conviene agrupar elementos que proporcionen un mismo servicio.

• Los elementos que se agrupen en un mismo paquete han de presentar un alto grado de cohesión, es decir deben estar muy relacionados.

• Los elementos que estén en diferentes paquetes deben tener poca relación, es decir deben colaborar lo menos posible.