UNIDAD VII

INTRODUCCIÓN A UML
LENGUAJE DE MODELAMIENTO UNIFICADO
UML

“
El Lenguaje de Modelamiento Unificado (UML) fue creado para forjar un
lenguaje de modelado visual común, semántico y sintácticamente rico para la
arquitectura, el diseño y la implementación de sistemas de software complejos,
tanto en estructura como en comportamiento. En general, los diagramas UML
describen los límites, la estructura y el comportamiento del sistema y los objetos
que contiene.
UML no es un lenguaje de programación, pero existen herramientas que se
pueden usar para generar código en diversos lenguajes usando los diagramas
UML. UML guarda una relación directa con el análisis y el diseño orientados a
objetos. 2
 HISTORIA DE UML
Grady, Booch y Rumbaugh conocidos como los tres amigos de la ingeniería de
software, habían desarrollado otras metodologías. Se asociaron para brindar
claridad a los programadores creando nuevos estándares. La colaboración entre
ellos fortaleció los tres métodos y mejoró el producto final.
Los esfuerzos de estos pensadores derivaron en la publicación de los documentos
UML 0.9 y 0.91 en 1996. Pronto se hizo evidente que varias organizaciones,
incluidas Microsoft, Oracle e IBM, consideraron que UML era esencial para su
propio desarrollo de negocios. Ellos, junto con muchas otras personas y
compañías, establecieron los recursos necesarios para desarrollar un lenguaje de
modelado hecho y derecho. "Los tres amigos" publicaron la Guía del usuario para
el Lenguaje Unificado de Modelado en 1999, y una actualización que incluye
información sobre UML 2.0 en la segunda edición de 2005.

3
UML es una notación destinada al modelado de sistemas y de procesos
mediante objetos. UML no contiene una guía metodológica sino que
constituye un soporte de modelado.

Arquitectura dirigida por

Proceso Unificado
modelos: MDA

El Proceso Unificado es un proceso de realización o de

evolución de software enteramente basado en UML, Propuesta de la OMG cuyo objetivo es
está constituido por un conjunto de directivas que diseñar sistemas basándose únicamente
permiten producir software a partir del pliego de en el modelado del dominio
condiciones (requisitos).

El PIM (modelo independiente de la Plataforma) está

UML (PIM) constituido por un conjunto de elementos cuyo diseño
debe hacerse de forma independiente

4
 UNA IMAGEN VALE MÁS QUE MIL PALABRAS

El Lenguaje de Modelamiento Unificado (UML) es un lenguaje gráfico para

visualizar, especificar, construir y documentar los artefactos de un sistema con
gran cantidad de software. UML proporciona una forma estándar de representar
los planos de un sistema, y comprende tanto elementos conceptuales, como los
procesos del negocio y las funciones del sistema, cuanto elementos concretos,
como las clases escritas en un lenguaje de programación específico, esquemas de
bases de datos y componentes de software reutilizables.
5
UNA EMPRESA DE SOFTWARE CON ÉXITO ES AQUELLA QUE PRODUCE DE UNA
MANERA CONSISTENTE, SOFTWARE DE CALIDAD QUE SATISFACE LAS
NECESIDADES DE SUS USUARIOS. UNA EMPRESA QUE PUEDE DESARROLLAR
ESTE SOFTWARE DE FORMA PREDECIBLE Y PUNTUAL, CON UN USO EFICIENTE Y
EFECTIVO DE RECURSOS, TANTO HUMANOS COMO MATERIALES, TIENE UN
NEGOCIO SOSTENIBLE.

6
 LA IMPORTANCIA DE MODELAR
Si se quiere construir una casa para una mascota, por ejemplo un perro, se puede
comenzar muy bien con un montón de madera, algunos clavos y algunas
herramientas básicas.
UN MODELO ES UNA SIMPLIFICACIÓN DE LA REALIDAD
Un modelo proporciona los planos del sistema, e involucran los planos detallados,
así como planos más generales que ofrecen una visión global del sistema. Un buen
modelo incluye elementos relevantes y omite aquellos elementos menores para
el nivel de abstracción.
Todos los sistemas pueden ser descritos desde diferentes perspectivas utilizando
diferentes modelos, y cada uno es, una abstracción semánticamente cerrada del
sistema. Un modelo puede ser estructural, destacando la organización, o puede
ser de comportamiento, resaltando la dinámica. 7
 ¿POR QUE MODELAR?
