Modelo Analisis o o Weitzenfeld Corto

INGENIERIA DE SOFTWARE I
MODELO DE ANALISIS
CONCEPTOS
El objetivo del modelo de anlisis es comprender y
generar una arquitectura de objetos para el sistema en
base a lo especificado en el modelo de requisitos.
Durante esta etapa no se considera el ambiente de
implementacin (que incluye al lenguaje de programacin,
manejador de base de datos, distribucin o configuracin
de hardware, etc.), que es posible que cambie incluso
radicalmente
El anlisis pretende modelar el sistema bajo condiciones
ideales, garantizando que la arquitectura de software
resultante sea suficientemente robusta y extensible para
servir de base a la estructura lgica de la aplicacin
pero sin consideraciones relativas al entorno de
implementacin.
MODELO DE ANALISIS
Modelo de anlisis junto con la arquitectura general de objetos en relacin

al modelo de requisitos anteriormente desarrollado.
MODELO DE ANALISIS
ARQUITECTURA DE CLASES
El modelo de anlisis tiene como objetivo generar una
arquitectura de objetos que sirva como base para el
diseo posterior del sistema.
Dependiendo del tipo de aplicacin existen diversas
arquitecturas que se pueden utilizar, siendo de nuestro
inters aquellas arquitecturas especialmente diseadas
para el manejo de los sistemas de informacin.
En trmino de las propias arquitecturas, stas se
distinguen segn la organizacin de la funcionalidad que
ofrecen los objetos dentro de ellas o la dimensin de los
objetos.
MODELO DE ANALISIS
Correspondencia de las dimensiones del Modelo de

Requisitos y el Modelo de Anlisis
Modelo de Requisitos
Modelo de Anlisis
Hemel Castro P. - Universidad
MODELO DE ANALISIS
Arquitectura de Clases
Diagrama de tres dimensiones correspondiente a la arquitectura
MVC Modelo, Vista, Control.
MODELO DE ANALISIS
ARQUITECTURA DE CLASES . . . .
Vista o presentacin de la informacin: corresponde a los
bordes que se le presentan al usuario para el manejo de la
informacin, donde por lo general pueden existir mltiples
vistas sobre un mismo modelo.
La informacin: representa el dominio del problema y es
almacenada en una base de datos.
El control: corresponde a la manipulacin de la informacin a
travs de sus diversas presentaciones.
Aunque existe cierta dependencia entre estas tres
dimensiones se considera que la manera de presentar la
informacin es independiente de la propia informacin y de
cmo esta se controla.
Sin embargo, cada una de ellas probablemente experimente
cambios a lo largo de la vida del sistema, donde el control es
el ms propenso a ser modificado, seguido de la vista y
finalmente la informacin.
MODELO DE ANALISIS (CLASES CON ESTEREOTIPOS)
ESTEREOTIPO
Es el tipo de funcionalidad o la razn de ser de un objeto dentro de una arquitectura
Estereotipo entidad (entity)

Para objetos que guarden informacin
sobre el estado interno del sistema, a
corto y largo plazo, correspondiente al
dominio del problema
Todo comportamiento naturalmente
acoplado con esta informacin
tambin se incluye en los objeto
entidad.
Un ejemplo de un objeto entidad es
un registro de usuario con sus
datos y comportamiento asociados.
Estereotipo interface o borde

(boundary)
Para objetos que implementen la
presentacin o vista correspondiente
a las bordes del sistema hacia el
mundo externo, para todo tipo de
actores, no slo usuarios humanos.
Un ejemplo de un objeto borde es la
funcionalidad de interface de usuario
para insertar o modificar informacin
sobre el registro de usuario
Estereotipo control (control)

Para objetos que implementen el
comportamiento o control especificando
cuando y como el sistema cambia de estado,
correspondiente a los casos de uso.
Los objetos control modelan
funcionalidad que no se liga naturalmente
con ningn otro tipo de objeto, como el
comportamiento que opera en varios objetos
entidad a la vez, por ejemplo, hacer alguna
computacin y luego devolver el resultado a
un objeto borde.
Un ejemplo tpico de objeto control es
analizar el uso del sistema por parte de algn
usuario registrado y presentar tal informacin
posteriormente
Este comportamiento no le pertenece a ningn
objeto entidad u objeto borde especfico
Diagrama mostrando traslape en los estereotipos de los objetos.
MODELO DE ANALISIS (CLASES PARA CASOS DE USO)
La funcionalidad de cada caso de uso es asignada a objetos
distintos y de acuerdo a los estereotipos de dichos objetos
CLASES PARA CASOS DE USO

