Post on 31-Dec-2014
UML
Situación de Partida
• Diversos métodos y técnicas OO, con muchos aspectos en común pero utilizando distintas notaciones
• Inconvenientes para el aprendizaje, aplicación, construcción y uso de herramientas, etc.
• Pugna entre distintos enfoques (y correspondientes gurús)
• Establecer una notación estándar
I. Introducción: UML
Historia de UML
• Comenzó como el “Método Unificado”, con la participación de Grady Booch y Jim Rumbaugh. Se presentó en el OOPSLA’95
• El mismo año se unió Ivar Jacobson. Los “Tres Amigos” son socios en la compañía Rational Software. Herramienta CASE Rational Rose
I. Introducción: UML
… Historia de UML
Nov ‘97 UML aprobado por el OMG
1998
1999
2000
UML 1.2
UML 1.3
UML 1.4
2001-2003 UML 2.0
Revisiones menores
I. Introducción: UML
Participantes en UML 1.0
• Rational Software (Grady Booch, Jim Rumbaugh y Ivar Jacobson)
• Digital Equipment • Hewlett-Packard • i-Logix (David Harel)
• IBM• ICON Computing
(Desmond D’Souza)
• Intellicorp and James Martin & co. (James Odell)
• MCI Systemhouse• Microsoft • ObjecTime• Oracle Corp. • Platinium Technology• Sterling Software• Taskon• Texas Instruments • Unisys
I. Introducción: UML
Que es UML• El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language)
es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software.
• UML entrega una forma de modelar cosas:
procesos de negocio funciones de sistema
escribir clases en un lenguaje determinado Concretas esquemas de base de datos
componentes de software reusables.
• UML es una especificación de notación orientada a objetos. Se basa en las anteriores especificaciones BOOCH, RUMBAUGH y COAD-YOURDON.
• Divide cada proyecto en un número de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto
Conceptuales
Ventajas
• UML es estándar.
• UML introduce nuevos diagramas que representa una visión dinámica del sistema.
• Permite darse cuenta en la fase de diseño de problemas en la fase de estructura al propagar errores o de las partes que necesitan ser sincronizadas y el estado de cada una de las instancias en cada momento.
• Su utilización es independiente del lenguaje de programación y de las características de los proyectos.
• UML ha sido diseñado para modelar cualquier tipo de proyectos tanto informáticos como de arquitectura
• Un lenguaje de propósito general para el modelado orientado a objetos
• UML combina notaciones provenientes desde:– Modelado Orientado a Objetos – Modelado de Datos– Modelado de Componentes – Modelado de Flujos de Trabajo (Workflows)
I. Introducción: UML
… Ventajas
UML “aglutina” enfoques OO
UML
Rumbaugh
Jacobson
Meyer
Harel
Wirfs-BrockFusion
Embly
Gamma et. al.
Shlaer-Mellor
Odell
Booch
Pre- and Post-conditions
State Charts
Responsabilities
Operation descriptions, message numbering
Singleton classes
Frameworks, patterns, notes
Object life cycles
I. Introducción: UML
Aspectos Novedosos
• Definición semi-formal del Metamodelo de UML
• Mecanismos de Extensión en UML:
• Stereotypes
• Constraints
• Tagged Values
• Permiten adaptar los elementos de modelado,
• asignándoles una semántica particular
I. Introducción: UML
Inconvenientes en UML
• Definición del proceso de desarrollo usando UML. UML no es una metodología
• Falta integración con respecto de otras técnicas tales como patrones de diseño, interfaces de usuario, documentación, etc.
• Ejemplos aislados
• “Monopolio de conceptos, técnicas y métodos en torno a UML”
I. Introducción: UML
Perspectivas de UML
• UML será el lenguaje de modelado orientado a objetos estándar predominante los próximos años
• Razones:– Participación de metodólogos influyentes– Participación de importantes empresas– Aceptación del OMG como notación estándar
• Evidencias:– Herramientas que proveen la notación UML– “Edición” de libros– Congresos, cursos, “camisetas”, etc.
I. Introducción: UML
Breve recorrido por UML
Modelos y Diagramas
• Un modelo captura una vista de un sistema del mundo real. Es
una abstracción de dicho sistema, considerando un cierto
propósito. Así, el modelo describe completamente aquellos
aspectos del sistema que son relevantes al propósito del
modelo, y a un apropiado nivel de detalle.
• Diagrama: una representación gráfica de una colección de
elementos de modelado, a menudo dibujada como un grafo con
vértices conectados por arcos
OMG UML 1.4 Specification
II. Breve Tour por UML
• Un proceso de desarrollo de software debe ofrecer un conjunto de modelos que permitan expresar el producto desde cada una de las perspectivas de interés
• El código fuente del sistema es el modelo más detallado del sistema (y además es ejecutable). Sin embargo, se requieren otros modelos ...
• Cada modelo es completo desde su punto de vista del sistema, sin embargo, existen relaciones de trazabilidad entre los diferentes modelos
II. Breve Tour por UML
… Modelos y Diagramas
Diagramas de UML
• Diagrama de Casos de Uso• Diagrama de Clases• Diagrama de Objetos Diagramas de Comportamiento
• Diagrama de Estados• Diagrama de Actividad Diagramas de Interacción
• Diagrama de Secuencia• Diagrama de Colaboración
Diagramas de implementación• Diagrama de Componentes• Diagrama de Despliegue
II. Breve Tour por UML
... Diagramas de UML
Use CaseDiagrams
Use CaseDiagrams
Diagramas de Casos de Uso
ScenarioDiagrams
ScenarioDiagrams
Diagramas deColaboración
StateDiagrams
StateDiagrams
Diagramas deComponentes
ComponentDiagramsComponent
DiagramsDiagramas deDistribución
StateDiagrams
StateDiagrams
Diagramas de Objetos
ScenarioDiagrams
ScenarioDiagrams
Diagramas deEstados
Use CaseDiagrams
Use CaseDiagrams
Diagramas deSecuencia
StateDiagrams
StateDiagrams
Diagramas deClases
Diagramas deActividad
Modelo
II. Breve Tour por UML
Los diagramas expresan gráficamente partes de un modelo
Diagramas Estáticos
• Diagrama de clases: muestra las clases, interfaces, colaboraciones y sus relaciones. Son los más comunes y dan una vista estática del proyecto.
• Diagrama de objetos: Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Muestra las instancias y como se relacionan entre ellas. Se da una visión de casos reales.
• Diagrama de componentes: Muestran la organización de los componentes del sistema. Un componente se corresponde con una o varias clases, interfaces o colaboraciones.
… Diagramas Estáticos
• Diagrama de despliegue: Muestra los nodos y sus relaciones. Un nodo es un conjunto de componentes. Se utiliza para reducir la complejidad de los diagramas de clases y componentes de un gran sistema. Sirve como resumen e índice.
• Diagrama de casos de uso: Muestran los casos de uso, actores y sus relaciones. Muestra quien puede hacer que y relaciones existen entre acciones (casos de uso). Son muy importantes para modelar y organizar el comportamiento del
sistema.
Diagramas Dinámicos
• Diagrama de secuencia, Diagrama de colaboración: Muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envían entre ellos. Son dos diagramas diferentes, que se puede pasar de uno a otro sin perdida de información, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es
un Diagrama de Interacción.
• Diagrama de estados: muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son útiles en sistemas que reaccionen a eventos.
• Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.
… Diagramas Dinámicos
Diagramas Recomendados
Los diagramas a representar dependerán del sistema adesarrollar, para ello se efectúan las siguientes recomendaciones dependiendo del sistema.
• Aplicación monopuesto – Diagrama de casos de uso.
– Diagrama de clases.
– Diagrama de interacción.
• Aplicación monopuesto, con entrada de eventos: – Añadir: Diagrama de estados.
• Aplicación cliente servidor: – Añadir: Diagrama de despliegue y diagrama de componentes,
dependiendo de la complejidad.
• Aplicación compleja distribuida: – Todos.
4+1 vistas de Kruchten (1995)
Vista de Diseño
Vista de Procesos
Vista de Despliegue
Vista de Implementación
Vista de los Casos de Uso
Organización de Modelos
II. Breve Tour por UML
Las vistas existentes en UML son:
• Vista de casos de uso: Se forma con los diagramas de casos de uso, colaboración, estados y actividades.
• Vista de diseño: Se forma con los diagramas de clases, objetos, colaboración, estados y actividades.
• Vista de Procesos: Se forma con los diagramas de la vista de diseños, recalcando las clases y objetos referentes a procesos.
• Vista de Implementación: Se forma con los diagramas de componentes, colaboración, estados y actividades.
• Vista de despliegue: Se forma con los diagramas de despliegue, interacción, estados y actividades
… Organización de Modelos
Propuesta de Rational Unified Process (RUP)
• M. de Casos de Uso del Negocio (Business Use-Case Model)• M. de Objetos del Negocio (Business Object Model)• M. de Casos de Uso (Use-Case Model)• M. de Análisis (Analysis Model)• M. de Diseño (Design Model)• M. de Despliegue (Deployment Model)• M. de Datos (Data Model)• M. de Implementación (Implementation Model)• M. de Pruebas (Test Model)
II. Breve Tour por UML
… Organización de Modelos
Casos de uso
• Casos de Uso es una técnica para capturar información de cómo un sistema o negocio trabaja, o de cómo se desea que trabaje
• Se trata de la descripción de escenarios o situaciones posibles donde se pone de relieve el comportamiento del sistema ante su uso por parte del usuario.
Así pues, los objetivos principales de la realización de casos de uso son:
• Definir el límite entre el sistema a desarrollar y los elementos externos a ese sistema (actores usuarios del sistema).
• Capturar el conjunto de funcionalidades y comportamientos del sistema a desarrollar.
Conceptos BásicosEn el modelado de casos de uso debemos tener encuenta dos conceptos básicos:
• Actores .• Casos de Uso.
Actores.• Los actores pueden ser personas, software o hardware; el
término actor• Representa el rol genérico de usuario del sistema. • El nombre que se le dé a un actor deberá reflejar el papel que
tendrá para el sistema.
Actor Caso de Uso
Identificar los actores nos permite:
• Definir los límites del sistema (qué forma parte del sistema y qué no).
• Desarrollar un sistema orientado al usuario que contemple todas las funcionalidades esperadas por los diferentes actores.
… Conceptos Básicos
Casos de uso.
Reflejan el uso que harán los actores del sistema; se muestran a través de ellos tanto las funcionalidades que ofrecerá el sistema, como los diferentes comportamientos posibles inherentes a las situaciones contempladas para cada una de estas.
Los casos de uso pueden estar relacionados con actores o con otros casos de uso; gráficamente una relación vendrá dada por una línea entre los casos de uso y/o actores relacionados, siendo que el extremo de dicha línea dependerá del tipo de relación.
… Conceptos Básicos
Diagramas de casos de uso.
RELACIONES.
• Asociación.- Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.
• Dependencia o Instanciación.- Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.
• Generalización.- Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>). Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).
• Relación <<include>>.
Es una simple relación de inclusión, es decir, los escenarios o situaciones posibles detalladas en un caso de uso están incluidas en otro caso de uso (aquel del que, gráficamente, parte la flecha).
• Relación <<extend>>.
Este tipo de relación refleja situaciones particulares en un caso de uso que pueden ser tratadas (extendidas) por otro. En la descripción del caso de uso que es extendido debe haber una forma de indicar en que punto entra en juego el caso de uso que lo extiende (punto de extensión); esto se representa mediante una "etiqueta" (un texto significativo entre paréntesis) como referencia del lugar donde entraría a formar parte del caso de uso extendido.
Relaciones
… Relaciones
Flujos de Eventos
• Hasta aquí hemos tenido encuenta principalmente la representación gráfica, sin embargo, aparte de esta, un diagrama de casos de uso llevará asociada una descripción textual, en forma de flujos de eventos, de cada caso de uso representado. Surgen aquí dos tipos de apartado a tener en consideración:
• Flujo de eventos principalSe trata de una descripción de los eventos que van aconteciendo en el uso habitual, es decir, cuando no se presenta ningún tipo de problema (es el denominado happy path).
• Flujo de eventos excepcionalPodemos encontrar tantos apartados de este tipo como situacionesexcepcionales se puedan plantear, siendo que para cada uno de estos escenarios atípicos se definirá el flujo de eventos correspondiente.
Ejemplos
Supervisor Verificar Situación del Cliente
Administrativo Preparar Catálogo Sistema Inventario
Tipos de Venta
… Ejemplos
En el paquete tipos de venta:
Venta Normal
Venta en Rebajas
Venta en Ofertas
Vendedor
… Ejemplos
Solicitar Nueva Tarjeta
ClienteSolicitar Préstamo
<<extend>>
[Tarjeta Caducada]
… Ejemplos
Verificar Operación
Reintegro Cuenta Corriente
Cliente
Reintegro Cuenta de Crédito
<<include>>
<<include>>