UML

M.C. Juan Carlos Olivares Rojas

UML• UML (Unified Modelling Language), lenguaje de

modelado unificado. Fue desarrollado en 1997 alfusionar las metodologías de Ivar Jacobson,Jame Rumbaugh y Grady Booch.

• Es un lenguaje visual, su premisa básica radicaen que una imagen vale más que 1,000 líneas decódigo

UML• Al ser UML un lenguaje posee gramáticas y

alfabetos que definen como deben deestructurarse cada una de las palabrasválidas del lenguaje.

• Un modelo es una representación de larealidad. No sólo se modela software sinoprácticamente cualquier actividad.

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 crearUML fueron OMT (Rumbaugh), Objectory(Jaconson) y el método Booch.

¿Por qué modelar?• Casi el 80% de los proyectos de software

fallan.

• Nadie construye una casa sin un plano.

• Actualmente existen muchas herramientasque auxilian el proceso de modelado comoVisio, ArgoUML, Rational Rose, Together,etc.

Modelos• Los modelos deben ser más baratos que la

realidad.

• Es más fácil para una persona entender undiagrama que las líneas de código fuente deun programa.

• Los diagramas al igual que el textoconsumen tiempo.

Modelos• Se deben construir modelos que sean

representativos para que sean útiles(imaginense hacer un documento de 100hojas que nadie va a leeer)

• UML define varios tipos de diagramas loscuales pueden ser extensibles.

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

Tipos de diagramas• Diagramas de estado• Diagramas de componentes• Otros diagramas

– Diagrama de topología del despliegue

• Los diagramas deben de reflejar lo que sepretende modelar

Diagramas de casos de uso• Son responsables de documentar los

macrorequisitos del sistema.

• Lista de capacidades que debe brindar elsistema.

• Los elementos principales son los actores ylos casos de usos que en conjunto formanun escenarios

Diagramas de casos de uso• Se deben establecer prioridades para las

capacidades del sistema.

• ¿Cuál es la diferencia entre un editor detextos como Notepad y Word?

• Objetivos primarios: crear, guardar eimprimir documentos de texto.

Diagramas de caso de uso• Objetivos secundarios: guardar el archivo en

formato HTML, RTF y PDF.

• Los diagramas de uso sirven para mostrardetalles de implementación del sistema ausuarios finales.

• Los conectores asocian a los actores y loscasos de uso.

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 lapunta representa una generalización que esuna relación de herencia.

• Los estereotipos agregan detalles a unarelación.

Diagramas de caso de uso• Los estereotipos más utilizados son:

inclusión y de extensión.

• Muchas herramientas no impelemnat UMLal 100% existen muchos problemas decompatibilidad entre dichas herramientas.XMI es la descripción de un diagrama UMLen XML el cual utilizan varias herramientaspara exportar diagramas

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 deun caso de uso al cual se le agregan máscapacidades.

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árrafoque describa cada una de las funcionesprimarias y secundarias, entre otros.

Diagramas de casos de uso• Se deben detallar ejemplos de la utilización

de casos de uso.

• Los actores pueden ser usuarios o partesdel sistema.

• En general los primeros diagramas que sedeben construir son los casos de uso

Diagramas de caso de uso

Diagramas de actividades• Es la versión UML de un diagrama de flujo.

• Se usan para analizar los procesos yrealizar la ingeniería de los mismos.

• Es una excelente herramienta para analizarproblemas.

Diagramas de actividades• Son diagramas que representan las

carácterísticas de los procesos.

• Estos diagramas deben facilitar laimplementación del sistema.

• Van enfocados a los expertos del dominio(programadores y analistas)

Diagrama de actividades• Pueden modelar procesos lineales y

paralelos.

• Los diagramas deben ser más simples quedetallados.

• Los elementos principales son: nodo inicial,flujo, actividades, conectores.

Diagramas de actividades• Se pueden utilizar clavijas para conectar dos

nodos de acción.

• Los nodos de decisión son importantes parabifurcar el flujo de actividades.

• Los nombres y los verbos nos sirven paradeterminar las clases y los métodos.

Diagramas de actividades• Los casos de uso son candidatos a

desarrollar diagramas de actividades.

• Las condiciones previas y posteriores semanejan con el uso de guardianes.

• Los nodos de decisión también sirven parafusionar diversos flujos en uno solo.

Diagramas de actividades• Los carriles sirven para delimitar quien es el

responsable de una serie de actividades.

• Los carriles formalmente se llaman particiónde actividades y puede haber varios siemprey cuando no se encimen.

