UML - 1

UML

Introducción

UML (Unified Modeling Language) es un lenguaje de modelamiento, que permite especificar, visualizar,

construir y documentar sistemas complejos. Como todo lenguaje, UML define una sintaxis, basada en

unos elementos constructores básicos, y una semática, basada en unas reglas (well-formedness rules),

que permiten construir los modelos necesario para representar un sistema. Es importante aclarar que

UML no define el proceso que debe seguirse para construir cada modelo, lo cual corresponde a la

metodología que se seleccione.

Inicialmente el lenguaje fue creado por Ivar Jacobson, Grady Booch y Jim Rumbaugh en 1995, buscando

un lenguaje unificado para modelar sistemas orientados a objetos (OO). Sin embargo, UML empezó a ser

ampliamente utilizado, y se definieron mecanismos que permitían modelar otro tipo de sistemas. En 1997,

con la versión 1.2, UML fue adoptado oficialmente por el OMG (Object Management Group), que es un

consorcio de empresas que elaboran estándares relacionados con OO. El OMG está encargado, desde

entonces, de publicar las especificaciones de cada versión, y actualmente se tiene la versión 2.0.

Existen muchas herramientas en el mercado que permiten elaborar los diagramas de UML, e incluso hay

muchas que se encuentran integradas con ambientes de desarrollo, de manera que es posible tener

“sincronizado” el código y el modelo del sistema que se realiza generalmente en las etapas de análisis y

diseño. Una lista bastante completa de estas herramientas puede encontrarse en:

http://www.objectsbydesign.com/tools/umltools_byPrice.html

Bloques básicos

UML tiene los siguientes bloques básicos, a partir de los cuales se crean los modelos:

• Elementos

• Relaciones

• Diagramas

Elementos

Los elementos pueden ser:

• Estáticos: clases, interfaces, colaboraciones, casos de uso, clases activas, componentes y

nodos.

• De comportamiento: interacciones y máquinas de estado

• De agrupación: paquetes

• De anotación: notas

A continuación se presentan brevemente los elementos más utilizados:

• Clase: Es la descripción de un conjunto de objetos que tienen características y comportamiento

comunes. Puede verse como una “plantilla” o molde que define los atributos y las operaciones

que tienen un grupo de objetos. Representación:

UML - 2

En UML se pueden tener diferentes niveles de detalle, de manera que es posible representar una clase

con un rectángulo que tenga el nombre de la misma (y nada más), o incluir todos sus elementos. Para

cada elemento también es posible darle más información. Por ejemplo, para los atributos se puede definir

el nivel de visibilidad y el tipo, y en las operaciones o métodos se puede definir el nivel de visibilidad, los

parámetros que necesita y el tipo de dato que retorna.

Ejemplo:

Es posible extender la información de una clase, adicionando otros compartimientos si son necesarios, o

mediante comentarios.

• Objeto: Es una instancia de una clase. Es decir, no define un marco general, como la clase, sino

que ya tiene una identidad y valores específicos en sus atributos. Se representa con un

rectángulo dividido en dos compartimientos:

Por ejemplo:

• Interfaz: Una interfaz es un conjunto de operaciones que definen un comportamiento, por

ejemplo, una interfaz “Comparable” define el comportamiento que debe tener todo elemento que

se pueda comparar con otro. Normalmente estas operacionen deben ser implementadas por una

clase u otro elemento. Son muy utilizadas para definir la comunicación entre procesos o entre

paquetes. Hay dos formas de representar interfaces:

• Casos de uso: Un caso de uso representa una funcionalidad o comportamiento del sistema.

Generalmente es un conjunto de acciones que el sistema lleva a cabo para ofrecer un servicio a

los usuarios de ese sistema. Representación:

UML - 3

Los nombres de los casos de uso generalmente son verbos, pues representan funciones o acciones del

sistema. Por ejemplo:

• Actor: Representa el rol que pueden tomar los usuarios del sistema o cualquier elemento externo

