metodologia de aplicacion web.doc.docx

SOHDM Es un Mtodo que Desarrolla Diseo en panoramas (scenario) Orientada a Objetos en Hipermedia (Scenario based Object-oriented Hypermedia Design Methodology). Presenta la necesidad de disponer de un proceso que permita capturar las necesidades del sistema. Para ello, propone el uso de escenarios. Es una de las primeras propuestas para la web y brinda ms importancia a la tarea de tratamiento de requisitos. Se caracteriza principalmente porque su ciclo de vida comienza con la aplicacin de los escenarios como tcnica de elicitacin y definicin de requisitos.El proceso de definicin de requisitos parte de la realizacin de un diagrama de contexto tal y como se propone en los diagramas de flujos de datos (DFD) de Yourdon (1989). En este diagrama de contexto se identifican las entidades externas que se comunican con el sistema, as como los eventos que provocan esa comunicacin. La lista de eventos es una tabla que indica en qu eventos puede participar cada entidad. Por cada evento diferente, SOHDM propone elaborar un escenario. Estos son representados grficamente mediante los denominados SACs2 (ScenarioActivity Chart). Cada escenario describe el proceso de interaccin entre el usuario y el sistema cuando se produce un evento determinado, especificando el flujo de actividades, los objetos involucrados y las transacciones realizadas. SOHDM propone un proceso para conseguir a partir de estos escenarios el modelo conceptual del sistema, que es representado mediante un diagrama de clases. El proceso de SOHDM contina reagrupando estas clases para conseguir un modelo de clases navegacionales del sistema. Consiste en seis fases: anlisis del dominio, modelado del objeto, diseo de la visin, diseo de la navegacin, diseo de la puesta en prctica y construccin. Esta metodologa tiene semejanzas con, OOHDM y EORM donde se diferencian en el uso de panoramas, que describen las actividades en los acontecimientos y primitivas de flujos de actividades. Los panoramas se definen en la fase de anlisis y se utilizan para modelar los objetos

1. CONCEPTOS BSICOS DE SOHDMSOHDM es una metodologa para el desarrollo de aplicaciones multimedia que se divide en seis fases que hay que realizar de forma secuencial. Sin embargo, el proceso de desarrollo es un proceso cclico en el sentido de que al realizar una fase se puede regresar a alguna de las anteriores para refinarla y adaptarla mejor.Como su propio nombre indica, SOHDM est basado en los escenarios para elaborar las aplicaciones multimedia. En su proceso, los escenarios se elaboran en la fase de anlisis para capturar los requisitos funcionales del sistema y sirven como base para el resto del proceso. A pesar de que SOHDM se asemeja bastante a OOHDM y EORM, difiere de ellas en el sentido de que mientras que estas dos metodologas slo trabajan en la fase de diseo, SOHDM engloba tambin la fase de anlisis.

2. FASES DE SOHDMEn la figura siguiente se presenta un esquema en el que se detallan las fases y los productos obtenidos en cada una de ellas y cmo los productos obtenidos en una fase sirven como referencia para la fase siguiente

Sin embargo, a pesar de que el modelo est pensado como secuencial, permite volver atrs en cualquiera de las etapas del proceso. A continuacin se presentarn cada una de estas fases.

2.1 FASE DE ANLISIS DEL DOMINIO:

En la fase de anlisis se debe realizar un estudio de las necesidades de la aplicacin, del entorno de trabajo y de los actores. La finalidad principal de esta fase es conseguir los escenarios que representen las actividades que se pueden llevar a cabo en el sistema.

Para ello, lo primero que se debe realizar es un diagrama de contexto tal y como se propone en diagramas de flujos de datos [Yourdon 1989]. En este diagrama de contexto es necesario detectar a las entidades externas que se comunican con el sistema, as como los eventos que provocan esa comunicacin.

Una vez detectados estos eventos, se debe elaborar lo que se denomina lista de eventos.

En esta tabla se detallan todas las entidades en la columna de la izquierda y en la columna de la derecha todos los eventos en los que cada una participa.

EJEMPLO:

Para nuestro ejemplo, la nica entidad externa que tenemos es el usuario. Podramos detectar, por ejemplo que se ve afectado por el evento de conectarse al sistema y el de peticin de datos, quedando nuestra tabla como la que se muestra en la siguiente tabla.

Partiendo de esta tabla, por cada evento diferente se debe elaborar un escenario. stos se van a representar mediante los denominados SACs2 (Scenario Activity Chart). En estos escenarios se va a describir el proceso de trabajo que se va a seguir en el sistema cuando se produzca la situacin que el escenario representa.

EJEMPLO:Por ejemplo, en la figura siguiente nos encontramos un escenario en el que se describe cmo se produce la conexin al sistema del usuario.

2.2 FASE DE MODELADO DE OBJETOS:

Los escenarios representados mediante SACs son usados para conseguir modelar los objetos del sistema. En la fase de modelado de objetos, los escenarios van a ser transformados en objetos segn la propuesta de los CRC Cards (Class Responsability Collaboration) [Wirfs-Brock 1990]. Esta propuesta tiene como objetivo presentar un formato sencillo e informal para conseguir un diccionario de datos para las clases del sistema. En ellas cada clase tiene asociado una ficha (CRC Cards) en la que se almacena: su nombre, sus atributos, su superclase, sus subclases, sus componentes, las asociaciones en las que participa, las otras clases con las que colabora y los eventos detallados en los SACs de los que es responsable.

Las CRC Cards irn acompaadas de un diagrama de clases, CSD (Class Structure Diagram), que representar grficamente lo recogido en las CRC Cards.

2.3 FASE DE DISEO DE VISTAS:

En la fase de diseo de vistas, los objetos sern reorganizados en unidades navegacionales. Una unidad navegacional representa una vista de los objetos del sistema. Las vistas van a estar muy relacionadas con el concepto de nodos de OOHDM.

La vista es una agrupacin de informacin que se presenta agrupada al usuario bajo un determinado criterio.

En SOHDM, las vistas pueden ser:

Vistas base; son aquellas que toman todos los datos que muestra de una nica clase.

Vistas de asociacin; toma los datos de dos clases que se encuentran relacionadas mediante una asociacin en el modelo de clases.

Vistas de colaboracin; toma los datos de clases que se encuentran relacionadas mediante una relacin de colaboracin.

2.4 Fase de Diseo Navegacional:

En el diseo navegacional se van a definir los enlaces o hiperenlaces que existen entre las diferentes vistas. Aqu las vistas definidas en la fase anterior se relacionan a travs de estructuras de acceso.

El primer paso a realizar es definir lo que se conoce como nodos de estructuras de acceso (ASNs). Estos son nodos especiales como diccionarios, mens, etc. que sirven como punto de partida para la navegacin. Una vez definidos los ASN, estos y las vistas definidas en la fase anterior, se conectan mediante flechas que indican el sentido de la navegacin. Se obtiene as un grafo en el que se representa como se navega desde un punto de informacin (vista o ASN) a otro. A este modelo se le denomina enlaces navegacionales.

A pesar de que el grafo que surge es bastante intuitivo, SOHDM propone una alternativa para representar los enlaces navegacionales. Por cada componente conexa de este grafo, se elabora una matriz, denominada matriz de enlaces navegacionales. En esta matriz se indica como los nodos de esa componente se relacionan entre s.

El grafo resultante de esta fase y de la anterior para nuestro ejemplo, puede recordarnos bastante al modelo de clases navegacionales de OOHDM. El concepto es el mismo ,cambia en las denominaciones: el nodo pasa a llamarse vista y las clases ndices a estructuras de acceso y los enlaces son direccionales. En la figura anterior se ve el resultado para nuestro ejemplo. Vemos que desde el men podemos navegar a los datos de identificacin del bien y a los datos de descripcin. Desde estos se puede volver almen. Ntese que al tener un bien varios valores para los datos de descripcin, lamultiplicidad en este enlace es de 0..n.2.5 FASE DE DISEO DE LA IMPLEMENTACIN:

En esta fase se van a generar esquemas de pginas que van a representar los puntos de informacin definidos en la fase anterior dentro de un entorno determinado. Para cada esquema se debe indicar: su nombre, su ttulo, las vistas que engloba, una breve descripcin de su significado y una lista con los enlaces que tiene.

Tras definir estos puntos de informacin se hace un diseo de la interfaz de usuario.

SOHDM tiene prevista una nomenclatura normalizada para representar los posibles elementos que se pueden encontrar en una pantalla: botones, imgenes, listas, etc.

Una vez definida la interfaz de usuario y los esquemas, es necesario definir la base de datos. En principio las aplicaciones hipermedia deben definirse en sistemas gestores orientados a objeto, pero, acercndose ms a la realidad, permite el uso de sistemas gestores de bases de datos relacionales. Para poder llevar una representacin orientada a objetos a un modelo relacional, es necesario aplicar tcnicas de conversin. Los autores de SOHDM proponen las detalladas en [Fong 1995] y [Blaha 1988].

2.6 FASE DE CONSTRUCCIN:

En este paso los desarrolladores generan una aplicacin hipermedia, la cual cumple con todas las caractersticas especificadas en las fases anteriores.

Se realiza la construccin de la base de datos del sistema. La que se implementa la aplicacin

EJEMPLO PRCTICO

CONSTRUCCION DE UN SISTEMA WEB BIBLIOTECA VIRTUAL

FASE I:ANLISIS DEL DOMINIO

1. DIAGRAMA DE CONTEXTO

