Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

30
Facilitador: Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza

Transcript of Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Page 1: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Facilitador: Ing. Jorge Alarcón

Grupo: Jenny Ruiz

Mario Amache Edwin Chasiquiza

Page 2: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Metodologías para el desarrollo Web

AGENDA1. UWE

2. OOHDM

3. CUADRO COMPARATIVO

4. CONCLUSIONES Y RECOMENDACIONES

Page 3: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Metodología UWE

•UML está basado en la ingeniería web(UWE), que apoya el desarrollo de aplicaciones Web•Es una propuesta orientada a objetos iterativa e incremental •Establece elementos necesarios para modelar diferentes aspectos de una aplicación web como : Navegación, Diseño y presentación

Page 4: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Visión de los Modelos de Desarrollados para Ingeniería WEB

UWE es un producto de la evolución de varios modelos estos son

Page 5: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Puntos RelevantesMetamodelo= Modelo de modelos

MOF= STANDART DE OMT PARA MODELAMIENTO EN UWE

MDD= MODEL DRIVEN DEVELOPMENT

MDA= MODEL DRIVEN ARCHITECTURE

Page 6: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Modelo Navegacional de UWE

Page 7: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Arquitectura de UWE

Page 8: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

ARTEFACTOS DE ANALISIS Y DISEÑO UTILIZADOS EN UWE

1. Modelos de Análisis para aplicativos WEB:1.1. Modelos de Casos de Uso para análisis de requerimientos

funcionales1.2. Modelos de Dominio de Información para la abstracción de

datos.

2. Modelos de Diseño para aplicativos WEB:2.1. Modelo de Contenidos que informe sobre los aspectos

(información) del aplicativo Web2.2. Modelo Navegacional que contiene estructuras de

hipertexto y la funcionalidad de la navegación2.3. Modelo de Presentación con las hojas de esquema del

aplicativo Web2.4. Modelo de Procesos que incluya la funcionalidad del

aplicativo

Page 9: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Estructura de UWE

Page 10: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

ANÁLISIS DE REQUERIMIENTOS CON CASOS DE USOEl diagrama de casos de uso representa la interacción entre un Actor (usuario) y el sistema a desarrollarse. También muestra la forma, el orden y el tipo de elementos que van a usarse en el proyecto. Los diagramas de casos de uso tienen tres elementos principales que son: • Actor• Casos de Uso• Relaciones de Uso, Herencia y Comunicación

REPRESENTACIÓN UML DEL MODELO CONCEPTUALEl diseño conceptual está basado en el análisis de requerimientos. Éste incluye los objetos involucrados en la interacción entre el usuario y la aplicación, especificado en los casos de uso.

El objetivo principal del diseño conceptual es construir un modelo de clase con estos objetos, ignorando muchos aspectos de las rutas de navegación, presentación e interacción como sea posible.

Page 11: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

CONSTRUCCIÓN DEL MODELO DE ESPACIO DE NAVEGACIÓN

Construir el modelo de navegación no solo es útil para la documentación de la aplicación, sino también permite un aumento de la visión más estructurado respecto a la navegabilidad.

El modelo de navegación está compuesto por:

• Modelo espacial de navegación• Modelo estructural de navegación

Al momento de construir el modelo espacial de navegación, se deciden las vistas del modelo conceptual y las rutas de navegación para la funcionalidad requerida en la aplicación. Estas decisiones se basan en el modelo conceptual y la especificación de requerimientos elaborada con casos de uso.

Page 12: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

El modelo de estructura de navegación es construido en base al modelo de espacio de navegación, puede ser considerado como un paso de refinamiento en el modelado UWE, proporciona un conjunto de pautas y los mecanismos semiautomáticos para la construcción del modelo; este modelo da lugar a una especificación muy concreta casi trasladable automáticamente a unidades de implementación, en el que se describe como la navegación es apoyada por elementos de acceso tales como índices, tours guía, queries y menús, de tal manera que, las rutas de navegación junto con los elementos de acceso son presentados por un modelo de clase el cual puede ser construido sistemáticamente desde el modelo espacial de navegación en dos pasos:

•El primer paso consiste en reforzar el modelo espacial de navegación con índices, tour guía y queries. •El segundo consiste en derivar menús directamente del modelo. Los menús representan posibles opciones para la navegación. El resultado es un diagrama de clases UML construido con símbolos, los mismos que son definidos de acuerdo al mecanismo de extensión del UML

Page 13: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

CONSTRUYENDO EL FLUJO DE LA PRESENTACIÓN

