Ejemplos de Diagramas UML 2014

Uni

vers

idad

de

Cas

tilla

-La

Man

cha

Ingeniera del Software de Gestin

(I.T.I Gestin / I.T.I Sistemas)

MODELADO DE APLICACIONESCON UML

PROFESORESJose Eduardo CrcolesMara Dolores Lozano

Cuaderno de Prcticas

TEMA 1. INTRODUCCIN A LASHERRAMIENTAS CASE 4

1.1 HERRAMIENTAS CASE............................................................................................................ 41.2 INGENIERA DE SOFTWARE Y HERRAMIENTAS CASE ................................................................ 5

1.2.1 Metodologas Estructuradas ............................................................................................ 71.2.2 Metodologas Orientadas a Objeto................................................................................... 7

1.3 EVOLUCIN DE LAS HERRAMIENTAS CASE.............................................................................. 71.3.1 Expectativas del uso de un CASE ..................................................................................... 8

TEMA 2. UNIFIED MODELINGLANGUAGE (UML) 10

2.1 INTRODUCCIN ..................................................................................................................... 102.2 PAUTAS GENERALES PARA DESARROLLAR USANDO UML ....................................................... 11

2.2.1 Paquetes y dependencia ................................................................................................. 112.2.2 Diagrama de Casos de Uso............................................................................................ 122.2.3 Diagrama de Secuencia y diagrama de Colaboracin .................................................... 152.2.4 Diagrama de Objetos y diagrama de Clases................................................................... 172.2.5 Diagrama de Estados..................................................................................................... 202.2.6 Diagrama de Componentes............................................................................................ 212.2.7 Diagrama de Despliegue ............................................................................................... 22

TEMA 3. DIAGRAMAS DE UML ENRATIONAL ROSE. GUA DE

PRCTICAS 233.1 INTRODUCCIN ..................................................................................................................... 233.2 ACTIVIDAD 1 ........................................................................................................................ 233.3 ACTIVIDAD 2 ........................................................................................................................ 253.4 ACTIVIDAD 3 ........................................................................................................................ 263.5 ACTIVIDAD 4 ........................................................................................................................ 273.6 ACTIVIDAD 5 ........................................................................................................................ 283.7 ACTIVIDAD 6 ........................................................................................................................ 293.8 ACTIVIDAD 7 ........................................................................................................................ 293.9 ACTIVIDAD 8 ........................................................................................................................ 303.10 ACTIVIDAD 9 ...................................................................................................................... 323.11 ACTIVIDAD 10 .................................................................................................................... 333.12 ACTIVIDAD 11 .................................................................................................................... 343.13 ACTIVIDAD 12 .................................................................................................................... 37

TEMA 4. ACTIVIDADES PARADESARROLLO DE LA PRCTICA 40

4.1 INTRODUCCIN ..................................................................................................................... 40

TEMA 5. CASOS DE USO.EJERCICIOS RESUELTOS 42

EJERCICIO 1. GESTIN DE FINCAS E INMUEBLES ........................................................................... 42Enunciado.............................................................................................................................. 42Solucin:................................................................................................................................ 44

EJERCICIO 2. GESTIN CALIFICACIONES ENUNCIADO: ............................................................... 47Enunciado.............................................................................................................................. 47Solucin................................................................................................................................. 49

EJERCICIO 3. PUNTOS DE INFORMACIN UNIVERSITARIA ............................................................ 52Enunciado.............................................................................................................................. 52Solucin................................................................................................................................. 54

TEMA 6. DIAGRAMA DE CLASES.EJERCICIOS RESUELTOS 58

EJERCICIO 1. ANIMALES DE LA CASA......................................................................................... 58Enunciado.............................................................................................................................. 58Solucin................................................................................................................................. 58

EJERCICIO 2. RESERVA DE VUELOS ........................................................................................... 59Enunciado.............................................................................................................................. 59Solucin................................................................................................................................. 61

EJERCICIO 3. RESTAURANTE ..................................................................................................... 68Enunciado.............................................................................................................................. 68Solucin................................................................................................................................. 72

EJERCICIO 4. PARQUE DE ATRACCIONES .................................................................................... 76Enunciado.............................................................................................................................. 76Solucin................................................................................................................................. 78

TEMA 7. DIAGRAMAS DEINTERACCIN. EJERCICIOS

RESUELTOS 82EJERCICIO 1. GESTIN DE DIETAS ............................................................................................. 82

Enunciado.............................................................................................................................. 82Solucin................................................................................................................................. 83

EJERCICIO 2. CONTROL DE TRFICO EN UN CRUCE REGULADO POR SEMFORO ............................ 85Enunciado.............................................................................................................................. 85Solucin................................................................................................................................. 87

TEMA 8. DIAGRAMA DE ESTADOS.EJERCICIOS RESUELTOS 89

Enunciado.............................................................................................................................. 89Solucin................................................................................................................................. 90

EJERCICIO 2. GESTIN DE UN RESTAURANTE ............................................................................. 91Enunciado.............................................................................................................................. 91

EJERCICIO 4. VENTA DE PRODUCTOS POR INTERNET .................................................................. 94Enunciado.............................................................................................................................. 94Solucin................................................................................................................................. 95

Tema 1. Introduccin a las HerramientasCASE

1.1 Herramientas CASE

CASE es un acrnimo para Computer-Aided Software Engineering, aunque existenalgunas variaciones para lo que actualmente se entiende por CASE, tal como seilustra en la Tabla 1.1.

C Computer

A Aided

Assisted

Automated

S Software

Systems

E Engineering

Tabla 1.1 Variaciones del acrnimo CASE

Esencialmente, un CASE es una herramienta que ayuda al ingeniero de software adesarrollar y mantener software. A continuacin se presentan algunas definicionesdadas para el trmino CASE.

En Terminology for Software Engineering and Computer-aided SoftwareEngineering by B.Terry & D.Logee, Software Engineering Notes, Abril 1990,CASE es definido como:

Herramientas individuales para ayudar al desarrollador desoftware o administrador de proyecto durante una o msfases del desarrollo de software (o mantenimiento).

En The CASE Experience, Carma McClure, BYTE Abril 1989 p.235 se ofrece lasiguiente definicin:

Una combinacin de herramientas de software ymetodologas de desarrollo

La pieza fundamental, y ms importante avance tecnolgico asociado a unaherramienta CASE, es su repositorio integrado. En el repositorio se almacena toda lainformacin de uno o varios sistemas de informacin, por ejemplo, datos acerca de:

? El dominio (problema) de los sistemas desarrollados o en desarrollo

? Modelos de solucin e implementacin

? Informacin de la metodologa que est siendo usada

? Historia de los proyectos, recursos, presupuestos, etc.

? Contexto organizacional: organigramas, planes estratgicos, factores crticos dexito, etc.

Cada tem en el repositorio es descrito en detalle. Atributos tpicos podran ser:identificacin, definicin (significado), tipo, alias, tems componentes, tems padres,reglas de uso, quin y cundo lo cre, quin y cundo lo actualiz por ltima vez,quines pueden actualizarlo y/o consultarlo, cul es su estado (por ejemplo:incompleto, completo etc.), nmero de versin, dnde est almacenado fsicamente.

1.2 Ingeniera de Software y herramientas CASELa evolucin de las herramientas CASE est ligada a la evolucin de la Ingeniera deSoftware como disciplina. El trmino Ingeniera de Software fue usado porprimera vez en una conferencia OTAN en 1968. En dicha conferencia se revel laexistencia de la llamada Crisis del Software, causada por los problemas inherentesal desarrollo de software.

El ciclo de vida del software es entendido como la secuencia de fases por las cualesatraviesa un proyecto de desarrollo de software desde su concepcin hasta el fin deluso del producto software obtenido, pasando por su construccin y mantenimiento.En el Diccionario de la Lengua Espaola una metodologa se define como:

Conjunto de mtodos que se siguen en una investigacincientfica o en una exposicin doctrinal.

y un mtodo como:

Procedimiento que se sigue en las ciencias para hallar laverdad y ensearla.

Una metodologa en Decline & Fall of the American Programmer, Edward Yourdon,Yourdon Press 1993 es definida como:

Un plan de batalla paso a paso, o libro de cocina, paraejecutar algn resultado deseado. Una metodologa desoftware usualmente identifica las principales actividades-por ejemplo, anlisis, diseo, codificacin y pruebas- a serrealizadas e indica qu personas (usuarios,administradores, tcnicos) deben estar involucrados encada actividad y qu papel desempean en ellas. Lasmetodologas a menudo describen criterios de entrada (porejemplo condiciones para comenzar una fase), criterios desalida y puntos de revisin

A veces se utiliza ciclo de vida como sinnimo de metodologa pues cadametodologa ofrece su particular visin de las fases por las cuales debe pasar unproyecto de desarrollo de software.

Un mtodo es entendido como un enfoque tcnico para ser utilizado en toda o partede una metodologa. Tanto las metodologas como los mtodos estn basados endiversas tcnicas principalmente grficas y/o textuales.

Las siguientes son algunas actividades que tpicamente incluidas en el ciclo de vidadel software: planificacin del proyecto, gestin del proyecto, anlisis, diseo,codificacin, pruebas, documentacin, mantenimiento, validacin y verificacin.

Los esfuerzos iniciales por resolver la crisis del Software se orientaron en elmbito de la codificacin, apareciendo las primeras tcnicas de programacin. Afines de los 60s y comienzos de los 70s surgieron gran cantidad de tcnicas paraprogramar y documentar programas. Un ejemplo representativo lo constituyen laProgramacin Estructurada y los Diagramas de Flujo. Sin embargo, las mejorasintroducidas al proceso de desarrollo no eran suficientes.

A fines de los 70s y comienzos de los 80s la atencin se centr en resolverproblemas de especificacin, diseo, mtricas y gestin dentro del desarrollo desoftware. Es decir, el inters fue dirigido a otras fases del desarrollo dentro del ciclode vida del software.

Actualmente la Ingeniera de Software como disciplina se ve plasmada en una granvariedad de modelos y metodologas para el desarrollo de software. Algunosmodelos para el desarrollo de software son: Desarrollo en Cascada, Desarrollo conPrototipacin, Desarrollo Incremental, Desarrollo en Espiral. Las metodologas sebasan en algn modelo o combinacin de ellos.

