Análisis Orientado a Objetos Aplicando UML

Página 1 de 43

Modelos y DiagramasUn modelo captura una vista de un sistema del mundo real. Es

una abstracción de dicho sistema, considerando un cierto propósito. Así, el modelo describe completa-mente aquellos aspectos del sistema que son relevantes al propósito del modelo, y a un apropiado nivel de detalle.

Diagrama: una representación gráfica de una colección de elementos de modelado, a menudo dibujada como un grafo con vértices conectados por arcos

Diagramas de UML

Diagrama de Casos de Uso

Diagrama de Clases

Diagrama de Objetos Diagramas de Comportamiento

Diagrama de Estados

Diagrama de Actividad Diagramas de Interacción

Diagrama de Secuencia

Diagrama de Colaboración Diagramas de implementación

Diagrama de Componentes

Diagrama de Despliegue

En esta sección se presenta en forma resumida lo que significa e incluye UML:

UMLIntroducción:

El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software. UML entrega una forma de modelar cosas conceptuales como lo son procesos de negocio y funciones de sistema, además de cosas concretas como lo son escribir clases en un lenguaje determinado, esquemas de base de datos y componentes de software reusables.

En este repaso teórico práctico estudiaremos tres diagramas:

Modelamiento de Clases Casos de Uso Diagrama de Interacción

Modelo de Clases

Introducción

Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.

Un diagrama de clases esta compuesto por los siguientes elementos:

Página 2 de 43

... Diagramas de UML

Use CaseDiagramsUse Case

DiagramsDiagramas de Casos de Uso

ScenarioDiagramsScenario

DiagramsDiagramas deColaboración

StateDiagramsState

DiagramsDiagramas deComponentes

ComponentDiagramsComponent

DiagramsDiagramas deDistribución

StateDiagramsState

DiagramsDiagramas de Objetos

ScenarioDiagramsScenario

DiagramsDiagramas deEstados

Use CaseDiagramsUse Case

DiagramsDiagramas deSecuencia

StateDiagramsState

DiagramsDiagramas deClases

Diagramas deActividad

Modelos

Los diagramas expresan gráficamente partes de un modelo

Clase : atributos, métodos y visibilidad. Relaciones : Herencia, Composición, Agregación, Asociación y Uso.

Elementos

Clase

Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectángulo que posee tres divisiones:

En donde:

o Superior: Contiene el nombre de la Clase o Intermedio: Contiene los atributos (o variables de instancia) que

caracterizan a la Clase (pueden ser private, protected o public). o Inferior: Contiene los métodos u operaciones, los cuales son la forma como

interactúa el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Ejemplo:

Una Cuenta Corriente que posee como característica:

o Balance

Puede realizar las operaciones de:

o Depositar o Girar o y Balance

El diseño asociado es:

Atributos y Métodos:

Página 3 de 43

o Atributos:

Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son:

public (+, ): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.

private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar).

protected (#, ): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).

o Métodos:

Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:

public (+, ): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.

private (-, ): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden accesar).

protected (#, ): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia).

Relaciones entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes).

Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:

o uno o muchos: 1..* (1..n) o 0 o muchos: 0..* (0..n) o número fijo: m (m denota el número).

1). Herencia (Especialización/Generalización):

Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected), ejemplo:

Página 4 de 43

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir, Auto posee las Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es Descapotable, en cambio Camión también hereda las características de Vehiculo (Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.

Cabe destacar que fuera de este entorno, lo único "visible" es el método Caracteristicas aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición publica, en cambio atributos como Descapotable no son visibles por ser privados.

2). Agregación:

Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades:

Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comunmente llamada Composición (el Objeto base se contruye a partir del objeto incluido, es decir, es "parte/todo").

Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comunmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).

Un Ejemplo es el siguiente:

Página 5 de 43

En donde se destaca que:

Un Almacen posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).

Cuando se destruye el Objeto Almacen también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.

La composición (por Valor) se destaca por un rombo relleno. La agregación (por Referencia) se destaca por un rombo

transparente.