Cuando se trabaja en el desarrollo del modelo de anlisis,
normalmente se trabaja con un caso de uso a la vez.
Para cada caso de uso se identifican los objetos necesarios
para su implementacin.
Se identifican estos objetos segn sus estereotipos para
corresponder a la funcionalidad ofrecida en cada caso de uso
Se define explcitamente qu objeto es responsable de cual
comportamiento dentro del caso de uso.
Tpicamente se toma un caso de uso y se comienza
identificando los objetos borde necesarios, continuando con
los
objetos entidad y finalmente los objetos control.
Este proceso se contina a los dems casos de uso.
En general, se desea asignar la funcionalidad ms
especializada correspondiente a la poltica de la aplicacin a
los objetos control, la cual depende y afecta al resto de los
CLASES PARA CASOS DE USO. . .

Por otro lado, los objetos entidad y borde deben contener
funcionalidad ms bien local limitando su efecto en los
dems objetos.
Dado que los objetos son ortogonales a los casos de uso,
en el sentido de que un objeto puede participar en varios
casos de uso, este proceso es iterativo.
Esto significa que cuando un conjunto de objetos ya existe,
estos pueden modificarse para ajustarse al nuevo caso de
uso
La meta es formar una arquitectura lo ms estable posible,
reutilizando el mayor nmero de objetos posible.
De tal manera, la descripcin original de los casos de uso
se transforma a una descripcin en base a los tres tipos de
objetos
La funcionalidad de cada caso de uso es asignada a objetos
distintos y de acuerdo a los estereotipos de dichos objetos
PARTICIONAMIENTO DE LOS CASOS DE USO

Se parte el caso de uso de acuerdo a los siguientes principios
La funcionalidad de los casos de uso que depende
directamente de la interaccin del sistema con el mundo
externo se asigna a los objetos borde.
La funcionalidad relacionada con el almacenamiento y
manejo de informacin del dominio del problema se asigna
a los objetos entidad.
La funcionalidad especfica a uno o varios casos de uso y
que no se ponen naturalmente en ningn objeto borde o
entidad se asigna a los objetos control. Tpicamente se
asigna a un slo objeto control y si ste se vuelve muy
complejo se asignan objetos control adicionales.
IDENTIFICACIN DE CLASES SEGN ESTEREOTIPOS

BORDE
1. En base a los actores.
2. En base a las descripciones de las borde del sistema que acompaan al
modelo de requisitos.
3. En base a las descripciones de los casos de uso y extraer la
funcionalidad que es especfica a los bordes.
MODELACION DE CLASES BORDE

Para objetos borde que se comunican con otros sistemas, es muy comn
que la comunicacin se describa mediante protocolos de comunicacin.
Para los objetos borde que se comunican con usuarios humanos, los
objetos borde se pueden modelar con Interfaces Grficas de Usuario
(GUI - Graphical User Interface), Sistemas de Manejo de Ventanas de
Usuario (UIMS - User Interface Management Systems) y sistemas de
Interface de Programacin de Aplicacin (API).
Clases borde para el sistema de reservaciones de

vuelo identificados directamente de los actores
MODELO DE REQUISITOS
MODELO DE ANALISIS
Clases borde identificadas del caso uso Validar Usuario
MODELO DE ANALISIS
Clases borde identificadas del caso uso Registrar Usuario
MODELO DE ANALISIS
Relacin entre casos de uso, actores y clases borde

para el sistema de reservaciones de vuelo

ENTIDAD
Se utilizan objetos entidad para modelar la informacin que el
sistema debe manejar a corto y largo plazo.
La informacin a corto plazo existe por lo general durante la
ejecucin del caso de uso, mientras que la informacin a largo
plazo sobrevive a los casos de uso, por lo cual es necesario guardar
esta informacin en alguna base de datos.
Adicionalmente, se debe incluir comportamiento para manejar la
propia informacin local al objeto entidad.
Los objetos entidad se identifican en los casos de uso, donde la
mayora se identifican del modelo del dominio del problema en el
modelo de requisitos.
Las necesidades de los casos de uso deben ser las guas y
solamente aquellos objetos entidad que puedan justificarse de la
descripcin del caso de uso deben ser incluidos.
Cierta informacin puede modelarse como objeto entidad en un
sistema, mientras que en otro sistema puede ser un atributo

