UML

LENGUAJE DE MODELACION UNIFICADO

INF 3751
TALLER DE DASARROLLO DE SOFTWARE
CONTENIDO.

Introducción.
¿Qué es UML?
UML, ¿Método o Lenguaje de Modelado?
Breve historia de UML.
Las versiones que existen de UML.
Fases del Desarrollo de un Sistema
Tipos de diagramas UML.
Diagramas estructurales.
Diagramas de comportamiento.
Relaciones.
Herramientas Software para construir diagramas UML.
¿QUÉ ES UML?

El Lenguaje Unificado de Modelado o UML (“Unified Modeling Language”) es un

lenguaje estandarizado de modelado. Está especialmente desarrollado para ayudar
a todos los intervinientes en el desarrollo y modelado de un sistema o un producto
software a describir, diseñar, especificar, visualizar, construir y documentar todos los
artefactos que lo componen, sirviéndose de varios tipos de diagramas. En esencia,
la documentación que se genera en un proyecto de desarrollo de software
(inicialmente), aunque su empleo en otros ámbitos es también recomendada, en
específico para el análisis de sistemas desde simples a complejos.

Estos diagramas contenidos en UML son la forma más común y más utilizada de
modelado de software. Modelar consiste en hacer un diseño previo de una aplicación
antes de proceder a su desarrollo e implementación. De forma similar que un
arquitecto dibuja planos sobre la casa que va a construir, un analista de software (u
otros perfiles) crea distintos diagramas UML que sirven de base para la posterior
construcción/mantenimiento del sistema. El modelado es la principal forma de
visualizar el diseño de una aplicación con la finalidad de compararla con los requisitos
antes de que el equipo de desarrollo comience a codificar

El modelado es vital en todo tipo de proyectos, pero cobra especialmente importancia

a medida que el proyecto crece de tamaño. Para que una aplicación funcione
correctamente, debe ser diseñada para permitir la escalabilidad, la s eguridad y la
ejecución. Utilizando diagramas UML se consigue visualizar y verificar los diseños de
sus sistemas de software antes de que la implementación del código haga que los
cambios sean difíciles y demasiado costosos.

Estos diagramas de UML son representaciones gráficas que muestran de forma

parcial un sistema de información, bien esté siendo desarrollado o ya lo haya sido.
Suelen estar acompañados de documentación que les sirve de apoyo, adoptando
esta, múltiples formas. Además, UML no excluye la posibilidad de mezclar diagramas,
algo que, de hecho, suele ser bastante común.

En todas las disciplinas de la Ingeniería se hace evidente la importancia de los

modelos ya que describen el aspecto y la conducta de "algo". Ese "algo" puede existir,
estar en un estado de desarrollo o estar, todavía, en un estado de planeación. Es en
este momento cuando los diseñadores del modelo deben investigar los
requerimientos del producto terminado y dichos requerimientos pueden incluir áreas
tales como funcionalidad, performance y confiabilidad. Además, a menudo, el modelo
es dividido en un número de vistas, cada una de las cuales describe un aspecto
específico del producto o sistema en construcción.
El modelado sirve no solamente para los grandes sistemas, aun en aplicaciones de
pequeño tamaño se obtienen beneficios de modelado, sin embargo es un hecho que
entre más grande y más complejo es el sistema, más importante es el papel de que
juega el modelado por una simple razón: "El hombre hace modelos de sistemas
complejos porque no puede entenderlos en su totalidad".

¿Por qué UML?

Los modelos o diagramas de UML ayudan a trabajar a un mayor nivel de abstracción.

Permite modelar cualquier tipo de aplicación corriendo en cualquier combinación de
hardware y software, sistema operativo, lenguaje de programación y red, es decir,
UML es independiente de la plataforma hardware sobre la que actúa el software. Su
flexibilidad permite modelar cualquier tipo de aplicación e, incluso, otros tipos de
proyecto que no son puramente software.

UML ofrece ese modelado utilizando diagramas y se denomina lenguaje por ser una
forma común de expresarse por todos los analistas, desarrolladores y usuarios. Está
desarrollado para ayudar a todos estos (y más) perfiles a especificar, visualizar,
construir y documentar todos los componentes de un proyecto. A pesar de que cada
diagrama UML en particular aporta su visión particular al modelado, el lenguaje en
su conjunto tiene algunas características que interesa resaltar:

