Lenguaje unificado de modelado

1. LENGUAJE UNIFICADO DE
MODELADO
MODELO DELNEGOCIOYFACTIBILIDADES
DISEÑODESISTEMAS
Ing. José Bustamante Romero

3. Agenda
• OMG
• Definición de UML
• Historia de UML
• Modelamiento con UML
• Definición de conceptos
• Diagramas de UML
• Fuentes de consultas y links

4. Object Management Group (OMG)
• Es un consorcio internacional que promueve el desarrollo
de software orientado por objetos.
• El objetivo del OMG es proveer un marco de arquitectura
común para permitir la interacción de objetos en
plataformas heterogéneas y distribuidas.
• Fue fundado en 1989.
• Inicialmente estuvo conformado por 8 compañías: 3Com
Corpotation, American Airlines, Canon Inc., Data General,
Hewlett-Packard, Philips TelecommunicationsN.V., Sun
Microsystemsy Unisys Corporation.
• El OMG no realiza trabajos de desarrollo e
implementación, más bien se basa en la tecnología
existente ofrecida por sus miembros.

5. UML -Unified Modeling Language
¿Cómo se creó UML?
• Socios de la compañía
Rational Software,
Herramienta case
Rational Rose.
• UML es el lenguaje
estándar para visualizar,
especificar, construir y
documentar los
artefactos de una
aplicación de software ó
sistema.

6. ¿Por qué Lenguaje unificado de modelado?
• OMT -ObjectModeling Technique(James Rumbaugh)
 especialmente bueno para análisis de datos de Sistemas de
Información
 entre otros, usa extensiones de los diagramas Entidad Relación
• Método-Booch(GradyBooch)
• especialmente útil para sistemas concurrentes y de tiempo real
• fuerte relación con lenguajes de programación
• OOSE -Object-OrientedSoftware Engineering
(IvanJacobson)
• desarrollo guiado por los use cases(casos de uso)
• buen soporte de Ingeniería de Requisitos e Ingeniería de
Información
• Modelado y simulación de sistemas de telecomunicaciones
UML unifica estos conceptos e introduce otros nuevos

7. Evolución de UML:
Fuente: http://www.dsic.upv.es/~uml/curso.ppt

8. ¿Qué es UML?
• UML, prescribe un conjunto de notaciones y diagramas
estándar para modelar sistemas orientados a objeto y
describe la semántica esencial de lo que estos diagramas
y símbolos significan.
• UML es una notación, destinado a los sistemas de
modelado que utilizan conceptos orientados a objetos.
• Los principales factores que motivaron la creación de
UML fueron:
• La necesidad de modelar sistemas
• Las tendencias en la industria de software
• Unificar los distintos lenguajes y métodos existentes
• Innovar los modelos para adaptarse a la arquitectura distribuida

9. UML no es:
• Un lenguaje de programación visual, sino un lenguaje
de modelación visual.
• Una herramienta o deposito de especificación, sino un
lenguaje de modelación de especificación.
• Un proceso, sino que habilita procesos.
• Fundamentalmente, UML está relacionado con la captura,
comunicación y nivelación (disgregación en niveles) de
conocimientos.

10. UML, características:
• Divide cada proyecto en un número de diagramas que
representan las distintas vistas del proyecto y juntos
representan la arquitectura del mismo.
• Permite describir un sistema en diferentes niveles de
abstracción, simplificando la complejidad sin perder
información, para que los usuarios y desarrolladores
comprendan las características de la aplicación.
• Se quiere convertir en un lenguaje estándar con el que
sea posible modelar todos los componentes del
desarrollo de una aplicación, sin embargo no pretende
definir un modelo de desarrollo sino únicamente un
lenguaje de modelado.

11. Modelo
El proceso de desarrollo de software se inicia con la
construcción de un modelo. Dicho modelo representa la
especificación precisa de las necesidades del usuario
trasladadas a los requerimientos.
Un modelo es la interpretación simplificada de la
realidad.
Estructuralmente destaca la organización del sistema y a
nivel de comportamiento destaca la dinámica del sistema.

12. ¿Por qué construir un Modelo?
1. Construimos modelos para comprender mejor el
sistema que estamos desarrollando
2. Cuatro utilidades de los modelos:
 Visualizar cómo es o queremos que sea el sistema
 Especificar la estructura y comportamiento del sistema
 Proporcionan plantillas que guían la construcción del sistema
 Documentan las decisiones
3. “Equivalen a los planos de una casa”

