2. MÉTODOLOGÍAS PARA EL DESARROLLO DE SOFTWARE...

Modelos de Desarrollo Web Primavera 2020 Dr. Mario Rossainz López

7

2. MÉTODOLOGÍAS PARA EL DESARROLLO DE

SOFTWARE BASADO EN WEB

2.1. INTRODUCCIÓN

El desarrollo de aplicaciones web involucra decisiones no triviales de diseño e

implementación que inevitablemente influyen en todo el proceso de desarrollo, afectando la

división de tareas. Los problemas involucrados, como el diseño del modelo del dominio y

la construcción de la interfaz de usuario, tienen requerimientos disjuntos que deben ser

tratados por separado.

El alcance de la aplicación y el tipo de usuarios a los que estará dirigida son

consideraciones tan importantes como las tecnologías elegidas para realizar la

implementación. Así como las tecnologías pueden limitar la funcionalidad de la aplicación,

decisiones de diseño equivocadas también pueden reducir su capacidad de extensión y

reusabilidad. Es por ello que el uso de una metodología de diseño y de tecnologías que se

adapten naturalmente a ésta, son de vital importancia para el desarrollo de aplicaciones

complejas.

Existen en la actualidad tecnologías ampliamente usadas para el desarrollo de aplicaciones

web, pero muchas de ellas obligan al desarrollador a mezclar aspectos conceptuales y de

presentación. Esto sucede principalmente con aquellas tecnologías no basadas en objetos.

La elección de tecnologías complejas demora el proceso e incrementa los costos, pero en

ocasiones permite adecuarse a metodologías de diseño más fácilmente. Tal es el caso de las

tecnologías orientadas a objetos, las cuales tienden a demorar el desarrollo en etapas

tempranas. El tiempo de desarrollo en la actualidad es crítico, tanto por razones de

marketing como por límites en el presupuesto y los recursos, pero la adopción de estas

tecnologías hace que el mantenimiento se transforme en una actividad más simple, la

división en capas sea tarea natural del desarrollo y el tiempo invertido en el diseño facilite

el trabajo necesario para el resto de las actividades.

2.2. APLICACIONES WEB Y SU DESARROLLO EN CAPAS

Las aplicaciones hipermedia han evolucionado en los últimos años y se han concentrado

mayormente en la web. La complejidad del desarrollo ocurre a diferentes niveles: dominios

de aplicación sofisticados (financieros, médicos, geográficos, etc.); la necesidad de proveer

acceso de navegación simple a grandes cantidades de datos multimedia, y por último la

aparición de nuevos dispositivos para los cuales se deben construir interfaces web fáciles de

usar. Esta complejidad en los desarrollos de software sólo puede ser alcanzada mediante la

separación de los modelos. La metodología OOHDM (Object Oriented Hypermedia Design

Method), presentada en la siguiente sección, ha sido utilizada para diseñar diferentes tipos

de aplicaciones hipermedia como galerías interactivas, presentaciones multimedia y

aplicaciones web. El éxito de esta metodología es la clara identificación de los tres

diferentes niveles de diseño en forma independiente de la implementación: conceptual,

navegacional y de interfaz; y aplicar las tecnologías adecuadas a cada capa en el proceso de

implementación.


8

2.3. OOHDM: METODOLOGIA DE DISEÑO HIPERMEDIA

ORIENTADA A OBJETOS

Las metodologías tradicionales de ingeniería de software, o las metodologías para sistemas

de desarrollo de información, no contienen una buena abstracción capaz de facilitar la tarea

de especificar aplicaciones hipermedia. El tamaño, la complejidad y el número de

aplicaciones crecen en forma acelerada en la actualidad, por lo cual una metodología de

diseño sistemática es necesaria para disminuir la complejidad y admitir evolución y

reusabilidad. Producir aplicaciones en las cuales el usuario pueda aprovechar el potencial

del paradigma de la navegación de sitios web, mientras ejecuta transacciones sobre bases de

información, es una tarea muy difícil de lograr. En primer lugar, la navegación posee

