1. INTRODUCCIÓN A UML...

Transcripción

1 1. INTRODUCCIÓN A UML QUÉ ES UML QUE ES UN MODELO COMO NACE UML DONDE SE UTILIZA INTRODUCCIÓN A LOS DIAGRAMAS DE UML INTRODUCCIÓN LOS DIAGRAMA DE UML Diagrama de Clases Diagrama de Objetos Diagrama de Casos de Uso Diagrama de Estados Diagrama de Actividades Diagrama de Comunicación Diagrama de Secuencia Diagrama de Componentes Diagrama de Despliegue CLASIFICACIÓN Diagramas Estáticos Diagramas Dinámicos Diagramas Estructurales Diagramas de Comportamiento EL DIAGRAMA DE CLASES (CLASS DIAGRAM) DEFINICIÓN OBJETIVO ELEMENTOS Clase Interfaz RELACIONES Generalización Asociación Composición Agregación Implementación o Realización CLASES ESTEREOTIPADAS Que es un estereotipo de clase El estereotipo Boundary El estereotipo Control El estereotipo Entity Representación grafica APLICACIÓN Modelo de Análisis o Modelo Conceptual Modelo de Diseño Diseño de Base de Datos EJEMPLO DIAGRAMA DE OBJETOS (OBJECT DIAGRAM) DEFINICIÓN OBJETIVO ELEMENTOS Objeto RELACIONES Vínculo Tel. (54) (011) Página 1

2 Vínculo Direccional APLICACIÓN Fotografía del sistema EJEMPLO DIAGRAMA DE CASOS DE USO DEFINICIÓN OBJETIVO ELEMENTOS Actor Caso de Uso (Use Case) RELACIONES Asociación Generalización Especialización Inclusión Extensión APLICACIÓN Captura de Requisitos Funcionales Modelo de Casos de Uso Establecimiento de contratos Construcción de Casos de Prueba (Test Cases) EJEMPLO DIAGRAMA DE ESTADOS DEFINICIÓN OBJETIVO ELEMENTOS Estado (State) Estado compuesto (Sub-machine State) Pseudo-Estado Inicial (Initial State) Pseudo-Estado Final (Final State) Punto de Entrada (Entry Point) Punto de Salida (Exit Point) Estado de Sincronización (Sync State) Estado Histórico (Shallow History State) Estado Histórico Profundo (Deep History State) Fork Join Unión (Junction) Decisión (Choice) RELACIONES Transición APLICACIÓN Seguimiento de un objeto EJEMPLO DIAGRAMA DE ACTIVIDADES DEFINICIÓN OBJETIVO ELEMENTOS Actividad (Activity) Actividad Estructurada (Structured Activity) Acción (Action) Objeto (Object) Datastore Object Tel. (54) (011) Página 2

3 CentralBuffer Node Pseudo-Estado Inicial (Initial State) Pseudo-Estado Final (Final State) Señal de Envío (Send Signal) Señal de Recepción (Receive Signal) Manejador de Excepciones (Exception Handler) Fork Join Decisión (Choice) Partición (Partition) RELACIONES Flujo de control (Control Flow) Flujo de objeto (Object Flow) Flujo de objeto con Pines (Pinned Object Flow) Flujo de Interrupción (Interrupt Flow) APLICACIÓN Desarrollo de aplicaciones procedurales Modelado de procesos de negocio - Workflow EJEMPLO DIAGRAMA DE COMUNICACIÓN (COMMUNICATION DIAGRAM) DEFINICIÓN OBJETIVO ELEMENTOS Actor Objeto Boundary Control Entity RELACIONES Vinculo Vinculo Direccional Mensaje APLICACIÓN Realización de Casos de Uso en el Modelo de Análisis EJEMPLO DIAGRAMA DE SECUENCIA (SEQUENCE DIAGRAM) DEFINICIÓN OBJETIVO ELEMENTOS Actor Línea de vida (LifeLine) Boundary Control Entity RELACIONES Mensaje APLICACIÓN Realización de Casos de Uso en el Modelo de Diseño EJEMPLO DIAGRAMA DE COMPONENTES DEFINICIÓN OBJETIVO ELEMENTOS Tel. (54) (011) Página 3

4 Componente Interfaz RELACIONES Utilización (Use) Implementación (Implementation) APLICACIÓN Modelado de un Sistema Modelado de un Modulo EJEMPLO DIAGRAMA DE DESPLIEGUE DEFINICIÓN OBJETIVO ELEMENTOS Nodo (Node) Componente (Component) Dispositivo (Device) Ambiente de Ejecución (Execution Environment) Especificación de Despliegue (Deployment Spec) RELACIONES Asociación Utilización (Use) Comunicación (Communication Path) APLICACIÓN Definición de la arquitectura de un sistema EJEMPLO CONCEPTOS GENERALES ESTEREOTIPOS VALOR ETIQUETADO (TAGGED VALUES) INGENIERÍA DIRECTA INGENIERÍA INVERSA EL LENGUAJE XMI INTRODUCCIÓN AL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE DEFINICIÓN HISTORIA El proceso Objectory El proceso Objectory de Rational El Proceso Unificado de Rational (RUP) LA NECESIDAD DE UNA METODOLOGÍA FUNDAMENTOS DEL PROCESO UNIFICADO DE DESARROLLO Dirigido por Casos de Uso Centrado en una arquitectura Iterativo e incremental CICLO DE VIDA DEL PROCESO UNIFICADO Fase de Inicio Fase Elaboración Fase de Construcción Fase de Transición LABORATORIOS LABORATORIO #1 DIAGRAMA DE CLASES Caso de Estudio Construcción del Diagrama LABORATORIO #02 DIAGRAMA DE OBJETOS Tel. (54) (011) Página 4

