Luis A. GuerreroUniversidad de ChileDepartamento de Ciencias de la ComputacinCC61J - Taller de UMLAnlisis y Diseo Orientado a Objetos

Proceso de desarrollo de software:Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quin hace qu, cundo y cmo).

Objetivos:Asegurar la produccin de software de calidad dentro de plazos y presupuestos predecibles.Introduccin

IntroduccinEjemplo: Un juego de dados. Se tiene un juego de dados en que un jugador lanza dos dados. Si el total obtenido es siete, el jugador gana, en caso contrario pierde.

Introduccin1. Definicin de casos de uso Los casos de uso son descripciones narrativas en lenguaje natural de los procesos del dominio en un formato estructurado de prosa. Describen una secuencia de acciones. Caso de uso: Jugar un juego. Participantes: Jugador. Descripcin: Este caso de uso comienzacuando el jugador recoge y lanza los dados.Si los puntos suman siete, gana y pierde sisuman cualquier otro nmero.

Introduccin2. Definicin de un modelo conceptual Un modelo conceptual muestra grficamente los conceptos (clases de objetos), los atributos y las asociaciones ms importantes del dominio del problema. Supongamos que queremos hacer una simulacin del juego de dados:

Introduccin3. Definicin de los diagramas de colaboracin Los diagramas de colaboracin representan el flujo de mensajes entre las instancias y la invocacin de mtodos.

Introduccin4. Definicin del diagrama de diseo de clases Cmo se relacionan unos objetos con otros?, cules son las caractersticas (mtodos y atributos) de cada clase?

Introduccin5. Codificacin

Escritura del cdigo en un lenguaje orientado a objetos.class JuegodeDados { String Nombre;class Jugador { String nombre; public Jugador(String nombre) { this.nombre = nombre; } public jugar(Dado d1,d2); int dado1 = d1.lanzar(); int dado2 = d2.lanzar(); }}public void Dado(){ int ValorMostrado; public Dado { this.ValorMostrado = 0; } public lanzar(); this.ValorMostrado = Math.random(1,6); }} ...

IntroduccinProceso de desarrollo de software

IntroduccinProceso de desarrollo de software Ciclo de Ciclo de Ciclo de . . .desarrollo 1 desarrollo 2 desarrollo 3Caso de uso A:Versinsimplificada--------------Caso de uso A:Versincompleta--------------Caso de uso B----------------------------Caso de uso C----------------------------

IntroduccinProceso de desarrollo de software

Anlisis y Diseo OOAlgunas de las tareas a realizarse en la etapa de anlisis(dominio del problema) son las siguientes:

Anlisis y Diseo OOAlgunas de las tareas a realizarse en la etapa de diseo (dominio de la solucin) son las siguientes:

Caso de estudioCaso de estudio: punto de venta

Supongamos como caso de estudio el sistema de una terminalde punto de venta. Esta terminal es un sistema automatizadocon el que se registran las ventas y se realizan los pagos.

Por lo general este tipo de sistemas comprenden hardware (un computador y un lector de cdigo barras) y software (el sistema que se ejecuta en la terminal).

RequisitosLos requisitos

Los requisitos son una descripcin de las necesidadeso deseos de un producto.

Se recomienda aqu definir al menos los siguientes puntos:

Panorama general Metas Funciones del sistema

a) Panorama general Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se utilizar en las ventas de un supermercado.

b) Metas En trminos generales, la meta es una mayor automatizacin del pago en las cajas registradoras, y dar soporte a servicios ms rpidos, ms baratos y mejores. Concretamente, la meta incluye:

Pago rpido de los clientes. Anlisis rpido y exacto de las ventas. Control automtico del inventario.Requisitos

c) Funciones del sistema Las funciones del sistema son lo que ste deber de hacer.

Las funciones pueden clasificarse en tres categoras: evidentes, ocultas y superfluas. Las evidentes deben realizarse, y el usuario debe saber que se han realizado. Las ocultas tambin deben realizarse, y puede que no sean visibles para el usuario. Las superfluas son opcionales, y su inclusin no repercute significati- vamente en el costo ni en otras funciones.Requisitos

Estas son algunas de las funciones del sistema de punto de venta:Ref. Funcin Categora

R1.1 Registra la venta en proceso (actual): los productos comprados. evidenteR1.2 Calcula el total de la venta actual; se incluye el impuesto. evidenteR1.3 Captura la informacin sobre el objeto comprado usando su cdigo de barras, o usando una captura manual del cdigo de producto. evidenteR1.4 Reduce las cantidades del inventario cuando se realiza una venta. ocultaR1.5 Se registran las ventas efectuadas. ocultaR1.6 El cajero debe introducir una identificacin y una contrasea para poder utilizar el sistema. evidenteR1.7 Ofrece un mecanismo de almacenamiento persistente. ocultaR1.8 Ofrece mecanismos de comunicacin entre los procesos y entre los sistemas. ocultaR1.9 Muestra la descripcin y el precio del producto registrado. evidenteRequisitos