La flecha en este tipo de relación indica la navegabilidad del objeto refereniado. Cuando no existe este tipo de particularidad la flecha se elimina.

3). Asociación:

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.

4). Dependencia o Instanciación (uso):

Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el objeto Aplicacion):

Página 6 de 43

Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicación).

Casos Particulares:

o Clase Abstracta:

Una clase abstracta se denota con el nombre de la clase y de los métodos con letra "itálica". Esto indica que la clase definida no puede ser instanciada pues posee métodos abstractos (aún no han sido definidos, es decir, sin implementación). La única forma de utilizarla es definiendo subclases, que implementan los métodos abstractos definidos.

o Clase parametrizada:

Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los parámetros que deben ser pasados a la clase para que esta pueda ser instanciada. El ejemplo más típico es el caso de un Diccionario en donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden ser genéricos. La genericidad puede venir dada de un Template (como en el caso de C++) o bien de alguna estructura predefinida (especialización a través de clases).

En el ejemplo no se especificaron los atributos del Diccionario, pues ellos dependerán exclusivamente de la implementación que se le quiera dar.

Ejemplo:

Supongamos que tenemos tenemos un el caso del Diccionario implementado mediante un árbol binario, en donde cada nodo posee:

Página 7 de 43

key: Variable por la cual se realiza la búsqueda, puede ser generica. item: Contenido a almacenar en el diccionario asociado a "key", cuyo tipo también

puede ser genérico.

Para este caso particular hemos definido un Diccionario para almacenar String y Personas, las cuales pueden funcionar como llaves o como item, solo se mostrarán las relaciones para la implementación del Diccionario:

Página 8 de 43

Casos de Uso (Use Case)

Introducción

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso).

Un diagrama de casos de uso consta de los siguientes elementos:

Actor . Casos de Uso . Relaciones de Uso, Herencia y Comunicación .

Elementos

Actor:

Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.

Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.

Caso de Uso:

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

Relaciones:

o Asociación

Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

o Dependencia o Instanciación

Página 9 de 43

Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.

o Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).

uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.

De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.

Ejemplo:

Como ejemplo esta el caso de una Máquina Recicladora:

Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:

Registrar el número de ítemes ingresados. Imprimir un recibo cuando el usuario lo solicita:

a. Describe lo depositado b. El valor de cada item c. Total

El usuario/cliente presiona el botón de comienzo Existe un operador que desea saber lo siguiente:

a. Cuantos ítemes han sido retornados en el día. b. Al final de cada día el operador solicita un resumen de todo lo depositado en

el día. El operador debe además poder cambiar:

a. Información asociada a ítemes. b. Dar una alarma en el caso de que:

i. Item se atora. ii. No hay más papel.

Como una primera aproximación identificamos a los actores que interactuan con el sistema:

Página 10 de 43

Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la información de un Item o bien puede Imprimir un informe:

Además podemos notar que un ítem puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún item por un cliente o bien puede ser realizada a petición de un operador.

Página 11 de 43

Entonces, el diseño completo del diagrama Use Case es:

Diagrama de Interacción

Introducción

El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en petición a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades claramente.

Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o el de Casos de Uso (son diferentes).

Los componentes de un diágrama de interacción son:

Un Objeto o Actor . Mensaje de un objeto a otro objeto . Mensaje de un objeto a si mismo .

Elementos

Objeto/Actor:

Página 12 de 43

El rectángulo representa una instancia de un Objeto en particular, y la línea punteada representa las llamadas a métodos del objeto.

Mensaje a Otro Objeto:

Se representa por una flecha entre un objeto y otro, representa la llamada de un método (operación) de un objeto en particular.

Mensaje al Mismo Objeto:

No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a métodos desde el mismo objeto en estudio.

Ejemplo

En el presente ejemplo, tenemos el diagrama de interacción proveniente del siguiente modelo estatico:

Aquí se representa una aplicación que posee una Ventana gráfica, y ésta a su vez posee internamente un botón.

Entonces el diagrama de interacción para dicho modelo es:

Página 13 de 43

En donde se hacen notar las sucesivas llamadas a Draw() (entre objetos) y la llamada a Paint() por el objeto Botón.

