Contenido. 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo

Transcripción

1 Tutorial

2 Contenido 1. El proceso 2. Los modelos 3. Los diagramas 4. Ejemplo

3 1. El proceso Fases soportadas por UML Análisis de requisitos de usuario Análisis de requisitos de software Diseño de la plataforma Diseño de aplicaciones Diseño interfaz de usuario Análisis de requisitos de usuario Análisis de requisitos de software Diseño plataforma Diseño del modelo de datos Diseño aplicaciones

4 Análisis de requisitos de usuario Objetivos Identificar los conceptos que existen en el ámbito que se desea automatizar Identificar las relaciones entre los conceptos: herencia, pertenencia y asociación Identificar las actividades y procesos (secuencias de actividades) que realizan los actores Resultado Modelo del dominio

5 Análisis de requisitos de software Objetivos Identificar los objetos que van a estar presentes en el software que se va a desarrollar Identificar las operaciones que van a estar disponibles para aplicarlas a esos objetos Resultado Modelo del software

6 Diseño de la plataforma Objetivos Identificar los aplicaciones que van a desarrollarse para dar soporte a las necesidades analizadas Especificar las posibles configuraciones de las aplicaciones Resultado Arquitectura de la plataforma

7 Diseño de aplicaciones Objetivos Identificar los módulos con los que se va a construir cada aplicación Definir las relaciones entre estos módulos Resultado Arquitectura de las aplicaciones

8 2. Los modelos Modelo del dominio Modelo del software Modelo arquitectónico de la plataforma Modelo arquitectónico de las aplicaciones

9 Modelo del dominio Diagrama de clases del dominio Para representar los conceptos que deben tener los usuarios en el dominio en el que se desea realizar el software, y las relaciones que existen entre estos conceptos Diagramas de actividades Para representar los procesos en los que un usuario o conjunto de usuarios deben resolver conjuntamente una situación Diagrama de estado Para representar los distintos estados por los que atraviesa un sistema en la medida en la que el estado afecte a su comportamiento.

10 Modelo del software Diagrama de clases del software Para representar los conceptos que van a estar virtualizados en el software. Se deben incluir en las descripciones de clases los atributos que van a estar visibles. En este diagrama se especifican solamente las clases que van a existir en el software. Diagrama de casos de uso Para representar las situaciones en las que los usuarios pueden necesitar el software y las operaciones que van a tener disponibles.

11 Arquitectura de la plataforma Diagrama de emplazamiento Para representar los componentes de una plataforma hardware (servidores, estaciones de trabajo, terminales...) y software (bases de datos, servicios, aplicaciones). Es posible desarrollar varios diagramas de emplazamiento, de manera que se establezcan posibles configuraciones diferentes. Diagramas de actividades Para describir el comportamiento del software en una situación que afecte a muchas aplicaciones. Diagramas de estados Para describir los posibles estados del conjunto de la plataforma en función de las operaciones que ejecuten los usuarios.

12 Arquitectura de las aplicaciones (1) Diagrama de clases de diseño Para representar las clases que van a componer la arquitectura de una aplicación. También se representan las relaciones que van a existir entre esas clases (composición, herencia, dependencia, navegabilidad) Diagramas de paquetes Para agrupar clases en un software grande. Los paquetes son útiles para la prueba, ya que cada paquete debe tener una o mas unidades de prueba que compruebe el comportamiento del paquete Diagrama de estados Para representar los estados en los que se puede encontrar un objeto de una clase.

13 Arquitectura de las aplicaciones (2) Diagramas de interacción de objetos Para describir como grupos de objetos colaboran para proporcionar algún comportamiento en una situación simple como ejecutar una operación, atender algún evento... Hay dos tipos de diagramas de interacción Diagrama de colaboración Son útiles en los casos de interacciones síncronas entre objetos. Diagrama de secuencia Son muy útiles para representar procesos concurrentes y respuestas asíncronas.

14 3. Los diagramas Diagrama de clases Diagrama de casos de uso Diagrama de interacción Diagrama de paquetes Diagrama de estados Diagrama de actividades Diagrama de emplazamiento

15 Diagrama de clases (1) Descripción de una clase Se utiliza en el análisis para describir el contenido de una clase y las operaciones que puede ejecutar el usuario. Se utiliza en el diseño de la arquitectura de las aplicaciones para describir la estructura de una clase y los servicios que ofrecen a otras clases. Clase [visibilidad] atributo: tipo [=valordefecto] [visibilidad] atributo: tipo [=valordefecto]... [visibilidad] operacion(argumentos): retorno [visibilidad] operacion(argumentos): retorno... Visibilidad de los atributos y operaciones + publico - privado # protegido