Para el modelo de presentación se utiliza una forma particular un diagrama de clases. El propósito de este punto es modelar la dinámica de la presentación mostrando donde serán presentados al usuario los objetos y elementos de acceso, es decir en qué marco o ventana será desplegado el contenido además en donde será reemplazado cuando el link sea activado. En primer lugar el diseñador debe especificar si será usada la técnica de simple o múltiple ventana, si serán usados los marcos; en ese caso, en cuantos frames serán divididos. En el caso de una ventana sin frames cada click produce únicamente un reemplazo completo del contenido de la ventana por un nuevo contenido; El flujo de la presentación se visualiza con modelos de interacción, es decir diagramas de secuencia UML.

Page 14: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

OOHDM (Método de diseño hipermedia orientado a objetos) es una metodología de desarrollo propuesta por Rossi y Schwabe (ROSSI 1996) para la elaboración de aplicaciones multimedia y tiene como objetivo simplificar y a la vez hacer más eficaz el diseño de aplicaciones hipermedia.

OOHDM está basada en HDM, en el sentido de que toma muchas de las definiciones, sobre todo en los aspectos de navegación

OOHDM es una mezcla de estilos de desarrollo basado en prototipos, desarrollo iterativo e incremental

METODOLOGÍA OOHDM

Page 15: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Etapas de la metodología OOHDM

Page 16: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

1ra. ETAPA: Obtención de requerimientos Como en todo proyecto informático la obtención de

requerimientos es una de las etapas más importantes, la mayoría de los estudios entregan resultados claros que los errores más caros son los que se cometen en esta etapa.

Para enfrentar esta dificultad, OOHDM propone dividir esta etapa en cinco subetapas: 1.-Identificación de roles y tareas2.-Especificación de escenarios3.-Especificación de casos de uso 4.-Especificación de UIDs5.-Validación de casos de uso y UIDs

Page 17: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Identificación de roles y tareas • En esta subetapa el analista deberá

introducirse cuidadosamente en el dominio del sistema, ahora su principal labor será identificar los diferentes roles que podrían cumplir cada uno de los potenciales usuarios de la aplicación.

• En el ejemplo ¨Cursos ofertados por Internet¨, una examinación inicial podría revelar los siguientes posibles roles: Alumno, Potencial Alumno, Profesor, Agente de Ventas, Secretaria, Coordinador. Para efectos de validación de los casos de uso es muy importante tener identificado el rol de cada usuario, ya que serán ellos los que entregarán su conformidad con respecto al caso de uso en el que participan.

Page 18: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Especificación de escenarios Son descripciones narrativas de cómo la

aplicación será utilizada. Cada usuario deberá especificar textual o verbalmente los escenarios que describen su tarea.

A continuación, en la figura se muestran dos escenarios obtenidos en el ejemplo.

Page 19: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Especificación de casos de uso Un caso de uso es una forma de utilizar la aplicación.

Específicamente representa la interacción entre el usuario y el sistema, agrupando las tareas representadas en los escenarios existentes.

En la siguiente figura se describe el caso de uso “Buscando un curso dado un tema”

Page 20: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Especificación de UIDs (Diagramas de Interacción de Usuario) La secuencia de información intercambiada entre el

usuario y el sistema debe ser identificada y organizada en las interacciones.

A continuación se muestra el UID: ” Ver notas a través de código del alumno”

Page 21: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Validación de casos de uso y UIDs

En esta etapa, el desarrollador deberá interactuar con cada usuario para validar los casos de uso y UIDs obtenidos, mostrando y explicando cada uno de ellos para ver si el o los usuarios están de acuerdo. El usuario deberá interceder sólo en aquellos casos de uso y UIDs en que participa.

Page 22: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

2da. ETAPA: Diseño Conceptual En esta etapa se genera un modelo conceptual, donde se

definen las clases, relaciones y cardinalidades, de acuerdo a reglas que se aplican sobre los UIDs. Cabe destacar que gran parte de ellas provienen de las técnicas de normalización.

Page 23: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

3ra. ETAPA: Diseño Navegacional• Se desarrolla una topología navegacional que permita a

la aplicación ejecutar todas las tareas requeridas por el usuario. La idea principal es unificar una serie de tareas para obtener el diseño navegacional de la aplicación.

• A continuación se muestra el Diagrama de contexto final:

Page 24: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

4ta. ETAPA: Diseño de Interfaz AbstractaUna vez finalizado el diseño navegacional, será