Actualmente existe un gran nmero de metodologas tanto comerciales como en elmbito acadmico y de investigacin. Ellas pueden ser agrupadas en tres grandescorrientes: Metodologas Estructuradas y Metodologas Orientado a Objeto.

1.2.1 Metodologas Estructuradas

Aparecieron a fines de los 60s con la Programacin Estructurada, posteriormente amediados de los 70s extendidas con el Diseo Estructurado y a fines de los 70s conel Anlisis Estructurado. Versiones ms recientes incorporan Diagramas Entidad-Relacin y Diagramas de Transicin de Estados.

Ejemplos de metodologas estructuradas promocionadas por organismosgubernamentales lo constituyen: MERISE (Francia), METRICA (Espaa), SSADM(Reino Unido).

Otras metodologas estructuradas en el mbito comercial son: Gane & Sarson, Ward& Mellor, Yourdon & DeMarco y Information Engineering. Esta ltima propuestapor James Martin pone un nfasis adicional en el modelamiento de datos y laincorporacin de los desarrollos informticos dentro del contexto su organizacional(planificacin, objetivos, etc.).

1.2.2 Metodologas Orientadas a Objeto

Su historia va unida a la evolucin de los lenguajes de programacin orientada aobjeto, los ms representativos: a fines de los 60s SIMULA, a fines de los 70sSmalltalk-80, la primera versin de C++ por Bjarne Stroustrup en 1981 yactualmente Java. Slo a fines de los 80s comenzaron a consolidarse algunasmetodologas Orientadas a Objeto.

Algunas de las ms representativas en el mbito comercial son: Booch, Coad &Yourdon, Shaler & Mellor y OMT.

1.3 Evolucin de las herramientas CASELas primeras herramientas para apoyar el proceso de desarrollo de software fueronlos editores y procesadores de texto, usados para escribir programas y sudocumentacin. As, tambin algunos programas de dibujo comenzaron a incorporarlas notaciones grficas de tcnicas para diseo de programas.

La consolidacin de metodologas de desarrollo integrando diferentes tcnicasimpuls la aparicin de paquetes de propsito ms amplio. Surgi la necesidad de undiccionario de datos del sistema que almacene las definiciones usadas en lasdiferentes fases del desarrollo (este diccionario es lo que actualmente se denominarepositorio). Esto contribuy a implementar funciones de integracin y verificacinde consistencia entre tcnicas (asociadas a distintas actividades y/o fases en eldesarrollo). La automatizacin de tareas tambin ha sido un aspecto de inters. Enprogramacin automtica esto se ha traducido en: generadores de pantallas e

informes, generadores de esquemas fsicos de bases de datos y generadores decdigo para prototipos o partes de programas.

Actualmente, en Ingeniera de Software todos los desafos y los correspondientesenfoques de solucin estn siempre concebidos y llevados a la prctica dentro delcontexto de un CASE.

1.3.1 Expectativas del uso de un CASE

El propsito de una herramienta CASE es dar soporte automatizado para laaplicacin de todas o algunas tcnicas usadas por una o varias metodologas.

Cualquier mejora orientada a resolver problemas asociados a la Crisis del Softwarese enmarca dentro de los siguientes niveles de solucin, desde el ms general al msparticular:

1. Enfrentar el proceso de desarrollo de software como un proyecto deIngeniera de Software.

2. Aplicar una o varias metodologas de forma integrada cubriendo todas lasactividades del ciclo de vida del software

3. Usar una herramienta CASE para apoyar la aplicacin de la(s)metodologa(s) utilizada(s).

Si consideramos que cada nivel debe implicar al anterior, se pone de manifiesto quela sola utilizacin de una herramienta CASE no garantiza una mejora en el procesode desarrollo de software.

Por otra parte, las metodologas incluyen gran cantidad de tcnicas, y el esfuerzo dedocumentacin (y actualizacin de dicha documentacin) es por lo generalconsiderable. Por lo tanto, es difcil aplicar una metodologa sin la ayuda de unaherramienta CASE. As, los beneficios de utilizacin de un CASE se entremezclancon los beneficios de aplicar una metodologa con xito. El valor agregado indudablede utilizar un CASE es el aumento en la productividad en las actividades soportadaspor la herramienta.

Mientras los costos del hardware han ido en continuo descenso, sucede todo locontrario con los costos del software. Las exigencias en complejidad y envergadurahan sobrepasado a las mejoras en cuanto a mtodos de desarrollo. El uso demetodologas de desarrollo junto a herramientas CASE no es una panacea, pero sinlugar a dudas ofrece la mejor alternativa actual para enfrentar proyectos dedesarrollo de software de complejidad y/o envergadura.

El nfasis en planificacin, anlisis y diseo promovido por una herramienta CASEtiene un fuerte impacto y recompensa en la mejora de la calidad del productoobtenido y en el aumento de productividad (disminucin de tiempos, costes yesfuerzos) en las actividades de desarrollo y mantenimiento.

El beneficio adicional obtenido por la utilizacin de un CASE actual (si se comparacon la utilizacin de una metodologa sin el uso de un CASE) se representa en lossiguientes aspectos:

? Facilita la verificacin y mantenimiento de la consistencia de la informacindel proyecto.

? Facilita el establecimiento de estndares en el procesos de desarrollo ydocumentacin.

? Facilita el mantenimiento del sistema y las actualizaciones de sudocumentacin.

? Facilita la aplicacin de las tcnicas de una metodologa.

? Disponibilidad de funciones automatizados tales como: obtencin deprototipos, generacin de cdigo, generacin de pantallas e informes, generacin dediseos fsicos de bases de datos, verificadores automticos de consistencia.

? Facilita la aplicacin de tcnicas de reutilizacin y reingeniera.

? Facilita la planificacin y gestin del proyecto informtico.

Tema 2. Unified Modeling Language (UML)

2.1 IntroduccinUML es una notacin estndar para desarrollo de sistemas usando el enfoqueorientado a objeto. Es una notacin en evolucin, an en desarrollo. SA en estaversin provee soporte para la especificacin 1.0 de UML.

UML comenz en 1994 como un esfuerzo de Grady Booch y James Rumbaugh paracombinar sus metodologas definiendo una notacin estndar para ellas. Despus, en1995, Ivar Jacobson (tcnica OOSE , incluyendo Casos de Uso) se uni al equipo.

Paralelamente a este esfuerzo, El Object Management Group (OMG,http://www.omg.org) hizo una llamada para propuestas de notacin y metamodeloorientado a objetos. En Enero de 1997 UML fue entregado al OMG en respuesta a suconvocatoria. Existan otras propuestas remitidas, pero al final, se form un soloequipo en torno a UML.

UML es slo una notacin, no dicta estndares para el proceso de desarrollo. Sinembargo, UML condiciona dicho proceso de desarrollo al establecer los diagramas einformacin asociada que debe representarse. Los diagramas incluidos en UML,agrupados segn su mbito de aplicacin, son:

Anlisis en el contexto organizacional

? Diagramas de Casos de Uso

Anlisis y diseo desde la perspectiva esttica

? Diagrama de Clase

? Diagrama de Objetos

Anlisis y diseo desde la perspectiva dinmica

? Diagrama de Secuencia

? Diagrama de Colaboracin

? Diagrama de estados

Implementacin

? Diagrama de Componentes

? Diagrama de Despliegue

2.2 Pautas generales para desarrollar usando UMLUML no es una metodologa, es una notacin obtenida desde experiencia en las mspopulares metodologas OO actuales. El propsito de este apartado es proveer pautasmuy generales de desarrollo, indicando como se relacionan los diagramas de UML.

Existe consenso en que el proceso de desarrollo OO es repetitivo con sucesivosrefinamientos. Los diagramas pueden representar situaciones actuales o situacionespropuestas (sistema deseado) en los diagramas de Casos de Uso, de Secuencia o deColaboracin. Al comienzo del proceso de desarrollo, cuando se realiza la captacinde requisito, suelen representarse smbolos asociados a objetos (incluso objetosfsicos, por ejemplo nombres de personas, cargos, etc.); posteriormente esasdefiniciones llegan a constituir clases de objetos. Del mismo, modo los mensajes endiagramas de Secuencia y Colaboracin dan lugar a los mtodos asociados a clasesdel sistema. Segn esto, el nivel de detalle con el cual se especifican los diagramasdepende del conocimiento que el desarrollador tiene del sistema. El proceso deaprendizaje del problema y de la determinacin de la solucin es un proceso derefinamiento sucesivo.

2.2.1 Paquetes y dependencia

En sistemas de envergadura es conveniente hacer una divisin en subsistemas. EnUML esto se representa con el concepto de package (paquete). Un paquete es unaagrupacin de elementos modelados. Los paquetes pueden estar anidados dentro deotros. Todos los tipos de elementos y diagramas pueden ser organizados en paquetes.En particular un paquete puede ser visto como un subsistema el cual es modelado enforma independiente. La relacin entre paquetes se establece mediante conexionesde dependencia. Una relacin de dependencia se simboliza por una flecha punteadadibujada desde el paquete que al menos usa un elemento de otro paquete, este ltimoes apuntado por la flecha.

El concepto de paquete permite organizar los casos de usos por subsistemas. De lamisma forma, en sistemas de tamao considerable, las clases pueden organizarse ensubsistemas.

La Figura 2.1 muestra la representacin de paquetes para un ejemplo.

Editor

Sistema Ventanas

Ncleo Windows

Ncleo Grfico

MSWindows

Ncleo Motif

Elementos

Controlador

Motif

Dominios

Figura 2.1:Paquetes.

2.2.2 Diagrama de Casos de Uso

Casos de Uso es una tcnica para capturar informacin de cmo un sistema onegocio trabaja actualmente, o de cmo se desea que trabaje. No es realmente unenfoque orientado a objeto, ms bien es un enfoque de construccin de escenarios enlos cuales se modelan los procesos del sistema. Sin embargo, constituye un buenmodo de llevar a cabo la fase de captura de requisitos del sistema al comienzo delanlisis orientado a objeto.

Tpicamente, se modela un Caso de Uso para cada escenario en el sistema o negocio.Cada Caso de Uso puede estar definido simplemente por una sentencia de texto quedescribe el escenario. Tambin se puede describir mediante una secuencia de pasosejecutados dentro del escenario o condiciones pre-post para que el escenariocomience o termine, respectivamente. Un Caso de Uso es representado por unaelipse y describe una situacin de uso del sistema interactuando con actores.

Un actor es un agente externo al sistema, alguien o algo que solicita un servicio alsistema o acta como catalizador para que ocurra algo. UML especifica que un actores una clase de objetos, no una instancia particular de una clase. Durante el anlisisdel negocio se puede construir un diagrama de Casos de Uso que represente alsistema y dibujar paquetes que representen los diferentes dominios (subsistemas) delsistema. Para cada paquete se puede crear un diagrama de Casos de Uso hijo dondese describen los casos de uso del dominio. Esto se puede repetir refinando un Casode Uso en un nuevo diagrama hijo, y as sucesivamente creando una jerarqua dediagramas de Casos de Uso.

Ventas

Supervisor

Secretaria

Vendedor

Cliente

Establecercrdito

Prepararcatlogo

Realizar venta

Verificarsituacin

Figura 2.2: Casos de Uso

Un diagrama de Casos de Uso es un grafo con actores, un conjunto de Casos de Uso,comunicaciones (participacin) entre actores y Casos de Uso, y relaciones entreCasos de Uso. La Figura 2.2 presenta un ejemplo de diagrama de Casos de Uso paraun subsistema de ventas.

La Toolbox asociada a un diagrama de Casos de Uso se muestra en laFigura de la derecha.

En el ltimo nivel cada Caso de Uso debera ser descrito en mayor detalle,mediante la especificacin de pasos asociados, condiciones pre-post osimplemente un texto. La Figura 2.3 presenta la descomposicin del caso deuso emitir orden de venta de la Figura 2.2.

VendedorCliente

Venta ofertas

Venta normal

Venta enrebajas

Figura 2.3: Casos de Uso Ventas

En el diagrama de Casos de Uso pueden establecerse tres tipos de relaciones:

a) _ se comunica con_: es una relacin entre un actor y un caso de uso.