Se modela para comprender mejor el sistema que se esta modelando

A través del modelado, se consiguen los siguientes objetivos:

Los modelos ayudan a visualizar como es o se quiere que sea un sistema.
Permiten especificar la estructura o el comportamiento de un sistema.
Proporcionan plantillas que guían en la construcción de un sistema.
Documentan las decisiones adoptadas.

Se modelan sistemas complejos porque no es posible comprender el sistema en

su totalidad

8
 PRINCIPIOS DEL MODELADO
La elección acerca de que modelos crear tiene una profunda influencia sobre
como se acomete un problema y como dar forma a una solución.
Todo modelo puede ser expresado con diferentes niveles de precisión.
Los mejores modelos están ligados a la realidad.
Un único modelo o vista no es suficiente. Cualquier sistema no trivial se
aborda mejor a través de un pequeño conjunto de modelos casi
independientes con múltiples puntos de vista.

9
 MODELADO ORIENTADO A OBJETOS
En el software hay varias formas de enfocar un modelo. Las dos formas más
comunes son la perspectiva algorítmica y la perspectiva orientada a objetos.

VISUALIZAR, ESPECIFICAR, CONSTRUIR Y DOCUMENTAR SISTEMAS

ORIENTADOS A OBJETOS ES EL PROPÓSITO DE UML

10
 UML
El Lenguaje de Modelamiento Unificado (Unified Modeling Language, UML) es un
lenguaje estándar para describir planos de software. UML puede utilizarse para
visualizar, especificar, construir y documentar los artefactos de un sistema que
involucre una gran cantidad de software.
UML es apropiado para modelar desde sistemas de información empresariales
hasta aplicaciones distribuidas basadas en la Web, e incluso para sistemas
embebidos de tiempo real muy exigentes. Es un lenguaje muy expresivo, que
cubre todas las vistas necesarias para desarrollar y luego desplegar tales
sistemas.
UML es solo un lenguaje y, por tanto, es tan solo una parte de un método de
desarrollo de software. UML es independiente del proceso, aunque para utilizarlo
óptimamente se debería usar en un proceso que fuese dirigido por los casos de
uso, centrado en la arquitectura, iterativo e incremental.
11
UML es un lenguaje.
UML es un lenguaje para visualizar.
UML es un lenguaje para especificar.
UML es un lenguaje para describir.
UML es un lenguaje para documentar.

12
 ¿DÓNDE PUEDE UTILIZARSE UML?
UML esta pensado principalmente para sistemas con gran cantidad de software.
Ha sido utilizado de forma efectiva en dominios tales como:
Sistemas de información empresariales.
Bancos y servicios financieros.
Telecomunicaciones.
Transporte.
Defensa/industria aeroespacial.
Comercio.
Electrónica medica.
Ámbito científico.
Servicios distribuidos basados en la Web.
UML no esta limitado al modelado de software. De hecho, es lo suficientemente
expresivo para modelar sistemas que no son software, como flujos de trabajo
(workflows) o el diseño de hardware. 13
 EL MODELO CONCEPTUAL DE UML
Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje,
y esto requiere aprender tres elementos principales:
los bloques básicos de construcción de UML
las reglas que dictan como se pueden combinar estos bloques básicos y
algunos mecanismos comunes que se aplican a través de UML.
Una vez comprendidas estas ideas, se pueden leer modelos UML y crear algu-
nos modelos básicos. Conforme se gana mas experiencia en la aplicación de
UML, se puede ampliar a partir de este modelo conceptual, utilizando
características mas avanzadas del lenguaje.

14
 BLOQUES BÁSICOS DE UML
El vocabulario de UML incluye tres clases de bloques básicos: Elementos,
Relaciones y Diagramas.

