Universidad Tecnolgica del Per - UTP PRESENTACIN Cada uno de los captulos se divide en partes que van ayudar

a los lectores a un aprendizaje rpido en temas especficos. En el capitulo I se proporciona un panorama breve de los sistemas de informacin, los conceptos bsicos de la tecnologa de objetos y del lenguaje unificado de modelado. En el capitulo II se tiene un resumen del modelado de negocio, requisitos anlisis y diseo. En el capitulo III utilizamos los conceptos del anlisis orientado a objetos para organizar los elementos en paquetes, descripcin de casos de uso y elaboracin de los diagramas de casos de uso. En el capitulo IV mostramos el aspecto dinmicos de los sistemas a travs de los diagramas de secuencia y de colaboracin. En el capitulo V modelamos la vista esttica de un sistema, a travs de las instancias de los elementos contenidos en los diagramas de clases . En el capitulo VI modelamos el aspecto dinmico de los sistemas utilizando los diagramas de actividad que se centra en las actividades que ocurren dentro del objeto, y los diagramas de estado, que se centran en el comportamiento dirigidos por eventos de un objeto. En el capitulo VII de describen los elementos fsicos del sistema y sus relaciones. Adems, la disposicin fsica de los distintos nodos que componen un sistema.

Universidad Tecnolgica del Per - UTP

INDICE CAPITULO I 1.1 Introduccin

1.2 Sistema de informacin

4 4 4 7 9 13 13 14 15 15 16 16 17 22 28 28 29 34

1.3 Conceptos Bsicos de la Tecnologa de Objetos 1.4 El Lenguaje Unificado de Modelado (UML) CAPITULO II 2.1 2.2 2.3 2.4 Modelado del Negocio Modelado de Requisitos Modelado del Anlisis Modelado del Diseo

CAPITULO III 3.1 Organizando los Elementos en Paquetes 3.2 Casos de Uso 3.3 Diagramas de Casos de Uso CAPITULO IV 4.1 Diagramas de Interaccin 4.1.1 Diagrama de Secuencia 4.1.2 Diagrama de Colaboracin

CAPITULO V 5.1 Diagrama de Objetos 5.2 Clases 5.3 Diagrama de Clases CAPITULO VI 6.1 Diagrama de Estado 6.2 Diagrama de Actividad CAPITULO VII 7.1 7.2 7.3 7.4 Bibliografa Diagrama de Componentes Diagrama de Distribucin Trabajo Prctico Arquitectura de Tres Capas

37 37 38 49 72 72 85 94 94 95 98 115 120

Universidad Tecnolgica del Per - UTP

DISTRIBUCIN TEMTICA Clase Tema N 1 Introduccin a los Sistemas de Informacin: Enfoque Sistmico, Enfoque Orientado a Objeto 2 Conceptos Bsicos de la Tecnologa de Objetos 3 Anlisis y Diseo de Sistemas Orientado a Objetos (Modelando en UML) 4 Casos de Uso Diagramas de Casos de Uso. Organizando los Elementos de Paquetes 5 Casos de Uso Diagramas de Casos de Uso. Organizando los Elementos de Paquetes (Continuacin) 6 Diagrama de Interaccin: Diagrama de Secuencia Diagrama de Colaboracin 7 Diagrama de Interaccin: Diagrama de Secuencia Diagrama de Colaboracin (Continuacin) 8 Diagrama de Objetos Comparacin del Anlisis Orientado a Objetos y el Diseo Orientado a Objetos 9 Diagramas de Clases 10 EXAMEN PARCIAL 11 Diagrama de Clases (Continuacin) 12 Especificacin de la Lgica General 13 Diagramas de Comportamiento: Diagrama de Estado Diagrama de Actividad 14 Diagramas de Comportamiento: Diagrama de Estado Diagrama de Actividad (Continuacin) 15 Diagrama de implementacin: Diagrama de Componentes Diagrama de distribucin 16 Arquitectura Clsica de Tres Capas 17 Diagrama de despliegue 18 Revisin, Nivelacin 19 EXAMEN FINAL

Semana 1

Horas
03

2 3

03 03

03

03

03

03

03

9 10 11 12 13

03 03 03 03 03

14

03

15

03

16 17 18 19

03 03 03 03

Universidad Tecnolgica del Per - UTP

CAPITULO I
1.1 INTRODUCCIN Los altos ejecutivos, estadistas o cualquier persona que tiene un puesto de responsabilidad en las empresas, instituciones privadas o estatales, encuentran cada da ms difcil el tomar una decisin sobre el curso de accin para solucionar, de la mejor forma un problema. Esta situacin hace que los sistemas de informacin sean cada vez ms importantes para el desenvolvimiento diario de la empresa. Sistema Desde un punto de vista prctico un sistema es un conjunto de elementos dinmicamente relacionados entre s, para alcanzar un objetivo. Sistema Productivo En un proceso industrial entran insumos (materia prima), que pasan por un proceso de transformacin y se obtiene como resultado final un producto terminado. Paralelo a este proceso industrial, existe un sistema de informacin que utiliza los datos de los insumos, del proceso y del producto terminado 1.2 SISTEMA DE INFORMACIN (SI) Un sistema informtico utiliza ordenadores para almacenar datos, procesarlos y ponerlos a disposicin de quien se considere oportuno. Un sistema puede ser tan simple como: una persona tiene un microordenador y le introduce datos tan elementales, como por ejemplo las ventas diarias de una pequea empresa, se produce una entrada por cada venta y en ella se declara el elemento vendido, por ejemplo un yogur, la cantidad de elementos vendidos, por ejemplo cuatro y el precio de venta unitario, por ejemplo 0.15 euros. Cada entrada se almacena como un registro de un fichero en el disco. Al finalizar el da se puede obtener un informe de las ventas y las tendencias. El usuario puede utilizar esta informacin para la gestin de almacn o planificar campaas publicitarias. Habitualmente una empresa tiene ms de un ordenador, por ejemplo uno para la gestin de ventas y otro para la contabilidad y procesos asociados. Sin embargo la mayor parte de los sistemas son ms complejos. Los sistemas de informacin tienen muchas cosas en comn, la mayora de ellos estn formados por: Personas.- son un componente esencial en cualquier sistema de informacin, producen y utilizan la informacin de sus actividades diarias para decidir lo que se debe hacer. Las decisiones pueden ser rutinarias o complejas. Procedimientos.los sistemas de informacin deben soportar diversas clases de actividades del usuario, por eso han de establecerse procedimientos que aseguren que los datos correctos llegan a las personas adecuadas en su momento justo. 4

Universidad Tecnolgica del Per - UTP Equipo.- es decir los ordenadores y todos los dispositivos necesarios. Tipos de Sistemas de Informacin Es importante distinguir los diferentes tipos de sistemas de informacin, de acuerdo con la tecnologa aplicada. Estos tipos de sistemas de informacin se diferencian uno de otro por el uso de diversos elementos: 1. Dispositivos de entrada/salida. 2. Medios de almacenamiento. 3. Sistemas operativos. 4. Etctera.

S. I. de Proceso de Datos en Lotes (Batch) Captura de datos.- Por lo general los datos se capturan de documentos fuentes como : notas de ventas, remisiones y nominas de salarios. La informacin se puede registrar directamente en lugar donde se efectan las transacciones. Proceso de datos.- Este tipo de procesamiento es adecuado para ciertos procesos, por ejemplo: los datos de los sueldos de los empleados y los movimientos de cargo y crdito de los clientes son acumulados en lotes de transacciones y procesados en intervalos programados. Salida.- La salida de este procesamiento puede ser: Interna: Es la informacin para uso interno de la organizacin. Ejemplo: archivos actualizados, informes, etctera. Externa: Es la informacin que se utilizar fuera de la organizacin. Ejemplo: avisos enviados a los clientes, cheques de empleados y proveedores, etctera.

S.I. de Proceso de Datos en Lnea (On Line) Captura de datos.- los datos entran a travs del teclado (dispositivo de captura de datos en lnea) o de algn otro dispositivo en lnea, en el momento en que ocurre la transaccin. Proceso de datos.- Este proceso permite localizar y actualizar directamente cualquier registro sin necesidad de leer el que le precede. Cuando una computadora esta procesando un acceso directo, normalmente acepta la introduccin de datos desde un teclado conectado, un dispositivo de Coleccin de datos o un archivo de transacciones. Adems de la velocidad de actualizacin de los registros directos sin tener que clasificar el archivo, el proceso de acceso directo puede proveer informacin instantnea en respuesta a solicitudes de informacin formuladas desde las estaciones de lnea. Salida.- Las personas utilizan terminales para introducir datos en el sistema y para solicitar y recibir informacin del sistema. Cuando se utiliza terminales de punto de venta, o terminales de operaciones financieras, la computadora suele responder con una salida impresa producida por la terminal. Esta salida puede tener la finalidad exclusiva de ser utilizada por los miembros de una 5

Universidad Tecnolgica del Per - UTP organizacin. Los terminales de despliegue visuales son los dispositivos ms comunes empleados para recibir salida durante el procesamiento de acceso directo. Tambin pueden utilizarse las terminales de despliegue grfico para producir salida en forma de grficos, mapas y dibujos. Los cajeros automticos, a menudo exhiben instrucciones en pantalla para ayudar a los clientes de un banco en la realizacin de sus operaciones. Tambin se puede preparar respuestas con voz para proporcionar informacin de salida interna y externa. Dispositivos.- Los dispositivos empleados en aplicaciones de procesamiento en lnea tienen las siguientes caractersticas: Permiten introducir datos directamente a la CPU. Generalmente estn ubicados en o cerca de la fuente de datos, la cual puede estar alejada de la CPU. Permiten una relacin interactiva directa entre las personas y las computadoras. Manejan en forma econmica un volumen de datos de entrada. Ejemplos: Terminales porttiles de captura de datos. Terminales de punto de venta. Terminales para operaciones financieras. Terminales de despliegue visual.

S.I. de Procesos Distribuidos (Distributed Processing) Las tecnologas de hardware, de software, de base de datos y de redes contribuyen todas ellas a la arquitectura de computadoras distribuidas y cooperativas. En su forma ms general, un sistema raz, que tpicamente ser una gran computadora, acta como un depsito de los datos corporativos. El sistema raz est conectado con servidores (que tpicamente son estaciones de trabajo potentes, o PC) y que poseen un doble papel. Los servidores actan para actualizar y solicitar los datos corporativos mantenidos por el sistema raz. Adems mantienen sistemas departamentales locales y desempean un papel clave al poner en red los PC de nivel de usuario a travs de una red de rea local (LAN). S.I. de Proceso en Tiempo Real (Real Time) Un sistema en Tiempo Real esta en una relacin paralela de tiempo con una actividad en marcha y produce informacin con la rapidez necesaria para ser utilizada en el control de esa actividad. Por tanto, las palabras Tiempo Real describen un sistema de acceso directo o de procesamiento en lnea con limitaciones severas de tiempo. En este tipo de proceso muchas estaciones estn conectadas directamente por medio de lneas de telecomunicaciones de alta velocidad a una o ms CPU. Los archivos se actualizan cada minuto y las consultas se contestan por medio de accesos que tardan fracciones de segundo a los registros actualizados al instante. Sin embargo, es posible tener sistemas de acceso directo a los registros para propsitos de consulta, sin hacer uso de un sistema de tiempo real. 6

Universidad Tecnolgica del Per - UTP Categoras de los SI Puede decirse, en lneas generales, que esta evolucin ha tenido lugar en tres grandes etapas Sistema de Procesamiento de Transacciones.- tienen como objetivo automatizar procesos basados en la informacin (ej. facturacin) buscando simplemente mejorar el rendimiento operativo mediante la sustitucin del trabajo de los hombres por las mquinas Sistema de Informacin para la Direccin.- permiten a los directivos aprovechar la gran cantidad de datos acumulados, por los sistemas antes mencionados, para incrementar la efectividad de sus actividades de gestin y satisfacer sus necesidades de informacin Sistema de Informacin Estratgicos.- En la dcada de los ochenta la forma de actuar de algunas organizaciones innovadoras ponen de manifiesto la posibilidad de utilizar los sistemas de informacin para mejorar directamente la posicin competitiva de una empresa alterando la naturaleza, el comportamiento o la orientacin de los negocios. Se debe aclarar que estos tres sistemas se superponen; es decir: los tres se complementan.

1.3 CONCEPTOS BSICOS DE LA TECNOLOGIA DE OBJETOS Clase: Es una descripcin para producir objetos de esa clase o tipo. Una clase esta formada por los mtodos y los atributos, que definen las caractersticas comunes a todos los objetos de esa clase. Una clase se puede considerar como una plantilla para crear objetos de esa clase o tipo. Objetos: Es una encapsulacin genrica de datos y de los procedimientos para manipularlos. Dicho de otra forma un objeto es una entidad que tiene unos atributos particulares (los datos) y una forma de operar sobre ellos (los mtodos y los procedimientos). Jzquel 1996.- Un objeto describe una abstraccin caracterizada por una entidad del mundo real Existe en el tiempo Puede estar en diferentes estados (cambiantes) Puede ser creada y destruida Un objeto tiene una identidad que denota una existencia separada de los otros objetos El comportamiento de un objeto se manifiesta ante acciones y reacciones en forma de cambios de estado. Wirfs-Brook et al, 1990.- bsicamente un objeto contiene determinada informacin y es capaz de realizar determinadas operaciones Snyder, 1993.- bsicamente un objeto es una entidad que juega un papel visible al proporcionar servicios a clientes

Universidad Tecnolgica del Per - UTP Un objeto viene caracterizado por identidad (Oid Object identifier) a. identificador nico y global b. independiente de las propiedades c. invariable desde la creacin a la destruccin del objeto estado (el estado de un objeto condiciona su comportamiento) a. evoluciona a lo largo del tiempo b. es funcin de los valores de los atributos comportamiento a. describe las acciones y reacciones de un objeto b. las operaciones de un objeto se realizan como consecuencia de estmulos realizados mediante el envo de mensajes Mensajes: Cuando se utiliza el AOO, los objetos estn recibiendo, interpretando y respondiendo a mensajes de otros objetos. El conjunto de mensajes a los que un objeto puede responder se le llama protocolo. Mtodos: Un mtodo determina cmo tiene que actuar el objeto cuando recibe un mensaje. Un mtodo tambin puede enviar mensajes a otros objetos solicitando una accin o informacin. La descripcin de un mtodo se denomina operacin. Herencia: Es el mecanismo para compartir automticamente mtodos y datos entre clases y subclases. Encapsulamiento: Se refiere a la prctica de incluir dentro de un objeto todo lo que necesita, de tal forma que ningn otro objeto necesite conocer nunca su estructura interna. Polimorfismo: Es una caracterstica que permite implementar mltiples formas de un mismo mtodo, dependiendo de cada una de ellas de la case sobre la que se realice la implementacin. Anlisis orientado a objetos(OOA) Estudio de un problema previamente a tomar cualquier decisin sobre l Incluye o presupone un Anlisis del dominio Necesita una especificacin de requisitos Funcionales No funcionales El OOA se lleva a cabo desde la perspectiva de las clases y objetos que forman parte del vocabulario del dominio Especificacin del comportamiento observable externamente Establecimiento explcito de lo que se necesita consistente, completo, factible Cobertura funcional Cuantificacin de las caractersticas operacionales

Universidad Tecnolgica del Per - UTP Diseo orientado a objetos (OOD) La fase de diseo comienza al acabar la de anlisis Se extiende el modelado de clases a interfaz, utilidades, clases bsicas, gestin de la persistencia De forma gradual el nfasis pasa del dominio de la aplicacin al dominio de la computacin Estrategia de implementacin Representacin de los datos Algoritmos Deteccin de clases de la implementacin Programacin Orientada a Objetos (OOP) mtodo de implementacin en el cual los programas se organizan como colecciones colaborativas de objetos, cada uno de los cuales representa un ejemplar de una clases, y cada una de las clases forma parte de una jerarqua de clases ligadas por relaciones de herencia Ensamblado de componentes ms que programacin Componentes de software ms que programas 1.4 EL LENGUAJE UNIFICADO DE MODELADO, UML A mediados de los noventa existan muchos mtodos de anlisis y diseo OO. Mismos conceptos con distinta notacin. Mucha confusin. Guerra de los mtodos En 1994, Booch, Rumbaugh (OMT) y Jacobson (Objectory/OOSE) deciden unificar sus mtodos: Unified Modeling Language (UML) Proceso de estandarizacin promovido por el OMG El consorcio OMG Rational Software Hewlett-Packard IntelliCorp Platinum Technology Reich Technologies Oracle Sterling Software ICON Computing Petch Microsoft IBM MCI Systemhouse i-Logix Taskon A/S .... DEC Unisys ObjectTime Softeam

Las races tcnicas de UML OMT - Object Modeling Technique (Rumbaugh et al.) Especialmente bueno para anlisis de datos de SI. Entre otros, usa extensiones de los diagramas ER. Mtodo-Booch (G. Booch) Especialmente til para sistemas concurrentes y de tiempo real. Fuerte relacin con lenguajes de programacin, como Ada. OOSE - Object-Oriented Software Engineering (I. Jacobson) Desarrollo guiado por los use cases. Buen soporte de Ingeniera de Requisitos e Ingeniera de Informacin Modelado y simulacin de sistemas de telecomunicaciones UML unifica estos conceptos e introduce otros nuevos 9