5 Caso de Estudio Construcción del Diagrama LABORATORIO #03 DIAGRAMA DE CASOS DE USO Caso de Estudio Construcción del Diagrama LABORATORIO #04 DIAGRAMA DE ESTADOS Caso de Estudio Construcción del Diagrama LABORATORIO #05 DIAGRAMA DE ACTIVIDADES Caso de Estudio Construcción del Diagrama LABORATORIO #06 DIAGRAMA DE SECUENCIA Caso de Estudio Construcción del Diagrama LABORATORIO #07 DIAGRAMA DE COMUNICACIÓN Caso de Estudio Construcción del Diagrama Tel. (54) (011) Página 5

6 1. Introducción a UML 1.1. Qué es UML UML es un lenguaje grafico que permite modelar, visualizar y documentar sistemas. Esta compuesto por distintos diagramas que permiten ir representando las distintas vistas de un sistema, cada diagrama tiene un objetivo bien definido. UML significa Unified Modeling Language o Lenguaje Unificado de Modelado, y esta basa en tres principios fundamentales: Es un Lenguaje: está formado por elementos y reglas bien definidas, que poseen su propia sintaxis y semántica Esta Unificado: unifica los distintos criterios utilizados antes de su creación, es decir que toma las mejores propuestas de herramientas previas para presentar una propuesta sumamente abarcativa e integradora Permite Modelar: está basado en la construcción de modelos que permite representar abstracciones de la realidad. UML esta estrechamente ligado con el paradigma de objetos, lo que permite construir sistemas de información de una forma mucho mas intuitiva, integrada y sencilla con el proceso de desarrollo. UML no es una metodología que presenta los pasos a seguir para realizar un desarrollo, sino que es un lenguaje grafico de modelado Que es un Modelo Un modelo es una posibilidad de visualizar a escala o de una manera simulada algo que será construido en la realidad. Es posible decir que antes de construir un edificio se realizan maquetas a escala que representa modelos a seguir, así como también cuando se construye un auto se confeccionan distintos planos o modelos a escala para intentar simular o prever su comportamiento. Académicamente, es posible definirla como una abstracción de la realidad, es una simplificación de la realidad, con el objetivo final de pasar del modelo a producto real. Tel. (54) (011) Página 6

7 Los modelos pueden ser expresados en distintos niveles de precisión, desde algo muy genérico presentando una visión, hasta algo mucho mas especifico que representa un gran compromiso con el producto a construir Como nace UML La historia cuenta que UML da sus primeros pasos con al unión de los tres amigos : Booch, Rumbaugh y Jacobson. En los años 80 cada uno utilizaba un lenguaje propietario aunque como denominador común tenían como objetivo el desarrollo de sistemas, con previa modelizacion. A partir de los años 90 comienzan a intercambiar ideas para intentar unificar criterios. Booch es el fundador de Rational Software Corp, y recluta en el año 1995 a Rumbaugh y Jacobson para comenzar a determinar una especificación genérica, sencilla y abarcativa. Así es como las grandes empresas de tecnologías de información entre ellas Rational - deciden forman un consorcio para la construcción de un Lenguaje Unificado de Modelado: UML. La primer versión de UML, la 1.0, sale a la luz en el año 1997, y a partir de 1998 un organización llamada OMG (Object Management Group) se encargo de generar nuevas revisiones. En el año 1998 UML se establece como Standard de facto en la industria del Software Donde se utiliza UML se utiliza dentro del marco de IT, aunque puede utilizarse en proyectos que no son de tecnología de la información, como ser el modelado de un motor o de una turbina. En el campo de IT, se utiliza tanto para sistemas monolíticos como para sistemas distribuidos, abarca desde proyectos pequeños hasta grandes proyectos. Permite realizar la integración del software, donde representa el correcto enlace de los roles para lograr el éxito de la constricción del sistema. En proyectos de software, es utilizado desde la gestación hasta la instalación y el testing. Si bien para utilizar UML es posible realizar los distintos diagramas con papel y lápiz, es conveniente contar con alguna herramienta del tipo IDE que facilite su construcción, corrección e integración ente diagramas. Tel. (54) (011) Página 7

8 2. Introducción a los diagramas de UML 2.1. Introducción UML esta organizado en una serie de diagramas que tienen objetivos bien definidos, con una sintaxis y semántica determinada, que intentan representar / modelar distintas vistas de un sistema Los Diagrama de UML Diagrama de Clases El Diagrama de Clases tiene como objetivo describir las clases del dominio y sus relaciones. Permite modelar la estructura del sistema desde un punto de vista estático, modelando las clases desde distintos enfoques de acuerdo a la etapa del proyecto. Esta compuesto por clases, relaciones entre clases y opcionalmente los paquetes que agrupan a las clases Diagrama de Objetos El Diagrama de Objetos tiene como objetivo describir los objetos del dominio y sus relaciones. Permite representar al sistema en un momento determinado del tiempo, es proporcional a obtener una fotografía o snapshot del sistema en un momento determinado. Esta compuesto por objetos y relaciones de enlace. También es posible pensarlo como una instancia de un Diagrama de Clases Diagrama de Casos de Uso El Diagrama de Casos de Uso tiene como objetivo describir las acciones del sistema desde el punto de vista del usuario. Representa las formas que tiene un usuario de utilizar un sistema, y se puede utilizar como un contrato entre cliente y proveedor de software para determinar la funcionalidad del sistema, es decir los requisitos funcionales. Esta compuesto por actores (agentes externos al sistemas, pueden ser usuarios u otros sistemas), casos de uso y distintos tipos de relaciones. Es posible construir diagramas con diferentes niveles de detalle. Tel. (54) (011) Página 8

