programación orientada a objetos y lenguaje de modelado unificado
TRANSCRIPT
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
EstadoMediante todas las propiedades del mismo (normalmente
estáticas), más los valores actuales ( normalmente dinámicas), de cada una de esas propiedades.
ComportamientoA través de la forma en que responde a los estímulos a los
que es sometido
IdentidadMediante 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):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:Enlace:•Instancia de una asociación•Lista ordenada de referencias a objetos
Tipos de Relaciones entre Objetos
Agregación: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
Orden
Item
Precio
“tiene un”
“tiene un”
“tiene un”
Tipos de Relaciones entre Objetos
Generalización: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”.
Cuenta
CajaDeAhorro CuentaCte
¿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 modelosPropósitos de los modelosCapturar 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
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
Asociación
Generalización
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)
Este tipo de relación es el más utilizado, cumple una doble función según el estereotipo <<include>> o <<extends>>
Consideraciones claves
• La relación <<Extiende Extiende >> se utiliza cuando un caso de uso es similar a otro pero con alguna característica nueva.
• La relación << usa – Includeusa – 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.
Consideraciones claves
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:
ClienteOperador
Depositar Ítem
Generar Reporte
Cambiar Ítem
3) Pero a su vez, podemos notar que un ítem puede ser una botella o un tarro por lo tanto:
Depositar Ítem
Depositar Botella Depositar Tarro
<<extends>> <<extends>>
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
Imprimir
<<include>> <<include>>
Ejemplo: Diagrama de Casos de Uso
Ejemplo: UCS_Depositar ItemCaso 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 DominioLos 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 nodosLos estereotipos permiten precisar la naturaleza del equipo:
•Dispositivos•Procesadores•Memoria
Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse
Modelo
Terminal Punto de Venta
<<Cliente>>
Base de Datos
<<Servidor>>
Control
<<TCP/IP>>
<<RDSI>>
Podemos distinguir tipos de nodos y conexiones por estereotipado
<<RDSI>>
Otra forma de representarlo