socio Encargado

Solicitar nuevatarjeta

Realizarprstamo

tarjeta caducada

Figura 2.4: Casos de Uso Prestamo.

b) _ extiende_: es una relacin entre un caso de uso y otro. Si al caso de uso Aextiende al caso de uso B, significa que una instancia del caso de uso B puede incluir(sujeto a ciertas condiciones especificadas en la extensin) el comportamientodescrito en el caso de uso A. Es decir, los pasos del caso de uso A son una extensina los del caso de uso B. Despus de realizados los pasos de A se contina en el pasosiguiente en B. La Figura 2.4 muestra un Caso de Uso solicitar nueva tarjeta, queextiende al Caso de Uso prstamo de libros.

c) _ usa _: es una relacin entre casos de uso que indica que un caso de uso usafunciones provistas por otro. La relacin se representa por una lnea desde el caso deuso que utiliza los servicios de otro. Si el caso de uso A usa el caso de uso B,

significa que una instancia del caso de uso A incluye tambin parte delcomportamiento especificado por B. En el ejemplo de la Figura 2.5 los casos de usoReintegro desde cuenta corriente y Reintegro desde cuenta de ahorro usan elcaso de uso Verificar Saldo.

Cliente

Validaroperacin

Reintegrocuenta crdito

Reintegrocuenta corriente

Figura 2.5: Casos de Uso Reintegro.

Las relaciones usa y extiende permiten evitar redundancias en la descripcin de loscasos de uso.

2.2.3 Diagrama de Secuencia y diagrama de Colaboracin

El diagrama de Secuencia y el diagrama de Colaboracin son realizados al mismotiempo por Rational Rose y se mantienen sincronizadas sus modificaciones. Alcrear/abrir uno de ellos, automticamente se crea/abre el otro.

Los diagramas de Secuencia y de Colaboracin son usados para establecermayor detalle de un escenario del sistema, determinando los objetos ymensajes involucrados.

El diagrama de Secuencia muestra los objetos involucrados en el escenariomediante lneas verticales y punteadas, y los mensajes entre objetos comoflechas horizontales conectando lneas de pares de objetos. Los mensajesson dibujados cronolgicamente desde arriba hacia abajo. La ubicacin delos objetos es arbitraria. La Figura de la derecha muestra la Toolboxasociada a un diagrama de Secuencia.

La Figura 2.6 muestra un diagrama de Secuencia para el escenarioprstamo de libros.

PrstamoFicha LibroFicha SocioLibroEncargadoSocio

coger libro

solicitar prstamo

verificar situacin socio

situacin ok

Introducir prstamo

verificar situacin libro

situacin ok

autorizar prstamo

Figura 2.6: Diagrama de Secuencia Prestamo de Libros

El diagrama de Colaboracin es usado para modelar la interaccin entrelos objetos de un Caso de Uso. Los objetos estn conectados por enlaces(links) en los cuales se representan los mensajes enviados acompaadosde una flecha que indica su direccin. El diagrama de Colaboracinofrece una mejor visin del escenario cuando el analista est intentandocomprender la participacin de un objeto en el sistema. La Figura de laderecha muestra la Toolbox asociada a un diagrama de Colaboracin.

La Figura 2.7 muestra el diagrama de Colaboracin correspondiente aldiagrama de Secuencia de la Figura 2.6.

Ficha Socio

Ficha Libro

Encargado

Prstamo

Socio

Libro

8: autorizar prstamo

2: solicitar prstamo

6: situacin ok

5: verificar situacin libro

7: Introducir prstamo

4: situacin ok

3: verificar situacin socio

1: coger libro

Figura 2.7: Diagrama de Colaboracin

Inicialmente el anlisis pone nombre a los mensajes utilizando el nombre usado en elcontexto del negocio. Ms tarde, durante el diseo, los nombres de mensajescorresponden a mtodos invocados desde un objeto a otro. El mtodo invocadocorresponde a un mtodo definido para el objeto al cual apunta la flecha del mensaje.

2.2.4 Diagrama de Objetos y diagrama de Clases

La notacin de ambos tipos de diagramas es similar. La diferencia es el nivel deabstraccin en el cual se trabaja. Comnmente, al principio del desarrollo, cuandoan no est decidido qu elementos llegarn a ser clases, objetos o datoselementales, se puede modelar dichos elementos como objetos (instancias de algunaclase). Sin embargo, cuando se establece la solucin, todos los elementos estnclaramente diferenciados y representados en diagramas de Clases (que tambinpodran incluir representaciones para objetos, cuando slo una instancia participa enel sistema). Por lo anterior, para el soporte de UML, Rational Rose proporciona sloun tipo de diagrama, denominado Class Diagram.

El diagrama de Clases es el diagrama principal para el anlisis y diseo esttico. Undiagrama de clases presenta las clases y objetos del sistema con sus relacionesestructurales y de herencia. La definicin de clase u objeto incluye definiciones paraatributos y mtodos.

El trabajo realizado y expresado en los diagramas de Casos de Uso, diagramas deSecuencia y diagramas de Colaboracin debera aportar informacin para ladeterminacin de las clases, objetos, atributos y mtodos, es decir, la captura derequisitos. El diagrama de Clases debera permitir la especificacin en un mbito dedetalle igual o mayor al utilizado para especificar los tres diagramas anteriores. Eldiagrama de Clases es la especificacin de requisitos en su aspecto esttico.

La Figura 2.8 presenta un diagrama de Clases para un sistema de Lnea Area.

Avin de Pasajeros

Avin Comercial

Motor Vendedor

Reserva

Avin de Carga

Lnea AreaAvin Militar

VueloAvin

Piloto

{disjoint, complete}


1

1..4 1..2

*

1*

*

1

1

*

*

1

Figura 2.8: Diagrama de Clases Lnea Aerea

La Toolbox usada para construir un diagrama de Clases se muestra en laFigura de la derecha

A continuacin se presentan ejemplos de cmo pueden combinarse loselementos grficos del diagrama de Clases, explicando brevemente loscuadros de dilogo asociados.

ClasesUna clase describe un conjunto de objetos con estructura y comportamientosimilares. Una clase est definida por una serie de propiedades. Las msrelevantes son los atributos y los mtodos. Una clase es representada comoun rectngulo con cuatro compartimentos separados por lneas horizontales.En el superior, se muestra el nombre de la clase y todas las propiedadesgenerales, en el siguiente se presenta la lista de atributos de la clase, acontinuacin se muestran los mtodos.

Cada atributo o mtodo de una clase es antecedido por un indicador de visibilidad,especificado en cuadro de dilogo que define al mtodo o atributo

AsociacionesSon relaciones bidireccionales potenciales entre instancias de clases. En unaasociacin, una instancia de una clase puede estar relacionada (potencialmente) conun nmero mnimo y mximo instancias de otra clase (o de la misma clase). Estosnmeros definidos desde la perspectiva de cada una de las clases que estn asociadasse denominan cardinalidad de la asociacin. La notacin para cardinalidad de lasasociaciones y relaciones en diagramas de Clase UML es:

Uno y slo uno: 1

Cero o uno: 0..1

Uno o ms: 1..*

Cero o ms: 0..*

Entre N y M : N..M , donde N y M son nmeros naturales y M>=N.

GeneralizacinLa generalizacin/especializacin son operadores entre clases que permiten definirnuevas clases mediante el mecanismo de herencia. La herencia permite separar laespecificacin de una clase en versiones ms refinadas de ella misma. Las versionesrefinadas son llamadas subclases o clases derivadas. La clase que es refinada sedenomina superclase o clase base. Las subclases estn conectadas a las superclasesmediante el smbolo hereda desde. Mediante generalizacin/especializacin seconstruyen jerarquas de clases. La Figura 2.9 muestra un ejemplo de una jerarquade generalizacin/especializacin. En dicha figura, Empleado es una generalizacinde Administrativo, Ejecutivo y Operario. Tambin podemos decir que tantoAdministrativo como Ejecutivo y Operario son especializaciones de Empleado. Enambas visiones (generalizacin o especializacin), las subclases Administrativo,Ejecutivo y Operario heredan las propiedades de la superclase Empleado.

Empleado

Directivo Administrativo Obrero


Figura 2.9: Generalizacin

Una clase puede ser superclase de ms de una jerarqua. Para cada jerarqua puedeespecificarse un discriminador, es decir, un nombre que identifica a la jerarqua.Cada jerarqua o cada conexin de subclase puede estar etiquetada con algunarestriccin a cumplir por las instancias de la subclase.

Las siguientes son las restricciones predefinidas usadas para jerarquas:

overlapping Una objeto puede pertenecer a ms de una de las subclases.

disjoint Un objeto puede pertenecer a lo ms a una de las subclases.

complete La unin de los objetos instancias de las subclasescorresponde exactamente a los objetos instancia de la superclase.

incomplete Un objeto instancia de la superclase puede no pertenecer aninguna de las subclases declaradas.

2.2.5 Diagrama de Estados

El diagrama de estados representa el comportamiento del sistema a travsdel tiempo. Tpicamente se elabora un diagrama de Estados para cada claseque tenga un comportamiento significativo. El comportamiento esmodelado en trminos del estado en el cual se encuentra el objeto, quacciones se ejecutan en cada estado y cul es el estado al que transitadespus de un determinado evento.

Los estados representan condiciones que son vlidas en el objeto en uncierto instante. Los eventos representan la causa que origina el cambiodesde un estado a otro y estn asociados a transiciones, lneas que unen elestado inicial y el final. Las acciones ocurren cuando un objeto llega a unestado. La Figura 2.10 muestra la clase socio. A dicho smbolo se le haenlazado un diagrama hijo de tipo diagrama de Estado (por esta raznaparecen los puntos en el costado superior izquierdo). La Figura 2.11muestra dicho diagrama de Estados.

La Figura de la derecha muestra la Toolbox usada en el diagrama deEstados.

Socio

- Numero : int- Nombre : char [50]- NumeroPrestamos : int

+ Alta+ Baja+ Prestar(int CodigoLibro, date Fecha)+ Devolver(int CodigoLibro, date Fecha)

persistent

Figura 2.10: Clase Socio

Con prstamos

. NumeroPrestamos

Sin prestamos

. NumeroPrestamos

Devolver[NumeroPrestamos > 1]

Devolver[NumeroPrestamos = 1]Prestar

Baja

Prestar

Alta

Figura 2.11: Diagrama de Estados Libro

2.2.6 Diagrama de Componentes

Un diagrama de Componentes permite modelar la estructura del software,incluyendo dependencias entre componentes en cdigo fuente, componentes encdigo binario y componentes ejecutables. El diagrama de componentes establecerelaciones de dependencia entre componentes y/o paquetes de componentes. LaFigura 2.12 muestra un diagrama de Componentes.

Un componente es un grupo de clases que trabajan estrechamente. Los componentespueden clasificarse por tipos. Algunos slo existen en tiempo de compilacin; otrosslo en tiempo de enlace; otros en tiempo de ejecucin y otros en varios de esosmomentos.

Una dependencia indica que un elemento del modelo (fuente) depende de otro(objetivo), de manera que un cambio en el elemento objetivo puede significarcambiar el elemento fuente.

Control y Anlisis

Comment

Acceso a BD

CommentRutinas de Coneccion

Comment

Interfaz de Terminal

Comment

Gestin de Cuentas

Comment

Figura 2.12: Diagrama de Componentes

2.2.7 Diagrama de Despliegue

El diagrama de Despliegue modela la distribucin en tiempo de ejecucin de loselementos de procesamiento y componentes de software, procesos y objetosasociados. En el diagrama de Despliegue se modelan los nodos y la comunicacinentre ellos. Cada nodo puede contener instancias de componentes. La Figura 2.13presenta un ejemplo de diagrama de Despliegue.

Punto de Venta

Servidor Central

Terminal de Consulta

Gestin de Cuentas

Comment


Comment

Rutinas de ConeccionComment

Rutinas de Coneccion

Comment


Comment

Rutinas de Coneccion

Comment

Acceso a BD

Comment

Control y Anlisis

Comment

Figura 2.13: Diagrama de Despliegue

Tema 3. Diagramas de UML en Rational Rose.Gua de Prcticas

3.1 IntroduccinEn este tema se detallan una serie de actividades que sirven como prctica inicialpara el manejo de Rational Rose. El objetivo fundamental es familiarizarse con elentorno de trabajo al mismo tiempo que se empieza a tomar un primer contacto conla sintaxis y semntica de los diagramas UML.

Nuestro agradecimiento a Patricio.Letelier (www.dsic.upv.es/~uml), profesor de laUniversidad Politcnica de Valencia por compartir este trabajo.

3.2 Actividad 1Con el botn derecho del ratn y estando en el navegador sobre el paquete de laVista de Casos de Uso, haga new-package y cree un paquete que se llameActividad 1.

Estando sobre el paquete recin creado haga click con el botn derecho y cree dosnuevos paquetes que se llaman Ventanas y Editor, estos se crearn como paquetesdentro del paquete Actividad 1.

Repita la operacin anterior y cree los subpaquetes Motif y MSWindows comosubpaquetes de Ventanas y Controlador, Dominio, Elementos, Ncleo Motif,Ncleo Windows como subpaquetes de Editor.

Sobre el paquete Actividad 1 realice new-Use Case Diagram, creando el diagramaActividad 1. Haga doble click en el icono del diagrama e introduzca el diagramamostrado en la Figura 3.1. Para ello arrastre desde el navegador los paquetesinvolucrados.

Repita el paso anterior para los paquetes Ventanas y Editor obteniendo losdiagramas mostrados en las Figuras 3.2 y 3.3, respectivamente. En cada oportunidadarrastre desde el navegador los paquetes indicados.

Consejo: Cuando quiera asociar un nuevo diagrama a un paquete basta con hacerdoble clic sobre l y luego renombrar el diagrama obtenido (por defecto se denominaMain).

Consejo: Utilice los botones para ir al diagrama padre o al diagramaanterior, respectivamente.

Editor Ventanas

Figura 3.1: Diagrama Actividad 1

MSWindows

Motif

Figura 3.2: Diagrama Ventanas

Controlador

Dominio

Elementos

Ncleo Moti f

Ncleo Windows

MSWindow

(from Ventanas)

Moti f

(from Ventanas)

Figura 3.3 Diagrama Editor

3.3 Actividad 2Estando en el navegador sobre el paquete de la Vista de Casos de Uso, con el botnderecho del ratn haga new-package y cree un paquete que se llame Actividad 2.

Con el botn derecho del ratn y estando en el navegador sobre el paquete recincreado haga new-Use Case Diagram y cree un diagrama que se llame Actividad 2.

Dibuje en el diagrama Actividad 2 lo mostrado en la figura 3.3.

Verificar Operacin

Reintegro Cuenta Corriente

Cliente

Reintegro Cuenta de Crdito


Observaciones:

Los estereotipos se introducen en la especificacin del smbolo de generalizacin(hacer doble clic sobre el smbolo para abrir su especificacin)

La opcin Navigable establece la direccin en una asociacin (puede habilitarse odeshabilitarse con el botn derecho sobre el smbolo)

3.4 Actividad 3Estando en el navegador sobre el paquete de la Vista de Casos de Uso, con el botnderecho del ratn haga new-package y cree un paquete que se llame Actividad 3.

En el paquete recin haga new-Use Case Diagram y cree un diagrama que se llameActividad 3. Dibuje en el diagrama Actividad 3 lo mostrado en la figura 3.4.

Cliente Reintegro


Observacin: Puede arrastrar el actor Cliente desde el paquete Actividad 2.

Con el botn derecho del ratn y estando en el navegador sobre el Caso de UsoReintegro haga new-Sequence Diagram y cree un diagrama que se llameReintegro Saldo Insuficiente.

Haga doble clic en el diagrama Reintegro Saldo Insuficiente y dibuje el diagramamostrado en la Figura 3.5

: Cliente :Cajero automtico:cuenta

tarjeta

solicitar nmero secreto

nmero

solicitar cantidad

realizar transaccin(cantidad)

saldo insuficiente

saldo insuficiente

cantidad

Figura 3.5: Diagrama Reintegro Saldo Insuficiente

Haga Browse-Create Collaboration Diagram para obtener automticamente elDiagrama de Colaboracin asociado.

3.5 Actividad 4Crear el paquete Actividad 4 en la Vista Lgica.

Dentro de este paquete crear las clases: avin, motor, avin militar, avincomercial, vuelo, piloto, reserva, lnea area, avin de carga, avin de pasajeros,vendedor de billetes.

Cree dentro de la Actividad 4 el Diagrama de Clases Actividad 4, mostrado de laFigura 3.6.

Avin militar Avin comercial

Avin de carga Avin de pasajeros

Motor Vendedor de billetes

Avin

1..4

1

1..4

1

Piloto

Reserva

n

1

n

1

Lnea area

Vuelon1 n1

1..2

n

1..2

nn1 n1

1

n

1

n{ disjunta, completa }

{ disjunta, completa }


3.6 Actividad 5En la Vista Lgica cree el paquete Actividad 5. Dentro de este paquete cree unDiagrama de Clases que se llame Actividad 5.

Incluya una nica clase dentro de este diagrama que se llame Alumno y completesegn lo mostrado en la Figura 3.7.

AlumnoDNI : char[10]nmero_exp : intnombre : char[50]

alta()poner_nota(asignatura : char *, ao : int, nota : float)matricular(cursos : asignatura, ao : int)listar_expediente()


Observacin: Pregunte al profesor si no consigue obtener la presentacin mostradaen la Figura 3.7.

3.7 Actividad 6En la Vista Lgica cree un paquete denominado Actividad 6.

Asociado al paquete Actividad 6 cree el Diagrama de Clases Actividad 6 e insertelas clases Departamento y Profesor y ascielas tal como se muestra en la Figura3.8.