• Mejores tiempos totales de desarrollo (de 50 % o más).

• Modelar sistemas (y no sólo de software) utilizando conceptos orientados a
objetos.
• Establecer conceptos y artefactos ejecutables, entendibles por todos los
participantes del equipo de desarrollo.
• Encaminar el desarrollo del escalamiento en sistemas complejos de misión
crítica.
• Crear un lenguaje de modelado utilizado tanto por humanos como por
máquinas.
• Mejor soporte a la planeación y al control de proyectos.
• Alta reutilización y minimización de costos.
UML, ¿MÉTODO O LENGUAJE DE MODELADO?

UML es un lenguaje para hacer modelos y es independiente de los métodos de

análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de
modelado. Un método es una manera explícita de estructurar el pensamiento y las
acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo
hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado
carece de estas instrucciones. Los métodos contienen modelos y esos modelos son
utilizados para describir algo y comunicar los resultados del uso del método.

Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado

consiste de vistas, diagramas, elementos de modelo -- los símbolos utilizados en los
modelos -- y un conjunto de mecanismos generales o reglas que indican cómo utilizar
los elementos. Las reglas son sintácticas, semánticas y pragmáticas.

UML

MODELO VISTAS
DIAGRAMAS SIMBOLOS REGLAS

Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no
es una gráfica, pero sí una abstracción que consiste en un número de diagramas y
todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las
vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para
el desarrollo. Las diferentes vistas que UML tiene son:

o Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la
perciben los actores externos.
o 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.
o Vista de Componentes: Muestra la organización de los componentes de código.
o 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.
o Vista de Distribución: muestra la distribución del sistema en la arquitectura
física con computadoras y dispositivos llamados nodos.
Diagramas: Los diagramas son las gráficas que describen el contenido de una vista.
UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer
todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de
estados, de secuencia, de colaboración, de actividad, de componentes y de
distribución.

Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son

los elementos de modelo que representan conceptos comunes orientados a objetos,
tales como clases, objetos y mensajes, y las relaciones entre estos conceptos
incluyendo la asociación, dependencia y generalización. Un elemento de modelo es
utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y
simbología.

Reglas o Mecanismos generales: Proveen comentarios extras, información o

semántica acerca del elemento de modelo; además proveen mecanismos de
extensión para adaptar o extender UML a un método o proceso específico,
organización o usuario.
BREVE HISTORIA DE UML.

Desde hace unos años, las tecnologías de la información y comunicación ya han

producido una enorme variedad de métodos y notaciones para llevar a cabo el
modelado. Existen métodos y anotaciones para el diseño, la estructura, el
procesamiento y el almacenamiento de información. De la misma manera también
podemos encontrar métodos para la planificación, modelado, implementación,
ensamblaje, prueba, documentación, ajuste, etc. de los sistemas. Entre los conceptos
que se utilizan existen algunos relativamente fundamentales y, debido a eso, se
expanden más allá del ámbito en el que fueron creados en un principio.

Desde la concepción de la tecnología de la información hasta finales de 1970, los

desarrolladores de software se tomaron el desarrollo del software como un arte. Pero
estos sistemas fueron poco a poco haciéndose más complejos y por esta razón el
mantenimiento y el desarrollo exigía otro tipo de visión, más allá del previamente
descrito. Este hecho dio lugar a la ya famosa crisis del software.

Esta crisis lleva al enfoque de ingeniería (ingeniería de software) y la programación

estructurada. Se desarrollaron métodos para la estructuración de sistemas y para los
procesos de diseño, desarrollo y mantenimiento. Los enfoques orientados a
procesos, por ejemplo, el método de salida de procesamiento de entrada de
jerarquía, enfatizaron la funcionalidad de los sistemas. Con este método, el sistema
total se divide en componentes más pequeños a través de la descomposición
funcional.

La crisis del software

Al mismo tiempo, se desarrollaron enfoques orientados a la estructura de datos, como

el método de Jackson, en el que la estructura del programa se deriva de la
visualización gráfica de las estructuras de datos.

En todos estos métodos y notaciones, dividimos el sistema en dos partes: una

sección de datos y una sección de procedimientos. Esto es claramente reconocible
en lenguajes de programación más antiguos, como COBOL. Los diagramas de flujo
de datos, los diagramas de estructura, los diagramas HIPO y los diagramas de
Jackson se utilizan para ilustrar el rango de funciones. Naturalmente, estos primeros
métodos enfatizaron el desarrollo de nuevos sistemas.

