Programación Orientada a Objetos y Lenguaje de Modelado Unificado

Objetivos Adquirir la terminología necesaria para realizar el análisis y diseño bajo UML Conocer las herramientas de análisis y aprender como utilizarlas y en qué momento. Asimilar los conceptos teóricos aprendidos mediante la exposición de ejemplos prácticos.

Agenda Programación Orientada a Objetos Que es UML? Modelos del Proceso Unificado Tipos de Diagramas – Aplicación Diagramas Estáticos vs. Diagramas Dinámicos ¿Qué es un Caso de Uso? Diagrama y Especificación Ejemplos

Programación Orientada a Objetos ¿Qué es un Objeto? Un Objeto es la representación de un conocimiento abstracto de un problema del mundo real Una cosa tangible y/o visible. Algo que puede comprenderse intelectualmente. Algo a lo que se dirige un pensamiento o acción.

Un Objeto tiene: Estado, Comportamiento e Identidad Estado Mediante todas las propiedades del mismo (normalmente estáticas), más los valores actuales ( normalmente dinámicas), de cada una de esas propiedades. Comportamiento A través de la forma en que responde a los estímulos a los que es sometido Identidad Mediante la propiedad que distingue al objeto de otro objeto

¿Cómo identificamos a los objetos? Usando herramientas gramaticales tales como sustantivos y verbos Objetos --> nombres; servicios --> verbos Usando entidades tangibles, (cosas), en la aplicación de dominios Productos, Clientes, Gerencia, Reuniones, etc... Determinando participantes y comportamientos, tanto a nivel general como particular Participantes son objetos y los comportamientos son servicios.

Tipos de Relaciones entre Objetos Las relaciones entre Objetos son: Asociación (conocimiento) Agregación Generalización

Tipos de Relaciones entre Objetos Asociación (mensajes): Conexión semántica entre instancias de clases Proporciona una “conexión” entre los objetos para el envío de mensajes. Enlace: Instancia de una asociación Lista ordenada de referencias a objetos

Tipos de Relaciones entre Objetos Agregación: Mientras que los enlaces denotan relaciones igual-a-igual la agregación denota una jerarquía todo/parte. Con la capacidad de ir desde el todo, (el agregado), hasta sus partes, (conocidos también como atributos). Cliente “tiene un” Orden Item “tiene un” Precio “tiene un”

Tipos de Relaciones entre Objetos Generalización: Relación taxonómica entre una descripción general y otra más específica que la extiende. Relación “es un tipo de”.

¿Qué es UML? UML es un conjunto de herramientas que permite modelar sistemas orientados a objetos No es un método de desarrollo, por lo tanto, no va a decir cómo pasar del análisis al diseño y de éste al código Y al no ser un método de desarrollo, es independiente del ciclo de desarrollo que se utilice

¿Qué es UML? UML es un lenguaje “unificado” de modelado para: Visualizar Especificar Construir Documentar Los artefactos de un sistema de software. Representar y Comunicar Ideas Modelos precisos, no ambiguos, completos Trasladar en forma directa a un leng. prog. Los artefactos construidos durante un proyecto

Modelos de Proceso Unificado Un modelo es una representación en algún medio que captura los aspectos importantes del sistema modelado desde un determinado punto de vista. Propósitos de los modelos Capturar y precisar requerimientos de un dominio de conocimiento, que sea comprensible por los Sponsors del proyecto. Pensar sobre un diseño de un sistema. Capturar decisiones de diseño de un sistema. Explorar posibles soluciones a un problema económicamente. Generar productos de trabajo útiles. Documentar.

Modelos de Proceso Unificado Iterativo Incremental Dirigido por Casos de Uso Centrado en la Arquitectura Enfocado en los Riesgos

Diagramas UML Diagrama de Casos de Uso (Dinámico) UML cuenta con distintos tipos de diagramas los que muestran distintos aspectos de las entidades representadas. Ellos son: Diagrama de Casos de Uso (Dinámico) Diagrama de Clases (Estático) Diagrama de Estados (Dinámico) Diagrama de Secuencia (Dinámico) Diagrama de Colaboración (Dinámico) Diagrama de Actividades (Dinámico) Diagrama de Componentes (Estático) Diagrama de Distribución (Estático)

Diagramas UML