9 Diagrama de Estados El Diagrama de Estados tiene como objetivo describir los estados por los cuales puede pasar un objeto durante su ciclo de vida. Permite modelar tanto estas simples como compuestos y concurrentes. Esta compuesto por estados, pseudo-estados y transiciones entre estados Diagrama de Actividades El Diagrama de Actividades tiene como objetivo describir las acciones que ocurren dentro de un proceso. Se utiliza principalmente para modelar flujo de trabajo o workflow, con lo cual visualiza las acciones de manera ordenada. Esta compuesto por acciones simples y concurrentes, y transiciones entre las acciones Diagrama de Comunicación El Diagrama de Comunicación tiene como objetivo describir como colaboran o se comunican los distintos objetos entre sí para conseguir un objetivo. Se lo suele llamar también Diagrama de Colaboración. Es posible verlo como una extensión del Diagrama de Objetos, ya que es muy parecido pero tiene como valor agregado los mensajes que se envían entre los objetos. Esta compuesto por objetos, relaciones de enlace y relaciones del tipo llamadas, representando que objeto se comunica con que otro. Es semánticamente equivalente al Diagrama de Secuencia Diagrama de Secuencia El Diagrama de Secuencia tiene como objetivo describir como colaboran los distintos objetos entre sí para conseguir un objetivo a lo largo del tiempo. Esta directamente relacionado con el Diagrama de Comunicación ya que el objetivo es el mismo, pero tiene la particularidad de estar obligatoriamente ordenado en el tiempo. Esta compuesto por objetos y relaciones del tipo llamadas, representando que objeto se comunica con que otro. Es semánticamente equivalente al Diagrama de Comunicación. Tel. (54) (011) Página 9

10 Diagrama de Componentes El Diagrama de Componentes tiene como objetivo describir la relación que existe entre los distintos componentes del sistema. Esta directamente vinculado con el diseño del sistema, permitiendo modelar las relaciones e interfaces que existen entre los componentes. Está orientado a la implementación del sistema. Esta compuesto por componentes, interfaces y sus relaciones Diagrama de Despliegue El Diagrama de Despliegue tiene como objetivo describir la arquitectura de un sistema. Es posible representar la arquitectura desde el punto de vista lógico, basándose en la organización del software, o desde una punto de vista físico, representando directamente cada unidad de hardware. Esta compuesto por nodos, componentes y sus relaciones. Tel. (54) (011) Página 10

11 2.3. Clasificación Es posible clasificar a los diagramas según si tienen alguna relación con el tiempo o no. Existen dos posibles categorías, los diagramas estáticos y los diagramas dinámicos Diagramas Estáticos Los Diagramas Estáticos son aquellos que no tienen ninguna relación con el tiempo. Generalmente representan a estructuras o a posibles acciones pero sin una relación directa con el tiempo. Estos diagramas son: Diagrama de Clases Diagrama de Objetos Diagrama de Casos de Uso Diagrama de Componentes Diagrama de Despliegue Diagramas Dinámicos Los Diagramas Dinámicos son aquellos que tienen relación con el tiempo. Están directamente vinculados con acciones que ocurren bajo cierta secuencia, es decir primero una acción, luego otra, y así sucesivamente. Estos diagramas son: Diagrama de Actividades Diagramas de Interacción (es una subcategoría, que incluye a los Diagramas de Secuencia y Comunicación) Diagrama de Estado Tel. (54) (011) Página 11

12 Diagramas Estructurales Los Diagramas Estructurales son aquellos que reflejan relaciones estáticas de una estructura. Estos diagramas son: Diagrama de Clases Diagrama de Objetos Diagrama de Componentes Diagrama de Despliegue Diagramas de Comportamiento Los Diagramas de Comportamiento son aquellos que reflejan características de comportamiento del sistema o modelan procesos de negocios. Estos diagramas son: Diagrama de Casos de Uso Diagrama de Comunicación Diagrama de Secuencia Diagrama de Actividades Diagrama de Estados Tel. (54) (011) Página 12

13 3. El Diagrama de Clases (Class Diagram) 3.1. Definición 3.2. Objetivo El diagrama de clases es un diagrama que permite modelar la estructura del sistema desde un punto de vista estático, modelando las clases desde distintos enfoques de acuerdo a la etapa del proyecto. Describe tipos de jerarquías, relaciones y abstracciones...describir las clases del dominio y sus relaciones Elementos Clase Una clase representa a una agrupación de cosas, es una plantilla para armar un objeto. Las clases son detectadas en la mayoría de los casos - como sustantivos en singular. Ejemplos de una clase puede ser la clase Auto, que es una clase representante de todos los autos posibles (autos de carrera, autos urbanos, cualquier marca, patente, color, etc.) Otro ejemplo puede ser la clase Animal, representando a todos los animales posibles (mamíferos, herbívoros u otros, cualquier cantidad de patas, color, etc.) Las clases están formadas por atributos y métodos, y por convención, la primera letra debe estar en mayúscula. Que son los atributos Los atributos son características que posee una clase, y determinan el estado que posteriormente tendrá un objeto En el caso de la clase Auto, atributos pueden ser color, marca, modelo, cantidad de puertas y velocidad. Por convención, la primera letra debe estar en minúscula. Que son los métodos Los métodos son las responsabilidades (o comportamiento) que realiza una clase. Generalmente los métodos son verbos. Por convención, la primera letra debe estar en minúscula. Representación grafica de una clase Tel. (54) (011) Página 13

