El documento presenta una introducción al Lenguaje de Modelado Unificado (UML). Explica que UML es una herramienta para visualizar, especificar, construir y documentar sistemas de software a través de diagramas. Describe algunos diagramas clave como el diagrama de clases, diagrama de casos de uso, diagrama de secuencias y diagrama de estados. Concluye que UML sirve como guía para el desarrollo de sistemas de software al igual que los planos y maquetas sirven para proyectos de arquitectura.

1. Lenguaje de
Modelado
Unificado
Lic. Carlos Villarroel Murga

2. Arquitectura de software
Es un instrumento cuya
función principal es la de
intervenir en favor del
hombre
James M Fitch.
Necesitamos soluciones para problemas reales, no
inventar problemas para afrontar con nuevas soluciones

3. Arquitectura de software
Viéndolo de esa forma, en realidad el rol de un
arquitecto de edificaciones y un arquitecto de
software parecen enfrentar los mismos retos

4. Arquitectura de software
No es lo mismo
construir esto

5. Arquitectura de software
Que esto!!!

6. Arquitectura de software
O esto ?

7. Arquitectura de software
Que esto!!!
Cada escenario plantea retos,
condiciones y necesidades
diferentes!

8. Arquitectura de software
Que herramientas, personas
presupuesto, conocimiento y tiempo
necesitamos para cada escenario?

9. Arquitectura de Software
Todas las consideraciones que
se tienen que tomar en
cuenta para definir la
arquitectura de edificaciones ,
deberían ser tomadas en
cuenta también al definir una
Arquitectura de software

10. Mansión Winchester
 160 Habitaciones
 3 Ascensores
 47 Chimeneas
 Sistema de
Alcantarillado y
calefacción
Todo Adelantado
para su época 1922
La arquitectura de esta
mansión sorprende y
escapa a los limites de
la razón

11. Mansión Winchester
Se pueden encontrar puertas que dan
a paredes o que están en medio de las
ventanas, etc.

12. Mansión Winchester
Qué tiene que ver esto con
la arquitectura de software

13. Esta situación es mas común de lo que
debería en el desarrollo de software
Cuando un desarrollador es asignado a la
tarea de mantener y/o actualizar un sistema
legado, cuya arquitectura tiene fallas o no
esta documentada.
Elegimos reconstruir partes o crear nuestras
propias rutas dentro el código.
“Programar sin una arquitectura en mente es como
explorar una gruta solo con una linterna: no sabes
dónde estás, dónde has estado ni hacia dónde vas”
Danny thorpe

14. Analogía Arquitectónica
 Tiene sentido poner ladrillos sin hacer
antes los planos?
 El modelo, los planos, ayudan a afrontar
la complejidad del proyecto.
 ¿Cuál es el lenguaje adecuado para
representar los planos?

15. Comunicación y Representación
del Conocimiento
 Para representar el conocimiento hace falta un
lenguaje adecuado
 El conocimiento bien representado ayuda a hacerse
las preguntas oportunas:
 ¿qué falta aquí?
 ¿qué pasaría si...?
 ¿por qué no se puede...?

16. ¿Qué es un Modelo?
 Abstracción o simplificación de la realidad
 Modelado y lenguaje
 El lenguaje es vehículo del pensamiento: ayuda
a pensar con claridad
 El modelado es un elemento esencial del
proceso de desarrollo de software
 El modelado requiere un lenguaje adecuado
 Modelar no es hacer diagramas sino pensar
con diagramas

17. Propiedades [Deseables]
de un Modelo
 Comprensible: Expresado de tal forma
que se pueda entender fácilmente.
 Preciso: Representa fielmente el sistema
modelado.
 Predictivo: Se puede utilizar para obtener
conclusiones correctas sobre el sistema.
 Barato: Más económico que construir y
estudiar el propio sistema.

18. UML
(Unified Modeling Language)

19. Historia UML

20. UML
Es un lenguaje para:
 Visualizar
 Especificar
 Construir
 Documentar
Artefactos de sistemas intensivos de software

21. Lenguajes de modelado,
modelos y diagramas
 Un lenguaje de modelado permite expresar los
distintos modelos que se producen en el
proceso de desarrollo.
 Un modelo es una representación abstracta de
una especificación, un diseño o un sistema
desde un punto de vista particular.
 Un diagrama es una representación de (parte
de) un modelo de diseño
 Un modelo se representa por uno o mas
diagramas

22. Lenguaje de Modelado UML 2.0
 Elementos primitivos de modelado
