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