ENTIDAD
lista de las operaciones tpicas que deben ser ofrecidas por un objeto
entidad:
Guardar y traer informacin
Comportamiento que debe modificarse si el objeto entidad cambia
Crear y remover el objeto entidad
Clases entidad identificadas del caso uso Validar Usuario
Este caso de uso requiere validar informacin exclusivamente guardada en
el registro de usuario, lo que se hace en la clase entidad RegistroUsuario,
utilizada tambin por el caso de uso RegistrarUsuario
Clases entidad identificadas del caso uso Registrar Usuario

Este caso de uso requiere guardar informacin exclusivamente acerca del
usuario, lo que se hace en la clase entidad RegistroUsuario
Relacin entre casos de uso y clases entidad para

el sistema de reservaciones de vuelo

CONTROL
En la mayora de los casos de uso, existe un comportamiento que no se
puede asignar de forma natural a ninguno de los otros dos tipos de
objetos, ya que realmente no pertenece de manera natural a ninguno de
ellos.
Una posibilidad es repartir el comportamiento entre los dos tipos de
objetos, como lo sugieren algunos mtodos, pero la solucin no es
buena si se considera el aspecto de extensibilidad.
Para evitar estos problemas tal comportamiento se asigna en objetos
control.
Los objetos de control tpicamente actan como pegamento entre los
otros tipos de objetos y por lo tanto proveen la comunicacin entre los
dems tipos de objetos.
Los objetos control se identifican directamente de los casos de uso
Como primera aproximacin, se asigna un objeto control a cada caso de
uso, concreto y abstracto

CONTROL
Dado que se asigna inicialmente el comportamiento a los objetos
borde y entidad para cada caso de uso, el comportamiento restante se
asigna a los objetos control.
A menudo una manera de asignar el comportamiento es modelar
inicialmente el caso de uso sin ningn objeto control, o sea slo
utilizar objetos borde y objetos entidad.
Cuando tal modelo se ha desarrollado, se ver que hay ciertos
comportamientos que no se asignan de forma natural, ni en los objetos
entidad ni en los objetos borde, o peor an, se dispersan sobre varios
objetos.
Estos comportamientos deben ubicarse en los objetos control.
Sin embargo, puede darse la situacin donde no queda comportamiento
restante para modelar en el caso de uso.
En tal caso no se necesita un objeto control.

CONTROL
Otra situacin es si el comportamiento que queda, despus de distribuir
el comportamiento relevante entre objetos borde y entidad, es
demasiado complicado, la funcionalidad puede ser dividida en varios
objetos control.
Por otro lado, si un caso de uso se acopla a varios actores esto puede
indicar que existen variados comportamientos en relacin a los
diferentes actores y por lo tanto deben asignarse varios objetos
control.
La meta debe ser ligar solo un actor con cada objeto control ya que los
cambios en los sistemas a menudo son originados por los actores y de
tal manera se logra modularizar los posibles cambios.
La estrategia de asignacin de control se debe decidir segn cada
aplicacin.
En la mayora de los casos, sin embargo, se promueve la separacin del
control de un caso de uso en un objeto control que delega funcionalidad
de manejo ms local a los otros dos tipos de objetos.
Clase Control para el caso uso Validar Usuario
Este caso de uso requiere un controlador para manejar la validacin del
registro de usuario. Dado que esto utiliza la misma informacin de registro
podemos como enfoque inicial utilizar la misma clase control que en el caso
de uso anterior, por lo cual utilizamo la clase control
ManejadorRegistroUsuario.
Clases Control para el caso uso Registrar Usuario

Este caso de uso requiere de un controlador para manejar la informacin,
lo que haremos mediante la clase control ManejadorRegistroUsuario
Relacin entre casos de uso y clases control para el sistema

de reservaciones de vuelo
MODELO DE ANALISIS
Clases identificadas para el caso uso Validar Usuario
MODELO DE ANALISIS
Clases identificadas para el caso uso Registrar Usuario
MODELO DE ANALISIS
DIAGRAMAS DE SECUENCIA
Una vez identificadas las clases, se debe describir la