13. Principios del Modelado:
• La elección de los modelos tiene una profunda influencia
sobre cómo se acomete el problema y se moldea la
solución.
• Todo modelo puede expresarse a diferentes niveles de
detalle y usarse en diferentes momentos del ciclo de vida.
• Todo modelo debe estar ligado a la realidad.
• Un único modelo no es suficiente. Cualquier sistema no
trivial se aborda mejor a través de un pequeño conjunto
de modelos casi independientes, que muestran distintos
aspectos.

14. Modelo, características:
• Abstracto:
• Enfatiza los elementos importantes y oculta los irrelevantes
• Comprensible:
• Fácil de comprender por los observadores
• Preciso:
• Representa de forma fiel el sistema que modela
• Predictivo:
• Se pueden usar para deducir conclusiones sobre el sistema que se
esta modelando
• Barato:
• Mucho más barato y sencillo de construir es el sistema que se
modela, luego se encontrara evidencia del desarrollo

15. ¿Cómo se usa un modelo?
• Para detectar errores u omisiones en el diseño antes de
comprometer recursos para la implementación
 Analizar y experimentar
 Investigar y comparar soluciones alternativas
 Minimizar riesgos
• Para comunicarse con los “Stakeholders”
 Clientes, usuarios, implementadores, encargados de pruebas,
documentadores, etc.
• Para guiar la implementación (construcción y
codificación)

16. Proceso
• Un buen proceso debe permitir a los equipos y clientes
trabajar juntos para construir sistemas complejos con
pocos defectos en menor tiempo con mayor confiabilidad
y previsibilidad para identificar y para reducir riesgos.

17. ¿Cómo utilizar UML?
• Lo primero que se debe hacer para comenzar a desarrollar un
proyecto con UML, es seleccionar una metodología de
desarrollo que defina la naturaleza concreta del proceso a
seguir.
• El modelo a definir en base al proceso elegido, se divide en
realidad en varios tipos de modelo o vistas, cada una centrada
en un aspecto o punto de vista del sistema. En general,
independientemente del proceso que se emplee, se puede
encontrar las siguientes vistas:
Vista de diseño Vista de implementación
Vista de procesos Vista de despliegue
Vista de Casos de Uso

18. ...continua, ¿Cómo utilizar UML?
• Vista de Casos de Uso. Engloba los Casos de Uso que
describen el comportamiento del sistema como lo verían los
usuarios finales y desarrolladores. No especifica la
organización del sistema.
• Vista de Diseño. Engloba las clases e interfaces que
conforman el vocabulario del problema y su solución. Da
soporte a los requisitos funcionales del sistema, es decir los
servicios que proporciona a los usuarios finales.
Con UML los aspectos estáticos de estas dos vistas se pueden
concretar con los diagramas de clases y de objetos; los
aspectos dinámicos con los diagramas de iteración (secuencia
y colaboración), diagramas de estados y de actividades.

19. ...continua, ¿Cómo utilizar UML?
• Vista de Procesos. Engloba los hilos y procesos que forman
los mecanismos de sincronización y concurrencia del sistema.
Da soporte al funcionamiento, capacidad de crecimiento y
rendimiento del sistema.
• Vista de Despliegue. Engloba los nodos que forman la
topología hardware sobre el que se ejecuta el sistema. Da
soporte a la distribución, entrega e instalación de las partes
que conforman el sistema físico.
Con UML los aspectos estáticos de estas dos vistas se pueden
concretar con los diagramas de clases y de objetos; los
aspectos dinámicos con los diagramas de iteración (secuencia
y colaboración), diagramas de estados y de actividades.

20. ...continua, ¿Cómo utilizar UML?
• Vista de Implementación. Engloba los componentes y
archivos empleados para hacer posible el sistema físico.
Da soporte a la gestión de configuraciones de las
distintas versiones del sistema, a partir de componentes y
archivos.
Con UML los aspectos estáticos de estas dos vistas se
pueden concretar con los diagramas de clases y de
objetos; los aspectos dinámicos con los diagramas de
iteración (secuencia y colaboración), diagramas de estados
y de actividades.

21. LENGUAJE DE
MODELAMIENTO: UML

22. Lenguaje de modelamiento: UML
UML tiene tres bloques básico de construcción: elementos,
relaciones y diagramas.
1. Bloques básicos de
construcción de UML.
2. Reglas que dictan cómo
se pueden combinar
esos bloques.
3. Y algunos mecanismos
comunes que se aplican
a través de UML.
elementos
relaciones
diagramas