algunos problemas. Una estructura de navegación robusta es una de las claves del éxito en

las aplicaciones hipermedia. Si el usuario entiende dónde puede ir y cómo llegar al lugar

deseado, es una buena señal de que la aplicación ha sido bien diseñada.

Construir la interfaz de una aplicación web es también una tarea compleja; no sólo se

necesita especificar cuáles son los objetos de la interfaz que deberían ser implementados,

sino también la manera en la cual estos objetos interactuarán con el resto de la aplicación.

En hipermedia existen requerimientos que deben ser satisfechos en un entorno de desarrollo

unificado (UML). Por un lado, la navegación y el comportamiento funcional de la

aplicación deberían ser integrados. Por otro lado, durante el proceso de diseño se debería

poder desacoplar las decisiones de diseño relacionadas con la estructura navegacional de la

aplicación, de aquellas relacionadas con el modelo del dominio.

OOHDM propone el desarrollo de aplicaciones hipermedia a través de un proceso

compuesto por cuatro etapas: diseño conceptual, diseño navegacional, diseño de interfaces

abstractas e implementación.

2.3.1. DISEÑO CONCEPTUAL

Durante esta actividad se construye un esquema conceptual representado por los objetos del

dominio, las relaciones y colaboraciones existentes establecidas entre ellos.

En OOHDM, el esquema conceptual está construido por clases, relaciones y subsistemas.

Las clases son descritas como en los modelos orientados a objetos tradicionales. Sin

embargo, los atributos pueden ser de múltiples tipos para representar perspectivas

diferentes de las mismas entidades del mundo real. Se usa notación extendida UML

(Lenguaje de Modelado Unificado) y tarjetas de clases y relaciones similares a las tarjetas

CRC (Clase Responsabilidad Colaboración). El esquema de las clases consiste en un

conjunto de clases conectadas por relaciones. Los objetos son instancias de las clases. Las

clases son usadas durante el diseño navegacional para derivar nodos, y las relaciones que

son usadas para construir enlaces.


9

2.3.2. DISEÑO NAVEGACIONAL

La primera generación de aplicaciones web fue pensada para realizar navegación a través

del espacio de información, utilizando un simple modelo de datos de hipermedia. En

OOHDM, la navegación es considerada un paso crítico en el diseño aplicaciones. Un

modelo navegacional es construido como una vista sobre un diseño conceptual, admitiendo

la construcción de modelos diferentes de acuerdo con los diferentes perfiles de usuarios.

Cada modelo navegacional provee una vista subjetiva del diseño conceptual. El diseño de

navegación es expresado en dos esquemas: el esquema de clases navegacionales y el

esquema de contextos navegacionales. En OOHDM existe un conjunto de tipos

predefinidos de clases navegacionales: nodos, enlaces y estructuras de acceso. La semántica

de los nodos y los enlaces son las tradicionales de las aplicaciones hipermedia, y las

estructuras de acceso, tales como índices o recorridos guiados, representan los posibles

caminos de acceso a los nodos.

La principal estructura primitiva del espacio navegacional es la noción de contexto

navegacional. Un contexto navegacional es un conjunto de nodos, enlaces, clases de

contextos, y otros contextos navegacionales (contextos anidados). Pueden ser definidos por

comprensión o extensión, o por enumeración de sus miembros. Los contextos

navegacionales juegan un rol similar a las colecciones y fueron inspirados sobre el

concepto de contextos anidados. Organizan el espacio navegacional en conjuntos

convenientes que pueden ser recorridos en un orden particular y que deberían ser definidos

como caminos para ayudar al usuario a lograr la tarea deseada.

Los nodos son enriquecidos con un conjunto de clases especiales que permiten de un nodo

observar y presentar atributos (incluidos las anclas), así como métodos (comportamiento)

cuando se navega en un particular contexto.

2.3.3. DISEÑO DE INTERFAZ ABSTRACTA

Una vez que las estructuras navegacionales son definidas, se deben especificar los aspectos

de interfaz. Esto significa definir la forma en la cual los objetos navegacionales pueden