interaccin entre ellas para lograr la funcionalidad de los
casos de uso.
Con base en esta funcionalidad, se definir la arquitectura
del sistema, tanto estructural como funcional
Esto se logra con el concepto de diagramas de secuencias,
interaccin o eventos, los cuales describen los diferentes
casos de uso segn la interaccin o eventos enviados entre
los objetos de la arquitectura del modelo de anlisis,
excluyendo cualquier detalle interno de ellos.
MODELO DE ANALISIS
DIAGRAMAS DE SECUENCIA
Diagrama de secuencia con eventos.

Las barras gruesas corresponden a actividades dentro del objeto, denominadas por a
Las flechas corresponden a eventos, denominadas por e.
Un evento se dibuja como una flecha horizontal que comienza en la barra
correspondiente al objeto que lo enva y termina en la barra correspondiente al objeto
que lo recibe.
MODELO DE REQUISITOS
MODELO DE CASOS DE USO (COMPORTAMIENTO)
Casos de uso completos para el sistema de reservaciones de vuelo
MODELO DE ANALISIS
Clases identificadas para el caso uso Registrar Usuario
MODELO DE ANALISIS
DIAGRAMA DE SECUENCIA CREAR REGISTRO USUARIO (SUBFLUJO) DEL
CASO DE USO REGISTRAR USUARIO
MODELO DE ANALISIS
DIAGRAMA DE SECUENCIA DEL CASO DE USO REGISTRAR USUARIO
Subflujo Crear Registro Usuario

Esta secuencia inicia en el flujo principal de Registrar Usuario
que deber incluir ciertas opciones definidas en Validar
Usuario seguidos por el subflujo Crear Registro Usuario (S-1) y
Administrar Registro Usuario (S-3).
MODELO DE ANALISIS
Validar Usuario.
Aunque la secuencia se inicia en el flujo princial de Registrar
Usuario, se contina inmediatamente con la insercin del caso de
uso Validar Usuario, donde podemos iniciar con el
ManejadorPrincipal solicitando el desplegado de la
PantallaPrincipal mediante el evento desplegarPantallaPrincipal.
Para continuar este secuencia, el usuario deber seleccionar la
opcin de Registrar Por Primera Vez oprimiendo el botn
correspondiente en la pantalla. La InterfaceUsuario por ser la
controladora de las interfaces de usuario, recibe el evento y lo
enva como un nuevo evento Registrar Por Primera Vez a
ManejadorPrincipal.
El ManejadorPrincipal que es el encargado de controlar la lgica
general del sistema, reconoce que este evento corresponde a una
actividad de registro y se lo enva como crearRegUsuario al
MODELO DE ANALISIS
Registrar Usuario subflujo Crear Registro Usuario (S-1).

En este momento el ManejadorRegistroUsuario reconoce el tipo
de evento particular y solicita a la InterfaceUsuario el desplegado
de la pantalla correspondiente mediante
desplegarPantallaCrearRegUsuario.
La InterfaceUsuario despliega esta pantalla, algo que no se
muestra en el diagrama por ser un evento interno. Para continuar
con la lgica principal de este subflujo, el usuario debe llenar sus
datos, que no se muestran aqu, y oprime el botn Registrar para
que esta informacin sea enviada a la clase InterfaceUsuario. Es
importante resaltar que los datos como tales no generan eventos
ni son de importancia en estos diagramas. Lo que genera eventos
son los botones en las pantallas.
Siguiendo con nuestra lgica, la InterfaceUsuario enva el evento
Registrar al ManejadorRegistroUsuario.
MODELO DE ANALISIS
Registrar Usuario subflujo Crear Registro Usuario (S-1). . .

Este controlador es responsable de guardar la informacin de
registro del usuario, por lo cual enva el evento
crearRegUsuario a la InterfaceBaseDatosRegistro.
Ntese que como en el caso de los datos, los objetos entidad
como la clase RegistroUsuario, tampoco son mostrados en el
diagrama, dado que no agregan eventos interesantes para la
lgica del sistema. Incluso se omiten del diagrama todas las clases
correspondientes a pantallas ya que sus eventos importantes son
manejados por la InterfaceUsuario.
Prosiguiendo con nuestra lgica, la InterfaceBaseDatosRegistro
enva el evento crearRegUsuario al actor Base de Datos Registros.
Este actor debe responder de alguna manera, y lo hace mediante
un OK el cual es luego enviado de manera sucesiva hasta llegar al
MODELO DE ANALISIS
Registrar Usuario subflujo Administrar Registro Usuario (S-3). .

