Agenda
Contexto
Arquitectura de Software
Métodos ágiles (XP y otros)
Modelado orientado a objetos
Elementos
Diagramas
Limitaciones
Conclusiones
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
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
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
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
UML 2 – Diagramas
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
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
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…)
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
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
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
Página siguiente  |