El Lenguaje Unificado de Modelado se ha convertido rápidamente en el estándar de facto para construir software orientado a

objetos. Este Tutorial provee una introducción técnica a los 13 diagramas UML soportados por Enterprise Architect. La
semántica de UML 2 son explicadas en detalles en el nuevo tutorial UML 2.0. Para que se familiarice con estos conceptos de
UML, le recomendamos mirar nuestro tutorial de UML 1.x el cual tiene detalles de los conceptos básicos de UML.
Pero primero... ¿Qué es UML?
La especificación del OMG:
"El Lenguaje de Modelado Unificado (UML) es un lenguaje gráfico para visualizar,
especificar, construir y documentar los artefactos de un sistema intensivo de software.
EL UML ofrece una forma estándar para escribir un plano del sistema, incluyendo cosas conceptuales tales como procesos de
negocios y funciones del sistema, como así también cosas concretas tales como expresiones de lenguajes de programación,
esquemas de bases de datos y componentes de software reutilizables"
El punto importante para notar aquí es que el UML es un "lenguaje" para especificar y no un método o un proceso. El UML se
usa para definir un sistema de software; para detallar los artefactos en el sistema, para documentar y construir -es el
lenguaje en el que está escrito el plano-. El UML se puede usar en una gran variedad de formas para soportar una
metodología de desarrollo de software (tal como el Proceso Unificado de Rational) -pero no especifica en sí mismo qué
metodología o proceso.
El UML define la notación y las semánticas para los siguientes dominios:
- El Modelo de Interacción del Usuario o Modelo de Casos de Uso -describe el límite y la interacción entre el sistema y
los usuarios-. Se corresponde en cierta manera a un modelo de requisitos.
- El Modelo de Interacción o de Colaboración -describe cómo interactuarán los objetos en el sistema entre sí para realizar
el trabajo.
- EL Modelo de Estado o Modelo Dinámico -las cartas de estados describen los estados o condiciones que las clases
asumen a través del tiempo-. Los grafos de actividad describen los flujos de trabajo que implementará el sistema.
- El Modelo Lógico o de Clases -describe las clases y los objetos que conformarán el sistema.
- El Modelo de Componentes Físicos -describe el software (y algunas veces los componentes de hardware) que
conforman el sistema.
- EL Modelo de Despliegue Físico -describe la arquitectura física y el despliegue de componentes en esa arquitectura de
hardware.
El UML también define mecanismos de extensión para extenderlo a fin de cumplir con necesidades específicas (por ejemplo,
extensiones de Modelado de Procesos de Negocios).
La parte dos de este Tutorial detalla más cómo usar el UML para definir y construir sistemas actuales.
Vea también El Modelado de Procesos de Negocios (pdf).
TUTORIAL DE UML 2.0

UML 2 construido en el estándar altamente exitoso UML 1.x, el cual se ha convertido en un estándar de la industria, tanto
para el modelado, diseño y construcción de sistemas de software así como también más negocios generalizados y procesos
científicos. Una introducción a UML 1.x también está disponible en este sitio, y para los nuevos lectores de UML,
recomendamos leer este texto primero para tener una orientación con los conceptos y modelos de UML básicos.
UML 2 define 13 tipos básicos de diagramas, divididos en dos grupos generales:
1. Diagramas de Modelado Estructurado

Los diagramas estructurales definen la arquitectura estática de un modelo. Ellos se usan para modelar las “Cosas” que
constituyen un modelo – los componentes de clases, objetos, interfaces y físicos. Además se usan para modelar las
relaciones y dependencias entre elementos.
- Los diagramas de paquetes se usan para dividir el modelo en contenedores lógicos o “paquetes” y describen las
interacciones entre ellos a un nivel más alto.
- Los diagramas estructurales o de clases definen los bloques de construcción básica de un modelo: los materiales
generales, clases y tipos que se usan para construir un modelo completo.
- Los diagramas de objetos muestran como las instancias de elementos estructurales se relacionan y usan en tiempo de
ejecución.
- Los diagramas de estructuras compuestas proveen un medio de ordenar una estructura de elementos y focalizar en
detalles, construcciones y relaciones internas.
- Los diagramas de componentes se usan para modelar estructuras de alto nivel o más complejas, usualmente
construidas desde una o más clases, y provee una interfaz bien definida.
- Los diagramas de despliegue muestran la disposición de artefactos significativos dentro de una configuración real.

2. Diagramas de Modelado de Comportamiento

Los diagramas de comportamiento capturan las variedades de interacción y el estado instantáneo dentro de un modelo
mientras se “ejecuta” a través del tiempo.
- Los diagramas de Casos de Uso se usan para modelar las interacciones del usuario/sistema. Ellos definen el
comportamiento, requisitos y restricciones en la forma de scripts o escenarios.
- Los diagramas de actividades tienen un amplio número de usos, desde definir un flujo de programa básico, hasta
 capturar los puntos de decisión y acciones dentro de cualquier proceso generalizado.
- Los diagramas de máquina de estados son esenciales para el entendimiento de la condición momento a momento o
“estado de ejecución” de un modelo cuando éste se ejecuta.
- Los diagramas de comunicaciones muestran la red y la secuencia de mensajes de comunicaciones entre objetos en
tiempo de ejecución durante una instancia de colaboración.
- Los diagramas de secuencia están estrechamente relacionados a los diagramas de comunicaciones y muestran la
secuencia de mensajes pasadas entre los objetos usando una línea de tiempo vertical.
- Los diagramas de tiempos fusionan los diagramas de secuencia y estados para proveer una vista de un estado del
objeto a través del tiempo y los mensajes que modifican ese estado.
- Los diagramas de descripción de la interacción fusionan los diagramas de actividades y secuencia para permitir que
los fragmentos de interacción sean fácilmente combinados con los puntos y flujos de decisión.

1 Diagrama de Paquete UML 2

Diagrama de Paquetes
Los diagramas de paquetes se usan para reflejar la organización de paquetes y sus elementos. Cuando se usan para
representaciones, los diagramas de paquete de los elementos de clase se usan para proveer una visualización de los espacios
de nombres. Los usos más comunes para los diagramas de paquete son para organizar diagramas de casos de uso y
diagramas de clase, a pesar de que el uso de los diagramas de paquete no es limitado a estos elementos UML.

El siguiente es un ejemplo de un diagrama del paquete.

Los elementos contenidos en un paquete comparten el mismo espacio de nombre, el hecho de compartir espacios de
nombres requiere que los elementos contenidos en un espacio de nombre específico tengan nombres únicos.
Los paquetes se pueden construir para representar relaciones tanto físicas como lógicas. Cuando se elige incluir las clases a
los paquetes específicos, es útil asignar las clases con la misma jerarquía de herencia a los paquetes, las clases que están
relacionadas a través de la composición y las clases que colaboran que también tienen un fuerte argumento para ser
incluidas en el mismo paquete…

Los paquetes se representan en UML 2.0 como carpetas y contienen los elementos que comparten un espacio de nombre;
todos los elementos dentro de un paquete deben tener un identificador único. El paquete debe mostrar el nombre del
paquete y puede opcionalmente mostrar los elementos dentro del paquete en compartimientos extras.
Combinación de paquetes
Cuando un conector «merge» se usa en un paquete, la fuente de la combinación importa los contenidos importados y
anidados del destino. Si existe un elemento dentro del origen y el destino, las definiciones del elemento origen se expandirán
para incluir las definiciones del elemento contenidas en el destino. Todos los elementos agregados o actualizados por una
combinación se notan por una relación de generalización desde el origen hasta el destino.
Importación de Paquetes
El conector «import» indica que los elementos dentro del paquete destino, que en este ejemplo es una sola clase, se
importarán al paquete origen. El espacio de nombre del paquete origen ganará acceso a la Clase/s de Destino; el espacio de
nombre del destino no está afectado.
Conectores Anidados
El conector anidado entre el paquete destino y los paquetes de origen reflejan lo que muestran los contenidos del paquete.

2 Diagrama de Clase UML 2

Diagrama de Clase
El diagrama de Clase muestra los bloques de construcción de cualquier sistema orientado a objetos. Los diagramas de clases
describen la vista estática del modelo o parte del modelo, describiendo que atributos y comportamientos tienen en lugar de
detallar los métodos para realizar operaciones. Los diagramas de Clase son más útiles para ilustrar relaciones entre clases e
interfaces. Las generalizaciones, agregaciones, y asociaciones son todas valiosas al reflejar herencias, composición o uso, y
conexiones respectivamente.

El siguiente diagrama ilustra relaciones de agregación entre clases. La agregación que tiene la punta de flecha en color más
claro, indica que la clase Account usa AddressBook, pero no necesariamente contiene una instancia de este. La agregaciones
compuestas con una punta de flecha más oscura de los otros conectores, indican pertenencia o contención de las clases de
orígen por las clases destino, por ejemplo los valores Contact y ContactGroup estarán contenidos en AddressBook.

Clases
Una clase es un elemento que define los atributos y comportamientos que un objeto podrá generar. El comportamiento es el
que se describe por posibles mensajes que la clase pueda comprender conjuntamente con las operaciones que son
apropiadas para cada mensaje. Las clases pueden también contener definiciones de valores etiquetados de restricciones y
estereotipos.
Notación de Clase
Las clases se representan por rectángulos que muestran el nombre de la clase y opcionalmente el nombre de las operaciones
y atributos. Los compartimientos se usan para dividir el nombre de la clase, atributos y operaciones. Adicionalmente las
restricciones, valores iniciales y parámetros se pueden asignar a clases.

En el siguiente diagrama la clase contiene el nombre de la clase en el compartimiento más alto, el compartimiento siguiente
detalla los atributos, con el atributo del “centro” mostrando los valores iniciales. El último compartimiento muestra las
operaciones, las operaciones setWidth, setLength y setPosition mostrando sus parámetros. La notación que precede el
nombre del atributo u operación indica la visibilidad del elemento, si se usa el símbolo + el atributo y la operación tienen un
nivel público de visibilidad, si se usa un símbolo – el atributo u operación es privado. Además, el símbolo # permite definir
una operación o atributo como protegido y el símbolo ~ indica la visibilidad del paquete.

Interfaces
Una interfaz es una especificación que los implementadores han acordado realizar. Es un contrato. Si se realiza una interfaz,
se garantiza que las clases soporten un comportamiento requerido, que permite que el sistema trate los elementos no
relacionados en la misma manera – es decir a través de la interfaz común.

Las interfaces se pueden dibujar en un estilo similar al de una clase, con operaciones especificadas como se muestra a
continuación. También se pueden dibujar como un círculo con ninguna operación explicita detallada. Cuando se dibujan como
un círculo, se dibujan vínculos de realización a la forma de círculo de la notación sin flechas de destino.

