UNIVERSIDAD POPULAR DE LA CHONTALPA

DIVISIÓN DE INGENIERÍA
ING. TECNOLOGÍA DE LA INFORMACIÓN

ALUMNA:
MIRIYAN GARCIA GUADARRAMA

MATERIA:
FUNDAMENTOS DE SISTEMAS Y DE LA INFORMACIÓN

SEMESTRE:
1°A

DOCENTE:
LORENA GOMEZ XEQUEB

TRABAJO:
LENGUAJE DE MODELADO UNIFICADO (UML)

TURNO:
MATUTINO
 INDICE

INTRODUCCIÓN…………………………………………………………………………………………… 1

4.1 Introducción al
UML…………………………………………………………………………………………… 2

4.2 Vistas
UML……………………………………………………………………………………………. 2

4.3 Diagramas
UML…………………………………………………………………………………………. 3

4.4 Diagramas de caso de

uso…………………………………………………………………………………. 6

4.5 Diagramas de
clases………………………………………………………………………………………… 7

4.6 Diagramas de
estado…………………………………………………………………………………………. 9

4.7 Diagramas de
secuencias…………………………………………………………………………………. 10

4.8 Diagramas de
colaboraciones…………………………………………………………………………… 11

4.9 Herramientas
UML…………………………………………………………………………………………
… 12

4.9.1 IBM Rational

Rhapsody………………………………………………………………………... 12

4.9.2 Microsoft
Visio……………………………………………………………………………………... 13

CONCLUCION……………………………………………………………………………. 13
 INTRODUCCIÓN
Hoy en día, UML ("Unified Modeling Language") está consolidado como el lenguaje estándar en
el análisis y diseño de sistemas de cómputo. Mediante UML es posible establecer la serie de
requerimientos y estructuras necesarias para plasmar un sistema de software previo al proceso
intensivo de escribir código.

En otros términos, así como en la construcción de un edificio se realizan planos previo a su

construcción, en Software se deben realizar diseños en UML previa codificación de un sistema,
ahora bien, aunque UML es un lenguaje, éste posee más características visuales que
programáticas, mismas que facilitan a integrantes de un equipo multidisciplinario participar e
intercomunicarse fácilmente, estos integrantes siendo los analistas, diseñadores, especialistas
de área y desde luego los programadores.

Hoy en día, entre los lenguajes orientados a objetos más utilizados se encuentran Java y C#,
además de otros más antiguos como C++ y SmallTalk, aunque el programar en todos estos
lenguajes requiere experiencia previa sobre la sintaxis y bloques específicos, el paradigma
empleado en todos ellos es el mismo: Objetos.

Antes de que UML se introdujera en el desarrollo de software, el campo de la programación

orientada a objetos (OOP) había crecido. Este estilo de programación se basa en el concepto
de que todo es un objeto: los bloques de construcción de un programa son objetos que
interactúan entre sí, los mensajes que se envían de un lado a otro entre los componentes
también constan de objetos. Cada objeto individual es un ejemplo de su clase superior. La
clase misma también actúa como un objeto y también determina el comportamiento de las
instancias de objetos que contiene. Los objetos consisten en datos y código. El objeto
organiza los datos en campos, también llamados atributos. El código determina su
procedimiento o método.

Desde finales de la década de 1980 hasta la de 1990 se desarrolló un gran número de

métodos y lenguajes para la representación de la programación orientada a objetos. El
resultado fue una confusa abundancia de métodos que apenas eran comparables entre sí.
Para unificarlos, los tres desarrolladores James Rumbaugh, Grady Booch e Ivar Jacobson
decidieron fusionar varios lenguajes existentes en un estándar común.

Con esta investigación se espera aprender más sobre el UML con la siguiente información
recolectada, también se espera conocer los diagramas de UML, cuales son y sus
características de cada uno, de igual manera de que forma nos pueden servir y ayudar en un
futuro, ya sea solo para recolectar u ordenar información o para una serie de pasos de un
programa el cual debemos de crear o escribir.

4. Lenguaje de Modelado Unificado

(UML)

4.1 Introducción al UML