aparecer, cómo los objetos de interfaz activarán la navegación y el resto de la funcionalidad

de la aplicación, qué transformaciones de la interfaz son pertinentes y cuándo es necesario

realizarlas.

Una clara separación entre diseño navegacional y diseño de interfaz abstracta permite

construir diferentes interfaces para el mismo modelo navegacional, dejando un alto grado

de independencia de la tecnología de interfaz de usuario.

El aspecto de la interfaz de usuario de aplicaciones interactivas (en particular las

aplicaciones web) es un punto crítico en el desarrollo que las modernas metodologías

tienden a descuidar. En OOHDM se utiliza el diseño de interfaz abstracta para describir la

interfaz del usuario de la aplicación de hipermedia. El modelo de interfaz ADVs (Vista de

Datos Abstracta5) especifica la organización y comportamiento de la interfaz, pero la

apariencia física real o de los atributos, y la disposición de las propiedades de las ADVs en

la pantalla real son hechas en la fase de implementación.


10

2.3.4. IMPLEMENTACION

En esta fase, el diseñador debe implementar el diseño. Hasta ahora, todos los modelos

fueron construidos en forma independiente de la plataforma de implementación; en esta

fase es tenido en cuenta el entorno particular en el cual se va a correr la aplicación.

Al llegar a esta fase, el primer paso que debe realizar el diseñador es definir los ítems de

información que son parte del dominio del problema. Debe identificar también, cómo son

organizados los ítems de acuerdo con el perfil del usuario y su tarea; decidir qué interfaz

debería ver y cómo debería comportarse. A fin de implementar todo en un entorno web, el

diseñador debe decidir además qué información debe ser almacenada.

2.4. COMPARATIVO DE METODOLOGÍAS

En la tabla siguiente se presenta un comparativo de distintas metodologías extraídas de

parte de la bibliografía que sustenta este documento, teniendo en cuenta:

• los pasos que componen el proceso

• la técnica de modelado

• la representación gráfica

• la notación elegida para los modelos y

• la herramienta CASE de soporte proporcionada para el desarrollo

Las metodologías comparadas son:

• HDM (Hypermedia Design Method - Método de Diseño Hipermedia)

• RMM (Relationship Management Methodology - Metodología de Administración de

Relaciones)

• EORM (Enhanced Object Relationship Methodology - Metodología de Relaciones de

Objetos Mejorada)

• OOHDM (Object Oriented Hypermedia Design Method - Metodología de Diseño

Hipermedia orientada a objetos)

• SOHDM (Scenario-based Object-oriented Hypermedia Design Methodology -

Metodología de Diseño Hipermedia basada en escenarios),

• WSDM (Web Site Design Method - Método de Diseño de Sitios Web) y

• WAE-Proceso Conallen (Web Application Extension for UML – Process Conallen -

Extensión de Aplicación Web para UML).


11

En la tabla siguiente se presenta un segundo comparativo, que relaciona los conceptos de

diseño de los tres niveles típicos de diseño web: conceptual, estructural y visible. La

mayoría de estos métodos realizan una clara separación entre el análisis del dominio, la

especificación de la estructura navegacional y el diseño de la interfaz de usuario.


12

2.5. METODOLOGIA UWE

La metodología UWE (UML-based Web Engineering – Ingeniería Web basada en UML)

presentada por Hennicker y Koch soporta el desarrollo de aplicaciones Web con un especial


13

interés en la sistematización, personalización y generación semi-automática de código. Es

una metodología iterativa e incremental orientada a objetos basada en el Lenguaje de

Modelado Unificado (UML) y en Proceso Unificado de Desarrollo de Software (PUDS).

UWE se centra en actividades de modelado tales como el análisis de requerimientos y el

diseño conceptual, de navegación y de presentación complementado con modelado de

tareas y visualización de escenarios Web. Existe una aplicación encargada de la generación

semi-automática de código Web en base a los modelos de diseño generados llamada

ArgoUML.

2.5.1. CASOS DE USO PARA LA ESPECIFICACION DE REQUERIMIENTOS