14 Las clases abstractas Las clases abstractas son clases que representan un concepto abstracto, de carácter muy general. Por ejemplo una institución, que tiene los atributos dirección y superficie, pero no es posible determinar que tipo de institución es. Es una clase que no se puede instanciar, es decir que no se puede crear un objeto a partir de ésta clase. Se utiliza como base para otras clases en la relación de generalización, pero no tiene sentido por sí sola. Las clases que no son abstractas se denominan concretas. Por convención, la primera letra debe estar en mayúscula, y la palabra en negrita e itálica. Representación grafica de una clase abstracta Interfaz A diferencia de la clase, la interfaz define únicamente un comportamiento, es decir un conjunto de métodos que no poseen implementación. Estos métodos deberán ser implementados por las clases que decidan implementar la interfaz. Representa un contrato que una clase debe respetar en caso de implementar la interfaz. Por ejemplo, se puede crear un interfaz denominada Volador, que tiene los métodos despegar, aterrizar y volar. Tel. (54) (011) Página 14

15 3.4. Relaciones Generalización Por convención, para definir el nombre de una interfaz se aplican las mismas reglas que para una clase. La relación de generalización se produce entre dos clases. La clase superior es una generalización de la clase inferior, como así también la clase inferior es una particularización de la clase superior. A la clase superior se la denomina superclase, y a la clase inferior se la denomina subclase. La subclase deberá respetar la relación es un o is a, que representa a la relación de generalización. Al construir varios relaciones de este tipo entre clases, se genera la jerarquía de clases (o árbol de clases). En términos de un lenguaje de programación, es posible entenderla como herencia. Por ejemplo, la clase MedioDeTransporte puede ser una superclase, y algunas de sus subclases pueden ser Auto, Avión y Tren. Tel. (54) (011) Página 15

16 Asociación La relación de asociación representa una asociación entre dos clases, donde una clase es socia de otra o tienen algún tipo de relación. Es común describir con un nombre definido por el usuario la relación entre ambas. Por ejemplo, la clase Cuidador tiene una relación con la clase Perro, donde Cuidador cuida al Perro. Es posible determinar la multiplicidad de los extremos de la relación, en el caso anterior un cuidador cuida de uno a muchos perros. Existen dos relaciones denominadas Composición y Agregación que son casos particulares de la relación de Asociación Composición La relación de composición se puede describir como está compuesta por, ya que una clase determina la existencia de la otra. Si Clase1 está compuesta por Clase2 entonces Clase1 determina la existencia de Clase2. Clase2 no podrá existir por si sola si no existe Clase1, es decir que Clase1 controla el tiempo de vida de Clase2. Si la Clase1 es eliminada, también será eliminada Clase2, es decir que si se elimina el todo (Clase1), también serán eliminadas sus partes (Clase2). UML denomina a la relación como strong has-a relationship, representando un fuerte sentido de pertenencia del todo hacia la parte. Por ejemplo, un Auto está compuesta por un Carburador, con lo cual el Carburador no tiene sentido por si solo si no existe el Auto. Dicho Carburador puede utilizarse únicamente para ese Auto, y no para otros, es decir que el mismo Carburador no puede utilizarse al mismo tiempo en más de un Auto. Tel. (54) (011) Página 16

17 Otro ejemplo muy ilustrativo puede ser la relación entre una Tabla y una Columna, donde la Columna es construida si la Tabla es construida, y la Columna es eliminada si la Tabla es eliminada Agregación La relación de agregación se puede describir como tiene como partes a. A diferencia de la composición, si Clase1 tiene como partes a Clase2, Clase1 no determina la existencia de Clase2. Clase2 puede existir aún cuando Clase1 no exista, es decir tiene sentido por si sola. Clase1 no controla el tiempo de vida de Clase2. Si la Clase1 es eliminada, puede no ser eliminada Clase2, es decir que si se elimina el todo (Clase1), no necesariamente serán eliminadas sus partes (Clase2). UML denomina a la relación como weak has-a relationship, representando un débil sentido de pertenencia del todo hacia la parte. Por ejemplo, una OrdenDeCompra tiene como partes a uno o muchos Producto(s), pero si el Producto no forma parte de ninguna OrdenDeCompra, sigue teniendo sentido por si mismo. Si la OrdenDeCompra es eliminada, el Producto no será eliminado Implementación o Realización La relación de implementación se produce entre una clase y una interfaz. La clase que implementa la interfaz tiene la obligación de implementar todos los métodos que forman parte de esa interfaz. Por ejemplo, un Avión para saber volar deberá implementar un interfaz denominada Volador, que incluye los métodos despegar, aterrizar y volar. Tel. (54) (011) Página 17

18 Esta relación también se denomina realización Clases Estereotipadas Que es un estereotipo de clase El estereotipo representa la construcción de un nuevo elemento de UML que extiende a partir de uno ya existente, en el caso de las clases representa a una categoría o un tipo nuevo de clases. Representa una funcionalidad determinada, identificada por su nombre. El Proceso Unificado de Desarrollo (presentado mas adelante) utiliza tres estereotipos de clases que se han estandarizado en el mercado, estos son Boundary, Control y Entity El estereotipo Boundary El estereotipo Boundary se utiliza para representar clases que se encuentran en el limite (bound) del sistema. Estas clases representan a la interfaz de usuario dentro de un sistema, generalmente implementadas como ventanas. Se utilizan para capturar la interacción entre el usuario y el sistema a nivel de pantalla. Estas clases dentro de una arquitectura multicapa generalmente pertenecen a la Capa de Presentación (PL o Presentation Layer). En el patrón de diseño M-V-C representa a la vista El estereotipo Control El estereotipo Control se utiliza para representar clases que se encargan de controlar los procesos de negocios, son clases que llevan a cabo las reglas de negocios, realizando la coordinación entre las clases del tipo Boundary y las clases del tipo Entity. Se encargan de la organización y planificación de actividades. Tel. (54) (011) Página 18

