Anlisis y diseo - Parte II ADOO - Lic.

Morales INF-162 La mayora de proyectos de software son complejos, y la estrategia primaria para superar la complejidad, es la descomposicin (divide y vencers). La estrategia es dividir el problema en unidades ms pequeas que sean manejables. Un enfoque tradicional para realizar esto fue el anlisis y diseo estructurados, donde se trata de descomponer el problema en funciones o procesos. Este mtodo origina una divisin jerrquica de procesos constituidos por sub-procesos. Por ejemplo, una descomposicin por funciones o procesos en anlisis y diseo estructurados, de un Sistema de Informacin de Biblioteca podra ser el siguiente:

Otra forma de realizar la descomposicin, es usando un esquema de anlisis y diseo orientado a objetos. En este esquema, se busca descomponer el problema en objetos, y no en funciones. Por ejemplo, una descomposicin orientada a objetos del Sistema de Informacin de Biblioteca podra ser la siguiente:

Algunas de las tareas a realizarse en la etapa de anlisis son las siguientes: 1. Definir los requerimientos. 2. Definir los casos esenciales de uso. 3. Crear y perfeccionar los diagramas de casos de uso. 4. Crear y perfeccionar el modelo conceptual. 5. Crear y perfeccionar el glosario. 6. Definir los diagramas de secuencia de los sistemas. 7. Definir los contratos de operaciones. Algunas de las tareas a realizarse en la etapa de diseo son las siguientes: 1. Definir los casos reales de uso. 2. Definir los reportes, la interfaz de usuario y la secuencia de las pantallas. 3. Perfeccionar la arquitectura del sistema. 4. Definir los diagramas de interaccin. 5. Definir los diagramas de diseo de clases. 6. Definir el esquema de la base de datos.

Caso de estudio: el punto de venta Supongamos como caso de estudio el sistema de una terminal de punto de venta. Esta terminal es un sistema automatizado con 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). Suponga que se nos ha contratado para crear este software. Los requerimientos Los requerimientos son una descripcin de las necesidades o deseos de un producto. La meta principal en esta etapa es identificar y documentar lo que en realidad se necesita, en una forma en que pueda fcilmente ser transmitido al cliente y al equipo de desarrollo. Se recomienda aqu definir al menos los siguientes puntos: Panorama general Metas Funciones del sistema Atributos 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 al menudeo. 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. Ms concretamente, la meta incluye: Pago rpido de los clientes. Anlisis rpido y exacto de las ventas. Control automtico del inventario. c) Funciones del sistema Las funciones del sistema son lo que ste deber de hacer. Hay que identificar estas funciones y listarlas en grupos lgicos. Para verificar que X es en verdad una funcin del sistema, la siguiente frase deber tener sentido: "El sistema deber hacer X". Por ejemplo: "el sistema deber autorizar pagos a crdito". 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. Muchas de estas funciones se omiten (errneamente) durante el proceso de obtencin de requerimientos. Las superfluas son opcionales, y su inclusin no repercute significativamente en el costo ni en otras funciones. Las siguientes son algunas de las funciones ms representativas del sistema de punto de venta: Funciones bsicas: Referencia R1.1 R1.2 R1.3 Funcin Registra la venta en proceso (actual): los productos comprados. Calcula el total de la venta actual; se incluye el impuesto. Categora evidente evidente

Captura la informacin sobre el objeto comprado usando su cdigo de barras evidente y un lector, o usando una captura manual de un cdigo de producto.

R1.4 R1.5 R1.6 R1.7 R1.8 R1.9

Reduce las cantidades del inventario cuando se realiza una venta. Se registran las ventas efectuadas. El cajero debe introducir una identificacin y una contrasea para poder utilizar el sistema. Ofrece un mecanismo de almacenamiento persistente.

oculta oculta evidente oculta

Ofrece mecanismos de comunicacin entre los procesos y entre los sistemas. oculta Muestra la descripcin y el precio del producto registrado. evidente

