Está en la página 1de 15

Sistemas de informacin hipermedia permiten a los usuarios compartir informacin a travs de

una variedad de medios tales como texto, vdeo, imagen y voz. Sistemas Hipermedia puede ser
ampliamente utilizado para la World Wide Web (WWW) aplicaciones a travs de Internet o
Intranet [6]. Hipermedia extender el paradigma hipertextual en multimedia. El hipertexto es una
manera no secuencial de ver la informacin basada en texto. Aunque manuales, libros, informes, o
de algunos otros documentos pueden ser almacenados en un sistema informtico de manera
secuencial manera, hipertexto proporciona una interfaz para que cualquier nmero de enlaces no
secuenciales puede permitir a un usuario acceder a un elemento de inters, incluso si no es la
siguiente elemento almacenado secuencialmente-. En lugar de la navegacin entre los objetos de
texto, ofrecen enlaces hipermedia entre el conjunto espectro de informacin multimedia [26].
Hipermedia desarrollo, especialmente en un escala comercial, a menudo involucra equipos de
desarrolladores que tenga que ser gestionado y coordinado a travs de una perodo de tiempo
extendido. Desarrollo de los sistemas formales y las tcnicas de gestin de proyectos son
necesarios para garantizar que el producto hipermedia cumple sus objetivos, y se completa a
tiempo y dentro del presupuesto [14]. Por lo tanto, no es sorprendente observar que la
investigacin de metodologas de desarrollo de hipermedia est activo (por ejemplo HDM [8],
EORM [18], RMM [14], y OOHDM [24]).
HDM (Hypermedia Design Method) proporciona la primer modelo formal para aplicaciones
hipermedia. es basado en una tcnica orientada a objetos que alienta el uso de diferentes
perspectivas en la presentacin de la misma entidad conceptual. EORM (Enhanced Object Modelo
de Relacin) es la primera orientada a objetos metodologa de diseo de hipermedia. EORM
consiste tres marcos: marco de la clase, la composicin marco, y la interfaz grfica de usuario
(GUI) marco. RMM (Relationship Management Model) utiliza Entidad-Relacin (E-R) abstracciones;
que mejora HDM por el uso de estructuras de acceso adicional (ndices condicionales y visitas
guiadas). fases RMM incluir el diseo ER, diseo rebanada, diseo de navegacin, el diseo del
protocolo de conversin, el diseo de interfaz de usuario, diseo de comportamiento en tiempo
de ejecucin, y la construccin / testing.
OOHDM (Object Oriented Hypermedia Design Model), otra metodologa orientada a objetos,
adopta cuatro fases de diseo como el diseo conceptual, diseo de navegacin, diseo de
interfaz abstracta y aplicacin. Un diseo hipermedia vista basada metodologa (VHDM) ha sido
propuesto por Lee et al. [20]. Las vistas se utilizan para representar la percepcin de los usuarios
requisitos hipermedia. VHDM facilita la exploracin la funcionalidad de las vistas en las
aplicaciones hipermedia. Estudios anteriores tienen varios puntos dbiles. En primer lugar, se
emplear relaciones entre los datos para la determinacin de rutas de navegacin. Estas relaciones
orientadas a datos en aislamiento puede no reflejar la navegacin de los usuarios requisitos
satisfactoriamente. En segundo lugar, la integracin de los hipermedia con bases de datos
empresariales no es suficiente enfatizado, en vista de su importancia para la Intranet aplicacin.
En tercer lugar, la investigacin en el pasado adoptar modelos de datos conceptuales para
capturar los requerimientos de los usuarios.
Estos modelos no pueden proporcionar la flexibilidad que sistemas hipermedia requieren.
Para resolver los problemas anteriores, este trabajo se desarrolla un diseo de hipermedia
orientada a objetos basado en escenarios metodologa (SOHDM). El paradigma de objeto
orientacin se debe extender a la hipermedia entorno de desarrollo en su conjunto [26]. SOHDM
tiene varias caractersticas nuevas. identifica SOHDM requisitos para aplicaciones hipermedia de la
a partir del desarrollo del sistema. Se utilizan Escenarios para mejorar la capacidad expresiva de la
modelizacin. en particulares puntos de vista, orientados a objetos se utilizan comounidades de
navegacin, as como vistas de usuario lgicas.
2. Metodologa Arquitectura
SOHDM consta de seis fases: anlisis de dominio, modelado de objetos, la vista de diseo, diseo
de la navegacin, diseo de la aplicacin, y la construccin. la marco de SOHDM se representa en
la Figura 1. Para el propsito de la presentacin ms clara, la retroalimentacin entre fases no se
representan en la Figura 1. Sin embargo, la retroalimentacin es importante para el anlisis de la
refinacin o salidas de diseo en cada fase.
ANALISIS DE DOMINIO
MODELADO DE OBJETOS
Diagrama de Contexto
Lista de Evento
Escenarios
VISTA DE DISEO
CRC
CSD
VISTA DE DISEO
Vista OO
CRC
DISEO PAGINA
DISEO DEL INTERFACE DE
USUARIO
DISEO DE BASE DE
DATOS LOGICOS
CRC
CSD
Escenarios
Vista OO Vista OO
Enlace de Navegacional
Pagina de Esquema
CONSTRUCCION
Especificacin de
Interfaz de Usuario
Esquema de
Base de Datos Fisica
DISEO DE
IMPLEMENTACION