Universidad Tecnolgica del Per - UTP Los rivales de UML Otras propuestas enviadas a OMG Catalysis (D. DSouza, A. Willis) Syntropy (S. Cook et al., IBM) OML/Open (B. Henderson-Sellers) Fusion (D. Coleman, HP) Ventajas de la unificacin Reunir los puntos fuertes de cada mtodo Idear nuevas mejoras Proporcionar estabilidad al mercado Proyectos basados en un lenguaje maduro Aparicin de potentes herramientas Eliminar confusin en los usuarios Objetivos en el diseo de UML Modelar sistemas, desde los requisitos hasta los artefactos ejecutables, utilizando tcnicas Orientadas a Objetos. Cubrir las cuestiones relacionadas con el tamao propio de los sistemas complejos y crticos. Lenguaje utilizable por las personas y las mquinas Encontrar equilibrio entre expresividad y simplicidad. UML y el modelado UML es una notacin, no es un proceso Se estn definiendo muchos procesos para UML. Rational ha ideado RUP, Proceso Unificado de Rational. Utilizable para sistemas que no sean software UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos (modelos) de un sistema que involucra una gran cantidad de software, desde una perspectiva OO. Por qu modelamos? 1. Construimos modelos para comprender mejor el sistema que estamos desarrollando 2. Cuatro utilidades de los modelos: Visualizar cmo es o queremos que sea el sistema Especificar la estructura y comportamiento del sistema Proporcionan plantillas que guan la construccin del sistema Documentan las decisiones 3. Equivalen a los planos de un edificio Una empresa software con xito es aquella que produce de manera consistente software de calidad que satisface las necesidades de los usuarios El modelado es la parte esencial de todas las actividades que conducen a la produccin de software de calidad Un modelo es una simplificacin de la realidad 10

Universidad Tecnolgica del Per - UTP Principios del modelado La eleccin de los modelos tiene una profunda influencia sobre cmo se acomete el problema y se moldea la solucin. Todo modelo puede expresarse a diferentes niveles de detalle y usarse en diferentes momentos del ciclo de vida. Todo modelo debe estar ligado a la realidad. Un nico modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a travs de un pequeo conjunto de modelos casi independientes, que muestran distintos aspectos. Por qu las empresas no hacen modelado? La mayor parte de las empresas software no realizan ningn modelado. El modelado requiere: aplicar un proceso de desarrollo formacin del equipo en la tcnicas tiempo Algunos problemas en el desarrollo de software Retrasos en los plazos Proyectos cancelados Rpido deterioro del sistema instalado Tasa de defectos o fallos Requisitos mal comprendidos Cambios frecuentes en el dominio del problema Muchas de las interesantes caractersticas del software no proporcionan beneficios al cliente Utilidad del modelado Se facilita la comunicacin entre el equipo al existir un lenguaje comn. Se dispone de documentacin que trasciende al proyecto. Hay estructuras que trascienden lo representable en un lenguaje de programacin. Utilidad de UML Permite especificar todas las decisiones de anlisis, diseo e implementacin, construyndose modelos precisos, no ambiguos y completos. UML puede conectarse a lenguajes de programacin: Ingeniera directa e inversa Permite documentar todos los artefactos de un proceso de desarrollo (requisitos, arquitectura, pruebas, versiones,..)

Diagramas de UML (http://www.agilemodeling.com/essays/umlDiagrams.htm) Diagramas de Casos de Uso Diagramas de Clases Diagramas de Objetos Diagramas de Interaccin Diagrama de Secuencia Diagrama de Colaboracin (UML 2.0) 11

Universidad Tecnolgica del Per - UTP Diagramas de Estados Diagramas de Actividades Diagramas de Componentes Diagramas de Despliegue Composite Structure Diagram (UML 2.0) Package Diagram (UML 2.0) Interaction Overview Diagram (UML 2.0) Timing Diagram (UML 2.0)

Reglas de uso de UML Especifican cmo construir modelos bien formados (auto consistentes y en armona con otros modelos relacionados) Proporcionan reglas semnticas para: Nombres (a qu se puede llamar elementos, relaciones y diagramas) Alcance (contexto que da significado especfico a un nombre) Visibilidad (cmo los nombres pueden ser vistos y usados por otros) Integridad (cmo los elementos se relacionan entre s de forma consistente) Ejecucin (significado de simular o ejecutar un modelo dinmico) Puede ser necesario trabajar con modelos mal formados: Con omisiones (incluso intencionadamente, para simplificar las vistas) Incompletos (faltan an elementos, relaciones por identificar) Inconsistentes (no se garantiza la integridad del modelo)

12

Universidad Tecnolgica del Per - UTP

CAPITULO II
2.1 MODELADO DEL NEGOCIO El objetivo es comprender el conjunto de procesos de negocio que tienen lugar dentro de una empresa, como paso previo a establecer los requisitos del sistema a desarrollar. Una organizacin tiene una serie de objetivos que satisface a travs de Procesos de Negocio. Los elementos de un proceso de negocio son: Flujo de Tareas, Agentes/Roles, Informacin y Reglas Negocio. Las Reglas de Negocio regulan el funcionamiento de la empresa Describen restricciones y comportamientos. NO son requisitos, pero influyen en ellos.

Ejemplo

13

Universidad Tecnolgica del Per - UTP Etapas del modelado del negocio Identificar y definir los procesos de negocio segn los objetivos de la organizacin. Definir un caso de uso del negocio para cada proceso del negocio (diagrama de casos de uso del negocio muestra el contexto y los lmites de la organizacin). Identificar los roles implicados en los diferentes procesos del negocio (diagrama de roles) Modelar el flujo de tareas asociado a cada proceso de negocio mediante escenarios (diagramas de secuencia) y diagramas de procesos (diagramas de actividades) que muestran la interaccin entre roles para conseguir el objetivo. Especificar las informaciones y actividades incluidas en cada diagrama de actividades.

2.2 MODELADO DE REQUISITOS El propsito de este modelo es establecer los requisitos funcionales y no funcionales del sistema. Tipos de requisitos Funcionales.- Especifican los servicios que debe proporcionar la aplicacin No funcionales.- Estn vinculados a: Usabilidad Fiabilidad Rendimiento Adaptabilidad, Mantenimiento, Configurable Implementacin: lenguajes, herramientas,.. GUI Legales

Cmo podemos pasar del modelo de negocio al modelo de requisitos? Extraer los casos de uso del sistema a partir de las actividades que aparecen en los diagramas de actividades. Establecer el modelo conceptual a partir de las informaciones incluidas en los diagramas de actividades.

2.3 MODELADO DEL ANLISIS A partir de los casos de uso obtener el diseo preliminar del sistema que deber ser refinado en el modelo del diseo. Se tiene una visin ideal del sistema. Se define una arquitectura del sistema. Para cada caso de uso se define un diagrama de secuencia del sistema que muestra los eventos que un actor genera durante la interaccin con el sistema 14

Universidad Tecnolgica del Per - UTP (caja negra). Cada evento da origen a una operacin del sistema. El efecto de las operaciones se describe mediante contratos especificados mediante una plantilla (opcional). Para cada operacin del sistema se define una colaboracin (diagrama de interaccin) que muestra cmo deben colaborar los objetos para satisfacer la postcondicin expresada en el contrato de dicha operacin. Disear las colaboraciones, asignando responsabilidades a las clases. Crear el modelo de clases a partir del modelo conceptual, conforme se definen las colaboraciones El modelo de clases del anlisis se crea a partir del modelo conceptual. Se aade una clase por cada tipo de objeto del dominio que participa en la colaboracin. Se aaden atributos segn los contratos. Se aaden mtodos segn las colaboraciones. Para aquellas clases con objetos con comportamiento dependiente del estado, se construye una mquina de estados

2.4 MODELADO DEL DISEO El objetivo es Refinar el diseo del sistema del modelo del anlisis considerando los requisitos no funcionales y restricciones del entorno de implementacin. De manera iterativa se refina el modelo de clases y las colaboraciones del anlisis hasta obtener un diseo del sistema adecuado para pasar a la implementacin. Se debe: Identificar clases (atributos y mtodos) e interfaces en el modelo de clases del diseo Establecer asociaciones entre clases. Establecer navegabilidad para todas las asociaciones. Determinar visibilidad entre clases. Incluir relaciones de dependencia entre clases. Definir la arquitectura del sistema. Establecer los subsistemas: Paquetes. Identificar estructuras de datos. Disear las interfaces del usuario. Distribucin.

15

Universidad Tecnolgica del Per - UTP

CAPITULO III
3.1 ORGANIZANDO LOS ELEMENTOS EN PAQUETES Los distintos componentes pueden agruparse en paquetes segn un criterio lgico y con vistas a simplificar la implementacin. Son paquetes estereotipados en <<subsistemas>>. Los subsistemas organizan la vista de realizacin de un sistema Cada subsistema puede contener componentes y otros subsistemas La descomposicin en subsistemas no es necesariamente una descomposicin funcional Paquetes (Categoras) y clases en el nivel lgico. Paquetes (Subsistemas) y componentes en el nivel fsico Un paquete incluye un conjunto de elementos de cualquier naturaleza.

Ejemplo.- En este caso existen tres paquetes (que se muestran vacos en este caso, con su contenido encapsulado), con dos de ellos dependiendo del Modelo del Mundo.

3.2 CASO DE USO Un caso de uso especifica el comportamiento deseado del sistema. Representan los requisitos funcionales del sistema. Un caso de uso especifica una secuencia de acciones, incluyendo variantes, que el sistema puede ejecutar y que produce un resultado observable de valor para un particular actor Describe un conjunto de interacciones entre actores externos y el sistema en consideracin orientadas a satisfacer un objetivo de un actor. [D. Bredemeyer] Es una coleccin de posibles secuencias de interacciones entre el sistema en discusin y sus actores externos, relacionado con un objet ivo particular. [A. Cockburn] 16

Universidad Tecnolgica del Per - UTP Es una descripcin de un conjunto de secuencias de acciones, incluyendo variantes, que ejecuta un sistema para producir un resultado observable de valor para un actor [UML] Adems:

Describen qu hace el sistema, no cmo lo hace. Son tcnica de recoleccin y especificacin de requisitos. Fciles de comprender/validar por los usuarios. Guan todo el proceso de desarrollo. Ayudan a la planificacin/desarrollo incremental. Tradicionalmente ligados a la OO, pero no obligatorio Ayudan a determinar la interfaz de usuario.

Actor.- Un actor representa un conjunto coherente de roles que juegan los usuarios de los casos de uso al interaccionar con el sistema. Roles jugados por personas, dispositivos, u otros sistemas. No forman parte del sistema. Inician la ejecucin de los casos de uso. Un usuario puede jugar diferentes roles. En la realizacin de un caso de uso pueden intervenir diferentes actores. Un actor puede intervenir en varios casos de uso. Identificar casos de uso mediante actores y eventos externos. Un actor necesita el caso de uso y/o participa en l. Los actores solo se pueden conectar a los casos de uso a travs de asociaciones. Una asociacin entre actor y un caso indica que el actor y el caso de uso se comunican entre si, y cada uno puede enviar y recibir mensajes. A. Cockburn distingue dos tipos de actores: Primarios: Requieren al sistema el cumplimiento de un objetivo Secundarios: El sistema necesita de ellos para satisfacer un objetivo Es til encontrar primero los actores. Se puede diferenciar entre (Fowler): Objetivos del usuario: formatear un documento Interacciones del sistema: definir un estilo, mover un estilo a otro documento. Gua til: primero buscar los objetivos del usuario, y luego cubrir cada objetivo con interacciones del sistema. Propiedades de los casos de uso Son iniciados por un actor con un objetivo en mente y es completado con xito cuando el sistema lo satisface y si el caso de uso se inicia automticamente? Entonces el Actor sera el Sistema o Tiempo Puede incluir secuencias alternativas que llevan al xito y fracaso en la consecucin del objetivo. El sistema es considerado como una caja negra y las interacciones se perciben desde fuera. El conjunto completo de casos de uso especifica todas las posibles formas de usar el sistema, esto es el comportamiento requerido. 17

Universidad Tecnolgica del Per - UTP Cada caso de uso debe tener un nombre que lo distingue de otros casos de uso. Un nombre es una cadena de caracteres. En la practica, los nombres de los casos de uso, son expresiones verbales que describen algn comportamiento del vocabulario del sistema que se esta modelando. Puede tener cualquier nmero de letras, dgitos o signos de puntuacin.

Ejemplos

Efectuar Pedido

Validar usuario

Hacer pedido

Por qu casos de uso? Ofrecen un medio sistemtico e intuitivo para capturar los requisitos funcionales, centrndose en el valor aadido para el usuario Dirigen todo el proceso de desarrollo puesto que la mayora de actividades (planificacin, anlisis, diseo, validacin, test,..) se realizan a partir de los casos de uso. Mecanismo importante para soportar trazabilidad entre modelos. Crtica a los casos de uso (B.Meyer, E. Berard) Los casos de uso no son adecuados en el modelado orientado a objetos porque: i) Favorecen un enfoque funcional, basado en procesos ii) Se centran en secuencias de acciones iii) Se basan en los escenarios actuales del sistema Solo deben ser usados por equipos expertos en desarrollo OO. Utiles para validacin. Utilidad de los casos de uso Hay consenso en considerar casos de uso como esenciales para capturar requisitos y guiar el modelado. Pero existe mucha confusin sobre cmo usarlos. Diferentes opiniones sobre el nmero de casos de uso conveniente: 20 para un proyecto 10 personas/ao (Jacobson) 100 para un proyecto 10 personas/ao (Fowler) depende de la granularidad

18

Universidad Tecnolgica del Per - UTP Granularidad (M. Fowler) Diferente granularidad Un caso de uso puede describir: Un objetivo o propsito del usuario Una interaccin con el sistema Un objetivo implica una o ms interacciones. Primero construir un caso de uso por cada objetivo del usuario. Despus escribir casos de uso para cada interaccin que corresponda a un objetivo. Granularidad (A. Cockburn) Organizacin Objetivo estratgico para la empresa, de mucho valor Sistema (objetivo del usuario) Funcionalidad del sistema, tarea del usuario o proceso de negocio elemental Subfunciones Un paso en la descripcin de un caso de uso (validar, buscar, log on) Tipos de casos de uso (Larman) Descripcin breve, informal o completa Descripcin muy general o conversacin entre actor y sistema. Primarios, Secundarios u Opcionales Segn su importancia en el sistema Esenciales vs. Reales Segn su grado de abstraccin Un caso de uso real describe el proceso en trminos de su diseo actual, teniendo en cuenta tecnologa de E/S. Especificacin de requisitos La ERS (Especificacin de Requisitos del Software) puede estar formada por: Diagrama de casos de uso Modelo del dominio (modelo conceptual) (Para cada caso de uso) Descripcin textual (usando una plantilla) Descripciones de las interfaces de usuario Requisitos no funcionales Descripcin de un caso de uso En cada momento de la especificacin de caso de uso, una representacin (Larman): Descripcin breve (prrafo en lenguaje natural) Descripcin informal (prrafo en lenguaje natural para escenario principal y alternativo) Descripcin completa (plantilla) Describir el flujo de eventos Texto estructurado informal Texto estructurado formal (pre y postcondiciones) Notaciones grficas: Diagramas de Secuencia Debe ser legible y comprensible para un usuario no experto. 19

Universidad Tecnolgica del Per - UTP Debe indicarse: inicio y final, actores, objetos que fluyen, flujo principal y flujos excepcionales.

Ejemplo Comprar artculos (en un terminal de punto de venta)

Comprar artculos Flujo Principal: Un cliente llega al TPV con un conjunto de artculos. El Cajero registra los artculos y se genera un ticket. El cliente paga en efectivo y recoge los artculos. 1. El cliente llega al TPV con los artculos. 2. El cajero registra el identificador de cada artculo. 3. El sistema obtiene el precio de cada artculo y aade la informacin a la transaccin de venta. 4. Al acabar el cajero indica la finalizacin de la introduccin de artculos. 5. El sistema calcula el total de la compra y lo muestra. 6. El Cajero le dice al cliente el total. 7. El cliente realiza el pago. 8. El cajero registra la cantidad de dinero recibida. 9. El sistema muestra la cantidad a retornar al cliente y genera un recibo. 10. El cajero deposita el dinero recibido y saca la cantidad a devolver que entrega al cliente junto al ticket de compra. 11. El sistema almacena la compra completada. 12. El cliente recoge los artculos comprados.

Ejemplo Validar Usuario (contexto de un cajero automtico)

Validar Usuario Flujo Principal: El sistema pide la Clave. El cliente lo introduce a travs del teclado y pulsa Enter. El sistema comprueba la validez de la Clave. Si es vlido el sistema acepta la entrada y finaliza el caso de uso.