19 Estas clases dentro de una arquitectura multicapa generalmente pertenecen a la Capa de Negocios (BL o Business Layer). En el patrón de diseño M-V-C representa al controlador El estereotipo Entity El estereotipo Entity se utiliza para almacenar o persistir información propia del sistema. Estas clases dentro de una arquitectura multicapa generalmente pertenecen a la Capa de Acceso a Datos (DAL o Data Access Layer). En el patrón de diseño M-V-C representa al modelo Representación grafica Tel. (54) (011) Página 19

20 3.6. Aplicación Modelo de Análisis o Modelo Conceptual Uno de los posibles usos del diagrama de clases es la construcción del denominado Modelo Conceptual. El modelo conceptual es uno o varios diagramas de clase construidos por un Analista Funcional que esta basado en la detección de clases (junto con sus atributos y posibles métodos) y sus relaciones pero desde un punto de vista funcional, es decir dentro de la de la etapa de Análisis. No se definen características propias de un lenguaje de programación, sino que se intenta reflejar la realidad. En algunos casos se categorizar las clases como entity / controller / boundary, que son estereotipos de RUP (Racional Unified Process) presentados mas adelante. Adicionalmente, es posible utilizar una CRC Card (Class Responsability and Collaboration) para detallar el nombre de la clase, descripción, atributos y responsabilidades Modelo de Diseño El modelo de diseño es el conjunto de diagramas de clases (puede ser uno solo) que se utiliza como base para realizar la codificación de la aplicación. El encargado de construirlo es el Diseñador, y debe definir todo lo que sea necesario para que el desarrollador pueda codificar sin problemas. Toma como uno de los documentos de entrada el correspondiente al Modelo de Análisis, y se definen nuevas clases (en general las detectadas en Análisis se mantienen) que tiene un perfil netamente de diseño y resuelven cuestiones técnicas y ya no de negocios. A partir del Modelo de Diseño se genera el código fuente de manera automática que será tomado como base por los desarrolladores. De esta manera el programador no toma decisiones ni de Análisis ni de Diseño, lo cual queda restringido a programar en el código recibido. El modelo tiende a evolucionar en la fase de construcción a través de feed-backs que realizan los desarrolladores. Tel. (54) (011) Página 20

21 Diseño de Base de Datos El modelo de datos o diseño de una base de datos también es posible realizarlo a través de un diagrama de clases. En este caso las clases representan las tablas y los atributos representan los campos Ejemplo Para esto es necesario utilizar estereotipos (ver Sección Conceptos Generales), determinando el estereotipo <<table>> para las tablas, el estereotipo <<column>> para los campos, y otros estereotipos posibles como <<PK>> para las claves primarias y <<FK>> para las claves foráneas, entre otros. Tel. (54) (011) Página 21

22 4. Diagrama de Objetos (Object Diagram) 4.1. Definición El Diagrama de Objetos permite representar el sistema en un momento determinado del tiempo, es similar a obtener una fotografía o snapshot del sistema en un momento determinado, y visualizar los objetos junto con sus relaciones Objetivo Se suele utilizar como punto de partida para la construcción del Diagrama de Comunicación o Colaboración...describir los objetos del dominio y sus relaciones Elementos Objeto El objeto representa una cosa en particular, es una instancia de una clase. Nace de utilizar una clase como plantilla y llenar sus atributos con valores. Los objetos dentro del diagrama dependen de algún tipo de clase, y pueden estar estereotipados para una mejor comprensión. Por convención, la primera letra debe estar en minúscula y la palabra subrayada. Es común agregar luego del nombre del objeto el nombre de la clase a la cual pertenece el objeto Relaciones Vínculo Se utiliza para establecer algún tipo de relación entre los objetos, no denota un tipo de relación en particular sino simplemente un vinculo que no tiene dirección. Tel. (54) (011) Página 22

23 Vínculo Direccional Se utiliza de la misma forma que el vínculo, pero tiene como valor agregado que permite entender mejor la relación, determinar la navegabilidad de la misma Aplicación Fotografía del sistema Este diagrama es el menos utilizado de todos los diagramas ya que no representa relevancia sobre ninguna vista posible del sistema. Su uso mas frecuente es la posibilidad de visualizar el sistema en un determinado momento, estudiando que objetos están instanciados y la relación entre los mismos. Tel. (54) (011) Página 23

24 4.6. Ejemplo Tel. (54) (011) Página 24

25 5. Diagrama de Casos de Uso 5.1. Definición El Diagrama de Casos de Uso representa las formas que tiene un usuario de utilizar un sistema, y esta directamente asociado con el que debe hacer un sistema, y no como debe hacerlo. Visualiza de forma directa los requisitos funcionales de un sistema, es decir como el sistema debería funcionar, es por esta razón que se utiliza para guiar el diseño y el desarrollo. Todo el proceso de desarrollo de software (análisis, diseño, testing, etc) son dirigidos por los casos de uso, donde un cambio en un caso de uso impacta en gran parte del proceso de desarrollo. Es importante aclarar que no permite modelar workflow ni visualizar como se desarrollan las acciones detrás de los casos de uso. Adicionalmente, es posible construir diagramas con diferentes niveles de detalle. Requisito Funcional Los requisitos funcionales determinan el funcionamiento del sistema, son aquellos que especifican el que debe hacer el sistema, representa a las reglas de negocio. Por ejemplo, el sistema debe administrar clientes, realizar cobros, emitir facturas, etc. Requisito No Funcional Los requisitos no funcionales son aquellos que no determinan la funcionalidad del sistema, aunque pueden influir sobre la misma. Son requisitos no funcionales la velocidad de respuesta, el rendimiento, exactitud, el hardware a utilizar, etc Objetivo Por ejemplo, en el caso de estar operando con un cajero automático, el caso de uso sacar dinero puede tener asociado un requisito no funcional velocidad de repuesta, donde especifique que el cliente no debe esperar mas de 1 segundo para realizar la transacción...describir las acciones del sistema desde el punto de vista del usuario.. Tel. (54) (011) Página 25