Modifique la visibilidad de los roles eligiendo entre Pblico (+): el rol es visiblefuera del mbito del paquete y puede referenciarse en otras partes del modelo;Implementacin (sin smbolo asociado): visible slo en el paquete en el que sedefine; Protected (#): accesible a la clase misma, a las subclases o friends; Private(-): accesible solo a la propia clase o friends.

ProfesorDepartamento

10..1director

1dirige0..1

0..*rea_conocimiento : char *

1 profesores0..*

depto1

rea_conocimiento : char *


3.8 Actividad 7Cree el paquete Actividad 7 y dentro de l introduzca el diagrama de clasesActividad 7 con las clases Empresa, Empleado y Cargo. Defina en la clase Cargolos atributos Nombre y Sueldo.

Establezca la asociacin entre Empresa y Empledo, mostrada en la figura 3.9.

Empresa Empleado

1..** 1..**

trabajadoresempleador

Cargonombresueldo 0..1

1..*

superior

subordinado 1..*

0..1


Observacin: Use el smbolo de la barra de herramientas denominado LinkAttribute para enlazar la clase Cargo con la asociacin entre Empresa yEmpleado.

3.9 Actividad 8Cree el paquete Actividad 8.

Cree en el navegador las clases: Trabajador, Directivo, Administrativo, Obrero,Vehculo, Vehculo impulsado por viento, Vehculo Terrestre, Vehculoimpulsado por motor, Vehculo acutico, Camin, Velero, Cuenta, Cuentarentable y Cuenta no rentable.

Cree el Diagrama de Clases llamado Actividad 8.1 segn se muestra en la Figura3.10.

Repita la operacin para las Figuras 3.11 y 3.12.

Trabajador

Directivo Administrativo Obrero

{ disjunta, completa }

Figura 3.10: Diagrama Actividad 8.1

Vehculo

Vehculo impulsado por viento Vehculo impulsado por motor

VehculoTerrestreVehculo acutico

Velero

Camin

impulsado por

medio


Cuenta

Cuenta rentable Cuenta no rentable

{ disjunta, incompleta }

saldo_medio > 1000 saldo_medio < 500

saldo


3.10 Actividad 9Cree el paquete Actividad 9.

Cree en este paquete la clase Socio en un Diagrama de Clases que se llameActividad 9. La Figura 3.13 da el detalle de la estructura de la clase.

Asocie a la clase anterior el Diagrama de Transicin de Estados de la Figura 3.14.Para ello, desde el navegador seleccionando la clase en cuestin y con el botnderecho del ratn escoja la opcin Open State Diagram.

Socionmero : intnombre : char[50]nmero_prestamos : int = 0

alta()baja()prestar(cdigo_libro : int, fecha : date)devolver(cdigo_libro : int, fecha : date)


con prstamos

sin prstamos

prestar devolver[ nmero_prstamos = 1 ]

prestar

devolver[ nmero_prstamos > 1 ]

alta baja

nmero_prstamos = 0

nmero_prstamos > 0

Figura 3.14: Diagrama de Estados

3.11 Actividad 10Cree en la Vista de Componentes un paquete que se llame Actividad 10 y dibuje eldiagrama que se muestra en la Figura 3.15. Una relacin de dependencia entrecomponentes viene dado porque un componente usa las facilidades de otro. Esto sereduce a dependencias de compilacin entre componentes. Consulte en el Help losestereotipos para los componentes.

Dibuje el Diagrama de Despliegue de la Figura 3.16. Una Connection representap.e. un cable RS232, comunicacin va satlite, etc. Un Processor representahardware con capacidad de computacin. Un Device incluye dispositivos hardwarecomo terminales, modems, etc.

Interfaz de Terminal Control y

Anlisis

Gestin de Cuentas

Rut inas de Conexin

Acceso a DB

Figura 3.15: Diagrama de Componentes

Punto de Venta

Servidor Central Gestor de Datos

Terminal de Venta

Figura 3.16: Diagrama de Despliegue

3.12 Actividad 11Cree un nuevo modelo y renombre el diagrama Main de la Vista de Casos de Usopor ACME.

Haga doble click sobre el icono del diagrama ACME y dibujando, introduzca lossubpaquetes Publicidad, Ventas, Inventario y Contabilidad. El resultado semuestra en la Figura 3.17

Publicidad Ventas

Inventario Contabilidad

Figura 3.17: Diagrama ACME

Haga doble click sobre el paquete Ventas en el Diagrama ACME e introduzca eldiagrama de casos de uso mostrado en la Figura 3.18.

Con el botn derecho sobre el diagrama llamado Main bajo el paquete Ventasrenmbrelo por Ventas.

Asociado al paquete Realizar Venta crear un diagrama de casos de uso llamadoRealizar Venta. Hacer doble click sobre el icono que representa el paquete RealizarVenta e introduzca el diagrama mostrado en la Figura 3.19

Renombre como Realizar Venta el diagrama Main bajo el paquete Realizar Venta.El resultado hasta este punto puede verse en la Figura 3.20.

Supervisor Verificar Situacin del Cliente

Administrativo Sistema Inventario

Preparar Catlogo

Realizar Venta

Figura 3.18: Diagrama Ventas

Venta Normal

Venta de RebajaVendedor

Venta de Oferta

Figura 3.19: Diagrama Realizar Venta

En los D. de Casos de Uso no existe el concepto de explosin tal como se tiene enlos DFDs (Diagramas de Flujo de Datos). La funcionalidad representada por un casode uso es atmica (aunque en Rational Rose 98 a un caso de uso se le puedeasociar un nuevo D. de Casos de Uso!!). En UML el concepto de paquete permiteorganizar de manera jerrquica un modelo, y en este caso, un paquete puede tenerasociado un nuevo diagrama.

Figura 3.20: Estado de la Prctica al terminar el paso f)

Documente los casos de uso Venta Normal, Venta Rebajas, Venta Ofertas a partirde la informacin siguiente, presentada en tres estilos distintos (secuencia depasos, condiciones pre-post de la aplicacin del caso de uso y, por ltimodescripcin narrativa).

Venta Normal

Cree un fichero word con el siguiente contenido:

Caso de Uso Venta Normal

El cliente se identifica mostrando su tarjeta y el DNI

El vendedor revisa los datos del cliente

El vendedor introduce su cdigo de vendedor e indica al sistema que se trata de unaventa normal

El sistema muestra la pantalla para introducir los datos de la venta

El vendedor introduce los artculos mediante un lector de cdigo de barras odirectamente por teclado. Pueden ser varios artculos en una misma venta.

El vendedor solicita la emisin del recibo

El sistema imprime el recibo

Haga doble click sobre el caso de uso Venta Normal del diagrama y en la pestaaFiles con el botn derecho realice Insert File, asociando el fichero word recincreado.

Venta en Oferta

Haciendo doble click en el caso de uso Venta en Oferta y dentro del cuadrodenominado documentacin, introducir:

Precondiciones

- Los artculos de la venta deben estar en oferta

- El pago debe hacerse en efectivo

- El artculo debe tener el suficiente stock para satisfacer la venta

Postcondiciones

- El stock del artculo se decrementa con la venta realizada

- Se registran todos sus datos en la base de datos

Venta en Rebajas

Seleccionando el caso de uso Venta en Rebajas, introducir en el cuadro dedocumentacin (bajo el browser) el siguiente texto:

En el periodo de rebajas los precios tienen una disminucin de precio tanto de formaindividual como por grupos de artculos. Los descuentos se detallan en lacorrespondiente tabla de descuentos por grupo.

3.13 Actividad 12Cree un nuevo modelo y renombre el diagrama Main de la Vista de Casos de Usopor Video Club.

Introduzca en el Diagrama Video Club el modelo de la figura 3.21.

Encargado Prestar Video

Figura 3.21: Diagrama Video Club

Cree un Diagrama de Secuencia asociado al Caso de Uso Prestar Video ydenomnelo Prestar con xito. Arrastre desde el navegador el actor Encargado ycomplete el Diagrama de Secuencia segn lo mostrado en la Figura 3.22. Los objetosutilizados en este diagrama son annimos, es decir, slo se indica la clase a la cualpertenecen, pero no se les asigna un nombre especfico.

Deshabilite la opcin Focus of Control en Tools-Options-Diagrams y observe elefecto.

Cree el Diagrama de Colaboracin asociado al Diagrama de Secuencia dibujadomediante Browse-Create Collaboration Diagram. La Figura 3.23 muestra eldiagrama de colaboracin que se debe obtener.

: Encargado :WInPrstamos :Socio :Video :Prstamo

prestar(video, socio)

verificar situacin socio

verificar situacin video

registrar prstamo

entregar recibo

Figura 3.22: Diagrama Prestar con xito

: Encargado

:WInPrstamos

:Socio

:Video

:Prstamo

1: prestar(video, socio)

2: verificar situacin socio

3: verificar situacin video

4: registrar prstamo5: entregar recibo

Figura 3.23: Diagrama Obtenido a partir del Diagrama Prestar con xito

Tema 4. Actividades para desarrollo de laprctica

4.1 IntroduccinLa siguiente es una lista de actividades, que puede servir como pauta general dedesarrollo usando UML. Hay que insistir en el hecho que dichas actividadesdeberan retroalimentarse entre ellas en un proceso de refinamiento sucesivo.

Comenzar con el anlisis del negocio y Casos de Uso

Capturar cmo funciona actualmente el negocio y cmo se desea que funcione. Usarla tcnica Casos de Uso para construir escenarios1 que modelen los procesos delsistema. Construir un diagrama de Casos de Uso para cada escenario en el sistema.

Migrar desde los diagramas de Casos de Uso a diagramas de Secuencia y diagramasde Colaboracin

Realizar un diagrama de secuencia o colaboracin por cada Caso de Uso, capturandolos objetos y los mensajes entre ellos. La secuencia de pasos del Caso de Uso setraduce en una secuencia de interacciones entre objetos en el diagrama de secuencia.El diagrama de Colaboracin muestra las mismas interacciones, pero sin indicar susecuencia. Es una visin alternativa para el diagrama de Secuencia.

Construir el diagrama de Clases

Especificar la estructura de las clases y sus relaciones de herencia. Los objetosmodelados en los diagramas de Secuencia y Colaboracin son utilizados paramodelar las clases en el diagrama de Clases.

1 Un escenario es el planteamiento de una situacin de funcionamiento del sistema, incluye ladeterminacin de los actores externos y de la parte del sistema involucrada. Un escenario puede serdescrito por un Caso de Uso.

Construir diagramas de Estado

Modelar el comportamiento de un objeto particular o clase de objetos. Realizar undiagrama de Estado para cada clase que tenga un comportamiento significativo.

Modelar componentes de software

Utilizar el diagrama de Componentes para modelar la estructura del software,incluyendo dependencias entre componentes de software, componentes en cdigobinario y componentes ejecutables.

Modelar la distribucin e implementacin

Utilizar el diagrama de Despliegue para modelar la configuracin en tiempo deejecucin de los componentes del sistema, modelando nodos y comunicacin entreellos.

Tema 5. Casos de Uso. Ejercicios Resueltos

Ejercicio 1. Gestin de fincas e inmuebles

Enunciado