Ejemplo1: Caso de un "Hotel"

El dueño de un hotel le pide a usted desarrollar un programa para consultar sobre las piezas disponibles y reservar piezas de su hotel.

El hotel posee tres tipos de piezas: simple, doble y matrimonial, y dos tipos de clientes: habituales y esporádicos. Una reservación almacena datos del cliente, de la pieza reservada, la fecha de comienzo y el número de días que será ocupada la pieza.

El recepcionista del hotel debe poder hacer las siguientes operaciones:

Obtener un listado de las piezas disponible de acuerdo a su tipo Preguntar por el precio de una pieza de acuerdo a su tipo Preguntar por el descuento ofrecido a los clientes habituales Preguntar por el precio total para un cliente dado, especificando su numero de RUC, tipo

de pieza y número de noches. Dibujar en pantalla la foto de un pieza de acuerdo a su tipo Reservar una pieza especificando el número de la pieza, ruc y nombre del cliente. Eliminar una reserva especificando el número de la pieza

El administrador puede usar el programa para:

Cambiar el precio de una pieza de acuerdo a su tipo Cambiar el valor del descuento ofrecido a los clientes habituales Calcular las ganancias que tendrán en un mes especificado (considere que todos los

meses tienen treinta días).

El hotel posee información sobre cuales clientes son habituales. Esta estructura puede manejarla con un diccionario, cuya clave sea el número de RUC y como significado tenga los datos personales del cliente.

El diseño a desarrollar debe facilitar la extensibilidad de nuevos tipos de pieza o clientes y a su vez permitir agregar nuevas consultas.

Página 14 de 43

Casos de USO

Página 15 de 43

Diagrama de Clases

Página 16 de 43

Diagrama de Interacción

Página 17 de 43

Ejemplo2: Sistema de Registro de Nacimientos

Elaboración de los Diagramas de Casos de Uso.

CASO DE USO DEL SISTEMA

RealizarBusquedaProcesarConsulta

<<include>>

ProcesarDuplicadoDePartida

<<include>>

RegistarPersona

ValidarPasswordJefeRegistroCivil

<<include>>

AutentificarUsuario<<extend>>

ValidarCodigoPersonaInteresada

<<extend>>

<<include>>

Sistema

ParaIdentidad

ImprimirPartida <<extend>>

PersonaInteresada

<<extend>>

CASO DE USO: REGISTRAR PARTIDA

IngresarCodigo

DePadres

DelNacido

IngresarDatos

<<extend>>

<<extend>>Usuario

SolicitarDuplicadoConsultarPartida

<<extend>>

Página 18 de 43

CASO DE USO: ADMINISTRAR SISTEMA

ProporcionarPassword ValidarPassword

<<include>>

Mensuales

Anuales

GenerarReportes

<<extend>>

<<extend>>JefeDeRegistroCiv

il

Descripción de los casos de Uso y Escenarios

CASO DE USO – CU0001 AUTENTIFICAR USUARIOVERSIÓN Versión 1.0AUTOR Grupo De TrabajoFUENTES SistemaOBJETIVOS ASOCIADOS Describir los pasos de iniciar una sesión en el sistemaDESCRIPCIÓN El usuario o jefe de registro ingresa al sistema ingresando el

código u password.

PRECONDICIÓN NingunaSECUENCIA NORMAL Paso Acción

1 El sistema pide el nombre del usuario y la contraseña.2 El sistema valido los datos ingresados por el usuario. 3 Si la autenticación es correcta el sistema habilita al

usuario para trabajar en el sistema, muestra un mensaje de éxito, da la bienvenida al sistema de Partidas.

4 El sistema controla los permisos del usuario y presenta un menú de opciones apropiado y termina el caso de uso

POSTCONDICIONES El sistema habilita al usuario a trabajar en el sistema con los permisos apropiados.

EXCEPCIONES Paso Acción1 El usuario puede borrar su nombre y/o contraseña

antes de validar los datos.2 Si no se validan los datos no se permite ingresar al

sistema pudiendo en usuario volver a digitar los datos hasta por tres veces, después se bloqueará el sistema por 30 segundos.