26 5.3. Elementos Actor El actor representa una entidad externa al sistema que utiliza el sistema. Generalmente son usuarios, aunque también podría ser otro sistema. Participa en un caso de uso (o más) con el propósito de cumplir su objetivo, definiendo el rol que un usuario del sistema va a asumir cuando esté en funcionamiento. El conjunto de todos los actores representará todas las formas de comunicación de una entidad externa con el sistema Caso de Uso (Use Case) El caso de uso es la interacción que existe entre un actor y el sistema, representa un forma de utilizar el sistema. Es posible entenderla como una unidad de funcionalidad expresada como una transacción entre un actor y el sistema. Un caso de uso puede ser descrito en términos de casos de uso más simples, pudiendo un caso de uso detallarse desde el punto de vista del usuario como un Diagrama de Casos de Uso Relaciones Asociación Tel. (54) (011) Página 26

27 La relación de Asociación es una línea de comunicación entre un actor y el caso de uso de uso en el que participa Generalización La relación de Generalización representa a un elemento que es general, y a otro elemento que tiene la base del elemento general, pero como valor agregado tiene algunas particularidades. Por ejemplo, el elemento2 toma como base al elemento1, con lo cual el elemento2 tiene como mínimo lo que tiene el elemento 1, y aparte agrega otras cosas. Se dice que el elemento1 es una generalización del elemento2, y el elemento2 es una especialización del elemento1. Esta relación puede darse tanto entre actores como entre casos de uso. Aplicación entre Actores Aplicación entre Casos de Uso Especialización Tel. (54) (011) Página 27

28 La relación de Especialización es la relación inversa a la relación de Generalización. Según el ejemplo anterior, abrir cuenta es una generalización de abrir cuenta corriente, pero también abrir cuenta corriente es una especialización de abrir cuenta. Se maneja bajo el mismo criterio que la generalización, con lo cual también es aplicable a actores Inclusión La relación de Inclusión representa que un caso de uso esta incluido en otro caso de uso base, donde el caso de uso incluido es parte del caso de uso base. Por ejemplo, el caso de uso abrir cuenta incluye a los casos de uso registrar datos y depositar fondos, ya que al abrir un cuenta en un banco es necesario registrarse y depositar fondos en la cuenta Extensión La relación de Extensión se utiliza entre dos casos de uso, cuando un caso de uso incluye al otro pero opcionalmente. Por ejemplo, el caso de uso entregar pasaporte es una extensión del caso de uso abrir cuenta, ya que solo será solicitado entregar el pasaporte a aquellas personas que sean extranjeros y quieran abrir una cuenta. Tel. (54) (011) Página 28

29 5.5. Aplicación Captura de Requisitos Funcionales La forma estándar de captura de requisitos funciones son los Diagrama de Casos de Uso. Esto se debe a que es una forma sencilla, sistemático e intuitiva, fácil de leer por cualquier persona que forma parte de un proyecto, incluyendo al cliente mismo Modelo de Casos de Uso El modelo de casos de uso es el conjunto de todos los diagramas de casos de uso que forman parte del sistema. En este artefacto quedan documentados todos los requisitos funcionales que deberá satisfacer el sistema, y se utiliza como la documentación que detalle la funcionalidad del sistema. El sistema no podrá tener más ni menos funcionalidad que la especificada en este documento Establecimiento de contratos Dependiendo de la envergadura del sistema, los casos de uso sirven como una forma de ponerse de acuerdo entre el cliente (es el que quiere/necesita un sistema) y el proveedor (es el que construye el sistema). Se suelen establecer contratos en base a los casos de uso, donde cliente y proveedor se comprometen a que el sistema debe tener la funcionalidad especificada en los casos de uso que forman parte del contrato. De esta manera se evitan malentendidos acerca de las funcionalidades que están incluidas de las que no están incluidas Construcción de Casos de Prueba (Test Cases) Los casos de prueba son necesarios en todo sistema para poder realizar el testing de la aplicación, y así asegurar la calidad del producto desde el punto de vista funcional, es decir asegurar que lo que tiene que hacer el sistema, lo esta haciendo correctamente. Los casos de uso se utilizan como punto de partida para los casos de prueba, ya que los casos de prueba son los casos de uso con algunos agregados adicionales como casos especiales a testear. Tel. (54) (011) Página 29

30 5.6. Ejemplo Tel. (54) (011) Página 30

31 6. Diagrama de Estados 6.1. Definición El Diagrama de Estados permite visualizar los cambios de comportamiento de un objeto a partir de sus transiciones Objetivo Se lo conoce también como Maquina de Estados....describir los estados por los cuales puede pasar un objeto durante su ciclo de vida Elementos Estado (State) El estado corresponde generalmente a un objeto, y representa el conjunto de valores que tiene ese objeto en un determinado momento. Describe un periodo de tiempo durante el ciclo de vida del objeto. El comportamiento interior de un estado es posible modelarlo con un Diagrama de Actividad, que visualiza las acciones que ocurren cuando un objeto entra en ese estado Estado compuesto (Sub-machine State) El estado compuesto es un estado que contiene sub-estados. Es posible modelar los sub-estados dentro del estado compuesto, o en un diagrama de estados aparte. Si se modela el estado compuesto como una caja negra que esta desarrollada en un diagrama aparte, su representación grafica es la siguiente: Tel. (54) (011) Página 31