El Lenguaje Unificado de Modelado (UML) desempeña un rol importante no solo en el
desarrollo de software, sino también en los sistemas que no tienen software en muchas
industrias, ya que es una forma de mostrar visualmente el comportamiento y la estructura de
un sistema o proceso. el UML ayuda a mostrar errores potenciales en las estructuras de
aplicaciones, el comportamiento del sistema y otros procesos empresariales.

¿Por qué UML?

El UML se implementó por primera vez en la década de los 90 gracias a tres ingenieros de
software: Grady Booch, Ivar Jacobson y James Rumbaugh. Ellos querían desarrollar una
forma menos caótica de representar el cada vez más complejo desarrollo de software, a la
vez que separaban la metodología del proceso. Hoy, el UML sigue siendo la indicación
estándar para los desarrolladores, así como para gestores de proyectos, propietarios de
negocios, empresarios tecnológicos y profesionales de distintos sectores.

¿Cuáles son las ventajas del UML?

• Simplifica las complejidades
• Mantiene abiertas las líneas de comunicación
• Automatiza la producción de software y los procesos
• Ayuda a resolver los problemas arquitectónicos constantes
• Aumenta la calidad del trabajo
• Reduce los costos y el tiempo de comercialización

4.2 Vistas UML

Es una técnica para la captura de requisitos potenciales de un nuevo sistema o una
actualización de software. Cada caso de uso proporciona uno o más escenarios que indican
cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un
objetivo específico. Normalmente, en los casos de usos se evita el empleo de jergas técnicas,
prefiriendo en su lugar un lenguaje más cercano al usuario final. Se enfoca el QUÉ y no
CÓMO.

• Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los
actores externos.
• Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la
estructura estática y la conducta dinámica del sistema.
• Vista de Componentes: Muestra la organización de los componentes de código.
• Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con
la comunicación y sincronización que están presentes en un sistema concurrente.
• Vista de Distribución: muestra la distribución del sistema en la arquitectura física con
computadoras y dispositivos llamados nodos.

2
4.3 Diagramas UML
Existen dos tipos principales de diagramas UML: diagramas de estructura y diagramas de
comportamiento (y dentro de esas categorías se encuentran varios otros). Estas variaciones
existen para representar los numerosos tipos de escenarios y diagramas que usan los
diferentes tipos de personas. Desde clientes y gestores de proyectos hasta autores técnicos,
diseñadores, analistas, codificadores y encargados de pruebas y control de calidad, cada rol
utilizará un diagrama específico que se adapte a sus necesidades. Eso significa que cada
disposición requiere un enfoque y nivel de
detalle diferente. El objetivo es que el UML exprese visualmente diagramas que sean fáciles
de entender para todos.

Diagramas estructurales
Los diagramas estructurales representan la estructura estática de un software o sistema, y
también muestran diferentes niveles de abstracción e implementación. Estos se usan para
ayudarlo a visualizar las diversas estructuras que componen un sistema, como una base de
datos o aplicación. Muestran la jerarquía de componentes o módulos y cómo se conectan e
interactúan entre sí. Estas herramientas ofrecen orientación y garantizan que todas las partes
de un sistema funcionen según lo previsto en relación con todas las demás partes.

Diagramas de comportamiento
El enfoque aquí está en los aspectos dinámicos del sistema de software o proceso. En estos
diagramas se muestra la funcionalidad de un sistema y se enfatiza lo que debe ocurrir en el
sistema que se está modelando.

1. Diagramas UML estructurales

• Diagrama de clases. Este diagrama, el más común en el desarrollo de software, se usa
para representar el diseño lógico y físico de un sistema, y muestra sus clases. Tiene
un aspecto similar al del diagrama de flujo porque las clases se representan con
cuadros. Este diagrama ofrece una imagen de las diferentes clases y la forma en la
que se interrelacionan, y cada clase posee tres compartimientos:
➢ Sección superior: nombre de clase
➢ Sección central: atributos de clase
➢ Sección inferior: métodos u operaciones de clase

• Diagrama de objetos. A menudo, este diagrama se usa como una forma de

comprobar la revisión de un diagrama de clases para fines de precisión. En otras
palabras, ¿funcionará en la práctica? Muestra los objetos de un sistema y sus
relaciones, y ofrece una mejor visión de los potenciales defectos de diseño que
necesitan reparación.