RENDIMIENTOFRECUENCIA ESPERADA 3 vez por díaIMPORTANCIA VitalURGENCIA Puede esperarCOMENTARIOS Ninguno

Página 19 de 43

CASO DE USO – CU0002 REGISTRAR PARTIDA

VERSIÓN Versión 1.0

AUTOR Grupo De Trabajo

FUENTES Sistema

OBJETIVOS ASOCIADOS

Describir los pasos para registrar una partida de nacimiento

DESCRIPCIÓN Registrar una persona

PRECONDICIÓN NingunaSECUENCIA NORMAL Paso Acción

1 El sistema pide el código proporcionado en el certificado que emite el hospital donde nació el niño.

2 El sistema valido el código ingresados por el usuario.

3 Si el código ingresado es correcto el sistema habilita al usuario para trabajar en el sistema, muestra un mensaje de éxito, da la bienvenida al sistema de Partidas.

4 El sistema controla los permisos del usuario y presenta un menú de opciones apropiado y termina el caso de uso.

  5 El usuario ingresa la informacion necesaria requerida por el sistema.

  6 El sistema valida la informacion ingresada por el sistema

  7 El sistema imprime la firma del jefe de registros en la partida.

  8 El Sistema almacena los datos de la persona en la base de datos e imprime la partida si el usuario lo desea.

POSTCONDICIONES Haber ingresado correctamente en sistema

EXCEPCIONES Paso Acción

   

RENDIMIENTO  

FRECUENCIA ESPERADA

3 vez por día

IMPORTANCIA Vital

URGENCIA Puede esperar

COMENTARIOS Ninguno

Escenario #1 del Caso de Uso: Registrar Persona

Rosa y José van a una cabina pública de Internet más cercana a su domicilio a

registrar a su hijo de quince días de nacido.

Rosa o José proceden a ingresar el código que figura en la constancia

entregada por el hospital donde nació su pequeño hijo. El sistema valida el

Página 20 de 43

código ingresado por este y si es correcto ingresa al sistema de registro de

partidas proporcionando los datos requeridos por el sistema y se verifica que

los datos estén completos y que esté en la fecha requerida para ser registrado.

Ingresar la firma de los padres por cualquier medio electrónico lápiz óptico o

firmas escaneadas proporcionadas al sistema por cualquier medio de

almacenamiento magnético (CDS, Diskettes) u electrónico (Memorias USB).

Luego el Sistema valida las firmas de los padres realizando una búsqueda en la

base de datos de la RENIEC.

Si las firmas son correctas el sistema procede a imprimir la firma del jefe de

registro civil.

El sistema imprime la Partida de Nacimiento previa orden de Rosa o José.

Elaboración de los diagramas de secuencia y colaboración.

Diagrama de Secuencia: Administrar sistema

: JefeDeRegistr

:Win Principal :Jefe_Registro

Ingresar Password

Vereficar Password

Buscar Password

Si Existe Password

Habilitar Funciones De Administrador

Generar Reportes

Visualizar Reportes

Salir Del Sistema

Página 21 de 43

Diagrama de Colaboración: Administrar Sistema

: JefeDeRegistro

:Win Principal

:Jefe_Registro

3: Buscar Password

1: Ingresar Password6: Generar Reportes8: Salir Del Sistema

5: Habilitar Funciones De Administrador7: Visualizar Reportes

2: Vereficar Password

4: Si Existe Password

Página 22 de 43

Diagrama de Secuencia: Registrar Partida

: Usuario

:Win Principal Base_Hospital Base_Reniec Padre Madre Partida

Ingresar Codigo del Nacido

Verificar Codigo

Buscar Codigo

Si Existe Codigo

Habilitar Usuario

Ingresar DNI de Padre

Verificar DNI de Padre

Buscar DNI De Padre

Si Existe DNI de Padre

Ingresar Datos de Padre

Registrar Datos Del Padre

Ingresar DNI de Madre

Verificar DNI de Madre

Buscar DNI de Madre

Si Existe DNI de Madre

Ingresar Datos De Madre