23. Lenguaje de modelamiento: UML
1. Elementos: Unidades básicas de construcción, cuatro tipo:
Estructurales
De
comportamiento
De agrupación De anotación
Elementos
en UML
Partes dinámicas de los
modelos, representan
comportamientos en el
tiempo y espacio.
Partes explicativas de
los modelos.
Partes organizativas
de los modelos.
Partes estáticas de los
modelos, representan
aspectos conceptuales o
materiales

24. …continua, Lenguaje de modelamiento: UML
1.1 Elementos estructurales:
• Una interfaz es una colección de
operaciones que especifican un servicio de
una clase o un componente. Describe el
comportamiento visible de ese elemento.
• Una clase es una descripción de un conjunto
de objetos que comparten los mismos
atributos, operaciones, relaciones y
semántica.

25. …continua, Lenguaje de modelamiento: UML
1.1 Elementos estructurales:
• Un caso de uso es una descripción de un
conjunto de secuencias de acciones de un
sistema y que produce un resultado
observable de interés para un actor particular.
• Una colaboración define una interacción y es
una sociedad de roles y otros elementos que
colaboran para proporcionar un
comportamiento cooperativo.

26. …continua, Lenguaje de modelamiento: UML
1.1 Elementos estructurales:
• Un componente, parte física y reemplazable
de un sistema, que agrupa un conjunto de
interfaces, archivos de código fuente, clases,
colaboraciones y proporciona la
implementación de dichos elementos.
• Un nodo, elemento físico que existe en
tiempo de ejecución y representa un recurso
computacional con capacidad de
procesamiento.

27. …continua, Lenguaje de modelamiento: UML
1.2 Elementos de comportamiento:
• Interacción, Comprende un conjunto de
mensajes que se intercambian entre un
conjunto de objetos, para cumplir un objetivo
especifico.
• Maquina de estado, Especifica la secuencia
de estados por los que pasa un objeto o una
interacción, en respuesta.

28. …continua, Lenguaje de modelamiento: UML
1.3 Elementos de agrupación:
• Paquete, se emplea para organizar
elementos en grupos.
1.4 Elementos de notación:
• Una nota es un elemento explicativo de los
modelos UML. Sirve para hacer claridad
sobre elementos del modelo.

29. …continua, Lenguaje de modelamiento: UML
II. Relaciones: Abstracciones (relación) que actúan de
unión entre los elementos.
• Una dependencia es una relación semántica entre dos
elementos, en la cual un cambio a un elemento
(elemento independiente) puede afectar la semántica
del otro elemento (elemento dependiente).
• Es una relación estructural que resume un conjunto de
enlaces que son conexiones entre objetos.
• Una asociación es una relación estructural que
describe un conjunto de enlaces, los cuales son
conexiones entre objetos. La agregación es un tipo
especial de asociación, que representa una relación
estructural entre un todo y sus partes.

30. …continua, Lenguaje de modelamiento: UML
• Una generalización es una relación en la cual
los objetos del elemento especializado (el
hijo) pueden sustituir a los objetos del
elemento general (el padre). De esta forma,
el hijo comparte la estructura y el
comportamiento del padre.
• Una realización especifica que una clase
implementara un conjunto de métodos
especificados por una interfaz.

31. …continua, Lenguaje de modelamiento: UML

32. III. Diagramas
En OMG UML 2.0 se definen una serie de diagramas adicionales a los
establecidos en OMG UML 1.x. El conjunto de diagramas se encuentra
organizado en torno a dos categorías: diagramas estructurales
(representados en verdes) y diagramas dinámicos o de
comportamiento (representados en celeste). Los diferentes diagramas
son indicados en la figura siguiente:

33. III. Diagramas, continua…
Jerarquía de Diagramas
1. Diagramas de estructura enfatizan en los elementos
que deben existir en el sistema modelado
2. Diagramas de comportamiento enfatizan en lo que
debe suceder en el sistema modelado
3. Diagramas de Interacción, un subtipo de diagramas
de comportamiento, que enfatiza sobre el flujo de
control y de datos entre los elementos del sistema
modelado

34. III. Diagramas, continua…

35. Diagrama de Casos de Uso
Permiten realizar la especificación del alcance funcional
del producto software que se construye y de los actores,
entes que interactúan con el producto de software, que
requieren los diferentes casos de usos.
Los casos de usos pueden relacionarse entre sí a través
de asociaciones que permiten, entre otras cosas, refinar el
Modelo de Casos de Usos a través de las asociaciones de:
• Generalización
• Extends
• Includ
Enfatizan el qué en lugar del cómo.

36. ...continua, Diagrama de Casos de Uso
Generalización
• Asociación estereotipada como
“generalization”. Permite
establecer una jerarquía de
herencia al nivel de los casos de
uso, donde el caso de uso
derivado adquiere toda la
especificación del caso de uso
base e incorporar nuevos
requerimientos a la
especificación.