que interactúe con el sistema (como por ejemplo, otro sistema). Representación:

• Componente: Es uno de los elementos finales “entregables” del sistema. Generalmente se asocia

con un archivo ejecutable o con un conjunto de archivos que se pueden integrar fácilmente con

otros componentes (como las librerías). Al igual que un componente de hardware, un

componente de software es una parte modular del sistema, que internamente tiene una

implementación, pero que sólo muestra un conjunto de interfaces para integrarse con los demás

componentes. Representación:

• Nodo: Representa un recurso computacional, es decir, un elemento físico donde se ejecutan los

componentes (por ejemplo, un servidor, una base de datos, etc.) Su representación es:

• Paquete: Es un elemento de agrupación, y por lo tanto pueden contener otros elementos. Se

representa:

• Comentario:

UML - 4

Relaciones

Las relaciones básicas que define UML son:

• Asociación: Representa una relación estructural entre dos elementos. Generalmente se le puede

dar información a esta relación, como el nombre, la dirección en la cual se implementa, etc. Se

representa con una línea continua:

Hay dos tipos de asociaciones muy utilizadas: la agregación, que es una relación de un todo con

sus partes (por ejemplo, clase con los estudiantes), y la composición, que es una agregación

fuerte, donde la existencia de la partes depende del todo (por ejemplo, edificio con sus pisos).

• Dependencia: Es una relación que indica que un elemento “usa” otro elemento, pero no es una

relación estructural. Si un elemento cambia puede afectar al otro (pero no a la inversa). Se

representa con una línea discontinua que termina en flecha:

• Generalización (herencia): Indica que un elemento “hereda” todo lo de otro elemento, pero

además tiene cosas propias. El elemento “padre” es más general, y los hijos son más

específicos. Representación:

• Realización (implementación): Normalmente se presenta entre una interfaz y otro elemento,

indicando que dicho elemento implementa las operaciones que están definidas en la interfaz.

Representación:

Diagramas

En UML versión 1.5 hay definidos 9 diagramas (en la versión 2.0 se define una mayor cantidad), que

algunas veces se agrupan dependiendo de el tipo de información que contienen, así:

• Diagramas estructurales: Muestran la estructura general del sistema, clasificando los elementos

que participan, con sus relaciones, atributos y operaciones. Los diagramas estructurales de UML

son los diagramas de clase y los diagramas de objetos.

• Diagrama de casos de uso: Muestra las relaciones entre los diferentes casos de uso de un

sistema y sus actores.

• Diagramas de comportamiento: Muestran el componente dinámico del sistema, y son: diagramas

UML - 5

de estado, diagramas de actividades y diagramas de interacción.

• Diagramas de interacción: Muestran la comunicación o intercambio de mensajes entre

los objetos del sistema. Comprende los diagramas de secuencia y los diagramas de

colaboración.

• Diagramas de implementación: Muestran los aspectos de implementación del sistema,

incluyendo el código y los elementos de ejecución. Hacen parte de estos diagramas los

diagramas de componentes y los diagramas de despliegue (deployment).

Cada diagrama reúne un conjunto de elementos y relaciones entre ellos, para mostrar alguna parte del

sistema que se desea modelar. No es necesario usar todos los diagramas siempre, sólo los que se

necesiten para representar lo que se requiere. Posteriormente se mostrarán los diagramas más

utilizados, por medio de un ejemplo.

Mecanismos de extensión

Como UML se está utilizando ampliamente para modelar todo tipo de sistemas (no solo OO), es

necesario tener cierto grado de flexibilidad, para incluir elementos propios de cada sistema, con su

semántica particular. Por este motivo UML define unos mecanismos de extensión, que permiten “refinar”

la semántica de UML, sin ir en contra de los estándares básicos definidos.

Estos mecanismos de extensión son:

• Estereotipos: Un estereotipo es un elemento “nuevo”, que se crea a partir de un elemento ya

existente en UML. En realidad lo que se hace es usar un elemento ya existente, pero dándole un