Los elementos son abstracciones que constituyen los ciudadanos de primera

clase en un modelo; las relaciones ligan estos elementos entre si; los diagramas
agrupan colecciones interesantes de elementos.
Hay cuatro tipos de elementos en UML:
1. Elementos estructurales.
2. Elementos de comportamiento.
3. Elementos de agrupación.
4. Elementos de anotación.
Estos elementos son los bloques básicos de construcción orientados a objetos de
UML. Se utilizan para escribir modelos bien formados.
15
1. ELEMENTOS ESTRUCTURALES
Los elementos estructurales son los nombres de los modelos UML. En su mayoría
son las partes estáticas de un modelo, y representan conceptos o cosas
materiales. Colectivamente, los elementos estructurales se denominan
clasificadores.
Clases Interfaces Colaboraciones

16
Casos de uso Clases activas Componentes

Artefactos Nodo

17
2. ELEMENTOS DE COMPORTAMIENTO
Los elementos de comportamiento son las partes dinámicas de los modelos UML.
Estos son los verbos de un modelo, y representan comportamiento en el tiempo y
el espacio.

Interacción - Mensajes Estados Acciones

18
3. ELEMENTOS DE AGRUPACIÓN
Los elementos de agrupación son las partes organizativas de los modelos UML.
Estos son las cajas en las que puede descomponerse un modelo.

Paquetes

19
4. ELEMENTOS DE ANOTACIÓN
Los elementos de anotación son las partes explicativas de los modelos UML. Son
comentarios que se pueden aplicar para describir, clarificar y hacer
observaciones sobre cualquier elemento de un modelo.

Notas

20
En cuanto a las relaciones, se tienen: Relaciones de dependencia, asociación,
generalización y realización.

1. RELACIONES DE DEPENDENCIA
Una dependencia es una relación semántica entre dos elementos, en la cual un
cambio a un elemento (el elemento independiente) puede afectar a la semántica
del otro elemento (el elemento dependiente).

21
2. RELACIONES DE ASOCIACIÓN
Una asociaci6n es una relación estructural entre clases que describe un conjunto
de enlaces, los cuales son conexiones entre objetos que son instancias de clases. La
agregación es un tipo especial de asociación, que representa una relación
estructural entre un todo y sus partes.

3. RELACIONES DE GENERALIZACIÓN
Una generalizaci6n es una relación de especialización/generalizacion en la cual
el elemento especializado (el hijo) se basa en la especificación del elemento
generalizado (el padre). El hijo comparte la estructura y el comportamiento del
padre.
22
4. RELACIONES DE REALIZACIÓN
Una realización es una relación semántica entre clasificadores, en donde un
clasificador especifica un contrato que otro clasificador garantiza que cumplirá.
Se pueden encontrar relaciones de realización en dos sitios: entre interfaces y las
clases y componentes que las realizan, y entre los casos de uso y las
colaboraciones que los realizan.

23
Un diagrama es la representación grafica de un conjunto de elementos,
visualizado la mayoría de las veces como un grafo conexo de nodos (elementos) y
arcos (relaciones). Los diagramas se dibujan para visualizar un sistema desde
diferentes perspectivas, de forma que un diagrama es una proyecci6n de un
sistema. En todos los sistemas, excepto en los mas triviales, un diagrama
representa una vista resumida de los elementos que constituyen un sistema. El
mismo elemento puede aparecer en todos los diagramas, solo en unos pocos
diagramas (el caso mas común), o en ningún diagrama (un caso muy raro). En
teoría, un diagrama puede contener cualquier combinación de elementos y
relaciones. En la práctica, sin embargo, solo surge un pequeño numero de
combinaciones habituales, las cuales son consistentes con las cinco vistas mas
útiles que comprenden la arquitectura de un sistema con gran cantidad de
software. Por esta razón, UML incluye trece tipos de diagramas:

