Índice.

Transcripción

1 Módulo 2 UML

2 Índice Introducción a UML Lenguaje Unificado de Modelado (UML) Diagramas UML Diagramas de casos de uso Diagramas estructurales: Clases Diagramas estructurales: Objetos Diagramas de interacción: Secuencia Diagramas de interacción: Colaboracion Diagramas de comportamiento: Estado Diagramas de comportamiento: Actividad Diagramas de implementación: Componentes Diagramas de implementación: Despliegue

3 Introducción UML A principios de los 90 existían muchos métodos de análisis y diseño Orientado a Objetos. Estos métodos, se basaban en los mismos conceptos pero con distinta notación lo cual creaba mucha confusión. En 1994 Grady Booch y Jim Rumbaugh de Rational Software Corporation decidieron unificar sus trabajos en un método único: el método unificado (The Unified Method) cuya primera versión fue presentada en Octubre de Un año después se les unió Jacobson y el método unificado se transformo en UML (The Unified Modeling Method).

4 Introducción UML Objetivos Al finalizar este módulo deberías ser capaz de: Conocer las características básicas del lenguaje modelado unificado (UML) y aplicarlas al análisis y diseño Orientado a Objetos Analizar los requisitos del sistema para determinar los casos de uso y el modelo de dominio Crear los principales diagramas para modelar una aplicación tanto desde el punto de vista dinámico como estático

5 El proceso de desarrollo software El proceso de desarrollo de software es un método de organizar las actividades relacionadas con la creación, presentación y mantenimiento de los sistemas software. En él existen cinco actividades fundamentales comunes a todos los procesos software: planificación y selección del software análisis del software diseño del software implantación y operación del software mantenimiento del software

6 El proceso de desarrollo software Modelos El modelo captura una vista de un sistema del mundo real. Es por tanto 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 Estos modelos se visualizan a través de un conjunto de diagramas

7 Lenguaje Unificado de Modelado (UML) Qué es UML? Cuando hablamos del lenguaje unificado de modelado o UML, nos estamos refiriendo a un lenguaje de propósito general para el modelado orientado a objetos que combina notaciones de los modelados OO, de datos, componentes y workflows. Su objetivo es ser una notación estándar Este lenguaje define una notación que se expresa como diagramas que sirven para representar modelos, subsistemas o parte de ellos. Además, define una estructura para ir del análisis al diseño y del diseño a la implementación.

8 Lenguaje Unificado de Modelado (UML) Qué NO es UML? Antes de seguir avanzando, es importante tener en cuenta que el estándar UML no define un proceso de desarrollo específico, sólo se trata de una notación En otras palabras, se puede aplicar en el desarrollo de software para dar soporte a una metodología (como RUP), pero no especifica en sí mismo la metodología o proceso a usar Asimismo, al no ser un método de desarrollo, es independiente del ciclo de desarrollo.

9 Lenguaje Unificado de Modelado (UML) Qué ventajas e inconvenientes tiene UML? Los principales inconvenientes que nos podemos encontrar en el lenguaje unificado son: No cubre todas las necesidades de especificación de un proyecto software Falta integración con respecto a otras técnicas, tales como patrones de diseño, interfaces de usuario, documentación etc. Las principales ventajas que aporta el lenguaje UML son: Permite conectarse a lenguajes de programación Permite documentar todos los artefactos de un proceso de desarrollo Es un estándar que, además será el predominante en los próximos años

10 Diagramas UML El lenguaje UML cuenta con varios tipos de diagramas que reflejan diferentes aspectos de las entidades representadas Estos diagramas son los siguientes: Diagramas de casos de uso: Acciones del sistema desde el punto de vista del usuario Diagramas estructurales: Diagramas de clases: Para modelar la estructura estática de las clases del sistema Diagramas de Objetos: Modelan instancias de los elementos contenidos en el diagrama Diagramas de interacción: Diagramas de secuencias: Para modelar el paso de mensajes entre objetos Diagramas de colaboración: Para modelar interacciones entre objetos

11 Diagramas UML Diagramas de comportamiento Diagrama de estado: Para modelar el comportamiento de los objetos del sistema Diagrama de actividad: Para modelar el comportamiento de los casos de uso, objetos u operaciones Diagramas de implementación: Diagrama de componentes: Para modelar componentes Diagrama de despliegue: Para modelar la distribución del sistema