• Diagrama de componentes. También conocido como diagrama de flujo de

componentes, muestra agrupaciones lógicas de elementos y sus relaciones. En otras
palabras, ofrece una vista más simplificada de un sistema complejo al desglosarlo en
componentes más pequeños. Cada una de las piezas se muestra con una caja
rectangular, que tiene su nombre escrito dentro. Los conectores definen la relación/las
dependencias entre los diferentes componentes.

• Diagrama de estructura compuesta. Este lo utilizan rara vez las personas externas
al campo de desarrollo de software. ¿Por qué? Aunque es similar a un diagrama de

4
 clases, adopta un enfoque más profundo, que describe la estructura interna de
múltiples clases y muestra las interacciones entre ellas. Salvo que usted sea
desarrollador, la vista de nivel superior probablemente le entregará información
suficiente.

• Diagrama de despliegue. Este diagrama muestra los componentes de hardware

(nodos) y software (artefactos) y sus relaciones. Ofrece una representación visual
exacta del lugar donde se implementa cada componente de software.

• Diagrama de paquetes. Este se utiliza para representar las dependencias entre los
paquetes que componen un modelo. Su objetivo principal es mostrar la relación entre
los diversos componentes grandes que forman un sistema complejo.

• Diagrama de perfiles. Este es más similar a un lenguaje que a un diagrama. Un

diagrama de perfil ayuda a crear nuevas propiedades y semántica para los diagramas
UML al definir estereotipos personalizados, valores marcados y restricciones. Estos
perfiles le permiten personalizar un metamodelo de UML para diferentes plataformas
(por ejemplo, Java Platform, Enterprise Edition (Java EE) o Microsoft .NET
Framework) y dominios (por ejemplo, modelado de proceso empresarial, arquitectura
orientada a servicios, aplicaciones médicas y más).

2. Diagramas UML de comportamiento:

• Diagrama de actividades. Este representa un proceso paso a paso con un inicio y
final claros. Es un conjunto de actividades que deben realizarse para lograr un
objetivo. Muestra cómo cada actividad conduce a la siguiente y cómo todas estas se
conectan. Además del desarrollo de software, estas se pueden utilizar en casi
cualquier entorno empresarial. También se denominan asignación o modelado de
proceso empresarial.

• Diagrama de casos de uso. Este describe lo que un sistema hace las cosas, pero no
la forma en que las hace. Un caso de uso es un conjunto de eventos que ocurren
cuando un “actor” usa un sistema para completar un proceso. Un actor se define como
cualquier persona o cualquier cosa que interactúa con el sistema (persona,
organización o aplicación) desde fuera del sistema. Por lo tanto, un diagrama de casos
de uso describe visualmente ese conjunto de secuencias y representa los requisitos
funcionales del sistema.

• Diagrama de descripción general de interacción. Este diagrama, a menudo

complejo, es similar al diagrama de actividad, ya que ambos muestran una secuencia
paso a paso de las actividades. Sin embargo, un diagrama de descripción general de
interacción es un diagrama de actividad que se compone de diferentes diagramas de

5
 interacción. Usan la misma composición que un diagrama de actividad (nodos
iniciales, final, decisión, unión, fork y join) e incorpora elementos como la interacción,
el uso de la interacción, restricción de tiempo y restricción de la duración.

• Diagrama de tiempos. Cuando el tiempo ocupa un lugar central, se usa este

diagrama de UML. También conocido como un diagrama de secuencia o eventos, no
muestra la forma en que los objetos interactúan o cambian entre sí. Funcionalmente,
muestra cómo los objetos y actores se desempeñan en una línea de tiempo. El
enfoque aquí está en la duración de los eventos y los cambios que se producen en
función de las restricciones de duración. Las principales partes de un diagrama de
plazos incluye:
➢ Línea de vida: participante individual
➢ Línea de tiempo de estado: estados diferentes por los que pasa la línea de vida dentro
de una canalización
➢ Restricción de duración: tiempo necesario para que se cumpla una restricción
➢ Restricción de tiempo: un periodo en el que el participante debe completar una acción
➢ Destrucción: cuando finaliza la línea de vida de un objeto. Después de que se realiza
la destrucción en una línea de tiempo, no se produce otra ocurrencia.