A continuacin pasamos al subflujo Administrar Registro Usuario
(S-3) donde el El ManejadorRegistroUsuario enva el evento
desplegarPantallaObtenerRegUsuario a la InterfaceUsuario.
En ese momento el Usuario presiona Salir, dando por concluida la
secuencia.
En resumen, la secuencia podr iniciar con el caso de uso Validar
Usuario seguido de los subflujos Crear Registro Usuario (S-1) y
Administrar Registro Usuario (S-3) del caso de uso Registrar
Usuario.
MODELO DE ANALISIS
DOCUMENTACION DE CASOS DE USO
A partir de las diversas secuencias analizadas y descritas

en los diagramas de secuencias, podemos generar una
descripcin casi completa de los casos de uso del sistema
Para lograr este paso, tomamos todas las descripciones y
las insertamos en los flujos o subflujos correspondientes de
los diversos casos de uso.
Dado que las secuencias no mencionan todos los posibles
eventos sino los principales, podemos en este momento
completar los que sean necesarios.
En particular deberemos asegurarnos que no existan
discontinuidades entre las secuencias de eventos.
Cualquier cambio en la lgica en las secuencias o casos de
uso deber reflejarse tambin en los diagramas de
secuencia.
MODELO DE ANALISIS
DOCUMENTACION DE CASOS DE USO
En las descripciones de los casos de uso, estaremos

subrayando las clases y escribiendo en letras cursivas los
nombres de los eventos entre clases.
Es muy importante que las frases sean claras y concisas, ya
que esto facilitar posteriormente el diseo
MODELO DE ANALISIS
DICCIONARIO DE CLASES SEGN MDULOS
Como ltima etapa del modelo de anlisis, se actualiza el

diccionario de datos originalmente descrito para el
dominio del problema para incluir todas las clases
identificadas durante el modelo de anlisis.
Aunque no es obligatorio, aprovechamos para separar estas
clases en diferentes mdulos para lograr una mejor
organizacin y correspondencia entre clases y casos de uso.
Aquellas clases que participan en varios casos de uso se
pueden asignar a mdulos adicionales, como veremos a
continuacin para el sistema de reservaciones de vuelo.
MODELO DE REQUISITOS -ANALISIS
El modelo del dominio del problema puede hacerse bastante

complejo en el caso de sistema de gran tamao, para lo cual es
necesario separar las clases en mdulos.
El modelo completo se dividira en una coleccin de mdulos,
donde cada mdulo es una agrupacin lgica de clases y sus
asociaciones correspondientes
Sistema Reservaciones de vuelo
Mdulo Registro
Clases que guardan
informacin sobre
el usuario del Sistema
Mdulo Servicios
Clases que guardan
informacin sobre
vuelos, pasajeros, y
reservaciones
MODELO DE ANALISIS
Mdulos principales del sistema de reservaciones de vuelo
MODELO DE ANALISIS
Mdulo InterfaceUsuario
Est compuesto por una sla clase:
1. InterfaceUsuario Clase Borde. Toda la interaccin con el usuario se
hace por medio de la borde de usuario.
Mdulo Principal
Est compuesto por dos clases:
1. PantallaPrincipal - Clase Borde. Pantalla principal (P-1).
2. ManejadorPrincipal - Clase Control. El manejador principal es el
encargado de desplegar la pantalla principal de interaccin con el
usuario, y luego delegar las diferentes funciones a los manejadores
especializados apropiados.
MODELO DE ANALISIS
Mdulo Registro
Se divide en los siguientes mdulos:
MODELO DE ANALISIS
Mdulo Registro
Mdulo Usuario
Est compuesto por las clases:
1.
PantallaCrearRegUsuario - Clase Borde. Pantalla de solicitud de
registro de usuario (P-3).
2.
PantallaObtenerRegUsuario - Clase Borde. Pantalla de devolucin
con informacin de registro de usuario (P-4).
3.
RegistroUsuario - Clase Entidad. Para poder utilizar el sistema de
reservaciones, el usuario debe estar registrado con el sistema. El
registro contiene informacin acerca del usuario que incluye nombre,
direccin, colonia, ciudad, pas, cdigo postal, telfono de casa, telfono
de oficina, fax, email, login y password.
4.
ManejadorRegistroUsuario - Clase Control. El manejador de registro
de usuario se encarga de todo lo relacionado con registro del usuario
para poder utilizar el sistema.
MODELO DE ANALISIS
Mdulo Registro
Mdulo Tarjeta
Est compuesto por las clases:
1.
PantallaCrearRegTarjeta - Clase Borde. Pantalla de solicitud de
registro
de tarjeta (P-5).
2.
PantallaObtenerRegTarjeta - Clase Borde. Pantalla de devolucin
con
informacin de registro de tarjeta (P-6).
3.
RegistroTarjeta - Clase Entidad. Para poder hacer un pago con una
tarjeta de crdito, se debe tener un registro de tarjeta. El registro
contiene informacin acerca de la tarjeta incluyendo nombre, nmero,
expedidor y vencimiento. LA tarjeta est ligada a un registro de usuario.
4. ManejadorRegistroTarjeta - Clase Control. El manejador de registro de
tarjeta se encarga de todo lo relacionado con registro de la tarjeta del
usuario para poder pagar las reservaciones.
MODELO DE ANALISIS
Mdulo Registro
Mdulo InterfaceBD
Correspondiente a la interface para la base de datos, est compuesto por la
clase encargada de interactuar con la base de datos:
1.
InterfaceBaseDatosRegistro - Clase Borde. La informacin de cada
usuario se almacena en la base de datos de registro la cual se accesa
mediante la borde de la base de datos de registro. Esto permite validar a
los distintos usuarios adems de guardar informacin sobre la tarjeta de
crdito para pagos en lnea.