Flujo Excepcional: El cliente puede cancelar la transaccin en cualquier momento, pulsando el botn Cancelar, reiniciando el caso de uso.

20

Universidad Tecnolgica del Per - UTP Flujo Excepcional: Si la Clave introducida es invlida entonces se reinicia el caso de uso. Si esto ocurre tres veces, el sistema cancela la transaccin completa y se queda con la tarjeta.

Ejemplo Prestar libro (contexto de una biblioteca)

Prestar Libro Nombre del caso de uso: Prestar Libro Propsito: Hacer posible el prstamo de libros a los usuarios Actor(es):. Resumen:. Precondiciones:. Postcondiciones:

21

Universidad Tecnolgica del Per - UTP Tambin se puede utilizar la siguiente plantilla para la descripcin de un caso de uso
R F - < id d el re qu isito > V e rsi n A u tores F u en tes O b jetivo s aso ciado s D esc rip ci n < n o m bre d el req uisito fu n cio n al > < num ero de versin y fecha> < autor> < fuente de la versi n actual> < nom bre del o bjetivo> E l sistem a deber com p ortarse tal com o se describ e en el siguiente caso de uso { concreto cuan do < eve nto de activacin> , a bstracto durante la realizacin d e lo s caso s de uso <lista de ca sos de uso> } < pre con dicin del caso de uso> P a so A ccin 1 {E l <actor> , E l sistem a} < a ccin realizada po r el actor o sistem a>, se rea liza e l caso de uso < caso d e uso R F -x> 2 S i < cond icin> , {el <actor> , el sistem a} < accin realizada po r el actor o sistem a> >, se realiza el caso de uso < caso de uso R F -x> 3 4 5 6 n < postcon dicin del caso de uso> P a so A ccin 1 S i < cond icin de exce pcin> ,{el < actor> , el sistem a} }< acci n realiza da por e l actor o sistem a> > , se re aliza el caso de uso < caso d e uso R F -x>, a co ntinu acin este caso de uso {continu a, a borta} 2 3 P a so C o ta d e tiem p o 1 n segun dos 2 n segun dos < n de veces> veces / <u nida d de tiem p o> {sin im portancia , im portante , vital} {puede esperar, hay presin, inm ediatam e nte} < com entarios a dicion ales>

P reco n dici n S e cu en cia N o rm al

P o stco n d ici n E x cep cio n es

R en d im ien to

F rec uen cia esp erad a Im p o rtan cia U rg en cia C o m en tario s

3.3 DIAGRAMA DE CASOS DE USO Un diagrama de Casos de Uso muestra las distintas operaciones que se esperan de una aplicacin o sistema y cmo se relaciona con su entorno (usuarios u otras aplicaciones).

Ejemplo

22

Universidad Tecnolgica del Per - UTP Ejemplo

Ejemplo

23

Universidad Tecnolgica del Per - UTP Casos de uso y Colaboraciones Con un caso de uso se describe un comportamiento esperado del sistema, pero no se especifica cmo se implementa. Un caso de uso se implementa a travs de una colaboracin: Sociedad de clases y otros elementos que colaborarn para realizar el comportamiento expresado en un caso de uso. Una colaboracin tiene una parte esttica (diagramas de clases) y una parte dinmica (diagramas de secuencia).

Ejemplo

El objetivo de la arquitectura del sistema es encontrar el conjunto mnimo de colaboraciones bien estructuradas, que satisfacen el comportamiento especificado en todos los casos de uso del sistema Organizacin de los casos de uso Los casos de usos se pueden organizar agrupndolos en paquetes, de la misma manera que se organizan las clases. Tres tipos de relaciones: Generalizacin Un caso de uso hereda el comportamiento y significado de otro Inclusin Un caso de uso base incorpora explcitamente el comportamiento de otro en algn lugar de su secuencia. Extensin Un caso de uso base incorpora implcitamente el comportamiento de otro caso de uso en el lugar especificado indirectamente por este otro caso de uso.

24

Universidad Tecnolgica del Per - UTP Ejemplo

En el ejemplo se puede observar que: La relacin de inclusin permite factorizar un comportamiento en un caso de uso aparte y evitar repetir un mismo flujo en diferentes casos de uso. Ejemplo caso de uso Seguir Pedido: 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. La relacin de extensin en el caso de uso base incluye una serie de puntos de extensin. Sirve para modelar: la parte opcional del sistema un subflujo que slo se ejecuta bajo ciertas condiciones varios flujos que se pueden insertar en un punto Ejemplo caso de uso Hacer Pedido: Include (Validar usuario). Recoger los items del pedido del usuario. (establecer prioridad). Enviar pedido para ser procesado. Ejemplo Modelando el comportamiento de un elemento para un sistema de venta
Facturar al Cliente

Hacer pedido <<include>>

Seguir pedido <<include>>

Validar cliente

<<Include>> Enviar pedido Punto de extensin: Materiales preparados <<extend>>

Enviar Pedido parcial

Materiales preparados

25

Universidad Tecnolgica del Per - UTP Ejemplo

Ejemplo
Sistema de validacin de tarjetas de crdito

Realizar transacciones con Tarjetas con tarjeta Procesar Factura cliente

cliente individual

Comercio

Ajustar transacciones

cliente
Gestionar cuenta corriente

Entidad financiera

cliente corporativo

Modelado del contexto de un sistema

Recomendaciones (E. Berard) Un caso de uso no debe considerar cuestiones de implementacin. Conveniencia de una herramienta para la gestin de los casos de uso. Encontrar contradicciones entre casos de uso. Preocupacin por mantener la validez y consistencia del conjunto de casos de uso. Cmo se comprueba que los casos de uso incluyen toda la funcionalidad del sistema? 26

Universidad Tecnolgica del Per - UTP Cada compaa debe tener un manual sobre uso de los casos de uso. A qu nivel de detalle se describe un caso de uso? Qu granularidad es apropiada para un caso de uso? Pinchar botn, Aadir Empleado,.. son casos de uso? Recomendaciones (M. Fowler) Cuidado con el empleo de la relacin uses NO HAGAS UNA DESCOMPOSICION FUNCIONAL! No abusar de la estructuracin de casos de uso No es necesario aplicar la abstraccin USA CASOS DE USO CONCRETOS! Recomendaciones (A. Pols) Primero establecer los objetivos del proyecto. Despus identificar actores y sus responsabilidades, y las tareas que ejecutan son los casos de uso. Contrastar casos de uso frente a los objetivos. Cuidado con la ambigedad No profundizar en la descripcin de un caso de uso No te preocupes en exceso de la notacin Evita redes complicadas de casos de uso: Cuidado con las relaciones include y extend. No considerar la interfaz del usuario Los casos de uso slo consideran los requisitos funcionales del proyecto, hay que aadir los no funcionales.

27

Universidad Tecnolgica del Per - UTP

CAPITULO IV
4.1 DIAGRAMAS DE INTERACCIN Los diagramas de interaccin (los diagramas de secuencias y colaboracin) son dos de los cinco tipos de diagramas UML que se usan para modelar los aspectos dinmicos de los sistemas. Un diagrama de interaccin muestra la interaccin, que incluye un conjunto de objetos y sus relaciones y los mensajes que se pueden enviar entre ellos. Un diagrama de secuencia es un diagrama que destaca la ordenacin temporal de los mensajes. Un diagrama de colaboracin es un diagrama que destaca la organizacin estructural de los objetos que envan y reciben mensajes. Los diagramas de interaccin se usan para modelar los aspectos dinmicos de un sistema. Se utilizan para visualizar, especificar, construir y documentaran la dinmica de una sociedad particular de objetos o para modelar un flujo de control particular de un caso de uso. Normalmente, los diagramas de interaccin contienen: objetos, enlaces y mensajes. Al igual que otros diagramas pueden contener notas y restricciones.

4.1.1 Diagrama de secuencia. El diagrama de secuencia destaca la ordenacin temporal de los mensajes. Un diagrama se secuencia se forma colocando inicialmente los objetos que participan en la interacciones en la parte superior del diagrama (a lo largo del eje X). Normalmente, se coloca a la izquierda el objeto que inicia la interaccin y los objetos subordinados a la derecha. A continuacin se colocan los mensajes que estos envan y reciben (a lo largo del eje Y) en orden de sucesin en el tiempo desde arriba hasta abajo. Los diagramas de secuencia tienen dos caractersticas que los distinguen de los diagramas de colaboracin: a. La lnea de vida de un objeto es la lnea discontinua vertical que representa la existencia del objeto a lo largo del tiempo. La mayora de los objetos que aparecen en el diagrama de interaccin existirn mientras dure la a interaccin, as que los objetos se ubican en la parte superior del diagrama, con su lneas de vidas dibujadas desde arriba hacia abajo. Durante una interaccin se pueden crear objetos, tambin pueden destruirse (mensaje destroy y una X que marca el final de su vida). b. El foco de control es un rectngulo delgado y estrecho que representan el periodo del tiempo durante el cual un objeto ejecuta una accin, bien sea directamente o a travs de un procedimiento subordinando. La parte superior 28

Universidad Tecnolgica del Per - UTP del rectngulo se alinea con el comienzo de la accin; la inferior con su terminacin (pudiendo marcarse con un mensaje de retorno). En un diagrama de secuencia se muestra explcitamente la lnea de vida de un objeto, lo cual no ocurre en un diagrama de colaboracin.

Ejemplo Diagrama de secuencia de Comprar Artculos

Algunas consideraciones Un objeto puede enviarse a s mismo un mensaje:

a

m e ns a j e

r ef l e x iv o

Normalmente no es necesario indicar el retorno del control:

a b

E l re t o rn o s e c o n s id e ra im p lc it o c u a n d o e l e n vo e s s n c ro n o

29

Universidad Tecnolgica del Per - UTP En el caso asncrono el retorno, si existe, se debe representar:
a : aa b : aa

El Diagrama de Secuencia refleja de manera indirecta las opciones de control. Un control centralizado tiene una forma como esta:

Un control descentralizado tiene una forma como esta:

Podemos representar iteraciones en el envo de mensajes, p.e., mientras se cumpla una condicin:

W h ile X Loop end Loop

30

Universidad Tecnolgica del Per - UTP La iteracin puede expresarse tambin como parte del mensaje:
* [ c o n d ic i n ] M e n s a je

Las bifurcaciones condicionales pueden representarse de esta forma:

If c o n d ic i n e ls e e n d if

Ejemplo Diagrama de secuencia de prstamo de libro

Socio

Encargado Coger libro

Libro

Ficha socio

Ficha libro

Prstamo

Solicitar prstamo Verificar situacin socio Situacin socio ok Verificar situacin libro Situacin libro ok Introducir prstamo Autorizar prstamo

31

Universidad Tecnolgica del Per - UTP Ejemplo Diagrama de secuencia de efectuar llamada

Ejemplo Diagrama de secuencia de Realizar Compra

32

Universidad Tecnolgica del Per - UTP Ejemplo Diagrama de secuencia identificando la responsabilidad de cada clase

4.1.2 Diagrama de colaboracin. Un diagrama de colaboracin destaca la organizacin de los objetos que participan en una interaccin. Un diagrama de colaboracin se construye colocando primero los objetos que participan en la colaboracin, como nodos del grafo, Luego, se presentan los enlaces que conectan esos objetos como arcos del grado. Por ultimo, estos enlaces se adornan con los mensajes que envan y reciben los objetos. Este diagrama permite visualizar el flujo de control en el contexto de la organizacin estructural de los objetos que colaboran. Los diagramas de colaboracin tienen dos caractersticas que los distinguen de los diagramas de secuencia: a. El camino. Para indicar como se enlaza un objeto a otro, se puede asociar un estereotipo de camino al extrema ms lejano de un enlace (como <<local>> que indica que el objeto designado es local al emisor) Normalmente, solo se necesita representar explcitamente el camino del enlace para los camino local, parameter, global y self (pero no en association). b. El nmero de secuencia. Para indicar la ordenacin temporal de un mensaje, se precede de un nmero (iniciando con el numero ), que se incrementa secuencialmente por cada nuevo mensaje en el flujo de control (2, 3, etc.). Para representar anidamiento se usa la numeracin Dewey (1 es el primer mensaje, 1.1 es el primer mensaje dentro del mensaje 1, 1.2 es el segundo mensaje dentro del mensaje 1, etc.).

33

Universidad Tecnolgica del Per - UTP La mayora de las veces se modelar flujos de controles simples y secuenciales. Sin embargo, tambin se pueden modelar flujos ms complejos, que impliquen iteracin y bifurcacin. Una iteracin representa una secuencia repetida de mensajes. Una condicin representa un mensaje cuya ejecucin depende de la evaluacin de una expresin booleana. Tanto en la iteracin como en el bifurcacin, UML permite el uso del pseudocdigo o la sintaxis de un lenguaje de programacin especifico. Los diagramas secuencia y colaboracin son semnticamente equivalentes. Aunque debe tenerse en cuanta que los diagramas de colaboracin muestran como se enlazan los objetos, mientras el diagrama de secuencia no lo muestra. Un mensaje desencadena una accin en el objeto destinatario. Un mensaje se enva si han sido enviados los mensajes de una lista (sincronizacin):

A.1, B.3 / 1:Mensaje

Un mensaje se enva iterada y secuencialmente a un conjunto de instancias:

1 *[i:=1..n] : Mensaje B A

Un mensaje se enva iterada y concurrentemente a un conjunto de instancias:

1 *| | [i:=1..n] : Mensaje B A

34

Universidad Tecnolgica del Per - UTP Un mensaje se enva de manera condicionada:

[x>y] 1: Mensaje B A

Un mensaje que devuelve un resultado:

1: distancia:= mover(x,y) B A

Los argumentos de un mensaje pueden ser valores obtenidos como consecuencia de las llamadas anteriores. Los argumentos pueden ser tambin expresiones de navegacin construidas a partir del objeto cliente. Los argumentos pueden omitirse en el diagrama.

35

Universidad Tecnolgica del Per - UTP Ejemplo Diagrama de colaboracin de prstamo de libro

1: Coger libro : Libro

: Socio

2: Solicitar prstamo 3: Verificar situacin socio

: Ficha socio

8: Autorizar prstamo 4: Situacin socio ok

6: Situacin libro ok

: Encargado 7: Introducir prstamo : Prstamo

5: Verificar situacin libro : Ficha libro

36

Universidad Tecnolgica del Per - UTP

CAPITULO V
5.1 DIAGRAMA DE OBJETOS Los diagramas de objetos modelan las instancias de los elementos contenidos en los diagramas en los diagramas de clase y muestran un conjunto de objetos y sus relaciones en un momento concreto. Los diagramas de objetos se utilizan para modelar la vista de diseo esttica o la vista de procesos esttica de un sistema. Los diagramas de objetos normalmente contienen: objetos y enlaces (puede contener notas y restricciones). Tambin pueden contener paquetes o subsistemas, los que se usan para agrupar los elementos de un modelo en partes ms grandes. Un diagrama de objetos es esencialmente un diagrama de clases o la parte esttica de un diagrama de interaccin. Ejemplo

Compaa : C
enlace

Departamento : d2 Departamento : d1
Nombre D=ventas NombreD= I+D

objeto

Departamento : d3
Nombre D=ventasexterior

objeto annimo

Persona : per Nombre =Francisco IdEmpleado = 4578 Cargo =Gerente Ventas ...

Valor de atributo

InfoDeContacto :
Direccin =Bosques del Sur

37

Universidad Tecnolgica del Per - UTP

5.2 CLASES Las clases son los bloques de construccin mas importantes de cualquier sistema orientado a objetos. Una clase describe un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semntica. Una clave implementa una o ms interfaces. Las clases capturan el vocabulario del sistema que se esta desarrollando. Puede incluir abstracciones que formen parte del dominio del problema o clases que constituyan una implementacin. Pueden usarse para representar cosas que sean software, hardware o solo conceptuales. En UML todas las cosas se modelan con clases. Una clave no es un objeto individual, sino que representa un conjunto de objetos. Se representa por un rectngulo con tres divisiones internas (ver figura), son los elementos fundamentales del diagrama: su nombre, sus atributos y sus operaciones.
Rectngulo
Atributos float altura; float base; aadir ( ); ampliar ( ); mover ( ); estaVaco ( ); Nombre

Operaciones

Nombre

Cada clase ha de tener un nombre que la distinga de otra clases. Un nombre es una cadena de texto. Tambin se puede dibujar mostrando solo su nombre. Un nombre solo se denomina nombre simple; un nombre de camino consta de la clase precedido por el nombre del paquete en el que se encuentra.

ReglasDelNegocio :: AgenteFraudes

Cliente Empleado
Nombres simples Nombre de camino

38

Universidad Tecnolgica del Per - UTP Atributos

Un atributo es una propiedad de una clase identificada con un nombre, que describe un rango de valores que pueden tomar las instancias de la propiedad. Una clase puede tener cualquier nmero de atributos o no tener ninguno. Un atributo representa alguna propiedad del elemento que se esta modelando, que es compartida por todos los objetos de esa clase. Ejemplo: todo rectngulo tiene altura y base. Un atributo es una abstraccin de un tipo de datos o estado que puede incluir un objeto de la clase. En un momento dado, un objeto tendr valores especficos para cada uno de los atributos de la clase. Se ubican en el compartimiento que se encuentra debajo del nombre de la clase. [visibilidad] nombre [: tipo] [= valor_inicial ] Visibilidad + = pblica # = protegida - = privada nombre: nombre del atributo tipo: tipo del atributo valor_inicial: valor inicial o por defecto Ejemplo
Pedido
int articulo; int cantidad = 0; boolean seentrego = false;