• Diagrama de máquina de estados. También denominado gráfico de estados, este

diagrama se aplica cuando el comportamiento de un objeto es complejo y el detalle
es esencial. Ayuda a describir el comportamiento de un objeto (o a veces de un
operador) y la forma en que cambia según los eventos internos y externos.

• Diagrama de secuencia. Popular más allá de la comunidad de diseño, este

diagrama visualmente atractivo es bueno para mostrar todo tipo de procesos
empresariales. Simplemente revela la estructura de un sistema, mostrando la
secuencia de mensajes e interacciones entre actores y objetos cronológicamente.
Los diagramas de secuencia muestran iteraciones y ramificaciones simples. Es
favorable al realizar múltiples tareas.

• Diagrama de comunicación. Un diagrama de comunicación o colaboración es

similar a un diagrama de secuencia. Sin embargo, enfatiza la comunicación entre
objetos. Muestra la organización de los objetos que participan en una interacción y
presenta iteraciones y ramificaciones más complejas.

4.4 Diagrama de caso de uso.

El diagrama de casos de uso es una forma de diagrama de comportamiento en lenguaje de
modelado unificado (UML, del inglés Unified Modelling Language), con la que se representan

6
procesos empresariales, así como sistemas y procesos de programación orientada a objetos.
Por lo tanto, UML no es un lenguaje de programación, sino un lenguaje de modelado, es
decir, un método estandarizado para representar sistemas planificados o ya existentes. En
este diagrama, todos los objetos involucrados se estructuran y se relacionan entre sí.

Para garantizar que el diagrama de casos de uso sea comprensible para todo el mundo de
un vistazo, se utilizan elementos estandarizados para elaborarlo. En primer lugar, hay tres
elementos principales:

• Actor: tanto si es una persona, como un sistema, se representa con el dibujo de una
figura humana esquemática.
• Sistema: el sistema al que se refiere el caso de uso tiene forma de rectángulo.
• Caso de uso: se muestra como una elipse que suele incluir un texto describiendo
brevemente el proceso.

La relación entre estos elementos se representa con unas líneas de conexión llamadas
asociaciones. Una línea recta entre el actor y el caso de uso evidencia que el actor y el caso
de uso descrito en la elipse están relacionados. Una línea discontinua establece una relación
entre diferentes casos de uso. Como hay dos tipos diferentes de asociación entre casos de
uso, a las líneas se les añade una palabra clave, denominada “estereotipo” en UML, que se
pone entre dos pares de paréntesis angulares. La relación de dependencia entre los casos
de uso se representa con la punta de una flecha. Se distingue entre estos dos estereotipos:

• Asociación <>: el caso de uso en el cual comienza la línea discontinua se relaciona

con un segundo caso de uso señalado por la punta de la flecha.
• Asociación <>: el caso de uso en el cual comienza la línea discontinua puede
extenderse al caso de uso señalado por la punta de la flecha bajo ciertas condiciones,
que no han de cumplirse necesariamente en todos los casos.

4.5 Diagrama de clases.

Los diagramas de clases son un tipo de diagrama de estructura porque describen lo que
debe estar presente en el sistema que se está modelando. Sin importar tu nivel de
familiaridad con diagramas UML o diagramas de clases, nuestro software UML está diseñado
para ser simple y fácil de usar. El UML se estableció como un modelo estandarizado para
describir un enfoque de programación orientada a objetos (POO). Como las clases son los
componentes básicos de los objetos, los diagramas de clases son los componentes básicos
del UML. Los diversos componentes en un diagrama de clases pueden representar las clases
que se programarán en realidad, los objetos principales o la interacción entre clases y
objetos.