necesario especificar las diferentes interfaces de la aplicación. Esto significa definir de qué manera aparecerán los objetos navegacionales en la interfaz y cuales objetos activarán la navegación. Para lograr esto se utilizarán ADVs(Vista de Datos Abstracta), modelos abstractos que especifican la organización y el comportamiento de la interfaz

Page 25: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

5ta. ETAPA: Implementación • Una vez que ya se ha identificado la

información que será mostrada, cómo estará organizada y cuáles funciones permitirá ejecutar la aplicación. Además de ello, cuenta con una idea básica de cómo se verán las interfaces.

• Para comenzar con la implementación el desarrollador deberá elegir dónde almacenará los objetos y con qué lenguaje o herramienta desarrollará las interfaces; es necesario aclarar que, generalmente el desarrollador se encarga del lado técnico de la interfaz; la parte gráfica y el que le dará la apariencia final a la interfaz será el diseñador gráfico.

Page 26: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

CUADRO COMPARATIVO ENTRE UWE & OOHDMPros Contras

Metodología

UWE

Debe tener identificado, el rol de cada usuario, ya que serán ellos los que entregarán su conformidad con respecto al caso de uso en el que participan.

Al representar un caso de uso se debe realizar varios diagramas, Caso de uso, secuencia, colaboración, actividad y genera mucha documentación

Se realiza un modelado orientado a objetos fácil de entender por el conocimiento previo de UML.

No define donde se integrara el software

Se puede utilizar varias herramientas case para el modelado.

Los bocetos, storyboards, y el modelo de presentación permiten una mejor comprensión para el desarrollador y ayuda bastante en la toma de decisiones.

Utiliza lenguaje de restricción de objetos (OCL) para aumentar exactitud de modelos

Parte del enfoque de UWE es la creación sistemática de la combinación de la notación UML(1999) y su perfil (Baumeister, Koch & Mandel, 1999, yHennicker & Koch, 2000, y Koch, 2000), la extensión de UML basada en los mecanismos de extensión definidos por el propio UML incluye artefactos: El modelo navegacional y aspectos de presentación de las aplicaciones WEB se usan para mostrar las propiedades descriptivas y restrictivas de los elementos de modelado

Se basa en modelo orientado a objetos respetando sus principios y paradigmas

Page 27: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

CUADRO COMPARATIVO ENTRE UWE & OOHDM

Pros Contras

Metodología

OOHDM

Debe tener identificado, el rol de cada usuario, ya que serán ellos los que entregarán su conformidad con respecto al caso de uso en el que participan.

No se puede modelar cuando se trabaja con múltiples actores

Posee una notación diagramática bastante completa, que permite representar en forma precia los casos de uso.

El diseño navegacional es tedioso

Ayuda a entender y lograr en cada etapa lo que el usuario realmente necesita.

No se puede modelar cuando se trabaja con múltiples actores

Ofrece la posibilidad de crear estructuras de reusó, tales como los “esqueletos” o “frameworks”, cuyo principal objetivo es simplificar las tareas de diseño y disminuir su consumo de recursos.

El diseño navegacional es tedioso

Se define desde un inicio donde integrar el software. Solo existe una herramienta para el modelamiento de los UID.

Posee una notación diagramática bastante completa, que permite representar en forma precia los casos de uso.

Page 28: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

CONCLUSIONES Y RECOMENDACIONES

•Habitualmente el desarrollo de Sistemas Hipermediales suele hacerse utilizando directamente herramientas a nivel de implementación, descuidándose el importante proceso previo de análisis y diseño de los aspectos estructurales de la navegación e interfaz.

•Una de las desventajas que posee OOHDM corresponde a la redundancia de información presentada por los diagramas necesarios de cada etapa.

•Toda metodología de desarrollo de software integra las Fases de Ingeniería , en el caso particular de UWE y OOHDM permiten desarrollar aplicativos Web , incluyen el modelo navegacional que a través de elementos como: índex, queries, etc... Facilitan el acceso y el control de la navegabilidad del aplicativo WEB

Page 29: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

•Recomendac ión Todo proyecto Orientado a la WEB, debe realizarse bajo los estándares estrictos de una metodología, la ingeniería web basada en UML (UWE)y OOHDM garantizan no pasar por alto ciertos detalles de análisis y diseño así como brinda solidez a la aplicación. Cualquier metodología que se escoja, debería ser complementada con herramientas, para ayudar a un diseño y análisis más efectivo

Page 30: Facilitador:Ing. Jorge Alarcón Grupo: Jenny Ruiz Mario Amache Edwin Chasiquiza.

Gracias por su atención