Diagramas Estáticos vs. Dinámicos Podemos ver al modelos desde un punto de vista dinámico y estático. Esto se representa mediante la siguiente distinción: Modelo estático (estructural): Diagrama de despliegue Diagrama de componentes Diagrama de clases Diagrama de objetos Los diagramas estructurales de UML permiten visualizar, especificar, construir y documentar los aspectos estáticos de un sistema

Diagramas Estáticos vs. Dinámicos Modelo dinámico (comportamiento): Diagrama de estados Diagrama de actividades Diagrama de secuencia Diagrama de colaboración Diagrama de casos de uso Mientras que los diagramas de comportamiento de UML se emplean para visualizar, especificar, construir y documentar los aspectos dinámicos de un sistema

Diagrama de Casos de Uso (dinámico) Organizan los comportamientos del sistema. Un diagrama de caso de uso representa un conjunto de casos de uso y actores (un tipo especial de clases) y sus relaciones. Un diagrama de Casos de Uso consta de los siguientes elementos: Actores Casos de Uso Relaciones

Consideraciones claves El nombre de un Caso de Uso se expresa con verbo en infinitivo Los Casos de Uso tienen las siguientes características: Están expresados desde el punto de vista del actor Se documentan con texto informal Describen tanto lo que hace el actor como el sistema, aunque se hace énfasis en la interacción Son iniciados por un único actor Están acotados a una única funcionalidad (claramente diferenciada) del sistema

Consideraciones claves 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) Asociación Este tipo de relación es el más utilizado, cumple una doble función según el estereotipo <<include>> o <<extends>> Generalización

Consideraciones claves La relación <<Extiende >> se utiliza cuando un caso de uso es similar a otro pero con alguna característica nueva. La relación << usa – Include >> se utiliza cuando se tiene una parte del comportamiento común de más de un caso de uso y se desea simplificar el uso de la descripción de este comportamiento.

Descripción de los Casos de Uso Caso de Uso: Breve Descripción: Actores: Precondición: Post-Condición: Referencias: Curso Normal: Curso Alternativo: Supuestos y Dependencias: Problemas y Comentarios:

Caso de Ejemplo Se quiere realizar un Sistema que controla una máquina de reciclamiento de botellas y tarros. Para ello, el sistema debe permitir: Registrar el número de ítems ingresados Imprimir un recibo cuando el usuario finalice el deposito Comenzar el proceso al detectar el deposito de un nuevo ítem Saber cuántos ítems han sido retornados en el día Que el operador obtenga un resumen al final del día de todo lo depositado Cambiar información asociada a cada ítem Emitir una alarma en caso que el ítem se atore

1) Como primera aproximación se identifican los actores que interactúan con el sistema Cliente Operador Sistema Máquina de Reciclaje

2) Luego, tenemos que un cliente puede Depositar Ítems y un operador puede cambiar información de un Ítem, o bien, puede imprimir un informe: Generar Reporte Operador Cliente Depositar Ítem Cambiar Ítem

3) Pero a su vez, podemos notar que un ítem puede ser una botella o un tarro por lo tanto: Depositar Ítem <<extends>> <<extends>> Depositar Tarro Depositar Botella

4) A su vez, existe la impresión de comprobantes, que puede ser realizada después de depositar algún ítem por un cliente o bien, puede ser pedida por el operador: Depositar Ítem Generar Reporte <<include>> <<include>> Imprimir

Ejemplo: Diagrama de Casos de Uso

Ejemplo: UCS_Depositar Item Caso de Uso: Depositar ítem Breve Descripción: El presente caso de uso describe los pasos a seguir por el usuario para depositar un item en la recicladora Actor: Usuario Precondición: La maquina recicladora debe estar en funcionamiento Post condición: El ítem fue depositado y registrado Referencia: * Incluye CU: Depositar Botella. * Incluye CU: Depositar Tarro * Incluye CU: Eliminar Alarma Curso Normal: 1) El usuario deposita un ítem en la maquina recicladora. 2) La recicladora valida el ítem. Valida que: * Sea un ítem valido (Se un tarro o una botella) * Se encuentre en la posición correcta