7
Componentes básicos de un diagrama de clases
El diagrama de clases estándar está compuesto por tres partes:
• Sección superior: Contiene el nombre de la clase. Esta sección siempre es
necesaria, ya sea que estés hablando del clasificador o de un objeto.
• Sección central: Contiene los atributos de la clase. Usa esta sección para describir
cualidades de la clase. Esto solo es necesario al describir una instancia específica de
una clase.
• Sección inferior: Incluye operaciones de clases (métodos). Esto está organizado en
un formato de lista. Cada operación requiere su propia línea. Las operaciones
describen cómo una clase puede interactuar con los datos.

Modificadores de acceso a miembros

Todas las clases poseen diferentes niveles de acceso en función del modificador de acceso
(visibilidad). A continuación, te mostramos los niveles de acceso con sus símbolos
correspondientes:
• Público (+) • Privado (-) • Protegido (#) • Paquete (~) • Derivado (/) • Estático
(subrayado)

Alcance de los miembros

Hay dos alcances para los miembros: clasificadores e instancias.
Los clasificadores son miembros estáticos, mientras que las instancias son las instancias
específicas de la clase. Si estás familiarizado con POO, esto no es nada nuevo.

Componentes adicionales del diagrama de clases

En función del contexto, las clases de un diagrama de clases pueden representar los objetos
principales, las interacciones en la aplicación o las clases que se programarán. Para
responder la pregunta "¿Qué es un diagrama de clases en UML?" , primero deberías
comprender su composición básica.

• Clases: Una plantilla para crear objetos e implementar un comportamiento en un

sistema. En UML, una clase representa un objeto o un conjunto de objetos que
comparte una estructura y un comportamiento comunes. Se representan con un
rectángulo que incluye filas del nombre de la clase, sus atributos y sus operaciones. Al
dibujar una clase en un diagrama de clases, solo se debe cumplimentar la fila
superior. Las otras son opcionales y se usan si deseas agregar más detalles.
• Nombre: La primera fila en una figura de clase.
• Atributos: La segunda fila en una figura de clase. Cada atributo de una clase está
ubicado en una línea separada.

8
 • Métodos: La tercera fila en una figura de clase. También conocidos como
"operaciones", los métodos se organizan en un formato de lista donde cada operación
posee su propia línea.
• Señales: Símbolos que representan comunicaciones unidireccionales y asincrónicas
entre objetos activos.
• Tipos de datos: Clasificadores que definen valores de datos. Los tipos de datos
pueden modelar tanto enumeraciones como tipos primitivos.
• Paquetes: Figuras diseñadas para organizar clasificadores relacionados en un
diagrama. Se simbolizan con una figura de un gran rectángulo con pestañas.
• Interfaces: Una recopilación de firmas de operaciones o de definiciones de atributo
que define un conjunto uniforme de comportamientos. Las interfaces son similares a
una clase, excepto
por que una clase puede tener una instancia de su tipo, y una interfaz debe poseer,
como mínimo, una clase para implementarla.
• Enumeraciones: Representaciones de tipos de datos definidos por el usuario. Una
enumeración incluye grupos de identificadores que representan valores de la
enumeración.
• Objetos: Instancias de una clase o clases. Los objetos se pueden agregar a un
diagrama de clases para representar instancias prototípicas o concretas.
• Artefactos: Elementos modelo que representan las entidades concretas de un
sistema de software, como documentos, bases de datos, archivos ejecutables,
componentes de software y más.

4.6 Diagrama de estado.

Los diagramas de estado representan principalmente estados y transiciones. Los estados se
representan con rectángulos de esquinas redondeadas que se etiquetan con el nombre del
estado. Las transiciones se marcan con flechas que fluyen de un estado a otro, mostrando
cómo cambian los estados.

Aplicaciones de los diagramas de estado

De forma similar a la mayoría de los diagramas UML, los diagramas de estado tienen
diferentes usos. Las aplicaciones principales son las siguientes:

• Representar objetos basados en eventos en un sistema reactivo.

• Ilustrar escenarios de casos de uso en un contexto de negocios.
• Describir cómo se mueve un objeto a través de diversos estados a lo largo de su
existencia.
• Mostrar el comportamiento general de una máquina de estados o el comportamiento
de un conjunto relacionado de máquinas de estados.

9
Símbolos y componentes para diagramas de estados
Puedes incluir muchas figuras diferentes en un diagrama de estados, particularmente si
eliges combinarlo con otro diagrama. Esta lista resume las figuras más comunes que puedes
encontrar.

Estado compuesto
Un estado que contiene subestados anidados. Ve el ejemplo siguiente de diagrama de
estados de universidad. “Inscripción” es el estado compuesto en este ejemplo porque
comprende diversos subestados en el proceso. Pseudoestado de opción
Un símbolo de diamante que indica una condición dinámica con resultados potenciales
ramificados.
Evento
Una instancia que activa una transición, etiquetada arriba de la flecha de transición aplicable.
En este caso, "fin de clases" es el evento que activa el final del estado “Siendo instruidos” y el
inicio del estado “Exámenes finales”.
Punto de salida
El punto en el cual un objeto escapa el estado compuesto o máquina de estados, el cual se
indica por medio de un círculo cruzado con una X. El punto de salida generalmente se usa si
el proceso no está completado, pero tiene que ser escapado por algún error u otro problema.
Primer estado
Un marcador para el primer estado en el proceso, que se muestra mediante un círculo oscuro
con una flecha de transición. Protección
Una condición booleana que permite o detiene una transición. Se escribe arriba de la
flecha de transición. Estado
Un rectángulo de esquinas redondeadas que indica la naturaleza actual de un objeto.
Subestado
Un estado contenido dentro de la región de un estado compuesto. En el diagrama de máquina
de estados de universidad mostrado a continuación, “Abierto para inscripción” es un subestado
en el estado compuesto más grande de “Inscripción”.
Terminador
Un círculo con un punto en el interior que indica que un proceso está terminado.
Transición
Una flecha que corre de un estado a otro, que indica un estado cambiante.
Comportamiento transicional
Un comportamiento que resulta cuando un estado pasa por una transición. Se escribe
arriba de la flecha de transición. Disparador
Un tipo de mensaje que mueve activamente un objeto de estado en estado. Se escribe arriba
de la flecha de transición. En este ejemplo, “Problema con la reservación” es el disparador
que enviaría a la persona a la agencia de viajes del aeropuerto en lugar de al siguiente paso
en el proceso.

10
4.7 Diagrama de secuencia.
Dentro de los diagramas de comportamiento en UML que permiten enfatizar las interacciones
entre los objetos se encuentran los diagramas de secuencias, este describe el
comportamiento del sistema y las operaciones que se realizan representando los objetos y
los mensajes que se intercambian, ya que en un sistema real y funcional los objetos
interactúan entre sí, y tales iteraciones suceden con el tiempo que se asigna, es decir que el
diagrama de secuencias de UML es una mecánica de interacción en base a los tiempos.
Un diagrama de secuencias muestra la interacción de un conjunto de objetos de una
aplicación a través del tiempo, en el cual se indicarán los módulos o clases que formaran
parte del programa y las llamadas que se hacen cada uno de ellos para realizar una tarea
determinada, por esta razón permite observar la perspectiva cronológica de las interacciones.

Elementos de un diagrama de secuencias Rol de la Clase

El rol de la clase describe la manera en que un objeto se va a comportar en el contexto.
No se listan los atributos del objeto. Activación
Los cuadros de activación representan el tiempo que un objeto necesita para completar una
tarea.
Mensajes
Los mensajes son flechas que representan comunicaciones entre objetos.
Las medias flechas representan mensajes asincrónicos.
Los mensajes asincrónicos son enviados desde un objeto que no va a esperar una respuesta
del receptor para continuar con sus tareas.
Líneas de Vida
Las líneas de vida son verticales y en línea de puntos, ellas indican la presencia del objeto
durante el tiempo.
Destrucción de Objetos
Los objetos pueden ser eliminados tempranamente usando una flecha etiquetada
“<<destruir>>” que apunta a una X. Loops
Una repetición o loop en un diagrama de secuencias, es representado como un rectángulo.
La condición para abandonar el loop se coloca en la parte inferior entre corchetes [].

4.8 Diagrama de colaboraciones.

El Diagrama de Colaboración presenta una alternativa al diagrama de secuencia para
modelar interacciones entre objetos en el sistema. Mientras que el diagrama de secuencia se
centra en la secuencia cronológica del escenario que estamos modelando, el diagrama de
colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario.
Los objetos se conectan por medio de enlaces, cada enlace representa una instancia de una
asociación entre las clases implicadas. El enlace muestra los mensajes enviados entre los

11
objetos, el tipo de mensaje (sincrónico, asincrónico, simple, blanking, y 'time-out'), y la
visibilidad de un objeto con respecto a los otros.

Un uso de un diagrama de colaboración es mostrar la implementación de una operación. La

comunicación muestra los parámetros y las variables locales de la operación, así como
asociaciones más permanentes. Cuando se implementa el comportamiento, la secuencia de
los mensajes corresponde a la estructura de llamadas anidadas y el paso de señales del
programa.
Un diagrama de secuencia muestra secuencias en el tiempo como dimensión geométrica,
pero las relaciones son implícitas. Un diagrama de comunicación muestra relaciones entre
roles geométricamente y relaciona los mensajes con las relaciones, pero las secuencias
temporales están menos claras.

Es útil marcar los objetos en cuatro grupos: los que existen con la interacción entera; los
creados durante la interacción (restricción {new}); los destruidos durante la interacción
(restricción {destroyed}); y los que se crean y se destruyen durante la interacción (restricción
{transient}). Aunque las comunicaciones muestran directamente la implementación de una
operación, pueden también mostrar la realización de una clase entera. En este uso, muestran
el contexto necesario para implementar todas las operaciones de una clase. Esto permite que
el modelador vea los roles múltiples que los objetos pueden desempeñar en varias
operaciones.

4.9 Herramientas UML

l UML, o Lenguaje de Modelado Unificado, abstrae y visualiza sistemas de la programación
orientada a objetos. El lenguaje de modelado es, por lo tanto, una herramienta práctica para
los desarrolladores de programas y sistemas. Por un lado, permite crear fotocalcos claros
para proyectos de software, y por otro, presentar sistemas de programación complejos de
forma comprensible para las personas que no están familiarizadas con la temática. Por
ejemplo, si deseas presentar un proyecto de software de la aplicación de la empresa al
responsable de marketing, por medio de un diagrama UML puedes ofrecer una visión general
de las características más importantes de la aplicación.
Por supuesto, los diagramas UML no se preparan con un programa como Paint, sino que son
las herramientas UML las que te ayudan a utilizar el lenguaje de modelado. Pero encontrar la
herramienta adecuada no es tan fácil, ya que, aunque existen innumerables proveedores de
programas UML en la red, no todos ofrecen las mismas funciones. Algunas herramientas
requieren una capacidad de memoria menor y ofrecen pocas funciones; otras pueden
mapear cualquier tipo de diagrama y exportarlo a diferentes lenguajes de programación o
importar un modelo desde un código existente. En contrapartida, muchos de estos programas
no ofrecen ninguna función para intercambiar información sobre el proyecto dentro de un
equipo.

12
 4.9.1 IBN Rational Rhapsody.

Herramienta Tipo Plataforma Lenguajes y Trabajo en Versiones Adecuado

Precio UML formatos de equipo de UML para programación
integrado compatibles
compatibles
IBM Entorno de Multiplataforma Java EE, C+ Con plugin ¿? Modular, A
Rational desarrollo +, IDE consultar
Rhapsody gráfico para C#, EJB, totalmente
el desarrollo WSDL, XSD, integrable
y validación CORBA IDL,
de software SQL, .NET
basado en
modelos

4.9.2 Microsoft Visio.

Herramienta Tipo Plataforma Lenguajes y Trabajo Versiones Adecuado

Precio UML formatos de en de UML para programación equipo
compatibles compatibles integrado
Microsoft Software Windows, C++, C#, ✔ UML 2.0 y + Visualización Suscripción
Visio propietario navegador, VSDX, VSDM 2.5 de grandes asequible o
de gráficos app para proyectos pago único
vectoriales iPad, relativamente
y gráficos máquina alto
virtual

CONCLUSIONES
Ya sea que haya sido pensado primero o haya crecido orgánicamente, el código que
escribimos siempre tiene un diseño. Por lo cual, cuando vayamos a trabajar en un código
grande o queramos colaborar con otras personas, es importante tener al menos algún
entendimiento común respecto al diseño, para así evitar tener diferentes visiones respecto al
mismo trabajo.

Para ello, podemos elegir un o más diagramas UML dependiendo de lo que queramos poner
en énfasis. Estos diagramas se dividen en dos familias: estructurales y comportamentales.

13
Referencias
Ambler, S. (2005). The elements of UML 2.0 style. Cambridge University Press,
New York. De Lara, J. and Vangheluwe, H. (2002). AToM3
: A tool for
multi-formalism and meta-modelling.
Proceedings of the Fifth International Conference
on Fundamental
Approaches to Software Engineering, London (England). pp. 174-188. De
Lara, J.; Vangheluwe, H. and Alfonseca, M. (2003). Using meta-modelling and
graph-grammars to create modelling environments. Electronic Notes in
Theoretical Computer Science, 72(3): 36-50.
De Lara, J.; Guerra, E. and Vangheluwe, H. (2004). Metamodelling, graph transformation and
model checking for the analysis of hybrid systems. Lecture Notes in Computer Science,
3062:292-298.
Díaz, I.; Moreno, L.; Fuentes, I. and Pastor, O. (2005). Integrating natural language techniques in
OO-method.
Lecture Notes in Computer Science, 3406:560-571.
Feijs, L.M.G. (2000). Natural language and message sequence chart representation of use
cases. Information and Software Technology, 42(9):633-647.
Fliedl, G.; Kop, Ch.; Mayerthaler, W., Mayr, H. C. and Winkler, Ch. (2002). The NIBA
workflow: From textual requirements specifications to UML-schemata. Proceedings of the
ICSSEA’2002 International Conference “Software & Systems Engineering and their
Applications”, Paris (France). Fowler, M. and Scott, K. (1997). UML distilled: applying the
standard object modeling language. Addison-Wesley Series Editors, Essex.
Fowler, M. and Scott, K. (2003). UML distilled: a brief guide to the standard object
modeling language, 3rd ed. Addison-Wesley Professional, Essex. Harmain, H. M. and
Gaizauskas, R. (2000). CM-Builder: an automated NL-based CASE tool. Proceedings of
the Fifteenth IEEE International Conference on Automated Software Engineering.
Grenoble (France). pp. 45-53. Li, L. (1999). A semi-automatic approach to translating use
cases to sequence diagrams. Technology of Object-Oriented Languages and Systems,
Jul.1999:184-193. Mich, L. (1996). NL-OOPS: From natural language to object oriented
requirements using the natural language processing system LOLITA. Journal of Natural
Language Engineering, 2(2):161-187.
Mich, L. and Garigliano, R. (2002). NL-OOPS: A requirements analysis tool based on natural
language processing. Proceedings of the 3rd International Conference on Data Mining.
Bologna (Italy). pp. 321-330.
Objetc Management Group (OMG). (2007). Unified modeling language specification. Version
2.1.1. http://www. omg.org/uml /20-09-08.
Overmyer, S.; Lavoie, B. and Rambow, O. (2001). Conceptual modeling analysis using LIDA.
Proceedings of the 23rd International Conference on Software Engineering, Toronto (Canada).
pp. 401-410. Pressman, R. (2005). Software Engineering: a practitioner’s approach, 6th ed.
McGraw-Hill, NewYork.

14
Rountev, A.; Kagan, S. and Sawin, J. (2005).
Coverage criteria for testing of object interactions in
sequence diagrams. Lecture Notes in Computer
Sciences 3442:282-297.
Torres, A. (1993). Modelamiento y
metamodelamiento de la incertidumbre en
problemas de ingeniería. Revista de Ingeniería
Universidad de los Andes 4:29-36.
Zapata, C. and Arango, F. (2005). Los modelos
verbales y su utilización en la elaboración de
esquemas conceptuales: una revisión crítica.
Revista EAFIT. 41(137):77-95.
Zapata, C.; Gelbukh, A. and Arango, F. (2006a). Pre-conceptual schemas: a conceptual-graph-
like knowledge representation for requirements elicitation. Lecture Notes in Computer
Sciences, 4293:27-37.

15