12 Identificación de los requisitos Diagramas de casos de uso Los casos de uso son una técnica de recolección y especificación de requisitos que ayuda a obtener los requerimientos desde el punto de vista del usuario En un diagrama de casos de uso, podemos distinguir dos elementos, como los actores y los casos de uso Los Actores : Son los Roles que juega un usuario con respecto al sistema. Un usuario puede jugar diferentes roles e intervenir en varios casos de uso. A su vez, en un mismo caso de uso, puede intervenir diferentes actores Los Casos de Uso: Son iteraciones típicas entre los usuarios y el sistema. Es decir, un caso de uso es una operación o tareas específicas que se realizan tras una orden de algún agente externo, originada por una petición de un actor, o bien desde la innovación de otro caso de uso Los casos de uso se determinan observando y precisando, actor por actor, las secuencias de interacción y los escenarios desde el punto de vista del usuario

13 Identificación de los requisitos Diagramas de casos de uso Con la ayuda de estos dos elementos, vamos a crear el diagrama de caso de uso, para lo cual deberemos seguir tres pasos: Encontrar actores Encontrar casos de uso Encontrar relaciones entre actores y casos de uso

14 Identificación de los requisitos Diagramas de casos de uso Tanto si el cliente quiere realizar un reintegro como si quiere realizar un integro, tiene una tarea común a ambos

15 Identificación de los requisitos Diagramas de casos de uso El cliente además también podría realizar un reintegro con VISA, lo que sería similar a realizar el reintegro pero con sus peculiaridades, con lo cual extiende de Realizar reintegro

16 Identificación de los requisitos Diagramas de casos de uso Podría darse el caso también de que el cliente realizara una transferencia por internet, para lo cual debería identificarse

17 Diagramas estructurales Diagrama de clases En líneas generales, en este tipo de modelado estructural se describen los tipos de objetos de un sistema y las relaciones estáticas que existen entre ellos Para detallar este tipo de diagrama, se usan muchos de los otros diagramas, incluso el diagrama de casos de uso aporta información para establecer las clases, objetos, atributos y operaciones tan útiles en el diagrama de clase Es el diagrama principal para el análisis y el diseño en orientación a objetos Muestra las relaciones estructurales y estáticas entre las clases que se irán refinando durante todo el proceso de desarrollo Los elementos de los diagramas de clases son: Clases: Formadas por atributos y operaciones Relaciones: Herencia, asociación, agregación y dependencia

18 Diagramas estructurales Diagrama de clases Una clase es una descripción (plantilla) de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Así, un objeto es una instancia de una clase Cada clase se representa en el diagrama como un rectángulo con tres compartimentos : Nombre de la clase Atributos: características de los objetos que pueden tomar valores. Su sintaxis es: visibilidad nombre [multiplicidad] : tipo = valor-inicial {propiedades} Métodos: definen la manera en la que los objetos pueden interactuar con el entorno, es decir, lo que una clase puede realizar. Su sintaxis es: visibilidad nombre (parámetros) : tipo-devuelto {propiedades}

19 Diagramas estructurales Diagrama de clases: Ejemplo