Tablas
Una tabla es una clase estereotipada. Esto se dibuja con un pequeño icono de la tabla en la esquina superior derecha. Los
atributos de la tabla son «columnas» estereotipadas. La mayoría de las tablas tendrán una clave primaria, siendo uno o más
campos los que forman una combinación única usada para acceder la tabla, más una operación de clave primaria que es
«PK» estereotipada. Algunas tablas tendrán una o más claves foráneas, siendo uno o más campos que juntos trazan a una
clave foránea en una tabla relacionada, más una operación de clave foránea que es «FK» estereotipada.
Asociaciones
Una asociación implica que dos elementos del modelo tienen una relación – usualmente implementada como una variable de
instancia de una clase. Este conector puede incluir roles nombrados en cada extremo, cardinalidad, dirección y restricciones.
Una asociación es el tipo de relación general entre elementos. Para más de dos elementos, un elemento de la caja de
herramientas de representación diagonal también se puede usar. Cuando se genera código para diagramas de clase, las
asociaciones se convierten en variables de instancia en la clase de destino.

Generalizaciones
Una generalización se usa para indicar herencia. Dibujada desde un clasificador especifico a un clasificador general, la
implicación general es que el origen hereda las características del destino. El siguiente diagrama muestra una
clase padre generalizando una clase hijo. Implícitamente, un objeto instanciado de la clase Circulo tendrá atributos
x_position, y_position y radius y un método display(). Tener en cuenta que la Forma de clase es abstracta, mostrada por el
nombre en itálica.

El siguiente diagrama muestra una vista equivalente de la misma información.

Agregaciones
Las agregaciones se usan para describir elementos que están compuestos de componentes más pequeños. Las relaciones de
agregación se muestran por una punta de flecha con forma de diamante apuntando hacia el destino o clase padre.

Una forma más fuerte de agregación – una agregación compuesta – se muestra por una flecha con forma de diamante negro
y se usa donde los componentes se pueden incluir en un máximo de una composición a la vez. Si el padre de una agregación
compuesta se elimina, usualmente todas sus partes se eliminan con el mismo; sin embargo una parte puede ser
individualmente eliminada desde una composición sin tener que eliminar toda la composición. Las composiciones son
relaciones transitivas, asimétricas y pueden ser recursivas.
El siguiente diagrama ilustra la diferencia entre agregaciones fuertes y débiles. Un libro de direcciones esta conformado de
múltiples contactos y grupos de contacto; un contacto se puede incluir en más de un grupo de contacto. Si elimina un libro
de direcciones, todos los contactos y grupos de contactos se eliminarán también; si elimina un grupo de contacto, ningún
contacto se eliminará.

Clase Asociación
Una clase asociación es una estructura que permite una conexión de asociación para tener conexiones y atributos. El
siguiente ejemplo muestra que hay más al ubicar un empleado a un proyecto que al hacer un vínculo asociación simple
entre dos clases: el rol que el empleado toma en un proyecto es una entidad compleja y contiene detalles que no pertenecen
al empleado o clase del proyecto. Por ejemplo, un empleado puede estar trabajando en muchos proyectos al mismo tiempo y
tienen diferentes títulos de trabajo y niveles de seguridad.

Dependencias
Una dependencia se usa para modelar un alto rango de relaciones dependientes entre elementos del modelo. Esto se usaría
normalmente tempranamente en el proceso de diseño donde se conoce que hay algún tipo de vínculo entre dos elementos
pero es muy temprano para saber exactamente cual es la relación. Luego en el proceso de diseño, las dependencias serán
estereotipadas (los estereotipos disponibles incluyen <<instanciar>>, <<trazar>>, <<importar>> y otros) o reemplazar
con un tipo de conector más especifico.
Trazado
La relación de trazado es una especialización de una dependencia, vinculando elementos del modelo o conjuntos de
elementos que representan la misma idea a través de los modelos. Los trazados se usan a menudo para rastrear cambios de
requisitos y del modelo. Como los cambios pueden ocurrir en dos direcciones, la orden de esta dependencia usualmente se
ignora. Las propiedades de relación pueden especificar la asignación de trazado, pero el trazado es usualmente bi-
direccional, informal y raramente computable.
Realizaciones
El objeto fuente implementa o realiza el destino. Realizar se usa para expresar trazabilidad e integridad en el modelo – un
proceso de negocio o requisitos se realiza por uno o más casos de uso que a su vez se realizan por un componente, etc.
Asignando requisitos, clases, etc. a través del diseño de su sistema, hacia arriba a través de los niveles de abstracciones del
modelo, asegura las imágenes grandes de su sistema, recuerda y refleja todas las imagines pequeñas y detalla esa
restricción y la define. Una relación se muestra como una línea de trazos con una punta de flecha sólida y el estereotipo
<<realizar>>.
Anidamientos
Un anidamiento es un conector que muestra que el elemento fuente se anida dentro del elemento destino. El siguiente
diagrama muestra la definición de una clase interna a pesar de que en EA es más usual mostrarlos por su posición en la
jerarquía de la Vista del Proyecto.

3 Diagrama de Objetos UML 2

Diagrama de Objetos
An object Un diagrama de Objeto se puede considerar un caso especial de un diagrama de clase. Los diagramas de objetos
usan un sub conjunto de elementos de un diagrama de clase para enfatizar la relación entre las instancias de las clases en
algún punto en el tiempo. Estos son útiles para entender los diagramas de clases. Estos no muestran nada diferente en su
arquitectura a los diagramas de secuencia, pero reflejan multiplicidad y roles.
Elementos de Clase y Objeto
El siguiente diagrama muestra las diferencias en apariencia entre un elemento clase y un elemento objeto. Tener en cuenta
que el elemento clase consiste de tres partes, divididas en compartimientos de nombres, atributos y operaciones; por
predeterminado, los elementos objetos no tienen compartimientos. La exhibición de los nombres es también diferente: los
nombres de los objetos están subrayados y pueden mostrar el nombre del clasificador desde el cual el objeto se instancia.

Estado en tiempo de ejecución

Un elemento clasificador puede tener cualquier número de atributos y operaciones. Estos se muestran en una instancia
objeto. Sin embargo, es posible definir el estado en tiempo de ejecución del objeto, mostrando un conjunto de valores de
atributos en la instancia particular.
Ejemplos de diagramas de clase y objeto
El siguiente diagrama muestra un diagrama objeto con su intercalación de clase definida, e ilustra la forma en la que un
diagrama objeto se puede usar para probar las multiplicidades de tareas en los diagramas de clase. La clase car tiene
multiplicidad de una a muchos a la clase wheel, pero si en su lugar se elije una multiplicidad de 1 a 4, eso no hubiera
permitido una clase car con tres clases wheel como se muestra en el diagrama objeto.

4 Diagrama de Estructura Compuesta UML 2

Diagramas de Estructura Compuesta

Un diagrama de estructura compuesta es un diagrama que muestra la estructura interna de un clasificador, incluyendo sus
puntos de interacción a otras partes del sistema. Esto muestra la configuración y relación de las partes que juntas realizan el
comportamiento de clasificador contenido.

Los elementos de clase han sido descriptos en gran detalle en la sección en los diagramas de clase. Esta sección describe la
forma en que las clases se pueden mostrar como elementos compuestos exponiendo interfaces y conteniendo puertos y
partes.
Parte
Una parte es un elemento que representa un conjunto de una o más instancias que pertenecen a una instancia del
clasificador contenida. Por ejemplo, si una instancia de diagrama se apropia de un conjunto de elementos gráficos, luego los
elementos gráficos se pueden representar como partes, si fuera útil hacer eso para modelar algún tipo de relación entre
ellos. Tener en cuenta que una parte se puede quitar de sus padres antes de que el padre se elimine, para que la parte no se
elimine al mismo tiempo.

Una parte se muestra como un rectángulo no adornado dentro del cuerpo de una clase o del elemento componente.

Puerto
Un Puerto es un elemento escrito que representa una parte visible externa de una instancia del clasificador contenido. Los
puertos definen la interacción entre un clasificador y su entorno. Un Puerto puede aparecer en el límite de la parte contenida,
una clase o una estructura compuesta. Un Puerto puede especificar los servicios que un clasificador provee así como también
los servicios que este requiere de su entorno.

Un Puerto se muestra como un rectángulo nombrado en el borde del límite de su clasificador apropiado.

Interfaces
Una interfaz es similar a una clase pero con un número de restricciones. Todas las operaciones de la interfaz son públicas y
abstractas, y no proveen ninguna implementación predeterminada. Todos los atributos de la interfaz deben ser constantes.
Sin embargo, mientras que una clase puede solo heredar de una sola super-clase, puede implementar interfaces múltiples.

Una interfaz, cuando esta sola en un diagrama, se muestra como un rectángulo del elemento clase con la clave «interfaz» y
con su nombre en itálica para denotar que es abstracto, o se muestra como un circulo.

Tener en cuenta que la notación del círculo no muestra las operaciones de la interfaz. Cuando las interfaces se muestran
como si fueran apropiadas por las clases, se refieren a ellas como interfaces expuestas. Una interfaz expuesta se puede
definir como provista o requerida. Una interfaz provista es una afirmación que el clasificador contenido provee a las
operaciones definidas por el elemento de la interfaz nombrada y se define dibujando un vínculo de realización entre la clase y
la interfaz. Una interfaz requerida es un estado que el clasificador puede comunicar con algún otro clasificador que provee
operaciones definidas por el elemento de la interfaz nombrada y se define dibujando un vínculo de dependencia entre la clase
y la interfaz
Una interfaz provista se muestra como una “pelota en un palo” adjuntada al borde de un elemento clasificador. Una interfaz
requerida se muestra como una “copa en un palo” adjuntada al borde de un elemento clasificador.

Delegar
Un conector delegar se usa para definir los trabajos internos de los puertos e interfaces externas del componente. Un
conector delegar se muestra como una flecha con un estereotipo «delegar». Esto conecta un contrato externo de un
componente como se muestra por sus puertos a la realización interna del comportamiento de la parte del componente.

Colaboración
Una colaboración define un conjunto de roles co-operativos usados colectivamente para ilustrar una funcionalidad especifica.
Una colaboración debería solo mostrar los roles y los atributos requeridos para lograr sus tareas o funciones definidas. Aislar
los roles primarios es un ejercicio de simplificar la estructura y clasificar el comportamiento, y también provee para poder re-
usarlo. Un elemento colaboración a menudo implementa un patrón.

Un elemento colaboración se muestra como un elipse

Enlace de Roles
Un conector enlace de roles se dibuja desde una colaboración a un clasificador que completa el rol. Esto se muestra como
una línea de trazos con una punta de flecha y el estereotipo «enlace de roles».
Representa
Un conector representa se puede dibujar desde una colaboración a un clasificador para mostrar que una colaboración se usa
en el clasificador. Se muestra como una línea de trazos con una punta de flecha y el estereotipo «representa».

Ocurrencia
Un conector ocurrencia se puede dibujar desde una colaboración a un clasificador para mostrar que la colaboración
representa (sic) el clasificador. Esto se muestra como una línea de trazos y el estereotipo «ocurrencia».

5 Diagrama de Componentes UML 2