Arquitectura de SOHDM
En la fase de anlisis de dominio, un diagrama de contexto es dibujado para representar los
lmites del sistema. Adicionalmente, se emplean escenarios para identificar los requisitos de los
usuarios. Los escenarios dan lugar a un modelo de objetos dentro del marco de la colaboracin de
clases Responsabilidades (CRC) [30]. Para una mejor representacin de las relaciones entre clases
de objetos, una estructura de clases Diagrama (CSD) se dibuja. En la fase de diseo de la visin,
orientada a objetos (OO) vistas son extrados de las tarjetas CRC. OO vistas son unidades de
navegacin, en el diseo de la navegacin.
La fase de diseo de navegacin define Acceso Nodos de Estructura (ASN) y enlaces de
navegacin. ASN contiene la estructura de acceso y la ruta de vistas OO. para aras de la
conveniencia, enlaces de navegacin son presentado en la forma de una matriz de enlace de
navegacin.
Fase de diseo de implementacin define ventanas de los usuarios (por ejemplo, un conjunto de
pginas HTML) y los flujos de navegacin de una pgina a otra pgina. Adems, se detalla
interfaces de usuario (UI) estn diseados. OO puntos de vista pueden ser transformado en el
esquema de base de datos relacional. Claramente, independencia de base de datos est
garantizada [4]. Por ltimo, una sistema de informacin hipermedia se construye lo que
representa el esquema de base de datos fsica resultante y la interfaz de usuario especificaciones.
3. Metodologa Detalles
Aqu explicamos cada fase de SOHDM con ms detalles, mediante el uso de un sistema de
aplicacin de la vida real. La aplicacin ha operado en una arquitectura cliente / servidor para uno
de los bancos ms importantes de Corea del Sur. El banco es interesados actualmente en una
infraestructura de Intranet, y as SOHDM se aplica para la construccin de un hipermedia sistema
para esta aplicacin.
3.1 Anlisis de Dominio
En primer lugar, un diagrama de alcance del sistema se seala a delimitar el sistema hipermedia a
desarrollar. Una de datos bien conocida diagrama de flujo (DFD) [31] se utiliza. Tpicamente, un
contexto diagrama (por ejemplo, el nivel cero DFD) es una buena alternativa. Para nuestro SI
(Sistema de Cuenta Bancaria), el alcance del sistema diagrama se dibuja como se muestra en la
Figura 2. El banco sistema de contabilidad tiene tres entidades externas, tales como gestin, el
cliente, y la rama. Los eventos se identifican para cada entidad externa. un evento se define como
el gatillo que se inicia el sistema [15]. Cuatro eventos se encuentran, como se muestra en la Tabla
1.
SOHDM utiliza escenarios para identificar hipermedia requisitos de las aplicaciones de la mayor
brevedad posible.
Cartas de la actividad Escenario (ZEC) se han desarrollado para describir escenarios. SAC describe
los procesos de negocio de acuerdo a los actores. Un actor es un operador de concreto
actividades, es decir, un creador de eventos. Notacin de las ZEC es las entidades externas dadas
en la Figura 3. Son los primeros candidatos para los actores de las ZEC. Un evento es un punto de
partida punto, un disparador de un escenario. Una actividad es una operacin por el cual un actor
completa un escenario. Una alternancia es una actividad que permite a un actor para elegir el
siguiente actividad. Un flujo de actividad es una secuencia de actividades. La terminacin es el final
de un escenario.
CLIENTE
SISTEMA DE
CONTABILIDAD DEL
BANCO
ADMINISTRACION
SUCURSAL
Numero de Cuenta
Informacion de Cuenta
Informacion de Sucursal
Nombre de la Sucursal
Informacion del
Cliente
ID. Cliente

Diagrama de Alcance del Sistema
Lista de Evento
Entidad Fuente Nombre del Evento
Sucursal
Solicitar Informacin Total*
Solicitar Informacin del Cliente
Cliente
Comprobar Cuenta
Identificar Tipo Bancario del Producto
Administracin Solicitar Informacin Total*

*El mismo Evento




NOTACION DEL SAC