Adems:

Nivel Conceptual: Los clientes tienen un nombre Nivel de Especificacin: El cliente puede almacenar y consultar su nombre Nivel de Implementacin: Cliente tiene un campo de tipo string que almacena su nombre y un mtodo que lo devuelve

39

Universidad Tecnolgica del Per - UTP Operaciones

Una operacin es la implementacin de un servicio que puede ser requerido a cualquier objeto de la clase para que muestre un comportamiento. Una operacin es una abstraccin de algo que se puede hacer a un objeto y que es compartido por todos los objetos de la clase. Una clase puede tener cualquier nmero de operaciones o ninguna. Grficamente, las operaciones se listan en un compartimiento debajo de los atributos de la clase. Se puede representar mostrando slo sus nombres.

Ejemplo
Rectngulo

aadir ( ), ampliar ( ); mover ( ); esta Vaco ( );

[visibilidad] nombre [(lista_parametros)] [: tipo_retorno] Visibilidad + = pblica # = protegida - = privada nombre: nombre de la operacin lista_parmetros: lista de parmetros separados por comas tipo retorno: tipo de valor devuelto por la operacin Ejemplo

Nivel Conceptual Responsabilidades de la clase 40

Universidad Tecnolgica del Per - UTP Tarjetas CRC: Descripcin de alto nivel del propsito de la clase Nivel Especificacin Protocolo de la clase (operaciones pblicas) Nivel Implementacin Conjunto de mtodos de la clase

Responsabilidades Una responsabilidad es un contrato u obligacin de una clase. Al crear una clase, se esta expresando que todos los objetos de esa clase tiene el mismo tipo de estado y el mismo tipo de comportamiento. En forma abstracta, los atributos y las operaciones son caractersticas por medio de los cuales se llevan a cabo las responsabilidades de la clase. Una clase AgenteFraudes puede ubicarse en una aplicacin de tarjetas de crdito, y se responsabiliza de procesar pedidos y determinar si son sospechosos, fraudulentos o legales. Una clase puede tener cualquier numero de responsabilidades, aunque una clase bien construida tendr al menos una responsabilidad y a lo sumo unas pocas. El refinamiento de la clase, traduce esas responsabilidades en un conjunto de atributos y operaciones que mejor satisfagan las responsabilidades definidas para esa clase. Grficamente se pueden ubicar en un comportamiento separado al final de la clase, y son texto libre escrito como una frase.

Agente Fraudes

Responsabilidades
-- determinar el riesgo de un pedido de cliente. -- manejar criterios de fraude especficos del cliente responsabilidades

Al modelar clases en UML hay que recordar que cada clase debe corresponderse con una abstraccin tangible a conceptual en el dominio del problema. Un clase bien estructurada: Debe proporcionar una abstraccin precisa de algo extrado del vocabulario del dominio del problema. Contiene un grupo de responsabilidades bien definidos, y los lleva a cabo en buena forma. Permite distinguir entre la especificacin de la abstraccin y su implementacin. Es compresible y sencilla, a la vez que extensible y adaptable.

41

Universidad Tecnolgica del Per - UTP RELACIONES En el proceso de abstraccin se concluye que pocas clases se hallan aisladas. En el modelado orientado a objetos, hay tres tipos de relaciones importantes: dependencias, que representan relaciones de uso entre clases; generalizaciones, que conectan clases generales con sus especializaciones; y asociaciones que representan relaciones estructurales entre objetos. Una Relacin es una conexin entre elementos. Grficamente se representa como una lnea, usando diferentes tipos de lnea para diferenciar los diferentes tipos de relacin. Una Dependencia es una relacin de uso que declara que un cambio en la especificacin de un elemento puede afectar a otro elemento que le utiliza, pero no necesariamente a la inversa. Se representa como una lnea discontinua dirigida hacia el elemento del cual depende. Se usa cuando se quiere indicar de un elemento utiliza a otro. La mayora de las veces, la dependencia se usan en el contexto de los clases, para indicar que una clase utiliza a otro como argumento en la signatura de una operacin. Ejemplo

Una dependencia puede tener un nombre, aunque es raro que se usen, a menos que se tenga el caso de muchas dependencias y cada una daba distinguirse.

La Generalizacin es una relacin entre un elemento general (llamado superclase o padre) y un caso mas especifico de ese elemento (llamado subclase o hijo), la generalizacin tambin se denomina como una relacin es-un-tipo-de. La generalizacin significa que los objetos hijo se pueden emplear en cualquier lugar que pueda aparecer el padre, pero no a la inversa. Una clase hija hereda las propiedades de sus clases padres (atributos y operaciones). En ocasiones, el hijo aade atributos y operaciones a las que hereda de sus padres. En ocasiones, el hijo redefine operaciones (con el mismo nombre) definidas por la clase padre (esto 42

Universidad Tecnolgica del Per - UTP se denomina polimorfismo). Se representa como una lnea dirigida continua, con una gran parte de flecha vaca (pequeo tringulo) que apunta a la superclase. Una clase puede no tener clase padre. Si tiene uno o ms hijos se denominan clase base. Una clase sin hijos se llama clase hoja. Una clase con un nico padre se dice que es una herencia simple; si tiene ms de una clase padre, utiliza herencia mltiple. Ejemplo de generalizacin y especializacin de clases (en el contexto de figuras geomtricas)

Figura
origen mover ( ) cambiarTamao ( ) dibujar Clase padre o superclase (base) generalizacin

Rectngulo
punto esquina float radio

Circulo
dibujar

Polgono
lista : puntos

cuadrado

Clase hoja

Clase hija

Ejemplo Generalizacin y especializacin de clases

A b s tra c c i o ne s m s g e ne ra le s . ve hi c ulo

ve hi c ulo te rre s tre

v ehi c ul o a r eo

c a m io n

c o c he

a vi o n

he li c o p te ro

43

Universidad Tecnolgica del Per - UTP

La especializacin es una tcnica muy eficaz para la extensin y reutilizacin

c o c he

func i o na nd o

e s tro p ea do

Particionamiento del espacio de objetos => Especializacin Esttica

ve h i c u lo a r e o

a vi o n

h e li c o p te r o

Particionamiento del espacio de estados de los objetos => Especializacin Dinmica

c o c he

fu n c i o n a n d o

e s tr o p e a d o

44

Universidad Tecnolgica del Per - UTP En la Especializacin Esttica, el objeto es instancia de la subclase desde su creacin y la superclase en las que fue creado. Esta pertenencia es inmutable. Puede haber ms de una especializacin esttica o dinmica a partir de la misma superclase
c o m e rc i al v ehi c ul o a r eo

m i li ta r a vi o n he li c o p te ro

En la Especializacin Dinmica un objeto puede migrar durante su vida entre las distintas subclases de la especializacin. La migracin puede definirse en funcin de su estado o de los eventos que le acontezcan.

d e m e n o s de 1 0 0 0 km s c oc he

d e m s d e 1 0 0 0 km s fu n c i o n an d o e s tro p e a d o

45

Universidad Tecnolgica del Per - UTP Uso disciplinado de la herencia mltiple

conejo con pelo Herbvoro con plumas omnvoro Animal con escamas carnvoro Bipedo Cuadrpedo

La herencia no es una necesidad absoluta y siempre puede sustituirse por delegacin. Disminuye el acoplamiento: el cliente no conoce directamente al proveedor y el proveedor puede ser modificado sobre la marcha Permite implementar herencia mltiple en lenguajes con herencia simple.

Animal

x Locomocin

x Alimento

Bpedo

Cuadrpedo

Herbvoro

Carnvoro

46

Universidad Tecnolgica del Per - UTP Una Asociacin es una relacin estructural que especifica que los objetos de un elemento estn conectados con los objetos de otro. La asociacin entre dos clases permite navegar desde un objeto de una clase hasta un objeto de la otra clase y viceversa. Una asociacin que conecta exactamente 2 clases se dice binaria. Se puede tener asociaciones que conectan ms de dos clases, se llaman n-arias. Se usan cuando se quiere representar relaciones estructurales. Hay cuatro adornos que se aplican: Nombre. Una asociacin puede tener nombre, que se usa para descubrir la naturaleza de la relacin.
nombre Trabaja para Persona asociacin Empresa

Rol. Cuando una clase participa en una asociacin, tiene un rol especifico que juega en la asociacin; un rol puede verse como la cara que la clase de un extremo de la asociacin presenta a la clase del otro extremo. En la figura, una Persona que juega el rol de empleado esta asociado con una Empresa que juega el rol de patrn.
asociacin

Persona

empleado rol

patrn

Empresa

Una asociacin puede tener un nombre. Si se incluyen explcitamente los nombres de rol para la asociacin, no se necesita incluir el nombre de la asociacin, excepto si se tiene un modelo con muchas asociaciones y se hace necesario distinguir una de otra (en especial si hay ms de una asociacin entre las mismas clases). Multiplicidad. En muchas ocasiones es importante indicar cuantos objetos pueden conectarse a travs de una instancia de la asociacin; a esto se denomina multiplicidad de la asociacin. Se escribe como una expresin que se evala a un rango de valores o a un valor explcito. Cuando se indica la multiplicidad se esta especificando que para cada objeto de la clase en el extremo opuesto debe haber tantos objetos en este extremo. Se pueden indicar multiplicidades como: exactamente uno ( 1 ), cero o uno ( 0..1 ), cero o muchos (0..*), uno o mas ( 1..* ), o incluso indicar el nmero exacto.
multiplicidad

1..* Persona empleado

0..* patrn Empresa

47

Universidad Tecnolgica del Per - UTP Agregacin Una asociacin representa una relacin estructural entre iguales, es decir que ambas clases se encuentran conceptualmente al mismo nivel (no hay una parte mas importante). A veces se desea modelar una relacin todo/parte, en la cual una clase representa una cosa grande (el todo), que esta conformado por elementos pequeos (las partes). Este tipo de relacin se denomina agregacin y se representa una relacin del tipo tiene-un. Se representa aadiendo a una asociacin normal un rombo vaco en la parte del todo.
Empresa
agregacin parte todo

Departamento

Composicin Es un caso particular de agregacin: exclusiva y dependiente. Las partes pueden crearse despus del agregado compuesta al que pertenecen, pero una vez creadas viven y mueren con ella. La parte slo puede formar parte de un agregado. El agregado gestiona la creacin y destruccin de las partes. Las partes se pueden eliminar antes de eliminar el agregado.

5.3 DIAGRAMAS DE CLASES Un diagrama de clases muestra un conjunto de clases, interfaces y colaboraciones, as como sus relaciones. Se usan para modelar la vista esttica (estructura esttica) de un sistema. Son los ms utilizados en el modelado de un sistema orientado a objetos. Un diagrama de estructura esttica muestras un conjunto de clases y objetos importantes que hacen parte de un sistema, junto con los relaciones existentes entre estas clases y objetos. 48

Universidad Tecnolgica del Per - UTP Trminos y conceptos Un diagrama de clases es un diagrama que muestra un conjunto de nodos (clases, colaboraciones o interfaces) y arcos (relaciones). Un diagrama de clases contiene normalmente los siguientes elementos: Clases Interfaces Colaboraciones Relaciones de dependencias, generalizacin y asociacin. Usos Los diagramas de clase se utilizan para modelar la estructura esttica del sistema. Es la vista que soporta los requisitos funcionales de un sistema, los servicios que se proporciona a los usuarios finales. Los diagramas de clases se utilizan en una de las siguientes formas: 1. Para modelar las colaboraciones simples 2. Para modelar un esquema lgico de base de datos. Modelado de colaboraciones simples Ninguna clase se encuentra aislada, cada una trabaja en colaboracin con otras para llevar a cabo una semntica mayor que la asociada cada clase individual. Cuando se crea un diagrama de clase, se esta modelando una parte de los elementos y relaciones que configuran la vista de diseo del sistema. Por ello, cada diagrama de clases debe centrase en una colaboracin cada vez. Para modelar una colaboracin: Hay que identificar los mecanismos que se quieren modelar. Un mecanismo representa una funcin o comportamiento de la parte del sistema que se esta modelando que resulta de la interaccin de una sociedad de clases, interfaces y otros elementos. Para cada mecanismo, hay que identificar las clase, interfaces y otras colaboraciones que participan en la colaboracin que se esta modelando. Tambin se debe identificar las relaciones entre esos elementos. Hay que usar escenarios para recorrer la interaccin entre esos elementos. Durante su recorrido se descubrirn partes faltantes y errores semnticos. Debemos asegurarnos de rellenar estos elementos con su conteniendo. Para las clases, hay que comenzar obteniendo un reparto equilibrado de responsabilidades, Despus, con el tiempo, stas se deben convertir atributos y operaciones concretas. En la figura se representa un conjunto de clases extradas de la implementacin de un robot autnomo, la cual se centra en las clases implicadas en el mecanismo para mover el robot a travs de una trayectoria. Hay una clase abstracta (Motor) con dos hijos (Motor Direcciones y Motor Principal), las cuales se muestran como partes de otra clase (Conductor). La clase AgenteTrayectoria tiene asociacin uno a muchos con Conductor y una asociacin uno a muchos con SensorColisin. No se muestra atributos mi operaciones para Agentetrayectoria, aunque si se indica las responsabilidades. 49

Universidad Tecnolgica del Per - UTP Si cada una de estas colaboraciones es traslada en un diagrama diferente, se proporciona una vista comprensible del sistema desde diferentes perspectivas.

Trayectoria 1 Conductor
Responsabilidades: --buscar camino --evitar obstculos 1 1

SensorColisin

Motor Direccin

Motor Principal

Motor

mover (Direccin d, Velocidad v) parar ( ) reiniciarContador ( ) statusMotor ( ) int distancia ( )

Modelado de un esquema lgico de la base de datos Muchos de los sistemas que se modelan tendrn objetos persistentes, lo que significa que estos objetos podrn ser almacenados en una base de datos con el fin de poderlos recuperar posteriormente. La mayora de las veces se emplear una base de datos relacional, una base de datos orientada a objetos o una base de datos hbrida objeto-relacional para el almacenamiento persistente. UML permite modelar esquemas lgicos de base de datos, as como bases de datos fsicas. Los diagramas UML son un superconjunto de los diagramas Entidad-Relacin (E-R), herramientas de uso frecuente. Los diagramas E-R se centran en los datos, los diagramas de clase permiten, adems, modelar el comportamiento. En la base de datos fsica, estas operaciones lgicas normalmente se convierten en disparadores (triggers) o procedimientos almacenados. Para modelar un esquema: Debemos identificar aquellas clases del modelo cuyo estado debe trascender el tiempo de vida de las aplicaciones.

50

Universidad Tecnolgica del Per - UTP Hay que crear un diagrama de clases que contenga estas clases y marcarlas como persistentes (un valor etiquetado estndar). Hay que expandir los detalles estructurales de estas clases. Esto significa especificar los detalles de estos atributos y definir las asociaciones que se presentan, asi como sus cardinalidades. Hay que buscar patrones comunes que complican el diseo fsico, como el caso de asociaciones cclicas, asociaciones uno a uno y asociaciones n-arias. Donde deben crearse abstracciones intermedias para simplificar la estructura lgica. Hay que revisar el comportamiento de las clases persistentes expandiendo las operaciones que sean importantes para el acceso a los datos y la integridad de los datos. Se puede emplear la encapsulacin para trabajar las reglas del negocio que manipulan conjuntos de objetos. Donde sea posible, se debe utilizar herramientas que ayuden a transformar un diseo lgico en un diseo fsico.

El diseo lgico de base de datos escapa al alcance de este curso. Aqu solo se pretende mostrar como se puede modelar un esquema usando UML. Veamos el siguiente ejemplo:

Universidad
Nombre: nombre M String: direccin Long: telfono

(persistente) tiene

Departamento (persistente)
1 Nombre: nombreD 1 1..* adicinProfesor ( ) retirarProfesor ( ) obtenerProfesor ( ) listarTodosProfesores ( ) 0..1

adicionarEstudiante ( ) quitarEstudiante ( ) obtenerEstudiante ( ) listarTodosEstudiantes ( ) adicionarDepartamento quitarDepartamento ( ) obtenerEstudiante ( ) listarTodosDepartamentos ( )

asignado dirige

1..*

0..1

1..*
(persistente)

Estudiante (persistente)
Miembro * Nombre: nombreE String: codEstudiante * * asiste

Curso

(persistente) * 1..* ensea

Profesor

Nombre: nombreC Long: idMateria

Nombre: nombreP

51

Universidad Tecnolgica del Per - UTP Asociaciones calificadas

Nivel Conceptual: Dentro del mismo pedido no pueden existir dos lneas con el mismo producto Nivel Especificacin: El acceso a lineaPedido es indexado por productos Nivel Implementacin: Se usa una tabla para almacenar las lneas de pedido