16 Diagrama de clases (2) Relación de asociación Representa cualquier tipo de relación entre clases. No obstante en caso de relaciones estándares se aconseja utilizar la notación disponible. Fundamentalmente se utilizan en el análisis Clase A Papel de B. Cardinalidad Papel de A. Cardinalidad Clase B Papel de clase representa el tipo de asociación entre las clases Cardinalidad [ n n,m n..m * +] Clase A { Restricción } Clase B Restricción. Son reglas escritas en lenguaje natural que establecen en que casos es válida la relación Clase A Clase B Clases asociadas. Son clases cuyo contenido es derivado de una relación Clase asociación Clase A Cualificador Clase B Cualificador. Son relaciones en las que existe un cualificador sirve como elemento de búsqueda o selección en una relación con muchos elementos

17 Diagrama de clases (3) Relación de generalización La generalización se asocia a las relaciones es-un en el análisis y herencia en el diseño, es decir, el subtipo tiene todas las características que tiene el supertipo. Relación de agregación Representa la composición de un objeto. Se utiliza para representar las relaciones es-parte-de en el análisis Clase Clase I Clase A Clase Ax Criterio discriminante Clase Ay Criterio discriminante define la jerarquía representada Relación de composición También representa la composición de un objeto, pero la existencia de los componentes es dependiente de la existencia de la clase que lo contiene. Se utiliza par representar la composición de una clase en el diseño Clase C Clase I Clase Clase I C

18 Diagrama de clases (4) Relación de navegabilidad Se utilizan en diseño para indicar que una clase accede al contenido de otra clase. Relación de dependencia Se utilizan en el diseño para indicar que una clase accede a los servicios de otra clase. Fuente Destino Clase Clase Clase parametrizada Se utilizan en el diseño para representar plantillas (templates). Son muy útiles para definir colecciones Interfaces Se utilizan en el diseño para representar Plantilla Clase

19 Diagramas de casos de uso Hay que distinguir entre las intenciones del usuario y las interacciones con el sistema. Un caso de uso representa una intención de un usuario y las interacciones que va a realizar dicho usuario. En un diagrama de casos de uso se representan varios casos de uso para cumplir con las intenciones de un usuario. También se utilizan para representar las operaciones que ejecuta un actor virtual. «usa» Caso de uso «extiende» Actor

20 Diagrama de actividades Este diagrama se puede utilizar en el análisis de requisitos de usuario para representar las actividades de un proceso y las condiciones de ejecución del mismo. Actividad condición transición para n elementos * También se puede utilizar en el diseño de la arquitectura de la plataforma para describir el comportamiento del software en una situación que afecte a muchas aplicaciones. Actividad condición sincronización Actividad Actividad condición transición Actividad

21 Diagrama de secuencia Este diagrama se utiliza en el diseño de la arquitectura de las aplicaciones para representar una traza de un proceso, aunque también es muy útil para representar las interacciones entre aplicaciones cliente-servidor o aplicaciones multihilo con varios procesos. objeto: clase create mensaje objeto: clase retorno autodelegación El diagrama permite representar durante el tiempo de vida de un objeto su comportamiento. destroy

22 Diagrama de colaboración El significado de un diagrama de colaboración es bastante similar al diagrama de secuencia. Fudamentalmente se utiliza en el diseño de la arquitectura de las aplicaciones para describir la traza de un proceso. objeto: clase 1: mensaje(..) : clase objeto 1.1*: mensaje(..) 1.2:[condicion] mensaje(..)

23 Diagrama de paquetes Este diagrama se utiliza para representar los detalles del diseño de la arquitectura de las aplicaciones. Se representan las unidades de código que se hayan desarrollado así como la visibilidad entre ellas. Para cada unidad se identifican los módulos que contienen. paquete A paquete B Clase A Clase C Clase B

24 Diagrama de estados Este diagrama se puede utilizar tanto el análisis de requisitos de usuario como en el diseño de la arquitectura de las aplicaciones. Un diagrama de estados se emplea cuando el estado de un sistema u objeto pueda afectar a su comportamiento. Estado var: tipo=valor comienzo entry / acción exit / acción evento / acción do / actividad Estado evento[condición] / acción Estado En el análisis representa los estados de un sistema, mientras que el diseño representa los estados de un objeto. Estado Estado Estado fin

25 Diagrama de emplazamiento Para representar los componentes de una plataforma hardware (servidores, estaciones de trabajo, terminales...) y software (bases de datos, servicios, aplicaciones). Es posible desarrollar varios diagramas de emplazamiento, de manera que se establezcan posibles configuraciones diferentes. nodo componente componente