nuevo significado (nueva semántica). También es posible darle una nueva forma de

representación (icono) y definirle algunas restricciones. Los estereotipos se reconocen (si no

tienen su propia representación) porque antes del nombre del elemento se indica el nombre del

estereotipo entre los símbolos: << y >>. Por ejemplo, si se desea modelar un sistema que se

ejecutará en un celular es muy común contar con “MIDlets”, que son elementos basados en

clases, pero que tienen un comportamiento previamente definido. Para esto puede crearse el

estereotipo “midlet” basado en las clases, y se representaría:

Se pueden crear estereotipos basados en cualquiera de los elementos o relaciones que define

UML.

Actualmente es posible encontrar conjuntos de estereotipos estándar para algunos tipos de

sistemas, por ejemplo, para sistemas distribuidos, sistemas de tiempo real, entre otros. Cada uno

de estos conjuntos con estereotipos se denomina “perfil” (profile) y también son definidos por el

OMG.

• Restricciones (constraint): Es un enunciado en lenguaje formal o informal que cambia la

semántica del elemento al cual se adjunta. Las restricciones se muestran entre llaves. Por

ejemplo, si se desea indicar que una clase es abstracta se escribe:

O si se desea definir una asociación ordenada se adiciona la restricción “sorted”:

UML - 6

• Valores etiquetados (tagged values): Permiten extender las propiedades de un elemento o

relación en UML. Normalmente son usados con los estereotipos, pues permiten definir alguna

característica particular. Por ejemplo, si se ha definido el estereotipo “midlet” se le puede

adicionar un valor etiquetado llamado versión, para saber si corresponde a la versión 1.0 o 2.0 de

MIDP.

Ejemplo

En este parte se usará una herramienta libre (Open Source), llamada ArgoUML, para elaborar los

diagramas. Actualmente se encuentra la versión 0.16.1, pero para el desarrollo del ejemplo se usó la

versión 0.12.

Para poder ejecutar esta herramienta es necesario tener instalada la máquina virtual de Java (se puede

bajar de java.sun.com). La instalación de ArgoUML consiste simplemente en descomprimir el archivo .zip

que se obtiene de la página argouml.tigris.org, y para ejecutar la herramienta simplemente se debe dar

doble clic en el archivo “argouml.jar”.

Enunciado:

“En una empresa de la región han decidido implementar un sistema de identificación de sus empleados,

que también les ayude a controlar la entrada a las diferentes áreas en la planta de producción. A cada

empleado le proporcionarán una tarjeta con un código de barras que tiene el nombre y el número de

identificación del empleado.

Cuando el empleado desee ingresar a un área deberá pasar su tarjeta por un lector que estará ubicado

en la puerta, y posteriormente debe escribir su clave (sólo en algunas áreas). La clave, que es personal,

es un número de 4 dígitos, pero cada persona también tiene una clave de 5 dígitos, que puede usar en

casos de emergencia, ya que al ingresarla se enciende una alarma en la oficina central de seguridad. El

lector que hay en la puerta de cada área envía la información al servidor central, donde se verifica que el

cargo del empleado le permita entrar, y que la clave, si es necesaria, sea correcta. Si esto se cumple se

envía la señal al lector para que abra la puerta. Sin importar si es posible entrar o no, en el servidor

también se guarda un registro con la fecha y la hora en la cual el empleado usó el lector de un área.

Se ha definido que es la oficina de recursos humanos la encargada de ingresar los datos básicos de cada

persona, que son nombre, teléfono, número de identificación y teléfono. Ellos también definen, para cada

cargo, además de una breve descripción, las áreas a las cuales puede ingresar. La oficina de seguridad

complementa esta información, ingresando para cada empleado sus diferentes claves, y definiendo qué

áreas necesitan clave para el ingreso.”

Inicialmente se elaborará el diagrama de casos de uso, identificando actores y funciones del sistema. Los

actores, es decir, quienes interactúan con este sistema son:

- La oficina de recursos humanos

- La oficina de seguridad