Casos de uso

Los casos de uso requieren tener al menos un conocimiento parcialde los requerimientos del sistema. Un caso de uso es un documentonarrativo que describe la secuencia de eventos de un actor (agenteexterno) que utiliza un sistema para completar un proceso. Casos de uso

El formato para la descripcin de los casos de uso es el siguiente:

Caso de uso: Nombre Actores: Lista de actores (agentes externos) Propsito: Intencin del caso de uso Resumen: Repeticin del caso de uso de alto nivel o alguna sntesis. Tipo: Primario, secundario u opcional. Esencial o real. Referencias cruzadas: Casos de uso relacionados y funciones relacionadas del sistema. Descripcin: Descripcin del caso de uso.Casos de uso

Ejemplo: el siguiente caso de uso describe el proceso de comprar artculos en una tienda, a travs de un terminal de punto de venta.

Caso de uso: Comprar productosActores: Cliente, cajeroTipo: PrimarioDescripcin: Un Cliente llega a la caja registradora con los artculos que va a comprar. El Cajero registra los artculos y cobra el importe. Al terminar la operacin, el Cliente se marcha con los productos.Es conveniente comenzar con los casos de uso de ms alto nivel paralograr comprender mejor los principales procesos globales.Casos de uso

Diagrama UML de casos de uso para el sistema de punto de venta:Este esquema tiene por objeto ofrecer un diagrama contextual que nos permita conocer rpidamente los actores externos de un sistema y las formas bsicas en que stos lo utilizan.Casos de uso

Un diagrama de casos de uso ms refinado seria el siguiente:Casos de uso

Modelo conceptual

Un modelo conceptual explica los conceptos significativos en undominio del problema, identificando los atributos y las asociaciones,y es la herramienta ms importante del anlisis orientado a objetos.

Los casos de uso son una importante herramienta para el anlisis derequerimientos, pero realmente no estn orientados a objetos. Unmodelo conceptual representa cosas del mundo real, no componentesdel software. En los diagramas UML se muestran conceptos (objetos),asociaciones entre conceptos (relaciones) y atributos de conceptos(atributos).Modelo conceptual

La siguiente figura muestra un modelo conceptual parcial deldominio de la tienda y las ventas.Modelo conceptual

Modelo conceptualLa siguiente lista muestra un conjunto de conceptos idneos para serincluidos en el modelo conceptual.

Objetos fsicos o tangiblesEspecificaciones, diseo o descripciones de cosasLugaresTransaccionesLnea o rengln de un elemento de transaccionesRol de las personasContenedores de otras cosasCosas dentro de un contenedorOtros sistemas de cmputo o electromecnicos externos al sistemaOrganizacionesEventosProcesosReglas y polticasCatlogosRegistros de finanzas, de trabajo, de contratos, de asuntos legalesInstrumentos y servicios financierosManuales y libros

A partir de esta lista de categoras de conceptos podemos generarun conjunto de conceptos para nuestro problema del punto de venta:

TDPV EspecificaciondeProducto Producto VentasLineadeProductos Tienda Cajero Venta Cliente Pago Gerente CatalogodeProductos Modelo conceptual

Por tanto, el modelo conceptual inicial del sistema de puntode venta (sin incluir atributos ni asociaciones) sera:Modelo conceptual

Asociaciones

Una asociacin es una relacin entre dos conceptos que indicaalguna conexin significativa entre ellos. Las asociaciones tilesa determinar, suelen incluir el conocimiento de una relacin queha de preservarse por algn tiempo: puede tratarse de milisegundoso de aos (segn el contexto). Por ejemplo, debemos recordarcuales instancias de VentasLineadeProducto estn asociadas aVenta? Si, porque de lo contrario no sera posible reconstruir la venta,imprimir la boleta ni calcular el total de la venta. Modelo conceptual

Para identificar las asociaciones ms comunes, la siguiente listaes de gran ayuda.

A es una parte fsica o lgica de BA est lgica o fsicamente contenido en BA es una descripcin de BA es un elemento de lnea (o rengln) en una transaccin o reporte BA se conoce/introduce/registra/presenta/captura en BA es miembro de BA es una unidad organizacional de BA usa o dirige a BA se comunica con BA se relaciona con una transaccin BA es una transaccin relacionada con otra transaccin BA es propiedad de BModelo conceptual

La multiplicidad define cuntas instancias de un tipo A pueden asociarse a una instancia del tipo B en determinado momento. Las expresiones de multiplicidad son las siguientes: *cero o ms, muchos1..*uno o ms1..40de uno a cuarenta5exactamente cinco 2,4,6exactamente dos, cuatro o seis Por ejemplo:Modelo conceptual