Funciones de pago: Referencia R2.1 Funcin Maneja los pagos en efectivo, capturando la cantidad ofrecida y calculando el saldo deudor. Maneja los pagos a crdito, capturando la informacin crediticia a partir de una lectora de tarjetas, o mediante captura manual, y autorizando los pagos con el servicio de autorizacin (externa) de crditos de la tienda a travs de una conexin por modem. Maneja los pagos con cheque, capturando el nmero de RUT y telfono mediante captura manual, y autorizando los pagos con el servicio de autorizacin (externo) de cheques de la tienda a travs de consulta telefnica. Registra los pagos en el sistema de cuentas por cobrar, pues el servicio de autorizacin de crdito debe a la tienda el monto del pago. Categora evidente

R2.2

evidente

R2.3

evidente

R2.4

oculta

d) Atributos del sistema Los atributos del sistema son cualidades no funcionales que a menudo se confunden con las funciones. Por ejemplo: facilidad de uso, tolerancia a fallas, tiempo de respuesta, metfora de interfaz, plataformas. Los atributos tienen un posible conjunto de detalles de atributos, los cuales tienden a ser valores discretos, confusos o simblicos. Por ejemplo: tiempo de respuesta = (psicolgicamente correcto) metfora de interfaz = (grfico, colorido, basado en formularios) Algunos atributos del sistema tambin pueden tener restricciones de frontera del atributo, que son condiciones obligatorias de frontera, generalmente en un rango numrico de valores de un atributo. Por ejemplo: tiempo de respuesta = (dos segundos como mximo) Algunos atributos del sistema de punto de venta son: Atributo tiempo de respuesta Detalles y restricciones de frontera (restriccin de frontera) Cuando se registre un producto vendido, la descripcin y el precio aparecern en un segundo.

(detalle) Ventanas orientadas a la metfora de un formulario y cuadros de metfora de interfaz dilogo. (detalle) Maximiza una navegacin fcil con teclado y no con mouse. tolerancia a fallas plataformas del sistema operativo (restriccin de frontera) Debe registrar los pagos a crdito autorizados que se hagan a las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de energa o del equipo. (detalle) Microsoft Windows 95, 98, 2000 y NT.

Finalmente, es conveniente describir todos los atributos del sistema que se relacionen claramente con las funciones especificadas. Adems, los detalles de los atributos y las restricciones de frontera pueden catalogarse como obligatorios u opcionales. Por ejemplo: Ref. Funcin Categora evidente Atributo tiempo de respuesta metfora de interfaz Registrar los pagos a crdito en el sistema de cuentas por cobrar, pues el R2.4 servicio de autorizacin de crdito debe a la tienda el importe del pago. Detalles y restricciones 1 segundo como mximo Pantallas basadas en formularios. Con colores. Debe registrar en las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de energa o del equipo. 10 segundos como mximo Categora obligatorio

Mostrar la descripcin y el R1.9 precio del producto registrado.

obligatorio

oculto

tolerancia a fallas

Obligatorio

tiempo de respuesta Casos de uso

Obligatorio

Los casos de uso requieren tener al menos un conocimiento parcial de los requerimientos del sistema. Un caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso. Para especificar los casos de uso en el lenguaje UML, se utiliza una elipse que encierra el nombre del caso. El formato para la descripcin de los casos de uso es el siguiente: Caso de uso: Nombre del caso de uso Lista de actores (agentes externos), en la cual se indica quin inicia el caso de uso Actores: Propsito: Intencin del caso de uso Resumen: Repeticin del caso de uso de alto nivel o alguna sntesis similar. Primario, secundario u opcional. Esencial o real. Tipo: Referencias Casos relacionados de uso y funciones tambin relacionadas del sistema. cruzadas: Descripcin: Descripcin del caso de uso.