Modelo Analisis o o Weitzenfeld Corto

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Modelo Analisis o o Weitzenfeld Corto

Uploaded by

Copyright:

Available Formats

INGENIERIA DE SOFTWARE I

Modelo de anlisis junto con la arquitectura general de objetos en relacin

Correspondencia de las dimensiones del Modelo de

Hemel Castro P. - Universidad

Es el tipo de funcionalidad o la razn de ser de un objeto dentro de una arquitectura

Estereotipo entidad (entity)

Estereotipo interface o borde

Estereotipo control (control)

Diagrama mostrando traslape en los estereotipos de los objetos.

CLASES PARA CASOS DE USO

CLASES PARA CASOS DE USO. . .

PARTICIONAMIENTO DE LOS CASOS DE USO

IDENTIFICACIN DE CLASES SEGN ESTEREOTIPOS

MODELACION DE CLASES BORDE

Clases borde para el sistema de reservaciones de

Clases borde identificadas del caso uso Validar Usuario

Clases borde identificadas del caso uso Registrar Usuario

Relacin entre casos de uso, actores y clases borde

IDENTIFICACIN DE CLASES SEGN ESTEREOTIPOS

IDENTIFICACIN DE CLASES SEGN ESTEREOTIPOS

Clases entidad identificadas del caso uso Registrar Usuario

Relacin entre casos de uso y clases entidad para

IDENTIFICACIN DE CLASES SEGN ESTEREOTIPOS

IDENTIFICACIN DE CLASES SEGN ESTEREOTIPOS

IDENTIFICACIN DE CLASES SEGN ESTEREOTIPOS

Clases Control para el caso uso Registrar Usuario

Relacin entre casos de uso y clases control para el sistema

Clases identificadas para el caso uso Validar Usuario

Hemel Castro P. - Universidad

Clases identificadas para el caso uso Registrar Usuario

Hemel Castro P. - Universidad

Una vez identificadas las clases, se debe describir la

Diagrama de secuencia con eventos.

Casos de uso completos para el sistema de reservaciones de vuelo

Hemel Castro P. - Universidad

Clases identificadas para el caso uso Registrar Usuario

Hemel Castro P. - Universidad

Subflujo Crear Registro Usuario

Registrar Usuario subflujo Crear Registro Usuario (S-1).

Registrar Usuario subflujo Crear Registro Usuario (S-1). . .

Registrar Usuario subflujo Administrar Registro Usuario (S-3). .

A partir de las diversas secuencias analizadas y descritas

En las descripciones de los casos de uso, estaremos

Como ltima etapa del modelo de anlisis, se actualiza el

El modelo del dominio del problema puede hacerse bastante

Hemel Castro P. - Universidad

Mdulos principales del sistema de reservaciones de vuelo

You might also like