Monografias.com > Computación > Programación
Descargar Imprimir Comentar Ver trabajos relacionados

Introducción a UML




Enviado por Pablo Turmero



    Monografias.com

    Agenda
    Contexto
    Arquitectura de Software
    Métodos ágiles (XP y otros)
    Modelado orientado a objetos
    Elementos
    Diagramas
    Limitaciones
    Conclusiones

    Monografias.com

    UML – Antecedentes
    Lenguaje Unificado de Modelado: Lenguaje para especificar, visualizar y documentar los artefactos de los sistemas
    Grady Booch (Booch) + Jim Rumbaugh (OMT) + Ivar Jacobson (Objectory), 1994 ?
    Estándar de OMG (Object Management Group) desde 1997 [ http://www-omg.org ]
    Versión 2.0: notación simplificada

    Monografias.com

    UML – Significación
    Definición: Es una familia de notaciones gráficas, útil para diseñar sistemas de software, particularmente sistemas que habrán de desarrollarse en términos de OO.
    Desde su establecimiento ca. 1997, ha desplazado a una multitud de lenguajes gráficos de modelado OO (lo cual es de agradecer)
    Mellor y Fowler: principales usos
    Sketch (selectivo) *
    Blueprint (completo) – Igual a CASE, en desgracia
    Lenguaje de programación – MDA, Executable UML. No realista en opinión de Fowler.
    Fowler: No existe ningún estándar que especifique cómo mapea UML sobre un lenguaje de programación en particular

    Monografias.com

    UML – Building blocks
    7 Elementos Estructurales
    Clases, Interfaces, Colaboraciones, Casos de uso, Clases activas, Componentes, Nodos
    2 Elementos de Comportamiento
    Interacciones (mensajes, secuencias & enlaces), máquinas de estado
    1 elemento de agrupación: paquetes
    1 elemento de anotación
    4 Relaciones
    Dependencia, asociación, generalización, realización
    9 Diagramas

    Monografias.com

    UML – Diagramas
    Estáticos:
    Diagramas de clases
    Diagramas de objetos
    Diagramas de componentes
    Diagramas de despliegue
    Dinámicos:
    Diagramas de casos de uso
    Diagramas de secuencia
    Diagramas de colaboración
    Diagramas de estados
    Diagramas de actividades

    Monografias.com

    UML 2 – Diagramas

    Monografias.com

    RUP
    Milestones – Por primera vez en Boehm, 1996:
    Incepción – Visión y alcance – Life Cycle Objective Milestone
    Elaboración – Riesgos, arquitectura y planes – Life Cycle Architecture Milestone
    Construcción – Diseño detallado – Operation Capability Milestone
    Transición – Fine tuning – Product Release Milestone

    Monografias.com

    Fases de análisis y diseño
    Definiciónde casos de uso
    Definicióndel modelodel dominio
    Definiciónde diagramasde interacción
    Definiciónde diagramas declases diseño
    Casos de uso: Análisis de requerimientos
    Modelo de dominio: Conceptos, atributos y asociaciones
    Diagramas de interacción: Flujo de mensajes (invocación de métodos)
    Diagramas de clases: Métodos requeridos por los mensajes

    Monografias.com

    Análisis de requerimientos
    En UP los requerimientos se clasifican conforme al modelo FURPS+ [Grady92]:
    Funcional [Casos de uso]
    Usabilidad: Factor humano, documentación
    Fiabilidad (Reliability)
    Performance
    Soporte: Mantenimiento, configurabilidad…
    +: Adicionales (packaging, legales…)

    Monografias.com

    Análisis de requerimientos
    Casos de uso:
    Writing effective use cases [Cockburn01]
    Software Engineering Body of Knowledge, http://www.swebok.org
    ISO 9126, IEEE Std 830, IEEE Std 1061
    SEI – Carnegie Mellon
    Introducidos por Jacobson (86) para describir requerimientos funcionales

    Monografias.com

    Casos de Uso
    Los casos de uso son requerimientos, pero no todos los requerimientos
    Son documentos de texto, no diagramas (aunque en UML hay diagramas de casos de uso)
    No están ligados a OOD u OOP
    Anderson, Fowler, Cockburn… recomiendan no usar diagramas, sino escribir texto
    Se recomienda que sean de caja negra: qué (análisis), pero no cómo (diseño)
    Plantillas para casos de uso en http://www.usecases.org

    Monografias.com

    Casos de Uso
    Un caso de uso puede tener variantes, ser parte de otro o extender algún otro
    Los casos de uso se realizan mediante diagramas de colaboración* (UML 1)
    En BRJ99 son alternativamente referidos como estáticos (p.203) y dinámicos (p.205)
    Fowler no recomienda el uso de diagramas, sino la forma narrativa
    Se considera que la definición de casos de uso en UML es más bien ambigua

    Monografias.com

    Casos de Uso
    Diagramas de casos de uso:
    Casos de uso
    Actores
    Relaciones de dependencia, generalización y asociación
    Actores:
    Se representan mediante monigotes
    Se pueden definir categorías generales (Cliente) y especializarlas a través de relaciones de generalización
    Un Actor sólo se puede conectar a un caso de uso mediante una asociación

    Monografias.com

    Diagramas de Clases
    Modelan la vista de diseño estática de un sistema
    La vista estática soporta los requisitos funcionales
    Son los más utilizados en el modelado de sistemas orientados a objeto
    Fowler: “Psst… ¿Quiere ver un diagrama de UML?”
    Muestra un conjunto de clases, interfaces y colaboraciones
    Son importantes para construir sistemas ejecutables, aplicando ingeniería directa e inversa

    Monografias.com

    Diagramas de Clases
    Son un conjunto de nodos y arcos
    Contienen clases, interfaces, colaboraciones, relaciones de dependencia, generalización y asociación
    Pueden contener también paquetes o subsistemas para agrupar otros elementos del modelo
    El mayor peligro de los diagramas de clases es que uno se puede concentrar en la estructura y olvidar la conducta – Alternar clases de diagramas
    Recomendación 2 (Fowler): No diagramar todo, sino aspectos importantes

    Monografias.com

    Diagramas de Objetos
    Modelan las instancias de los elementos contenidos en los diagramas de clases
    Muestran un conjunto de objetos y sus relaciones en un momento concreto (vista estática, como una instantánea)
    Consisten en los objetos que colaboran, pero sin especificar los mensajes
    Contienen objetos y enlaces
    Pueden contener paquetes o subsistemas

    Monografias.com

    Diagramas de Objetos
    Se puede hacer ingeniería directa, pero en la práctica esto tiene un valor limitado
    Las instancias son creadas en tiempo de ejecución
    Hacer ingeniería inversa es más razonable y se hace continuamente p. ej. para localizar un enlace perdido, etc.
    Tener en cuenta:
    No es posible capturar todos los objetos potenciales de un sistema o sus relaciones
    Se usan para capturar algún aspecto específico del sistema en un momento dado

    Monografias.com

    Diagramas de Componentes
    Modelan aspectos físicos del sistema
    Ejecutables, bibliotecas, tablas, archivos, documentos
    Representan el empaquetamiento físico de elementos lógicos tales como clases, interfaces y colaboraciones
    Definen abstracciones con interfaces bien definidas
    La notación canónica permite visualizar un componente con independencia de sistema operativo o lenguaje de programación
    Con los mecanismos de extensión (estereotipos) se puede particularizar la notación

    Monografias.com

    Diagramas de Componentes
    Contienen componentes, interfaces y relaciones de dependencia, asociación y realización
    También pueden contener paquetes, subsistemas e instancias
    Es habitual hacer ingeniería directa e inversa
    Cada diagrama representa un aspecto; el conjunto de todos representa una vista estática completa del sistema

    Monografias.com

    Diagrama de Secuencia (DSS)
    Muestra eventos de entrada y salida relacionados con el sistema
    UML incluye notación para representar los eventos que parten de los actores externos hacia el sistema
    Un DSS es un dibujo que muestra, para un escenario* de casos de uso, los eventos generados por los actores, el orden y los eventos entre sistemas
    El orden de los eventos debe seguir el orden en el caso de uso

    Monografias.com

    Diagrama de Secuencia (DSS)
    Larman, p. 118

    Monografias.com

    Diagrama de Secuencia (DSS)
    Forman parte del Modelo de los Casos de Uso
    No se mencionan en la especificación de UP
    Se suelen crear en la elaboración, no en la incepción
    No es necesario crear DSS para todos los escenarios de todos los casos de uso
    En UML 1, los elementos del DSS eran objetos; ahora es más complicado y abstracto

    Monografias.com

    Diagramas de Secuencia
    Son buenos para comprender la conducta de varios objetos en un solo caso de uso
    Sirven para mostrar colaboración entre objetos; no lo son para modelar la conducta
    Si se quiere ver la conducta de un solo objeto a través de varios casos de uso, usar un diagrama de estados
    Muchos threads a través de muchos casos, un diagrama de actividad

    Monografias.com

    Diagramas de Estados
    Statecharts: Muestran una máquina de estados
    Un diagrama de actividad es una clase especial de diagrama de estados que muestra el flujo de control entre actividades
    Un diagrama de estados muestra el flujo de control entre estados
    Especifica la secuencia de estados por la que pasa un objeto en respuesta a eventos, junto con sus respuestas a esos eventos
    Son útiles para modelar comportamiento regido por eventos

    Monografias.com

    Diagramas de Estados
    Usualmente se modela la vida de un objeto, comenzando por su creación, sus estados estables y su destrucción
    Una máquina de estados cuyas acciones están asociadas a transiciones se llama máquina de Mealy
    Una máquina de estados cuyas acciones están asociadas a estados se llama máquina de Moore
    En la práctica se suelen mezclar ambos tipos de máquinas

    Monografias.com

    Diagramas de Estado
    La ingeniería directa es usual
    La ingeniería inversa es teóricamente posible pero no es útil
    Las herramientas de ingeniería inversa no tienen capacidad de abstracción y no pueden producir diagramas de estado significativos
    Puede resultar más útil alguna herramienta de animación

    Monografias.com

    Diagramas de Actividad
    Equivalente de un workflow, pero con soporte de paralelismo
    Describen lóigica de procedimiento, lógica de negocios y workflow
    Es uno de los que más cambió en UML 2
    En UML 1 eran casos especiales de diagramas de estado; ya no más
    En UML 1 había reglas especiales para balancear forks y joins; ya no es más preciso

    Monografias.com

    Diagramas de Comunicación
    Se llamaban Diagramas de Colaboración en UML 1.
    Enfatiza los vínculos de datos entre los participantes de una interacción
    Utilizan numeración para mostrar la secuencia de un mensaje
    Usualmente su usa numeración común, plana; pero la legal (“Kosher”) debería ser decimal 1.1, etc

    Monografias.com

    Diagramas de Despliegue
    Modelan la vista de despliegue estática, equivalente a la topología del sistema
    Para modelar hardware, se recomiendan lenguajes específicos, como VHDL
    No sólo modelan el despliegue, sino que pueden gestionarlo a través de ingeniería directa o inversa
    Contienen nodos y relaciones de dependencia y asociación
    Pueden contener paquetes, subsistemas, componentes e instancias

    Monografias.com

    Diagramas de Despliegue
    Se puede hacer alguna ingeniería directa, mayormente para visualizar
    La ingeniería inversa es de mayor valor

    Monografias.com

    Vista de gestión: Paquetes
    Un paquete es una parte de un modelo
    Cada parte de un modelo debe pertenecer a un paquete
    Los paquetes contienen elementos en el más alto nivel
    Clases y relaciones, máquinas de estado, diagramas de casos de uso, interacciones y colaboraciones
    Cualquier elemento que no esté contenido en otro paquete
    Si se ilgen bien los paquetes, representan la arquitectura de alto nivel del sistema

    Monografias.com

    Mecanismos de Extensión
    Las herramientas pueden almacenar y manipular las extensiones, pero sin entender su semántica
    Se espera que haya herramientas y módulos adicionales que puedan entenderlas
    Los mecanismos usuales de extensión son:
    Restricciones
    Valores etiquetados
    Estereotipos
    Las extensiones generan “dialectos” de UML

    Monografias.com

    Extensiones: Restricción
    Es una condición semántica representada como expresión textual
    Puede ser notación matemática formal, un lenguaje como OCL, un lenguaje de programación o seudocódigo
    Aunque se represente en lenguaje formal, no es de cumplimiento automático
    Habitualmente se expresan entre llaves
    cantidad: Dinero {valor múltiplo de 20}
    {Persona.Empleado = Persona.Jefe.Empleado}

    Monografias.com

    Extensiones: Valor etiquetado
    Los valores etiquetados se muestran como cadenas con el nombre de la etiqueta, un signo igual y un valor
    No se deben usar etiquetas reservadas
    Usualmente se ponen entre llaves
    {autor=Billy Reynoso,creación=7/12/04,estado=activado}

    Monografias.com

    Extensiones: Estereotipos
    Pueden utilizar símbolos pre-existentes o iconos creados a ese efecto
    Usualmente se presentan como cadenas de texto encomilladas

    Monografias.com

    Referencias
    Grady Booch, James Rumbaugh, Ivar Jacobson – El Lenguaje Unificado de Modelado. Madrid, Addison Wesley, 1999.
    Craig Larman – UML y Patrones. 2a ed., Madrid, Pearson/Prentice Hall, 2003.

    Nota al lector: es posible que esta página no contenga todos los componentes del trabajo original (pies de página, avanzadas formulas matemáticas, esquemas o tablas complejas, etc.). Recuerde que para ver el trabajo en su versión original completa, puede descargarlo desde el menú superior.

    Todos los documentos disponibles en este sitio expresan los puntos de vista de sus respectivos autores y no de Monografias.com. El objetivo de Monografias.com es poner el conocimiento a disposición de toda su comunidad. Queda bajo la responsabilidad de cada lector el eventual uso que se le de a esta información. Asimismo, es obligatoria la cita del autor del contenido y de Monografias.com como fuentes de información.

    Categorias
    Newsletter