En la década de 1980, el análisis estructural clásico se desarrolló aún más. Los

desarrolladores generaron diagramas de relaciones de entidades para el modelado
de datos y redes de Petri para el modelado de procesos.
A medida que los sistemas se volvieron más complejos, ya no se podría diseñar cada
sistema “desde cero”. Las propiedades, como la mantenibilidad y la reutilización, se
hicieron cada vez más importantes. Se desarrollaron lenguajes de programación
orientados a objetos, y con ellos, los primeros lenguajes de modelado orientados a
objetos surgieron en los años 70 y 80. En la década de 1990, las primeras
publicaciones sobre análisis orientado a objetos y diseño orientado a objetos se
pusieron a disposición del público. A mediados de la década de 1990, ya existían
más de 50 métodos orientados a objetos, así como muchos formatos de diseño. Un
lenguaje de modelado unificado parecía indispensable.

A principios de la década de 1990, los métodos orientados a objetos de Grady Booch

y James Rumbaugh se utilizaron ampliamente. En octubre de 1994, Rational
Software Corporation (parte de IBM desde febrero de 2003) comenzó la creación de
un lenguaje de modelado unificado. Primero, acordaron una estandarización de la
notación (lenguaje), ya que esto parecía menos elaborado que la estandarización de
los métodos. Al hacerlo, integraron el Método Booch de Grady Booch, la Técnica de
modelado de objetos ( OMT ) de James Rumbaugh y la Ingeniería de software
orientada a objetos ( OOSE ), de Ivar Jacobsen, con elementos de otros métodos y
publicaron esta nueva notación bajo el nombre UML, versión 0.9 .

El objetivo no era formular una notación completamente nueva, sino adaptar,

expandir y simplificar los tipos de diagramas existentes y aceptados de varios
métodos orientados a objetos, como los diagramas de clase, los diagramas de casos
de uso de Jacobson o los diagramas de gráficos de estado de Harel. Los medios de
representación que se utilizaron en los métodos estructurados se aplicaron a UML.
Por lo tanto, los diagramas de actividad de UML están, por ejemplo, influenciados por
la composición de los diagramas de flujo de datos y las redes de Petri.

Lo que es sobresaliente y nuevo en UML no es su contenido, sino su estandarización

a un solo lenguaje unificado con un significado definido formalmente. Los creadores
originales de UML son 3: Jim Rumbaugh, Grady Booch e Ivar Jacobson.
LAS VERSIONES QUE EXISTEN DE UML.

Compañías conocidas, como IBM, Oracle, Microsoft, Digital, Hewlett-Packard y

Unisys se incluyeron en el desarrollo posterior de UML. En 1997, la versión 1.1 de
UML fue enviada y aprobada por la OMG . La versión 1.2 de UML, con adaptaciones
editoriales, se lanzó en 1998, seguida de la versión 1.3 un año despu és, y la versión
1.5 de UML en marzo de 2003. Los desarrolladores ya habían estado trabajando en
la versión 2.0 de UML desde el año 2000, La versión actual de UML es la 2.5.1 y fue
publicada en Junio de 2015. UML es gestionada y actualizada por la OMG (Object
Manabement Group).

Esta es la lista de versiones que han sido publicadas:

1.1 – Noviembre de 1997

1.3 – Marzo de 2000

1.4 – Septiembre de 2001

1.5 – Marzo de 2003

1.4.2 – Enero de 2005

2.0 – Octubre de 2005

2.1 – Abril de 2006

2.1.1 – Febrero de 2007

2.1.2 – Noviembre de 2007

2.2 – Febrero de 2009

2.3 – Mayo de 2010

2.4.1 – Agosto de 2011

2.5 – Junio de 2015

2.5.1 – Diciembre de 2017 (Última versión)

FASES DEL DESARROLLO DE UN SISTEMA

Las fases del desarrollo de sistemas que soporta UML son: Análisis de
requerimientos, Análisis, Diseño, Programación y Pruebas.

Análisis de
Pruebas Requisitos

Cada Iteración Genera

un producto
ejecutable y su
documentación con
UML

Programacion Análisis

Diseño

Análisis de Requerimientos

UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A
través del modelado de casos de uso, los actores externos que tienen interés en el
sistema son modelados con la funcionalidad que ellos requieren del sistema (los
casos de uso). Los actores y los casos de uso son modelados con relaciones y tienen
asociaciones entre ellos o éstas son divididas en jerarquías. Los actores y casos de
uso son descritos en un diagrama use-case. Cada usecase es descrito en texto y
especifica los requerimientos del cliente: lo que él (o ella) espera del sistema sin
considerar la funcionalidad que se implementará. Un análisis de requerimientos
puede ser realizado también para procesos de negocios, no solamente para sistemas
de software.

Análisis

La fase de análisis abarca las abstracciones primarias (clases y objetos) y

mecanismos que están presentes en el dominio del problema. Las clases que se
modelan son identificadas, con sus relaciones y descritas en un diagrama de clases.
Las colaboraciones entre las clases para ejecutar los casos de uso también se
consideran en esta fase a través de los modelos dinámicos en UML. Es importante
notar que sólo se consideran clases que están en el dominio del problema (conceptos
del mundo real) y todavía no se consideran clases que definen detalles y soluciones
en el sistema de software, tales como clases para interfaces de usuario, bases de
datos, comunicaciones, concurrencia, etc.

Diseño

En la fase de diseño, el resultado del análisis es expandido a una solución técnica.

Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de
usuario, manejo de bases de datos para almacenar objetos en una base de datos,
comunicaciones con otros sistemas, etc. Las clases de dominio del problema del
análisis son agregadas en esta fase. El diseño resulta en especificaciones detalladas
para la fase de programación.

Programación

En esta fase las clases del diseño son convertidas a código en un lenguaje de
programación orientado a objetos. Cuando se crean los modelos de análisis y diseño
en UML, lo más aconsejable es trasladar mentalmente esos modelos a código.

Pruebas

Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración,

pruebas de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan
a clases individuales o a un grupo de clases y son típicamente ejecutadas por el
programador. Las pruebas de integración integran componentes y clases en orden
para verificar que se ejecutan como se especificó. Las pruebas de sistema ven al
sistema como una "caja negra" y validan que el sistema tenga la funcionalidad final
que le usuario final espera. Las pruebas de aceptación conducidas por el cliente
verifican que el sistema satisface los requerimientos y son similares a las pruebas de
sistema.
TIPOS DE DIAGRAMAS UML.

Al día de hoy, en la versión 2.5.1 de UML, existen dos clasificaciones de diagramas:

Los diagramas estructurales y los diagramas de comportamiento. Todos los
diagramas UML están contenidos en esta clasificación.
DIAGRAMAS ESTRUCTURALES.
Los diagramas estructurales muestran la estructura estática del sistema y sus partes
en diferentes niveles de abstracción. Existen un total de siete tipos de diagramas de
estructura:

Diagrama de clases

Muestra la estructura del sistema, subsistema o componente utilizando clases con

sus características, restricciones y relaciones: asociaciones, generalizaciones,
dependencias, etc.

Diagrama de componentes

Muestra componentes y dependencias entre ellos. Este tipo de diagramas se utiliza

para el desarrollo basado en componentes (CDB), para describir sistemas con
arquitectura orientada a servicios (SOA).

Diagrama de despliegue

Muestra la arquitectura del sistema como despliegue (distribución) de artefactos de

software.

Diagrama de objetos

Un gráfico de instancias, incluyendo objetos y valores de datos. Un diagrama de

objeto estático es una instancia de un diagrama de clase; muestra una instantánea
del estado detallado de un sistema en un punto en el tiempo.

Diagrama de paquetes

Muestra los paquetes y las relaciones entre los paquetes.

Diagrama de perfiles

Diagrama UML auxiliar que permite definir estereotipos personalizados, valores

etiquetados y restricciones como un mecanismo de extensión ligero al estándar UML.
Los perfiles permiten adaptar el metamodelo UML para diferentes plataformas o
dominios.

Diagrama de estructura compuesta

Muestra la estructura interna (incluidas las partes y los conectores) de un

clasificador estructurado.
DIAGRAMAS DE COMPORTAMIENTO.

A diferencia de los diagramas estructurales, muestran como se comporta un sistema

de información de forma dinámica. Es decir, describe los cambios que sufre un
sistema a través del tiempo cuando está en ejecución. Hay un total de siete
diagramas de comportamiento, clasificados de la siguiente forma:

Diagrama de actividades

Muestra la secuencia y las condiciones para coordinar los comportamientos de nivel

inferior, en lugar de los clasificadores que poseen esos comportamientos. Estos son
comúnmente llamados modelos de flujo de control y flujo de objetos.

Diagrama de casos de uso

Describe un conjunto de acciones (casos de uso) que algunos sistemas o sistemas

(sujetos) deben o pueden realizar en colaboración con uno o más usuarios externos
del sistema (actores) para proporcionar algunos resultados observables y valiosos a
los actores u otros interesados del sistema(s).

Diagrama de máquina de estados

Se utiliza para modelar el comportamiento discreto a través de transiciones de

estados finitos. Además de expresar el comportamiento de una parte del sistema, las
máquinas de estado también se pueden usar para expresar el pro tocolo de uso de
parte de un sistema.

Diagramas de interacción.

Es un subconjunto de los diagramas de comportamiento. Comprende los siguientes

diagramas:

Diagrama de secuencia

Es el tipo más común de diagramas de interacción y se centra en el intercambio de

mensajes entre líneas de vida (objetos).

Diagrama de comunicación

Se enfoca en la interacción entre líneas de vida donde la arquitectura de la estructura

interna y cómo esto se corresponde con el paso del mensaje es fundamental. La
secuencia de mensajes se da a través de una numeración.
Diagrama de tiempos

Se centran en las condiciones que cambian dentro y entre las líneas de vida a lo largo
de un eje de tiempo lineal.

Diagrama global de interacciones

El diagrama global de interacciones brinda una descripción general del flujo de control
donde los nodos del flujo son interacciones o usos de interacción.
RELACIONES Y ARTEFACTOS.

Relaciones.

Cuando diferentes objetos trabajan en función a una meta o propósito y se logra por
medio de la colaboración entre las partes a través de las relaciones.

En pocas palabras se define como la conexión entre elementos. Para diferenciar las
distintas relaciones se utilizan una Simbología con base en varios tipos de líneas.

De los diferentes tipos de relaciones a las que más se les da importancias son: las
dependencias, las generalizaciones y asociaciones. También existe la relación de
realización.

Dependencias

Es una relación de significado entre dos elementos, donde cualquier cambio a un

elemento independiente, puede afectar el significado de otro elemento dependiente.

Las dependencias generalmente representan relaciones de uso que manifiestan que

un cambio en la especificación de un elemento puede afectar a otro que la utiliza,
pero no necesariamente a la inversa.

Las clases o paquetes utilizan en su mayoría en su contexto, para indicar que una
clase utiliza a otra como argumento en la asignatura de una operación.
Generalizacion

Esta hace referencia a la relación de una súper clase o clase padre con una subclase
o clase hija. La generalización significa que los objetos hijos se pueden emplear en
cualquier clase donde pueda aparecer el padre, pero no a la inversa. Es decir, el hijo
puede sustituir al padre, pero el padre no puede sustituir al hijo. Estas s on sus
características:

El hijo hereda atributos y operaciones del padre. El hijo puede agregar atributos y
operaciones. Puede tener operaciones polimórficas

La generalización se llama a veces relación “es-un-tipo-de”: un elemento (clase

Animal mamífero) es-un-tipo-de un elemento más general (clase Animal).
Asociaciones

Es una relación estructural que especifica que los objetos de un elemento están
conectados con los objetos de otro. Permitiendo a una asociación entre dos clases
se puede pasar de un objeto de una clase hasta un objeto de otra clase.

Podemos encontrar una característica especial entre las asociaciones y las

dependencias ya que estas pueden ser reflexivas.

La agregación es un tipo especial de asociación, que representa una relación

estructural entre todo y sus partes. Donde representa Una relación del tipo “Tienen -
un” ejemplo, Un AnimalAves “Tienen” Plumas.

Realización

Es una relación semántica entre clasificadores donde este especifica unas normas o
un reglamento con otro clasificador que garantiza que se cumplirá.

Se encuentran relaciones de realización: entre interfaces, clases y componentes que

las realizan y entre los casos de uso y las colaboraciones que los realizan.

Si confrontamos las relaciones de la dependencia, la generalización y la asociación