24
1. Diagrama de clases.
2. Diagrama de objetos.
3. Diagrama de componentes.
4. Diagrama de estructura compuesta.
5. Diagrama de casos de uso.
6. Diagrama de secuencia.
7. Diagrama de comunicaci6n.
8. Diagrama de estados.
9. Diagrama de actividades.
10. Diagrama de despliegue.
11. Diagrama de paquetes.
12. Diagrama de tiempos.
13. Diagrama de visión global de interacciones.

25
 DIAGRAMA DE CLASES
Un diagrama de clases muestra un conjunto de clases, interfaces y
colaboraciones, así como sus relaciones.
Estos diagramas son los mas comunes en el modelado de sistemas orientados a
objetos. Los diagramas de clases abarcan la vista de diseño estática de un sistema.
Los diagramas de clases que incluyen clases activas cubren la vista de procesos
estática de un sistema. Los diagramas de componentes son una variante de los
diagramas de clases.

26
 DIAGRAMA DE OBJETOS
Un diagrama de objetos muestra un conjunto de objetos y sus relaciones. Los
diagramas de objetos representan instantáneas estáticas de instancias de los
elementos existentes en los diagramas de clases. Estos diagramas cubren la vista
de diseño estática o la vista de procesos estática de un sistema, como lo hacen los
diagramas de clases, pero desde la perspectiva de casos reales o prototípicos

27
 DIAGRAMA DE COMPONENTES
Un diagrama de componentes representa la encapsulación de una clase, junto con
sus interfaces, puertos y estructura interna, la cual esta formada por otros
componentes anidados y conectores. Los diagramas de componentes cubren la
vista de implementación estática del diseño de un sistema. Son importantes para
construir sistemas mas grandes a partir de partes pequeñas.

28
 DIAGRAMA DE CASOS DE USO
Un diagrama de casos de uso muestra un conjunto de casos de uso y actores (un
tipo especial de clases) y sus relaciones. Los diagramas de casos de uso cubren la
vista de casos de uso estática de un sistema. Estos diagramas son especialmente
importantes en el modelado y organización del comportamiento de un sistema.

29
 DIAGRAMA DE SECUENCIA – DIAGRAMA DE COMUNICACIÓN
Tanto los diagramas de secuencia como los diagramas de comunicación son tipos
de diagramas de interacción. Un diagrama de interacción muestra una
interacción, que consta de un conjunto de objetos o roles, incluyendo los men-
sajes que pueden ser enviados entre ellos. Los diagramas de interacción cubren
la vista dinámica de un sistema. Un diagrama de secuencia es un diagrama de
interacción que resalta la ordenación temporal de los mensajes; un diagrama de
comunicación es un diagrama de interacción que resalta la organización
estructural de los objetos o roles que envían y reciben mensajes.

30
 DIAGRAMA DE ESTADOS
Un diagrama de estados muestra una maquina de estados, que consta de estados,
transiciones, eventos y actividades. Un diagrama de estados muestra la vista
dinámica de un objeto. Son especialmente importantes en el modelado del
comportamiento de una interfaz, una clase o una colaboraci6n y resaltan el
comportamiento dirigido por eventos de un objeto, lo cual es especialmente útil en
el modelado de sistemas reactivos

31
 DIAGRAMA DE ACTIVIDADES
Un diagrama de actividades muestra la estructura de un proceso como el flujo de
control y datos paso a paso en la computación. Los diagramas de actividades
cubren la vista dinámica de un sistema. Son especialmente importantes al modelar
el funcionamiento de un sistema y resaltan el flujo de control entre objetos.

 DIAGRAMA DE DESPLIEGUE
Un diagrama de despliegue muestra la configuración de nodos de procesamiento
en tiempo de ejecución y los artefactos que residen en ellos. Los diagramas de
despliegue abordan la vista de despliegue estática de una arquitectura.
Normalmente, un nodo alberga uno o mas artefactos.

32
 DIAGRAMA DE ARTEFACTOS
Un diagrama de artefactos muestra los constituyentes físicos de un sistema en el
computador. Los artefactos incluyen archivos, bases de datos y colecciones
físicas de bits similares. Los artefactos se utilizan a menudo junto con los
diagramas de despliegue. Los artefactos también muestran las clases y
componentes que implementan. (UML trata a los diagramas de artefactos como
una variación de los diagramas de despliegue).

 DIAGRAMA DE PAQUETES