- Los empleados de la compañía

Las funciones macro de este sistema (de acuerdo con el enunciado) son:

- Ingresar información de cargos y áreas

- Ingresar información básica de un empleado

- Ingresar información de seguridad (claves) de un empleado

UML - 7

- Ingresar información de seguridad de las áreas

- Entrar a un área de la compañía

En un diagrama de casos de uso se muestra la interacción entre los actores y los casos de uso, lo cual

permite visualizar la funcionalidad general del sistema. Para detallar cada función (caso de uso) puede

utilizarse una descripción textual o usar otros diagramas. Los elementos y relaciones que pueden

incluirse en este tipo de diagramas son:

< Casos de uso

< Actores

< Límite del sistema (opcional): Delimita el sistema, y se representa como un rectángulo que

agrupa los casos de uso.

< Asociación: relación entre un actor y un casos de uso

< Extend: Estereotipo de una dependencia. Muestra que un caso de uso extiende el

comportamiento de otro, ejecutando sus acciones cuando se presentan unas condiciones dadas

< Include: Estereotipo de una dependencia. Muestra que un caso de uso siempre incluye a otro.

En ArgoUML, para elaborar este diagrama simplemente se hace clic en el nombre del diagrama en el

lado izquierdo (use case diagram 1), o se puede crear uno nuevo con la opción del menú “Crear

diagrama - Diagrama de casos”. Al seleccionar este diagrama se muestran los elementos básicos en la

paleta (actor, caso de uso, asociación, dependencia, generalización, extend e include):

Utilizando estos botones se adicionan los elementos en el área de dibujo:

Es importante anotar que para cada elemento que se adicione es posible ingresar información adicional,

utilizando el área de propiedades que tiene la herramienta.

Luego se adicionan las relaciones que hay entre los actores y los casos de uso, que son asociaciones Por

ejemplo, la oficina de recursos humanos interactúa con “Ingresar datos básicos empleado” e “Ingresar

datos cargos”, así:

UML - 8

En ocasiones algunas funciones se dividen, para mostrar actividades que son comunes a varios casos de

uso, o para dar mayor claridad al diagrama. Por ejemplo, es posible mostrar que cada vez que una

persona intenta ingresar a un área hay una comunicación con el servidor, así:

Es una relación “include”

También se puede mostrar que - a veces - hay un conjunto de actividades que extiende un caso de uso.

Por ejemplo, si el empleado usa la clave adicional, además de realizar la funcionalidad habitual, se debe

encender una alarma:

Es una relación “extend”

En esta oportunidad en el caso de uso “Entrar a un área” se hace visible una nueva sección llamada

“punto de extensión”, que permite mostrar cuándo se ejecutan las acciones del otro use case.

Para guardar el trabajo realizado hasta el momento se selecciona la opción del menú Archivo - Guardar

proyecto como, y se indica la ubicación y el nombre que se desea dar (también es posible guardar los

diagramas como archivos .gif, con la opción “Archivo - Guardar gráficos”).

A continuación se construirá el diagrama de clases (es de anotar que este orden es sólo para efectos del

ejemplo, ya que en realidad esto depende de la metodología).

En un diagrama de clases se muestra toda la parte “lógica” del sistema, ya que incluye la información y

las operaciones necesarias para realizar lo que se requiere. Generalmente se tienen tres tipos de clases:

las que guardan la información básica, llamadas clases de entidad, las que tienen la lógica general y

coordinan las acciones, llamadas clases de control, y las que tienen que ver con la presentación final al

usuario, llamadas clases de interfaz.

En ArgoUML se puede crear un nuevo diagrama de clases (opción Crear diagrama - diagrama de clase)

o se puede usar el que la herramienta crea al comienzo (class diagram 1). Al seleccionar el diagrama se

muestra la nueva paleta de herramientas:

En esta paleta se resumen los elementos y relaciones que pueden incluirse en un diagrama de clases,

que son:

< Paquetes

< Clases

< Asociación: relaciones entre clases