Los nombres de las asociaciones deben ser lo ms claros posibles, y deben permitir leer y entender fcilmente las relaciones entre conceptos. Por ej.:Modelo conceptual

Modelo conceptual

Diagramas de secuenciaEl diagrama de secuencia de un sistema muestra grficamente los eventos que originan los actores y que impactan al sistema.

La creacin de los diagramas de secuencia depende de la formulacin de los casos de uso.

Durante la operacin del sistema, los actores generan eventos, solicitando alguna operacin a cambio. Ejemplo: cuando un cajero ingresa un cdigo de barras de un artculo, est pidiendo al sistema de TPV que registre esa compra. Con este evento se inicia una operacin en el sistema.

Antes de hacer el diseo lgico de la aplicacin de software, es conveniente investigar y definir su comportamiento como una "caja negra".

Se estudia el comportamiento del sistema, desde la perspectiva de qu es lo que hace, y no de cmo lo hace.Diagramas de secuenciaDefinicin: El diagrama de secuencia de un sistema es una representacin que muestra, en determinado escenario de un caso de uso, los eventos generados por actores externos, su orden y los eventos internos del sistema. En esta fase del proyecto, el sistema mismo es una caja negra.

Recordemos el caso de uso Comprar productos:

Caso de uso: Comprar productos Actores: Cliente, cajero Tipo: Primario Descripcin: Un Cliente llega a la caja registradora con los artculos que va a comprar. El Cajero registra los artculos y cobra el importe. Al terminar la operacin, el Cliente se marcha con los productos.Diagramas de secuencia

El diagrama de secuencia del caso de uso ComprarProductospodra ser el siguiente:

Diagramas de secuencia

Anlisis y Diseo OOLas herramientas usadas en la etapa de anlisis (investigacindel problema) se pueden resumir en la siguiente tabla.

Herramienta de anlisis Preguntas que contesta

Casos de uso Cules son los procesos del dominio?

Modelo conceptual Cules son los conceptos, los trminos?

Diagramas de secuencia Cules son los eventos y las operac. del sistema?

Diagramas de colaboracinDiagramas de colaboracin

Los diagramas de interaccin (diagramas de secuencia y diagramasde colaboracin) explican grficamente cmo los objetos interactana travs de mensajes para realizar las tareas.

Antes de definir estos diagramas, hay que generar el modelo conceptual y los casos de uso reales (estos ltimos se generan a partir de los casos de uso definidos en el anlisis).

Diagramas de colaboracinLos diagramas de colaboracin explican grficamente las interacciones entre las instancias del modelo (objetos). Por ejemplo:

Diseo de la solucin

Para cada evento del sistema se debe construir un diagramade colaboracin cuyo mensaje inicial sea el de sus eventos.En el caso del punto de venta, tendremos tres diagramas,uno para cada evento: pasarProducto, terminarVenta, yefectuarPago.Diagramas de colaboracin

El diagrama de colaboracin del caso de uso pasarProducto serael siguiente:Diagramas de colaboracin

Diagramas de clases

Anlisis y Diseo OO

Nombre: Modelo-Vista-Controlador (MVC) [Buschmann 96].Problema: Las interfaces de usuario son especialmente propensas a cambios de requerimientos. Cuando se extiende la funcionalidad de una aplicacin, se deben modificar cosas, por ejemplo: mens, botones, ventanas, etc. Solucin: MVC divide una aplicacin en tres reas: procesamiento, entrada y salida. El componente modelo encapsula los datos y la funcionalidad principales de la aplicacin. El componente Vista despliega la informacin al usuario, a partir de los datos del Modelo. Cada Vista tiene un componente Controlador asociado, que se encarga de recibir las entradas del usuario (movimiento del mouse, activacin de los botones o entradas de teclado). Esta separacin de componentes, permite, entre otras cosas, tener distintas vistas del mismo modelo.Anlisis y Diseo OO

Ejemplo: La mayora de aplicaciones con interfaz grfica utilizan este esquema. La programacin con herramientas visuales como Visual Basic, JBuilder, Delphi, etc. sigue este esquema. Beneficios: Es posible tener mltiples vistas de un mismo modelo. Es posible sincronizar las vistas cuando varios usuarios usan la misma aplicacin (juegos multiusuario, sistemas colaborativos, etc). La separacin conceptual permite intercambiar la vista y el controlador de un determinado modelo (plug and play). Anlisis y Diseo OO

Anlisis y Diseo OOEl patrn MVC separa dos conceptos fundamentales en toda aplicacin: la interfaz (vista y controlador) y el modelo (datos y funcionalidad). Usando este patrn podramos implementar la interfaz de nuestra aplicacin de punto de venta como un applet Java, como un programa Java stand-alone, y de otras formas (no necesariamente en Java).

Fin