Ejemplo

Asociaciones n-arias Asociacin entre tres o ms clases. Cada instancia de la asociacin es una ntupla de valores de cada una de las respectivas clases.

52

Universidad Tecnolgica del Per - UTP Ejemplo de diagrama de clase

Los Diagramas de Clases y los Diagramas de Objetos pertenecen a dos vistas complementarias del modelo. Un Diagrama de Clases muestra la abstraccin de una parte del dominio. Un Diagrama de Objetos representa una situacin concreta del dominio. Cada objeto es instancia de una clase. Ciertas clases (clases abstractas o diferidas) no pueden ser instanciadas.

53

Universidad Tecnolgica del Per - UTP Ejercicio prctico En una entidad educativa cuando se desea determinar la evaluacin de los alumnos, la secretaria debe considerar: Datos de los alumnos (cdigo y nombre) Datos de las evaluaciones que han obtenido en los cursos (cdigo del curso, cinco notas de prctica, una nota del examen parcial, una nota del examen final y una nota del examen sustitutorio) El promedio de practicas se determinar con las cuatro mayores notas de las prcticas El promedio final se determinar considerando la nota del examen parcial, nota del examen final y el promedio de prctica La condicin ser aprobado si el promedio final es mayor o igual a 10.5, en otro caso la condicin ser desaprobado Si el alumno esta desaprobado la nota del examen sustitutorio reemplaza a la nota ms baja entre el examen parcial y el examen final, seguidamente se vuelve a determinar el promedio final y su condicin Se pide desarrollar una aplicacin que permita determinar y mostrar el promedio final y condicin de los alumnos. Usted debe considerar los conocimientos aprendidos para disear dicha aplicacin.

Descripcin del caso de uso Nombre: Calculo del promedio final y condicin de los alumnos Propsito: Conocer el promedio final y condicin de los alumnos Actores: Alumno, Secretaria Resumen: Aceptar los datos de los alumnos que son necesarios para determinar el promedio final y la condicin. El promedio de las prcticas son con las cuatro notas mayores de las prcticas. En el promedio final se considera la nota del examen parcial, nota del examen final y el promedio de prctica. La condicin ser aprobado si el promedio final es mayor o igual a 10.5, sino la condicin ser desaprobado. Si el alumno esta desaprobado la nota del examen sustitutorio reemplaza a la nota ms baja entre el examen parcial y el examen final, seguidamente se vuelve a determinar el promedio final y su condicin. Precondiciones: El alumno debe ser un alumno regular (estar matriculado en los cursos). Postcondiciones: Se actualizara las evaluaciones del alumno en los cursos Se emitir un informe sobre las evaluaciones del alumno.

54

Universidad Tecnolgica del Per - UTP Diagrama de casos de uso

Imprimir

Ingresa datos de alumno

Alumno

Ingresa datos de evaluacin

Calcular promedio de prctica

Secretaria

<<Include>> Calcular promedio final y condicin <<include>>

Calcular menor nota

Diagrama de secuencia

:secretaria Ingresadatoa( )

:alumno

:evaluacion

Ingresadatoe( )

Promediofinal condicion( )

Promedio practica( ) menornota()

55

Universidad Tecnolgica del Per - UTP Diagrama de colaboracin Usted debe elaborar este diagrama

Diagrama de objetos :alumno Coda: a01 Nom: Patty Ruiz :evaluacion code : a01 codc : ad54 p1 : 12 p2 : 13 p3 : 11 p4 : 16 p5 : 15 ep : 17 ef : 10 es : 15

56

Universidad Tecnolgica del Per - UTP

Diagrama de clases Alumno Private Coda: char[4] Nom: char[30] evaluacion private coda : char[4] codc : char[4] p1, p2, p3, p4, p5 : int ep, ef, es: int public: evaluacion(); char* codigoe(); char* codigoc(); int n1(); int n2(); int n3(); int n4(); int n5(); int exp(); int exf(); int exs(); void ingresadatose(char[],char[],int,int,int, int, int, int, int, int); void promedioFinalCondicion(); float promedioPractica(); int menorNota();

Public alumno(); char* codigoa(); char* nombre(); void ingresadatosa(char[], char[]); void imprimira();

57

Especificacin de las clases Clase: alumno Responsabilidad: Manejar los datos personales del alumno Atributos (private) coda cadena de 4 caracteres nom cadena de 30 caracteres Mtodos (public) alumno(); char* codigoa(); char* nombre(); void ingresadatosa(char[], char[]); void imprimira(); Especificacin de los mtodos alumno() { Inicializar los atributos con espacios en blanco } char* codigoa() { Retornar el valor de coda } char* nombre() { Retornar el valor de nom } Void ingresadatosa(char codi[], char nomb[]) { Asignar a coda el valor de codi Asignar a nom el valor denomb } void alumno::imprimira() { Mostrar el codigo del alumno Mostrar el nombre del alumno } Clase: evaluacion Responsabilidad: Manejar las evaluaciones del alumno Atributos (private) coda cadena de 4 caracteres codc cadena de 4 caracteres p1, p2, p3, p4, p5 nmero entero ep, ef, es nmero entero 58

Mtodos (public) evaluacion() char* codigoe() char* codigoc() int n1() int n2() int n3() int n4() int n5() int exp() int exf() int exs() void ingresadatose(char[],char[],int,int,int, int, int, int, int, int) void promedioFinalCondicion() float promedioPractica() int menorNota()

Especificacin de los mtodos evaluacion() { Inicializa code con espacios en blanco Inicializa codc con espacios en blanco Inicializa p1, p2, p3, p4, p5, ep, ef y es en cero } char* codigoe() { Retornar el valor de coda } char* codigoc() { Retornar el valor de codc } int n1() { Retornar el valor de p1 } int n2() { Retornar el valor de p2 } int n3() { Retornar el valor de p3 }

59

int n4() { Retornar el valor de p4 } int n5() { Retornar el valor de p5 } int exp() { Retornar el valor de ep } int exf() { Retornar el valor de ef } int exs() { Retornar el valor de es }

void evaluacion::ingresadatose(char codi[],char codcu[],int pr1, int pr2, int pr3, int pr4, int pr5, int epa, int efi, int esu) { Asignar a coda el valor de codi Asignar a codc el valor de codcu Asignar a p1 el valor de pr1 siempre que sea positivo Asignar a p2 el valor de pr2 siempre que sea positivo Asignar a p3 el valor de pr3 siempre que sea positivo Asignar a p4 el valor de pr4 siempre que sea positivo Asignar a p5 el valor de pr5 siempre que sea positivo Asignar a ep el valor de epa siempre que sea positivo Asignar a ef el valor de efi siempre que sea positivo Asignar a es el valor de esu siempre que sea positivo } void evaluacion::promedioFinalCondicion() { Determinar el promedio final del alumno considerando el promedio de prctica, el examen parcial y examen final Si el alumno esta desaprobado se debe reemplazar la menor nota entre el examen parcial y examen final por la notas del examen sustitutorio Determinar nuevamente el promedio final del alumno considerando este reemplazo Mostrar el promedio final del alumno Mostrar la condicin del alumno }

60

float promedioPractica() { Determinar el promedio de prctica no considerando la menor de las prcticas retornar este valor hallado }

int menorNota() { Determinar el menor valor de de las cinco practicas Retornar este menor valor hallado }

Cuerpo principal { Crear el objeto a tipo alumno Crear el objeto e tipo evaluacion Solicitar los datos del alumno que son necesarios para el proceso de evaluacin del alumno Pasar los datos que le corresponden al objeto alumno Pasar los datos que le corresponden al objeto evaluacion Mostrar el codigo y nombre del objeto alumno Determinar y Mostar el promedio final y condicion del alumno considerando el objeto evaluacion }

61

Ejercicio prctico En una empresa se ha identificado cuatro tipos de trabajadores y cuando se desea elaborar la planilla, la secretaria considera lo siguiente: Datos de los trabajadores (cdigo y nombre) Si el trabajador es tipo 1, tiene un salario fijo Si el trabajador es tipo 2, tiene un salario base y gana una comisin (porcentaje ) sobre la cantidad de productos que ha vendido (esta cantidad esta expresada en soles) Si el trabajador es tipo 3, tiene un pago fijo por cada producto que ha elaborado, es decir , se debe considerar tambin los productos elaborados Si el trabajador es tipo 4, tiene un pago fijo por hora normal trabajada (hasta 40 horas) y tiene un pago de 50% ms del pago por hora normal, por aquellas horas extras (el exceso respecto a las 40 horas normales). Se pide desarrollar una aplicacin que permita determinar y mostrar el pago de cada uno de estos trabajadores. Usted debe considerar los conocimientos aprendidos para disear dicha aplicacin.

Descripcin del caso de uso Usted debe hacer esta descripcin Diagrama de casos de uso Usted debe elaborar este diagrama Diagrama de secuencia Usted debe elaborar este diagrama Diagrama de colaboracin Usted debe elaborar este diagrama Diagrama de objetos Usted debe elaborar este diagrama

62

Diagrama de clases (Herencia y Polimorfismo) trabajador protected codigo char[30] nombre char[30] Tipo4 Tipo1 salario float Public tipo1(char cod[], char nomb[], float s) void salariosemanal(float s); float pago(); void imprimir(); Public trabajador(char cod[], char nomb[] ) char* codigos() char* nombres() void imprimir() pagoh float horast int Public tipo4(char cod[], char nomb[], float w, int h); void pagohora(float w); void horastrabajadas(int h); float pago(); void imprimir();

Tipo2 salariob,comisiong float cantidadp int Public tipo2(char cod[], char nomb[], float s, float c, int q) void salariobase(float s); void comision(float c); void cantidadarticulos(int q); float pago(); void imprimir(); Pagoa float Producciona int

Tipo3

Public tipo3(char cod[], char nomb[], float w, int q) void pagoarticulo(float w); void produccionarticulo(int q); float pago(); void imprimir(); 63

Especificacin de las clases Clase: trabajador Responsabilidad: Manejar los datos personales del trabajador Atributos (protected) Codigo cadena de 30 caracteres nombre cadena de 30 caracteres Mtodos (public) trabajador(char cod[], char nomb[] ); char* codigos(); char* nombres(); void imprimir(); Especificacin de los mtodos trabajador(char cod[], char nomb[]) { Inicializar los atributos con espacios en blanco } char* codigos() { Retornar el valor de codigo } char* nombres() { Retornar el valor de nombre } Void imprimir() { Mostrar el codigo del trabajador Mostrar el nombre del trabajador } SubClase: tipo1 Responsabilidad: Manejar el pago fijo del trabajador Atributos salario numero real Mtodos (public) tipo1(char cod[], char nomb[], float s); void salariosemanal(float s); float pago(); void imprimir(); 64

Especificacin de los mtodos tipo1(char cod[], char nomb[], float s):trabajador(cod, nomb) { Llamar al metodo salariosemanal } void salariosemanal(float s) { Asignar a salario el valor de s } float pago() { Hacer que el pago sea el valor del salario Retornar el valor del pago } void imprimir() { Mostrar el titulo Trabajador tipo 1 Mostrar el codigo y nombre del trabajador } SubClase: tipo2 Responsabilidad: Manejar el pago con comisin del trabajador Atributos salariob,comisiong numero real cantidadp numero entero Mtodos (public) tipo2(char cod[], char nomb[], float s, float c, int q); void salariobase(float s); void comision(float c); void cantidadarticulos(int q); float pago(); void imprimir(); Especificacin de los mtodos tipo2(char cod[], char nomb[], float s, float c, int q):trabajador(cod, nomb) { Llamar al metodo salariobase Llamar al metodo comision Llamar al metodo cantidadarticulos } void salariobase(float s) { Asignar a salariob el valor de s } 65

void comision(float c) { Asignar a comisiong el valor de c } void cantidadarticulos(int q) { Asignar a cantidadp el valor de q } float pago() { Determinar el pago considerando el salario base y la comision Retornar el valor del pago } void imprimir() { Mostrar el titulo Trabajador tipo 2 Mostrar el codigo y nombre del trabajador } SubClase: tipo3 Responsabilidad: Manejar el pago del trabajador considerando los artculos producidos Atributos pagoa numero real producciona numero entero Mtodos (public) tipo3(char cod[], char nomb[], float w, int q); void pagoarticulo(float w); void produccionarticulo(int q); float pago(); void imprimir(); Especificacin de los mtodos tipo3(char cod[], char nomb[], float w, int q):trabajador(cod, nomb) { Llamar al metodo pagoarticulo Llamar al metodo produccionarticulo } void pagoarticulo(float w) { Asignar a pagoa el valor de w } void produccionarticulo(int q) { Asignar a producciona el valor de q }

66

float pago() { Determinar el pago considerando los articulos producidos Retornar el valor del pago } void imprimir() { Mostrar el titulo Trabajador tipo 3 Mostrar el codigo y nombre del trabajador }

SubClase: tipo4 Responsabilidad: Manejar el pago del trabajador considerando las horas trabajadas Atributos Pagoh numero real Horast numero entero Mtodos (public) tipo4(char cod[], char nomb[], float w, int h); void pagohora(float w) void horastrabajadas(int h) float pago() void imprimir() Especificacin de los mtodos tipo4(char cod[], char nomb[], float w, int h):trabajador(cod, nomb) { Llamar al metodo pagohora Llamar al metodo horastrabajadas } void pagohora(float w) { Asignar a pagoh el valor de w } void horastrabajadas(int h) { Asignar a horast el valor de h } float pago() { Determinar el pago considerando que si las horas son mayores a 40 este exceso se considera como horas extras Retornar el valor del pago } 67

void imprimir() { Mostrar el titulo Trabajador tipo 4 Mostrar el codigo y nombre del trabajador }

Cuerpo principal { Crear el objeto t1 del tipo tipo1 Solicitar los datos para este objeto Mostrar el tipo de trabajador, codigo y nombre Determinar y mostrar el pago que le corresponde considerando el mtodo pago de este objeto Crear el objeto t2 del tipo tipo2 Solicitar los datos para este objeto Mostrar el tipo de trabajador, codigo y nombre Determinar y mostrar el pago que le corresponde considerando el mtodo pago de este objeto Crear el objeto t3 del tipo tipo3 Solicitar los datos para este objeto Mostrar el tipo de trabajador, codigo y nombre Determinar y mostrar el pago que le corresponde considerando el mtodo pago de este objeto Crear el objeto t4 del tipo tipo4 Solicitar los datos para este objeto Mostrar el tipo de trabajador, codigo y nombre Determinar y mostrar el pago que le corresponde considerando el mtodo pago de este objeto }

68

EJERCICIOS En cada uno de los siguientes ejercicios se debe elaborar: Descripcin del caso de uso Diagrama de casos de uso Diagrama de secuencia Diagrama de colaboracin Diagrama de objetos Diagrama de clases Especificacin de las clases Construccin de la aplicacin (java con base de datos) 1. Supngase esta situacin: en una empresa se esta haciendo el estudio sobre las edades promedios de los hijos de los trabajadores. Dicho proceso se realiza de la siguiente manera: La secretaria debe ingresar los siguientes datos de cada uno de los trabajadores: cdigo del trabajador, nombre del trabajador y las edades de cada uno de sus hijos (hombres y mujeres), estas edades deben ser verificadas para ser aceptados en el proceso. La idea es determinar y mostrar la edad promedio de los hijos slo hombres y tambin determinar la edad promedio de las hijas mujeres. Adems se debe determinar la edad promedio de todos los hijos. 2. En una empresa cuando se le paga a un trabajador se considera los siguientes datos: Cdigo, Nombre, Categora (puede ser: 1, 2, 3), Ao de ingreso, Numero de hijos, Estado civil (puede ser: s]oltero, c]asado, d]ivorciado, v]iudo) Sueldo bsico. Seguidamente se desea determinar: Bonificacin por aos de servicios (2% del sueldo bsico si tiene ms de 10 aos de servicio) Bonificacin por hijos (1% del sueldo bsico, si el estado civil es: c, d, v) Bonificacin por categora (puede ser: 5%, 7%, 9% del sueldo bsico, respectivamente) Subtotal (sueldo bsico ms todas las bonificaciones) Descuento (10% del sueldo bsico, si el trabajador es soltero) Sueldo Neto (subtotal menos el descuento)
3.

En una entidad educativa para matricular un alumno, a partir del segundo ciclo, se consideran los siguientes datos: cdigo, nombre, nmero de cursos (en los cuales se va a matricular), precio por cada curso (el precio es el mismo para cada curso) y el promedio del ciclo anterior. Se desea determinar y mostrar: Monto total de los cursos (se sabe que el precio de los cursos se incrementa en un 15% de su valor en los meses de julio y diciembre) Descuento (el alumno tendr un descuento del 5% sobre el monto total de los cursos si el promedio es mayor o igual a 16, en caso contrario el descuento ser del 2% del monto total de los cursos) Importe a pagar (es lo que finalmente debe cancelar el alumno)

4. En una empresa para calcular el pago de cada uno de los trabajadores, el pagador debe considerar los siguientes datos del trabajador: nombre, sueldo bsico, nmero de hijos y fecha de contrato. Se sabe que los beneficios que 69