2. LISTA DE EVENTOS

NOMBRE DE LA ENTIDAD EXTERNANOMBRE DEL EVENTO

ALUMNOINGRESO AL SISTEMA

VISTA LIBROS

DESCARGA DE LIBROS

REGISTRO

SUGERENCIA LIBROS

DOCENTEINGRESO AL SISTEMA

PETICION DE DATOS

VISTA LIBROS

DESCARGA DE LIBROS

REGISTRO

SUGERENCIA LIBROS

ADMINISTRADORREGISTRA BIBLIOTECARIO(A)

BIBLIOTECARIAINGRESO AL SISTEMA

REVISION DE SUGERENCIAS

SUBE LIBROS A LA WEB

3. ESCENARIOS :

3.1 PARA EL ALUMNO:

A) ESCENARIO PARA INGRESO AL SISTEMA:1. El alumno se conecta al sistema2. El sistema solicita la clave , login3. El alumno ingresa la clave y login4. El sistema comprueba que la clave y login es correcto5. El sistema da acceso al men principal

B) ESCENARIO PARA DESCARGAR LIBRO:1. El alumno busca el libro que desea2. El alumno visualiza libro solicitado3. Alumno descarga libro4. El sistema muestra opcin donde guardar el libro5. El alumno guarda el libro

C) ESCENARIO REGISTRO DEL ALUMNO:1. El alumno solicita ser registrado2. El sistema solicita datos personales del alumno3. El alumno ingresa los datos solicitados por el sistema4. El alumno enva sus datos al sistema5. El sistema autoriza o deniega datos del alumno6. El sistema avisa al alumno si fue registrado o no

D) ESCENARIO ENVIAR SUGERENCIA:1. El alumno ingresa al men de sugerencia2. El sistema muestra formulario para sugerencia3. Al alumno llena dicho formulario4. El alumno enva su sugerencia

E) ESCENARIO VISUALIZAR LIBRO:1. El alumno ingresa al sistema.2. El sistema muestra diferentes libros3. El alumno busca el libro que requiere4. El alumno visualiza libro

3.2 PARA EL DOCENTE:

A) ESCENARIO PARA INGRESO AL SISTEMA:1. El docente se conecta al sistema2. El sistema solicita la clave , login3. El docente ingresa la clave y login4. El sistema comprueba que la clave y login es correcto5. El sistema da acceso al men principalB) ESCENARIO PARA DESCARGAR LIBRO:1. El docente busca el libro que desea2. El docente visualiza libro solicitado3. El docente descarga libro4. El sistema muestra opcin donde guardar el libro5. El docente guarda el libro

C) ESCENARIO REGISTRO DEL ALUMNO:1. El docente solicita ser registrado2. El sistema solicita datos personales del docente3. El docente ingresa los datos solicitados por el sistema4. El docente enva sus datos al sistema5. El sistema autoriza o deniega datos del docente6. El sistema avisa al docente si fue registrado o noD) ESCENARIO ENVIAR SUGERENCIA:1. El docente ingresa al men de sugerencia2. El sistema muestra formulario para sugerencia3. Eldocente llena dicho formulario4. El docente enva su sugerencia

F) ESCENARIO VISUALIZAR LIBRO:1. El docente ingresa al sistema.2. El sistema muestra diferentes libros3. El docente busca el libro que requiere4. El docente visualiza libro

3.3 PARA EL ADMINISTRADOR:

A) ESCENARIO REGISTRAR BIBLIOTECARIO(A):1. Administrador ingresa al sistema.2. administrador ingresa datos de bibliotecario(a)3. administrador otorga permisos4. administrador registra bibliotecario(a)

3.4 PARA LA BIBLIOTECARIA:

A) ESCENARIO PARA INGRESO AL SISTEMA:1. El bibliotecario(a) se conecta al sistema2. El sistema solicita la clave , login3. El bibliotecario(a) ingresa la clave y login4. El sistema comprueba que la clave y login es correcto5. El sistema da acceso al men principal

B) ESCENARIO PARA REVISION DE SUGERENCIAS:1. El bibliotecario(a) ingresa a la opcin de sugerencias2. El sistema informa sobre las sugerencias de libros que tiene pendiente3. El bibliotecario(a) revisa sugerencias

C) ESCENARIO PARA SUBIR LIBROS A LA WEB:1. El bibliotecario(a) ingresa a la opcin de libros2. El sistema informa sobre los diferentes libros que se encuentran guardados3. El bibliotecario(a) ingresa los diferentes datos del libro a subir4. El bibliotecario(a) ingresa el archivo del libro5. El bibliotecario(a) valida los datos del libro6. El bibliotecario(a) registra libro

FASE II:MODELADO DE OBJETOS

UNIVERSIDAD JOSE CARLOS MARIATEGUIIngenieria Web Biblioteca Virtual