• Se puede modelar el tiempo a través deseñales.

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ática del sistema; nodescriben los comportamientos ni la formaen como interactuan las clases del sistema.

Diagramas de clases• Los elementos del lenguaje son unos

rectángulos denominados clases y losconectores representan las relaciones.

• Las clases pueden tener comportamientos yatributos. Lo difícil no es encontrar lasclases sino definir sus relaciones

Diagramas de clases• Un diagrama de objetos es similar a un

diagrama de clases pero representa uncomportamiento dinámico.

• Los objetos se distinguen al subrayar elnombre de la clase.

• Las interfaces son clases abstractas puras.

Diagramas de clases• Las interfaces se usan cuando las partes de

las cosas tienen facetas semánticamentesimilares pero no tienen genealogíarelacionada.

• Se utiliza el estereotipo interface. Los tiposde datos pueden variar dependiendo de laimplementación.

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/oprotegidos se deben utilizar métodos get/set

Diagramas de clases• Los atributos funcionan como asociación. La

multiplicidad de las relaciones esimportante.

• Si los valores superiores e inferiores de lasrelaciones son iguales (1..1) se pone un solonúmero (1).

Diagramas de clases• Es común hablar de elementos, opcionales,

obligatorios, de un solo valor y valoresmúltiples.

• El 80% de los diagramas de clase utilizanrelaciones simples.

• Si existe una flecha en la asociación se diceque ésta es dirigida o direccional.

Diagramas de clase• La agregación se representa con un

diamante hueco; mientras que lacomposición es un diamante relleno.

• La generalización o herencia se refiere auna relación del tipo es un.

• En una relación de herencia la clase hijohereda las carácterísticas de la clase padre.

Diagramas de clase• Las relaciones de realización se utilizan en

interfaces para definir que la clase hijaimplementará esa interfaz. Se utiliza unalínea punteada con un diamante parecido ala herencia.

• Las relaciones de dependencia se dan entredos clases denominadas cliente yproveedor. Se representa con una líneapunteada con flecha sencilla.

Diagramas de clase• Los paquetes tienen la apariencia de una

carpeta de archivos. Se usa pararepresentar un nivel más avanzado deabstracción. Se utilizan para organizar lasclases, generalmente representan unespacio de nombres.

• Los espacios de nombres solucionan elproblema de tener clases diferentes con elmismo nombre.

Diagramas de clase• Algunas herramientas soportan la

documentación del modelo, pero no formaparte del estándar.

• UML tiene datos primitivos: Integer,Boolean, String y UnlimitedNatural, pero sepueden utilizar otros tipos de datos definidospor el estereotipo primitivo, solo hay quedefinir sus componentes y sus operadores.

Diagramas de clases• Los espacios de nombre se anteponen al de la

clases con el operador de alcance: ::

• Existen dos modalidades para el desarrollo desoftware orientrado a objetos: consumo (VisualBasic) y Producción (Visual C++).

• La técnica de nombres son clases, verbos sonmétodos sólo funciona en el 20% de los casos.

Diagramas de clases• Se recomienda realizar un análisis de

dominio ya que nos ayuda a encontrarclases frontera, de control y entidad.

• Las clases frontera interconenctanelementos del exterior con elementos delinterior. Las clases de entidad representandatos (generalmente persistentes). Lasclases de control representan interaccionesentre el sistema.

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 enUML pero no es recomendable hacerlo. Esmejor usar la composición o herencia deinterfaces.

• El mal se encuentra en los detalles.

Diagramas de clases

Diagramas de clases

Diagramas de secuencia• Muestran la parte dinámica del sistema.

• Muestran los mensajes que se envían las clasescon respecto al tiempo.

• Los diagramas de secuencia muestran un orden através del tiempo.

• Un diagrama de secuencia es más fácil de leer queuno de colaboración.

Diagramas de secuencia• Existen muchos diagramas en UML que resultan

redundantes, ya que dicen exactamente lo mismopero en diferente forma.

• Los elementos esenciales son las líneas de vida ylos mensajes.

• La línea de vida representa un ejemplo de clase

Diagramas de secuencia• Las líneas de vida pueden ser actores u

objetos.

• La activación de una línea de vida se hace através de un rectangulo sobre la línea devida. Un objeto puede crearse y destruirsevarias veces dentro de la ejecución de unsistema.

Diagramas de secuencia• Los mensajes forman una parte importante

de este diagrama. Si se tiene una flechatriangular representa un mensaje síncrono,si se tiene una flecha abierta se representaun mensaje asíncrono, los mensajes deretorno se representan con flechaspunteadas, mientras que un mensajeanidado inicia y termina en la misma líneade vida.