recibe es un bono del 3% del sueldo bsico si este es menor a 450 soles, 8 soles por cada hijo siempre que tenga menos de 5 hijos en caso contrario solo recibe 35 soles y recibe por cada ao de servicio el 0.8% del sueldo bsico. Los descuentos son 5% del sueldo bsico para AFP y 2% del sueldo bsico para ESSALUD. La empresa tiene la necesidad de imprimir por separado los beneficios y los descuentos, para finalmente imprimir los datos del trabajador con el pago correspondiente 5. En una empresa que vende productos medicinales, cuando se le paga a los trabajadores, se consideran los siguientes datos: cdigo, nombre, sueldo bsico y categora (A, B y C) Se desea determinar y mostrar: Bonificacin por categora (si la categora es A la bonificacin es 3% del sueldo bsico, si la categora es B la bonificacin es 2% del sueldo bsico y si la categora es C la bonificacin es 1% del sueldo bsico. Adems se sabe que: a todos los trabajadores se les da un gratificacin del 50% del sueldo bsico en el mes de julio y diciembre) Pago Bruto (todo el ingreso que recibe el trabajador) Descuento (si el pago bruto es mayor a $980 el descuento es el 0.05% del pago bruto, en caso contrario es el 0.025% del pago bruto) Pago neto (es lo que finalmente se le debe pagar al trabajador) 6. En una empresa para calcular el pago de cada uno de los trabajadores, el pagador debe considerar los siguientes datos del trabajador: nombre, sueldo bsico, nmero de hijos y aos de servicios. Se sabe que por cada hijo recibe 10 soles y por cada ao de servicio recibe el 0.3% del sueldo bsico. Adems se le debe hacer los descuentos que por ley le corresponde: AFP que es el 5% del sueldo bsico y ESSALUD que es el 7% del sueldo bsico. Los datos estn almacenados de manera apropiada. Tambin se desea almacenar los beneficios y descuentos que se estn haciendo. 7. En un industria para determinar el pago de los obreros se considera: Cdigo del obrero Nombre del obrero Pago por hora (con dos cifra decimales) Nmero de horas trabajadas (nmero entero) Horas extras trabajadas (nmero entero) Numero de hijos Se debe mostrar Monto de las horas normales Monto de las hora extras Bonificacin por hijos Monto total Descuento Pago neto Considerar: El pago por hora extra es el 50% del pago por hora normal. La bonificacin por cada hijo es de 5 nuevos soles 70

 El monto de la horas extras es lo que ha ganado por trabajar las horas extras El monto total es la suma del monto de las horas que ha trabajado ms la bonificacin por hijos El descuento es el 0.5% del monto total si este es menor a 800, en caso contrario ser el 1% del monto total El pago neto es la diferencia del monto total y el descuento

71

CAPITULO VI
6.1 DIAGRAMAS DE ESTADO Todos los sistemas reales tienen una dimensin dinmica, y esta dinmica se activa por las cosas que ocurren externa o internamente. En UML cada cosa que sucede se modela como un evento, y permiten, cuando ocurren, pasar en un objeto de un estado a otro, al responder con una accin. Los aspectos dinmicos de un sistema se modelan usando mquinas de estados que la mayora de las veces ser una clase, un caso de uso o un sistema completo. Las mquinas de estados pueden visualizarse de dos formas: usando los diagramas de actividades, centrndose en las actividades que ocurren dentro del objeto, y la segunda usando los diagramas de estados, centrndose en el comportamiento dirigido por eventos de un objeto (til en modelaje de sistemas reactivos).

Trminos y Conceptos Una mquina de estados es un comportamiento que especifica las secuencias de estados por las que pasa un objeto a lo largo de su vida en espera a eventos, junto con sus respuestas a estos eventos. Un estado es una condicin o situacin en la vida de un objeto durante la cual satisface a alguna condicin, realiza alguna actividad o espera algn evento. Un evento es la especificacin de un acontecimiento significativo que ocupa lugar en el tiempo y en el espacio. En el contexto de las mquinas de estados, un evento es la aparicin de un estimulo que puede disparar una transicin de estados. Una transicin es una relacin entre dos estados que indica que un objeto que este en el primer estado realizar ciertas acciones y entrar en el segundo estado cuando ocurra un evento especificado y se satisfagan unas condiciones definidas. Una actividad es un ejecucin no atmica en curso, dentro de una mquina de estados. Una accin es una computacin atmica ejecutable que produce un cambio de estado del modelo o devuelve un valor. Grficamente un estado se presenta como un rectngulo con las esquinas Un estado es una condicin o situacin en la vida de un objeto durante la cual satisface alguna condicin, realiza alguna actividad o espera algn evento. Un objeto permanece en un estado durante una cantidad de tiempo finita. Ejemplo: un Calentador puede estar en cualquiera de los siguientes cuatro estados: Inactivo: En preparacin: Activo: Apagando: Esperando la orden para calentar agua Se ha encendido, pero esta esperando que la temperatura se eleve. La energa esta encendida y el servicio de calefaccin funciona La energa se ha cortado pero el calentador an continua funcionando, enviando el agua calentada residual 72

Cuando la mquina de estados de un objeto se halla en un estado dado, se dice que el objeto est en ese estado. Ejemplo: el Calentador puede estar Activo o Apagando. Un estado tiene varias partes: 1 Nombre: 2 Acciones de entrada/salida : Una cadena de texto que distinguen el estado de otros Acciones ejecutadas al entrar y salir del estado, respectivamente

3 Transiciones Internas: Transiciones que no producen un cambio de estado 4 Susbestados: Estructura anidada en un estado, que engloba susbestados disjuntos (activos secuenciales) o concurrentes (activos Concurrentemente) lista de eventos que no se manejan en ese estado sino que se posponen y se aaden a una cola para ser manejados por el objeto en otro estado

5 Eventos diferidos:

Un estado se representa con un rectngulo con las esquinas redondeadas. El estado inicial, que indica el punto de comienzo por defecto para las mquinas de estado o subestado, se representa con un crculo negro. El estado final, indica que la ejecucin de la mquina de estados o del estado que lo contiene ha finalizado, se representa por un crculo negro dentro de una circunferencia. Una transicin es una relacin entre estados que indica que un objeto que esta en el primer estado, realizar ciertas acciones y entrar en el segundo estado cuando ocurra el evento especificado y se satisfagan las condiciones especificadas. Cuando esto ocurre se dice que la transicin se ha disparado. Hasta que se dispara la transicin, se dice que el objeto esta en el estado origen, despus de dispararse, se dice que esta en el estado destino. Por ejemplo: un Calentador puede pasar del estado inactivo al estado Enpreparacin cuando ocurra un evento como aguaFria (con el parmetro tempEsperada). Una transicin tiene 5 partes. 1 Estado origen: El estado afectado por la transicin; si un objeto esta en el estado origen, una transicin de salida puede dispararse cuando el objeto reciba el evento de disparo de la transicin, y si la condicin de guarda se satisface.

2 Evento disparo:

de Evento cuya recepcin por el objeto que esta en el estado origen provoca el disparo de la transicin si se satisface su condicin de guarda. Expresin booleana que se evala cuando se activa la transicin; si la expresin toma el valor verdadero, la transicin se puede disparar, de lo contrario no se dispara y si no hay otra transicin que pueda ser disparada por el mismo evento, 73

3 Condicin de guarda:

4 Accin:

sta se pierde. Computacin atmica ejecutable que puede actuar directamente sobre el objeto asociado a la mquina de estados.

5 Estado destino El estado activo tras completarse la transicin. :

Un estado representa con una lnea continua dirigida desde el estado origen hacia el destino. Una autotransicin es una transicin cuyos estados origen y destino son el mismo. Es posible tenor un transicin sin disparador, representada por una transicin sin evento de disparo. Una transicin sin disparador se dispara implcitamente cuando su estado origen ha completado su actividad. Los diagrama. de estados son autmatas jerrquicos que permiten expresar concurrencia, sincronizacin y jerarquas de objetos. Los diagramas de estados son grafos dirigidos. Los diagramas de estados de UML son deterministas, los estados inicial y final estn diferenciados del resto, la transicin entre estados es instantnea y se debe a la ocurrencia de un evento

Ejemplo de un Diagrama de Estados para la clase persona:

c o n t ra t a r e n e l p a ro p e rd e r e m p le o ju b ila rs e ju b il a rs e e n a c t ivo

ju b ila d o

La comunicacin bidireccional puede representarse mediante comunicacin asncrona. Por ejemplo en un Diagrama de Colaboracin:

1 : u n a p r e g u n ta un o b je t o 2 : la re s p u e s ta o t ro o b j e to

74

Si la comunicacin es sncrona el cliente debe esperar la respuesta. Con lo cual en el cliente tendramos:
a

p l an t e a r p re g u n ta

e s p e ra re s p u e s t a

re c i b i r re s p u e s t a

Las guardas permiten condicionar la transicin:

a E ve n to [ c o n d i c i n ] b

Podemos especificar la ejecucin de una accin como consecuencia de la transicin:

a E ve n to [ c o n d ic i n ] / a c c i n b

Se puede especificar el hacer una accin como consecuencia de entrar, salir o estar en un estado:
e s ta d o A e n tr y: a c c i n p o r e n tr a r e xi t: a c c i n p o r s a l i r d o : a c c i n m i e n tr a s e n e s ta d o

Se puede especificar el hacer una accin cuando ocurre en dicho estado un evento que no conlleva salir del estado:
e s ta d o A o n e ve n to _ a c ti va d o r ( a r g 1 ) [ c o n d i c i n ]: a c c i n p o r e ve n to

Podemos reducir la complejidad de estos diagramas usando la generalizacin de estados. Distinguimos as entre superestado y subastados. Un estado

75

puede contener varios subestados disjuntos. Los subestados heredan las variables de estado y las transiciones externas.

e1

e2 e2 c

Quedara como:

e1

e2

Las transiciones de entrada deben ir hacia subestados especficos:

e1 a e2 b

e0

Es preferible tener estados iniciales de entrada a un nivel de manera que desde los niveles superiores no se sepa a qu subestado se entra:
e1 a b c e2 e0

76

La agregacin de estados es la composicin de un estado a partir de varios estados independientes. La composicin es concurrente por lo que el objeto estar en alguno de los estados de cada uno de los subestados concurrentes

e1 e1

Historial Por defecto, los autmatas no tienen memoria. Es posible memorizar el ltimo subestado visitado para recuperarlo en una transicin entrante en el superestado que lo engloba.

E n ju a g u e

L a va d o

S ec ado

A b r i r P u e r ta

C e rra r P u e rt a

E s p e ra

La destruccin de un objeto es efectiva cuando el flujo de control del autmata alcanza un estado final no anidado. La llegada a un estado final anidado implica la subida al superestado asociado, no el fin del objeto . Las esperas son actividades que tienen asociada cierta duracin. La actividad de espera se interrumpe cuando el evento esperado tiene lugar. Este evento desencadena una transicin que permite salir del estado que alberga la actividad de espera. El flujo de control se transmite entonces a otro estado

77

/ Abrir ranura esperar dinero entry: Mostrar mensaje do: Esperar 30 segundos exit: cerrar ranura Depsito efectuado b

anular transaccin

Ejemplo ASCENSOR
SUBIENDO
on Cambio de piso/ Indicador=Piso actual

Seleccionar[ piso destino>piso actual ]

Llegada piso destino / Indicador=Piso actual

ESTATICO entry/ Abrir puerta exit/ Cerrar puerta

Seleccionar[ piso destino<piso actual ] Llegada a piso destino / Indicador=Piso actual

BAJANDO
on Cambio de piso/ Indicador=Piso actual

Conteste a las siguientes preguntas: 1. Si estamos en el estado SUBIENDO y se produce el evento Llegada piso destino A qu estado se llega? 2. Qu evento debe ocurrir para que se dispare la transicin desde el estado ESTATICO al estado SUBIENDO? 3. Qu eventos al menos habrn sucedido y en que orden para pasar del estado SUBIENDO al estado BAJANDO?

78

4. Partiendo del estado inicial a qu estado se llega si ocurre la siguiente secuencia de eventos: (1) Seleccionar[piso destino<piso actual], (2) Llegada a piso destino, (3) Seleccionar[piso destino<piso actual]

Ejemplo MARCAR NUMERO TELEFONICO

Pulsar digito(n)

Descolgar

INICIO
entry/ Iniciar tono marcado exit/ Finalizar tono marcado

Pulsar digito(n)

MARCANDO
entry/ Number.append(n)

[ number.isValid() ]

Conteste a las siguientes preguntas: 1. Si estamos en el estado INICIO y se produce el evento Pulsar dgino(n) A qu estado se llega? 2. Qu evento provoca que se llegue al estado INICIO? 3. Qu eventos y/o condiciones habrn sucedido como mnimo y en qu orden para pasar del estado inicial al estado final? 4. Partiendo del estado inicial a qu estado se llega si ocurre la siguiente secuencia de eventos y condiciones: (1) Descolgar, (2) Pulsar digito(n), y (3) Pulsar digito(n).

Ejemplo HABITACIN HOTEL

DISPONIBLE Servicio de limpieza DESOCUPADA PARA LIMPIAR

Cancelacion reserva

Hacer reserva

Salida del cliente

HABITACION OCUPADA HABITACION RESERVADA entry/ Anotar reserva

Llegada del cliente

on Uso minibar/ Incremento cuenta entry/ Iniciar factura exit/ Emitir factura

79

Conteste a las siguientes preguntas: 1. A qu estado llegaremos si estamos en el estado HABITACIN RESERVADA y se produce el evento Cancelacin reserva? 2. Si estamos en el estado HABITACIN OCUPADA y se llega DESOCUPADA PARA LIMPIAR Qu evento habr sucedido? 3. Qu eventos y/o condiciones habrn sucedido como mnimo y en qu orden para pasar del estado DISPONIBLE al estado DESOCUPADA PARA LIMPIAR? 4. Partiendo del estado DESOCUPADA PARA LIMPIAR a qu estado se llega si ocurre la siguiente secuencia de eventos y condiciones: (1) Servicio de limpieza, (2) Hacer reserva, y (3) Cancelacin de la reserva. Ejemplo EMBOTELLADO

EMBOTELLANDO

ROTA

DeteccionRotura[ Vactual=0 ]

VACIA

[ Vactual=0 ]

GOTEANDO

LLENANDO
on Comprobar[ Vactual<Vdeseado ]/ Aadir liquido entry/ Vactual=0

do/ Vaciar

[ Vactual=Vdeseado ]

DeteccionRotura [ Vactual !=0 ]

LLENA

PonerTapon

SELLADA

Conteste a las siguientes preguntas: 1. Si una botella esta en el subestado GOTEANDO del estado compuesto ROTA Qu evento o condicin puede provocar el cambio de estado? 2. Estamos en el subestado LLENANDO del estado compuesto EMBOTELLANDO, se produce el evento DeteccionRotura[Vactual=0] A qu estado se llega? 3. Qu eventos y/o condiciones habrn sucedido como mnimo y en qu orden si se pasa del estado inicial al estado SELLADA?

80

4. Partiendo del subestado LLENANDO del estado compuesto EMBOTELLANDO, a qu estado se llega si ocurre la siguiente secuencia de eventos y condiciones: (1) Comprobar[Vactual<Vdeseado], (2) DeteccionRotura[Vactual!=0], y (3) [Vactual=0]

Ejemplo CLIMATIZADOR
SELECCIONANDO T do/ Display T seleccionada Seleccionar T
Salir

INACTIVO Encender Apagar

on Paso 30 seg/ Medir T ambiente do/ Display T ambiente entry/ Medir T ambiente

Tambiente=T seleccionada Tambiente<T seleccionada Tambiente=T seleccionada

Tambiente>T seleccionada

CALENTANDO
on Paso 30 seg/ Medir T ambiente entry/ Encender resistencias exit/ Apagar resistencias

Tambiente>T seleccionada

ENFRIANDO
on Cada 30 seg/ Medir T ambiente entry/ Encender compresor exit/ Apagar compresor

Tambiente<T seleccionada

Conteste a las siguientes preguntas: 1. Si estamos en el estado INACTIVO y llegamos SELECCIONANDO T Qu evento ha sucedido?

al

estado

2. Si estamos en el estado INACTIVO y la temperatura ambiente es mayor que la temperatura seleccionada A qu estado se llega? 3. Qu eventos y/o condiciones habrn sucedido como mnimo y en qu orden para pasar del estado inicial al estado ENFRIANDO si se ha de seleccionar previamente la temperatura?

81

4. Partiendo del estado INACTIVO a qu estado se llega si ocurre la siguiente secuencia de eventos y condiciones: (1) Seleccionar T, (2) Salir, (3) [Tambiente<Tseleccionada], y (4) [Tambiente>Tseleccionada].

82

Subestados secuenciales. Veamos los subestados secuenciales con un ejemplo: el modelar el comportamiento de un cajero automtico. Hay 3 estados en los que puede estar el sistema Inactivo (en espera de un cliente), Activo (procesando una transaccin de un cliente) y Mantenimiento (recargando dinero).