Registrar Datos De Madre

Ingresar Datos Del Nacido

Registrar Datos De Partida

Imprimir Partida

Enviar Partida

Salir Del Sistema

Página 23 de 43

Diagrama de Colaboración: Registrar Sistema

: Usuario

:Win Principal

Base_Hospital

Base_Reniec

Padre

Madre

Partida

3: Buscar Codigo

8: Buscar DNI De Padre14: Buscar DNI de Madre

1: Ingresar Codigo del Nacido6: Ingresar DNI de Padre

10: Ingresar Datos de Padre12: Ingresar DNI de Madre

16: Ingresar Datos De Madre18: Ingresar Datos Del Nacido

20: Imprimir Partida22: Salir Del Sistema

5: Habilitar Usuario21: Enviar Partida

2: Verificar Codigo

4: Si Existe Codigo

7: Verificar DNI de Padre13: Verificar DNI de Madre

9: Si Existe DNI de Padre15: Si Existe DNI de Madre

11: Registrar Datos Del Padre

17: Registrar Datos De Madre

19: Registrar Datos De Partida

Página 24 de 43

Diagrama de Secuencia: Consultar Partida

: Usuario:Win Sistema :Base_Reniec

Ingresar Codigo Nacido

VerificarCodigo

Buscar Codigo

Si Existe Codigo

Habilitar Funciones De Usuario

Solicitar Consulta

Visualizar Partida

Imprimir Partida

Enviar Partida

Salir Del Sistema

Página 25 de 43

Diagrama de Colaboración: Consultar Partida

: Usuario

:Win Sistema

:Base_Reniec

3: Buscar Codigo

1: Ingresar Codigo Nacido6: Solicitar Consulta8: Imprimir Partida

10: Salir Del Sistema

5: Habilitar Funciones De Usuario7: Visualizar Partida

9: Enviar Partida

2: VerificarCodigo

4: Si Existe Codigo

Elaboración de los Diagramas de Estado y Actividad.

Ingresar Codigo

[ No Existe Codigo ]

Habilitar Usuario

Registra Partida

Consultar Partida

Solicitar Duplicado

Ingresar _Datos

Ingresar Parametros

Procesar Informacion

Registrar Informacion

[ Existe Codigo ]

Enviar Partida

Página 26 de 43

Elaboración de los Diagramas de clase.

Base_Hospital

Jefe_Registro

PartidaId_PartidaNombre_NacidoSexo_NacidoFecha_Inscripcion

1..*

11..*

1

1..*11..*1

Base_Reniec

PadreId_padreAp_PaternoAp_maternoNombre_PadreFecha_Nacimiento_PadreEdad_PadreNacionalidad_PadreDni_PadreCiudad_Padre

1..*1 1..*1

1

1..*

1

1..*

Madre1..*1

1..*1

1

1..*

1

1..*

DepartamentoId_DepartamentoDescripcion_Depa

1

1..*

1

1..*

1..*1..*

Página 27 de 43

Ejemplo 3: Desarrollo de Otro Ejemplo en forma detallada

Diagramas de UML: Par uso de Sw. Rational Rose o Argo UML o Star UML

Actividad 1

a) Cree un nuevo proyecto.

b) En el nodo raíz del navegador presione el botón derecho del ratón y seleccione Create Package para crear un paquete denominado Actividad 1.

c) Estando sobre el paquete recién creado haga clic con el botón derecho y cree nuevos paquetes que se llaman Editor, Controlador, Elementos de Diagrama, Elementos de Dominio, Núcleo Gráfico, Núcleo Motif, MS Windows, Motif y Sistema de Ventanas.

d) Con el botón derecho sobre el paquete Actividad 1 seleccione Diagrama de Clases y cree el diagrama Actividad 1.

e) Arrastre desde el navegador al diagrama todos los paquetes. Establezca relaciones de generalización ( ) entre paquetes, tal como lo muestra la Figura 1.1. Para representar que un paquete está contenido en otro se puede reflejar dicha relación en el diagrama o modificando la propiedad Espacio de Nombres. Observe cómo se refleja en el navegador cuando un paquete está contenido en otro.