Diagramas de secuencia• Los marcos de interacción o fragmentos

combinados son nuevos en UML 2.0.

• Son regiones rectangulares que se usanpara organizar los diagramas de interacción.

• Los marcos de interacción más comunesson: alt, bucle, neg, opt, par, ref, regio rod

Diagramas de secuencia• En un futuro no tan lejano, los diseños

deberán ser tan detallados como loscircuitos eléctricos.

• En algunos casos es mejor usar diagramasde colaboración, debido a la sencillez de sudiseño.

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 formaespacial. Como no lleva ordenación del tiempo losmensajes se numeran.

• Los diagramas de secuencia e interacciòn soncomplementarios y en algunos casos no esaconsejable utilizar ambos.

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 llamadopapel clasificador que representa losobjetos, conectores y una secuencia queindica los mensajes. En UML la secuenciase numera como 1, 1.1, 1.2, … en lugar de1, 2, 3

Diagramas de colaboración• Un diagrama de interacción se puede pasar

a código. Los objetos son instancias declases y los mensajes son métodos, loscuales se codifican en la clase del receptorno del llamador.

• En diagramas donde existen muchosmensajes se necesitan de más notas parapoder explicar el diagrama.

Diagramas de estado• Muestra el estado cambiante de un objeto.

• UML es un lenguaje relativamente sencilloya que utilizando poco vocabulario se puederealizar la mayoría del modeloa de unsistema.

Diagramas de estado• Sirven para representar máquinas de

estados (e.g. autómatas).

• Son ideales para representar procesos dered y de tiempo real.

• La creación de diagramas de interfacesgráficas de usuarios no es parte delestándar UML.

Diagramas de estado• Los diagramas de estado y actividades

comparten mucha de la simbología por loque se les suele confundir con frecuencia.

• Los estados son activos cuando se ejecutansu actividad de entrada. Se vuelveninactivos después de ejecutar su actividadde salida

Diagramas de estado• Las actividades comunes son algo que

sucede de manera instantánea; mientrasque una actividad inicia con el prefijo“hacer/” es una actividad de hacer.

• Un estado simple no está dividido enregiones. En un estado compuesto cadaregión representa una subactividad.

Diagramas de estado• Las transacciones son líneas dirigidas que

conectan estados. Pueden ocurrir en base aalgún mecanismo de disparo.

• Las máquinas de estado de protocolo seutilizan para describir interfaces.

Diagramas de estado

Diagramas de componentes• Muestra los subsistemas del producto final.

• No es un diagrama ampliamente utilizado enUML.

• Existen dos métodos para el diseño basadoen componentes: diseño componetes-interfaz (arriba abajo) y a partir de clases.

Diagramas de componentes• El símbolo de componente cambió en UML

2.0 a un diagrama más simple.

• Se utiliza generalmente para modelarsistemas muy grandes.

• Sistemas basados en red y distribuidospueden modelarse bien con este diagrama.

Diagrama de componentes

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 quemejor reflejen el modelado de laproblemática

Preguntas frecuentes• ¿Qué tan grande debe de ser un diagrama?

Entre más grande sea un diagrama mayores la confusión. Se deben realizar diagramsbien detallados, pero no detallados.

• ¿Cuánto texto debe complementar elmodelo? Entre menos texto mejor, soncomo los comentarios del código fuente:pocos pero claros

RUP• Rational Unified Process, Proceso unificado

de desarrollo.

• Se debe utilizar UML con una metodologíade desarrollo de procesos.

• Ni los lenguajes de programación ni UMLson los que guían el proceso de desarrollode software

Análisis y Diseño• UML permite realizar análisis y diseño de

sistemas orientados a objetos, pero no selimita exclusivamente a esta metodología.

• Los modelos como UML no puedenvalidarse a través de una herramienta comoel código.

Modelado de software• El modelado de software es algo

relativamente nuevo. Algunasrecomendaciones para el modelado desoftware son:

• No tenga a los programadores esperandolos modelos.

• Trabajar de una macrovista a una microvista.

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.

Diagrama de despliegue• Se utiliza para modelar la forma en como

lucirá el sistema cuando se ponga en uso.

• Los nodos representan componentes físicosque pueden ser computadoras, sistemasoperativos, entornos, servidores, etc.

• Ayudan al proceso de instalación de unsistema

Diagrama de despliegue• Los artefactos son las cosas que se están

desplegando. Usan el estereotipo artefacto ypueden ser achivos exe, dll, HTML, .jar,scripts, etc.

• Dentro de cada nodo se suele describiralgunas carácterísticas propias.

¿Preguntas?