Se desea desarrollar una aplicacin de gestin de fincas e inmuebles. La aplicacindeber cubrir todos los aspectos relacionados con dicho tema, teniendo en cuenta lasiguiente dinmica de funcionamiento:

Una empresa gestiona un conjunto de inmuebles, que administra en calidad depropietaria. Cada inmueble puede ser bien un local (local comercial, oficinas, ...), unpiso o bien un edificio que a su vez tiene pisos y locales. Como el nmero deinmuebles que la empresa gestiona no es un nmero fijo, la empresa propietariaexige que la aplicacin permita tanto introducir nuevos inmuebles, con sus datoscorrespondientes (direccin, nmero, cdigo postal, ...), as como darlos de baja,modificarlos y consultarlos. Asimismo, que una empresa administre un edificiodeterminado no implica que gestione todos sus pisos y locales, por lo que laaplicacin tambin deber permitir introducir nuevos pisos o locales con sus datoscorrespondientes (planta, letra,...), darlos de baja, modificarlos y hacer consultassobre ellos.

Cualquier persona que tenga una nmina, un aval bancario, un contrato de trabajo ovenga avalado por otra persona puede alquilar el edificio completo o alguno de lospisos o locales que no estn ya alquilados, y posteriormente desalquilarlo. Por ellodebern poderse dar de alta, si son nuevos inquilinos, con sus datos correspondientes(nombre, DNI, edad, sexo, fotografa, ... ), poder modificarlos, darlos de baja,consultar, etc. (para la realizacin de cualquiera de estas operaciones es necesaria laidentificacin por parte del inquilino). Por otra parte, cada mes el secretario de laempresa pedir la generacin de un recibo para cada uno de los pisos y de loslocales, el cual lleva asociado un nmero de recibo que es nico para cada piso y

para cada local y que no variar a lo largo del tiempo, indicando el piso o local a quepertenece, la fecha de emisin, la renta, el agua, la luz, la actualizacin del IPCanual, portera, IVA, etc. Y otros conceptos, teniendo en cuenta que unos sernopcionales (slo para algunos recibos) y otros obligatorios (para todos los recibos).Adems, para cada recibo se desea saber si est o no cobrado.

Con vistas a facilitar la emisin de recibos cada mes, la aplicacin deber permitir lageneracin de recibos idnticos a los del mes anterior, a excepcin de la fecha.Adems debern existir utilidades para inicializar los conceptos que se desee de losrecibos a una determinada cantidad y tambin debe ser posible modificar recibosemitidos en meses anteriores al actual. La aplicacin tambin deber presentar losrecibos en formato impreso, pero teniendo en cuenta que en un recibo nuncaaparecern aquellos conceptos cuyo importe sea igual a cero.

De igual forma, el secretario debe poder gestionar los movimientos bancarios que seproducen asociados a cada edificio, piso o local. Un movimiento bancario siempreestar asociado a un banco y a una cuenta determinada de ese banco. En esa cuentaexistir un saldo, acreedor o deudor, que aumentar o disminuir con cadamovimiento. Para cada movimiento se desea saber tambin la fecha en que se harealizado. Un movimiento bancario puede ser de dos tipos: un gasto o un ingreso.

Si el movimiento bancario es un gasto, entonces estar asociado a un inmuebledeterminado, y se indicar el tipo de gasto al que pertenece entre los que se tienenestipulados. Ejemplos de gastos son el coste de la reparacin de un ascensor delinmueble que pertenece a gastos de reparacin, el sueldo de la seora de la limpieza,etc. S el movimiento bancario es un ingreso entonces estar asociado a un piso deun inmueble determinado o a un local y tambin se indicar el tipo de ingreso al quepertenece, como en el caso de los gastos. Ejemplos de ingresos son precisamente losrecibos que se cobran cada mes a los inquilinos.

Basndose en los gastos e ingresos que se deducen de los movimientos bancarios, laaplicacin deber ser capaz de ocuparse de la gestin econmica generando losinformes que facilitan la realizacin de la declaracin de la renta.

Por ltimo, la aplicacin deber ser capaz de proporcionar el acceso, de formaestructurada, a toda la informacin almacenada en el sistema, generando para ellolos listados necesarios que requiere el secretario.

Ejemplos de listado son: el listado de todo los inquilinos ordenado por fechas, ellistado de inquilinos que han pagado o no en un determinado intervalo de tiempo, ellistado de todos los inmuebles, el listado de todos los pisos y locales de cadaedificio, el listado de todos los recibos pendientes de cobro en un determinadointervalo de tiempo, etc.

Solucin:

A continuacin se muestra el diagrama de casos de uso en el que se representan alactor propietario y las tareas requeridas por el sistema de gestin de fincas einmuebles (ver Figura 5.1).

El propietario ser el responsable de la gestin del edificio, local o de los pisosmediante el alta, las modificaciones, consulta y la baja de los mismos.

En este diagrama de casos de uso asociado con el propietario, los casos de usos conlos que se comunica el actor son:

? Gestin de edificios.

? Gestin de locales.

? Gestin de pisos.

Cada uno de los casos de uso anteriores refleja las actividades comunes que se debenrealizar en el alta, baja, modificacin y consulta. Ya que en el enunciado se hacereferencia a estas cuatro funcionalidades que se deben permitir en el sistema, se hareflejado tal situacin introduciendo un caso de uso especfico si se hace referenciaal edificio, al local o al piso. Se ha hecho este desglose y diferenciacin dependiendode si es un edificio, local o piso, ya que las operaciones que conllevan cada uno esdistinta aunque podamos nombrarlas de la misma forma. Los datos y actividades quese manejan son diferentes.

Figura 5.1:.Casos de uso relacionados con el actor propietario.

La relacin empleada para organizar los casos de uso es la de un extend, ya que seintenta identificar que cualquiera de estas funcionalidades se pueden o no realizartanto individual corno conjuntamente. Adems, hemos relacionado mediante unextend el caso de uso de Gestin de locales y de pisos con el caso de uso Gestinde edificio. Con esto reflejamos que la gestin de edificios puede conllevar lagestin de locales, de pisos o de ambos.

En el siguiente diagrama (ver Figura 5.2) se muestran los casos de uso relacionadoscon el actor inquilino. El inquilino va a ser aquella persona que tiene algn tipo deaval, de los expuestos en el enunciado, y, por tanto, puede realizar algunas de lassiguientes operaciones en el sistema:

? Alquilar.

? Desalquilar.

? Darse de baja.

? Modificar sus datos.

? Consultarlos.

Para cada una de estas operaciones hay un caso de uso en el diagrama reflejando lasituacin anterior. Adems, ya que se nos dice que para la realizacin de cualquierade las operaciones es necesaria su identificacin, se ha reflejado un caso de usonombrado Identificacin que se relaciona con los anteriores mediante la relacin deinclude. Con la relacin de include hacemos especial nfasis en esta situacin.

Figura 5.2: Casos de uso del actor 'Inquilino".

Tras volver a examinar con ms detalle la descripcin proporcionada se observa quecuando se produce el alquiler ste puede ser el de un piso (Alquiler Piso) un local(Alquiler Local) y de edificio (Alquiler de Edificio). Por ello se generan tresnuevos casos de uso que implican una relacin de extend con el caso de uso deAlquilar.

Como hemos observado que la primera vez que se produce una operacin de alquilerse debe permitir el alta de los datos del inquilino, se ha creado el caso de uso AltaInquilino como una extensin de Alquiler Piso, Alquiler Local y Alquiler Edificio.

Finalmente, el ltimo diagrama de caso de uso que se muestra (Figura 5.3) es aquelen el que se encuentra involucrado el actor secretario. Tras una visin general delas caractersticas del sistema, observamos que las tareas del secretario son:

Obtencin de los distintos tipos de recibos. Obtener los informes econmicos.Generacin de los listados.

Como vemos, en aras de reflejar de una forma ms meticulosa las funcionalidadesque debe contemplar el sistema, todos los casos de uso genricos, con los cuales estrelacionado, se desglosan en otros casos de uso. Para ello se ha utilizado la relacinde extensin en algunos casos de uso.

As pues, el caso de uso de "Generar recibos" est relacionado mediante un extendcon los casos de uso:

? Recibos idnticos mes anterior.

? Inicializar conceptos.

? Modificar los del mes anterior.

Este desglose se ha realizado para reflejar lo que el enunciado muestra con detalle yas poder tener una comprensin mayor de lo que el sistema debe de hacer.

Por otra parte, la Gestin de movimientos bancarios se extiende en los casos deuso de Ingresos y Gastos de inmuebles, mientras que el de ingresos se extiende eningresos de pisos e ingresos de local. De esta forma reflejamos el hecho de quelos ingresos pueden ser de pisos, de locales o ambos, pero slo por esos conceptos.

Figura 5.3:Casos de uso relacionados con el actor "Secretario empresa".

Finalmente, el caso de uso de Generacin de listados se extiende en distintos casosde uso dependiendo del tipo de listado que se ha comentado en el enunciado. Conesto se indica claramente cules son especficamente las operaciones que se debenpoder realizar, obteniendo, por tanto, una mayor comprensin de los requisitos quedebe tener el sistema. La extensin refleja esos comportamientos opcionales quepuede haber en el sistema y que no tienen por qu ser exclusivos, en el sentido deque si se realiza uno se pueden realizar los otros, cuando se generan listados.

Los casos de uso que tenemos son: Inquilino por fecha, Pagos inquilino en unintervalo de tiempo, Impagos inquilino en un intervalo de tiempo, De todos losinmuebles, De todos los pisos y locales de cada edificio, De recibos pendientes.

Ejercicio 2. Gestin calificaciones Enunciado:

Enunciado

Se desea desarrollar una aplicacin de gestin de las calificaciones de los alumnospara satisfacer las numerosas quejas de los profesores, por el uso del lpiz y papel.La aplicacin deber cubrir nicamente aquellos aspectos relacionados con dichotema, y que se describen a continuacin:

El profesor recibe las actas en blanco de las asignaturas de las que es responsable, enformato electrnico. El acta contiene los siguientes datos de la asignatura (titulacin,campus, curso acadmico, denominacin de la asignatura, convocatoria y grupo) y la

lista de alumnos matriculados (niu, nif, nombre y apellidos). Alguna de las accionesque puede hacer el profesor son:

? Completar un acta con las notas de los alumnos.

? Aadir o borrar un alumno de un acta.

? Integrar las actas de varios grupos de una misma asignatura en una sola acta.