Un modelo de casos de uso se utiliza para describir los requerimientos funcionales de una

aplicación en terminos de los “casos de uso”. Un caso de uso UML es una unidad coherente

de funcionalidad proporcionada por la aplicación que interactúa con uno o más actores que

estan fuera de la aplicación. Un caso de uso describe una pieza del comportamiento de la

aplicación sin definir su estructura interna.

En esta sección se muestra como los requerimientos para una aplicación Web pueden ser

especificados con un modelo de casos de uso. Como sabemos, los diagramas de casos de

uso son construidos utilizando tres elementos principales en el modelado con UML: los

casos de uso, los actores y las relaciones entre estos elementos, tales como las asociaciones

entre un actor y un caso de uso y las dependencias <<includes>> y <<extendsí>> entre

casos de uso.

Como un ejemplo que ilustra las técnicas UML utilizadas en UWE, se muestra el sitio Web

de una biblioteca en línea personalizada. Esta aplicación de biblioteca en linea ofrece

información sobre las publicaciones registradas por usuarios anónimos. Una publicación

captura información sobre revistas, libros y proceedings. Estas publicaciones son descritas

mediante un título, un número, una publicación, una fecha de publicación y un conjunto de

artículos y autores por cada artículo. Los libros consisten de exactamente un artículo cuyo

titulo es el mismo que el título del libro. Además se asocian un conjunto de palabras clave a

cada artículo y a cada publicación.

Identificamos además los siguientes tipos de usuarios para la aplicación de la biblioteca en

línea: Lectores registrados y no registrados y un administrador de la biblioteca. El lector

registrado es modelado por el interés de éste en artículos y en registrar los artículos que

visita. Este lector registrado puede marcar artículos de especial interés para él. Una lista

personal de palabras clave para cada lector es administrado por la aplicación. El sistema

realiza la actualización del modelo de usuario acorde con las observaciones en el

comportamiento de los lectores (limitado a los artículos marcados o visitados

frecuentemente). Esta lista puede incluir tanto palabras clave positivas como negativas. Las

palabras clave negativas son utilizadas para ocultar publicaciones irrelevantes.


14

El modelo de casos de uso de la aplicación de la biblioteca en línea es mostrado

parcialmente en la figura 2. Para entrar en detalle en estos casos de uso se puede utilizar

una forma textual o utilizar los diagramas de actividades para especificar la secuencia de

acciones que serán realizadas por los actores que intervienen en estos casos de uso.

2.5.2. DIAGRAMA DE CLASES PARA MODELADO CONCEPTUAL

Un diagrama de clases en UML es utilizado para representar gráficamente un modelo

conceptual como una vista estática que muestra una colección de elementos estáticos en el

dominio de la aplicación. Siguiendo la metodología OOHDM, UWE construye un modelo

conceptual de una aplicación Web que ignora tanto como sea posible aspectos de

navegación, presentación e interacción. Estos aspectos son pospuestos para los pasos

navegacional y presentacional del diseño.

Los elementos de modelado principales que se utilizan en el modelo conceptual son: las

clases y las asociaciones. Sin embargo, el poder de los diagramas de clases es dado por una

variedad de características adicionales que pueden ser utilizadas semánticamente dentro de

esos diagramas. Ejemplos de estas características son las asociaciones y roles,

multiplicidades y diferentes formas de asociación soportadas por UML: agregación,

herencia, composición y clases de asociación, las cuales son representadas gráficamente por

la notación UML.


15

En base a los casos de uso de la sección previa y en base a la descripción a detalle de estos

casos de uso, se construye el modelo conceptual. El modelo conceptual incluye los objetos

que intervienen en las actividades típicas de los usuarios sobre la aplicación. La figura 3,

muestra el modelo conceptual del ejemplo de la biblioteca en línea. El ejemplo esta

limitado a datos y funcionalidad para cada clase y otros aspectos pueden ser incluidos

mediante un proceso iterativo e incremental.

2.5.3. DIAGRAMA DE CLASES ESTEREOTIPADAS PARA EL MODELADO DE