32 Si se modela el estado compuesto como un conjunto de sub-estados visibles, su representación grafica es la siguiente: Pseudo-Estado Inicial (Initial State) El pseudo estado inicial representa el comienzo de las transiciones de los posibles estados Pseudo-Estado Final (Final State) Tel. (54) (011) Página 32

33 El pseudo estado final representa el final esperado de las transiciones de los posibles estados Punto de Entrada (Entry Point) El punto de entrada es utilizado en estados compuestos, y representa el punto de entrada al estado compuesto desde el exterior Punto de Salida (Exit Point) El punto de salida es utilizado en sub estados o estados compuestos, y representa el punto de salida del sub estado o estado compuesto desde el interior. Tel. (54) (011) Página 33

34 Estado de Sincronización (Sync State) El estado de sincronización indica que los caminos concurrentes que pasen por este estado serán sincronizados Estado Histórico (Shallow History State) El estado histórico se utiliza para representar el estado activo (o sub-estado) mas reciente de un estado compuesto, aunque no tiene la capacidad para representar el estado activo de un posible sub-estado (si existiera) del sub-estado del estado compuesto Estado Histórico Profundo (Deep History State) Tel. (54) (011) Página 34

35 El estado histórico profundo se utiliza para representar el estado activo (o subestado) mas reciente de un estado compuesto, y además tiene la capacidad para representar el estado activo de un posible sub-estado (si existiera) del subestado del estado compuesto, es decir que almacena el histórico de todos los estados activos en forma recursiva Fork El fork es un pseudo estado que se utiliza para separar una transición de entrada en dos transiciones concurrentes que tienen como destino diferentes estados Join El join es el proceso inverso al fork, es un pseudo estado que se utiliza para unir dos transiciones de entrada concurrentes en una única transición de salida. Tel. (54) (011) Página 35

36 Unión (Junction) La unión es un pseudo estado que se utiliza para unir múltiples caminos en otros caminos que pueden ser compartidos, o también para separar un camino en varios caminos alternativos. Se suelen agregar guardas a las transiciones para especificar una condición para la transición, si el resultado de la condición es negativo entonces no se produce esa transición Decisión (Choice) La decisión indica un condicional en el progreso: si la condición es verdadera toma un camino, y si es falsa toma el camino alternativo. Tel. (54) (011) Página 36

37 6.4. Relaciones Transición La transición es una ocurrencia en el tiempo, sin una determinada duración. Representa la forma de vincular estado, y es el medio en que un estado pasa a otro estado. En forma opcional, es posible especificar un evento disparador (trigger) que inicia la transición de un estado a otro Aplicación Seguimiento de un objeto El Diagrama de Estados se utiliza generalmente para hacer un seguimiento fino de un objeto en particular, cuando el foco del negocio requiere hacer énfasis en las transiciones de ese objeto. Adicionalmente, se utilizan para ayudar al desarrollador a entender funcionalidades complejas o algún proceso de negocio especializado en una área determinada. Es importante destacar que un Diagrama de Estados no es un diagrama mayormente utilizado, se utiliza únicamente para casos puntuales. Tel. (54) (011) Página 37

38 6.6. Ejemplo Se modelo a continuación los estados posibles de un alumno de una universidad. El estado compuesto inscripto desarrollado en otro diagrama queda de la siguiente manera: Tel. (54) (011) Página 38

39 7. Diagrama de Actividades 7.1. Definición 7.2. Objetivo El Diagrama de Actividad se utiliza principalmente para modelar flujo de trabajo o workflow, visualizando las acciones de manera ordenada. Permite modelar procesos y comprender la ejecución general de un sistema, localizándose en la secuencia de acciones y condiciones necesarias para su ejecución....describir la acciones que ocurren dentro de un proceso Elementos Actividad (Activity) Una actividad refleja el control de flujo y de datos de un proceso, y puede incluir la participación de sub-actividades y/o acciones. Generalmente representa a una unidad funcional dentro de una actividad mayor o de un proceso Actividad Estructurada (Structured Activity) La actividad estructurada es una actividad que visualiza de manera explícita que esta compuesto por un conjunto de actividades u acciones Acción (Action) La acción es la unidad funcional básica dentro de un diagrama de actividades, y representa la transformación que ocurre dentro del sistema. La diferencia principal con las actividades radica en que la acción no puede descomponerse, Tel. (54) (011) Página 39

40 mientras que una actividad puede descomponerse en sub-actividades y/o acciones Objeto (Object) El objeto tiene el mismo significado que el presentado para los diagramas anteriores, en este caso adicionalmente representa que un objeto es construido, modificado o consultado luego de una actividad Datastore Object El datastore es un objeto que se utilice para modelar la persistencia de información permanente. Se puede utilizar tanto para almacenar información como para consultar información CentralBuffer Node El buffer tiene el mismo significado que el datastore, pero se utiliza para almacenar información temporalmente (información no persistente o transitoria). Tel. (54) (011) Página 40

41 Pseudo-Estado Inicial (Initial State) El pseudo estado inicial representa el comienzo de los flujos entre las acciones Pseudo-Estado Final (Final State) El pseudo estado inicial representa el final de los flujos entre las acciones Señal de Envío (Send Signal) La señal de envío se utiliza para representar que se esta enviando un objeto en forma de señal hacia algún destino no necesariamente representado en el diagrama. En el siguiente ejemplo, la señal de envío se utiliza para notificar al proveedor acerca de la creación de un pedido, donde es enviado el objeto pedido al proveedor Señal de Recepción (Receive Signal) La señal de recepción se utiliza para representar la recepción y/o aceptación de un pedido. Existen dos tipos de señales de recepción. Tel. (54) (011) Página 41

