La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

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,

Presentaciones similares


Presentación del tema: "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,"— Transcripción de la presentación:

1 UML

2 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

3 Historia de UML Comenzó como el Método Unificado, con la participación de Grady Booch y Jim Rumbaugh. Se presentó en el OOPSLA95 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

4 … Historia de UML Nov 97 UML aprobado por el OMG UML 1.2 UML 1.3 UML UML 2.0 Revisiones menores I. Introducción: UML

5 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 DSouza) 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

6 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

7 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

8 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

9 UML aglutina enfoques OO UML Rumbaugh Jacobson Meyer Harel Wirfs-Brock Fusion 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

10 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

11 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

12 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

13 Breve recorrido por UML

14 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

15 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

16 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

17 ... Diagramas de UML Use Case Diagrams Use Case Diagrams Diagramas de Casos de Uso Scenario Diagrams Scenario Diagrams Diagramas de Colaboración State Diagrams State Diagrams Diagramas de Componentes Component Diagrams Component Diagrams Diagramas de Distribución State Diagrams State Diagrams Diagramas de Objetos Scenario Diagrams Scenario Diagrams Diagramas de Estados Use Case Diagrams Use Case Diagrams Diagramas de Secuencia State Diagrams State Diagrams Diagramas de Clases Diagramas de Actividad Modelo II. Breve Tour por UML Los diagramas expresan gráficamente partes de un modelo

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

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

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

21 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

22 Diagramas Recomendados Los diagramas a representar dependerán del sistema a desarrollar, 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.

23 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

24 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

25 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

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

27 Conceptos Básicos En el modelado de casos de uso debemos tener en cuenta 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. ActorCaso de Uso

28 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

29 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

30 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 ( >) o de Herencia ( >). Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

31 Relación >. 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 >. 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

32 … Relaciones

33 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 principal Se 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 excepcional Podemos encontrar tantos apartados de este tipo como situaciones excepcionales se puedan plantear, siendo que para cada uno de estos escenarios atípicos se definirá el flujo de eventos correspondiente.

34 Ejemplos

35 … Ejemplos En el paquete tipos de venta:

36 … Ejemplos

37


Descargar ppt "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,"

Presentaciones similares


Anuncios Google