Figura 1.1: Relaciones de composición y generalización entre paquetes

Observación: Constate que al seleccionar un elemento (ya sea en el navegador o en el diagrama) y presionar la tecla Suprimir dicho elemento es borrado del modelo/proyecto. Esto es equivalente a elegir la opción Borrar del Modelo del menú de edición o del menú del elemento. Para eliminar un elemento sólo de un diagrama debe seleccionarse y presionar Ctrl-Suprimir o seleccionar la opción Remove from Diagram. Además, presionando Ctrl en un elemento seleccionado del diagrama aparecen ambas opciones de borrado.

f) Establezca relaciones de dependencia ( ) entre paquetes completando el diagrama hasta obtener el resultado mostrado en la Figura 1.2. Observación: haga clic en el símbolo de dependencia para establecer el nombre del estereotipo.

Página 28 de 43

Figura 1.2: Diagrama resultante de la Actividad 1

g) Imprimir el diagrama. En la versión Poseidón for UML Community Edition las funciones de impresión están deshabilitadas. Sin embargo, esto puede suplirse de la siguiente manera:

Opción A: Con la opción de menú Ficheros|Guardar gráficos puede guardarse el diagrama en algún formato gráficos de los ofrecidos (entre ellos wmf, gif, jpg) y luego imprimirlo o insertarlo, por ejemplo, en un fichero MS Word. Sin embargo en este caso se añade el logotipo de Poseidón como fondo del diagrama. El resultado en nuestro ejempo sería el que se muestra en la Figura 1.3.

Opción B: Visualizar completamente el diagrama. Para esto, si es necesario, se pueden reducir otros paneles y/o ajustar el zoom. A continuación, presionar la tecla Impr-PetSis (tecla de impresión) para capturar la imagen. Abrir el programa Paint u otro editor gráfico compatible. Pegar la pantalla capturada y cortar sólo el área del diagrama. Finalmente, pegar el área del diagrama en el fichero destino, por ejemplo, un documento MS Word. Está es la opción que se ha utilizado para elaborar esta guía.

Editor

Controlador

Elementosde Dominio Núcleo Gráfico

Núcleo Windows

Elementos de Diagrama

<< import >>

<< import >>

<< access >>

<< import >>

<< access >>

Núcleo Motif

Sistema de Ventanas

Motif

MS Windows

<< import >>

<< import >>

<< import >>

Figura 1.3: Fichero gráfico generado

Página 29 de 43

Actividad 2 a) En el mismo proyecto cree un nuevo paquete bajo el nodo raíz, denominado Actividad

2.

b) Seleccione el paquete recién creado y con el botón derecho elija la opción Diagrama de caso de uso para crear el diagrama Actividad 2.

c) Seleccione el diagrama Actividad 2 y dibuje lo mostrado en la figura 2.1.

Figura 2.1: Diagrama Actividad 2

Página 30 de 43

Actividad 3

a) En el mismo proyecto cree un nuevo paquete bajo el nodo raíz, denominado Actividad 3.

b) Seleccione el paquete recién creado y con el botón derecho elija la opción Diagrama de caso de uso para crear el diagrama Actividad 3. Observación: Puede arrastrar el actor Cliente desde el paquete Actividad 2.

Figura 3.1: Diagrama Actividad 3

c) Seleccione en el navegador el paquete Actividad 3 y cree un diagrama de secuencia (desde el menú diagramas o desde la barra de menú. Se insertará un nodo de tipo colaboración, denomínelo Reintegro. Al nuevo diagrama llámelo Reintegro con saldo insuficiente.

d) Seleccione el diagrama Reintegro con saldo insuficiente e introduzca el diagrama mostrado en la Figura 3.2

Figura 3.2: Diagrama Reintegro con saldo insuficiente

Página 31 de 43