3) El sistema obtiene información del tipo de ítem. 4) El sistema registra el ítem según su tipo. *Ítem Botella. Caso de uso “Depositar Botella” *Ítem Tarro. Caso de uso “Depositar Tarro” 5) El sistema queda a la espera de un nuevo ítem. Curso Alternativo: 2.1 En caso que el ítem ingresado no sea valido, el sistema informa la situación por medio de un mensaje al usuario. 2.1.1 El usuario retira el ítem. 2.2 En caso que el ítem no se encuentre en la posición correcta, el sistema informa la situación al operador mediante una alarma. Para ello llama al caso de uso “Emitir Alarma” 2.2.1 El operador corrige el ítem atascado Supuestos y Dependencias: N / A Problemas y Comentarios:La maquina recicladora debe contar con un detector de ítems.

Diagrama de Secuencia (dinámico) Los Diagramas de Secuencia y de Colaboración son usados para describir gráficamente un escenario El Diagrama de Secuencia muestra los objetos de un escenario mediante líneas verticales y utiliza flechas de conexión para mostrar los mensajes entre objetos Los mensajes son dibujados cronológicamente desde arriba hacia abajo Los rectángulos en las líneas verticales representan los períodos de actividad de los objetos.

Ejemplo: Diagrama de Secuencia

Diagrama de Colaboración (dinámico) El Diagrama de Colaboración modela la interacción entre los objetos de un Caso de Uso Los objetos están conectados por enlaces (links) que representan los mensajes enviados acompañados de una flecha indicando su dirección Este tipo de diagrama ofrece una mejor visión del escenario cuando el analista está intentando comprender la participación de un objeto en el sistema

Ejemplo: Diagrama de Colaboración

Diferencias El Diagrama de Secuencia destaca la sucesión de las interacciones. El Diagrama de Colaboración destaca el contexto y organización general de los objetos que interactúan. El Diagrama de Secuencia se organiza de acuerdo al tiempo. El Diagrama de Colaboración de acuerdo a la interacción entre los objetos.

Diagrama de Clases (estático) Es el diagrama principal para el análisis y diseño del sistema Un diagrama de clases presenta las clases del sistema con sus relaciones estructurales y de herencia Para cada clase se describen los atributos y operaciones El modelo de casos de uso debería aportar información para establecer las clases, objetos, atributos y operaciones

Ejemplo: Diagrama de Clases

Diagrama de Estados (dinámico) El diagrama de estados presenta los estados en los que pueden encontrarse un objeto junto con las transiciones entre los estados, y muestra los puntos inicial y final de una secuencia de cambios de estado. Los diagramas de clase o casos de uso ya vistos modelan el comportamiento de un sistema o al menos un grupo de clases, mientras que el diagrama de estados muestra las condiciones de un solo objeto. Es necesario contar con diagramas de estados dado que permiten a los analistas, diseñadores y desarrolladores comprender el comportamiento de los objetos de un sistema.

Modelo

Diagrama de Actividades (dinámico) Es una extensión del Diagrama de Estados Fue diseñado para mostrar una visión simplificada de lo que ocurre durante una operación o proceso, mostrando los pasos, puntos de decisión y bifurcaciones. El Diagrama de Actividades puede especificar: El comportamiento de los objetos de una clase La lógica de una operación (método) Parte o toda la descripción de un Caso de uso La descripción de un Flujo de Trabajo

Ejemplo: Diagrama de Actividades

Diagrama de Componentes (estático) Los diagramas de componentes describen los elementos físicos - denominados artefactos del sistema - y sus relaciones Muestran grupos de artefactos de software de acuerdo a una funcionalidad común y pueden incluir código fuente, binario y ejecutable, recursos gráficos o textuales, etc. Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. Pueden ser simples archivos, paquetes, bibliotecas cargadas dinámicamente, etc. Las relaciones de dependencia entre componentes se utilizan para indicar que un componente utiliza los servicios ofrecidos por otro componente

Modelo

Diagrama de Despliegue (estático) El Diagrama de Despliegue mapea la arquitectura de software creada en diseño con una arquitectura física de sistema que lo ejecuta. Se lo conoce también como Diagrama de Distribución o de Dominio Los Diagramas de Despliegue muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos Los estereotipos permiten precisar la naturaleza del equipo: Dispositivos Procesadores Memoria Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse

Modelo <<Cliente>> <<Servidor>> Terminal Punto de Venta <<TCP/IP>> Base de Datos <<RDSI>> <<RDSI>> Control Podemos distinguir tipos de nodos y conexiones por estereotipado

Otra forma de representarlo