Los casos primarios de uso representan los procesos comunes ms importantes. Los casos secundarios de uso representan procesos menores o raros. Finalmente, los casos opcionales de uso representan procesos que pueden no abordarse. Ejemplo: el siguiente caso de uso describe claramente el proceso de comprar artculos en una tienda, a travs de una terminal de punto de venta. Caso de uso: Comprar productos Cliente, cajero Actores: Primario Tipo: 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. Es conveniente comenzar con los casos de uso de alto nivel para lograr rpidamente entender los principales procesos globales. Otros casos de uso del sistema de punto de venta son: Caso de uso: Comprar productos en efectivo Cliente (iniciador), Cajero. Actores: Propsito: Capturar una venta y su pago en efectivo. Resumen: Un Cliente llega a la caja registradora con artculos que desea comprar. El Cajero registra los productos y recibe un pago en efectivo. Al terminar la operacin, el Cliente se marcha con los productos comprados. Primario y esencial. Tipo: Referencias Funciones: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1. cruzadas: 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. La siguiente figura muestra un diagrama parcial de casos de uso para el sistema de punto de venta.

Este esquema tiene por objeto ofrecer una clase de diagrama contextual que nos permita conocer rpidamente los actores externos de un sistema y las formas bsicas en que lo utilizan. Un caso de uso describe la interaccin con un sistema. Las fronteras del sistema se representan en el diagrama por un rectngulo exterior. Las fronteras corresponden a: la frontera hardware/software de un dispositivo o sistema de cmputo, un departamento de una organizacin, o la organizacin entera. Otro caso de uso sera el siguiente: Caso de uso: Inicio de operaciones Gerente. Actores: Primario. Tipo: Descripcin: Un gerente activa una terminal de punto de venta con el fin de prepararla para que la usen los cajeros. El Gerente comprueba que la fecha y la hora sean correctos. Hecho esto, el sistema est listo para ser usado por el cajero. En sntesis, para determinar los casos de uso de un sistema, es necesario, como primer paso, identificar los actores y sus funciones. El segundo paso es describir los casos de uso en el formato visto arriba. El tercer paso es dibujar el diagrama de casos de uso. Ejemplo: (paso 1). Una lista de los actores y procesos relevantes en la aplicacin de punto de venta son los siguientes: Cajero Cliente Gerente Registra los productos Entrega el cambio Compra productos Paga los productos Inicia Cierra

Administrador Incorpora nuevos usuarios del sistema El diagrama de casos de uso (paso 3) sera similar al siguiente:

Definicin: Un caso de uso expandido muestra ms detalles que un caso de uso de alto nivel. Los casos de uso expandidos son tiles para alcanzar un conocimiento ms profundo de los procesos y los requerimientos. Ejemplo: Caso de uso: Actores: Propsito: Resumen: Comprar productos en efectivo

Cliente (iniciador), Cajero. Capturar una venta y su pago en efectivo. Un Cliente llega a la caja registradora con artculos que desea comprar. El Cajero registra los productos y recibe un pago en efectivo. Al terminar la operacin, el Cliente se marcha con los productos comprados. Primario y esencial. Tipo: Referencias Funciones: R1.1, R1.2, R1.3, R1.7, R1.9, R2.1. cruzadas: Curso normal de los eventos: Accin del actor 1. Este caso de uso comienza cuando un cliente llega a una caja del terminal de punto de venta (TPV) con productos para comprar. 2. El Cajero registra el identificador de cada producto. Si hay varios productos de una misma categora, el Cajero tambin puede introducir la cantidad. 4. Al terminar de introducir los productos, el Cajero indica al TPV que se concluyo la captura de los mismos. 6. El Cajero le indica el total al cliente. 7. El Cliente efecta un pago en efectivo, posiblemente mayor que el total de la venta. 8. El Cajero registra la cantidad de efectivo recibida. 9. Muestra al Cajero y al Cliente la diferencia. Genera la boleta. 3. Determina el precio del producto e incorpora a la transaccin actual la informacin correspondiente. Respuesta del sistema

5. Calcula y presenta el total de la venta.

10. El cajero deposita el efectivo recibido en la caja, 11. Registra la venta concluida. y extrae el cambio. 12. El cliente se marcha con los artculos comprados. Cursos alternos Item 2: Introduccin de identificador invlido. Indicar error. Item 7: El cliente no tiene suficiente dinero. Cancelar transaccin de venta o restar productos.