37. ...continua, Diagrama de Casos de Uso
Extensión
Asociación estereotipada
como: extend. Permite
incorporar el flujo de eventos
de un caso de uso pequeño
dentro de un caso de uso base
de la aplicación bajo la
ocurrencia de una determinada
condición, cuando la misma
evalúa verdadero.

38. ...continua, Diagrama de Casos de Uso
Inclusión
Asociación estereotipada como: incluye. Permite incorporar
el flujo de eventos de un caso de uso pequeño dentro de
un caso de uso base de la aplicación.

39. ...continua, Diagrama de Casos de Uso

40. Diagrama de Clases
• Muestra una colección de elementos del modelo estático, tales
como clases y tipos, sus contenidos y sus relaciones.
• Un modelo conceptual o modelo del dominio muestra
gráficamente las clases, los atributos y las asociaciones.

41. Diagrama de Objetos
Los diagramas de
objetos son análogos a
los de clases, con la
particularidad de que en
lugar de encontrar
clases, encontramos
instancias de éstas.
Son útiles para explicar
partes pequeñas del
modelo en las que hay
relaciones complejas.

42. Diagrama de Objetos –Diagrama de Clases (relación):
• Los objetos se vinculan por enlaces, que son instancias
de las relaciones entre las clases de objetos del dominio.

43. ...continua, Diagrama de Actividades
• Los diagramas de actividades muestran como las actividades
fluyen y las dependencias entre ellas. Muestran los procesos
de alto nivel de la organización.

44. ...continua, Diagrama de Actividades
• Ejemplo: “swim lines=pasillos”

45. Diagrama de Secuencia
Modela la secuencia lógica, a través del tiempo, de los mensajes entre
las instancias.
En el siguiente diagrama se puede observar que el registro del
préstamo solo se efectúa si el usuario satisface la regla de negocio que
establece que el video se encuentre disponible.

46. Diagrama de Comunicación
Muestra la distribución estática de los objetos, sus
interrelaciones y el flujo (envían y reciben) de mensajes entre
ellos. Son conocidos también como diagramas de colaboración.

47. Diagrama de Secuencia y de Comunicación (colaboración)
Los diagramas de secuencia y de colaboración son Isomorfos.
Un diagrama de secuencia se puede transformar mecánicamente en
un diagrama de comunicación. Un diagrama de comunicación se
puede transformar mecánicamente en un diagrama de secuencia.

48. Diagrama de Componentes
• El diagrama de componente
muestra interfaces y
dependencias entre los
componentes del software, los
componentes de código de
fuente, código binario y
ejecutables.
• Muestran la organización y
dependencias de un conjunto de
componentes. Cubren la vista de
implementación estática de un
sistema.

49. Diagrama de Despliegue o distribución
• Estos diagramas muestran la distribución y relación entre los
diferentes elementos de hardware llamados “nodos” (arquitectura del
sistema); por ejemplo: cpu, dispositivos de I/O, routers, etc.
• Los diagramas de despliegue sirven para modelar la configuración
del hardware del sistema, mostrando qué nodos lo componen.

50. Diagrama de Paquetes
• Los paquetes ofrecen un mecanismo general para la
organización de los modelos/subsistemas agrupando
elementos de modelado.
• Se representan gráficamente como:

51. ...continua, Diagrama de Paquetes
• Cada paquete corresponde a un submodelo
(subsistema)del modelo(sistema)
• Un paquete puede contener otros paquetes, sin límite de
anidamiento pero cada elemento pertenece a (está
definido en) sólo un paquete
• Una clase de un paquete puede aparecer en otro paquete
por la importación a través de una relación de
dependencia entre paquetes

52. UML – en resumen

53. Referencias
• Zambrano G. 2009. Construcción de Software Orientado a
Objetos. Universidad de San Martín de Porras. Facultad de
Ingeniería de Computación y Sistemas.
• Sánchez J. 2003. Proceso Unificado de Desarrollo de
Software. Metodologías de Desarrollo Software. Universidad
de Las Palmas de Gran Canaria
• Kendall K., Kendall J. 2005. Análisis y Diseño de Sistemas. Ed.
6. Pearson Educación, México.
• TUTORIAL: http://www.cs.utsa.edu/~kdo/roseTutorial/
• http://www.sparxsystems.com.au/resources/uml2_tutorial/
• Alfredo Weitzenfeld. “Ingenieria de software orientado a
objetos con UML, Java e Internet. Ed Thomson, Mexico. 2005.