notamos que la realización es diferente a las otras relaciones mencionadas y así
poderla trabajar como un tipo aparte de relación. Pero semánticamente la realización
es una mezcla entre dependencia y generalización.
Estereotipos

Los estereotipos definen a extensiones de las metaclases. Siguiendo la

especificación UML, pertenecen a los perfiles. Si un estereotipo describe propiedades
de varias metaclases, solo puede describir las instancias de una en una mientras se
ejecuta. Entre las metaclases, el estereotipo siempre asume un papel determinado
porque nunca puede estar solo. Los estereotipos se modelan siempre en relación con
el clasificador al que amplía. La metaclase se conecta con el estereotipo modelando
una extensión (Extension).

Notación de estereotipos: definido por el usuario y estándar

Entidad, Frontera y Control son formas definidas por el usuario representando ciertos
estereotipos. En la notación estándar la etiqueta del estereotipo se escribe entre
cuñas (< >) sobre el nombre de la metaclase. Otra opción menos habitual pero
posible es substituir la etiqueta por un símbolo (a la derecha).

UML define algunos estereotipos de clase que amplían un diagrama de clases. Seis
son considerados estándar, pero hay tres que, sin ser estándar, se usan mucho, y
con los que puede implementarse el modelo “Model-View-Controller” (MVC) en UML.
Son estos:

Entidad: el estereotipo Entity define a una clase o a un objeto. Cada instancia

representa a una colección de datos, a menudo datos de sistema que se han de
guardar durante mucho tiempo. La entidad asume el rol del modelo del patrón MVC.
UML conoce este estereotipo, pero lo asigna por defecto a los diagramas de
componentes. En la especificación no se representa a esta habitual notación. La
entidad se modela como un círculo que descansa sobre una línea corta.
Frontera: la Frontera es un estereotipo para una clase o un objeto. Se c orresponde
aproximadamente con el elemento View del modelo MVC. La Frontera modela los
límites de tu sistema, p. ej., una interfaz de usuario. Suele representarse gráficamente
como un círculo de cuyo lado izquierdo sale una línea que acaba en una línea ver tical.

Control: el elemento de Control representa el Controller en MVC. Las clases o los

objetos con este estereotipo modelan elementos que determinan el comportamiento
del sistema o los flujos de control. La instancia de control se dibuja como un círculo
con una flecha encima de la línea.

Los tres estereotipos pueden dibujarse como clases. En los rectángulos se escribe el
nombre del estereotipo. Los modeladores aplican estas formas principalmente en
diagramas de secuencia. Lee nuestro artículo sobre diagramas de secuencia con
UML si quieres profundizar en los diagramas de entidad-frontera-control.

Artefactos.

En el Lenguaje Unificado de Modelado (UML), un artefacto es la especificación de un

componente físico de información que es usado o producido por un proceso de
desarrollo de software, o por el desarrollo y operación de un sistema.

Ejemplos de artefactos incluyen modelo de archivos, archivos fuentes, scripts,

archivos binarios ejecutables, una tabla en una base de datos, un development
deliverable, o un documento de procesamiento de texto, como un mensaje de correo
electrónico.

Desde UML 2.0, los artefactos son las entidades físicas que son desplegadas en
Nodos, Dispositivos y Ambientes de Ejecución. Otros elementos de UML, tales como
las clases y los componentes, son primero manifestados como artefactos, y las
instancias de dichos artefactos son luego desplegados. Los artefactos pueden
también estar compuestos por otros artefactos.
HERRAMIENTAS SW. PARA CONSTRUIR DIAGRMAS UML

A mas de 20 años después de su creación y estandarización, UML sigue siendo el

lenguaje de modelado por excelencia. Hoy en día existen ya cientos de herramientas
UML, es decir entornos de modelado que permitan dibujar diagramas siguiendo la
notación UML. Es, por lo tanto, imposible compararlas todas. En lugar de eso, se
presenta a continuación una selección de las herramientas UML mas empleadas y
mencionadas en el Internet.

Antes de empezar, un consejo para seleccionar una herramienta de modelado UML:

se deberá pensar muy bien cómo va a ser usada UML en el proceso de desarrollo.
No hay ninguna herramienta que sirva para todo. La qué sea buena en generación
de código a lo mejor no permite el modelado colaborativo o es demasiado estricta
para dibujar modelos informales en etapas iniciales del desarrollo. Por tanto valorar
anticipadamente el uso y propósitos será un buen criterio.