Un diagrama de paquetes muestra la descomposición del propio modelo en
unidades organizativas y sus dependencias.

33
 DIAGRAMA DE TIEMPOS – DIAGRAMA DE VISIÓN GLOBAL
Un diagrama de tiempos es un diagrama de interacción que muestra los tiempos
reales entre diferentes objetos o roles, en oposición a la simple secuencia relativa
de mensajes.

Un diagrama de visión global de interacciones es un híbrido entre un diagrama de

actividades y un diagrama de secuencia. Estos diagramas tienen usos
especializados.

34
 DIAGRAMA DE CASOS DE USO
En el lenguaje de modelado unificado (UML), un diagrama de casos de uso
puede resumir los detalles de los usuarios de su sistema (también conocidos
como actores) y sus interacciones con el sistema. Para construir uno, usará un
conjunto de símbolos y conectores especializados. Un diagrama de casos de
uso eficaz puede ayudar a su equipo a debatir y representar:
Escenarios en los que su sistema o aplicación interactúa con personas,
organizaciones o sistemas externos.
Objetivos que su sistema o aplicación ayuda a esas entidades (conocidas
como actores) a lograr.
El alcance de su sistema.

35
 CUÁNDO APLICAR LOS DIAGRAMAS DE CASOS DE USO
Un diagrama de casos de uso no entra en muchos detalles; por ejemplo, no
espere que modele el orden en que se realizan los pasos. En cambio, un
diagrama de casos de uso adecuado muestra una descripción general de alto
nivel de la relación entre los casos de uso, los actores y los sistemas. Los
expertos recomiendan que se utilicen diagramas de casos de uso para
complementar un caso de uso textual más descriptivo.
UML es el conjunto de herramientas de modelado que puede utilizar para crear
sus diagramas. Los casos de uso se representan con una forma ovalada
etiquetada. Las figuras de palo representan actores en el proceso, y la
participación del actor en el sistema se modela con una línea entre el actor y el
caso de uso. Para representar el límite del sistema, dibuje un cuadro alrededor
del caso de uso.

36
37
Los diagramas de casos de uso de UML son ideales para:
Representar los objetivos de las interacciones entre el sistema y el usuario.
Definición y organización de requisitos funcionales en un sistema.
Especificar el contexto y los requisitos de un sistema
Modelado del flujo básico de eventos en un caso de uso

38
39
 ELEMENTOS DE UN DIAGRAMA DE CASOS DE USO
Un diagrama de casos de uso está compuesto, principalmente, de 3 elementos:
Actores, Casos de uso y Relaciones.

ACTORES
Un actor es algo o alguien externo al sistema que interactúa de forma directa
con el sistema. Cuando se dice que interactúa se refiere a que aporta
información, recibe información, inicia una acción…
Se representan con una imagen de un “muñeco de palo” con el nombre del actor
debajo.
Existen dos tipos de actores: Los usuarios y los sistemas.

40
No hay que entender los usuarios como personas singulares, sino como
“perfiles o roles” que identifican a un tipo de usuario, pero no al usuario en sí.
Por ejemplo, en una aplicación de gestión de nóminas, un actor de este tipo
podría ser “gestor de nóminas” que se encarga de emitir y firmar nóminas. Este
rol podría ser tomado, por ejemplo, por cualquier individuo del personal de
recursos humanos y, además, por el jefe de la empresa. Es un ejemplo muy
sencillo, pero se puede ver, un actor no representa a una única persona o a un
único usuario.

41
Por otro lado, los actores pueden ser otros sistemas que también interactúan
con nuestro propio sistema. Un ejemplo podría ser, en la aplicación de nóminas,
un sistema que almacene las nóminas firmadas a modo de archivo. En este caso
cuando se firma la nómina se recibe la misma por el sistema de archivo, por
tanto el caso de uso se relaciona con el actor.

