UML
M.C. Juan Carlos Olivares Rojas
UML
• UML (Unified Modelling Language), lenguaje de
modelado unificado. Fue desarrollado en 1997 al
fusionar las metodolog...
UML
• Al ser UML un lenguaje posee gramáticas y
alfabetos que definen como deben de
estructurarse cada una de las palabras...
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ét...
¿Por qué modelar?
• Casi el 80% de los proyectos de software
fallan.
• Nadie construye una casa sin un plano.
• Actualment...
Modelos
• Los modelos deben ser más baratos que la
realidad.
• Es más fácil para una persona entender un
diagrama que las ...
Modelos
• Se deben construir modelos que sean
representativos para que sean útiles
(imaginense hacer un documento de 100
h...
Tipos de diagramas
• Los diagramas más utilizados en UML son:
• Diagramas de casos de uso
• Diagramas de actividades
• Dia...
Tipos de diagramas
• Diagramas de estado
• Diagramas de componentes
• Otros diagramas
– Diagrama de topología del desplieg...
Diagramas de casos de uso
• Son responsables de documentar los
macrorequisitos del sistema.
• Lista de capacidades que deb...
Diagramas de casos de uso
• Se deben establecer prioridades para las
capacidades del sistema.
• ¿Cuál es la diferencia ent...
Diagramas de caso de uso
• Objetivos secundarios: guardar el archivo en
formato HTML, RTF y PDF.
• Los diagramas de uso si...
Diagramas de caso de uso
• Las líneas continuas representan una
asociación y las puntuadas dependencias.
• Si el conector ...
Diagramas de caso de uso
• Los estereotipos más utilizados son:
inclusión y de extensión.
• Muchas herramientas no impelem...
Diagramas de caso de uso
• Incluir implica una dependecia de utilización
de un caso de uso.
• Las notas ayudan ha aclarar ...
Diagramas de caso de uso
• Las notas deben ser como elementos
taquigráficos.
• Se deben incluir la siguiente documentación...
Diagramas de casos de uso
• Se deben detallar ejemplos de la utilización
de casos de uso.
• Los actores pueden ser usuario...
Diagramas de caso de uso
Diagramas de actividades
• Es la versión UML de un diagrama de flujo.
• Se usan para analizar los procesos y
realizar la i...
Diagramas de actividades
• Son diagramas que representan las
carácterísticas de los procesos.
• Estos diagramas deben faci...
Diagrama de actividades
• Pueden modelar procesos lineales y
paralelos.
• Los diagramas deben ser más simples que
detallad...
Diagramas de actividades
• Se pueden utilizar clavijas para conectar dos
nodos de acción.
• Los nodos de decisión son impo...
Diagramas de actividades
• Los casos de uso son candidatos a
desarrollar diagramas de actividades.
• Las condiciones previ...
Diagramas de actividades
• Los carriles sirven para delimitar quien es el
responsable de una serie de actividades.
• Los c...
Diagrama de actividades
Diagramas de secuencia
Diagramas de clases
• Se usan para mostrar las clases de un
sistema y las relaciones entre ellas.
• Muestran la vista está...
Diagramas de clases
• Los elementos del lenguaje son unos
rectángulos denominados clases y los
conectores representan las ...
Diagramas de clases
• Un diagrama de objetos es similar a un
diagrama de clases pero representa un
comportamiento dinámico...
Diagramas de clases
• Las interfaces se usan cuando las partes de
las cosas tienen facetas semánticamente
similares pero n...
Diagramas de clases
• El símbolo + se usa para describir datos
públicos. El símbolo - para datos privados y
# un dato no e...
Diagramas de clases
• Los atributos funcionan como asociación. La
multiplicidad de las relaciones es
importante.
• Si los ...
Diagramas de clases
• Es común hablar de elementos, opcionales,
obligatorios, de un solo valor y valores
múltiples.
• El 8...
Diagramas de clase
• La agregación se representa con un
diamante hueco; mientras que la
composición es un diamante relleno...
Diagramas de clase
• Las relaciones de realización se utilizan en
interfaces para definir que la clase hija
implementará e...
Diagramas de clase
• Los paquetes tienen la apariencia de una
carpeta de archivos. Se usa para
representar un nivel más av...
Diagramas de clase
• Algunas herramientas soportan la
documentación del modelo, pero no forma
parte del estándar.
• UML ti...
Diagramas de clases
• Los espacios de nombre se anteponen al de la
clases con el operador de alcance: ::
• Existen dos mod...
Diagramas de clases
• Se recomienda realizar un análisis de
dominio ya que nos ayuda a encontrar
clases frontera, de contr...
Diagramas de clases
• La refactorización y los patrones de diseño
ayudan a mejorar los diagramas de clases.
• La herencia ...
Diagramas de clases
Diagramas de clases
Diagramas de secuencia
• Muestran la parte dinámica del sistema.
• Muestran los mensajes que se envían las clases
con resp...
Diagramas de secuencia
• Existen muchos diagramas en UML que resultan
redundantes, ya que dicen exactamente lo mismo
pero ...
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
t...
Diagramas de secuencia
• Los mensajes forman una parte importante
de este diagrama. Si se tiene una flecha
triangular repr...
Diagramas de secuencia
• Los marcos de interacción o fragmentos
combinados son nuevos en UML 2.0.
• Son regiones rectangul...
Diagramas de secuencia
• En un futuro no tan lejano, los diseños
deberán ser tan detallados como los
circuitos eléctricos....
Diagramas de secuencia
Diagramas de secuencia
Diagramas de interacción
• También muestran la parte dinámica del sistema.
• Organizan las clases y los mensajes en forma
...
Diagramas de interacción
Diagramas de colaboración
• También se les llama diagrama de
comunicación en UML 2.0
• Los elementos son un rectángulo lla...
Diagramas de colaboración
• Un diagrama de interacción se puede pasar
a código. Los objetos son instancias de
clases y los...
Diagramas de estado
• Muestra el estado cambiante de un objeto.
• UML es un lenguaje relativamente sencillo
ya que utiliza...
Diagramas de estado
• Sirven para representar máquinas de
estados (e.g. autómatas).
• Son ideales para representar proceso...
Diagramas de estado
• Los diagramas de estado y actividades
comparten mucha de la simbología por lo
que se les suele confu...
Diagramas de estado
• Las actividades comunes son algo que
sucede de manera instantánea; mientras
que una actividad inicia...
Diagramas de estado
• Las transacciones son líneas dirigidas que
conectan estados. Pueden ocurrir en base a
algún mecanism...
Diagramas de estado
Diagramas de componentes
• Muestra los subsistemas del producto final.
• No es un diagrama ampliamente utilizado en
UML.
•...
Diagramas de componentes
• El símbolo de componente cambió en UML
2.0 a un diagrama más simple.
• Se utiliza generalmente ...
Diagrama de componentes
Preguntas frecuentes
• ¿Cuántos diagramas debo crear? No existe
una respuesta específica.
• ¿Debo hacer diagramas de todo ...
Preguntas frecuentes
• ¿Qué tan grande debe de ser un diagrama?
Entre más grande sea un diagrama mayor
es la confusión. Se...
RUP
• Rational Unified Process, Proceso unificado
de desarrollo.
• Se debe utilizar UML con una metodología
de desarrollo ...
Análisis y Diseño
• UML permite realizar análisis y diseño de
sistemas orientados a objetos, pero no se
limita exclusivame...
Modelado de software
• El modelado de software es algo
relativamente nuevo. Algunas
recomendaciones para el modelado de
so...
Modelado de software
• Se debe documentar en forma económica.
• Si es obvio no se debe de modelar.
• Hacer hincapié en la ...
Diagrama de despliegue
• Se utiliza para modelar la forma en como
lucirá el sistema cuando se ponga en uso.
• Los nodos re...
Diagrama de despliegue
• Los artefactos son las cosas que se están
desplegando. Usan el estereotipo artefacto y
pueden ser...
¿Preguntas?
Próxima SlideShare
Cargando en…5
×

Uml

427 visualizaciones

Publicado el

0 comentarios
0 recomendaciones
Estadísticas
Notas
  • Sé el primero en comentar

  • Sé el primero en recomendar esto

Sin descargas
Visualizaciones
Visualizaciones totales
427
En SlideShare
0
De insertados
0
Número de insertados
3
Acciones
Compartido
0
Descargas
7
Comentarios
0
Recomendaciones
0
Insertados 0
No insertados

No hay notas en la diapositiva.

Uml

  1. 1. UML M.C. Juan Carlos Olivares Rojas
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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
  18. 18. Diagramas de caso de uso
  19. 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. 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. 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. 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. 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. 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.
  25. 25. Diagrama de actividades
  26. 26. Diagramas de secuencia
  27. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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.
  41. 41. Diagramas de clases
  42. 42. Diagramas de clases
  43. 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. 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. 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. 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. 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. 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.
  49. 49. Diagramas de secuencia
  50. 50. Diagramas de secuencia
  51. 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.
  52. 52. Diagramas de interacción
  53. 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. 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. 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. 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. 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. 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. 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.
  60. 60. Diagramas de estado
  61. 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. 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.
  63. 63. Diagrama de componentes
  64. 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. 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. 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. 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. 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. 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. 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. 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.
  72. 72. ¿Preguntas?

×