Definiciones Los casos de uso se emplean para capturar el comportamiento deseado del sistema en desarrollo, sin tener que especificar cmo se implementa ese comportamiento. Proporcionan un medio para que los desarrolladores, los usuarios finales del sistema y los expertos del dominio lleguen a una comprensin comn del sistema. Adems ayudan a validar la arquitectura y a verificar el sistema mientras evoluciona a lo largo del desarrollo. Por lo general el nombre de un caso de uso comienza con un verbo en infinitivo. Un caso de uso describe un proceso de principio a fin, es decir, una secuencia de eventos, las acciones y las transacciones que se requieren para realizarlo. Debe ser posible revisar en las referencias cruzadas, que todas las funciones (de los requerimientos) hayan sido asignadas. Fronteras Un caso de uso define la interaccin con un sistema. Las fronteras del sistema normalmente son: la frontera software/hardware de un dispositivo o sistema de cmputo, el departamento de una organizacin, la organizacin entera. Las fronteras son importantes para definir lo que es interno y externo al sistema. El ambiente externo est representado exclusivamente por los actores. Las dos siguientes figuras muestran dos fronteras diferentes para el mismo sistema.

Casos de uso y actores cuando el sistema TPV es la frontera.

Casos de uso y actores cuando la tienda es la frontera. Repasar : Objetos, clases y herencia Actores Un actor representa un conjunto coherente de roles que juegan los usuarios de los casos de uso cuando interactan con stos. Los actores pueden ser personas (roles que desempean las personas), aparatos elctricos o mecnicos, y otros sistemas de cmputo. Se pueden definir categoras generales de actores (como cliente en el ejemplo de abajo) y especializarlos (como ClienteComercial) a travs de relaciones de generalizacin. Ejemplo:

Los casos de uso pueden ser versiones especializadas de otros casos de uso, casos de uso incluidos como parte de otros casos de uso, y casos de uso que extienden el comportamiento de otros casos de uso bsicos. Organizacin de casos de uso Los casos de uso pueden organizarse agrupndolos en paquetes. Tambin se pueden especificar relaciones de generalizacin, inclusin y extensin. Generalizacin significa que el caso de uso hijo hereda el comportamiento y el significado del caso de uso padre, donde el hijo puede agregar o redefinir el comportamiento del padre. La generalizacin entre casos de uso se representa como una lnea continua con una punta de flecha vaca.

Una relacin de inclusin entre dos casos de uso significa que un caso de uso base incorpora explcitamente el comportamiento de otro caso de uso en el lugar especificado en el caso base. Aqu el caso de uso base toma el comportamiento del caso de uso proveedor. Esta relacin se usa para evitar describir el mismo flujo de eventos repetidas veces, poniendo el comportamiento comn en un caso de uso aparte (que ser incluido por un caso base). Una relacin de inclusin se representa como una dependencia, usando la palabra include. Para especificar la posicin en un flujo de eventos, se usa la palabra include seguido del caso de uso que se quiere incluir. Por ejemplo, para describir el flujo de Seguir pedido: Flujo de eventos principal: Obtener y verificar el nmero de pedido. include (validar usuario). Examinar el estado de cada parte del pedido y preparar un informe para el usuario. Una relacin de extensin entre casos de uso significa que un caso de uso base incorpora implcitamente el comportamiento de otro caso de uso en el lugar especificado indirectamente por el caso de uso que extiende al base. Un caso de uso puede extenderse solamente en ciertos puntos,