NAVEGACION Y PRESENTACION

El modelado de navegación y presentación no es exclusivo de las aplicaciones Web, sin

embargo los conceptos de navegación y presentación son más importantes en el desarrollo

de software con núcleo en la Web. Adicionalmente, la separación del modelado conceptual,

de navegación y presentación en distintos aspectos de las aplicaciones Web, incrementan la

independencia y posibilidades de reuso.

2.5.3.1. MODELOS DE NAVEGACION

El modelado de navegación de aplicaciones Web comprende la construcción de dos

modelos de navegación: El modelo del espacio de navegación y el modelo de la estructura

de navegación. Este modelado especifica qué objetos pueden ser visitados por la

navegación sobre la aplicación. Este es un modelado en el nivel de análisis. Los modelos de

navegación son representados mediante diagramas de clases estereotipadas.

El modelo del espacio de navegación incluye las clases de aquellos objetos que pueden ser

visitados por la navegación sobre la aplicación Web. UWE proporciona un conjunto de

caminos y mecanismos semi-automáticos para modelar la navegación de un aplicación.


16

La figura 4 muestra el modelo del espacio de navegación para la aplicación de la biblioteca

en línea. Los elementos principales de modelado son las clases estereotipadas y la

navegabilidad dirigida que es definida como una asociación estereotipada. Hay que hacer

notar que sólo aquellas clases del modelo conceptual que son relevantes para la navegación

son incluidas en el modelo de navegación. La información de las clases omitidas pueden ser