< Dependencia: relaciones entre clases, paquetes y/o interfaces

< Generalización: relación entre una clase padre y una clase hija (especialización)

< Interfaces

< Realización: relación entre una clase y una interfaz

UML - 9

Inicialmente se pueden crear las clases que representan la información básica, junto con sus atributos:

También se pueden adicionar las relaciones entre clases, (asociaciones), y las nuevas clases que se

originan de estas relaciones. Por ejemplo, entre Empleado y Cargo hay una relación bidireccional: un

Empleado tiene un Cargo, y un Cargo puede tener asociados varios Empleados. También hay una

relación entre Cargo y Área y entre Empleado y Área. Esta última relación se complementa creando una

nueva clase, que tendrá el registro de todas las veces que un Empleado ha intentado entrar en un Área.

Cuando se desea dar información adicional a una relación se debe usar el área de propiedades de

ArgoUML. El diagrama con las relaciones y la nueva clase, queda:

A medida que se llevan a cabo las diferentes actividades de análisis, diseño e implementación del

sistema, se definen nuevas clases que complementan el modelo. Por ejemplo, se puede tener una clase

que tenga la información de cada lector (que da acceso a un área), y que también se encargue de la

comunicación con el servidor. Igualmente se puede tener una clase que controle todo el sistema, tanto

para recibir los datos de los lectores, como para gestionar la información de los empleados, los cargos y

las áreas. También se define que las áreas que necesitan clave para entrar son muy diferentes de las

que no necesitan claves, y por lo tanto se tendrán una clase que hereda de Área, llamada

ÁreaRestringida. En este último caso ya no es necesario tener el atributo “tieneClave”, pues se sabe que

las Áreas normales no la tienen, y las ÁreasRestringidas sí.

En la práctica generalmente se tienen muchas más clases de control, y algunas de entidad se omiten,

pues la información se conserva en una base de datos.

El diagrama, con los cambios mencionados, queda:

UML - 10

Los diagramas de interacción (diagramas de secuencia y de colaboración) permiten ver cómo los objetos

interactúan entre sí para poder prestar la funcionalidad deseada. Generalmente se muestra el actor

iniciando una petición, y luego se muestra cómo los objetos se envían mensajes para dar la respuesta.

En los diagramas de interacción los elementos y relaciones involucrados son:

< Objetos

< Enlaces: Al igual que los objetos son instancias de las clases, los enlaces son instancias de las

relaciones, y se utilizan en los diagramas de colaboración para mostrar que un objeto tiene una

referencia a otro objeto.

< Estímulo o mensaje: puede ser de varios tipos: sincrónico (la flecha final es rellena), asíncrono (la

flecha final es abierta) o de respuesta (como una dependencia).

< Operación: generalmente está asociada a un mensaje.

Antes de elaborar el diagrama se definirán las acciones que tienen que realizarse para el caso de uso

“Entrar a un área”, las cuales escribiremos como documentación. Para esto se selecciona el caso de uso

(en el diagrama correspondiente), y en la parte inferior se selecciona el tab “Documentation” para escribir

una breve descripción, así:

Se crea el diagrama de interacción deseado (en la versión 0.16 de ArgoUML no están disponibles los

diagramas de secuencia). Para crear el diagrama de secuencia se selecciona “Crear diagrama -

Diagrama de secuencia”. La paleta que aparece es:

UML - 11

Los elementos de la paleta son: objeto, mensaje normal, mensaje de creación, mensaje de destrucción,

mensaje asíncrono y respuesta.

Para comenzar se pueden crear los objetos que intervienen en el proceso, y luego se integran los

mensajes, que van en orden secuencial:

Nótese que el mensaje que llega al objeto de tipo Registro es diferente, pues en este caso se está

creando el objeto.

Al diagrama se le puede adicionar una condición para verificar la posibilidad de alarma, que es un

mensaje del objeto Control a sí mismo (sólo se muestra la parte que cambia):

UML - 12

El otro diagrama de interacción es el diagrama de colaboración. En este diagrama se muestran los