Diagramas de Componentes
Los Diagramas de Componentes ilustran las piezas del software, controladores embebidos, etc. que conformarán un sistema.
Un diagrama de Componentes tiene un nivel más alto de abstracción que un diagrama de clase – usualmente un componente
se implementa por una o más clases (u objetos) en tiempo de ejecución. Estos son bloques de construcción, como
eventualmente un componente puede comprender una gran porción de un sistema.
El diagrama de abajo muestra algunos componentes y sus relaciones internas. Los conectores Ensamble „vinculan‟ las
interfaces proporcionadas suministrada por el Producto y el Cliente a las interfaces requeridas especificadas por orden. Una
relación de dependencia traza los detalles de la cuenta asociada del cliente a la interfaz requerida, „pago‟, indicada por orden
Los componentes son similares en práctica a los diagramas de paquete como los límites definidos y se usan para agrupar
elementos en estructuras lógicas. La diferencia entre Diagramas de Paquete y Diagramas de Componente es que los
diagramas de componente ofrecen un mecanismo de agrupamiento más rico semánticamente. Con los Diagramas de
Componente todos los elementos del modelo son privados mientras que los diagramas de Paquete solo muestran ítems
públicos.
Representando Componentes
Los componentes se representan como un clasificador rectangular con la clave «componente», opcionalmente el componente
se puede mostrar como un rectángulo con un icono de componente en la esquina derecha arriba.

Interfaces Requeridas
El conector Ensamble une la interfaz requerida del componente (Componente1) con la interfaz proporcionada de otro
componente (Component2); esto permite que un componente provea los servicios que otro componente requiere. Las
Interfaces son colecciones de uno o más métodos que pueden o no contener atributos.

Componentes con puertos

Usar puertos con Diagramas de Componentes permite que se especifique un servicio o comportamiento a su entorno así
como también un servicio o comportamiento que un componente requiere. Los puertos pueden especificar entradas, salidas
así como también operar bi-direccionalmente. El siguiente diagrama detalla un componente con un puerto para servicios En
Línea conjuntamente con dos interfaces proporcionadas Ordenar Entrada y Seguimiento así como también una interfaz
requerida Pago.

6 Diagrama de Despliegue UML 2

Diagrama de Despliegue
Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecución de un sistema. Esto muestra la configuración de
los elementos de hardware (nodos) y muestra cómo los elementos y artefactos del software se trazan en esos nodos.

Nodo
Un Nodo es un elemento de hardware o software. Esto se muestra con la forma de una caja en tres dimensiones, como a
continuación.

Instancia de Nodo
Una instancia de nodo se puede mostrar en un diagrama. Una instancia se puede distinguir desde un nodo por el hecho de
que su nombre esta subrayado y tiene dos puntos antes del tipo de nodo base. Una instancia puede o no tener un nombre
antes de los dos puntos. El siguiente diagrama muestra una instancia nombrada de una computadora.

Estereotipo de Nodo
Un número de estereotipos estándar se proveen para los nodos, nombrados «cdrom», «cd-rom», «computer», «disk array»,
«pc», «pc client», «pc server», «secure», «server», «storage», «unix server», «user pc». Estos mostrarán un icono
apropiado en la esquina derecha arriba del símbolo nodo.

Artefacto
Un artefacto es un producto del proceso de desarrollo de software, que puede incluir los modelos del proceso (e.g. modelos
de Casos de Uso, modelos de Diseño, etc.), archivos fuente, ejecutables, documentos de diseño, reportes de prueba,
prototipos, manuales de usuario y más.
Un artefacto se denota por un rectángulo mostrando el nombre del artefacto, el estereotipo «artifact» y un icono de
documento, como a continuación.

Asociación
En el contexto del diagrama de despliegue, una asociación representa una ruta de comunicación entre los nodos. El siguiente
diagrama muestra un diagrama de despliegue para una red, mostrando los protocolos de red como estereotipos y también
mostrando multiplicidades en los extremos de la asociación.

Nodo como contenedor

Un nodo puede contener otros elementos, como componentes o artefactos. El siguiente diagrama muestra un diagrama de
despliegue para una parte del sistema embebido y muestra un artefacto ejecutable como contenido por el nodo madre
(motherboard).

7 Diagrama de Casos de Uso UML 2

Modelo de Casos de Uso

El modelo de casos de uso captura los requisitos de un sistema. Los casos de uso son un medio de comunicación con los
usuarios y otros interesados acerca de lo que se piensa hacer del sistema.
 Actores
Un diagrama de casos de uso muestra la interacción entre el sistema y entidades externas al sistema. Estas entidades
externas se referencian como actores. Los actores representan los roles que pueden incluir usuarios humanos, un hardware
externo u otros sistemas. Un actor usualmente se dibuja como una figura o alternativamente como una clase con la palabra
clave «actor».

Los actores pueden generalizar otros actores como se detalla en el siguiente diagrama.

Casos de Uso
Un caso de uso es una sola unidad de trabajo significativo. Este provee una vista de alto nivel de comportamiento observable
para alguien o algo fuera del sistema. La notación por un caso de uso es una elipse.

La notación para usar un caso de uso es una línea de conexión con una punta de flecha opcional mostrando la dirección del
control. El siguiente diagrama indica que el actor Customer (cliente) usa el caso de uso withdraw (retirar).

El conector “use” puede tener opcionalmente valores múltiples en cada final, como en el siguiente diagrama que muestra que
el cliente puede tener solo una sesión de “withdraw” (retiro) a la vez, pero un banco puede tener cualquier cantidad de
clientes haciendo retiros concurrentemente.

Definiciones de Casos de Uso

Un Caso de Uso normalmente incluye:
 Nombre y Descripción
 Requisitos
 Restricciones
 Escenarios
 Diagramas de escenarios
 Información adicional.
Nombre y Descripción
Un caso de uso normalmente se nombra como una frase verbal y se le da una descripción textual informal.
Requisitos
Los requisitos definen los requisitos funcionales formales que un caso de uso debe proveer al usuario final. Estos
corresponden a las especificaciones funcionales encontradas en las metodologías estructuradas. Un requisito es un contrato o
promesa de que el caso de uso realizará una acción o proveerá algún valor al sistema.
Restricciones
Una restricción es una condición o restricción bajo la cual opera un caso de uso y que incluye pre, y post condiciones y
condiciones invariantes. Una pre condición especifica las condiciones que se necesitan cumplir antes de que el caso de uso
pueda proceder. Una post condición se usa para documentar el cambio en condiciones que deben ser verdaderas después de
la ejecución del caso de uso. Una condición invariante especifica las condiciones que son verdaderas a través de la ejecución
del caso de uso.
Escenarios
Un escenario es una descripción formal del flujo de eventos que ocurren durante la ejecución de una instancia de casos de
uso. Este define la secuencia específica de eventos entre el sistema y los actores externos. Este normalmente se describe en
el texto y corresponde a la representación textual del diagrama de secuencia.
Incluyendo Casos de Uso
Los casos de uso pueden contener la funcionalidad de otro caso de uso como parte de su proceso normal. En general se
asume que cualquier caso de uso incluido se llamará cada vez que se ejecute una ruta básica. Un ejemplo de esto tiene la
ejecución de Caso de uso <Card Identification> para ejecutar como parte de un caso de uso <Withdraw>.

Los casos de uso se pueden incluir por uno o más casos de uso, ayudando a reducir el nivel de duplicación de la funcionalidad
realizando un factoreo del comportamiento común en casos de uso que se usan muchas veces.
Casos de Uso extendidos
Un caso de uso se pude usar para extender el comportamiento de otro, esto normalmente se usa en circunstancias. Por
ejemplo, si antes de modificar un tipo particular de orden del cliente, un usuario debe obtener la aprobación de una
autoridad superior, luego el caso de uso <Get Approval> puede opcionalmente extender el caso de uso <Modify Order>.

Puntos de extensión
El punto al cual un caso de uso extendido se agrega se puede definir por medio de un punto de extensión.
Límite del sistema
Usualmente se usa para mostrar casos de uso dentro del sistema y actores fuera del sistema.

8 Diagrama de Actividades UML 2

Diagrama de Actividades
En UML un diagrama de actividades se usa para mostrar la secuencia de actividades. Los diagramas de actividades muestran
el flujo de trabajo desde el punto de inicio hasta el punto final detallando muchas de las rutas de decisiones que existen en el
progreso de eventos contenidos en la actividad. Estos también pueden usarse para detallar situaciones donde el proceso
paralelo puede ocurrir en la ejecución de algunas actividades. Los Diagramas de Actividades son útiles para el Modelado de
Negocios donde se usan para detallar el proceso involucrado en las actividades de negocio.

Un ejemplo de un diagrama de actividades se muestra a continuación

Las siguientes secciones describen los elementos que constituyen un diagrama de actividades.
Actividades
Una actividad es la especificación de una secuencia parametrizada de comportamiento. Una actividad muestra un rectángulo
con las puntas redondeadas adjuntando todas las acciones, flujos de control y otros elementos que constituyen la actividad.

Acciones
Una acción representa un solo paso dentro de una actividad. Las acciones se denotan por rectángulos con las puntas
redondeadas.

Restricciones de Acción
Las restricciones se pueden adjuntar a una acción. El siguiente diagrama muestra una acción con pre y post condiciones
locales.
Flujo de Control
Un flujo de control muestra el flujo de control de una acción a otra. Su notación es una línea con una punta de flecha.

Nodo Inicial
Un nodo inicial o de comienzo se describe por un gran punto negro, como se muestra a continuación.

Nodo Final
Hay dos tipos de nodos finales: nodos finales de actividad y de flujo. El nodo final de actividad se describe como un círculo
con un punto dentro del mismo.

El nodo final de flujo se describe como un círculo con una cruz dentro del mismo.

La diferencia entre los dos tipos de nodos es que el nodo final del flujo denota el final de un solo flujo de control, y el nodo
final de actividad denota el final de todos los flujos finales dentro de la actividad.
Flujos de Objetos y Objeto
Un flujo de objeto es la ruta a lo largo de la cual pueden pasar objetos o datos. Un objeto se muestra cómo un rectángulo.

Un flujo de objeto se muestra como un conector con una punta de flecha denotando la dirección a la cual se está pasando el
objeto.
Un flujo de objeto debe tener un objeto en por lo menos uno de sus extremos. Una notación de acceso rápido para el
diagrama de arriba sería usar los pins de salidas y entradas.

Un almacén de clave se muestra como un objeto con las clave «datastore».

Nodos de Decisión y Combinación

Los nodos de decisión y combinación tienen la misma notación: una forma de diamante. Los dos se pueden nombrar. Los
flujos de control que provienen de un nodo de decisión tendrán condiciones de guarda que permitirán el control para fluir si
la condición de guarda se realiza. El siguiente diagrama muestra el uso de un nodo de decisión y un nodo de combinación.

Nodos de Bifurcación y Unión