UML no es un lenguaje de programación visual, pero sus modelos pueden conectarse

directamente con una variedad de lenguajes, con la posibilidad de realizar trabajo del
tipo “Forward & reverse engineering”, Ingeniería de ida y vuelta; alguna herramientas
apoyan también este trabajo: “del diseño a la implementación”.

MagicDraw: Me encanta su usabilidad. Pero aún me gusta más su motor de

ejecución de modelos UML. NoMagic (la empresa detrás MagicDraw) ha sido
comprada por Dassault Systems. Es de prever que, como consecuencia, MagicDraw
siga mejorando en todo lo que se refiere a la ingeniería de sistemas donde este tipo
de simulaciones a partir de modelos es clave.

MagicDraw convierte diagramas UML en marcos de código: Java, C++, C#,

Esquemas XML, Corba IDL, Ingeniería inversa de código en diagramas UML: DDL,
WSDL, Java, C++, C#, Esquemas XML.

Papyrus UML. El entorno de modelado estándar “de facto” en Eclipse. Gratuito y

open source, Papyrus es sin duda la mejor opción si trabajas con Eclipse o necesitas
integrar tus modelos con otros plug-ins de Eclipse como parte de tu proceso de
desarrollo. Te acepto que Papyrus no es la herramienta más intuitiva ni fácil de usar
pero se está esforzando para revertir la situación. Por ejemplo, recientemente ha
sacado versiones especializadas para escenarios de uso concretos (e.g. Papyrus fo r
Information Modeling o Papyrus for real-time).
Modelio. Herramienta muy potente, organizada en un núcleo open source al que se
le pueden añadir funcionalidades mediante un sistema de extensión modular.
Algunos de los modelos son también gratuitos pero muchos son ya extensiones
comerciales, disponibles en la modelio store. Esta estructuración te permite adaptar
la herramienta a tus necesidades de modelado UML. Por ejemplo, puedes empezar
modelando gratis tu sistema y si luego decides utilizar esos modelos para generar
código para la plataforma que sea, comprar la extensión correspondiente.

StarUML: Si Grady Booch mismo habla bien de ella, tenía que poner StarUML en la
lista. StarUML es la mejor opción si buscas una herramienta rápida, fácil de usar y
razonablemente barata en comparación a otras herramientas UML.

Enterprise Architect: Una gran herramienta centrada sobre todo en el modelado de

aspectos de negocio / estratégicos. Enterprise Architect combina el poder de la última
especificación UML 2.1 con alto rendimiento, interfaz intuitiva, para traer modelado
avanzado al escritorio, y para el equipo completo de desarrollo e implementación.
Con un gran conjunto de características y un valor sin igual para el dinero, EA puede
equipar a su equipo entero, incluyendo analistas, evaluadores, administradores de
proyectos, personal del control de calidad, equipo de desarrollo y más .

IBM Rational Rhapsody (la evolución de Rational Rose) es un entorno de desarrollo

gráfico integrado (IDE) para el desarrollo de software y otros productos. Esta
herramienta para modelado UML permite el desarrollo de software basado en objetos
para aplicaciones web, así como sistemas embebidos y sistemas en tiempo real
basados en C++ y Java EE. El modelado UML/SysML te permite crear rápidamente
código fuente en el IDE para los lenguajes especificados, C y C#, MISRA-C o MISRA-
C++ y Ada.

ArgoUML ha sido durante mucho tiempo una de las herramientas UML gratuitas de
código abierto más populares para el escritorio. Aunque ya no se mantiene, muchos
modeladores continúan usando el programa para tareas más pequeñas. Software
multiplataforma, el requisito mínimo es Java 5 ArgoUML soporta todos los tipos de
diagramas de la versión 1.4 de UML y perfiles UML. El programa también ofrece
algunas formas decorativas que no forman parte del estándar UML: si utilizas estos
formularios, te desviarás del estándar UML. Por lo tanto, asegúrate de que esto no
cause ningún problema de comprensión posteriormente. Utiliza OCL (Object
Constraint Language) para asignar información restrictiva a un modelo.

No hay una herramienta UML que sirva para todo. Piense bien para que la quiere
(¿documentación?, ¿generación de código?, ¿diseño inicial?...) y luego bus que una
herramienta que sea buena en eso.