tarjetaIntroducida

Activo Validacin

Inactivo
Cancelar

Estado compuesto Subestado secuencial [Continuar]

Seleccin Mantenimiento Procesamiento

[no continuar] Transicin desde subestado Entry/leertarjeta Exit/explusartarjeta

Impresin

83

Subestados concurrentes. Los subestados secuenciales son los que aparecen con mayor frecuencia en el modelaje; sin embargo en algunas situaciones debe trabajarse con subestados concurrentes, los cuales permiten especificar dos o mas maquinas de estados que se ejecutan en paralelo en el contexto que los contiene. Veamos el ejemplo de la figura. Dados dos o ms subestados secuenciales al mismo nivel, un objeto estar en uno y solo uno de los subestados. Dados dos o ms subestados concurrentes al mismo nivel, un objeto estar en un estado secuencial de cada uno de los subestados concurrentes.

divisin mantener

Inactivo
unin Estado compuesto

Mantenimiento Pruebas

Probar perifricos

Auto diagnostico

subestados concurrentes Manejo de Ordenes [continuar]

Espera

Orden
Tecla Pulsada [no continuar]

En el estado compuesto por subestados concurrentes, la ejecucin de stos contina en paralelo. Si un subestado concurrente alcanza su estado final antes que el otro, el control de ese subestado espera en su estado final hasta que el otro u otros subestados concurrentes alcancen sus respectivos estados finales, luego de lo cual se vuelven a unir en un mismo flujo.

84

6.2 DIAGRAMA DE ACTIVIDAD Los diagramas de actividades son uno de los cinco tipos de diagrama UML usados para modelar los aspectos dinmicos de los sistemas. Un diagrama de actividades es bsicamente un diagrama de flujo que muestra el flujo de control entre actividades. Los diagramas de actividades se utilizan para modelar los pasos secuenciales y posiblemente concurrentes de un proceso computacional. Tambin permite modelar el flujo de un objeto conforme pasa de estado a estado en diferentes puntos del flujo de control. Los diagramas de interaccin destacan el flujo de control entre objetos, los diagramas de actividades destacan el flujo de control entre actividades. Una actividad es una ejecucin no atmica en curso, dentro de una mquina de estados. Las actividades producen alguna accin, compuesta de computaciones atmicas ejecutables que producen un cambio en el estado del sistema o el retorno de un valor. Los diagramas de actividades son similares a los diagramas Pert. Un diagrama de actividades destaca la actividad que ocurre a lo largo del tiempo, mostrando las operaciones que se pasan entre los objetos. Trminos y conceptos Un diagrama de actividades muestra el flujo de actividades. Una actividad es una ejecucin no atmica en curso, dentro de una maquina de estados. Las actividades finalmente producen una accin, que esta compuesta de computaciones atmicas ejecutables que producen un cambio en el estado del sistema, o la devolucin de un valor. Las acciones incluyen llamadas a otras operaciones, envo de seales, creacin o destruccin de objetos o simples clculos (evaluar una expresin). Grficamente un diagrama de actividades es una coleccin de nodos y arcos. Normalmente un diagrama de actividades contiene: Estado de actividad y estados de accin. Transiciones Objetos Al igual que los dems diagramas, el diagrama de actividades pueden contener restricciones. Estados de accin y estados de actividad Un flujo de control modelado por un diagrama de actividades contiene diferentes sucesos, como evaluacin de expresiones que asignen un valor a un atributo o devuelva un valor. Tambin se puede invocar una operacin sobre un objeto, enviar una seal a un objeto o crear o destruir objetos. Este tipo de computaciones ejecutables y atmicas se llaman Estados de accin, porque son estados del sistema y cada una representa la ejecucin de una accin. El estado de accin se representa por un ovalo donde se escribe cualquier expresin.

85

accin simple

expresin

Preparar oferta

Indice = buscar(e) +3;

Los estados de accin no se pueden descomponer. Los estados de accin son atmicos, lo que significa que pueden ocurrir eventos, pero no se interrumpe la ejecucin del estado de accin. Se considera que la ejecucin de un estado de accin se realiza en un tiempo insignificante. Los estados de actividades pueden descomponerse an ms, representando su actividad con otros diagramas de actividades. Los estados de actividades no son atmicos. Es decir, pueden ser interrumpidos y en general invierten algn tiempo en completarse. Un estado de accin se puede ver como un caso especial de un estado de actividad. Un estado de actividad puede verse como un elemento compuesto, cuyo flujo de control se compone de otros estados de actividad y estados de accin. Entrando en detalles, en un estado de actividades se encontrar otro diagrama de actividades. Se usa la misma notacin para estados de accin y estados de actividad, con la excepcin que un estado de actividad puede tener partes adicionales, como acciones de entrada y salida y especificaciones de submquinas.
Procesar factura (f)
submaquinas accin de entrada

Preparar construccin ( ) Entry/poner Bloqueo ( )

Los estados de actividad son importantes por ayudar a dividir clculos complejos en partes ms simples, de la misma forma en que se utilizan las operaciones para agrupar y reutilizar expresiones.

Transiciones Cuando se completa la accin o la actividad de un estado, el flujo de control pasa inmediatamente al siguiente estado de accin o estado de actividad. Este flujo se especifica con transiciones que muestran el camino de un estado de actividad o estado de accin al siguiente. En UML la transicin se representa como una lnea dirigida.

86

estado inicial

Elegir Sitio
estado de accin Transicin

Contratar arquitecto

estado parada

Un flujo de control tiene que empezar y parar en algn sitio, por ello se puede especificar un estado inicial (circulo relleno) y un estado final (circulo relleno dentro de un circunferencia). Bifurcacin Las transacciones secuenciales no son el nico tipo de camino en un flujo de control, tambin se puede incluir una bifurcacin, que especifica caminos alternos, elegidos segn el valor de alguna expresin booleana.

Parte de trabajo

expresin de guarda

bifurcacin

[materiales no disponibles]

Repetir planeacin

[materiales disponibles] expresin de guarda Asignar tareas

Se puede lograr el efecto de iteracin usando un estado de accin que establezca el valor de la variable de control de una iteracin: otro estado de accin que incrementa el valor de la variable y una bifurcacin si se ha terminado la iteracin. Divisin y unin Es posible encontrar flujos concurrentes, especialmente cuando se modelan flujos de trabajo de procesos de negocio. En UML una divisin y la unin emplean una barra de sincronizacin para especificarlas, la cual se representa como una lnea horizontal o vertical ancha.

87

Ejemplo:

Preparar conversacin divisin

Descomprimir Gesticular ( )

Mover boca ( )

Emitir audio ( )

unin

Limpieza

El ejemplo considera los flujos implicados en el control de un dispositivo electrnico que emite voz y gestos humanos. En la figura se presenta una divisin, que representa la separacin de un flujo de control sencillo en dos o mas flujos concurrentes. Una divisin tiene una transicin de entrada y dos o mas transiciones de salida, cada una representa un flujo de control independiente. Despus de la divisin, las actividades de cada camino continan en paralelo. En la figura, una unin representa la sincronizacin de dos o ms flujos de control concurrentes. Una unin puede tener dos o ms transiciones de entrada y una de salida. En la unin los flujos concurrentes se sincronizan, es decir, cada uno espera hasta que todos los flujos de entrada han alcanzado a la unin y a partir de ese punto continua un nico flujo de control que sale de la unin. Las uniones y divisiones deben equilibrarse, es decir, el nmero de flujos que parten de una divisin debe coincidir con el nmero de flujos que entran en la unin correspondiente.

88

Ejemplo de diagrama de actividad