42 Accept Event Action Esta señal se utiliza para determinar la recepción de un evento por parte de terceros. Si se utiliza en conjunto con la señal de envío, establece que el flujo continuara normalmente una vez que se produzca la señal de respuesta. Accept Time Event Action Esta señal se utiliza para representar el pasaje del tiempo, es una acción que espera la ocurrencia de un evento del tipo tiempo, por ejemplo comienzo de un mes, finalización del mes, comienzo del día, etc Manejador de Excepciones (Exception Handler) El manejador de excepciones esta compuesto por una o mas acciones y se encarga de tomar medias correctivas en caso de que se haya lanzado alguna excepción (o se haya producido algún error) Fork Tel. (54) (011) Página 42

43 El fork es un pseudo estado que se utiliza para separar un flujo de entrada en dos flujos concurrentes que tienen como destino diferentes actividades y/o acciones Join El join es el proceso inverso al fork, es un pseudo estado que se utiliza para unir dos flujos de entrada concurrentes en un único flujo de salida Decisión (Choice) La decisión indica un condicional en el progreso: si la condición es verdadera toma un camino, y si es falsa toma el camino alternativo. Tel. (54) (011) Página 43

44 Partición (Partition) La partición se utiliza para establecer responsabilidades en las acciones o actividades. Determina que o quien realiza cada actividad. Son de uso opcional, y permiten estructurar la vista o las partes de la actividad, realizando una separación lógica. También son denominadas swimlanes Relaciones Flujo de control (Control Flow) El flujo de control es un conector que une dos actividades o acciones, una inicial y una final, determinado por una dirección. Una vez que la acción inicial es completada, el control pasa a la acción siguiente. Tel. (54) (011) Página 44

45 Es posible definir una guarda que representa una condición que debe cumplir la acción inicial para pasar a la próxima acción Flujo de objeto (Object Flow) El flujo de objeto conecta una actividad con un objeto, representando un flujo de información de la actividad al objeto Flujo de objeto con Pines (Pinned Object Flow) El flujo de objeto con distinción es semánticamente igual al flujo de objeto tradicional, la diferencia radica en la forma de graficarlo, ya que de esta manera resulta mas compacto Flujo de Interrupción (Interrupt Flow) El flujo de interrupción representa una interrupción debido a una ocurrencia inesperada en alguna acción o actividad Aplicación Desarrollo de aplicaciones procedurales Uno de los posibles usos que tiene el Diagrama de Actividades es la posibilidad de realizar el flujo de aplicaciones de tipo procedural, al estilo diagramas de jackson, donde se pueden representar las sentencias (acciones) junto con las estructuras Tel. (54) (011) Página 45

46 de control de flujo utilizando las decisiones, forks, joins y actividades estructuradas para representar llamadas a cajas negras o procedimientos Modelado de procesos de negocio - Workflow El uso mas común del Diagrama de Actividades es la representación de flujos de trabajo o procesos de negocio. Es posible modelar como arranca un proceso, a partir de quien o en que área se produce, y visualizar la transformación de información que va ocurriendo durante todo el proceso. En este contexto los eventos generalmente se originan dentro del sistema al finalizar las diferentes acciones, o también fuera del sistema a través de señales de recepción (por ejemplo, el proveedor entrego la mercadería) y a través de eventos correspondientes al tiempo (por ejemplo, paso un mes). Tel. (54) (011) Página 46

47 7.6. Ejemplo Tel. (54) (011) Página 47

48 8. Diagrama de Comunicación (Communication Diagram) 8.1. Definición El Diagrama de Colaboración modela los objetos junto con sus interacciones para visualizar como se lleva a cabo una tarea, modelando únicamente la interacción entre los objetos que realizan esa tarea en particular. Se lo suele llamar también Diagrama de Comunicación. Es posible verlo como una extensión del Diagrama de Objetos, ya que es muy parecido pero tiene como valor agregado los mensajes que se envían entre los objetos Objetivo Es uno del Diagrama de Interacción, y semánticamente es equivalente al Diagrama de Secuencia..Describir como colaboran o se comunican los distintos objetos entre sí para conseguir un objetivo Elementos Actor El actor es una entidad externa al sistema que dispara el comienzo de la interacción entre los objetos. La aparición de un actor dentro del diagrama es opcional Objeto Es el mismo elemento que se utiliza en el Diagrama de Objetos Boundary Tel. (54) (011) Página 48

49 Es el mismo elemento que se utiliza en el Diagrama de Clases, pero en este caso representa a un objeto, instancia de una clase que esta estereotipada como Boundary Control Entity Es el mismo elemento que se utiliza en el Diagrama de Clases, pero en este caso representa a un objeto, instancia de una clase que esta estereotipada como Control. Es el mismo elemento que se utiliza en el Diagrama de Clases, pero en este caso representa a un objeto, instancia de una clase que esta estereotipada como Entity Relaciones Vinculo Es la misma relación que se utiliza en el Diagrama de Objetos Vinculo Direccional Mensaje Es la misma relación que se utiliza en el Diagrama de Objetos. El mensaje es una llamada que se realiza de un objeto origen a un objeto destino, para entablar una conversación. Existen dos tipo de mensajes a enviar: los mensajes sincrónicos y los mensajes asincrónicos. Mensaje Sincrónico El objeto origen envía un mensaje al objeto destino y espera a recibir una respuesta. Una vez recibida la respuesta, sigue con su tarea. El mensaje sincrónico se modela con una fecha de punta rellena. Tel. (54) (011) Página 49