Figura 4. "Comprobar Cuenta" Escenario

Figure 6. Solicitar Informacion Total Escenario
3.2 Modelado de objetos
Escenarios en las ZEC se utilizan para el modelado de objetos. Escenarios se transforman en
objetos en forma de Tarjetas CRC. Las tarjetas de CRC se adoptan porque tener un atractivo
informal atractivo que ayuda a hacer complejo manejable modelado. Objetos se generan de los
escenarios de la siguiente manera.
En primer lugar, los actores son los candidatos principales para los objetos; entonces Se
consideran actividades. Escenarios (Figura 4,5, y 6) generar candidatos a objetos como cliente
actual, cliente potencial, cuenta, rama, y la transaccin. En particular, otro objeto, cliente, un
super conjunto de cliente actual y el objeto cliente potencial, es obtenido.


Figure 5. Solicitud de informacin al cliente Escenario
Four SAC se generan a partir de los cuatro eventos. para En aras de la simplicidad, tres escenarios
se ilustran en Las figuras 4, 5, y 6. Por ejemplo, la Figura 5 representa la SAC para el evento de
"Solicitud de Informacin del cliente". Los clientes se agrupan en dos categoras, como los clientes
actuales y potenciales clientes, y la informacin del cliente se proporciona para cada categora.
Clase: Cliente Super Clase:
Atributos:
ID_Cliente
Nombre_Cliente
Direccion_Cliente
Telefono_Cliente
Cliente_Credito
SubClase :
Cliente_Actual
Cliente_Futuro
Colaboradores:
Componentes:
Responsabilidades:
Conocer_Credito
Conocer_Informacion del Cliente Asociadores:


Clase: Cliente_Actual Super Clase: Cliente
Atributos:
Fecha_Inicial_Cliente_Actual
SubClase :
Colaboradores:
Cuenta
Transaccion
Componentes:
Responsabilidades:
Comprobar_Cuenta de Saldo
Comprobar_Cuenta de Transaccion
Conocer_Cliente Actual
Asociadores:
Cuenta (N)
Saldo(N)





Clase: Cliente_Futuro Super Clase: Cliente
Atributos:
Encuentro_Memo
SubClase :
Colaboradores:
Cuenta
Transaccion
Componentes:
Responsabilidades:
Conocer_Encuentro Memo Cliente
Futuro Asociadores:
Sucursal(1)





Clase: Cuenta Super Clase:
Atributos:
Numero_Cuenta
Saldo_Cuenta
Fecha_Registro_Cuenta
Tipo_Cuenta
SubClase :
Colaboradores:
Transaccion
Componentes:
Responsabilidades:
Comprobar_Transaccion
Conocer_Saldo Asociadores:
Sucursal(1)
Cliente_Actual(1)
Transaccion(N)





Clase: Sucursal Super Clase:
Atributos:
Codigo_Sucursal
Nombre_Sucursal
Direccion_Sucursal
Telefono_Sucursal
SubClase :
Colaboradores:
Cuenta
Cliente_Actual
Cliente_Futuro
Componentes:
Responsabilidades:
Comprobar_Total de Tipo de Cuenta
Comprobar_Cliente Actual
Comprobar_Cliente Futuro
Conocer_Total de Sucursal
Asociadores:
Cuenta(N)
Cliente_Actual(N)
Cliente_Futuro(N)
Transaccion(N)





Clase: Transaccion Super Clase:
Atributos:
Codigo_Transaccion
Fecha_Transaccion
Tipo_Transaccion
Cantidad_Transaccion
SubClase :
Colaboradores:
Componentes:
Responsabilidades:
Conocer_Transaccion
Asociadores:
Cuenta(1)
Sucursal(1)

Figura 7: Tarjetas CRC
A continuacin, los objetos identificados se documentan en formateada fichas, tarjetas CRC. Aqu,
Wirfs-Borck et al 's.
CRC originales se ampliaron para incluir listas de atributos y asociadores. Adems, la cardinalidad
de asociacin es representado en un soporte. Las tarjetas pueden ser especificados en varias
ocasiones por el refinamiento. Seis clases de objetos (clientes, Current_Customer,
Prospective_Customer, cuenta, Rama, y transacciones) se modelan como se muestra en la
Figura 7. Por ejemplo, en el Current_Customer CRC, se observa que su superclase es cliente y su
subclase no existe. Hereda de la clase Current_Customer atribuciones y responsabilidades de la
clase Cliente. lo tiene Current_Customer_Initial_Date como un atributo y Check_Account_Balance
y Check_Transaction como responsabilidades.
Cuatro tipos de relaciones se representan en los CRC (superclase / subclase, colaboradores,
componentes y asociadores). Para presentar estas relaciones ms efectivamente, se prepara un
CDS se muestra en la Figura 8