2. UML
• UML (Unified Modelling Language), lenguaje de
modelado unificado. Fue desarrollado en 1997 al
fusionar las metodologías de Ivar Jacobson,
Jame Rumbaugh y Grady Booch.
• Es un lenguaje visual, su premisa básica radica
en que una imagen vale más que 1,000 líneas de
código
3. UML
• Al ser UML un lenguaje posee gramáticas y
alfabetos que definen como deben de
estructurarse cada una de las palabras
válidas del lenguaje.
• Un modelo es una representación de la
realidad. No sólo se modela software sino
prácticamente cualquier actividad.
4. UML
• Es el lenguaje estándar para modelar
proyectos de software.
• La versión más actual del lenguaje es la 2.1
• Los métodos que se fusionaron para crear
UML fueron OMT (Rumbaugh), Objectory
(Jaconson) y el método Booch.
5. ¿Por qué modelar?
• Casi el 80% de los proyectos de software
fallan.
• Nadie construye una casa sin un plano.
• Actualmente existen muchas herramientas
que auxilian el proceso de modelado como
Visio, ArgoUML, Rational Rose, Together,
etc.
6. Modelos
• Los modelos deben ser más baratos que la
realidad.
• Es más fácil para una persona entender un
diagrama que las líneas de código fuente de
un programa.
• Los diagramas al igual que el texto
consumen tiempo.
7. Modelos
• Se deben construir modelos que sean
representativos para que sean útiles
(imaginense hacer un documento de 100
hojas que nadie va a leeer)
• UML define varios tipos de diagramas los
cuales pueden ser extensibles.
8. Tipos de diagramas
• Los diagramas más utilizados en UML son:
• Diagramas de casos de uso
• Diagramas de actividades
• Diagramas de clases
• Diagramas de interacción
– Diagramas de secuencia
– Diagramas de colaboración
9. Tipos de diagramas
• Diagramas de estado
• Diagramas de componentes
• Otros diagramas
– Diagrama de topología del despliegue
• Los diagramas deben de reflejar lo que se
pretende modelar
10. Diagramas de casos de uso
• Son responsables de documentar los
macrorequisitos del sistema.
• Lista de capacidades que debe brindar el
sistema.
• Los elementos principales son los actores y
los casos de usos que en conjunto forman
un escenarios
11. Diagramas de casos de uso
• Se deben establecer prioridades para las
capacidades del sistema.
• ¿Cuál es la diferencia entre un editor de
textos como Notepad y Word?
• Objetivos primarios: crear, guardar e
imprimir documentos de texto.
12. Diagramas de caso de uso
• Objetivos secundarios: guardar el archivo en
formato HTML, RTF y PDF.
• Los diagramas de uso sirven para mostrar
detalles de implementación del sistema a
usuarios finales.
• Los conectores asocian a los actores y los
casos de uso.
13. Diagramas de caso de uso
• Las líneas continuas representan una
asociación y las puntuadas dependencias.
• Si el conector tiene un triangulo hueco en la
punta representa una generalización que es
una relación de herencia.
• Los estereotipos agregan detalles a una
relación.
14. Diagramas de caso de uso
• Los estereotipos más utilizados son:
inclusión y de extensión.
• Muchas herramientas no impelemnat UML
al 100% existen muchos problemas de
compatibilidad entre dichas herramientas.
XMI es la descripción de un diagrama UML
en XML el cual utilizan varias herramientas
para exportar diagramas
15. Diagramas de caso de uso
• Incluir implica una dependecia de utilización
de un caso de uso.
• Las notas ayudan ha aclarar los diagramas.
• Extender da más detalle de dependecia de
un caso de uso al cual se le agregan más
capacidades.
16. Diagramas de caso de uso
• Las notas deben ser como elementos
taquigráficos.
• Se deben incluir la siguiente documentación:
párrafo que describa el caso de uso, párrafo
que describa cada una de las funciones
primarias y secundarias, entre otros.
17. Diagramas de casos de uso
• Se deben detallar ejemplos de la utilización
de casos de uso.
• Los actores pueden ser usuarios o partes
del sistema.
• En general los primeros diagramas que se
deben construir son los casos de uso
19. Diagramas de actividades
• Es la versión UML de un diagrama de flujo.
• Se usan para analizar los procesos y
realizar la ingeniería de los mismos.
• Es una excelente herramienta para analizar
problemas.
20. Diagramas de actividades
• Son diagramas que representan las
carácterísticas de los procesos.
• Estos diagramas deben facilitar la
implementación del sistema.
• Van enfocados a los expertos del dominio
(programadores y analistas)
21. Diagrama de actividades
• Pueden modelar procesos lineales y
paralelos.
• Los diagramas deben ser más simples que
detallados.
• Los elementos principales son: nodo inicial,
flujo, actividades, conectores.
22. Diagramas de actividades
• Se pueden utilizar clavijas para conectar dos
nodos de acción.
• Los nodos de decisión son importantes para
bifurcar el flujo de actividades.
• Los nombres y los verbos nos sirven para
determinar las clases y los métodos.
23. Diagramas de actividades
• Los casos de uso son candidatos a
desarrollar diagramas de actividades.
• Las condiciones previas y posteriores se
manejan con el uso de guardianes.
• Los nodos de decisión también sirven para
fusionar diversos flujos en uno solo.
24. Diagramas de actividades
• Los carriles sirven para delimitar quien es el
responsable de una serie de actividades.
• Los carriles formalmente se llaman partición
de actividades y puede haber varios siempre
y cuando no se encimen.
• Se puede modelar el tiempo a través de
señales.
27. Diagramas de clases
• Se usan para mostrar las clases de un
sistema y las relaciones entre ellas.
• Muestran la vista estática del sistema; no
describen los comportamientos ni la forma
en como interactuan las clases del sistema.
28. Diagramas de clases
• Los elementos del lenguaje son unos
rectángulos denominados clases y los
conectores representan las relaciones.
• Las clases pueden tener comportamientos y
atributos. Lo difícil no es encontrar las
clases sino definir sus relaciones
29. Diagramas de clases
• Un diagrama de objetos es similar a un
diagrama de clases pero representa un
comportamiento dinámico.
• Los objetos se distinguen al subrayar el
nombre de la clase.
• Las interfaces son clases abstractas puras.
30. Diagramas de clases
• Las interfaces se usan cuando las partes de
las cosas tienen facetas semánticamente
similares pero no tienen genealogía
relacionada.
• Se utiliza el estereotipo interface. Los tipos
de datos pueden variar dependiendo de la
implementación.
31. Diagramas de clases
• El símbolo + se usa para describir datos
públicos. El símbolo - para datos privados y
# un dato no es ni público ni privado
(protegido).
• Para acceder a datos privados y/o
protegidos se deben utilizar métodos get/set
32. Diagramas de clases
• Los atributos funcionan como asociación. La
multiplicidad de las relaciones es
importante.
• Si los valores superiores e inferiores de las
relaciones son iguales (1..1) se pone un solo
número (1).
33. Diagramas de clases
• Es común hablar de elementos, opcionales,
obligatorios, de un solo valor y valores
múltiples.
• El 80% de los diagramas de clase utilizan
relaciones simples.
• Si existe una flecha en la asociación se dice
que ésta es dirigida o direccional.
34. Diagramas de clase
• La agregación se representa con un
diamante hueco; mientras que la
composición es un diamante relleno.
• La generalización o herencia se refiere a
una relación del tipo es un.
• En una relación de herencia la clase hijo
hereda las carácterísticas de la clase padre.
35. Diagramas de clase
• Las relaciones de realización se utilizan en
interfaces para definir que la clase hija
implementará esa interfaz. Se utiliza una
línea punteada con un diamante parecido a
la herencia.
• Las relaciones de dependencia se dan entre
dos clases denominadas cliente y
proveedor. Se representa con una línea
punteada con flecha sencilla.
36. Diagramas de clase
• Los paquetes tienen la apariencia de una
carpeta de archivos. Se usa para
representar un nivel más avanzado de
abstracción. Se utilizan para organizar las
clases, generalmente representan un
espacio de nombres.
• Los espacios de nombres solucionan el
problema de tener clases diferentes con el
mismo nombre.
37. Diagramas de clase
• Algunas herramientas soportan la
documentación del modelo, pero no forma
parte del estándar.
• UML tiene datos primitivos: Integer,
Boolean, String y UnlimitedNatural, pero se
pueden utilizar otros tipos de datos definidos
por el estereotipo primitivo, solo hay que
definir sus componentes y sus operadores.
38. Diagramas de clases
• Los espacios de nombre se anteponen al de la
clases con el operador de alcance: ::
• Existen dos modalidades para el desarrollo de
software orientrado a objetos: consumo (Visual
Basic) y Producción (Visual C++).
• La técnica de nombres son clases, verbos son
métodos sólo funciona en el 20% de los casos.
39. Diagramas de clases
• Se recomienda realizar un análisis de
dominio ya que nos ayuda a encontrar
clases frontera, de control y entidad.
• Las clases frontera interconenctan
elementos del exterior con elementos del
interior. Las clases de entidad representan
datos (generalmente persistentes). Las
clases de control representan interacciones
entre el sistema.
40. Diagramas de clases
• La refactorización y los patrones de diseño
ayudan a mejorar los diagramas de clases.
• La herencia múltiple se puede modelar en
UML pero no es recomendable hacerlo. Es
mejor usar la composición o herencia de
interfaces.
• El mal se encuentra en los detalles.
43. Diagramas de secuencia
• Muestran la parte dinámica del sistema.
• Muestran los mensajes que se envían las clases
con respecto al tiempo.
• Los diagramas de secuencia muestran un orden a
través del tiempo.
• Un diagrama de secuencia es más fácil de leer que
uno de colaboración.
44. Diagramas de secuencia
• Existen muchos diagramas en UML que resultan
redundantes, ya que dicen exactamente lo mismo
pero en diferente forma.
• Los elementos esenciales son las líneas de vida y
los mensajes.
• La línea de vida representa un ejemplo de clase
45. Diagramas de secuencia
• Las líneas de vida pueden ser actores u
objetos.
• La activación de una línea de vida se hace a
través de un rectangulo sobre la línea de
vida. Un objeto puede crearse y destruirse
varias veces dentro de la ejecución de un
sistema.
46. Diagramas de secuencia
• Los mensajes forman una parte importante
de este diagrama. Si se tiene una flecha
triangular representa un mensaje síncrono,
si se tiene una flecha abierta se representa
un mensaje asíncrono, los mensajes de
retorno se representan con flechas
punteadas, mientras que un mensaje
anidado inicia y termina en la misma línea
de vida.
47. Diagramas de secuencia
• Los marcos de interacción o fragmentos
combinados son nuevos en UML 2.0.
• Son regiones rectangulares que se usan
para organizar los diagramas de interacción.
• Los marcos de interacción más comunes
son: alt, bucle, neg, opt, par, ref, regio rod
48. Diagramas de secuencia
• En un futuro no tan lejano, los diseños
deberán ser tan detallados como los
circuitos eléctricos.
• En algunos casos es mejor usar diagramas
de colaboración, debido a la sencillez de su
diseño.
51. Diagramas de interacción
• También muestran la parte dinámica del sistema.
• Organizan las clases y los mensajes en forma
espacial. Como no lleva ordenación del tiempo los
mensajes se numeran.
• Los diagramas de secuencia e interacciòn son
complementarios y en algunos casos no es
aconsejable utilizar ambos.
53. Diagramas de colaboración
• También se les llama diagrama de
comunicación en UML 2.0
• Los elementos son un rectángulo llamado
papel clasificador que representa los
objetos, conectores y una secuencia que
indica los mensajes. En UML la secuencia
se numera como 1, 1.1, 1.2, … en lugar de
1, 2, 3
54. Diagramas de colaboración
• Un diagrama de interacción se puede pasar
a código. Los objetos son instancias de
clases y los mensajes son métodos, los
cuales se codifican en la clase del receptor
no del llamador.
• En diagramas donde existen muchos
mensajes se necesitan de más notas para
poder explicar el diagrama.
55. Diagramas de estado
• Muestra el estado cambiante de un objeto.
• UML es un lenguaje relativamente sencillo
ya que utilizando poco vocabulario se puede
realizar la mayoría del modeloa de un
sistema.
56. Diagramas de estado
• Sirven para representar máquinas de
estados (e.g. autómatas).
• Son ideales para representar procesos de
red y de tiempo real.
• La creación de diagramas de interfaces
gráficas de usuarios no es parte del
estándar UML.
57. Diagramas de estado
• Los diagramas de estado y actividades
comparten mucha de la simbología por lo
que se les suele confundir con frecuencia.
• Los estados son activos cuando se ejecutan
su actividad de entrada. Se vuelven
inactivos después de ejecutar su actividad
de salida
58. Diagramas de estado
• Las actividades comunes son algo que
sucede de manera instantánea; mientras
que una actividad inicia con el prefijo
“hacer/” es una actividad de hacer.
• Un estado simple no está dividido en
regiones. En un estado compuesto cada
región representa una subactividad.
59. Diagramas de estado
• Las transacciones son líneas dirigidas que
conectan estados. Pueden ocurrir en base a
algún mecanismo de disparo.
• Las máquinas de estado de protocolo se
utilizan para describir interfaces.
61. Diagramas de componentes
• Muestra los subsistemas del producto final.
• No es un diagrama ampliamente utilizado en
UML.
• Existen dos métodos para el diseño basado
en componentes: diseño componetes-
interfaz (arriba abajo) y a partir de clases.
62. Diagramas de componentes
• El símbolo de componente cambió en UML
2.0 a un diagrama más simple.
• Se utiliza generalmente para modelar
sistemas muy grandes.
• Sistemas basados en red y distribuidos
pueden modelarse bien con este diagrama.
64. Preguntas frecuentes
• ¿Cuántos diagramas debo crear? No existe
una respuesta específica.
• ¿Debo hacer diagramas de todo tipo? No,
sólo se deben utilizar los diagramas que
mejor reflejen el modelado de la
problemática
65. Preguntas frecuentes
• ¿Qué tan grande debe de ser un diagrama?
Entre más grande sea un diagrama mayor
es la confusión. Se deben realizar diagrams
bien detallados, pero no detallados.
• ¿Cuánto texto debe complementar el
modelo? Entre menos texto mejor, son
como los comentarios del código fuente:
pocos pero claros
66. RUP
• Rational Unified Process, Proceso unificado
de desarrollo.
• Se debe utilizar UML con una metodología
de desarrollo de procesos.
• Ni los lenguajes de programación ni UML
son los que guían el proceso de desarrollo
de software
67. Análisis y Diseño
• UML permite realizar análisis y diseño de
sistemas orientados a objetos, pero no se
limita exclusivamente a esta metodología.
• Los modelos como UML no pueden
validarse a través de una herramienta como
el código.
68. Modelado de software
• El modelado de software es algo
relativamente nuevo. Algunas
recomendaciones para el modelado de
software son:
• No tenga a los programadores esperando
los modelos.
• Trabajar de una macrovista a una microvista.
69. Modelado de software
• Se debe documentar en forma económica.
• Si es obvio no se debe de modelar.
• Hacer hincapié en la especialización.
• Utilice patrones de diseño.
• Refactorice.
70. Diagrama de despliegue
• Se utiliza para modelar la forma en como
lucirá el sistema cuando se ponga en uso.
• Los nodos representan componentes físicos
que pueden ser computadoras, sistemas
operativos, entornos, servidores, etc.
• Ayudan al proceso de instalación de un
sistema
71. Diagrama de despliegue
• Los artefactos son las cosas que se están
desplegando. Usan el estereotipo artefacto y
pueden ser achivos exe, dll, HTML, .jar,
scripts, etc.
• Dentro de cada nodo se suele describir
algunas carácterísticas propias.
