Facilitador: Ing. Jorge Alarcón

Presentación del tema: "Facilitador: Ing. Jorge Alarcón"— Transcripción de la presentación:

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

2 Metodologías para el desarrollo Web
AGENDA UWE OOHDM CUADRO COMPARATIVO CONCLUSIONES Y RECOMENDACIONES

3 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

4 Visión de los Modelos de Desarrollados para Ingeniería WEB
UWE es un producto de la evolución de varios modelos estos son

5 Puntos Relevantes Metamodelo= Modelo de modelos
MOF= STANDART DE OMT PARA MODELAMIENTO EN UWE MDD= MODEL DRIVEN DEVELOPMENT MDA= MODEL DRIVEN ARCHITECTURE

6 Modelo Navegacional de UWE

7 Arquitectura de UWE

8 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 funcionales 1.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 Web 2.2. Modelo Navegacional que contiene estructuras de hipertexto y la funcionalidad de la navegación 2.3. Modelo de Presentación con las hojas de esquema del aplicativo Web 2.4. Modelo de Procesos que incluya la funcionalidad del aplicativo

9 Estructura de UWE

10 1.2.1 ANÁLISIS DE REQUERIMIENTOS CON CASOS DE USO
El 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 1.2.2 REPRESENTACIÓN UML DEL MODELO CONCEPTUAL El 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. ANÁLISIS DE REQUERIMIENTOS CON CASOS DE USO El 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 CONCEPTUAL El 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.

11 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.

12 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

13 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.

14 METODOLOGÍA OOHDM 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

15 Etapas de la metodología OOHDM

16 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 tareas 2.-Especificación de escenarios 3.-Especificación de casos de uso 4.-Especificación de UIDs 5.-Validación de casos de uso y UIDs

17 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.

18 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.

19 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”

20 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”

21 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.

22 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.

23 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:

24 4ta. ETAPA: Diseño de Interfaz Abstracta
Una 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

25 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.

26 CUADRO COMPARATIVO ENTRE UWE & OOHDM
Pros 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, y Hennicker & 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

27 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. 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. Se define desde un inicio donde integrar el software. Solo existe una herramienta para el modelamiento de los UID.

28 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

29 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

30 Gracias por su atención