[no hay caf] Buscar Bebida [hay caf

[no zumo] [hay zumo]

Poner caf en filtro

Aadir agua al depsito

Coger taza Coger zumo

Poner filtro en mquina

Encender mquina ^cafetera.On Caf en preparacin indicador de fin Servir caf Beber

Carriles (swimlanes) Cuando se modelan flujos de trabajo de procesos de organizaciones es til dividir los estados de la actividad en grupos, donde cada uno representa la parte de la organizacin responsable de esas actividades. En UML cada grupo se denomina carril porque, visualmente cada grupo se separa de sus vecinos por una lnea vertical continua. Un carril especifica un lugar para las actividades.

89

Ejemplo de diagrama de actividad

Pasajero

Vendedor

Airline

Solicitar pasaje Verificar existencia vuelo Dar detalles vuelo Informar alternativas y precios Seleccionar vuelo

Solicitar pago Pagar pasaje

Reservar plazas Confirmar plaza reservada

Emitir billete

90

Ejemplo de diagrama de actividad

Cliente

Ventas

Almacn

Solicitar producto

carril

Procesar pedido

Extraer artculos

Enviar pedido

Recibir pedido

Facturar al cliente

Pagar factura Cerrar pedido

Cada carril tiene un nombre nico en el diagrama. Un carril puede representar alguna entidad del mundo real, que puede ser implementada por una o varias clases. En un diagrama de actividades organizado por carriles, cada actividad pertenece a un nico carril, pero las transiciones pueden cruzar los carriles. Modelado de un flujo de trabajo Al modelar un flujo de trabajo se hace hincapi en las actividades, tal como son observadas por los actores que colaboran con el sistema. En el entorno de los sistemas con gran cantidades software, existen flujos de trabajo y se usan para visualizar, especificar, construir y documentar procesos de negocio que implican al sistema que s esta desarrollando. Es posible hallar sistemas automticos que trabajan en el contexto de procesos de negocios de ms alto nivel. Estos procesos de negocio son tipos de flujo de trabajo porque representan el flujo de trabajo y objetos a travs del negocio. Por ejemplo, en un negocio de venta habr algunos sistemas automticos y sistemas conformados por personas. Los diagramas de 91

actividades pueden utilizarse para modelar procesos en los que colaboran estos sistemas automticos y humanos. Para modelar un flujo de trabajo: Hay que establecer un centro de inters apara el flujo de trabajo. En sistemas no triviales no es posible mostrar todos los flujos de trabajo interesantes en un diagrama. Se deben seleccionar los objetos del negocio que tienen las responsabilidades de ms alto nivel en cada parte del flujo de trabajo global. En cualquier caso debe crearse un carril para cada objeto importante. Hay que identificar las precondiciones del estado inicial del flujo de trabajo las poscondiciones del estado final; esto ayuda a modelar los limites del flujo de trabajo. Comenzando por el estado inicial del flujo de trabajo, hay que especificar las actividades y acciones que ocurren a lo largo del tiempo, representndolos como estados de actividad o estados de accin. Hay que llevar las acciones complicadas o los conjuntos de acciones que aparezcan muchas veces a estados de actividad, y ubicarlas en un diagrama de actividades separado, expandindolas.
Cliente Televentas Contabilidad Almacn

Solicitar devolucin

Obtener numero de devolucin

Enviar articulo Recibir articulo Articulo : i [devuelto] Recolectar articulo Actualizar cuenta Articulo : i [disponible]

Hay que representar las transiciones que conectan los estados de accin y de actividad. Debe comenzarse con los flujos secuenciales del flujo de trabajo, luego considerar las bifurcaciones y por ltimo tener en cuenta divisiones y uniones. 92

Si el flujo involucra objetos importantes, hay que representarlas en el diagrama de actividades, mostrando sus valores y estado cuando cambien, mostrando el propsito del flujo de objetos.

En el ejemplo de la figura anterior, se muestra un diagrama de actividades de un negocio de venta que especifica el flujo de trabajo cuando un cliente devuelve un artculo de un pedido. El proceso comienza con la accin SolicitarDevolucin del Cliente y despus pasa a travs de Televentas a Obtener nmero de devolucin, vuelve al Cliente a Enviar articulo y despus pasa al almacn que ejecutas dos acciones Recibir artculo y Recolocar artculo y finalmente llega a Contabilidad que ejecuta Actualizar cuenta. En el diagrama se indica que hay un objeto significativo (el Artculo:i) tambin fluye en el proceso, cambiando del estado devuelta a disponible. En este ejemplo no se presenta bifurcaciones, ni divisiones ni uniones, caractersticas propias de flujos de trabajo ms complejos.

93

CAPITULO VII
7.1 DIAGRAMA DE COMPONENTES Los diagramas de componentes describen los elementos fsicos del sistema y sus relaciones Muestran las opciones de realizacin incluyendo cdigo fuente, binario y ejecutable. Los componentes representan todos los tipos de elementos software que entran en la fabricacin de aplicaciones informticas. Pueden ser simples archivos, paquetes de Ada, bibliotecas cargadas dinmicamente, etc. Cada clase del modelo lgico se realiza en dos componentes: la especificacin y el cuerpo. En C++ una especificacin corresponde a un archivo con un sufijo .h y un cuerpo a un archivo con un sufijo .cpp. En Ada la nocin de mdulo existe directamente en el lenguaje con el nombre del paquete. Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente

Ejemplo
Control y Anlisis Interfaz de Terminal Comment Comment

Gestin de Cuentas Comment

Rutinas de Coneccion Comment

Acceso a BD Comment

94

7.2 DIAGRAMA DE DISTRIBUCIN Los Diagramas de Distribucin muestran la disposicin fsica de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos
usuario
Nodo

Los estereotipos permiten precisar la naturaleza del equipo: Dispositivos Procesadores Memoria Los nodos se interconectan mediante soportes bidireccionales (en principio) que pueden a su vez estereotiparse

< < P ro c e s a d o r> Nodo < < < < T C P /I P > > > > c o n e x i n 1

< < d i s p o s i t i vo > > nodo2

c o n e x i n 7 < < R D S I> > d is p o s it iv o

95

Ejemplo
Servidor Central Acceso a BD Comment Control y Anlisis Comment

Rutinas de Coneccion Comment

Terminal de Consulta Rutinas de Coneccion Comment

Interfaz de Terminal Comment

Punto de Venta

Rutinas de Coneccion Comment

Gestin de Cuentas Comment

Interfaz de Terminal Comment

96

Resumen
Captura de Requisitos Anlisis y Diseo
Diagramas de Estados Diagramas de Secuencia Diagramas de Casos de Uso Diagramas de Colaboracin Diagramas de Distribucin Diagramas De Clases Diagramas de Componentes Diagramas de Actividad

Implementacin

Diagramas de Actividad

"You can model 80 percent of most problems by using about 20 percent of the UML."-- Grady Booch

97

7.3 TRABAJO PRCTICO Documentacin Diagrama Casos de Uso "Circulacin Libros Biblioteca" [ Caso Uso ] Manejo Usuarios [ Actores ] Bibliotecario, Usuario [ Flujo Principal ] Manejar las novedades relacionadas con los usuarios de la biblioteca. Inicia cuando el Bibliotecario abre una sesin ante el sistema identificndose ante l de manera satisfactoria. Termina en cualquier momento que el bibliotecario desee cerrar su sesin. [ Flujo Excepcional ] El sistema no puede determinar la identidad y las actividades permitidas para el bibliotecario.

[ Caso Uso ] Manejo Libros [ Actores ] Bibliotecario, Usuario [ Flujo Principal ] Manejar las novedades relacionadas con los libros de la biblioteca. Se inicia cuando el bibliotecario abre una sesin ante el sistema. Termina en cualquier momento que el bibliotecario desee cerrar su sesin. [ Flujo Excepcional ] El sistema no puede determinar la identidad y las actividades permitidas para el bibliotecario o usuario. "Manejo Usuarios" [ Caso Uso ] Reporte Usuarios [ Actores ] Bibliotecario [ Flujo Principal ] Reportes sobre la totalidad de los usuarios discriminados por tipos. Se ejecuta mnimo una vez al mes. [ Flujo Excepcional ] El sistema no est en capacidad de iniciar la elaboracin de este reporte al momento de ser solicitado. Lo pospone para cuando sea posible. [ Flujo Excepcional ] El Bibliotecario no cuenta con el nivel de seguridad necesario para solicitar este tipo de reporte. Se le informa al bibliotecario de dicha situacin.

98

[ Caso Uso ] Estado Usuarios [ Actores ] Bibliotecario [ Flujo Principal ] Reportes sobre los usuarios que a la fecha incurren en mora con sus prestamos. Calcula y actualiza los montos de las multas. Se ejecuta una vez al da, tan pronto ha concluido la atencin al publico. [ Flujo Excepcional ] El Bibliotecario no cuenta con el nivel de seguridad necesario para solicitar este tipo de reporte. Se le informa al Bibliotecario de dicha situacin. [ Flujo Excepcional ] El sistema no est en capacidad de iniciar la elaboracin de este reporte al momento de ser solicitado. Debe ser solicitado nuevamente por el Bibliotecario. Se le informa al Bibliotecario de dicha situacin.

[ Caso Uso ] Movimiento Usuarios [ Actores ] Bibliotecario, Usuario [ Flujo Principal ] Registrar todas las novedades relacionadas con los usuarios de la biblioteca. [ Flujo Excepcional ] El Bibliotecario no cuenta con el nivel de seguridad requerido para acceder a la informacin pertinente a los usuarios. Se le informa al Bibliotecario de dicha situacin. [ Flujo Excepcional ] El sistema no est en capacidad de iniciar este proceso al momento de ser solicitado. Debe ser requerido nuevamente por el Bibliotecario. Se le informa al Bibliotecario de dicha situacin. [ include ] Adicionar, Actualizar [ Caso Uso ] Adicionar [ Actores ] Bibliotecario, Usuario [ Flujo Principal ] Registrar ante el sistema la informacin pertinente a los nuevos usuarios de la biblioteca. Inicia cuando el usuario le solicita al Bibliotecario ser registrado como Usuario valido de la biblioteca y aporta sus datos. Termina cuando el Usuario es registrado en el sistema apropiadamente. [ Flujo Excepcional ] El usuario no cumple con los requisitos mnimos para ser un Usuario valido de la biblioteca. El Bibliotecario informa al usuario de tal situacin.

99

[ Caso Uso ] Actualizar [ Actores ] Bibliotecario, Usuario [ Flujo Principal ] Registrar ante el sistema los cambios en los datos personales aportados por un determinado Usuario de la biblioteca. Se inicia cuando el Usuario manifiesta las novedades en sus datos al Bibliotecario. Termina cuando al sistema se ingresan los nuevos datos del Usuario.

"Manejo Libros" [ Caso Uso ] Reporte Libros [ Actores ] Bibliotecario [ Flujo Principal ] Reportes sobre la totalidad de los libros que posee la biblioteca discriminados por materia, genero, editorial o algn otro conjunto de parmetros propio de los libros y definidos por el Bibliotecario. Se ejecuta mnimo una vez al mes. [ Flujo Excepcional ] El sistema no est en capacidad de iniciar la elaboracin de este reporte al momento de ser solicitado. Lo pospone para cuando sea posible. [ Flujo Excepcional ] El bibliotecario no cuenta con el nivel de seguridad necesario para solicitar este tipo de reporte. Se le informa al bibliotecario de dicha situacin.

[ Caso Uso ] Estado Libros [ Actores ] Bibliotecario [ Flujo Principal ] Reportes sobre los libros clasificados segn los diferentes estados contemplados por la biblioteca. Se puede ejecutar cuando el Bibliotecario lo desee. [ Flujo Excepcional ] El Bibliotecario no cuenta con el nivel de seguridad necesario para solicitar este tipo de reporte. Se le informa al Bibliotecario de dicha situacin. [ Flujo Excepcional ] El sistema no est en capacidad de iniciar la elaboracin de este reporte al momento de ser solicitado. Debe ser solicitado nuevamente por el bibliotecario. Se le informa al bibliotecario de dicha situacin. 100

[ Caso Uso ] Movimiento Libros [ Actores ] Bibliotecario, Usuario [ Flujo Principal ] Registrar todas las novedades relacionadas con los libros de la biblioteca. Se inicia con la interaccin del Usuario y Bibliotecario. [ include ] Consultas, Prestamos, Reservas, Adicionar, Devoluciones [ Caso Uso ] Consultas [ Actores ] Usuario, Bibliotecario [ Flujo Principal ] Desea saber que libros y el estado de los mismos, posee la biblioteca sobre un tema, materia o algn conjunto de parmetros por quien desee levar a cabo la operacin. La inicia el Usuario o el Bibliotecario. Termina cuando se han desplegado los libros segn los criterios de bsqueda. [ Flujo Excepcional ] El sistema no est en capacidad de llevar a cabo este proceso al momento de ser solicitado. Debe ser solicitado nuevamente por el usuario. Se le informa al Bibliotecario responsable dicha situacin.

[ Caso Uso ] Prestamos [ Actores ] Usuario, Bibliotecario [ Flujo Principal ] Desea registrar en el sistema que un determinado Usuario tiene en su poder un libro de la biblioteca. La inicia el Usuario suministrando los datos pertinentes para que el Bibliotecario pueda entregar el libro a quien lo solicita. Termina cuando se ha registrado la accin en el sistema y se ha entregado el libro al Usuario. [ Flujo Excepcional ] El Usuario no cumple con las condiciones estipuladas para prestar libros. [ Flujo Excepcional ] El sistema no est en capacidad de llevar a cabo este proceso al momento de ser solicitado. Debe ser solicitado nuevamente por el usuario. Se le informa al Bibliotecario responsable dicha situacin.

101

[ Caso Uso ] Renovaciones [ extend ] Prestamos [ Actores ] Usuario, Bibliotecario [ Flujo Principal ] Desea registrar en el sistema que un determinado Usuario quiere extender el periodo de prstamo de un libro en su poder. La inicia el Usuario suministrando los datos pertinentes para que el Bibliotecario pueda actualizar el prstamo del libro a quien lo solicita. Termina cuando se ha registrado la accin en el sistema. Punto de extensin: nueva fecha de devolucin del libro. [ Flujo Excepcional ] El Usuario o el periodo del prstamo o no cumple con las condiciones para ser extendido. [ Flujo Excepcional ] El sistema no est en capacidad de llevar a cabo este proceso al momento de ser solicitado. Debe ser solicitado nuevamente por el Usuario. Se le informa al Bibliotecario dicha situacin.

[ Caso Uso ] Reservas [ Actores ] Usuario, Bibliotecario [ Flujo Principal ] Registrar en el sistema que un determinado Usuario est esperando por un libro que en el momento no se encuentra disponible. La inicia el Usuario suministrando los datos pertinentes para que el Bibliotecario pueda contactar a quien lo solicita cuando el libro se encuentre disponible. Termina cuando se ha registrado la accin en el sistema. [ Flujo Excepcional ] El sistema no est en capacidad de llevar a cabo este proceso al momento de ser solicitado. Debe ser solicitado nuevamente por el usuario. Se le informa al Bibliotecario responsable dicha situacin.

[ Caso Uso ] Devoluciones [ Actores ] Usuario, Bibliotecario [ Flujo Principal ] Registrar en el sistema que un determinado Usuario ha devuelto un libro a la biblioteca. Determina si el prstamo se ha cumplido dentro de los plazos establecidos. Lo inicia el Usuario suministrando al 102

Bibliotecario el libro que se encontraba en su poder. Termina cuando se ha registrado la accin en el sistema, y el libro se encuentra nuevamente en su ubicacin fsica correspondiente. [ Flujo Excepcional ] El sistema no est en capacidad de llevar a cabo este proceso al momento de ser solicitado. Debe ser solicitado nuevamente por el usuario. Se le informa al Bibliotecario responsable dicha situacin.

103

Circulacin de Libros en una biblioteca A continuacin se presentan algunos Diagramas UML que modelizan la circulacin de libros en una biblioteca. Tarea: Complete los diagramas que representen los aspectos no cubiertos del modelo o los que usted considere se puedan mejorar.

Diagrama de Casos de Uso (Contexto)

104

105

Diagrama de Clases o Editorial

106

Autor

Libro

107

Prstamo

Usuario

108

Multas

109

Diagrama de Objeto o Editorial

Autor

Libro

110

Prstamo

Usuario

Multas

111

Diagrama de Secuencia (Prstamo de libro)

112

Diagrama de Actividades (Prstamo de libro)

113

Diagrama de Estados (Del objeto libro)

114

7.4 ARQUITECTURA DE TRES CAPAS La arquitectura tradicional de cliente/servidor tambin es conocida como arquitectura de dos capas. Requiere una interfaz de usuario que se instala y corre en una PC o estacin de trabajo; y que enva solicitudes a un servidor para ejecutar operaciones complejas. Por ejemplo, una estacin de trabajo utilizada como cliente puede correr una aplicacin de interfaz de usuario que interroga a un servidor central de bases de datos. La arquitectura de tres capas se refiere a un diseo reciente que introduce una capa intermedia al proceso. Cada capa es un proceso separado y bien definido corriendo en plataformas separadas. En la arquitectura tradicional de tres capas se instala una interfaz de usuario en la computadora del usuario final (el cliente). La arquitectura basada en WEB transforma la interfaz de bsqueda existente (el explorador de WEB), en la interfaz del usuario final. La tercera capa generalmente es el sistema de administracin de la base de datos. Es decir donde los datos requeridos por la capa intermedia son almacenados. La tercera capa se localiza en un servidor separado conocido como el servidor de base de datos. El servidor de aplicaciones fue introducido como parte del diseo de tres capas. Es relativamente nuevo y an no bien definido. Las empresas del mundo entero estn esforzndose para producir su propia versin de lo que creen que es un servidor de aplicaciones. Martin Marshall, de Zona Research, sugiere que hay confusin en el trmino servidor de aplicaciones. La definicin ms comn de un servidor de aplicaciones es la de software corriendo en una capa intermedia entre un cliente pequeo basado en un explorador y una base de datos. Generalmente se acepta que un servidor de aplicaciones maneja todas las transacciones lgicas y de conectividad que histricamente compartan el cliente y el servidor en un diseo cliente/servidor. Segn [Microsoft 1997], el diseo de software se realiza a tres niveles: conceptual, lgico y fsico.

115

Arquitectura lgica de tres capas de una aplicacin cliente/servidor En el diseo lgico conceptualmente se divide en tres niveles de servicios con el fin de que la aplicacin resulte flexible ante los cambios de requerimientos y/o de tecnologa cambiando nicamente la capa o capas necesarias. Los tres niveles son: servicios de usuario, servicios de negocio y servicios de datos. Los servicios de usuario (user services) controlan la interaccin. Un servicio de usuario son personas, aplicaciones, otros servicios o la combinacin de stos. Generalmente involucra una interfase grfica de usuario (GUI) o pude ser no visual (mensajes o funciones), maneja todos los aspectos de la interaccin con la aplicacin. El objetivo central es minimizar el esfuerzo de conocimiento requerido para interpretar la informacin. Un servicio de usuario incluye un contenido (qu se necesita comunicar al usuario) y una forma (cmo se comunica el contenido) cuando es necesaria la comunicacin. Los servicios de negocio (bussines services) convierten datos recibidos de los servicios de datos y de usuario en informacin (datos + regla de negocio) y pueden usar otros servicios de negocio para completar su tarea. Las tareas de los servicios de negocio son:

Dar formato a los datos Obtener y mover datos desde y hasta los servicios de datos Transformar los datos en informacin Validar los datos inmediatamente en el contexto o en forma diferida una vez terminada la transaccin.

Los servicios de datos (data services) son los servicios de bajo nivel que apoyan los servicios de negocio y son de una amplia gama de categoras como las siguientes:

116

Declaracin del esquema y su evolucin (estructuras de datos, tipos, acceso indexado, SQL, APIs) Respaldo y recuperacin (recuperacin de datos si un evento falla) Bsqueda y Lectura (bsquedas, compilacin, optimizacin y ejecucin de solicitudes, formacin de un conjunto de resultados) Insercin, actualizacin y borrado (procesar modificaciones consistentemente transaccional). Una transaccin es atmica (ocurre o no), consistente (preserva integridad), aislada (otras transacciones ocurren antes o despus) y durable (una vez completada, sta sobrevive). Bloqueo (permite al acceso concurrente a los datos) Validacin de datos (verifica la integridad del dominio, triggers y gateways para verificar el estado de los datos antes de aceptarlos, manejo de errores) Seguridad (acceso seguro a los objetos, operaciones, permisos a usuario y grupos y servicios) Administracin de la conexin (mecanismos bsicos para establecer una sesin de los servicios de datos). Establecer una conexin involucra: una identificacin, la colocacin y provisin de datos, tiempo de sesin, el tipo de interaccin (conversacional, transaccional, multiusuario, monousuario). Distribucin de datos (Distribuye informacin, a mltiples unidades de recuperacin, bases de datos heterogneas, segn la topologas de la red).

El diseo fsico traduce el diseo lgico en una solucin implementable y costo-efectiva o econmica. El componente es la unidad de construccin elemental del diseo fsico. Las caractersticas de un componente son:

Se define segn cmo interacta con otros Encapsula sus funciones y sus datos Es reusable a travs de las aplicaciones Puede verse como una caja negra Puede contener otros componentes

En el diseo fsico se debe cuidar el nivel de granularidad (un componente puede ser tan grande o tan pequeo segn su funcionalidad, es decir, del tamao tal que pueda proveer de una funcionalidad compleja pero de control genrico) y la agregacin y contencin (un componente puede reusar utilizando tcnicas de agregacin y contencin, sin duplicar cdigo). El diseo fsico debe involucrar:

El diseo para distribucin debe minimizarse la cantidad de datos que pasan como parmetros entre los componentes y stos deben enviarse de manera segura por la red.

117

El diseo para multitarea debe disearse en trminos de la administracin concurrente de dos o ms tareas distintas por una computadora y el multithreading o mltiples hilos de un mismo proceso) El diseo para uso concurrente el desempeo de un componente remoto depende de si est corriendo mientras recibe una solicitud. El diseo con el manejo de errores y prueba de eventos: o Validando los parmetros- a la entrada antes de continuar con cualquier proceso. o Protegiendo recursos crticos manejar excepciones para evitar la falla o terminacin sin cerrar archivos, liberar objetos sincronizados o memoria. o Protegiendo datos importantes contar con una excepcin a la mitad de la actuacin en las bases de datos. o Debugging crear una versin para limpiar errores. o Proteccin integral de transacciones de negocios los errores deben regresarse al componente que llama.

Arquitectura fsica de tres capas de la aplicacin cliente/servidor El diseo fsico comprende las siguientes tareas:

Definir los componentes Refinar el empaquetamiento y distribucin de componentes Especificar las interfases de los componentes Distribuir los componentes en la red 118

Distribuir los repositorios fsicos de datos Examinar la tolerancia a fallas y la recuperacin de errores Validar el diseo fsico

De las tareas anteriores la ms importante es la distribucin de los datos que pueden ser centralizados, una particin, un extracto o una rplica. Los datos centralizados equivalen a una base de datos maestra ubicada en un lugar central. No hay copias de los datos. Una particin de datos es una segmentacin de la base de datos maestra. Es til cuando los datos se pueden fragmentar fcilmente y actualizarse en un sitio local con cambios frecuentes. No hay sobreposicin entre particiones. En una particin horizontal cada hilera existe en una sola base de datos. En una particin vertical cada columna es contenida en una y solo una base de datos. Un extracto de datos es una copia de toda o una porcin de la base de datos maestra. No se permite la actualizacin. Se usa un timestamp o etiqueta de tiempo para indicar qu tan viejos son los datos. Una rplica de datos es un fragmento de la bases de datos maestra que se puede actualizar. Una rplica de datos es cuando el sitio de actualizacin cambia a un sitio local. No se permiten actualizaciones en la base de datos rplica y en la base de datos maestra a la vez, por lo que debe de haber sincronizacin entre ambas. El diseo fsico est ntimamente ligado a una alternativa tecnolgica. Ante la acelerada evolucin tecnolgica es importante considerar los estndares del momento y las tendencias ya que una mala decisin implicar un costo enorme (en dinero y en tiempo) al actualizarse a otra plataforma distinta. La tendencia actual en la arquitectura cliente/servidor es crear el back-end como un servidor robusto multitareas y multithreading y el front-end como un cliente muy delgado que no acapare al servidor comunicndose entre s en una plataforma internet con protocolos estndar en redes heterogneas.

119

factura.ex matricula. asignatura Sistema usuario asignatu persona Asignatu Estudian Profesor oferta e exe de s.dll ra.dll te asignatu ra facturaci ras n

BIBLIOGRAFA

VAR JACOBSON, GRADY BOOCH, JAMES RUMBAUGH GRADY BOOCH

El lenguaje Unificado de Modelado. Addision Wesly Longman,Inc. (1999). Anlisis y Diseo Orientado a Objetos con Aplicaciones. 2 Edicin Addison-. Wesley/Daz de Santos (1996). Anlisis y Diseo de Orientado a Objetos. Prentice Hall, (1993). Mtodos Orientados a Objetos: Conceptos Fundamentales. (1997), Prentice hall Modelado y Diseo Orientados a Objetos, Metodologa OMT

JAMES MARTIN

JAMES MARTIN & JAMES ODELL

JAMES RUMBAUGH Y OTROS

EJERCICIOS

1. Elaborar un programa que haga uso de una clase para conocer el rea y la longitud de un crculo. #include<iostream.h> class ALCirculo { private: double radio,area,longitud; public: void iniciar(void); void entradaDatos(void); void salidaDatos(void); }; void ALCirculo::iniciar(void) { cout <<"PROGRAMA QUE CALCULA EL AREA Y LONGITUD DE UNA CIRCUNFERENCIA"<<"\n\n"; 120

} void ALCirculo::entradaDatos(void) { const double pi=3.141516; cout<<"INTRODUZCA EL RADIO DE LA CIRCUNFERENCIA"<<"\n"; cin>>radio; area=pi*radio*radio; longitud=2*pi*radio; } void ALCirculo::salidaDatos(void) { cout<<"AREA =\t\t" <<area <<"\n"; cout<<"LONGITUD =\t\t" <<longitud <<"\n\n"; }

int main(void) { ALCirculo ALCirculo1; ALCirculo1.iniciar(); ALCirculo1.entradaDatos(); ALCirculo1.salidaDatos(); system("PAUSE"); return 0; }

2. zxfb0060037cbvx 3. xb

121