llamados puntos de extensin. La extensin se puede ver como que el caso de uso que extiende, incorpora su comportamiento en el caso de uso base. Se representa como una dependencia con la palabra extend. Los puntos de extensin slo son etiquetas que pueden aparecer en el flujo del caso de uso base. Por ejemplo, el flujo de Hacer pedido podra escribirse as: Flujo de eventos principal: include (Validar usuario). Recoger los temes del pedido del usuario. (establecer prioridad). Enviar el pedido para ser procesado. Una relacin de extensin se usa para modelar la parte de un caso de uso que el usuario puede ver como comportamiento opcional del sistema. De esta forma se separa el comportamiento opcional del obligatorio. Es decir, un caso de uso base puede, bajo ciertas condiciones, incorporar el comportamiento de otro caso de uso en el lugar especificado. Ejemplo 1: Sistema de ventas. Un sistema de ventas debe interactuar con clientes, los cuales efectan pedidos. Adems los clientes pueden hacer un seguimiento de sus propios pedidos. El sistema enva los pedidos y las facturas a los clientes. En algunos casos, segn la urgencia de los clientes, se puede adelantar parte del pedido (pedidos parciales).

Como se muestra en la figura anterior, el comportamiento de este sistema se puede modelar usando los casos de uso Hacer pedido, Seguir pedido, Enviar pedido, Facturar cliente. El comportamiento comn puede factorizarse (Validar cliente) y tambin pueden distinguirse sus variantes (Enviar pedido parcial). Cada caso de uso debe incluir una especificacin de su comportamiento. Ejemplo 2:Validacin de tarjetas de crdito. La figura de abajo muestra el contexto de un sistema de validacin de tarjetas de crdito. Se puede ver que existen dos categoras de clientes: clientes individuales, clientes corporativos. Estos actores representan los roles que juegan las personas que interactan con el sistema. Tambin hay actores que representan otras instituciones, como Comercio, con el cual el cliente realiza una transaccin para comprar un artculo o servicio, y Entidad financiera, que por lo general es una entidad bancaria donde el usuario tiene la tarjeta de crdito.

Modelado del contexto de un sistema Ejercicios 1 -. El hipdromo. Un hipdromo ofrece a sus clientes la posibilidad de asistir a las carreras y de realizar apuestas. Cules son los actores que interactan con estos servicios? Construya el diagrama de casos de uso 2 -. El club ecuestre Un club ecuestre pone a disposicin de los clientes establos para guardar los caballos y ofrece cursos de equitacin y paseos. Slo los socios tienen acceso a los cursos y a los servicios de establo. Los dems clientes tienen la posibilidad de participar en los paseos y de convertirse en socios. Cules son los actores que interactan con estos servicios? Construya el diagrama de casos de uso 3 -. El tiovivo de caballos de madera Un tiovivo de caballos de madera ofrece a sus clientes la posibilidad de dar una vuelta en l previo pago de una cantidad de dinero. Cules son los actores vinculados a este servicio?. Construya el diagrama de casos de uso. D la representacin textual correspondiente al diagrama. 4 -. Hotel El dueo de un hotel nos pide desarrollar un programa para consultar las habitaciones disponibles y poder reservar habitaciones en su hotel. El hotel posee tres tipos de habitaciones: simple, doble y matrimonial, y dos tipos de clientes: habituales y espordicos. Una reserva almacena datos del cliente, de la habitacin reservada, la fecha de comienzo y el nmero de das que ser ocupada la habitacin. El recepcionista del hotel debe poder hacer las siguientes operaciones: Obtener un listado de las habitaciones disponible de acuerdo a su tipo. Preguntar por el precio de una habitacin de acuerdo a su tipo. Preguntar por el descuento ofrecido a los clientes habituales. Preguntar por el precio total para un cliente dado, especificando su nmero de reserva, tipo de habitacin y nmero de noches. Dibujar en pantalla la foto de una habitacin de acuerdo a su tipo. Reservar una habitacin especificando el nmero de la pieza, reserva y nombre del cliente. Eliminar una reserva especificando el nmero de la habitacin. El administrador puede usar el programa para: Cambiar el precio de una habitacin de acuerdo a su tipo. Cambiar el valor del descuento ofrecido a los clientes habituales. Calcular las ganancias que tendrn en un mes especificado (considere que todos los meses tienen treinta das). El diseo a desarrollar debe facilitar la extensibilidad de nuevos tipos de habitaciones o clientes y a su vez permitir agregar nuevas consultas.