Otras de las opciones que se le exige a la aplicacin, para satisfacer completamentelas necesidades del profesor, son las siguientes:

? Permitir la consulta de la siguiente informacin de cualquier alumno seleccionado:

- DNI, N. EXPEDIENTE, Lista de asignaturas en las que est matriculado elalumno (Cdigo asignatura-Nombre asignatura).

? Obtener una estadstica de las calificaciones obtenidas por los alumnos en undeterminado grupo de una asignatura. En esta estadstica se tendr para cada posiblecalificacin:

- Nmero de personas con esa calificacin, Porcentaje sobre los presentados,Porcentaje sobre el total del grupo.

? Consultar el porcentaje de personas sobre el total del grupo que se han presentadoy el de los que no se han presentado.

? Poder visualizar un grfico indicativo del nmero de personas que han obtenidouna calificacin entre 0-0.99, 1-1.99, 2-2.99, 3-3.99, 4-4.99, 5-5.99, 6-6.99, 8-8.99,9-10; indicndose la nota media obtenida por la clase.

? Disponer de una calculadora que permita realizar las operaciones de suma, resta,multiplicacin, divisin. Esta calculadora se activar cuando se vayan a introducirlas notas a algn alumno de forma que una vez realizada la operacin aritmtica,pulsando un botn se vuelque el resultado en la casilla donde se estnintroduciendo las calificaciones, redondendose a dos cifras decimales.

? Permitir la importacin y exportacin de la lista de alumnos con sus calificacionesa un formato compatible con MS Excel.

? Imprimir las actas y la lista provisional de calificaciones.

Finalmente, como una ampliacin extra, a la cual slo podr acceder quien seidentifique inicialmente como administrador de la aplicacin, se deben permitir:

? Gestin ABMC (Altas/Bajas/Modificacin y Consulta) de los datos de unalumno y su matriculacin en una asignatura y a un grupo.

? Gestin de Asignaturas, teniendo en cuenta que una asignatura slo se puededar en un nico curso (primero, segundo, tercero...) y que cada curso est

formado ponlos datos sobre el nmero mximo de alumnos, nmero mnimo decrditos troncales y nmero mnimo de crditos optativos. Algunos de los datosque vamos a poder consultar de una asignatura son el nombre, nmero decrditos y cuatrimestre en el que se imparte.

? Gestin de Titulaciones, teniendo en cuenta que una titulacin slo se da enun campus determinado y los datos que podemos consultar son el nombre, elnmero de crditos o carga lectiva global, si es de 1. o 2.' ciclo, ...

? Gestin de grupos, en los que podemos consultar el nmero mximo dealumnos permitidos, si es un grupo de maana, de tarde o de noche, y cul es elcdigo empleado para identificar el grupo.

? Consultar aquellos alumnos que no se pueden matricular y el motivo de ello.

? Consultar el historial acadmico de un alumno.

Solucin

A continuacin se muestra el diagrama de casos de uso en el que se representanal actor profesor junto con las tareas que requiere del sistema de gestin decalificaciones (ver Figura 5.4). As tenemos que:

El profesor ser aquel que puede realizar una serie de operaciones relacionadascon el listado de alumnos que tiene matriculados en sus asignaturas, tales comointroducir las notas de alumnos, consultar el historial de alguno de sus alumnos,introducir o eliminar algn alumno en el listado y tareas de estadstica y deimportacin y exportacin.

Se ha intentado reflejar toda la funcionalidad del sistema asociada al actorprofesor para poder mostrar qu es lo que se espera que haga el sistema deforma completa.

As pues, se tiene el caso de uso de Poner notas, el cual se extiende en el casode uso de Operaciones Calculadora. Con ello se refleja que el profesor alintroducir las notas puede en algn momento hacer uso de las operaciones queaporta una calculadora. Y ya que actualmente una calculadora ofrece una granvariedad de operaciones se han detallado mediante la relacin de extend lasoperaciones que el profesor podra utilizar, como son: Sumar, Restar,Multiplicar o Dividir. Finalmente, para completar cul es la funcionalidadcompleta que se espera que permita el caso de uso de Operaciones Calculadorase identifica el caso de uso de Volcar Resultado mediante la relacin deinclude, ya que es algo que debe poder realizar siempre que se haga algunaoperacin con la calculadora.

Por otra parte, el caso de uso de Gestin de alumno se ha relacionado con elcaso de uso de Aadir y Borrar mediante un extend para identificarexplcitamente cules son las acciones que se espera que permita el sistema y

que o bien se puede realizar de forma individual o no, cuando el profesor utilizael sistema.

Otras de las funcionalidades que constituyen un caso de uso cada una son:Integrar grupos, Informacin alumno, Estadstica, Grfico, Importar y Exportar.

De la misma forma que anteriormente hemos comentado, se ha realizado elproceso de identificacin explcita de las operaciones que se pueden realizarcuando el profesor quiere Imprimir. Se ha expresado mediante el extend lasformas de impresin que puede tener el profesor reflejando que cuando seimprime puede imprimir slo las actas (Imprimir actas), slo las listas(Imprimir Listas provisional) o ambas.

Figura 5.4: Casos de uso relacionados con el actor "Profesor".

Finalmente se muestra que todos los casos de uso con los que se relaciona de formadirecta el actor se relacionan con el caso de uso de Validar Usuario para mostrarque es necesaria la identificacin del profesor en el sistema para poder realizarcualquier operacin comentada anteriormente.

En el siguiente diagrama se muestran todos los casos de uso relacionados con elactor administrador del sistema (ver Figura 5.5).

El administrador ser el responsable del mantenimiento de los datos que hay en elsistema respecto a las asignaturas y a los alumnos matriculados.

Como podemos observar, se ha intentado expresar toda la funcionalidad del sistemay por ello se han desglosado al mximo todos los casos de uso hasta que cada unorefleja una funcionalidad del sistema.

En la siguiente figura se muestran cules son de forma explcita las funcionalidadesque conlleva la gestin de los alumnos (caso de uso Gestin ABMC Alumnos). Aspues, se ha expresado mediante la relacin de extend las distintas posibilidades queofrece la gestin de alumnos, mostrndose adems que ninguna es excluyente y quese pueden realizar algunas de las operaciones o todas cuando el administradorgestiona a los alumnos (casos de uso Alta, Baja, Modificacin, Consulta HistorialAcadmico).

El resto de funcionalidades que el administrador espera del sistema son lassiguientes:

? Matriculacin, que identifica a la capacidad del sistema para realizar lamatriculacin de un alumno en las asignaturas, titulaciones y grupos existentes.

? Gestin de Asignaturas, que identifica la posibilidad que tiene el administradorpara introducir, borrar, modificar y consultar las asignaturas. En este caso no se hareflejado de forma explcita, ya que en el enunciado no aparece detallado cul es elalcance de la gestin de asignaturas.

Figura 5.5:Casos de uso relacionados con el actor "Administrador".

? Gestin de Titulaciones y Gestin de Grupos reflejan la posibilidadpara que el administrador introduzca en el sistema los datos de titulaciones y

Grupos. Como ocurra anteriormente, al no detallarse en el enunciado del problemacul es el alcance real de estas operaciones slo se reflejan estos casos de uso sin eldetalle mostrado para la Gestin ABMC Alumnos.

Resaltar el hecho de que el caso de uso de Validar Usuario est relacionado,mediante la asociacin de include, con todos los casos de uso con los que serelaciona directamente el actor administrador. De esta forma indicamos quecualquier administrador que tenga que realizar una tarea o funcin debe identificarseen el sistema. El caso de uso que aparece en el grfico siguiente es el mismo que seidentific anteriormente.

Ejercicio 3. Puntos de informacin universitaria

Enunciado

La Universidad Carlos III de Madrid en su constante innovacin pretende instalar unconjunto de Puntos de Informacin Universitaria (PIU) a travs de los cuales sepueda facilitar informacin a la comunidad universitaria.

Las funcionalidades consideradas para instalar en cada PIU son:

? Informacin General: actividades culturales y extra-acadmicas de la Universidady de las diferentes Escuelas y Facultades.

? Informacin Administrativa: plazos de matriculacin, fechas de exmenes,normativas y avisos.

? Informacin Privada: esta informacin se diferenciar segn el tipo de usuario finalque se identifique en el PIU.

PAS: informacin relativa a su cuerpo e informacin econmico-contractual.

Profesores: informacin relativa a su cuerpo, informacin de asignacin horaria declases e informacin econmico-contractual.

Alumnos: informacin referente a la carrera que estn cursando y su currculum, ascomo el estado de su matriculacin.

Como ayuda a la resolucin de esta problemtica, la Universidad Carlos 111 hapedido a su departamento de investigacin y desarrollo (I+D) la elaboracin de unsistema informtico que pueda ser utilizado por cuatro tipos de usuarios diferentes:

? Administrador: es el responsable de la colocacin y carga inicial de los PIU's enlas diferentes Escuelas y Facultades que componen la Universidad, es decir, seencarga de decidir, las situaciones fsicas ms propicias y de activacin inicial de loscontenidos (funcionalidades a proporcionar) de cada uno de los PIU's en lasdiferentes Escuelas y Facultades que componen la Universidad, es decir, se encarga

de decidir las situaciones fsicas ms propicias y de activacin inicial de loscontenidos (funcionalidades a proporcionar) de cada uno de los PIU's.

Por tanto, el administrador tan slo utilizar este sistema informtico para notificarla instalacin de los distintos dispositivos. Habr un administrador de dispositivospor cada turno de maana y de tarde para solucionar todas las peticiones realizadaspor los responsables de cada centro.

? Gestor: es el encargado de determinar la situacin (funcionamiento/desconexin)de cada uno de los PIU's distribuidos previamente por el administrador del sistema.

Asimismo, este usuario ser el responsable de determinar qu acciones sedesencadenarn como consecuencia de la aparicin de un mal funcionamiento delPIU's, como puede ser:

-Registro en una salida de "Log". - Envo de un equipo tcnico.

-Reporte del error al CAT (Centro de Atencin Tcnico).

-Reinicializacin del PIU.

-Emisin de una solicitud de desconexin del PIU al administrador.

Como la principal misin de los gestores de los PIU's es la regulacin ymantenimiento de los mismos, tan slo utilizarn el sistema informtico de formaespordica, para retocar los parmetros de funcionamiento del sistema cuando sedetectan anomalas a tener en cuenta. Habr un gestor de dispositivos en el turno demaana y en el de tarde.

