uml. situación de partida diversos métodos y técnicas oo, con muchos aspectos en común pero...

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


… 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


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


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)


… 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


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


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”


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.


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


… 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


... 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


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


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)


… 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>>

uml. situación de partida diversos métodos y técnicas oo, con muchos aspectos en común pero...

Documents