mismos mensajes mostrados en el diagrama de secuencia, pero se hace énfasis en las relaciones que

existen entre los objetos (enlaces) y no tanto en la secuencia de los mensajes. En este diagrama, por lo

tanto, después de crear los objetos hay que establecer enlaces entre ellos y luego sí crear los mensajes

sobre estos enlaces. Cada mensaje tiene la dirección y una numeración, para saber el orden en el cual

se ejecutan.

El mismo diagrama mostrado anteriormente, pero ahora como diagrama de colaboración, queda:

A medida que se crean estos diagramas se complementa el diagrama de clases, pues los mensajes

deben implementarse como métodos. Por ejemplo, la clase Control tendrá un método llamado

“verificarAcceso”.

Algunas veces es importante mostrar los estados por los cuales pasa un objeto (o todo el sistema),

indicando los eventos que hacen que se cambie de un estado a otro, y proporcionando información sobre

el comportamiento del objeto. Esto es posible utilizando un diagrama de estados (equivalente al concepto

formal de máquina de estados). Para crear un diagrama de estados en ArgoUML se selecciona primero

la clase (en el diagrama de clases) de la cual se desea conocer el detalle, y luego se selecciona “Crear

diagrama - diagrama de estado”.

Para el ejemplo se mostrarán los estados de la clase LectorÁrea. Al crear el diagrama de estados se

muestra la siguiente paleta:

En ella se muestran los elementos que pueden incluirse en este tipo de diagramas, que son:

• Estado: representa el estado de un objeto. Es posible, además de dar el nombre del estado,

incluir una lista de acciones que se realizan cuando el objeto está en dicho estado.

• Estado compuesto: es un estado que está compuesto a su vez, por otros estados.

UML - 13

• Transición: muestra un cambio de un estado a otro, generalmente causado por algún evento.

Generalmente se describe de la forma:

evento [condición] / acción

• Estado inicial

• Estado final (se pueden tener varios estados finales)

• Decisión: cuando el cambio de estado depende de alguna condición o decisión, este elemento

permite mostrar la condición y las diferentes rutas que se desprenden. Normalmente es más

usado en los diagramas de actividad que en los diagramas de estado.

• Barras de sincronización: permiten mostrar cuando una transición da lugar a varios estados

concurrentes (paralelos), o cuando de varios estados se llega a uno solo.

• Historia: cuando se cuenta con estados compuestos (y subestados), a veces es necesario

guardar la historia del último subestado visitado para recuperarlo posteriormente. Si además se

guarda toda la historia de los subestados anidados se habla de historia “profunda”.

El diagrama de estado para un objeto LectorÁrea es muy sencillo: cuando se enciende queda esperando

el ingreso de tarjetas. Al ingresar la tarjeta envía la comunicación al servidor y espera la respuesta o que

el tiempo termine. Si recibe una respuesta negativa o se termina el tiempo pasa de nuevo a espera, pero

si recibe una respuesta positiva abre la puerta antes de volver a esperar. Así continúa hasta que es

apagado. El diagrama queda:

Otro diagrama que ayuda a mostrar el comportamiento del sistema es un diagrama de actividades. Este

diagrama, que tiene una notación muy similar al diagrama de estados (de hecho es una especialización

de un diagrama de estados), muestra las diferentes actividades que se llevan a cabo para hacer algún

proceso. Este diagrama es como un diagrama de flujo, e incluso puede tener “canales” para identificar el

responsable de cada actividad. Este tipo de diagramas es muy utilizado para mostrar las acciones de un

caso de uso o para mostrar un proceso de negocio.

En el ejemplo se creará un diagrama de actividades para detallar el comportamiento del caso de uso

“ingresar datos seguridad empleado”. Primero se selecciona este caso de uso (en el diagrama de casos

de uso) y luego se selecciona la opción del menú “Crear diagrama - diagrama de actividades”.

La paleta de elementos en este caso es:

UML - 14

Los elementos definidos en la paleta son:

• Acción: es la actividad u operación que se realiza.

• Transición

• Estado inicial

• Estado final

• Decisión

• Barras de sincronización (para dividir o unir acciones)

Para ingresar los datos de seguridad el empleado primero se consultan los datos básicos. Si estos datos

existen se ingresan las claves, pero si no existen se debe remitir al empleado al departamento de

personal. El diagrama es:

Por último, se pueden tener diagramas de componentes y diagramas de despliegue, que en ArgoUML

están unidos en uno solo.

Los diagramas de componentes muestra la organización y las relaciones de dependencia que hay entre

componentes de software (ejecutables, libreraías, recursos, etc.). Los diagramas de despliegue muestran

la disposición física de los nodos, indicando también el tipo de enlace que hay entre ellos.

Es posible combinar estos dos diagramas, mostrando la configuración del sistema en tiempo de

ejecución, con las instancias de los nodos y los componentes que contienen.

Para el ejemplo se realizarán tres diagramas, que permitan mostrar con mayor claridad la

implementación del sistema. Para crear un diagrama se selecciona “Crear diagrama - diagrama de

instalación (o de implementación)”. La paleta mostrada es y sus elementos son:

• Nodo

• Instancia de un nodo

• Componente

• Instancia de un componente

• Dependencia (que es la relación usual componentes)

• Asociación (que permite relacionar nodos)

• Objeto

• Enlace (para relaciones entre instancias de componentes)

UML - 15

El diagrama de despliegue muestra que hay un servidor, que se comunica con los dispositivos lectores

mediante un enlace inalámbrico (es posible detaller mucho más este enlace indicando, por ejemplo, el

protocolo usado). También está el equipo de la oficina de seguridad (encargado de encender las

alarmas), que también se comunica con el servidor, pero mediante un enlace físico.

El diagrama de componentes mostrará cuatro componentes: dos encargados de la comunicación (en el

dispositivo lector y en el servidor) y dos encargados de la lógica, que dependen de los componentes de

comunicación. El componente encargado de la lógica en el servidor está formado (o “soportado”) por un

objeto de la clase Control, y el componente encargado de la lógica en el dispositivo está formado por un

objeto de la clase LectorArea, así:

Este diagrama es parcial, porque realmente hay muchos otros componentes en el sistema final (y

probablemente agrupe diferentes objetos). Nótese que en este caso cada componente de control

depende del componente de comunicación para poder enviar/recibir los mensajes.

Por último, se tiene el diagrama de implementación que muestra cómo se ubican las instancias de os

componentes en los diferentes nodos (o mejor, en sus instancias), así:

UML - 16

Queda como ejercicio final refinar y terminar estos modelos, de manera que incluyan mayor nivel de

detalle y sean más fieles a un sistema real (puede realizar los cambios que considere necesarios).

Cuando se tienen los modelos más adelantados es posible generar código a partir del diagrama de

clases, que ayuda a tener el “esqueleto” básico de cada clase, con sus atributos y el encabezado de los

métodos. Para generar este código se selecciona la opción del menú “Generar - generar todas las

clases”.

Bibliografía

• OMG Unified Modeling Language Specification, version 1.5 (03-03-01)

• Kobryn, Cris. Introduction to UML: Structural and Use Case Modeling, Object Modeling with OMG

UML Tutorial Series, 2001

• Övergaard, Gunnar, Bran Selic, Conrad Bock y Morgan Björkander. Behavioral Modeling, Object

Modeling with OMG UML Tutorial Series, 2001

• Palmkvist, Karin, Bran Selic, Jos W armer y Nathan Dykman. Advanced Modeling with UML,

Object Modeling with OMG UML Tutorial Series, 2001

• Ibarra, Armando, Msc. El Lenguaje de Modelación Unificado. CINVESTAV-IPN.

• Letelier Torres, Patricio. Desarrollo de Software Orientado a Objeto usando UML. Universidad

Politénica de Valencia (http://www.dsic.upv.es/~uml)