42
 CASOS DE USO
Un caso de uso se utiliza para representar una de las funcionalidades que realiza
el sistema. Es una secuencia de acciones que hace el sistema y que producen un
resultado que puede percibir un usuario.
Formalmente hablando, un caso de uso es una clasificación de comportamiento
que especifica una unidad de funcionalidad completa y que está realizada por
uno o más sujetos que se relacionan con el caso de uso colaborando para ello
con uno o más actores y que produce un resultado que tiene alguna utilidad
para cualquier de esos actores.
Se representan con una elipse que incluye en su interior el nombre del caso de
uso.

43
Existen muchos ejemplos de casos de uso. Algunos podrían ser: Crear pedido,
Listar productos, Enviar correo. Cualquier acción que realice la aplicación.
Las especificaciones anteriores a UML 2.5 requerían que un caso de uso sea
invocado por un actor. En UML 2.5 esto se eliminó, lo que significa que podría
haber algunas situaciones en las que la funcionalidad del sistema la inicie el
propio sistema y, al mismo tiempo, brinde resultados útiles a un actor. Por
ejemplo, el sistema podría notificar a un cliente que se envió la orden,
programar la limpieza y el archivo de la información del usuario, solicitar
información de otro sistema, etc.

44
 RELACIONES
Las relaciones conectan los casos de uso con los actores o los casos de uso entre
sí.
Cuando conectan un actor con un caso de uso representa que ese actor
interactúa de alguna manera con ese caso de uso y se representa con una línea
continua con la identificación <<communicates>>.

Cuando conectan casos de uso entre sí se pueden diferenciar dos tipos de

relaciones: <<include>> y <<extends>>. En español a veces se usa la
nomenclatura <<usa>> y <<extiende>>:
45
 <<include>>: Se utiliza para representar que un caso de uso utiliza
siempre a otro caso de uso. Es decir, un caso de uso se ejecutará
obligatoriamente (lo incluye, lo usa). Se representa con una flecha
discontinua que va desde el caso de uso de origen al caso de uso que se
incluye.

Un uso típico de este tipo de relaciones se produce cuando dos casos de

uso comparten una funcionalidad. Esa funcionalidad es extraída de los dos y se
crea un caso de uso nuevo que se relaciona con los anteriores con un include.

46
<<extend>>: Este tipo de relaciones se utilizan cuando un caso de uso
tiene un comportamiento opcional, reflejado en otro caso de uso. Es
decir, un caso de uso puede ejecutar, normalmente dependiendo de
alguna condición o flujo del programa, otro caso de uso. Se representa
con una flecha discontinua que va desde el caso de uso opcional al
original.

47
Existe, además, otra relación denominada generalización que consiste en
hacer que un elemento herede el comportamiento de otro. Aunque se
puede utilizar entre casos de uso, es más común utilizarlo entre actores,
haciendo que uno de los actores tenga acceso a las funcionalidades de
otro. Se representa con una flecha con la punta hueca que va desde el
elemento que hereda al elemento heredado:

48
 CÓMO DIBUJAR UN DIAGRAMA DE CASOS DE USO
Recopilar fuentes de información: ¿cómo se supone que debo saber eso?
Identificar actores potenciales: ¿qué usuarios utilizan los bienes y servicios
del sistema empresarial?. Para más información te recomiendo la guía para
identificar actores y casos de uso.
Identificar posibles casos de uso: ¿a qué bienes y servicios pueden recurrir
los actores?
Conectar los casos de uso: ¿quién puede hacer uso de los bienes y servicios
del sistema empresarial?
Describir actores: ¿a quién o qué representan los actores?
Buscar más casos de uso: ¿Qué más debe hacer el sistema?
Documentar casos de uso: ¿qué sucede exactamente en cada caso de uso?
Relacionar modelos entre casos de uso empresarial: ¿qué actividades se
realizan repetidamente?
Verificar la vista, ¿todo es correcto? 49
50
51
52
SISTEMA DE CONTROL DE ASISTENCIA

53
CONSULTAS Y OBSERVACIONES

54