20 Diagramas estructurales Diagrama de clases: Privacidad En la visibilidad o encapsulación de los atributos y los métodos existen tres niveles : public (+): indica que el atributo/método será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos los lados private (-): indica que el atributo/método sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar ) protected (#): indica que el atributo/método no será accesible desde fuera de la clase, pero si podrá ser accedido por métodos de la clase además de las subclases que se deriven. Más adelante, cuando veamos el término herencia, veremos más al detalle este aspecto

21 Diagramas estructurales Diagrama de clases: Relaciones entre clases Cardinalidad: Indica el grado y nivel de dependencia. Se anotan en cada extremo de la relación y éstas pueden ser: Exactamente uno: 1,(1) Uno o muchos: 1..*(1..n)(al menos uno) 0 o muchos: 0 * (0.. N), * Número fijo: m (m denota el número) Número variable, pero limitado, por ejemplo, por lo menos 2, pero no más de 6 : 2..6,(2,6)

22 Diagramas estructurales Diagrama de clases: Relaciones entre clases (II) Asociación: Permite asociar objetos que colaboran entre sí expresando una conexión bidireccional entre ellos Cada extremo de la asociación también tiene un valor de multiplicidad o cardinalidad, que indica cuantos objetivos de ese lado de la asociación están relacionados con un objeto del extremo contrario

23 Diagramas estructurales Diagrama de clases: Relaciones entre clases (III) Agregación: Representa una relación parte de entre objetos, de tal modo que cuando los objetos de un todo están compuestos por la unión de los objetos de otra parte existe una agregación

24 Diagramas estructurales Diagrama de clases: Relaciones entre clases (IV) Composición: Son asociaciones que representan agregaciones muy fuertes. Las composiciones forman relaciones completas, pero dichas relaciones son tan fuertes que las partes no pueden existir por sí mismas. Únicamente existen como parte del conjunto, y si este es destruido las partes también lo son Por ejemplo: Un detalle es parte de una compra, es una relación de agregación más fuerte que la del ejemplo anterior. Por lo tanto, podemos decir que un detalle no puede existir si no existe una compra, esto es, se trata de una relación de composición.

25 Diagramas estructurales Diagrama de clases: Relaciones entre clases (V) Generalización o herencia: Es una asociación entre una clase más general (superclase o clase padre) y una clase más especifica (subclase o clase hija) La clase hija, además de poseer sus propios atributos, hereda los métodos y atributos visibles de la clase padre (public y protected)

26 Diagramas estructurales Diagrama de clases: Relaciones entre clases (VI) Dependencia: Tipo de relación particular donde el cambio en una clase afecta a la otra Por ejemplo: Una tarjeta depende de una cuenta, con lo cual, cualquier cambio en la tarjeta afectará a la cuenta

27 Diagramas estructurales Diagrama de clases: Abstracción Además de la clase y las relaciones de clase que componen los diagramas de clase, existen otros elementos que conviene tener en cuenta, como son: 1. Clase abstracta: es una clase que posee métodos abstractos (sin implementación) y, por tanto, no puede ser instanciada. Basta con que un método sea abstracto para que la clase también lo sea. La única forma de utilizarla es definiendo subclases que implementen los métodos abstractos definidos Para denotar una clase abstracta, se emplea el nombre de la clase y de los métodos con letra "itálica". Ejemplo:

28 Diagramas estructurales Diagrama de clases: Interface 2. Interface: es una clase completamente abstracta que se representa mediante una caja con el nombre y operaciones, y el estereotipo «interface» o mediante un círculo pequeño con el nombre de la interfaz debajo Ejemplo: Interface

29 Diagramas estructurales Diagrama de clases: Polimorfismo 3. Polimorfismo: es la capacidad que tienen los objetos de una clase de responder al mismo mensaje o evento en función de los parámetros utilizados durante su invocación. Así un objeto polimórfico es una entidad que puede contener valores de diferentes tipos durante la ejecución de un programa En otras palabras representa la posibilidad de desencadenar operaciones distintas en respuesta a un mismo mensaje Casa subclase hereda las operaciones pero puede modificar localmente el comportamiento de estas Ejemplo:

30 Diagramas estructurales Diagrama de clases: Paquetes 4. Paquetes: los paquetes ofrecen un mecanismo general para la organización de los modelos/subsistemas agrupando elementos de modelado Cada paquete corresponde a un submodelo (subsistema) del modelo (sistema) Hay que tener en cuenta que un paquete puede contener otros paquetes, sin límite de anidamiento, pero cada elemento pertenece a (está definido en) un solo paquete y cada uno de ellos puede contener más de una clase Una clase de un paquete puede aparecer en otro paquete por la importación a través de una relación de dependencia entre paquetes. Estas relaciones entre paquetes son iguales que las relaciones entre clases Ejemplo:

31 Diagramas estructurales Diagrama de clases: Ejemplo

32 Diagramas de interacción Diagramas de secuencia Estos diagramas de secuencia, al igual que los diagramas de colaboración que veremos en este mismo apartado, pertenecen al grupo que podíamos denominar diagramas de interacción, los cuales describen como los objetos colaboran entre sí para realizar cierta actividad Los diagramas de secuencia muestran en detalle un caso de uso del negocio, del sistema o un determinado escenario para cada caso de uso Su objetivo es describir el comportamiento dinámico del sistema Además, muestran el intercambio de mensajes en un momento dado, poniendo especial énfasis en el orden y momento que se envían los mensajes a los objetos

33 Diagramas de interacción Diagramas de secuencia (II) Los diagramas de secuencia se componen de 3 elementos: Línea de vida Mensajes Activación

34 Diagramas de interacción Diagramas de secuencia (III) Línea de vida: La línea de vida de un objeto representa la vida del mismo durante la interacción En un diagrama de secuencia un objeto se representa con una línea vertical punteada con un rectángulo de encabezado que contiene el nombre del objeto y el de su clase, en un formato nombreobjeto:nombreclase. El inicio de la línea de vida se corresponde con el momento de creación del objeto. Si un objeto es destruido antes de terminar el diagrama se representa con un aspa

35 Diagramas de interacción Diagramas de secuencia (IV) Mensajes: El envío de mensajes entre los objetos se denota mediante una flecha que va desde el objeto que emite el mensaje hacia el objeto que lo ejecuta A la flecha se le asocia una etiqueta con el mensaje y los argumentos: También es posible añadir a los mensajes, condiciones e iteraciones: La condición se representa mediante una condición booleana entre corchetes; de esa manera el mensaje será enviado si la condición es cierta. La iteración se representa mediante un asterisco y una expresión entre corchetes indicando el número de veces que se ejecuta. Un objeto puede enviar mensajes a si mismo

36 Diagramas de interacción Diagramas de secuencia (V) Activación: Muestra el periodo de tiempo en el cual el objeto se encuentra desarrollando alguna operación, bien sea por si mismo o por medio de alguno de sus atributos Este elemento se representa mediante un rectángulo superpuesto a la línea de vida de un objeto Su tamaño depende de la duración de la acción realizada por el objeto La parte superior corresponde al inicio de la acción y la parte inferior indica la terminación

37 Diagramas de interacción Diagramas de secuencia (VI) Cuando el cliente llega al cajero, el cliente introduce la tarjeta y el cajero le solicitará el pin. Una vez que introduce el pin, el cajero le pedirá que introduzca la operación a realizar. En ese instante, el cajero accederá a la cuenta donde consultará el saldo y se lo enviará al cajero para que se lo muestre al cliente

38 Diagramas de interacción Diagramas de colaboración Los diagramas de colaboración muestran las iteraciones que ocurren entre los objetos que participan en una situación determinada Es más o menos la misma información que la mostrada por los diagramas de secuencia, pero los diagramas de colaboración fijan el interés en las relaciones entre los objetos y su topología Estos diagramas se componen de tres elementos: Objetos Mensajes Enlaces

39 Diagramas de interacción Diagramas de colaboración (II) Objetos: Se representan mediante un rectángulo en cuyo interior se coloca el nombre del objeto y el nombre de la clase a la que pertenece (nombre del objeto:nombreclase) Mensajes: Se representa mediante una pequeña flecha asociado a un enlace La dirección de la flecha indica el sentido del mensaje Es necesario indicar delante del mensaje su numero dentro de la secuencia de mensajes que se produce También pueden contener condiciones e iteraciones al igual que en los diagramas de secuencia Enlace: Es una instancia de una asociación en un diagrama de clases y se representa con una línea continua que une dos objetos

40 Diagramas de interacción Diagramas de colaboración (III)

41 Diagramas de comportamiento Diagramas de estado Los diagramas de estado muestran el conjunto de estados por los cuales pasa un objeto durante su vida en una aplicación, junto con los cambios que permiten pasar de un estado a otro Estos diagramas se componen de tres elementos: Un estado es una condición durante la vida de un objeto, de forma que cuando dicha condición se satisface se lleva a cabo alguna acción o se espera por un evento. Los estados se representan mediante un rectángulo con bordes redondeados. Entre ellos podemos distinguir dos tipos especiales: inicio y fin. La razón por la que son especiales es que no hay ningún evento que pueda devolver a un objeto a su estado de inicio, y de la misma forma, no hay ningún evento que pueda sacar a un objeto de su estado de fin. Una transición de un estado A a un estado B, se produce cuando se origina el evento asociado y se satisface la condición especificada, en cuyo caso se ejecuta la acción de salida A, la acción de entrada de B y la acción asociada a la transición

42 Diagramas de comportamiento Diagramas de estado (II) Evento: Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Esta ocurrencia puede ser: Condición que toma el valor verdadero o falso (se representa poniendo la condición entre corchetes) Recepción de una señal de otro objeto en el modelo Recepción de un mensaje Paso de cierto periodo de tiempo, después de entrar al estado, o de cierta hora y fecha particular

43 Diagramas de comportamiento Diagramas de estado (III) Los posibles estados del cajero son: Libre Ocupado Fuera de servicio En mantenimiento Por ejemplo, si el cajero está libre y alguien (un cliente) lo ocupa, el cajero pasará al estado ocupado.

44 Diagramas de comportamiento Diagramas de actividad Los diagramas de actividad describen la secuencia de las actividades en un sistema Son una forma especial de los diagramas de estado, que únicamente (o mayormente) contienen actividades Puede dar un detalle a un caso de uso, un objeto o un mensaje de un objeto Estos diagramas sirven para representar transiciones internas, sin hacer mucho énfasis en transiciones o eventos externos. Generalmente modelan los pasos de un algoritmo y pueden especificar: Un método Un caso de uso Un proceso de negocio (workflow)

45 Diagramas de comportamiento Diagramas de actividad (II) Estos diagramas se componen de tres elementos : Estado de acción:rrepresenta un estado con acción interna con, por lo menos, una transición que identifica la culminación de la acción (por medio de un evento implícito) No deben tener transiciones internas ni transiciones basadas en eventos (si este es el caso, se representan en un diagrama de estados) Los estados de acción permiten modelar un paso dentro del algoritmo y se representan por un rectángulo con bordes redondeados Transiciones: Las flechas entre estados representan transiciones con evento implícito. Las transiciones pueden tener una condición en el caso de decisiones Decisiones: Se representa mediante un rombo al cual llega la transición del estado inicial y del cual salen las múltiples transiciones de los estados finales.

46 Diagramas de comportamiento Diagramas de actividad (III) En el siguiente ejemplo de diagrama de actividad, cuando el cliente introduce la tarjeta, puede ocurrir que esta esté operativa o no Si no lo está finaliza la actividad En cambio, si la tarjeta está operativa el cliente deberá introducir el pin Si este es introducido erróneamente, aquí finaliza la actividad, pero si es válido, el cliente podrá realizar la operación deseada.

47 Diagramas de implementación Diagramas de componentes e implementación Tanto los diagramas de componentes como los diagramas de despliegue pueden encuadrarse dentro de los diagramas de implementación Los diagramas de implementación residen en los nodos del sistema y se trata de una colección de componentes y la implementación de los subsistemas que los contienen Asimismo modelan artefactos tales como ejecutables, bibliotecas, tablas, ficheros. En líneas generales, podemos decir que representan el empaquetamiento físico de elementos lógicos tales clases, interfaces, etc. Ahora que ya conocemos lo que son los diagramas de implementación, vamos a descubrir los dos tipos que nos podemos encontrar comenzando por los diagramas de componentes. Estos muestran la organización de los componentes software que puede ser código fuente, binario, ejecutable o una librería con una interfaz definida. Esta interfaz establece las operaciones externas de un componente.

48 Diagramas de implementación Diagramas de componentes Muestran la organización de los componentes software que puede ser código fuente, binario, ejecutable o una librería con una interfaz definida Esta interfaz establece las operaciones externas de un componente Los componentes son paquetes estereotipados en «subsistemas» para incorporar la noción de biblioteca de compilación, pudiendo agruparse en paquetes según un criterio lógico y con vistas a simplificar la implementación Así pues, en los diagramas de componentes se representan las relaciones de dependencia entre componentes o entre un componente y una interfaz de otro

49 Diagramas de implementación Diagramas de componentes (II) Formados por los siguientes elementos: Componente: Se representa con un rectángulo con dos pequeños rectángulos superpuesto perpendicularmente en el lado izquierdo Para distinguir los tipos de componentes se les puede asignar un estereotipo cuyo nombre estará dentro del símbolo << >> Relación de dependencia: Se representa mediante una línea discontinua con una flecha que apunta al componente o interfaz que provee del servicio o facilidad del otro. Puede tener un estereotipo que se coloca junto a la línea Interfaz: Se representa con un pequeño círculo situado junto al componente que lo implementa y unido a él por una línea continua La interfaz puede tener un nombre que se escribe junto al circulo Un componente puede proporcionar más de una interfaz

50 Diagramas de implementación Diagramas de despliegue Los diagramas de despliegue muestran las relaciones entre los componentes hardware y software en el sistema final, es decir, la configuración de los elementos de procesamiento en tiempo de ejecución y los componentes software (procesos y objetos que se ejecutan en ellos) En estos diagramas se representan dos tipos de elementos, nodos y conexiones, así como la distribución de componentes del sistema de información con respecto a la partición física del sistema Los componentes se ejecutan en nodos Un nodo es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional que puede tener memoria y capacidad de procesamiento Representan el despliegue físico de los componentes. Además cada nodo puede contener instancias de componentes.

51 Diagramas de implementación Diagramas de despliegue (II) A la hora de representarse, contamos con: nodos: Representados por cubos conexiones: Como líneas de comunicaciones Se reflejan los protocolos de comunicaciones Se refleja la cantidad de nodos existentes El diagrama de despliegue muestra la configuración de los nodos que participan en la ejecución y de los componentes que residen en los nodos. Incluye nodos y arcos que representa conexiones físicas entre nodos <<cliente>> <<Interface>> Terminal de de Cajero cajero <<TCP/IP>> <<Servidor>> Bases de datos <<RDSI>> <<RDSI>> Control

52 Módulo 2 UML