los atributos de algunas de las clases de navegación (por ejemplo el atributo Publisher de la

clase de navegación Publication.

El modelo de la estructura de navegación es construido sobre la base del modelo del

espacio de la navegación y es considerado como un paso de refinamiento en el proceso de

diseño de UWE. UWE proporciona un conjunto de lineamientos y mecanismos semi-

automáticos para refinar este proceso que consiste en refinar el modelo del espacio de

navegación mediante indices, líneas dirigidas, consultas y menús.


17

Las clases estereotipadas para el acceso de elementos son <<index>>, <<guided tour>>,

<<query>> y <<menú>>. La figura 5 muestra el diagrama de clases estereotipadas que

representa el modelo de la estructura de navegación del ejemplo.

2.5.3.2. MODELO DE PRESENTACION

El modelo de presentación es representado por un diagrama de clases que tiene una forma

particular. Este es un diagrama de clases utilizando la notación de composición UML para

clases. Es decir, este diagrama es representado por medio de un gráfico anidado de los

símbolos de las partes dentro del símbolo de la composición. Este tipo de representaciones

es apropiado para modelar las interfaces gráficas, así como el ordenamiento espacial y las

dimensiones relativas de la información que no puede ser manejada mediante herramientas

case estándar.

El modelo de presentación describe donde y como los objetos de navegación y las

primitivas de acceso son presentadas al usuario. El diseño de la presentación soporta la


18

transformación del modelo de la estructura de navegación en un conjunto de modelos que

muestran la localización estática de los objetos visibles al usuario, es decir, se tiene una

representación esquemática de esos objetos (sketches de las páginas). La figura 6 muestra

un sketch de presentación para la clase de navegación publication.

El conjunto de elementos de modelado estereotipados propuesto por UWE para describer el

modelo de presentación consiste de: <<text>>, <<form>>, <<button>>, <<image>>,

<<audio>, <<anchor>>, <<collection>> y <<anchored collection>>.

Las clases collection y anchored collection proporcionan una conveniente representación de

las composiciones frecuentemente usadas. Anchor y form son elementos interactivos

básicos. Un Anchor es asociado con un link para navegación.

2.5.4. DIAGRAMAS DE ESTADOS Y DE INTERACCION PARA

MODELAR ESCENARIOS WEB

Para modelar los aspectos dinámicos de una aplicación Web, UML proporciona diagramas

de transición de estados y de interacción. Un diagrama de transición de estados muestra una

secuencia de estados en que un objeto puede estar durante su ciclo de vida, junto con


19

acciones de respuesta, eventos y condiciones de guardas que provocan las transiciones entre

estados.

En UWE los diagramas de transición de estados se utilizan para visualizar escenarios de

navegación. Los detalles del modelo de la estructura de navegación especifican los eventos

que provocan las transiciones, definiendo condiciones de seguridad, haciendo explícitas las

acciones a realizarse. La figura 7 muestra el diagrama de transición de estados para la

interface de usuario de la aplicación de la biblioteca en línea. Los estados son nombrados

después de las clases de presentación que son mostradas en la interface de usuario.

Un diagrama de secuencia UML muestra la interacción del objeto en orden temporal. Este

diagrama presenta los objetos que participan en la interacción y en la secuencia de mensajes

entre ellos.

El propósito de UWE es usar los diagramas de secuencia para presentar los flujos, es decir,

los aspectos dinámicos de la presentación, tales como interacciones entre ventanas y

frames.

El tipo de diagrama elegido para este diseño de la representación de escenarios Web

depende del nivel de granularidad elegido.


20

2.5.5. DIAGRAMAS DE ACTIVIDAD PARA MODELAR TAREAS

El concepto de tarea (task) viene del campo de la Interacción Humano-Computadora (HCI).

Una tarea esta compuesta de una o más subtareas o acciones que un usuario puede llevar a

cabo para cubrir una meta. Una meta representa un cambio en el estado del sistema y puede

ser realizado por la formulación de un plan compuesto de tareas que se llevan a cabo

(acciones como tareas primitivas que no tienen estructura).

Aquí, queremos utilizar el concepto de tarea en el sentido de considerar aquellas tareas

realizadas por el usuario o por el sistema. Para modelar las tareas se han propuesto

diferentes notaciones en UML: clases estereotipadas, casos de uso, diagramas de

actividades, diagramas de transición de estados, etc.

UWE utiliza diagramas de actividades para modelar una tarea siendo los elementos de

modelado para tareas los propios de los diagramas de actividades: actividades, transiciones,

rombos, etc. Los diagramas de actividades son considerados como mapas de caminos del

comportamiento funcional de un sistema. La figura 8 muestra el modelo de tarea para la

tarea: borrado de publicación.


21

2.5.6. DIAGRAMA DE COMPONENTES PARA DOCUMENTAR LA

DISTRIBUCION DE LOS COMPONENTES DE UN APLICACIÓN

WEB

UWE utiliza los diagramas de componentes para documentar la distribución de los

componentes de una aplicación Web. Los elementos principales en los diagramas de

componentes UML son nodos que son dibujados gráficamente por cubos. Un nodo es un

elemento físico que existe en tiempo de ejecución y representa una fuente computacional.

Un nodo puede contener objetos y componentes que residen dentro de una fuente

computacional. Un componente en UML es una parte física y reemplazable de un sistema

que realiza y proporciona la realización de un conjunto de interfaces y es dibujado como un

rectángulo con dos rectángulos más pequeños que sobresalen por uno de sus lados.

La figura 9 muestra una parte del diagrama de componentes para el ejemplo de la

aplicación Web de la biblioteca en línea. Este diagrama se centra en el elemento

Publication y en las relaciones de dependencia entre sus componentes.

El elemento Publication del modelo conceptual puede ser realizado por un componente

Enterprise Java Bean (EJB) que reside dentro del nodo Servidor de la aplicación. El modelo

de presentación del elemento Publication es realizado por un componente JSP que reside en

el nodo del Servidor Web. Este utiliza el componente EJB denotado con la dependencia


22

<<uses>>. Finalmente dentro del nodo del Navegador Web, el componente de la página

del cliente para el elemento Publication es desplegado al usuario.

2.5.7. NOTACIONES GRAFICAS DE LA METODOLOGIA UWE


23


24

2. MÉTODOLOGÍAS PARA EL DESARROLLO DE SOFTWARE...

Documents

Transcript of 2. MÉTODOLOGÍAS PARA EL DESARROLLO DE SOFTWARE...