? Operador: es el usuario responsable de gestionar el funcionamiento de cada unode los PIU's existentes en cada una de las Escuelas y Facultades. Su actividadconsistir en el control de red, es decir, se encarga de verificar el funcionamientoglobal de la red de PIU's existente. Pudiendo realizar operaciones de control, gestiny estadsticas sobre la misma. Adems, se encarga de reportar los errores observadosal Gestor que est de guardia en cada momento.

Los operadores estarn utilizando continuamente el sistema de seguimiento de losPIU's, tan slo lo dejarn de utilizar en los periodos de descanso acordados. LaUniversidad utilizar a tres operadores en activo para cada uno de los turnos deservicio (maana, tarde y noche).

Por ltimo, los operadores tambin debern realizar las acciones indicadas por elgestor del sistema en caso de que ste no est localizable.

? Usuarios Finales: este grupo est compuesto por el PAS, el Profesorado y elAlumnado. Su conexin al sistema vendr siempre asociada a una solicitud/serviciode informacin.

Cada vez que un usuario intente conectarse al sistema deber introducir sus datosidentificativos, as como la introduccin de una contrasea y del tipo de usuario (en

caso de que sea necesario). Las actividades recogidas por el sistema slo estarnaccesibles para el tipo de usuario responsable de su realizacin, de tal manera,que la instalacin de PIU's no estar accesible a un gestor o a un operador, delmismo modo la gestin de red no podr ser realizada por un administrador o porun gestor.

Instalacin de los PIU's

Para instalar un PIU dentro de una Facultad o Escuela ser necesario, en primerlugar, seleccionar la Escuela/Facultad, de tal modo que slo puede haber unnico dispositivo de un tipo determinado en una misma Escuela/Facultad. Acontinuacin se indicar las funcionalidades que soportar dicho PIU. Serposible que el administrador de los PIU's cambie la colocacin de los mismos,as como el resto de caractersticas propias del PIU.

Control de funcionamiento

Peridicamente, el gestor de los PIU's podr observar el estado defuncionamiento de cada uno de los PIU's as como ajustar las acciones arealizar qu se desencadenar como consecuencia de la aparicin de un malfuncionamiento del PIU's.

Gestin de red

Se podrn realizar operacin de control, gestin y estadstica sobre la redinstalada observando la aparicin de errores, que debern ser reportados algestor de guardia.

Obtencin de informacin

Los Usuarios Finales realizarn peticiones al sistema guiados a travs de lainterfaz grfica del sistema, su nica interrelacin con el sistema, consiste en laemisin de dichas peticiones para que sean procesadas y servidas por elsistema.

Solucin

A continuacin se muestra el diagrama de casos de uso en el que se representantodos los actores y las tareas requeridas por el sistema de gestin de PIU's (verFigura 5.6). Identificamos inicialmente a los actores que van a interactuar dealguna forma con el sistema, obteniendo la siguiente lista:

El Administrador.

El Gestor.

El Operador o vigilante.

El Usuario final.

Una vez que hemos identificado a los distintos usuarios registramos lasoperaciones que cada uno de ellos debe de poder realizar en el sistema. Aspues, indicamos las funcionalidades del sistema desde el punto de vista delusuario del sistema.

As tenemos que:

? El administrador ser aquel que realice las tareas de instalacin de los PIU's.

? El gestor ser el responsable de controlar el buen funcionamiento de losdiferentes PIU's existentes en el sistema.

? El vigilante ser el responsable de la gestin de la red en la que se encuentranlos diferentes PIU's existentes en el sistema.

? El usuario final estar destinado a la realizacin de las consultas necesariaspara la extraccin de la informacin contenida en los PIU's.

Cada una de estas funcionalidades se representan como un caso de usorelacionado o asociado con el actor que tiene que demandarla.

Figura 5.6:Casos de uso del "sistema de informacin universitaria".

Podemos observar con la descripcin del problema que todos los actores van atener la tarea de su idenificacin previamente a la realizacin de cualquiertarea, con lo cual utilizaremos la relacin de include entre la nuevafuncionalidad de Identificacin y el resto. Con ello indicamos explcitamenteque para realizar cualquier operacin en el sistema es necesario laidentificacin.

Al examinar con posterioridad el enunciado observamos que existe una serie defuncionalidades que no habamos detectado y que mostramos en la Figura 5.7.Identificamos que la operacin de instalacin de PIU's tiene embebido lasoperaciones de Instalacin de PIU existente y/o la Instalacin de nuevo PIU.

Para representar esta relacin entre las distintas funcionalidades que debenexistir empleamos la relacin de extend entre el caso de uso Instalacin de losPIU's y los casos de uso Instalacin PIU existente e Instalacin nuevo PIU.Con ello reflejamos la semntica que nos proporciona la descripcin delproblema.

De forma anloga sucede con la operacin de Control de Funcionamiento.Observamos que esta operacin supone la realizacin o no de la funcin deDeterminar las acciones por mal funcionamiento, Realizar las accionescorrectivas y Actualizar los parmetros de los PIU.

Representamos pues estos casos de uso con una relacin extend entre el caso deuso Control de funcionamiento y los casos de uso Determinar Acciones MalFuncionamiento, Actualizar Parmetros PIU y Realizar Acciones Correctivas.De esa forma reflejamos el carcter de opcionalidad al realizar la funcin decontrol de funcionamiento.

Figura 5.7: Relaciones entre los casos de uso del "sistema de informacinuniversitaria".

Finalmente tambin sucede lo mismo con la funcionalidad de Gestin de Red,ya que supone las operaciones de Realizar Informe, Configurar Estadsticas yObtener Resultados de Estadsticas. Segn el enunciado, estas operacionespueden realizarse en determinados momentos, lo que supone que pararelacionar los distintos casos de uso que conforman cada una de estasoperaciones es necesario utilizar la relacin de extend entre el caso de usoGestin de Red y los otros tres.

Tema 6. Diagrama de Clases. EjerciciosResueltos

Ejercicio 1. Animales de la casa

Enunciado

Disear una aplicacin orientada a objetos que describa la siguiente situacin:

En una casa viven cinco animales: una ballena llamada "Moby Dick", que nodice nada; un perro fiero llamado "Can", que dice "Grrr"; un perro mansollamado "Abel", que dice "Guau"; un pingino llamado "Adela" que no dicenada, y un loro que dice "Lorito bonito", "Pretty Polly" y "Viva mi dueo".

Especificar la jerarqua de herencia, las clases, los atributos y los mtodos decada clase.

Solucin

El primero de los pasos que debemos realizar para obtener el diagrama declases del problema consiste en extraer todos los sustantivos que aparecen enel enunciado. La lista de sustantivos escritos, en singular, y que pueden ser,por tanto, una clase es la siguiente:

Casa Perro Animal Ballena Pingino Loro

Tras identificar todas las posibles clases que se extraen de forma directa deenunciado pasamos a eliminar aquellos que no aportan nada para modelar elproblema.

Eliminamos, por tanto, la clase Casa, ya que hace referencia al lugar en el quese describe la situacin y no aporta nada.

Tras quedarnos con las clases candidatas identificamos los atributos de lasclases. Para ello observamos los posibles valores que una propiedad de unaclase puede tomar, el rango de los valores o una regla que enuncia a todos losposibles valores.

De la nica clase que podemos extraer un atributo es de la clase Perro y elnombre del atributo tiene que reflejar el hecho que un Perro sea fiero o manso,as que definimos el atributo Agresividad que puede contener los valores defiero o manso. El atributo ser privado y por ello aparece en el diagrama elsmbolo de - a la izquierda del nombre.

A continuacin recogemos las operaciones de una clase, en nuestro enunciadose hace referencia a que un perro hace `guau' y un loro repite palabras variasveces, as que podemos deducir que el Perro tendr una operacin Ladrar y elLoro una operacin Hablar. A diferencia que en el caso del atributo el smboloque aparece a la izquierda de los nombres de las operaciones es un "+"indicando que son pblicas.

Finalmente recogemos la herencia existente entre las clases en la Figura 6.1.

Figura 6.1: Diagrama de clase.

Ejercicio 2. Reserva de vuelos

Enunciado

El sistema de reserva de vuelos es un sistema que permite al usuario hacerconsultas y reservas de vuelos, adems de poder comprar los billetes areos deforma remota, sin la necesidad de recurrir a un agente de viajes humano. Sedesea que el sistema de reservas sea accesible a travs de la World Wide Web.

El sistema actualmente tiene un Terminal de Servicio de Reserva (formado porun ratn Genius, teclado IBM y monitor Sony) en donde se presenta un mensajede bienvenida describiendo los servicios ofrecidos junto con la opcin pararegistrarse por primera vez, o si ya se est registrado, poder utilizar el sistemade reserva de vuelos. Este acceso se da por medio de la insercin de un loginpreviamente especificado (direccin de correo electrnico del usuario) y unacontrasea previamente escogida y que debe validarse.

Una vez registrado el usuario, y despus de haberse validado el registro ycontrasea del usuario, se pueden seleccionar las siguientes actividades:

Consulta de vuelos.

Reserva de vuelos.

Compra de billetes.

La consulta de vuelos se puede hacer de tres maneras diferentes:

Horarios de Vuelos.

Tarifas de Vuelos.

Informacin de Vuelo

La consulta segn horario muestra los horarios de las diferentes aerolneas que danservicio entre dos ciudades. La consulta segn tarifas muestra los diferentes vuelosentre dos ciudades ordenados por su costo. La informacin de vuelos se utilizaprincipalmente para consultar el estado de algn vuelo, incluyendo informacin de siexisten asientos disponibles y, en el caso de un vuelo para el mismo da, si ste esten hora. Se pueden incluir preferencias en las bsquedas, como fecha y horariodeseado, categora de asiento, aerolnea deseada y si se desean slo vuelos directos.

La reserva de vuelo permite al cliente hacer una reserva para un vuelo particular,especificando la fecha y horario, bajo una tarifa establecida. Es posible reservar unitinerario compuesto de mltiples vuelos, para uno o ms pasajeros, adems de poderreservar asientos.

La compra permite al cliente, dada una reserva de vuelo previa y una

Ejemplos de Diagramas UML 2014

Documents

Transcript of Ejemplos de Diagramas UML 2014