Las bifurcaciones y uniones tienen la misma notación: tanto una barra horizontal como vertical (la orientación depende de si
el flujo de control va de derecha a izquierda o hacia abajo y arriba. Estos indican el comienzo y final de hilos actuales de
control. El siguiente diagrama muestra un ejemplo de su uso.

Una unión es diferente de una combinación ya que la unión sincroniza dos flujos de entrada y produce un solo flujo de salida.
El flujo de salida desde una unión no se puede ejecutar hasta que todos los flujos se hayan recibido. Una combinación pasa
cualquier flujo de control directamente a través de esta. Si dos o más flujos de entrada se reciben por un símbolo de
combinación, la acción a la que el flujo de salida apunta se ejecuta dos o más veces.
Región de Expansión
Una región de expansión es una región de actividad estructurada que se ejecuta muchas veces. Los nodos de expansión de
salida y entrada se dibujan como un grupo de tres casillas representando una selección múltiple de ítems. La clave
reiterativa, paralelo, o flujo se muestra en la esquina izquierda arriba de la región.
Gestores de Excepción
Los gestores de Excepción se pueden modelar en diagramas de actividad como en siguiente ejemplo.

Región de Actividad Interrumpible

Una región de actividad interrumpible rodea un grupo de acciones que se pueden interrumpir. En un ejemplo simple como el
siguiente, la acción Procesar Orden se ejecutará hasta su cumplimiento cuando pase control a la acción Cerrar Orden, a
menos que una interrupción Cancelar Pedido se reciba, la cual pasará el control a la acción Cancelar Orden.

Partición
Una partición de una actividad se muestra como calles horizontales o verticales. En el siguiente diagrama, las particiones se
usan para separar acciones dentro de una actividad en aquellas realizadas por el departamento de contabilidad y aquellas
realizadas por el cliente.
 9 Diagrama de Máquina de Estados UML 2

Diagrama de Máquina de Estados

Un diagrama de maquina de estado modela el comportamiento de un solo objeto, especificando la secuencia de eventos que
un objeto atraviesa durante su tiempo de vida en respuesta a los eventos.

Como ejemplo, el siguiente diagrama de maquina de estado muestra los estados que una puerta atraviesa durante su tiempo
de vida.

La puerta puede estar en uno de tres estados: “Opened”(Abierta), “Closed” (Cerrada) o “Locked”(Bloqueada). Puede
responder a tres estados Abrir, Cerrar, Bloquear y No bloqueado. Tener en cuenta que no todos los eventos son válidos en
todos los estados: por ejemplo, si una puerta está abierta, no lo puede bloquear hasta que lo cierre. También tener en
cuenta de que como una transición de estado puede tener una condición de guarda adjunta. Si la puerta está abierta, esta
solo puede responder al Evento cerrar si la condición doorWay->isEmpty esta completa. La sintaxis y las conexiones usadas
en los diagramas de maquina de estados se discutirán por completo en las siguientes secciones.
Estados
Un estado se denota por un rectángulo con las esquinas redondeadas y con el nombre del estado escrito dentro del mismo.
Estados Initial y Final (Iniciales y Finales)
El estado inicial se denota con un círculo negro y se le puede proporcionar un nombre. El estado final se denota con un
círculo con un punto negro en el medio y también se lo puede nombrar.

Transiciones
Las transiciones desde un estado al siguiente se denotan por líneas con flechas. Una transición puede tener un disparador,
una guarda y un efecto, como a continuación.

“Trigger” (Disparador) es la causa de la transición, la cual podría ser una señal, un evento, un cambio en alguna condición, o
el pasaje de tiempo. "Guard" (guarda) es una condición que debe ser verdadera para que el disparador cause la transición.
"Effect" (efecto) es una acción que se llamará directamente en el objeto que tiene la maquina de estado como resultado de la
transición.
Acciones de Estado
En el ejemplo de transición, un efecto se asoció con la transición. Si el estado de destino tenía muchas transiciones llegando
al mismo, y cada transición tenía el mismo efecto asociado con este, sería mejor asociar el efecto con el estado de destino en
lugar de con las transiciones. Esto se puede realizar para definir una acción de entrada para el estado. El siguiente diagrama
muestra un estado con una acción de entrada y una acción de salida.

También es posible definir las acciones que ocurren en los eventos, o acciones que siempre ocurren. Es posible definir
cualquier número de acciones de cada tipo.
Transiciones recursivas
Un estado puede tener una transición que retorna a sí misma, como en el siguiente diagrama. Esto es más útil cuando un
efecto se asocia con la transición.

Estados Compuestos
Un diagrama de maquina de estado puede incluir diagramas de sub maquinas, como en el siguiente ejemplo.
La forma alternativa de mostrar la misma información es como el siguiente ejemplo.

La notación en la versión anterior indica que los detalles de la sub maquina Check Pin se muestran en un diagrama separado.
Punto de Entrada
Algunas veces no deseará ingresar una sub maquina en un Estado Inicial normal. Por ejemplo, en la siguiente sub maquina
sería normal comenzar en el estado inicial, pero si por alguna razón no fuera necesario realizar la inicialización, sería posible
comenzar en el estado Ready realizando una transición al punto de entrada nombrado.

El siguiente diagrama muestra la maquina de estado un nivel hacia arriba:

Punto de Salida
Similar al Punto de Entada, es posible nombrar Puntos de Salida nombrados. El siguiente diagrama provee un ejemplo donde
el estado ejecutado después del estado de procesos principal depende de que ruta se use para realizar la transición del
estado.

Pseudo estado “Choice” (Elección)

Un pseudo estado se muestra como un diamante con una transición llegando y dos o más transiciones saliendo. El siguiente
diagrama muestra que cualquier estado al que se llega después del pseudo estado elección depende del formato del mensaje
seleccionado durante la ejecución del estado anterior.
Pseudo estado “Junction” (unión)
Los pseudo estados unión se usan para unir transiciones múltiples. Una sola unión puede tener una o más transiciones de
entradas y una o más de salida, y se puede aplicar una guarda a cada transición. Las uniones son libres de semántica; una
unión que divide una transición de entrada en transiciones de salida múltiples realiza una rama condicional estática, opuesto
a un pseudo estado elección que realiza una rama condicional dinámica.

Pseudo estado “Terminate” (terminar)

Ingresar un pseudo terminar indica que la línea de vida de la maquina de estado ha terminado. Un pseudo estado indica que
una línea de vida de la maquina de estado ha terminado. Un pseudo estado terminar se denota como una cruz.

Estado “History” (Historial)

Un estado historial se usa para recordar el estado anterior de una maquina de estado cuando fue interrumpida. El siguiente
diagrama ilustra el uso de estados del historial. El ejemplo es una maquina de estado que pertenece a un lavarropas.
En esta maquina de estado, cuando un lavarropas comience, su proceso será desde el lavado y enjuague hasta el secado. Si
hay un corte de luz, el lavarropas se detendrá por lo que pasará al estado Power off (apagado). Luego, cuando la energía
retorne, el estado Running (ejecutar) ingresa al símbolo de estado Historial, lo que significa que debería seguir con el
proceso donde quedó cuando se corto la energía.
Regiones recientes
Un estado se puede dividir en regiones conteniendo sub estados que existen y se ejecutan concurrentemente. El siguiente
ejemplo muestra que dentro del estado “Applying Brakes” (Aplicar frenos), los frenos de adelante y atrás estarán operando
simultáneamente e independientemente. Tener en cuenta el uso de los pseudo estados en lugar de los pseudo estados
elección y combinación. Estos símbolos se usan para sincronizar los hilos concurrentes.

10 Diagrama de Comunicaciones UML 2

Diagrama de Comunicaciones
Un diagrama de comunicaciones, inicialmente llamado un diagrama de colaboración, es un diagrama de interacción que
muestra información similar a los diagramas de secuencia pero su foco principal es en la relación de objetos.

En los diagramas de comunicaciones, los objetos como se muestran con conectores de asociación entre ellos. Los mensajes
se agregan a las asociaciones y se muestran como flechas cortas apuntando en la dirección del flujo del mensaje. La
secuencia de los mensajes se muestra a través de un esquena enumerado.

Los siguientes diagramas muestran un diagrama de comunicación y el diagrama de secuencia que muestran la misma
información. A pesar de que es posible derivar la secuencia de mensajes en el diagrama de comunicación desde el esquema
enumerado, no es inmediatamente visible. Lo que el diagrama de comunicación realiza es mostrar claramente el conjunto
completo de mensajes pasados entre objetos adyacentes.
 11 Diagrama de Secuencia UML 2

Diagrama de Secuencia
Un diagrama de secuencia es una forma de diagrama de interacción que muestra los objetos como líneas de vida a lo largo
de la página y con sus interacciones en el tiempo representadas como mensajes dibujados como flechas desde la línea de
vida origen hasta la línea de vida destino. Los diagramas de secuencia son buenos para mostrar qué objetos se comunican
con qué otros objetos y qué mensajes disparan esas comunicaciones. Los diagramas de secuencia no están pensados para
mostrar lógicas de procedimientos complejos.
Línea de Vida
Una línea de vida representa un participante individual en un diagrama de secuencia. Una línea de vida usualmente tiene un
rectángulo que contiene el nombre del objeto. Si el nombre es self entonces eso indica que la línea de vida representa el
clasificador que posee el diagrama de secuencia.
Algunas veces un diagrama de secuencia tendrá una línea de vida con un símbolo del elemento actor en la parte superior.
Este usualmente sería el caso si un diagrama de secuencia es contenido por un caso de uso. Los elementos entidad, control y
límite de los diagramas de robustez también pueden contener líneas de vida.

Mensajes
Los mensajes se muestran como flechas. Los mensajes pueden ser completos, perdidos o encontrados; síncronos o
asíncronos: llamadas o señales. En el siguiente diagrama, el primer mensaje es un mensaje síncrono (denotado por una
punta de flecha oscura), completo con un mensaje de retorno implícito; el segundo mensaje es asíncrono (denotado por una
punta de flecha en línea) y el tercero es un mensaje de retorno asíncrono (denotado por una línea punteada).

Ocurrencia de ejecución
Un rectángulo fino a lo largo de la línea de vida denota la ocurrencia de ejecución o activación de un foco de control. En el
diagrama anterior hay tres ocurrencias de ejecución. El primero es el objeto origen que envía dos mensajes y recibe dos
respuestas, el segundo es el objeto destino que recibe un mensaje asíncrono y retorna una respuesta, y el tercero es el
objeto destino que recibe un mensaje asíncrono y retorna una respuesta.
Mensaje Self
Un mensaje self puede representar una llamada recursiva de una operación, o un método llamando a otro método
perteneciente al mismo objeto. Este se muestra como cuando crea un foco de control anidado en la ocurrencia de ejecución
de la línea de vida.
Mensajes perdidos y encontrados
Los mensajes perdidos son aquellos que han sido enviados pero que no han llegado al destino esperado, o que han llegado a
un destino que no se muestra en el diagrama actual. Los mensajes encontrados son aquellos que llegan de un remitente no
conocido, o de un remitente no conocido en el diagrama actual. Ellos se denotan yendo o llegando desde un elemento de
punto final.

Inicio y final de línea de vida

Una línea de vida se puede crear o destruir durante la escala de tiempo representada por un diagrama de secuencia. En el
último caso, la línea de vida se termina por un símbolo de detención, representado como una cruz. En el primer caso, el
símbolo al inicio de la línea de vida se muestra en un nivel más bajo de la página que el símbolo del objeto que causó la
creación. El siguiente diagrama muestra un objeto que fue creado y destruido.

Restricciones de tiempo y duración

En forma predeterminada, un mensaje se muestra como una línea horizontal. Ya que la línea de vida representa el pasaje de
tiempo hacia abajo, cuando se modela un sistema en tiempo real, o incluso un proceso de negocios en tiempo límite, puede
ser importante considerar el tiempo que toma realizar las acciones. Al configurar una restricción de duración para un
mensaje, el mensaje se mostrará como una línea inclinada.
 Fragmentos combinados
Se estableció anteriormente que no se espera que los diagramas de secuencia muestren lógicas de procedimientos
complejos. Siendo este el caso, hay un número de mecanismos que permiten agregar un grado de lógicas de procedimientos
a los diagramas y que a la vez vienen bajo el encabezado de fragmentos combinados. Un fragmento combinado es una o
más secuencias de procesos incluidas en un marco y ejecutadas bajo circunstancias nombradas específicas. Los fragmentos
disponibles son:

 El fragmento Alternative (denotedo “alt”) modela estructuras if…then…else.

 El fragmento Option (denotado “opt”) modela estructuras switch.
 El fragmento Break modela una secuencia alternativa de eventos que se procesa en lugar de todo del resto del diagrama.
 El fragmento Parallel (denotado “par”) modela procesos concurrentes.
 El fragmento de secuenciado Weak (denotado “seq”) incluye un número de secuencias para las cuales todos los mensajes se
deben procesar en un segmento anterior, antes de que el siguiente segmento pueda comenzar, pero que no impone ningún
secuenciado en los mensajes que no comparten una línea de vida.
 El fragmento de secuenciado Strict (denotado “strict”) incluye una serie de mensajes que se deben procesar en el orden
proporcionado.
 El fragmento Negative (denotado “neg”) incluye una serie de mensajes inválidos.
 El fragmento Critical incluye una sección crítica.
 El fragmento Ignore declara un mensaje o mensajes que no son de ningún interés si este aparece en el contexto actual.
 El fragmento Consider es el opuesto del fragmento Ignore: cualquier mensaje que no se incluya en el fragmento Consider se
debería ignorar.
 El fragmento Assertion (denotado “assert”) designa que cualquier secuencia que no se muestra como un operando de la
aserción es inválida.
 El fragmento Loop incluye una serie de mensajes que están repetidos.
El siguiente diagrama muestra un fragmento loop.
También hay una ocurrencia de interacción, que es similar a un fragmento combinado. Una ocurrencia de interacción es una
referencia a otro diagrama que tiene la palabra “ref” en la esquina izquierda arriba del marco, y tiene el nombre del
diagrama referenciado que se muestra en el medio del marco
Puerta
Una puerta es un punto de conexión para conectar un mensaje dentro de un fragmento con un mensaje fuera del fragmento.
EA muestra una puerta como un cuadro pequeño en un marco del fragmento.

Descomposición en parte
Un objeto puede tener más de una línea de vida que viene de ésta. Esto permite mensajes de entre e intra objetos para que
se muestren en el mismo diagrama.
Continuaciones / Invariantes de Estado
Una invariante de estado es una restricción ubicada en una línea de vida que debe ser verdadera en el tiempo de ejecución.
Esta se muestra como un rectángulo con los extremos en semi-circulos.

Una continuación tiene la misma notación que una invariante de estado pero se usa en fragmentos combinados y puede
extenderse a través de más de una línea de vida.

12 Diagrama de Tiempo UML 2

Diagrama de Tiempo
Los diagramas de tiempos de UML se usan para mostrar el cambio en el estado o valor de uno o más elementos en el
tiempo. Este también puede mostrar la interacción entre los eventos de tiempos, las restricciones de tiempos y la duración
que los gobiernan.
Línea de vida del estado
Una línea de vida del estado muestra el cambio de estado de ítem en el tiempo. El eje-X muestra el tiempo trascurrido en
cualquier unidad que se elija mientras que el eje-Y se nombra con una lista de estados proporcionados. El siguiente es un
ejemplo de una línea de vida del estado.
Línea de vida del valor
Una línea de vida del valor muestra el cambio del valor de un ítem en el tiempo. El eje-X muestra el tiempo transcurrido en
cualquier unidad que se elija, lo mismo que para la línea de vida del estado. El valor se muestra entre el par de líneas
horizontales que se cruzan en cada cambio del valor. El siguiente es un ejemplo de una línea de vida del valor.

Ubicar todo junto

Las líneas de vida y del estado se pueden ubicar una arriba de otro en cualquier combinación. Estas deben tener el mismo
eje-X. Los mensajes se pueden pasar de una línea de vida a otra. Cada transición del estado o valor puede tener un evento
definido, una restricción de tiempo que indica cuándo debe ocurrir un evento, y una restricción de duración que indica cuánto
tiempo debe estar en efecto un valor o estado. Una vez que estos se hayan aplicado, un diagrama de tiempo debería ser
como el siguiente.

13 Diagrama de Descripción de la Interacción UML 2

Diagrama de Descripción de la Interacción

Un diagrama de descripción de la interacción es una forma de diagrama de actividad en el cual los nodos representan
diagramas de interacción. Los diagramas de interacción pueden incluir diagramas de secuencia, comunicación, de descripción
de la interacción y de tiempos. La mayoría de la notación para los diagramas de descripción de la interacción es la misma
que para los diagramas de actividad, por ejemplo los nodos inicial, final, decisión, combinación, bifurcación y unión son todos
lo mismo. Sin embargo, los diagramas de descripción de la interacción introducen dos elementos nuevos, ocurrencias de
interacción y elementos de interacción.
Ocurrencia de la Interacción
Ocurrencias de Interacción son referencias a los diagramas de interacción existentes. Una ocurrencia de interacción se
muestra como un marco de referencia, es decir un marco con “ref” en la esquina superior izquierda. El nombre del diagrama
al cual se hace referencia se muestra en el centro del marco.

Elemento de Interacción
Los elementos de Interacción son similares a los de ocurrencias de interacción en el hecho de que estos muestran una
representación de diagramas de interacción existentes dentro de un marco rectangular. Estos difieren en el hecho de que
muestran los contenidos de los diagramas de referencia en línea.

Agrupar todo
Los mismos controles de los diagramas de actividad (bifurcación, unión, combinación etc) se pueden usar en diagramas de
descripción de la interacción para poner la lógica del control alrededor de los diagramas de bajo nivel. El siguiente ejemplo
describe un proceso de venta como ejemplo con sub-procesos dentro de las ocurrencias de interacción.
MODELOS UML

14 Modelando Procesos de Negocios

Una introducción a la terminología y a los íconos que se usan en el Modelo de Procesos de Negocio. Provee una introducción
rápida a los conceptos del Lenguaje de Modelado Unificado (UML) y a cómo éstos se aplican en el Modelo de Procesos de
Negocio de Enterprise Architect.
Un proceso de negocio:
1. Tiene un objetivo
2. Tiene entradas específicas
3. Tiene salidas especícicas
4. Emplea recursos
5. Tiene un número de actividades que se llevan a cabo en algún orden
6. Puede afectar más de uan unidad organizacional. Impacto organizacional horizontal
7. Crea valores de algún tipo para el cliente. El cliente puede ser interno o externo.
Modelo de Procesos
Proceso de Negocio:
Un proceso de negocio es una colección de actividades diseñadas para producir una salida específica para un cliente o
mercado particular. Implica un fuerte énfasis en 'cómo' se hace el trabajo en una organización, en contraposición al enfoque
en 'qué' de producto. Así, un proceso es un ordenamiento específico de actividades de trabajo a través del tiempo y del
espacio, con un comienzo, un fin, entradas y salidas claramente identificados: una estructura para la acción.
Conexiones
• Vínculo de provisión desde el objeto Información. Un vínculo de provisión indica que la información u objeto vinculado al
proceso no se utiliza en la fase de procesamiento. Por ejemplo, se pueden utilizar plantillas de órdenes una y otra vez
para proveer nuevas órdenes de un cierto estilo -las plantillas no se alteran ni se consumen como parte de la actividad-
• Vínculo de provisión desde el objeto Recurso. Un vínculo de entrada indica que el objeto o recurso adjunto se consume
durante el procedimiento del proceso. Como ejemplo, a medida que se procesan las órdenes de un cliente se completan y
firman y típicamente se utiliza sólo una vez por cada recurso único (orden).
• Vínculo de objetivo al objeto Objetivo. Un vínculo de objetivo indica que el objeto adjunto al proceso de negocio describe
su objetivo. Un objetivo es la justificación de negocio para desarrollar la actividad.
• Vínculo de flujo de estados al objeto Salida
• Vínculo de flujo de estados desde el evento Event. Un vínculo de flujo de estado indica que se pasa algún objeto al
proceso de negocio. Captura el paso de control a otra entidad o proceso, con el paso implícito del estado o de
información desde una actividad a otra.
Figura 1 : Flujo de Trabajo
Objetivo
Objetivo:
Un proceso de negocio tiene algún objetivo bien definido. Esta es la razón por la que la organización realiza este trabajo y se
debería definir en los términos de los beneficios que tiene para la organización como un todo y en la satisfacción de las
necesidades de negocio.
Conexiones
Vínculo de objetivo desde la actividad proceso de negocio. Un vínculo de objetivo indica que el objeto adjunto al proceso de
negocio describe su objetivo. Un objetivo es la justificación de negocio para el desarrollo de la actividad.
Información
Objetivo:
Los procesos de negocio utilizan información para personalizar o completar sus actividades. La información, a diferencia de
los recursos, no se consume en el proceso -más bien se utiliza como parte del proceso de transformación. La información
puede provenir de Fuentes externas, de clientes, de unidades organizacionales internas e incluso puede ser el producto de
otros procesos.
Conexiones
Vínculo de provisión a la actividad proceso de negocio. Un vínculo de provisión indica que la información u objeto vinculado al
proceso no se utiliza en la fase de procesamiento. Por ejemplo, se pueden utilizar plantillas de órdenes una y otra vez para
proveer nuevas órdenes de un cierto estilo -las plantillas no se alteran ni se consumen como parte de la actividad-.
Salida
Objetivo:
Un proceso de negocio producirá típicamente una o más salidas de valor para el negocio, tanto para uso interno como para
satisfacer requisitos externos. Una salida puede ser un objeto físico (tal como un informe o una factura), una transformación
de recursos crudos en un nuevo ordenamiento (una agenda diaria o calendario) o un resultado global de negocio tal como
completar una orden de cliente.
Una salida de un proceso de negocio puede alimentar otros procesos, tanto como un ítem que se solicita o como un
disparador para iniciar nuevas actividades.
Conexiones
Vínculo de flujo de estados desde la actividad Proceso de Negocio
Recurso
Objetivo:
Un recurso es una entrada a un proceso de negocio y, a diferencia de la información, típicamente se consume durante el
procesamiento. Por ejemplo, a medida que se lleva a cabo y se registran las novedades de cada servicio de tren diario, el
recurso servicio se 'usa' tantas veces como concierna al proceso de registrar las novedades del tren.
Conexiones
Vínculo de provisión a la actividad proceso de negocio. Un vínculo de provisión indica que el objeto o recurso adjunto se
consume durante el procesamiento del procedimiento. Como ejemplo, a medida que se procesan las órdenes de un cliente se
completan y firman y típicamente se utiliza sólo una vez por cada recurso único (orden).

15 Modelo de Caso de Uso

El modelo de casos de uso describe la funcionalidad propuesta del nuevo sistema. Un caso de uso representa una unidad
discreta de interacción entre un usuario (humano o máquina) y el sistema. Un Caso de Uso es una unidad simple de trabajo
significativo; por ejemplo, "Validarse en el sistema", "Registrarse en el sistema" y "Crear un pedido" son todos casos de uso.
Cada caso de uso tiene una descripción que describe la funcionalidad que se construirá en el sistema propuesto. Un caso de
uso puede "incluir" la funcionalidad de otro caso de uso o "extender" a otro caso de uso con su propio comportamiento.
 Una descripción de caso de uso generalmente incluirá:
 Comentarios generales y notas describiendo el caso de uso
 Requisitos -cosas que el caso de uso debe permitir hacer al usuario, tales como <capacidad para actualizar pedido>,
<capacidad para modificar pedido>, etc.
 Restricciones -reglas acerca de qué se puede y qué no se puede hacer-. Incluye:
o Pre-condiciones que deben ser verdaderas antes de que el caso de uso se ejecute, por ejemplo <crear pedido> debe
preceder a <modificar pedido>
o Post-condiciones que deben ser verdaderas una vez que el caso de uso se ejecutó, por ejemplo <el pedido está modificado y
es consistente>
o invariantes: éstas son siempre verdaderas -por ejemplo, un pedido debe tener siempre un número de cliente.
 Escenarios -descripciones secuenciales de los pasos que se toman para llevar a cabo el caso de uso. Pueden incluir
escenarios múltiples, para satisfacer circunstancias excepcionales y caminos de proceso alternativos
 Diagramas de escenarios -diagramas de secuencia para describir el flujo de trabajo- similar al punto 4 pero descrito
gráficamente.
 Atributos adicionales como fase de implementación, número de versión, rango de complejidad, estereotipo y estado

Actores
Un actor es un usuario del sistema. Incluye usuarios humanos y otros sistemas computarizados. Un actor usa un caso de uso
para desempeñar alguna porción de trabajo que es de valor para el negocio. El conjunto de casos de uso al que un actor
tiene acceso define su rol global en el sistema y el alcance de su acción.

Relaciones de Inclusión y Extensión entre Casos de Uso

Un Caso de Uso puede incluir la funcionalidad de otro como parte de su procesamiento normal. Generalmente se asume que
los casos de uso incluidos se llamarán cada vez que se ejecute el camino base. Un ejemplo puede ser listar un conjunto de
órdenes de clientes de las cuáles poder elegir antes de modificar una orden seleccionada; en este caso, el Caso de Uso
<listar órdenes> se puede incluir en el Caso de Uso <modificar orden> cada vez que éste se ejecute.
Un Caso de Uso puede ser incluido por uno o más casos de uso, ayudando así a reducir la duplicación de funcionalidad al
factorizar el comportamiento común en los casos de uso que se reutilizan muchas veces.
Un Caso de Uso puede extender el comportamiento de otro Caso de Uso; típicamente cuando ocurren situaciones
excepcionales. Por ejemplo, si antes de modificar un tipo particular de orden de cliente, un usuario debe obtener la
aprobación de alguna autoridad superior, entonces el Caso de Uso <obtener aprobación> puede extender opcionalmente el
Caso de Uso normal <modificar orden>.

Diagrama de Secuencia
El UML provee un medio gráfico para representar la interacción entre los objetos a lo largo del tiempo en los diagramas de
secuencia. Éstos muestran típicamente a un usuario o a un actor y los objetos y componentes con los que interactúen
durante la ejecución de un Caso de Uso. Un diagrama de secuencia representa típicamente un único escenario de Caso de
Uso o flujo de eventos.
Los diagramas son una vía excelente para documentar los escenarios de uso, para capturar los objetos necesarios de manera
temprana en el análisis y para verificar el uso de los objetos más tarde en el diseño. Los diagramas de secuencia muestran el
flujo de mensajes de un objeto a otro y, como tales, representan los métodos y los eventos soportados por un/a
objeto/clase.
El diagrama ilustrado abajo muestra un ejemplo de un diagrama de secuencia, con el usuario o actor a la izquierda iniciando
un flujo de eventos y mensajes que corresponden al escenario del caso de uso. Los mensajes que pasan entre objetos se
convertirán en operaciones de clases en el modelo final.

Diagrama de Implementación
Un Caso de Uso es una descripción formal de la funcionalidad que el sistema tendrá cuando se construya. Un diagrama de
implementación se asocia típicamente con un caso de uso para documentar qué elementos de diseño (por ejemplo,
componentes y clases) implementará la funcionalidad del Caso de Uso en el nuevo sistema. Esto provee un alto grado de
trazabilidad al diseñador, al cliente y al equipo que construirá el sistema. La lista de casos de uso a los que se asocia un
componente o una clase documenta la funcionalidad mínima que debe ser implementada por el componente.
El ejemplo de arriba muestra que el caso de uso "Acceso" implementa el requisito formal "1.01 Acceder al sitio web".
También establece que el componente de lógica de negocios y el componente de páginas ASP implementan alguna parte o
toda la funcionalidad de "Acceso". Un refinamiento adicional es mostrar la pantalla de "Acceso" (una página web) como una
implementación de su interfaz. Estos enlaces de implementación o realización definen la trazabilidad desde los requisitos
formales, a través de casos de uso, a componentes y pantallas.

16 El Modelo Dinámico

El modelo dinámico se usa para expresar y modelar el comportamiento del sistema a lo largo del tiempo. Incluye soporte
para diagramas de actividades, diagramas de estados, diagramas de secuencia y extensiones incluyendo modelado de
proceso de negocio.
Diagramas de secuencia
Los diagramas de secuencia se usan para mostrar la interacción entre los usuarios, las pantallas y las instancias de los
objetos en el sistema. Proveen un mapa secuencial del paso de los mensajes entre los objetos a lo largo del tiempo.
Frecuentemente, estos diagramas se ubican bajo los casos de uso o los componentes en el modelo para ilustrar un escenario
-cómo interactúa un usuario con el sistema y qué sucede internamente para que el trabajo se lleve a cabo-. Muchas veces,
los objetos se representan utilizando íconos especialmente estereotipados, como en el ejemplo de abajo. El objeto etiquetado
"PantallaDeIngreso" (Login Screen) se muestra empleando el ícono de interfaz. El objeto etiquetado
"AdministradorDeSeguridad" (SecurityManager) se muestra usando el ícono controlador. El objeto etiquetado "Usuarios"
(Users) se muestra usando el ícono entidad.
Diagramas de actividad
Los diagramas de actividad se usan para mostrar cómo se construyen los diferentes flujos de trabajo o los procesos dentro
de un sistema, cómo se inician, los variados caminos alternativos que se pueden tomar desde el inicio hasta el fin. También
pueden ilustrar dónde puede ocurrir procesamiento en paralelo durante la ejecución de algunas actividades.
Modelo de Procesos
Un modelo de procesos es una extensión del UML de un diagrama de actividades usado para un modelo de procesos de
negocios - este diagrama muestra que metas tiene el modelo, las entradas, salidas, eventos e información que se encuentran
involucradas en el proceso.
 17 El Modelo Lógico

Un modelo lógico es una vista estática de los objetos y las clases que cubren el espacio de análisis y diseño. Típicamente, un
modelo de dominio es una vista más pobre, de alto nivel de los objetos de negocio y de las entidades, mientras que el
modelo de clases es un modelo más riguroso y enfocado al diseño. Esta discusión describe principalmente el modelo de
clases.
El Modelo de Clases
Una clase es un elemento estándar del UML, que se usa para especificar el patrón del que se producirán los objetos en
tiempo de ejecución. Una clase es una especificación; un objeto es una instancia de una clase. Las clases se pueden heredar
de otras clases (es decir, heredan todo el comportamiento y el estado de sus padres y agregan nueva funcionalidad propia),
pueden tener otras clases como atributos, pueden delegar sus responsabilidades a otras clases e implementar interfaces
abstractas.
El modelo de clases está en el núcleo del desarrollo y del diseño orientados a objetos; expresa el estado persistente y el
comportamiento del sistema. Una clase encapsula el estado (los atributos) y ofrece los servicios para manipularlo (el
comportamiento). Un buen diseño orientado a objetos limita el acceso directo a los atributos de la clase y ofrece los servicios
que manipulan a solicitud del solicitante. Este ocultamiento de los datos y exposición de los servicios asegura que las
modificaciones de los datos se realizan sólo en un lugar y de acuerdo con reglas específicas; para grandes sistemas la
cantidad de código que tiene acceso directo a los elementos de datos en muchos sitios es extremadamente alto.
Las clases se representan usando la siguiente notación:

Observe que la clase tiene tres áreas diferentes:

1. El nombre de la clase (y el estereotipo, si corresponde)
 2. El área de los atributos (es decir los elementos de datos internos)
3. El comportamiento; privado y público
Los atributos y los métodos pueden ser marcados como:
- Privados (private), indicando que no son visibles para los solicitantes fuera de la clase
- Protegidos (protected), son visibles sólo para las clases hijas
- Públicos (public), son visibles para todos.
La herencia mostrada a continuación consiste en: una clase abstracta en este caso, es el padre de dos clases hijos, las cuales
heredan las características y extienden sus comportamientos.

Las clases se pueden agrupar en unidades lógicas o paquetes. Ellos juntan elementos relacionados entre sí. El diagrama
siguiente ilustra esto.

18 El Modelo de Componentes

Este artículo describe cómo modelar los componentes de software y hardware en UML. El modelo de componentes ilustra los
componentes de software que se usarán para construir el sistema. Se pueden construir a partir del modelo de clases y
escribir desde cero para el nuevo sistema o se pueden importar de otros proyectos y de productos de terceros. Los
componentes son agregaciones de alto nivel de las piezas de software más pequeñas y proveen un enfoque de construcción
de bloques de “caja negra” para la elaboración de software.
Notación de Componentes
Un componente puede ser algo como un control Actives; tanto un componente de la interfaz de usuario como un servidor de
reglas de negocio. Los componentes se representan gráficamente como muestra la figura siguiente:
El diagrama de componentes
El diagrama de componentes muestra la relación entre componentes de software, sus dependencias, su comunicación su
ubicación y otras condiciones.
Interfaces
Los componentes también pueden exponer las interfaces. Estas son los puntos visibles de entrada o los servicios que un
componente está ofreciendo y dejando disponibles a otros componentes de software y clases. Típicamente, un componente
está compuesto por numerosas clases y paquetes de clases internos. También se puede crear a partir de una colección de
componentes más pequeños.

Componentes y Nodos
Un diagrama de despliegue muestra el despliegue físico del sistema en un ambiente de producción (o de prueba). Muestra
dónde se ubican los componentes, en qué servidores, máquinas o hardware. Puede representar los enlaces de redes, el
ancho de banda de la LAN, etc.
Requisitos
Los componentes pueden tener requisitos adjuntos para indicar sus obligaciones contractuales; esto es, qué servicios
proveen en el modelo. Los requisitos ayudan a documentar el comportamiento funcional de los elementos de software.
Restricciones
Los componentes pueden restricciones asignadas que indican el entorno en el que operan. Las pre-condiciones especifican lo
que debe ser verdadero antes de que un componente pueda realizar alguna función; las post-condiciones indican lo que debe
ser verdadero después de que un componente haya realizado algún trabajo y los invariantes especifican lo que debe
permanecer verdadero durante la vida del componente.
Escenarios
Los escenarios son descripciones textuales y procedimentales de las acciones de un objeto a lo largo del tiempo y describen
la forma en la que un componente trabaja. Se pueden crear múltiples escenarios para describir tanto el camino básico (una
ejecución perfecta) como las excepciones, errores y otras condiciones.
Trazabilidad
Puede indicar la trazabilidad por medio de vínculos de realización. Un componente puede implementar otro elemento del
modelo (por ejemplo un caso de uso) o un componente puede ser implementado por otro elemento (por ejemplo un paquete
de clases). Al emplear las relaciones de realización desde y hacia los componentes, se pueden seguir las dependencias entre
los elementos del modelo y la trazabilidad desde los requisitos iniciales hasta la implementación final.
Un ejemplo
El ejemplo siguiente muestra cómo se pueden relacionar los componentes para proveer una vista conceptual/lógica de la
construcción de un sistema. Este ejemplo representa los elementos del servidor y la seguridad de una tienda de libros en
línea. Se incluyen elementos tales como el servidor WEB, el firewall, las páginas ASP, etc.
Componentes del servidor
Este diagrama ilustra la organización de los componentes del lado del servidor principal que se requerirá construir para una
tienda de libros en línea. Estos componentes son una mezcla de los ítems construidos a medida y adquiridos que se
ensamblarán para proveer la funcionalidad requerida.
Componentes de seguridad
El diagrama de componentes de la seguridad muestra cómo trabaja en conjunto el software de seguridad, tal como la
Autoridad Certificadora (Certificate Authority), el navegador (Browser), el servidor WEB y otros elementos del modelo para
asegurar la provisión de la seguridad en el sistema propuesto.
 19 El Modelo Físico

El Modelo Físico/de Despliegue provee un modelo detallado de la forma en la que los componentes se desplegarán a lo largo
de la infraestructura del sistema. Detalla las capacidades de red, las especificaciones del servidor, los requisitos de hardware
y otra información relacionada al despliegue del sistema propuesto.
Vista de Despliegue
MF01: Modelo Físico
El modelo físico muestra dónde y cómo se desplegarán los componentes. Es un mapa específico de la instalación física del
sistema. Un diagrama de despliegue ilustra el despliegue físico del sistema en un ambiente de producción (o prueba).
Muestra dónde se ubicarán los componentes, en qué servidores, máquinas o hardware. Puede ilustrar vínculos de red, ancho
de banda de LAN, etc.
Se utiliza un nodo para identificar cualquier servidor, terminal de trabajo u otro hardware host que se utiliza para desplegar
componentes en el ambiente de producción. Usted también puede especificar los vínculos entre los nodos y asignarles
estereotipos (tales como TCP/IP) y requisitos. Los nodos también pueden tener documentados características de
performance, estándares mínimos de hardware, niveles de sistema operativo, etc. La pantalla de abajo ilustra las
propiedades comunes que puede establecer para un nodo.
MODELO DE PROCESO DE NEGOCIO

20 Modelando Procesos de Negocios

Una introducción a la terminología y a los íconos que se usan en el Modelo de Procesos de Negocio. Provee una introducción
rápida a los conceptos del Lenguaje de Modelado Unificado (UML) y a cómo éstos se aplican en el Modelo de Procesos de
Negocio de Enterprise Architect.
Un proceso de negocio:
1. Tiene un objetivo
2. Tiene entradas específicas
3. Tiene salidas especícicas
4. Emplea recursos
5. Tiene un número de actividades que se llevan a cabo en algún orden
6. Puede afectar más de uan unidad organizacional. Impacto organizacional horizontal
7. Crea valores de algún tipo para el cliente. El cliente puede ser interno o externo.
Modelo de Procesos
Proceso de Negocio:
Un proceso de negocio es una colección de actividades diseñadas para producir una salida específica para un cliente o
mercado particular. Implica un fuerte énfasis en 'cómo' se hace el trabajo en una organización, en contraposición al enfoque
en 'qué' de producto. Así, un proceso es un ordenamiento específico de actividades de trabajo a través del tiempo y del
espacio, con un comienzo, un fin, entradas y salidas claramente identificados: una estructura para la acción.
Conexiones
• Vínculo de provisión desde el objeto Información. Un vínculo de provisión indica que la información u objeto vinculado al
proceso no se utiliza en la fase de procesamiento. Por ejemplo, se pueden utilizar plantillas de órdenes una y otra vez
para proveer nuevas órdenes de un cierto estilo -las plantillas no se alteran ni se consumen como parte de la actividad-
• Vínculo de provisión desde el objeto Recurso. Un vínculo de entrada indica que el objeto o recurso adjunto se consume
durante el procedimiento del proceso. Como ejemplo, a medida que se procesan las órdenes de un cliente se completan y
firman y típicamente se utiliza sólo una vez por cada recurso único (orden).
• Vínculo de objetivo al objeto Objetivo. Un vínculo de objetivo indica que el objeto adjunto al proceso de negocio describe
su objetivo. Un objetivo es la justificación de negocio para desarrollar la actividad.
• Vínculo de flujo de estados al objeto Salida
• Vínculo de flujo de estados desde el evento Event. Un vínculo de flujo de estado indica que se pasa algún objeto al
proceso de negocio. Captura el paso de control a otra entidad o proceso, con el paso implícito del estado o de
información desde una actividad a otra.
Figura 1 : Flujo de Trabajo
Objetivo
Objetivo:
Un proceso de negocio tiene algún objetivo bien definido. Esta es la razón por la que la organización realiza este trabajo y se
debería definir en los términos de los beneficios que tiene para la organización como un todo y en la satisfacción de las
necesidades de negocio.
Conexiones
Vínculo de objetivo desde la actividad proceso de negocio. Un vínculo de objetivo indica que el objeto adjunto al proceso de
negocio describe su objetivo. Un objetivo es la justificación de negocio para el desarrollo de la actividad.
Información
Objetivo:
Los procesos de negocio utilizan información para personalizar o completar sus actividades. La información, a diferencia de
los recursos, no se consume en el proceso -más bien se utiliza como parte del proceso de transformación. La información
puede provenir de Fuentes externas, de clientes, de unidades organizacionales internas e incluso puede ser el producto de
otros procesos.
Conexiones
Vínculo de provisión a la actividad proceso de negocio. Un vínculo de provisión indica que la información u objeto vinculado al
proceso no se utiliza en la fase de procesamiento. Por ejemplo, se pueden utilizar plantillas de órdenes una y otra vez para
proveer nuevas órdenes de un cierto estilo -las plantillas no se alteran ni se consumen como parte de la actividad-.
Salida
Objetivo:
Un proceso de negocio producirá típicamente una o más salidas de valor para el negocio, tanto para uso interno como para
satisfacer requisitos externos. Una salida puede ser un objeto físico (tal como un informe o una factura), una transformación
de recursos crudos en un nuevo ordenamiento (una agenda diaria o calendario) o un resultado global de negocio tal como
completar una orden de cliente.
Una salida de un proceso de negocio puede alimentar otros procesos, tanto como un ítem que se solicita o como un
disparador para iniciar nuevas actividades.
Conexiones
Vínculo de flujo de estados desde la actividad Proceso de Negocio
Recurso
Objetivo:
Un recurso es una entrada a un proceso de negocio y, a diferencia de la información, típicamente se consume durante el
procesamiento. Por ejemplo, a medida que se lleva a cabo y se registran las novedades de cada servicio de tren diario, el
recurso servicio se 'usa' tantas veces como concierna al proceso de registrar las novedades del tren.
Conexiones
Vínculo de provisión a la actividad proceso de negocio. Un vínculo de provisión indica que el objeto o recurso adjunto se
consume durante el procesamiento del procedimiento. Como ejemplo, a medida que se procesan las órdenes de un cliente se
completan y firman y típicamente se utiliza sólo una vez por cada recurso único (orden).

MODELO PERSONALIZADO

21 Modelo Personalizado

El modelo personalizado proporciona extensiones a los objetos UML básicos a través de estereotipos para manejar el diseño
de la pantalla, las entidades y la recopilación de requisitos.
Personalizado
Figura 1: Descripción general
OM01: Modelos
personalizados Los modelos personalizados proporcionan algunas extensiones al modelo UML y permiten algunos
experimentos exploratorios y no rigurosos con elementos y diagramas de modelos.

Figura 1: Descripción general

OM01-A: Pantallas El
diseño de la pantalla se admite a través de un objeto de pantalla estereotipado y controles de UI. Utilice este modelo para
diseñar prototipos de sistemas de alto nivel.

Figura 1: Diseño de pantalla

Nueva pantalla de
pantalla:
Control de la interfaz de
usuario:
Control de la interfaz de
usuario:
OM01-B: Requisitos
Los requisitos del sistema pueden modelarse utilizando objetos UML estereotipados diseñados para capturar requisitos. Estos
pueden luego vincularse de nuevo a los casos de uso y los componentes en el sistema para ilustrar cómo se cumple un
requisito del sistema en particular.

Figura 1: Requisitos
Capacidad para gestionar clientes.
Requisito:
Posibilidad de recibir un pedido
Requisito:
Conexiones
realiza el enlace desde Usecase Use Case
El sistema debe estar disponible las 24 horas del día.
Requisito:
Basura

Figura 1: Basura
Entidad
Entidad: Posiblemente artículos no deseados

22 El Modelo Dinámico

El modelo dinámico se usa para expresar y modelar el comportamiento del sistema a lo largo del tiempo. Incluye soporte
para diagramas de actividades, diagramas de estados, diagramas de secuencia y extensiones incluyendo modelado de
proceso de negocio.
Diagramas de secuencia
Los diagramas de secuencia se usan para mostrar la interacción entre los usuarios, las pantallas y las instancias de los
objetos en el sistema. Proveen un mapa secuencial del paso de los mensajes entre los objetos a lo largo del tiempo.
Frecuentemente, estos diagramas se ubican bajo los casos de uso o los componentes en el modelo para ilustrar un escenario
-cómo interactúa un usuario con el sistema y qué sucede internamente para que el trabajo se lleve a cabo-. Muchas veces,
los objetos se representan utilizando íconos especialmente estereotipados, como en el ejemplo de abajo. El objeto etiquetado
"PantallaDeIngreso" (Login Screen) se muestra empleando el ícono de interfaz. El objeto etiquetado
"AdministradorDeSeguridad" (SecurityManager) se muestra usando el ícono controlador. El objeto etiquetado "Usuarios"
(Users) se muestra usando el ícono entidad.

Diagramas de actividad
Los diagramas de actividad se usan para mostrar cómo se construyen los diferentes flujos de trabajo o los procesos dentro
de un sistema, cómo se inician, los variados caminos alternativos que se pueden tomar desde el inicio hasta el fin. También
pueden ilustrar dónde puede ocurrir procesamiento en paralelo durante la ejecución de algunas actividades.
Modelo de Procesos
Un modelo de procesos es una extensión del UML de un diagrama de actividades usado para un modelo de procesos de
negocios - este diagrama muestra que metas tiene el modelo, las entradas, salidas, eventos e información que se encuentran
involucradas en el proceso.
 23 El Modelo Lógico

Un modelo lógico es una vista estática de los objetos y las clases que cubren el espacio de análisis y diseño. Típicamente, un
modelo de dominio es una vista más pobre, de alto nivel de los objetos de negocio y de las entidades, mientras que el
modelo de clases es un modelo más riguroso y enfocado al diseño. Esta discusión describe principalmente el modelo de
clases.
El Modelo de Clases
Una clase es un elemento estándar del UML, que se usa para especificar el patrón del que se producirán los objetos en
tiempo de ejecución. Una clase es una especificación; un objeto es una instancia de una clase. Las clases se pueden heredar
de otras clases (es decir, heredan todo el comportamiento y el estado de sus padres y agregan nueva funcionalidad propia),
pueden tener otras clases como atributos, pueden delegar sus responsabilidades a otras clases e implementar interfaces
abstractas.
El modelo de clases está en el núcleo del desarrollo y del diseño orientados a objetos; expresa el estado persistente y el
comportamiento del sistema. Una clase encapsula el estado (los atributos) y ofrece los servicios para manipularlo (el
comportamiento). Un buen diseño orientado a objetos limita el acceso directo a los atributos de la clase y ofrece los servicios
que manipulan a solicitud del solicitante. Este ocultamiento de los datos y exposición de los servicios asegura que las
modificaciones de los datos se realizan sólo en un lugar y de acuerdo con reglas específicas; para grandes sistemas la
cantidad de código que tiene acceso directo a los elementos de datos en muchos sitios es extremadamente alto.
Las clases se representan usando la siguiente notación:

Observe que la clase tiene tres áreas diferentes:

1. El nombre de la clase (y el estereotipo, si corresponde)
2. El área de los atributos (es decir los elementos de datos internos)
 3. El comportamiento; privado y público
Los atributos y los métodos pueden ser marcados como:
- Privados (private), indicando que no son visibles para los solicitantes fuera de la clase
- Protegidos (protected), son visibles sólo para las clases hijas
- Públicos (public), son visibles para todos.
La herencia mostrada a continuación consiste en: una clase abstracta en este caso, es el padre de dos clases hijos, las cuales
heredan las características y extienden sus comportamientos.

Las clases se pueden agrupar en unidades lógicas o paquetes. Ellos juntan elementos relacionados entre sí. El diagrama
siguiente ilustra esto.

24 El Modelo Físico

El Modelo Físico/de Despliegue provee un modelo detallado de la forma en la que los componentes se desplegarán a lo largo
de la infraestructura del sistema. Detalla las capacidades de red, las especificaciones del servidor, los requisitos de hardware
y otra información relacionada al despliegue del sistema propuesto.
Vista de Despliegue
MF01: Modelo Físico
El modelo físico muestra dónde y cómo se desplegarán los componentes. Es un mapa específico de la instalación física del
sistema. Un diagrama de despliegue ilustra el despliegue físico del sistema en un ambiente de producción (o prueba).
Muestra dónde se ubicarán los componentes, en qué servidores, máquinas o hardware. Puede ilustrar vínculos de red, ancho
de banda de LAN, etc.
Se utiliza un nodo para identificar cualquier servidor, terminal de trabajo u otro hardware host que se utiliza para desplegar
componentes en el ambiente de producción. Usted también puede especificar los vínculos entre los nodos y asignarles
estereotipos (tales como TCP/IP) y requisitos. Los nodos también pueden tener documentados características de
performance, estándares mínimos de hardware, niveles de sistema operativo, etc. La pantalla de abajo ilustra las
propiedades comunes que puede establecer para un nodo.
 25 Modelo de Caso de Uso

El modelo de casos de uso describe la funcionalidad propuesta del nuevo sistema. Un caso de uso representa una unidad
discreta de interacción entre un usuario (humano o máquina) y el sistema. Un Caso de Uso es una unidad simple de trabajo
significativo; por ejemplo, "Validarse en el sistema", "Registrarse en el sistema" y "Crear un pedido" son todos casos de uso.
Cada caso de uso tiene una descripción que describe la funcionalidad que se construirá en el sistema propuesto. Un caso de
uso puede "incluir" la funcionalidad de otro caso de uso o "extender" a otro caso de uso con su propio comportamiento.
 Una descripción de caso de uso generalmente incluirá:
 Comentarios generales y notas describiendo el caso de uso
 Requisitos -cosas que el caso de uso debe permitir hacer al usuario, tales como <capacidad para actualizar pedido>,
<capacidad para modificar pedido>, etc.
 Restricciones -reglas acerca de qué se puede y qué no se puede hacer-. Incluye:
o Pre-condiciones que deben ser verdaderas antes de que el caso de uso se ejecute, por ejemplo <crear pedido> debe
preceder a <modificar pedido>
o Post-condiciones que deben ser verdaderas una vez que el caso de uso se ejecutó, por ejemplo <el pedido está modificado y
es consistente>
o invariantes: éstas son siempre verdaderas -por ejemplo, un pedido debe tener siempre un número de cliente.
 Escenarios -descripciones secuenciales de los pasos que se toman para llevar a cabo el caso de uso. Pueden incluir
escenarios múltiples, para satisfacer circunstancias excepcionales y caminos de proceso alternativos
 Diagramas de escenarios -diagramas de secuencia para describir el flujo de trabajo- similar al punto 4 pero descrito
gráficamente.
 Atributos adicionales como fase de implementación, número de versión, rango de complejidad, estereotipo y estado

Actores
Un actor es un usuario del sistema. Incluye usuarios humanos y otros sistemas computarizados. Un actor usa un caso de uso
para desempeñar alguna porción de trabajo que es de valor para el negocio. El conjunto de casos de uso al que un actor
tiene acceso define su rol global en el sistema y el alcance de su acción.

Relaciones de Inclusión y Extensión entre Casos de Uso

Un Caso de Uso puede incluir la funcionalidad de otro como parte de su procesamiento normal. Generalmente se asume que
los casos de uso incluidos se llamarán cada vez que se ejecute el camino base. Un ejemplo puede ser listar un conjunto de
órdenes de clientes de las cuáles poder elegir antes de modificar una orden seleccionada; en este caso, el Caso de Uso
<listar órdenes> se puede incluir en el Caso de Uso <modificar orden> cada vez que éste se ejecute.
Un Caso de Uso puede ser incluido por uno o más casos de uso, ayudando así a reducir la duplicación de funcionalidad al
factorizar el comportamiento común en los casos de uso que se reutilizan muchas veces.
Un Caso de Uso puede extender el comportamiento de otro Caso de Uso; típicamente cuando ocurren situaciones
excepcionales. Por ejemplo, si antes de modificar un tipo particular de orden de cliente, un usuario debe obtener la
aprobación de alguna autoridad superior, entonces el Caso de Uso <obtener aprobación> puede extender opcionalmente el
Caso de Uso normal <modificar orden>.

Diagrama de Secuencia
El UML provee un medio gráfico para representar la interacción entre los objetos a lo largo del tiempo en los diagramas de
secuencia. Éstos muestran típicamente a un usuario o a un actor y los objetos y componentes con los que interactúen
durante la ejecución de un Caso de Uso. Un diagrama de secuencia representa típicamente un único escenario de Caso de
Uso o flujo de eventos.
Los diagramas son una vía excelente para documentar los escenarios de uso, para capturar los objetos necesarios de manera
temprana en el análisis y para verificar el uso de los objetos más tarde en el diseño. Los diagramas de secuencia muestran el
flujo de mensajes de un objeto a otro y, como tales, representan los métodos y los eventos soportados por un/a
objeto/clase.
El diagrama ilustrado abajo muestra un ejemplo de un diagrama de secuencia, con el usuario o actor a la izquierda iniciando
un flujo de eventos y mensajes que corresponden al escenario del caso de uso. Los mensajes que pasan entre objetos se
convertirán en operaciones de clases en el modelo final.

Diagrama de Implementación
Un Caso de Uso es una descripción formal de la funcionalidad que el sistema tendrá cuando se construya. Un diagrama de
implementación se asocia típicamente con un caso de uso para documentar qué elementos de diseño (por ejemplo,
componentes y clases) implementará la funcionalidad del Caso de Uso en el nuevo sistema. Esto provee un alto grado de
trazabilidad al diseñador, al cliente y al equipo que construirá el sistema. La lista de casos de uso a los que se asocia un
componente o una clase documenta la funcionalidad mínima que debe ser implementada por el componente.
El ejemplo de arriba muestra que el caso de uso "Acceso" implementa el requisito formal "1.01 Acceder al sitio web".
También establece que el componente de lógica de negocios y el componente de páginas ASP implementan alguna parte o
toda la funcionalidad de "Acceso". Un refinamiento adicional es mostrar la pantalla de "Acceso" (una página web) como una
implementación de su interfaz. Estos enlaces de implementación o realización definen la trazabilidad desde los requisitos
formales, a través de casos de uso, a componentes y pantallas.
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

26 Bibliografía
Libros recomendados: Hemos revisado varios libros dedicados a la superestructura del UML 2.0. Entre ellos el que
parece ser más destacable es: UML 2.0 in a Nutshell.

 “UML 2.0 in a Nutshell ” de Dan Pilone y Neil Pitman

Excelente referencia para el trabajo diario. La introducción teórica es un poco superficial, debido a que el foco del libro es
la superestructura. El libro puede ser útil tanto a expertos UML como para quienes recién se inician.

 “UML 2 for Dummies” de Michael J. Chonoles y James A. Schardt

Libro de muy fácil lectura con una introducción teórica adecuada. El tratamiento de los temas podría ser un poco más
amplio, ya que el libro apunta a personas sin conocimiento del UML.

 “Fast Track UML 2.0” de Kendall Scott y Apress

Libro totalmente orientado a la superestructura. La introducción conceptual teórica a los nuevos aspectos del UML 2.0 es
bastante superficial y carece de un hilo conductor en cuanto a la organización de los temas. A pesar de esto, los distintos
diagramas están bien explicados

Otros libros recomendados de Orientación a Objetos: Para quien quiera una excelente introducción teórica al mundo
del diseño orientado objetos, dejamos estas recomendaciones:

 "Designing Object-Oriented? Software" de Rebecca Wirfs-Brock?, Brian Wilkerson y Lauren Wiener

Si le preguntan a alguien que trabaje con objetos sobre un libro de diseño orientado a objetos, seguramente les
recomiende este libro
  "Smalltalk Objects, and Design (Paperback)" de Chamond Liu

Otro excelente libro de diseño OO. Un poco más orientado a Smalltalk, pero conceptualmente completo.

 “Object-oriented Systems Analysis and Design Using UML” de Simon Bennett, Steve McRobb? y Ray Farmer.

Un libro que combina teoría de objetos y UML, con un enfoque un poco más práctico.

Herramientas A continuación, nombramos algunas herramientas que soportan UML 2.0. Dado que no todas tienen el
mismo nivel de conformidad, el nivel más alto a la fecha lo tiene Enterprise Architect.