e) Seleccione el paquete Actividad 3 y cree un diagrama de colaboración llamado Reintegro con saldo insuficiente. Introduzca el diagrama que se muestra en la Figura 3.3. Uno a uno, seleccione en el navegador los objetos ya creados y con botón derecho elija la opción Añadir al diagrama. Observación: aunque se esperaría que existiera una función para elaborar un diagrama de colaboración a partir de un diagrama de secuencia o viceversa, en Poseidón dicha funcionalidad no se proporciona. Además, los diagramas de colaboración en Poseidón no ofrecen toda la notación que especifica

UML.

Página 32 de 43

Actividad 4

a) En el mismo proyecto cree un nuevo paquete bajo el nodo raíz, denominado Actividad 4.

b) Seleccione el paquete Actividad 4 y cree un diagrama de clases. Introduzca el diagrama de la Figura 4.1. Observación: Para dibujar varios símbolos del mismo tipo (clases, asociaciones o generalizaciones en este ejemplo) haga doble clic en el icono correspondiente en la barra de herramientas del diagrama.

Figura 4.1: Diagrama Actividad 4

Página 33 de 43

Actividad 5

a) En el mismo proyecto cree un paquete bajo el nodo raíz, denominado Actividad 5.

b) Seleccione el paquete Actividad 5 y cree un diagrama de clases. Introduzca la clase Socio con los detalles que aparecen en la Figura 5.1.

c) Seleccione la clase Socio en el navegador y cree un Diagrama de Estados conteniendo el diagrama mostrado en la Figura 5.2.

Figura 5.1: Diagrama Actividad 5

Figura 5.2: Diagrama de Estados para la clase Socio

Página 34 de 43

Actividad 6

a) En el mismo proyecto cree un paquete bajo el nodo raíz, denominado Actividad 6.

b) Seleccione el paquete Actividad 6 y cree un diagrama de despliegue denominado Actividad 6.1. Introduzca el diagrama de componentes que se muestra en la Figura 6.1. Observación: en Poseidón el diagrama de despliegue incluye también la notación para el diagrama de componentes, con lo cual en él se pueden elaborar ambos tipos de diagramas, posibilitando la mezcla de elementos.

c) Seleccione el paquete Actividad 6 y cree un diagrama de despliegue denominado Actividad 6.2. Introduzca el diagrama de despliegue que se muestra en la Figura 6.2.

Figura 6.1 Diagrama de componentes

Figura 6.2 Diagrama de despliegue

Página 35 de 43

Actividad 7

a) Cree un nuevo proyecto. En él reproduciremos parte de una especificación de requisitos para el proyecto denominado ACME.

b) Cree un paquete denominado Modelo de requisitos. A continuación, agruparemos los Casos de Uso según el departamento involucrado, creando paquetes para cada uno de ellos; Contabilidad, Inventario, Publicidad y Ventas.

c) Dentro del paquete Ventas agruparemos los requisitos según actor, mediante los paquetes Requisitos administrativo y Requisitos vendedor. Cada uno de estos paquetes tendrá un diagrama de Casos de Uso con el mismo nombre del paquete. La Figura 7.1 muestra el estado del navegador al final de esta actividad. Observación: de momento sólo establezca la estructura de paquetes.

Figura 7.1: Diagrama ACME

d) En el diagrama Requisitos vendedor introduzca el diagrama que muestra la Figura 7.2.

Figura 7.2: Diagrama Requisitos vendedor

Página 36 de 43

e) En el diagrama Requisitos administrativo introduzca el diagrama que muestra la Figura 7.3.

Figura 7.1: Diagrama ACME

f) Utilizando las especificaciones proporcionadas a continuación, complete el apartado Documentación de los Casos de Uso del diagrama Requisitos vendedor.

Caso de Uso: Venta a cliente de tiendaPrecondición:

El cliente se identifica mostrando su tarjeta y el DNIPasos:

1. El vendedor introduce el código del cliente2. El sistema verifica si se trata de un cliente moroso3. INCLUIR Realizar venta

Caso de Uso: Venta a no clientePrecondición:

El cliente debe pagar en efectivo o con tarjeta de crédito (mostrando su identificación)Pasos:

1. INCLUIR Realizar venta

Caso de Uso: Realizar ventaPasos:

1. El vendedor introduce su código de vendedor2. El sistema muestra la pantalla para introducir los datos de la venta3. El vendedor introduce los artículos mediante un lector de código de barras o

directamente por teclado. Pueden ser incluidos varios artículos en una misma venta. Para cada artículo:

a. El sistema confirma que el artículo tiene suficiente stock para satisfacer la ventab. El sistema calcula el plazo estimado de entregac. El vendedor confirma con el cliente el plazo de entrega

4. El vendedor registra el pago en efectivo o a crédito según el tipo de venta5. El sistema emite el recibo de compra

Caso de Uso: Solicitar autorizaciónPasos:

1. El vendedor introduce solicita un código de autorización por teléfono y lo introduce en el sistema

2. El sistema muestra las condiciones de recargo o de advertencia al cliente3. El vendedor introduce la confirmación por parte del cliente

Página 37 de 43

Actividad 8

a) Elabore una lista de posibles escenarios para el caso de uso Realizar venta de la Actividad 7.

b) Cree un diagrama de secuencia para cada escenario describiendo gráficamente la interacción entre el actor y un objeto denominado sistema. Denomine Realizar venta al nodo colaboración que se creará automáticamente con el primer diagrama de secuencia y cree el resto de diagramas bajo dicho nodo.

c) Bajo el nodo raíz cree un paquete que se denomine Modelo de análisis/diseño. Seleccione un par de escenarios entre los especificados en el punto a) y realice su análisis para establecer posibles objetos/clases que colaborarían para ofrecer el comportamiento esperado del sistema. Bajo el paquete Modelo de análisis/diseño elabore diagramas de secuencia adicionales con los correspondientes nombres de los escenarios de los cuales provienen. Así, en estos nuevos diagramas en lugar de aparecer el objeto sistema, éste sería reemplazado por objetos que colaboran mediante mensajes.

Página 38 de 43

Actividad 9

a) Cree un nuevo proyecto y denomínelo Actividades 9-12. Cree el paquete Actividad 9 y añada bajo este paquete un diagrama de clases con el mismo nombre.

b) Introduzca el diagrama que se muestra en la Figura 9.1. Observación: intente obtener la misma visualización de la figura, consulte al profesor si no lo consigue.

c) Seleccione la clase Alumno y haga clic en la pestaña Previsualización del código en el panel de propiedades del elemento. Analice las correspondencias entre la clase UML y el código. Compruebe las modificaciones posibles de realizar en el código y cómo se reflejan en el código los cambios del diagrama.

Figura 9.1: Diagrama Actividad 9

Página 39 de 43

Actividad 10

a) Añada el paquete Actividad 10 y cree bajo este paquete un diagrama de clases con el mismo nombre.

b) Introduzca el diagrama que se muestra en la Figura 10.1.

c) Seleccione una clase y haga clic en la pestaña Previsualización del código en el panel de propiedades del elemento. Analice las correspondencias entre el diagrama UML y el código.

Figura 10.1: Diagrama Actividad 10

Página 40 de 43

Actividad 11

a) Cree el paquete Actividad 11 y añada bajo este paquete un diagrama de clases con el mismo nombre.

b) Introduzca el diagrama que se muestra en la Figura 11.1.

c) Seleccione una clase y haga clic en la pestaña Previsualización del código en el panel de propiedades del elemento. Analice las correspondencias entre el diagrama UML y el código.

Figura 11.1: Diagrama Actividad 11

Página 41 de 43

Actividad 12

a) Cree el paquete Actividad 12 y añada bajo este paquete los diagramas de clases Actividad 12.1, Actividad 12.2 y Actividad 12.3.

b) Introduzca los diagramas que se muestra en la Figuras 12.1, 12.2 y 12.3, cada uno en su respectivo diagrama de clases.

c) Seleccione clases en los diferentes diagramas, haciendo clic en la pestaña Previsualización del código para analizar las correspondencias entre el diagrama UML y el código.

Figura 12.1: Diagrama Actividad 12.1

Figura 12.2: Diagrama Actividad 12.2

Página 42 de 43

Figura 12.3: Diagrama Actividad 12.3

Página 43 de 43