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 |