(estáticos, dinámicos, agrupamiento, anotaciones)
 Relaciones
 Dependencia
 Asociación
 Generalización
 Realización
 Diagramas UML (13 diagramas)
 Diagramas estáticos
 Diagramas de comportamiento

23. RELACIONES
Dependencia
Una relación semántica entre dos elementos, tal que
un cambio en una de ellos (el independiente) puede
afectar al otro (el dependiente).
A B
“B depende de A”

24. RELACIONES
Asociación
Es una relación estructural que describe un
conjunto de links, siendo un link una conexión
entre objetos
0..1 *
empleador empleado

25. RELACIONES
Generalización
Una relación de generalización/especialización
en la que el elemento especializado
(descendiente) se construye sobre la
especificación del elemento generalizado
(ancestro)

26. RELACIONES
Realización
Es una relación semántica en la que un clasificador,
tal como una interfaz o un caso de uso, especifica
un “contrato” que otro clasificador, tal como una
clase o una colaboración, garantiza llevar a cabo.

27. DIAGRAMAS UML
Diagramas estáticos
Diagrama de clases
Diagrama de componentes
Diagrama de distribución

28. Diagramas UML
Diagramas de comportamiento
 Diagramas de casos de uso
 Diagrama de secuencia
 Diagrama de colaboración
 Diagrama de estados
 Diagrama de actividades

29. Diagrama de Casos de Uso
 Parte desde el punto de
vista del usuario final.
 Da una buena pauta
para conocer más a
fondo los requisitos que
deberá tener el sistema
a desarrollar.
 Muestra la manera en la
que un usuario final va a
interactuar con el
sistema sin tomar en
cuenta los mecanismos
que se van a utilizar
para crear o hacer
funcionar el sistema.

30. Diagrama de Estados
 Conforme un sistema
interactúa con los
usuarios y otros sistemas,
sus objetos pasan por
cambios que ajustan las
interacciones.
 Un cambio en un sistema
se da debido a que los
objetos que componen
dicho sistema
modificaron su estado
como respuesta a los
sucesos y al tiempo.
 Un diagrama de estados
también se conoce
como un "motor de
estado."

31. Diagrama de Secuencias
 Muestra una interacción ordenada según la
secuencia de eventos vista a la luz de una
línea de tiempo.
 Muestra los objetos participantes en la
interacción y los mensajes que intercambian.

32. Diagrama de Colaboración
 Muestra una interacción organizada, basándose en
los objetos que toman parte en la interacción y los
enlaces entre los mismos.
 A diferencia de los diagramas de secuencia, los
diagramas de colaboración muestran las relaciones
entre los roles de los objetos.

33. Diagrama de Actividades
 Es en cierta medida, un diagrama de flujo reforzado.
 Muestra los pasos (conocidos como actividades) así
como puntos de decisión y bifurcaciones
 Muestran una visión simplificada de lo que ocurre
durante una operación o proceso.

34. Diagrama de Componentes
 Un componente de
software es una parte
física de un sistema, y se
encuentra en la
computadora, no en la
mente del analista.
 Ejemplos de
componentes son tablas,
archivos de datos,
ejecutables, bibliotecas
de vínculos dinámicos,
documentos y cosas por
el estilo.
 Contiene componentes,
interfaces y relaciones.

35. Diagrama de Distribución
 Se enfoca
específicamente al
hardware de un sistema
determinado.
 El elemento primordial
del hardware es un
nodo, que es un
nombre genérico para
todo tipo de recurso de
cómputo.
 Cada uno de los nodos
puede contener otros
componentes,
incluyendo software,

36. Diagrama de Clases
 Describe la estructura de un sistema mostrando las
clases del sistema, sus atributos, operaciones (o
métodos), y las relaciones entre los objetos.
 Se utiliza para
que la atención
se centre en los
aspectos lógicos
de las clases en
lugar de en su
implementación
.

37. Herramientas de Modelado

48. Conclusiones
A diferencia de los
arquitectos de
edificaciones, los
arquitectos de
software son los
encargados de
construir la base de
la arquitectura de los
proyectos

49. Conclusiones
En desarrollo de software
servirá de guía para el
desarrollo de un sistema
Planos y maquetas
en arquitectura

50. Conclusiones
A través de los
diagramas se
representa el diseño
y distribución del
software, pueden
mostrar diferentes
vistas de un mismo
sistema y de las
condiciones que
existen en el
entorno donde se
despliega

51. Conclusiones
Es la herramienta por
excelencia que
utilizan los arquitectos
de software.