45 | Pgina

1. SAC`S1.1 ALUMNO :

1.2 DOCENTE:

1.3 ADMINISTRADOR:

1.4 BIBLIOTECARIO(A)

2. DIAGRAMA CSD:

3. 4. TARJETAS CRC:3.1 USUARIO:

3.2 VISUALIZACION:

3.3 TIPO DE USUARIO:

3.4 MATERIAL:

3.5 CARRERA:

3.6 TIPO_MATERIAL:

FASE III:DISEO DE VISTAS

1. VISTAS BASE:1.1 USUARIO:

1.2 MATERIAL:

1.3 VISUALIZACION:

2. VISTAS ASOCIACION:2.1 USUARIO-VISUALIZACION

2.2 MATERIAL-VISUALIZACION

3. VISTAS COLABORACION:3.1 VISUALIZACION_USUARIO:

3.2 VISUALIZACION _MATERIAL:

FASE IV:DISEO NAVEGACIONAL

FASE V:DISEO IMPLEMENTACION

1. ALUMNO/DOCENTE:

2. BIBLIOTECARIO(A):

FASE VI:CONSTRUCCION

3. CONCLUSIONESSOHDM es una propuesta bastanteinteresante pues cubre todas las fases del proceso de desarrollo, obviando laimplantacin y las pruebas.SOHDM es una propuesta joven que no ha sido muy usada an. Tiene como ventajaque es un proceso sencillo de seguir, aunque se le puede criticar el hecho de que sunomenclatura est muy cerrada. Por ejemplo, para el desarrollo de la interfaz se definecmo se representa una imagen o un botn en el modelo, aunque no se dice nada decmo se representa un elemento de audio, sin dejar ninguna opcin a que el diseadorpudiese definir su propia representacin.Esta propuesta es hasta ahora la nica que tiene en cuenta aspectos como la especificacin de requisitos haciendo uso de los escenarios. Otra ventaja es que es un proceso sencillo de seguir, no obstante su nomenclatura es muy cerrada. Adems es una propuesta donde se hacen uso de tcnicas de modelado orientado a objetos, algo muy significativo ya que es adecuado para el desarrollo de este tipo de aplicaciones

+usar_sistema()

-cod_usuario-nombre_usuario-apellidos_usuario-login_usuario-password_usuario-carrera_usuario

USUARIO+usar_sistema()

-cod_usuario-nombre_usuario-apellidos_usuario-login_usuario-password_usuario-carrera_usuario

USUARIO_VISTA-cod_material-nombre_material-autor_material-login_usuario-password_usuario-cod_carrera-anio_material-cod_tipo_material

MATERIAL-cod_material-nombre_material-autor_material-login_usuario-password_usuario-cod_carrera-anio_material-cod_tipo_material

MATERIAL_VISTA+mostrar material()

-cod_material-cod_usuario

VISUALIZACION+mostrar material()

-cod_material-cod_usuario

VISUALIZACION_VISTA+usar_sistema()

-cod_usuario-nombre_usuario-apellidos_usuario-login_usuario-password_usuario-carrera_usuario

USUARIO+mostrar material()

-cod_material-cod_usuario

VISUALIZACION+usar_sistema()+mostrar_material()

-cod_usuario-nombre_usuario-apellidos_usuario-login_usuario-password_usuario-carrera_usuario-cod_material

USUARIO_VISUALIZACION_VISTA+mostrar material()

-cod_material-cod_usuario

VISUALIZACION-cod_material-nombre_material-autor_material-login_usuario-password_usuario-cod_carrera-anio_material-cod_tipo_material

MATERIAL+mostrar_material()

-cod_material-nombre_material-autor_material-login_usuario-password_usuario-cod_carrera-anio_material-cod_tipo_material-cod_usuario

MATERIAL_VISUALIZACON_VISTA

+usar_sistema()

-cod_usuario-nombre_usuario-apellidos_usuario-login_usuario-password_usuario-carrera_usuario

USUARIO+mostrar material()

-cod_material-cod_usuario

VISUALIZACION+usar_sistema()+mostrar_material()

-cod_usuario-nombre_usuario-apellidos_usuario-login_usuario-password_usuario-carrera_usuario-cod_material

VISUALIZACION_USUARIO_VISTA

+mostrar material()

-cod_material-cod_usuario

VISUALIZACION-cod_material-nombre_material-autor_material-login_usuario-password_usuario-cod_carrera-anio_material-cod_tipo_material

MATERIAL+mostrar_material()

-cod_material-nombre_material-autor_material-login_usuario-password_usuario-cod_carrera-anio_material-cod_tipo_material-cod_usuario

VISUALIZACON_MATERIAL_VISTA

ClaseActorestado

ClaseActoractorReferenciaestado

ClaseActoractorReferenciaestado