UWE

Introducción.
En los años 1980 se propuso que la mejor forma de
desarrollar un sistema software era por medio de una
planificación rígida y meticulosa del proyecto, soportada por
herramientas CASE (Ingeniería de Software Asistida por
Computador) y algunos procesos de desarrollo rigurosos y
altamente controlados, que eran sinónimo de garantía y
calidad en el software.
Estas metodologías tenían una carga de trabajo pesada en
planificación, diseño y documentación, absorbiendo gran
parte del tiempo destinado al desarrollo del sistema.

Introducción.
En los años 1990 se comenzaron a proponer métodos ágiles
para el desarrollo de software, que permitieran a los
desarrolladores concentrarse en el software y no totalmente
en el diseño y documentación del mismo.
Éstas metodologías tienen un enfoque iterativo para la
especificación, el desarrollo y la entrega del producto,
teniendo como principio que los requerimientos podían
cambiar permanentemente y durante el proceso de
desarrollo, entregando sistemas funcionales más
rápidamente con la posibilidad de agregar nuevos cambios
en las especificaciones.

Introducción.
En la actualidad, el proceso de desarrollo de software ha
sido abordado desde diferentes metodologías, las cuales
tienen diferentes enfoques para la captura de requerimientos
y el proceso de desarrollo del sistema software, algunas de
ellas se basan en analizar y documentar rigurosamente las
especificaciones del sistema, para luego realizar un
desarrollo y posteriormente efectuar las pruebas.
Otros métodos proponen centrarse en la organización del
equipo de trabajo, incluir al cliente activamente y en arrojar
resultados satisfactorios más rápidamente. Sea cual fuere la
metodología es conveniente saber que éstas se eligen e
implementan de acuerdo a la naturaleza del proyecto,
llegando incluso a combinarse entre sí para lograr mejores
resultados.

Introducción.
El avance de Internet y las comunicaciones ha provocado en
los últimos años el nacimiento de nuevas propuestas
metodológicas para la web.
La web se ha convertido por méritos propios en el medio de
comunicación por excelencia del siglo XXI. Resulta difícil
decir algo original para justificar el tremendo impacto que
tiene y seguirá teniendo en el devenir de nuestra civilización.
Entre sus muchos aportes, destaca la rapidez con la cual se
intercambia la información que unida a la eliminación de las
barreras geográficas, han convertido Internet en un terreno
fértil en el cual las empresas pueden extender sus negocios.

Introducción.
Como consecuencia ha proliferado el número de
aplicaciones web para la resolución de las necesidades de
las organizaciones.
A diferencia de las aplicaciones tradicionales desarrolladas
para una plataforma tecnológica concreta, las aplicaciones
web potencialmente pueden llegar a cualquier tipo de
dispositivo.
Por tanto este nuevo paradigma de desarrollo se está
utilizando cada vez más para implementar aplicaciones
gubernamentales, de enseñanza a distancia o de gestión
empresarial entre otras.

Introducción.
ORGANIZACIÓN USUARIOS
SISTEMA DE
INFORMACIÓN

Introducción.
¿Qué es una Aplicación Web?
Es un Sistema de Información donde una gran cantidad de
datos volátiles, altamente estructurados, van a ser
consultados, procesados y analizados mediante
navegadores.
Una de las principales características va a ser su alto grado
de interacción con el usuario, y el diseño de su interfaz debe
ser claro, simple y debe estar estructurado de tal manera
que sea orientativo para cada tipo de usuarios.

Introducción.
DEMORAS
EN CARGA
NECESITO
INFORMACIÓN
ENCONTRE LO
QUE BUSCO
NECESIDAD
INSATISFECHA
SITIO CAÍDO
ERRORES EN
NAVEGACIÓN
CONTENIDOS
POBRES
NO CUMPLE
EXPECTATIVAS
POCA
IDENTIFICACIÓN
CONFUSO
DIFICULTAD DE
USO
POCO ATRACTIVO
¿EL SISTEMA ES
USABLE?

Introducción.
Arquitectura de las aplicaciones web.
DOS NIVELES: Es la más simple, se tiene el nivel del
“Cliente” y el nivel del “Servidor”.

Introducción.
TRES NIVELES:
1. El primer nivel consiste en la capa de presentación que
incluye no sólo el navegador, sino también el servidor
web que es el responsable de dar a los datos un formato
adecuado.
2. El segundo nivel está referido habitualmente a algún tipo
de programa o script.
3. Finalmente, el tercer nivel proporciona al segundo los
datos necesarios para su ejecución.

Introducción.
TRES NIVELES:

Introducción.
El servidor web
Es un programa que implementa el protocolo HTTP. Este
protocolo pertenece a la capa de aplicación del modelo OSI
y está diseñado para transferir lo que se llama hipertextos,
páginas web o páginas HTML: textos complejos con
enlaces, figuras, formularios, botones y objetos incrustados
como animaciones o reproductores de música.

Introducción.
Algunos ejemplos de servidor web
• CERN httpd.
• Apache (Libre, servidor más usado del mundo, según
Wikipedia.)
• IIS.
• Resin.
• Tomcat (Libre, del proyecto Jakarta de Apache.)
• Geronimo (Libre, orientado a J2EE, del proyecto Jakarta
de Apache, actualmente se encuentra en desarrollo.)
• JBoss.
• JOnAS.
• Cherokee.

Introducción.
Son varias las ventajas que proporciona resolver la
problemática de una organización a través de una aplicación
web. En primer lugar para su uso, el usuario final sólo
necesita conocer el uso de un navegador Web. Por lo tanto,
no es necesario que asimile conocimientos de instalación o
configuración.
En segundo lugar, debido a que el desarrollo web se basa
en estándares aceptados (HTTP, HTML, XML, etc.) y
tecnologías multiplataforma (JavaScript, etc.) se soluciona el
problema de generar software para distintos sistemas
operativos o dispositivos. La misma aplicación web puede
usarse con Internet Explorer de Windows o en un
smartphone con un navegador móvil.

Introducción.
Lenguajes de programación del lado del cliente.
1. Los programas del lado del cliente están incluidos dentro
de la página HTML, se descargan del servidor junto con
este.
2. Los programas se ejecutan dentro del ámbito del
browser.

Introducción.
Tecnologías y lenguajes del lado del cliente.
1. Navegadores para Web.
2. HTML.
3. Javascript y Vbscript.
4. Applets en Java.
5. Flash (Lenguaje ActionScript.)
6. XML.
7. PDF.
8. AJAX, acrónimo de Asynchronous JavaScript And XML
(JavaScript asíncrono y XML.)

Introducción.
Tecnologías y lenguajes del lado del cliente.
1. Algunos de estos lenguajes y tecnologías requieren de
un programa especial (plug-in) instalado en la
computadora del usuario. Ejemplo: Adobe Flash Player.
2. Un complemento (o plug-in en inglés) es una aplicación
que se relaciona con otra para aportarle una función
nueva y generalmente muy especifica. Esta aplicación
adicional es ejecutada por la aplicación principal e
interactúan por medio de la API.

Introducción.
Lenguajes de programación del lado del servidor.
1. Se ejecutan en el servidor de Web y son dependientes
de la plataforma del servidor.
2. Se usan para acceder a recursos del servidor, como
bases de datos y generación de contenido dinámico para
las páginas.

Introducción.
Lenguajes de
programación del
lado del servidor.
• Por ejemplo,
el ámbito de
ejecución de
una página
ASP.NET.

Introducción.
Algunos ejemplos de lenguajes del lado del servidor:
• ASP, ASP.NET (son tecnologías, soportan diferentes
lenguajes como VB, C#, C++, etc.)
• PHP.
• JSP.
• Perl.
• Ruby.
• Python.
• XML.

Introducción.
Ambientes para el desarrollo de aplicaciones Web.:
• Los IDE (ambientes integrados de desarrollo) para
aplicaciones Web son muy numerosos.
• Considerar los que permitan trabajar con los diferentes
lenguajes para Web.
• Algunos son específicos para lenguajes del lado del
servidor. Por ejemplo, Visual Studio solo soporta
ASP.NET del lado del servidor.
• Existen IDE’s de buena cantidad, libres y gratuitos de
buena calidad.

Introducción.
Algunos ejemplos de IDE para Web:
• Microsoft Visual Studio.
• Microsoft Web Developer Express.
• Mono (para ASP.NET.)
• NetBeans.
• Jbuilder.
• Eclipse.

Introducción.
Las aplicaciones web están más expuestas a ataques. Se
pueden tener ataques en tres niveles:
• A la computadora del usuario.
• Al servidor.
• A la información en tránsito.
La seguridad en web tiene 3 etapas primarias:
• Seguridad de la computadora del usuario.
• Seguridad del servidor web y de sus datos.
• Seguridad de la información que viaja entre el servidor
Web y el usuario.

Introducción.
Seguridad de la computadora del usuario: Los usuarios
deben contar con navegadores y plataformas seguras, libres de
virus y vulnerabilidades. También debe garantizarse la privacidad
de los datos del usuario.
Seguridad del servidor web y de sus datos: Se debe
garantizar la operación continua del servidor, que los datos no
sean modificados sin autorización (integridad) y que la
información sólo sea distribuida a las personas autorizadas
(control de acceso.)
Seguridad de la información que viaja entre el servidor web y
el usuario: Garantizar que la información en tránsito no sea
leída (confidencialidad), modificada o destruida por terceros.
Asegurar que el enlace entre cliente y servidor no pueda
interrumpirse fácilmente (disponibilidad.)

Introducción.
Se deben considerar los siguientes puntos:
• Asegurar el servidor en una forma fundamental: el sistema
operativo, ya sea por medio de actualizaciones (parches) y
habilitando los mecanismos propios de la plataforma.
• Garantizar la seguridad del servidor web propiamente (IIS,
Apache, etc.)
• Auditar las aplicaciones que interactúan en las dos capas
anteriores (módulos, bibliotecas.)
• Asegurando la red físicamente (switches en lugar de hubs).
• Esconder la información (esteganografía).
• Cifrar la información (criptografía) por medio de algoritmos
diversos (SSL, VPNs).
• Actualizar (parchar) el sistema operativo de los clientes.
• Uso de antivirus, firewalls personales.
• Educar a los usuarios.

Introducción.
En web se simplifica notablemente el mantenimiento de la
aplicación, pues siempre se accede en el mismo servidor y
ante un cambio no es necesario instalar una nueva versión
en todos los dispositivos.
Pero debido a esta rápida evolución y a la complejidad
tecnológica añadida, el desarrollo de aplicaciones web se
caracteriza por ser más costoso y complejo que el desarrollo
tradicional de software.
Lamentablemente los métodos de Ingeniería de Software
tradicionales, no están adaptados para resolver los
requisitos específicos de las aplicaciones web 2.0.

Introducción.
La Ingeniería Web surge para aplicar los fundamentos de la
Ingeniería de Software sobre el desarrollo sistemático de
aplicaciones web, atendiendo las características particulares
propias de este tipo de aplicaciones.
La mayoría de las propuestas metodológicas ha centrado su
trabajo principalmente en las etapas de diseño e
implementación y tratamiento de requisitos ha sido tratado con
una menor importancia.
En el año 1993 un grupo de expertos (F. Garzoto, D. Schwabe y
P. Paolini) comienzan a desarrollar HDM. La hipermedia
necesita métodos de trabajo específicos para tratar aspectos
como la navegación o la interfaz. En 1995 se comienza a
evolucionar hacia la orientación a objetos y nacen OOHDM y
EORM.

Introducción.
A partir de ahí comienzan elaborarse diferentes
metodologías de trabajo para la web. Sin embargo, desde
1999 (HFPM, WSDM, UWE, etc) se comienza a potenciar la
ingeniería de requisitos.
(Ferreira & Loucopoulos, 2001): El tratamiento de requisitos
es el proceso mediante el cual se especifican y validan los
servicios que debe proporcionar el sistema así como las
restricciones sobre las que se deberá operar.
Consiste en un proceso iterativo y cooperativo de análisis
del problema, documentando los resultados en una variedad
de formatos y probando la exactitud del conocimiento
adquirido.

En el ámbito del desarrollo web no es usual modelar mucho
las aplicaciones.
Quizá es una de las razones por las que los desarrollos se
tornan más complejos de lo pensado.
En la mayoría de los proyectos complejos ya sean estos
basados en web o de otro tipo, el cliente espera ver
resultados rápidamente, de modo que se suele desestimar la
importancia del buen análisis y modelado.
Esta es una muy mala práctica, tomando en cuenta que
muchas de la aplicaciones que se desarrollan hoy día y que
interactúan en la red son sistemas de complejidad media o
alta con la salvedad que opera sobre una plataforma web.
Introducción.

Y si el software que representan los sistemas de información
web suelen ser la realización de las reglas de negocios de
cada organización. En la medida que cambian estas reglas,
el software tiene que cambiar también.
Cuando se intentan modificar esas reglas para lograr una
mayor efectividad y competitividad, el software tiene que
adaptarse, en algunos casos implica la creación de un nuevo
software, pero en otros significa la modificación o
reconstrucción de algo ya existente para que pueda seguir
satisfaciendo las necesidades cambiantes de los negocios.
Ejemplos son la necesidad o conveniencia de colocar el
sistema en Internet, la inestabilidad de la aplicación, la
aparición de efectos colaterales graves e inesperados.
Introducción.

Por ello toda organización necesita una estrategia para la
migración de sus sistemas antiguos basada en una
metodología moderna que contenga toda clase de controles.
Las metodologías web permiten especificar de mejor manera
una aplicación, su proceso de creación, diseño entre otros.
Proceden de manera iterativa e incremental y coinciden con
UML en su mayoría.
Las metodologías de Web maduras tal como OOHDM, UWE,
WebML, OO-H, entre otras son ejemplos de metodologías
que facilitan el diseño de una aplicación Web atacando los
aspectos (conceptual, navegacional y de interfaz de usuario)
por separado.
Introducción.

El análisis de requerimiento de aplicaciones web implica
adquirir un entendimiento de las necesidades de todos
aquellos interesados en el sistema; aquellos que están
interesados en el mismo negocio corporativo.
La mayoría de las veces, los requerimientos son acordados
por los interesados de tal forma que la semántica y el
significado de cada término o concepto utilizado es bien
entendido.
Sin embargo, cuando existen diferentes puntos de vista del
mismo concepto de negocio, ambigüedades o
inconsistencias pueden surgir, siendo estas perjudiciales
para la Especificación de Requerimientos de Software
(ERS.)
Introducción.

Tradicionalmente, las tareas de conciliación son realizadas
utilizando técnicas y herramientas basadas principalmente
en reuniones; con el objetivo de eliminar ambigüedad e
inconsistencias en los requerimientos.
Cuando la inconsistencia en requerimiento no es detectada
a tiempo, ellos pueden convertirse en defectos en el
software; siendo éste una de las razones más severas de
que los proyectos superen el costo estimado ya que estos
defectos deben ser resueltos en las etapas finales del
proceso de desarrollo de software.
Introducción.

En este contexto, el esfuerzo para corregir las fallas es
varios órdenes de magnitud mayor que corregir los
requerimientos en las etapas tempranas del desarrollo del
software.
Las inconsistencias pueden surgir desde nuevos
requerimientos, que introducen nuevas funcionalidades o
mejoras a la aplicación, o, incluso, desde requerimientos
existentes que cambian durante el proceso de desarrollo.
Introducción.

Por ejemplo, un sitio de comercio electrónico que provee un
servicio pago de entrega a domicilio de productos, del tipo
que ha sido utilizado en los ejemplos hasta el momento,
puede planear una promoción para “Navidad”, donde
algunos productos tienen el servicio de envío sin costo por
un período de tiempo; mientras que el resto de los productos
mantienen el costo usual del servicio.
Este nuevo requerimiento introduce cambios que son
percibidos por el usuario porque él puede ver banners
promociónales en diferentes páginas.
Introducción.

Durante la especificación de requerimientos, existen casos
donde dos o más escenarios que reflejan la misma lógica de
negocio difieren sutilmente uno de otro produciendo una
inconsistencia.
Cuando estas inconsistencias están basadas en
comportamientos contradictorios, nos encontramos con un
conflicto de requerimientos.
Los conflictos están caracterizados por tener diferencias en
las características, conflictos lógicos (lo que se espera) o
temporales (cuando se espera) entre acciones, o incluso
diferencias en terminología que crea ambigüedad.
Introducción.

RUP es una metodología que tiene como objetivo ordenar y
estructurar el desarrollo de software, en la cual se tienen un
conjunto de actividades necesarias para transformar los
requisitos del usuario en un sistema software.
Inicialmente fue llamada UP (Unified Process) y luego
cambió su nombre a RUP por el respaldo de Rational
Software de IBM. Ésta metodología fue lanzada en 1998
teniendo como sus creadores a Ivar Jacobson, Grady Booch
y James Rumbaugh. El RUP nació del UML (Unified
Modeling Language) y del UP.
Introducción.

Características del RUP
El RUP es un proceso basado en los modelos en Cascada y
por Componentes, el cual presenta las siguientes
características:
 Es dirigido por los casos de uso.
 Es centrado en la arquitectura.
 Es iterativo e incremental.
Lo cual es fundamental para el proceso de desarrollo de
software. A continuación se explican las tres características:
Introducción.

a. Casos de Uso: Describe un servicio que el usuario
requiere del sistema, incluye la secuencia completa de
interacciones entre el usuario y el sistema.
Introducción.

b. Centrado en la arquitectura: Comprende las diferentes
vistas del sistema en desarrollo, que corresponden a los
modelos del sistema: Modelos de casos de uso, de
análisis, de diseño, de despliegue e implementación.
La arquitectura del software es importante para
comprender el sistema como un todo y a la vez en sus
distintas partes, sirve para organizar el desarrollo,
fomentar la reutilización de componentes y hacer
evolucionar el sistema, es decir, agregarle más
funcionalidad.
Introducción.

c. Iterativo e Incremental: Significa que la aplicación se
divide en pequeños proyectos, los cuales incorporan una
parte de las especificaciones, y el desarrollo de la misma
es una iteración que va incrementando la funcionalidad
del sistema de manera progresiva.
Introducción.

Una iteración está compuesta por los requisitos, análisis,
diseño, implementación y pruebas; pero dicha iteración sólo
entrega una parte pequeña pero funcional del sistema, de tal
forma que los requisitos y demás modelos no se desarrollan
en una sola iteración sino progresivamente, ello con la
finalidad de poder garantizar entregas funcionales e
iterativas y de tal forma ir completando el sistema software
paso a paso.
Cabe aclarar que una iteración también incluye otros
artefactos, tales como la planificación y el análisis de la
iteración, entre otras actividades específicas concebidas
dentro de esa iteración.
Introducción.

Relaciones entre las metodologías web existentes.

Introducción.
WSDM
SOHDM
DDDP
NDT
UWA
W2000
UWE
RNA
HFPM
OOHDM
1. Seleccionar una metodología
2. Justificar por que usar la
metodología seleccionada.
3. Seguir las etapas que establece
la metodología seleccionada.

La problemática propuesta estaría en relación al hecho si un
sistema de información orientado a la web es usable o no.
La solución a la problemática implementaría una
metodología que investigue el comportamiento de los
usuarios y que determine cuáles son las necesidades de
información que buscan los usuarios en un sistema de
información Web.
Esta metodología entregaría las estrategias necesarias para
estructurar y organizar el contenido utilizando estándares y
herramientas dedicadas al tratamiento de usuarios.
Introducción.

Introducción.
USUARIOS
CONTEXTO
CONTENIDO
USABILIDAD ACCESIBILIDAD

La usabilidad mejora la calidad de vida de los usuarios, ya
que reduce su estrés, incrementa la satisfacción y la
productividad al encontrar rápidamente la información que
buscan.
La accesibilidad es que todos los usuarios pueden acceder
en condiciones de equidad a los contenidos.
La arquitectura de la información 2.0 aminora el costo en la
búsqueda de información, la construcción y mantenimiento y
la educación y capacitación.
Introducción.

Introducción.
ESTRATEGIASNECESIDADES
ESTÁNDARES
USUARIOSHERRAMIENTAS
Los objetivos de la metodología deben responden a:

Introducción.
Fases de la metodología:
IMPLEMENTACIÓN
Y MANTENCIÓN
IDENTIFICACIÓN DE
REQUERIMIENTOS
ANÁLISIS
DISEÑO
CONSTRUCCIÓN
PLANIFICACIÓN
ESTUDIO DE
VIABILIDAD

Introducción.
PLANIFICACIÓN
ESTRATÉGICA
ABSTRACCIÓN Y
ESTUDIO DE
PROCESOS
VISIÓN GENERAL Y
ESTRATÉGICA
DEL SISTEMA
DEFINICIÓN DE
OBJETIVOS Y
NECESIDADES
IDEA DE
SISTEMA

Introducción.
ESTUDIO DE
VIABILIDAD
ESTUDIO DE
IMPACTO EN LA
ORGANIZACIÓN
BENEFICIOS Y
RIESGOS DEL
PROYECTO
SELECCIÓN DE
ALTERNATIVA
MODELO
CONCEPTUAL
DE SISTEMA

Introducción.
IDENTIFICACIÓN
DE
REQUERIMIENTOS
IDENTIFICACIÓN
DE USUARIOS
DEFINICIÓN DE
ESTÁNDARES
REQUERIMIENTOS
IDENTIFICADOS
CONTEXTO DE
USO
ALTERNATIVA
DE SOLUCIÓN

Introducción.
ANÁLISIS
INTENCIÓN DE USO
DEFINICIÓN DE
INTERFACES
MODELADO DE
DATOS
Y PROCESOS
MODELO DE
SISTEMA DE
INFORMACIÓN
PERFILES
VALIDACIÓN
REQUERIMIENTOS
DEFINICIÓN DE
REQUERIMIENTOS

Introducción.
DISEÑO
VISUAL
DISEÑO DE
INTERACCIÓN
ARQUITECTURA
DE LA
INFORMACIÓN
PROTOTIPO WEB
DEL SISTEMA
VISTAS DE
DISEÑO
HERRAMIENTAS
TECNOLÓGICAS
DISEÑO DE
CONTENIDO
MODELO DE SISTEMA
WEB
DISEÑO

Introducción.
CONSTRUCCIÓN
CONSTRUCCIÓN
ESTÁNDARES
SISTEMA WEB
CONSTRUIDO
EDUCACIÓN DE
USUARIOS
PRUEBAS Y
VALIDACIÓN
REQUERIMIENTOS
TECNOLÓGICOS
PROTOTIPO
WEB

Introducción.
IMPLEMENTACIÓN
Y MANTENIMIENTO
IMPLEMENTACIÓN
MANTENIMIENTO
SISTEMA DE
INFORMACIÓN WEB
APROBADO
PRUEBAS Y
VALIDACIÓN
REVISIÓN DE
TAREAS
SISTEMA
CONSTRUIDO

Introducción.
INTERNET
NECESITO
INFORMACIÓN
ENCONTRE LO
QUE BUSCO
FACTORES DE
ÉXITO
CONOCER A
LOS USUARIOS
TECNOLOGÍAS
ACTUALES
EL SISTEMA ES
USABLE Y
ACCESIBLE
FACTORES
CRÍTICOS
EVALUACIÓN
HUMANA
RESPONSABLES
COMPROMISO
ORGANIZACIÓN

WSDM: Web Site Design Method. 1997.
• Define el sistema basado en los grupos de usuario.
• Su proceso de definición de requisitos tiene por objetivo
detectar los perfiles de usuario mediante dos tareas.
• Clasificación de usuarios mediante el estudio del
entorno.
• Descripción de los grupos de usuario.

SOHDM: Scenario-based Object-Oriented
Hypermedia Design Methodology. 1998
• Esta propuesta ofrece un modelo de escenarios propia,
denominada SAC, para representar los requisitos.
• Para el desarrollo de los mismos hace uso del diagrama
de contexto propuesto en los DFD.
• Ha caido en desuso, principalmente por el uso de los
DFD.

RNA: Relationship Navigational Analysis. 1998
• Plantea una secuencia de pasos en la que separa el
tratamiento de diferentes requisitos:
• Análisis del Entorno
• Elementos de Interés
• Análisis del Conocimiento
• Análisis de la Navegación
• Implementación del Análisis
• Está muy enfocada en un grupo de sistemas: Los
sistemas legales y en la actualidad no es muy usada.

HFPM: Hypermedia Flexible Process Modeling. 1999
Define un proceso detallado que cubre todo el ciclo de vida y
que está compuesto por 13 fases.
En la primera de ellas, modelado de requisitos, propone las
tareas siguientes:
• Descripción breve del problema.
• Descripción de los requisitos funcionales.
• Realización del modelo de datos.
• Modelado de la interfaz de usuario.
• Modelado de los requisitos no funcionales.
No está siendo trabajada actualmente, sin embargo, fue la
primera en definir ciertos aspectos:

HFPM: Hypermedia Flexible Process Modeling. 1999
• Incluye al usuario desde el principio del desarrollo.
• Introduce el concepto de la separación de aspectos,
propuesto para el análisis, ya desde la Ingeniería de
Requisitos.
• Establece la necesidad de definir modelos específicos
para el usuario. Aunque no define ninguno.
• Establece la necesidad de elaborar manuales de usuario
e incluir esto en el ciclo de vida.

OOHDM: Object Oriented Hypermedia Design Model. 1999
Es un método orientado a modelos para el desarrollo de
aplicaciones web. Permite a los diseñadores especificarla
mediante el uso de varios meta-modelos especializados:
conceptual, navegación y de interfaz de usuario.
Cada meta-modelo pone foco en diferentes aspectos de una
aplicación. Una vez que estos modelos han sido
especificados para una aplicación dada, es posible generar
código en tiempo de ejecución que implemente la aplicación;
es decir, los diseños de la aplicación.
Existen varios intérpretes de estos modelos encargados de
producir una aplicación web basada en ellos: el ambiente
HyperDE y el framework Cazon.

OOHDM utiliza mecanismos de abstracción y composición
diferentes en un framework orientado a objetos, para permitir
una descripción concisa de elementos de información
correspondientes al negocio subyacente y la especificación
de escenarios de navegación complejos según los datos del
modelo conceptual y transformaciones de interfaz para
hacer percibible la información indicada en el modelo
anterior.

OOHDM, sucesor de HDM, es una propuesta (Rossi y
Schwabe) ampliamente aceptada para la web, es una
metodología de desarrollo 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.
Inicialmente no proponía la fase de Ingeniería de Requisitos
y centraba su desarrollo en cuatro etapas:

OOHDM: Fases de desarrollo
1. Análisis (o determinación) de requerimientos
2. Modelo (o diseño) conceptual (Análisis del dominio.):
Obtiene esquemas conceptuales de las clases y las
relaciones entre las mismas.
3. Modelo (o diseño) navegacional.
4. Modelo (o diseño) de interfaz abstracta.
5. Implementación.

OOHDM es una mezcla de estilos de desarrollo basado en
prototipos, en desarrollo interactivo y de desarrollo
incremental.
En cada fase se elabora un modelo que recoge los aspectos
que se trabajan en esa fase. Este modelo parte del modelo
conseguido en la fase anterior y sirve como base para el
modelo de la siguiente fase.
Cada paso de diseño se enfoca en un aspecto de diseño
particular, y, en consecuencia, un modelo es elaborado a
partir de esto.

Propone un modelo para representar a las aplicaciones
multimedia, propone un proceso predeterminado para el que
indica las actividades a realizar y los productos que se
deben obtener en cada fase del desarrollo.
Toma como partida el modelo de clases que se obtiene en el
análisis del Proceso Unificado de UML. A este modelo lo
denomina modelo conceptual.
Partiendo de este modelo conceptual, OOHDM propone ir
añadiendo características que permitan incorporar a esta
representación del sistema todos los aspectos propios de las
aplicaciones multimedia.

En una segunda etapa de diseño, se parte de ese modelo y
se le añaden los aspectos de navegación, generándose un
nuevo modelo de clases denominado modelo navegacional.
Por último, este modelo sirve como base para definir el
modelo de interfaz abstracta, que representa la visión que
del sistema tendrá cada usuario del mismo.
En 2001, OOHDM tuvo una propuesta orientada a la
ingeniería de requisitos denominada User Interaction
Diagrams (UID.)
La única herramienta disponible relacionada con OOHDM es
HyperDE, pero se enfoca en SHDM (Semantic Hypermedia
Design Method), una extensión original para construir
aplicaciones semánticas.

OOHDM: Fase 1. Determinación de Requerimientos.
Se fundamenta en los diagramas de casos de usos, los
cuales son diseñados por escenarios con la finalidad de
obtener de manera clara los requerimientos y acciones del
sistema.
Primero es necesario la recopilación de requerimientos. Para
ello, se necesitan identificar los actores y las tareas que ellos
deben realizar. Luego, se determinan los escenarios para
cada tarea y tipo de actor. Los casos de uso que surgen a
partir de aquí, serán luego representados mediante los
Diagramas de Interacción de Usuario (UIDs), los cuales
proveen de una representación gráfica concisa de la
interacción entre el usuario y el sistema durante la ejecución
de alguna tarea.

Con este tipo de diagramas se capturan los requisitos de la
aplicación de manera independiente de la implementación.
Para ello se deben proporcionar las respuestas a las
siguientes interrogantes:
 ¿Cuáles son los tópicos principales que serán atendidos?
 ¿Cómo los tópicos están relacionados entre sí?
 ¿Qué categoría de usuarios serán atendidos?
 ¿Cuáles son las tareas principales que serán abordadas?
 ¿Qué tareas corresponden a qué categoría de usuarios?
 ¿Los recursos disponibles son competitivos con la
información levantada?

Con este tipo de diagramas se capturan los requisitos de la
aplicación de manera independiente de la implementación.
Para ello se deben proporcionar las respuestas a las
siguientes interrogantes:
 ¿Cuáles son los tópicos principales que serán atendidos?
 ¿Cómo los tópicos están relacionados entre sí?
 ¿Qué categoría de usuarios serán atendidos?
 ¿Cuáles son las tareas principales que serán abordadas?
 ¿Qué tareas corresponden a qué categoría de usuarios?
 ¿Los recursos disponibles son competitivos con la
información levantada?
Se inicia obteniendo los requerimientos de los
stakeholders (interesados en el sistema). Para ello, es
necesario identificar los actores y las tareas que ellos
deben realizar en casos de uso. Luego, los casos de
uso son acopiados (o bosquejados) para cada tarea y
tipo de actor utilizando Diagramas de Interacción de
Usuario (UID, User Interaction Diagram). Estos
diagramas proveen una representación concisa
utilizando una metáfora gráfica del flujo de información
entre el usuario y la aplicación durante la ejecución de
una tarea. Los UIDs son validados con el actor del
caso de uso y rediseñado, si fuese necesario, a partir
del retorno que haya brindado este último.

UID del caso de uso “Buscar película por nombre”.

UID del caso de uso “Buscar película por nombre”.
Con las elipses se grafican los paso de interacción (Interaction),
dentro de estos se enumeran los elementos de datos que
participarán de la interacción tanto de escritura (utilizando un
rectángulo) o de solo lectura (sin detalle.)
También es posible indicar conjuntos de datos usando puntos
suspensivos “…” como prefijo al nombre del dato.
La transición de una interacción a otra se especifica mediante
una flecha llamada transición (Interaction) y las operaciones
que son disparadas desde una interacción dada se especifican
con una línea que se desprende de la interacción con una
cabeza redonda y rellena en el otro extremo.

OOHDM: Fase 2. Diseño Conceptual.
Se construye un modelo orientado a objetos según (KOCH
2002) que represente el dominio de la aplicación usando las
técnicas propias de la orientación a objetos.
La finalidad principal durante esta fase es capturar el
dominio semántico de la aplicación en la medida de lo
posible, teniendo en cuenta el papel de los usuarios y las
tareas que desarrollan.
El resultado de esta fase es un modelo de clases
relacionadas que se divide en subsistemas.

Se construye un modelo orientado a objetos según (KOCH
2002) que represente el dominio de la aplicación usando las
técnicas propias de la orientación a objetos.
La finalidad principal durante esta fase es capturar el
dominio semántico de la aplicación en la medida de lo
posible, teniendo en cuenta el papel de los usuarios y las
tareas que desarrollan.
El resultado de esta fase es un modelo de clases
relacionadas que se divide en subsistemas.
En este paso se elabora un Modelo Conceptual de
dominio de la aplicación utilizando principios de
modelado orientados a objetos.
En este paso solo se enfoca en la semántica del
dominio de aplicación y no en los tipos de usuarios y
tareas.
OOHDM utiliza el meta-modelo de clases de UML
(Unified Modelling Language), con pequeñas
extensiones, para expresar el diseño conceptual.

Fase de diseño conceptual de OOHDM.

En OOHDM una aplicación se ve a través de un sistema de
navegación. En la fase de diseño navegacional se debe
diseñar la aplicación teniendo en cuenta las tareas que el
usuario va a realizar sobre el sistema.
Para ello, hay que partir del esquema conceptual
desarrollado en la fase anterior. Hay que tener en cuenta
que sobre un mismo esquema conceptual se pueden
desarrollar diferentes modelos navegacionales (cada uno de
los cuales dará origen a una aplicación diferente.)
La estructura de navegación de una aplicación hipermedia
está definida por un esquema de clases de navegación
específica, que refleja una posible vista elegida.

En OOHDM hay una serie de clases especiales predefinidas,
que se conocen como clases navegacionales:
• Nodos.
• Enlaces.
• Estructuras de acceso.
Los cuales se organizan dentro de un:
• Contexto navegacional.

Nodos: Son contenedores básicos de información de las
aplicaciones hipermedia.
Son vistas orientadas a objeto de las clases definidas
durante el diseño conceptual usando un lenguaje
predefinido, permitiendo que un nodo sea definido mediante
la combinación de atributos de clases diferentes
relacionadas en el modelo de diseño conceptual.
Los nodos contendrán atributos de tipos básicos (donde se
pueden encontrar tipos como imágenes o sonidos) y
enlaces.

Enlaces: Los enlaces reflejan la relación de navegación que
puede explorar el usuario.
Para un mismo esquema conceptual puede haber diferentes
esquemas navegacionales y los enlaces van a ser
imprescindibles para poder crear esas vistas diferentes.
Este modelo se obtiene a partir de una versión básica
derivada desde los UIDs a la que se le aplicaron iteraciones
de refinamientos donde se elimina información redundante;
se aplican buenas prácticas de diseño de software tal como
generalizaciones y especializaciones, patrones de diseño
orientado a objetos, entre otro.

OOHDM:Fase2.DiseñoConceptual.

OOHDM: Fase 3. Diseño Navegacional.
Una aplicación web es concebida como una vista
navegacional sobre un Modelo Conceptual. Esto refleja la
mayor innovación de OOHDM también adoptado por UWE y
WebML) la cual reconoce que los objetos que el usuario
navega no son objetos conceptuales sino un tipo de objetos
que se construye a partir de ellos para soportar tareas y una
presentación adecuada de la información.
Es decir, para cada perfil de usuario se puede definir una
vista navegacional basada en la tarea que este tipo de
usuario debe realizar, dicha vista refleja los datos y
relaciones en el esquema conceptual.

Estas definiciones pertenecen al Modelo Navegacional. En
OOHDM existe un conjunto de tipos de básicos predefinidos
de clases navegacionales usuales en aplicaciones de
hipermedia: Nodo, Links, Anchors y estructuras de acceso.
Los nodos representan la vista lógica sobre el Modelo
Conceptual definidos a partir de un lenguaje de consulta.
Desde una perspectiva O.O., los nodos implementan una
variante del patrón Observer ya que presentan una vista
particular de los objetos de negocio.

Los cambios en el Modelo Conceptual son notificados
inmediatamente a los nodos (objetos observadores) y, por
otro lado, los nodos pueden invocar mensajes de los objetos
del modelo conceptual a partir de eventos surgidos en la
interfaz de usuario.
En la actualidad, el patrón Observer es implementado
utilizando requerimientos HTTP para actualizar la
información presentada al usuario bajo demanda y solo un
conjunto de tecnologías basadas en Javascript con XML de
forma asincrónica (AJAX, Asynchronous JavaScript and
XML) tal como Google Web Toolkit (GWT) soporta la
notificación de cambios tal como lo indica el patrón.

Links, se refiere a la realización hipermedial de las
relaciones del modelo conceptual así como también las
asociaciones. Pueden existir Links que no reflejen relaciones
en el Modelo Conceptual que permiten mejorar, por ejemplo,
la navegación de la aplicación. Las estructuras de acceso,
tal como los índices, representan puntos de inicio de la
navegación.
Aplicaciones web diferentes (en el mismo dominio) pueden
contener topologías de Nodos y Links debido a los perfiles
de usuario.

En el ejemplo Internet Movie Database (IMDB), la vista
administrativa de un DVD puede indicar que por cada copia
disponible cuándo esta debe ser retornada mientras que la
perspectiva de un cliente no lo mostrará.
Puede verse el Modelo de Navegación compuesto por
Nodos y Links que rigen la navegación de la aplicación.
Los nodos son usualmente contrapartes del modelo
navegacional, pero muchas veces nodos específicos de la
navegación pueden definirse como el caso del nodo “Orden”
que permite modelar el pedido de compras que está
realizando el usuario en el momento y agrupa todas las
películas que éste desea adquirir.

Los nodos navegacionales son objetos que pueden poseer
métodos que encapsulan lógica específica de navegación de
la aplicación tal como la resolución de ciertos datos
mediante la ejecución de una consulta sobre el Modelo
Conceptual.
La mayoría de las aplicaciones web permiten realizar tareas
que involucran un conjunto de objetos que representan
conceptos similares tal como libros por autor, CDs por
cantante, hoteles en una ciudad, etc.

OOHDM estructura el espacio de navegación en conjuntos
llamados contextos de navegación. Estos poseen las
mismas alternativas de navegación y son significativos para
cierto paso de alguna tarea que un usuario realice.
Cada contexto navegacional es un conjunto de nodos, y es
descrito especificando sus elementos, su estructura interna
e índices asociados.

Los contextos navegacionales juegan un rol análogo con
respecto a la navegación que las clases con respecto a la
estructura y comportamiento de los objetos.
Se puede modelar un conjunto de actores en una película
dirigida por un director, el conjunto de copias de DVD de una
película, etc.

OOHDM: Fase 4. Diseño de Interfaces.
El diseño de interfaces puede separarse en dos tareas:
1. Diseño estructural.
2. Diseño de comportamiento.

OOHDM: Fase 4. Descripción del contenido de interfaces.
OOHDM utiliza Vistas de Datos Abstractas (ADV, Abstract
Data View) para representar las interfaces de usuario que
requiere una aplicación web.
Un ADV tiene una estructura (expresada como un conjunto
de atributos), comportamiento (definido como un conjunto de
mensajes o eventos externos que éste puede manejar) y
puede ser definido recursivamente componiendo otros
ADVs.
Dado su naturaleza estructurada, los ADVs pueden ser
mapeados fácilmente en documentos XML facilitando así su
escritura y edición.

ADV del componente ChangeablePicture de la interfaz
web. Este ADV está compuesto de forma anidada por otros
ADVs primitivos como Imagen Picture o Text, mostrando
como los componentes serán percibidos por el usuario.

Pantalla esperada del ADV y
con líneas punteadas se
muestra la relación entre los
elementos concretos y
abstractos. La posición de los
objetos anidados en el ADV
refleja la apariencia (look and
feel) de la interfaz siendo un
medio efectivo para validar con
el cliente cómo será el resultado
final del desarrollo de la interfaz.

Los ADVs observan Objetos de Datos Abstractos (ADO,
Abstract Data Objects), conocidos como “dueños” de ADV,
con dos objetivos: ser una vista de los datos y disparar
comportamientos de aplicación o interfaz.
Los ADV de la ilustración obtiene sus contenidos del
correspondiente ADO; en este caso, un nodo del modelo
navegacional.

La relación entre el ADV y su ADO es descripta utilizando
diagramas de configuración (configuration diagram), una
combinación entre clases UML y diagramas de colaboración,
mostrando qué mensajes son intercambiados entre el ADV
(actuando como cliente de consulta) y el ADO (en role de
servidor de datos).
En la ilustración, el ADV ChangeablePicture resuelve
información invocando los métodos getImage() y getText()
del nodo ChangeablePicture.
Esta información es utilizada para presentar los
componentes de la interfaz concreta: Image, Description y
SmallImage (arreglo de elementos). El parámetro “i” hace
referencia al índice de la imagen seleccionada en el arreglo.

En las aplicaciones web convencionales, usualmente se
especifica un ADV anidado observando un único ADO.
Esto puede ser la causa que el mismo nodo tenga varios
ADVs (por ejemplo para proveer muchas interfaces), pero no
es común que dos nodos (ADOs) yuxtapongan un único
ADV.
En aplicaciones web tipo RIA, puede necesitarse que un
ADV consuma información desde diferentes ADOs (nodos)
de acuerdo con las características de las interfaces.
Nótese que los aspectos de comportamiento de una interfaz
de aplicación web convencional son simples.

Cuando un anchor es seleccionado, el ADV del nodo actual
debe cerrarse y el correspondiente destino del link (otro
nodo) debe abrirse.
En consecuencia, hay otros comportamientos en
aplicaciones Web interesantes pero no simples como, por
ejemplo, permitir autocompletado de formularios.

Luego que la interfaz ha sido completamente especificada,
los modelos conceptuales, navegacionales y de interfaz son
implementados en plataformas particulares.
Para facilitar la adopción de la metodología OOHDM, se ha
implementado un framework de ejecución, llamado Cazon,
que soporta la generación semi-automática de código de
modelos OOHDM, incluyendo la instanciación de páginas
desde modelos navegacionales OOHDM.

OOHDM: Fase 4. Dinámica de RIAs con ADV-Charts.
Las aplicaciones web RIAs se caracterizan por una interfaz
dinámica y comportamiento rico que permite mejorar la
experiencia del usuario.
Mientras que los ADV permiten expresar características
estáticas de las aplicaciones convencionales, OOHDM utiliza
ADV-Charts para especificar aspectos dinámicos de estas
aplicaciones.
Los ADV-Charts son una variante de las máquinas de estado
que permiten expresar las transformaciones de una interfaz
que pueden surgir a partir de la interacción con un usuario.

Una transición en un ADV-Chart es anotada con un
identificador (ID), el/los evento/s que la causan, una
precondición que debe ser satisfecha para disparar la
transición, y una post-condición que es obtenido después
que esta transición se procesa.
La post-condición es expresada en términos de propiedades
de objetos que son alterados luego que la transición ocurre.

1
Event: MouseOver
PreCond: Focus (Icons[i])
PostCond:
Image.getURL() =
owner.getImage(i).getURL()
Description.getText() =
owner.getDescription(i)

En el ejemplo, también se utiliza la función Focus que indica
la posición del cursor y una pseudo variable PerCont (para
referir el contexto de percepción) para indicar los objetos
que son percibibles por el usuario.
Cuando un objeto es “agregados” al conjunto PerCont este
pasa a ser percibible por el usuario, caso contrario, cuando
es “retirados”, este deja de ser visible.
La palabra clave owner refiere al ADO observado que puede
ser utilizado como parte de una definición de transición para
consultar su estado.

En la ilustración, puede verse el ADV-Chart especificando el
comportamiento del ADV ChangeablePicture: cuando el
mouse se encuentra sobre un ícono, los Widget gráficos
correspondientes a la imagen actual y la descripción deben
ser actualizados con datos icono seleccionado.
El objeto propietario, u owner, del ADV es consultado por la
información requerida en la actualización utilizando la
posición en la lista (o índice) como parámetro. La flecha
negra hacia el mismo estado señala que el componente
SmallImage va a retornar al estado inicial luego que la
transición está completa.

Los ADV-Charts pueden componerse(a través del
anidamiento de estados) indicando como los ADVs internos
son afectados cuando el usuario interactúa con el sistema.
Estos pueden también ser utilizados (en combinación con
los diagramas de configuración) para indicar la forma como
las operaciones navegacionales son disparadas por los
eventos de interfaz.
Mientras que los estados anidados en un ADV siguen la
semántica de los Statecharts, significando que un ADV
puede estar en algunos estados (mediante los operadores
lógicos “Y” u “O”), el anidamiento de ADVs dentro de
estados indica que el ADV es perceptible por el usuario en
ese estado.

UWE
UML - Based Web Enginereeing. 1999.

UWE.
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, modelo navegacional y la construcción de la
interfaz de usuario, tienen requerimientos disjuntos que
deben ser tratados por separado.
A partir de esta separación de intereses, surgen las
metodologías de desarrollo de aplicaciones web que
permiten especificar los requerimientos atacando cada uno
de sus aspectos más importantes: el modelo conceptual,
navegacional y de interfaz de usuario.

UWE.
El modelo conceptual define cuáles serán los conceptos u
objetos del negocio que serán manipulados en la aplicación.
El modelo navegacional permite describir la información que
será presentada usualmente agrupada en un nodo y la
forma como interactuará con esta información a partir de las
relaciones conceptuales; un nodo, por ejemplo, indica el
criterio con el que se mostrarán lo objetos de negocio.
Finalmente el modelo de interfaz de usuario especifica de
qué forma se presentará la información al usuario y como
éste la percibirá en términos de elementos visuales.

UWE.
 La utilización de UWE en los proyectos, es una de las
buenas practicas de desarrollo y además provee la
documentación necesaria para dar soporte a las
aplicaciones desarrolladas, facilitando la implementación
de las mismas.
 Se podrían señalar muchas razones para que el uso de
herramientas de representación adecuadas dos de ellas
sin embargo pueden ser significativas a mediano plazo.
 Los lenguajes de programación web están evolucionando
hacia la orientación a objetos, PHP y ASP:net ya están en
ese camino, otros como Java, Python y C# son ya
orientados a objetos.
 Las aplicaciones, programas y servicios están cada vez
más integradas o encaminadas a la web. Pese a esto
muchos programadores, desarrolladores y analistas aún
no actualizan sus "cajas de herramientas".

UWE.
 La principal característica de UWE es el hecho
de ser una aproximación basada en
estándares, la cual no se limita al uso de UML,
además integra:
 XMI como modelo de intercambio de formatos,
 MOF para los metamodelos.
 Principios de la aproximación MDA (dirigida por
el modelo),
 El modelo de transformación del lenguaje QVT
y
 XML

UWE.
La razón principal para extender UML en lugar de
crear una técnica de modelamiento propietaria,
es la aceptación de UML en el proceso de
desarrollo de software, la flexibilidad para la
definición de un lenguaje de modelamiento
específico en el dominio WEB, también llamado
perfil UML, y un gran soporte del modelo de
visualización con las herramientas existentes de
UML CASE.

UWE.
 Es una herramienta para modelar aplicaciones web,
utilizada en la ingeniería web, prestando especial atención
en la sistematización y la personalización.
 Es una propuesta basada en el proceso unificado y UML
pero adaptada a la web.
 Es una metodología detallada para el proceso de autoría
de aplicaciones con una definición exhaustiva del proceso
de diseño que debe ser utilizado. Este proceso, iterativo e
incremental, incluye flujos de trabajo y puntos de control, y
sus fases coinciden con las propuestas en el Proceso
Unificado de Modelado.
 En requisitos separa las fases de captura, definición y
validación. Hace además una clasificación y un
tratamiento especial dependiendo del carácter de cada
requisito.

UWE.
 UWE está especializada en la especificación de
aplicaciones adaptativas, y por tanto hace especial
hincapié en características de personalización, como es la
definición de un modelo de usuario o una etapa de
definición de características adaptativas de la navegación
en función de las preferencias, conocimiento o tareas de
usuario.
 Otras características relevantes del proceso y método de
autoría de UWE son el uso del paradigma orientado a
objetos, su orientación al usuario, la definición de un meta-
modelo (modelo de referencia) que da soporte al método y
el grado de formalismo que alcanza debido al soporte que
proporciona para la definición de restricciones sobre los
modelos.

UWE.
 UWE cubre todo el ciclo de vida de este tipo de
aplicaciones centrando además su atención en
aplicaciones personalizadas o adaptativas.
 Su proceso de desarrollo se basa en tres fases
principales: la fase de captura de requisitos, la fase de
análisis y diseño y la fase de implementación.
 UWE detalla el proceso de autoría de aplicaciones con
una definición exhaustiva del proceso de diseño que debe
ser utilizado.

UWE.
 UWE se caracteriza por la importancia que da a la
segunda fase, la de análisis y diseño. Todo el proceso de
desarrollo de UWE se encuentra detallado y definido, así
como la estructura de los modelos que se van generando.
Sin embargo es en el análisis y diseño donde se enfoca
más la propuesta.
 Su iteratividad e incrementalidad incluye flujos de trabajo y
puntos de control; y sus fases coinciden con las
propuestas de RUP.

UWE. Características principales.
 Notación estándar.
 Métodos definidos: Pasos definidos para la construcción
de cada modelo.
 Especificación de restricciones: Recomendables de forma
escrita.
 Se basa en OCL (Objetc Constraint Language, lenguaje
de restricciones para objetos.)

UWE.
 Los principales de aspectos en los que se fundamenta
UWE son los siguientes: Lenguaje de modelado
unificado). Uso de una notación estándar, para todos los
modelos (UML)
 En requisitos separa las fases de captura, definición y
 validación.
 Hace además una clasificación y un tratamiento especial
dependiendo del carácter de cada requisito.
 Entra las ventajas más importantes de UWE es su uso
100% UML.
 Ofrece una herramienta denominada ArgoUWE.

UWE.
 UWE apunta a construir un modelo conceptual de una
aplicación Web, procurando hacer caso en la medida de lo
posible de cuestiones relacionadas con la navegación, y
de los aspectos de interacción de la aplicación Web.
 La construcción de este modelo lógico-conceptual se debe
llevar a cabo de acuerdo con los casos de uso que se
definen en la especificación de requerimientos.
 Es una notación y en un método. La notación se basa en
UML (OMG, 2003): para aplicaciones web en general y
para aplicaciones adaptativas en particular.

UWE.
El método consta de seis modelos:
 Modelo de casos de uso para capturar los requisitos
funcionales del sistema.
 Modelo conceptual para el contenido (modelo del
dominio). Usa el diagrama de clase con gran porcentaje
de detalle.
 Modelo de usuario: modelo de navegación que incluye
modelos estáticos y dinámicos.
 Modelo de estructura de presentación, modelo de flujo
de presentación.
 Modelo abstracto de interfaz de usuario y modelo de
ciclo de vida del objeto.
 Modelo de adaptación.

UWE.
 El modelo conceptual incluye los objetos implicados en las
actividades típicas que los usuarios realizarán en la
aplicación Web.
 Modelo de navegación: Consta de 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.
El primero especifica que objetos serán visitados por el
navegador a través de la aplicación. El segundo define
como se relacionarán, amplía el modelo con estructuras de
acceso como índices, consultas, etc.
 Modelo de presentación: Describe dónde y cómo los
objetos de navegación y accesos primitivos serán
presentados al usuario, es decir, una representación
esquemática de los objetos visibles al usuario.

UWE.
En el modelo de presentación se incluyen las interfaces de
usuario por medio de vistas estándares de interacción. En este
modelo se distinguen dos vistas diferentes:
 Estructura de la vista: Muestra la estructura del espacio de
presentación.
 Interfaz de usuario: Vista que presenta detalles acerca de los
elementos de la interfaz de usuario dentro de las páginas.

UWE.
 Interacción Temporal: Presenta los objetos que
participan en la interacción y la secuencia de los
mensajes enviados entre ellos.
 Escenarios Web: Permiten detallar la parte dinámica
del modelo de navegación, especificándoles eventos
que disparan las situaciones, definen condiciones y
explícitamente incluyen las acciones que son realizadas.
Junto con el modelo de interacción temporal, los
escenarios web proveen la representación funcional
dinámica del modelo de navegación.
 Diagramas: Los diagramas usados por UWE, son
diagramas UML puro. Entre los más importantes
tenemos: Diagramas de estado, de secuencia, de
colaboración y diagramas de actividad.

UWE.
 UWE permite que un diseñador Web pueda también hacer
uso de otra técnica de modelado UML que agreguen otras
vistas de la aplicación, en otras palabras, UWE no limita el
número de vistas posibles de una aplicación.

UWE.
Capturar requisitos
Analizar y diseñar
Implementar

UWE: Fases.
1. Captura, análisis y especificación de
requisitos: Durante esta fase, se adquieren,
reúnen y especifican las características
funcionales y no funcionales que deberá
cumplir la aplicación web. Trata de diferente
forma las necesidades de información, las
necesidades de navegación, las
necesidades de adaptación y las de interfaz
de usuario, así como algunos requisitos
adicionales. Centra el trabajo en el estudio
de los casos de uso, la generación de los
glosarios y el prototipado de la interfaz de
usuario.

UWE: Fases.
2. Diseño del sistema: Se basa en la
especificación de requisitos producido por el
análisis de los requerimientos (fase de
análisis), el diseño define cómo estos
requisitos se cumplirán, la estructura que
debe darse a la aplicación web.
UWE engloba más aspectos que OOHDM,
distingue entre diseño conceptual, de modelo de
usuario, de navegación, de presentación, de
adaptación, de la arquitectura, en el diseño
detallado de las clases y en la definición de los
subsistemas e interfaces.

UWE: Fases.
3. Codificación del software: Durante esta
etapa se realizan las tareas que comúnmente
se conocen como programación; que
consiste, esencialmente, en llevar a código
fuente, en el lenguaje de programación
elegido, todo lo diseñado en la fase
anterior.

UWE: Fases.
4. Pruebas: Las pruebas se utilizan para
asegurar el correcto funcionamiento de
secciones de código.

UWE: Fases.
5. La instalación o fase de implementación:
Proceso por el cual los programas
desarrollados son transferidos
apropiadamente al computador destino,
inicializados, y, eventualmente,
configurados; todo ello con el propósito de
ser ya utilizados por el usuario final. Incluye
la implementación de la arquitectura, la
estructura del hiperespacio, el modelo de
usuario, la interfaz de usuario, los
mecanismos adaptativos y las tareas
referentes a la integración de estas
implementaciones.

UWE: Fases.
UWE considera los requisitos de navegación
como un tipo de requisito funcional y, aunque
realmente no propone técnicas específicas para
este tratamiento, principalmente se basa en los
casos de uso, los separa con la idea de
identificar mejor los aspectos que influirán en el
modelo navegacional que se realiza en la fase de
análisis y diseño.

UWE: Fases.
6. El mantenimiento: Es el proceso de control,
mejora y optimización del software ya
desarrollado e instalado, que también incluye
depuración de errores y defectos que
puedan haberse filtrado de la fase de
pruebas de control.

UWE: Etapas.
 Planificación: Se utilizaron métodos como el
Abordaje a la comunidad, un Diagnostico
Participativo, un inventario de los equipos,
identificación del problema y detectar las
necesidades de la institución y tener buena
aceptación del proyecto, conjuntamente con la
recolección de información para el desarrollo de
la página.

UWE: Etapas.
 Diseño: La etapa de Diseño es el momento del
proceso de desarrollo para la toma de
decisiones acerca de cómo diseñar o rediseñar,
en base al conocimiento obtenido en la etapa
de planificación, así como a los problemas de
usabilidad descubiertos en etapas de
prototipado y evaluación.

UWE: Etapas.
 Usabilidad y Accesibilidad: En esta fase los
usuarios tendrán fácil uso y acceso las veces
que deseen,siempre y cuando haya un grado
de eficacia y se cumplan con los objetivos y a
una vez planteados.

UWE: Beneficios.
 La reducción de los costes de aprendizaje.
 Disminución de los costes de asistencia y ayuda al
usuario.
 Disminución en la tasa de errores cometidos por el
usuario.
 Optimización de los costes de diseño, rediseño y
mantenimiento.
 Aumento de la satisfacción y comodidad del usuario.
 Mejora la imagen y el prestigio de la institución.
 Mejora la calidad de vida de los usuarios, ya que
reduce su estrés, incrementa la satisfacción y la
productividad de la institución y la comunidad en
general.

UWE: Beneficios.
 UWE se acepta ampliamente por ser extensión de
UML en el desarrollo de software, es flexible en la
definición de un lenguaje de modelado específico de
dominio Web: el llamado perfil UM , y tiene amplio
apoyo de modelado visual por herramientas CASE
UML existentes.
 UWE utiliza "puro" notación UML y tipos de diagramas
UML siempre que sea posible para el análisis y diseño
de aplicaciones web, es decir, sin las extensiones de
cualquier tipo.

UWE: Etapas.
 Prototipado: Una semejanza de cómo quedara cuando
esté terminada a nivel de interfaz.
 Implementación y lanzamiento: En la implementación
de la página web es recomendable utilizar estándares
(HTML, XHTML...) para asegurar la futura
compatibilidad y escalabilidad del sitio.
 En esta etapa se debe llevar un control de calidad de
la implementación, supervisando que todo funcione y
responda a cómo había sido planificado, ya que la
usabilidad del sitio depende directamente de la
funcionalidad. Si algo no funciona, sencillamente no
se puede usar.
 Una vez implementada la página web y aprobada su
funcionalidad se procede al lanzamiento del sitio.

UWE: Etapas.
 Mantenimiento y seguimiento: Una vez puesta la
página web a disposición de los usuarios hay que ir
cambiando datos y mantener este sitio actualizado, ya
que esta página no puede permanecer en el olvido.
 Los problemas de uso no detectados durante el
proceso de desarrollo pueden descubrirse a través de
varios métodos, principalmente a través de los
mensajes, opiniones de los usuarios, el
comportamiento y uso del sitio.

UWE
 Estudio de la
metodología.
 4.5.1. Obtención de requerimientos
de los sistemas de información
Web.
 4.5.2. Casos de uso de procesos y
casos de uso navegacionales.
 4.5.2. Diseño Conceptual.
 4.5.3. Diseño Navegacional.
 4.5.4. Diseño de la presentación
(Interfaces abstractas.)
 4.5.5. Diseño de la Infraestructura
tecnológica del sistema de
información Web.
 4.5.6. Integración y prueba de
servicios.

UWE: Diseño conceptual.
Para hacerse una redefinición o definición sobre el
sistema que realimente se necesita, debe diseñarse un
modelo conceptual incluyendo el modelo obtenido del
sistema actual si lo hubiera, tomando en cuenta las
propiedades de la nueva arquitectura de software.
El diseño conceptual pretende definir claramente el
problema que se debe solucionar y elaborar una
solución para el mismo, en términos que todos los
involucrados lo puedan comprender.

Este modelado proporciona una visión más amplia del
problema. Trata de mantener esos requisitos en
contexto y tomar decisiones racionales. Captura las
tareas y la información esencial necesaria de las
actividades del negocio, dando como resultado una
visión de la solución enfocada en el proceso y centrada
en el usuario.
Especifica la ubicación, las capacidades y las
expectativas de los usuarios. Es similar a un análisis de
actividades, consiste en la solución de negocios para el
usuario y se expresa con casos de uso.

Perfiles de usuario.
Para indicar a los actores del sistema, se analizan las
personas que utilizan el sistema actual o utilizarán el
sistema propuesto; y sus roles o papeles que juegan en
su interacción con el mismo. Se toman en cuenta los
actores externos necesarios para las interrelaciones con
los actores internos.
El nombre del actor, reflejará el papel que tendrá para el
sistema e identificarlos permite definir los límites del
sistema y desarrollar un sistema dirigido al usuario que
tome en cuenta todas las funcionalidades esperadas por
los diferentes actores.

Escenarios de uso.
Estos describen los requerimientos del sistema en el
contexto del usuario, mostrando cómo se efectúan los
procesos de negocios o cómo se deberían efectuar.
Estos escenarios toman los datos recolectados y los
aplica en un documento donde paso por paso se
describe qué pasa primero, luego y después en la
ejecución de una tarea específica.

Escenarios de uso.
Métodos de construcción para los escenarios de
uso:
 Modelo de proceso de flujo de trabajo.
 Modelo de secuencia de tareas.
 Modelo de ambiente físico.

Métodos de construcción para los escenarios de uso:
 Modelo de proceso de flujo de trabajo.
Permite crear escenarios de uso, que muestran cómo
los trabajos específicos son ruteados a través de una
organización. Indica las condiciones necesarias para
que el trabajo sea encaminado de un área a otra y lo
necesario para que cada paso pueda efectuarse.
Requiere definir pre y pos condiciones.

 Modelo de secuencia de tareas:
Posee una serie de acciones o secuencias de tareas
que un usuario efectúa para completar una actividad. Se
usa con texto estructurado o no estructurado. El rol del
usuario debe estar identificado en el escenario, de
manera que cualquier persona pueda saber quien
efectúa cada actividad.

 Modelo de ambiente físico:
Cuando el lugar donde la aplicación se use afecte el
diseño de la misma, se requiere este modelo; pues
documenta cómo las actividades se relacionan con el
ambiente físico de la empresa y permite determinar
cómo los datos se mueven a determinadas
localizaciones.

 Diagramas de casos de uso:
Basándose en la secuencia de tareas de los escenarios
de uso, se crean los casos de uso, de manera que se
pueda tener una idea clara, de lo que se quiere
funcionalmente del sistema y de la forma en la que se
realizan los procesos.
La conjugación de todos los casos de uso en un único
diagrama, crea el diagrama de casos de uso el cual
modela la vista de los casos de uso del sistema e
involucra el modelado del contexto del sistema,
subsistema, o clase.

 Modelado del contexto del sistema:
Envuelve al sistema total dentro de un cuadro que
dibuja los límites del modelo y los actores que
interactúan con éste. Debe especificar los actores y el
significado de sus roles.

 Modelado de requerimientos del sistema:
Especifica qué hace el sistema desde el punto de vista
externo. De esta forma el diagrama de casos de uso
permite ver el sistema total como una caja negra, en el
cual se pueden ver las reacciones del sistema a las
cosas externas, pero no se puede ver cómo ess sistema
trabaja en el interior.

Figura rica de un sistema centralizado.

Sistema migrado hacia Internet.

Abstracción de clases del sistema antiguo.

Abstracción de clases detallado del sistema antiguo.

Ejemplo de caso de uso.
Nombre: Ingreso al sistema.
Precondiciones: Debe existir el usuario en el sistema.
Flujo principal:
1. El usuario inicia el sistema.
2. El sistema presenta formulario de ingreso.
3. El usuario ingresa credenciales.
4. El sistema verifica y valida información ingresada.
5. El sistema presenta opciones según parámetros.
Flujo alterno:
4.1. El sistema detectó parámetros incorrectos.
4.2. El sistema muestra mensaje de error.
Propósito: Ingresar al sistema con usuarios válidos.

Nombre: Ingreso de empleado nuevo.
Precondiciones: El usuario debe haber ingresado al
sistema y estar dentro.
Flujo principal:
1. El sistema presenta formulario.
2. El usuario ingresa información.
3. El sistema verifica información ingresada.
4. El sistema retorna mensaje de verificación.
5. El usuario graba información.
6. El sistema sigue su flujo básico.
Flujo alterno:
4.1. Se ingresó información incorrecta.
4.2. El sistema retorna mensaje de advertencia de error.
5.1. El sistema no pudo grabar.
5.2. El sistema retorna mensaje de error.

Diagrama de caso de uso: Inicio de sesión en el sistema.

Diagrama de clases.

Diagrama de secuencia para las altas,
bajas y consultas a empleados.

Diagrama de colaboración para la
administración de solicitudes de
contratos.

UWE: Diseño navegacional.Diagrama de espacio de navegación por departamento.

UWE:Diseñonavegacional.
Diagramadeestructuradenavegaciónparagerencia.

UWE: Diseño navegacional.
Este modelo se construye en dos fases. En una primera
etapa se desarrolla un modelo de espacio de la
navegación, construido como vista del modelo
conceptual y que indica cuáles son las clases y modelos
visitables. Es decir qué objetos pueden ser navegados.
Se representa mediante un modelo de clases especiales
llamadas clases navegacionales que son clases de UML
estereotipadas para indicar su semántica.
Luego la segunda etapa con el modelo de la estructura
de la navegación, indica qué es visitable y cómo estos
objetos son visitados. Es decir cómo son alcanzados en
la navegación.

Los diseños navegacionales representan el camino que
se debe tomar dentro de la web para realizar las
funciones autorizadas a cada tipo de usuario.
Objetivos:
 Representar los nodos y los enlaces en la estructura
del hipertexto.
 Diseñar trayectorias de navegación.
 Evitar la desorientación y conocer la carga de trabajo.
Resultado:
 Modelo de la estructura navegacional.
 Diagramas de clase UML.
 Elementos específicos del modelo.

• Elementos de navegación básicos:
- Clase de navegación, especifica el nodo que es visitado
por el usuario cuando navega por el sistema.
- (a la clase de navegación se le nombra de igual forma
que la clase de dominio que mapea o representa.)
- Enlaces de navegación, especifican que los objetos de
navegación son accedidos por objetos de navegación
fuentes.

• Definir las clases navegacionales

Modelo de estructura navegacional (segundo paso.)
• Mejorar el modelo de estructura navegacional
incluyendo las estructuras de acceso

• Utilizados para la selección de destinos navegacionales
desde un conjunto de elementos navegacionales.

UWE: Un proyecto de ejemplo
Ejemplo.
• Hacer un sistema web en el cual puedan cargarse los
distintos clubes de fútbol del país, con su información
particular.
• Cargar diferentes ciudades del país.
• Asociar clubes con ciudades.
• Obtener el informe de los campeonatos logrados por
cada club.
• Registro de usuario y login al sistema.

Tareas a realizar
1. Definir actores.
2. Definir relaciones entre actores.
3. Definir casos de uso para cada actor.
4. Definir capa de contenido.
5. Definir capa de navegación.
6. Definir capa de presentación.

1. Actores
• Se definen dos tipos de actores:
• Usuario no registrado.
• Usuario registrado.
• El no registrado podrá leer información.
• El registrado podrá hacer lo mismo que el no registrado,
más cargar información al sistema.
• Entregar una página con todos los actores del sistema y
una breve descripción de los mismos en formato tabular.

1. Actores
Actores Descripción
Usuario no registrado El usuario no registrado representa al
usuario que no posee login, que no… etc.
Usuario registrado Este actor representa a los usuarios que
no .. y tampoco .. Etc. etc.

2. Relaciones entre actores
• El usuario registrado puede hacer todo lo que hace el no
registrado, además de sus propias funcionalidades.
• Debe haber un diagrama exclusivamente para denotar
esto.
• Este diagrama, por sí solo, ocuparía la segunda página.

3. Casos de uso por actor
• Hacer un diagrama por actor.
• En cada diagrama colocar el actor y todos los casos de
uso asociados al mismo.
• No hace falta repetir los casos de uso de un actor, si la
generalización ya indica que un actor está heredando
los mismos de otro actor.

Diagrama de un
actor en
particular.
Notar el
diagrama
comprende
solo los casos
de uso
particulares a
este actor.

3. Casos de Uso por actor
Diagrama del actor
registrado.
Notar es un diagrama
separado del anterior.
Solo comprende sus casos
de uso.
No es necesario repetir los
casos de uso que “recibe”
por herencia.
Estos se denotan en la
segunda página del
documento.
Y en el diagrama
“generalización de
actores”.

• Una vez definidos ésto, se continua agregando los
esterotipos para casos de uso definidos por UWE
(Navegación, Proceso, Personalización).
• Estos se agregan en los diagramas de Casos de Uso.
• No hace falta crear nuevos diagramas para esto.
• Si no tienen los esterotipos o no saben como crearlos,
denotar que estereotipos tiene cada CU mediante notas
uml sobre los mismos.

• Luego de esto los diagramas quedarían de la siguiente
manera:

4. Capa de contenido
• La capa de contenido puede considerarse el diagrama
presentado por cada grupo de la Base de Datos.
• Diagrama Entidad/Relación (Tablas, campos con tipos
de datos, asociaciones entre tablas, etc.).
• Diagrama físico (Generado automáticamente por su
herramienta a partir del anterior, el cual ya incluye
claves foráneas, tablas intermedias, etc.)

4. Capa de contenido
Para este ejemplo usaremos como diagrama E/R (no
olvidar el físico y script de la BD)

5. Capa de navegación
• En Magic Draw, el perfil UWE, proporciona todos los
esterotipos necesarios.
• En este ejemplo, de los requerimientos y
funcionalidades de casos de uso, se sabe que debe
buscar clubes, cargar clubes nuevos, cargar ciudades,
cargar campeonatos, etc.
• Está basado en todas las funcionalidades para obtener
la navegación.

• Conceptualmente, se supone que el usuario se logueará
primero.
• Posteriormente podrá buscar un club, ver los
campeonatos de un club, ver los equipos en cada
ciudad.
• Además, si es usuario registrado, podrá cargar un club
nuevo, cargar un campeonato nuevo, o cargar una
ciudad.
• A ejemplos demostrativos se omitió el login y registro de
nuevo usuario en los CU.

• En algún momento debe poder navegarse hasta una
página de un club.
• O una página con los campeonatos de un club.
• O una página con los clubes de una ciudad.
• Basar en esto para saber las páginas (nodos) a los
cuales se llegará y refinaremos hacia atrás.
• Todos estos serán nodos navegacionales.
• Son los casos de uso que definimos con el estereotipo
<<navegacional>>

• Además habrá nodos de proceso.
• Los casos de uso definidos como <<proceso>> derivarán en
algún momento en un nodo de proceso.
• Es decir donde hay algún tipo de lógica de programación,
terminará en algún tipo de modificación de datos.
• En otras palabras, los casos de uso cargar club implica en algún
momento poder navegar hasta una página donde se cargará un
nuevo club.
• Cargar ciudad, igual al punto anterior. Etcetera.
• Notar que un caso de uso de <<proceso>> eventualmente
implicará dos nodos. Uno de navegación (la página de carga), y
el otro un nodo de proceso (la lógica de negocio donde se realiza
el proceso de carga y los controles necesarios para esto).
• Y debe haber una asociación de proceso entre estos.

• Se parte de la capa de contenido (diagrama BD)

• Cuales de las tablas son importantes para la
navegación y se colocan en el diagrama de navegación,
junto con sus asociaciones.
• Los links de navegación son dirigidos.
• Si se considera necesario un link de ida y vuelta entre
dos nodos, se deben colocar dos links de asociación.

5.Capadenavegación UWE: Un proyecto de ejemplo

• Ahora deben eliminarse las multiplicidades.
• Donde desde un nodo haya más de un link de
navegación de salida se utiliza un menú.
• Si la multiplicidad del lado final del link de navegación
es mayor a uno se utiliza:
• Index
• Guided tour
• Querie

• En la imagen anterior se reemplazan asociaciones con
multiplicidad por nodos con primitivas de acceso.
• En la imagen se ve color gris las clases con el estereotipo index.
• Ahora debe agregar la dirección en las asociaciones.
• En el ejemplo anterior desde un nodo de navegación Ciudad
general, se pasa a un Indice de Ciudades, donde se elige una y
se ven los clubes de dicha Ciudad.
• Lo mismo de un nodo Clubes, va a un nodo Índice de
campeonatos de Club, donde puede elegir uno en particular.
• Normalmente se quiere buscar una ciudad primero, o un club, o
grupos de los mismos.
• Desde los resultados de la búsqueda, tener una o varias
opciones de elección para ver la información de los mismo.
• Ahí se usan queries.

• Ahora en verde están las clases con estereotipo query.
• Las clases verdes indican un nodo donde se realiza una búsqueda
(query).
• La misma puede tener desde cero a varios resultados. Por tanto se
utiliza un menú (nodos con links de salida con multiplicidad mayor a
uno).
• Desde la lista de Ciudades, puede elegir cualquiera, para ver los clubes
en dicha ciudad.
• Desde la lista de clubes, puede elegir cualquiera para ver sus
campeonatos.
• Tanto la lista de clubes, como la lista de ClubCiudad tienen el mismo
contenido (un grupo de clubes)
• Por tanto en ClubCiudad puede también elegir cualquier Club y ver sus
campeonatos, lo que crea un link de navegación hacia
CampeonatosIndex.
• CampeonatosIndex es un indice porque puede tener multiplicidad
mayor a uno en el lado final o de salida (un club con varios
campeonatos).

• También debe verse información de usuarios, buscar
usuarios, elegir un usuario de una lista, etc.
• De esta manera se sigue refinando el diagrama de
navegación.

• Puede verse la información general de un club desde el
índice de clubes.
• Sin embargo ahora hay dos links de navegación de salida
de un mismo nodo.

• De nuevo, nodos con más de un link de navegación se
deben transformar en menúes.

• Se sigue refinando la navegación de esta manera.
• Luego se agregan los nodos de proceso.
• Estos salen de los casos de uso de proceso.
• Los mismos implican situaciones donde haya lógica de
negocio, transacciones con los datos subyacentes, etc.

• De nuevo, refinar los nodos con más de un link de salida.
• Y luego, definir un punto de entrada a la aplicación que
será simbolizado como el home.
• No dejar nodos sin conexión, ya que implicaría que no se
puede navegar hasta ellos.

• Debe refinarse el diagrama hasta cubrir todas las
funcionalidades, items en los requerimientos, etc.
• Evidentemente el diagrama puede crecer demasiado,
entonces debe separarse en diferentes sub-diagramas.
• Otra opción sería por navegación de cada actor.

6. Capa de presentación
• Provee una visión abstracta de la interfaz del usuario.
• Esta basada en el modelo de navegación.
• No tener en cuenta temas como colores, letras, posicionamiento
de los elementos dentro de la página, etc.
• Las clases de presentación se basan los nodos del diagrama de
navegación.
• Es decir, tendremos una clase de presentación por cada menú,
clase de navegación, primitivas de acceso (query, guided tour,
index), y clases de proceso.
• Para facilitar la ubicación de la clase de presentación de un
nodo de navegación se recomienda utilizar los mismos
nombres.
• Ejemplo: El nodo de navegación “InformaciónClub” del diagrama
de Navegación. A continuación, observe la clase de
representación que corresponde a este nodo.

• Clase de presentación del nodo de navegación del
mismo nombre.

• Ya existe una clase de presentación vacía.
• Para llenarla, se inicia desde la Base de Datos.
• ¿Qué atributos tiene, en la BD, la tabla que produce el
nodo de navegación InformacionClub, y posteriormente
la clase de presentación InformacionClub?

• De nuevo el diagrama de la BD.

• En el nodo de presentación se verá la información
relacionada con un club.
• De la tabla se tienen los atributos:
• Id
• Nombre
• Apodo Principal
• Apodo Secundario
• Estadio
• Año de fundación
• Id de la ciudad a la que pertenece (esta es una clave
foránea que viaja desde la tabla ciudad)

• Cada atributo de la clase será representado con un
elemento de UI.
• Entonces la clase de presentación InformaciónClub se verá
como en la siguiente página. Notar que un elemento, el
nombre de la ciudad, viene de otra tabla (Ciudad),
mediante un Join, con la información que se tiene con el id
de Ciudad.
• Se permiten dibujar los elementos dentro de la clase que lo
contiene, facilitando la visualización y entendimiento de los
mismos.

• Cuando un club, muestre en su presentación, el nombre de
la ciudad a la que pertenece, sería conveniente que del
nombre de la ciudad pueda llegarse a la lista de clubes de
dicha ciudad.
• Debería modificarse el diagrama navegacional permitiendo
un link de salida desde InformacionClub hacia
ClubesCiudad.
• Hecho esto, “ciudad” en nuestra clase de presentación ya
no sería solo texto, sino un enlace (link.)

• De esta manera, se van tomando los diferentes nodos de
navegación, y se construye su correspondiente clase de
presentación.
• Usualmente, en una misma página se presentará
información de varios nodos de navegación.
• Para esto use el estereotipo page.
• Una página puede contener varias clases de presentación,
así como grupos de presentación.
• Los grupos de presentación son contenedores que
pueden tener grupos de presentación y clases de
presentación.
• A continuación un ejemplo de la página de ClubesMenu.

• En esta página se desea ver:
• El menú principal
• El menú de clubes
• Información relacionada al club (información propia,
campeonatos, etc).
• Por lo tanto, se agregan las clases de presentación de
dichos elementos a la clase (tarea para el estudiante.)

• Simplemente se completan las páginas con las clases que
la componen. Recuerde que los atributos salen de la BD.
• Además, la navegación se hace según los links de
navegación entre los nodos en el diagrama de
navegación.
• Quizá necesite modificar la navegación y tener un link a
crear un nuevo club.
• Por tanto necesita añadir esto también a los casos de uso,
etc.
• Así de informacionClub puede llegar a informacionClub y
también a campeonatosIndex (diagrama de navegacion).
Por lo tanto:

• Como se ve, normalmente, los query se ven en una clase
con un formulario dentro.
• Un atributo que lleva a otro nodo, un anchor o ancla (link).
• Debe realizar las clases de presentación individuales.
• Y posteriormente, agrupar las necesarias para ir
presentando las páginas.

UWA: Ubiquituos Web Applications. 2001
 El proyecto UWA ha nacido de la colaboración de varios
grupos.
 Su fase de tratamiento de requisitos se basa en los roles
de usuario y en ir refinando los requisitos en un proceso
iterativo mediante el que se clasifican los objetivos según
su carácter.

NDT: Navigational Development Tecniques. 2004
 Es un proceso metodológico para especificar, analizar y
diseñar sistemas web.
 En el tratamiento de requisitos separa la captura, la
definición y la validación de requisitos, proponiendo
técnicas específicas para cada uno de ellos.
 Ofrece además una herramienta, NDT-Tool, que sirve
como soporte en la aplicación de sus técnicas.

DDDP: Design-driven Requirements Elicitation. 2004
 Esta propuesta para el tratamiento de requisitos es parte
del proceso design-Driven propuestos por Lowe y Ekluind.
 Consiste en realizar la captura, la definición y la validación
de requisitos durante el proceso de diseño.
 El proceso que ofrecen fue definido según un exhaustivo
análisis de best practices en el desarrollo de aplicaciones
comerciales para la web.

Técnicas comúnmente utilizadas en las metodologías

Introducción.
La programación extrema o Extreme Programming, es una
disciplina de desarrollo de software basada en los métodos
ágiles, que evidencia principios tales como el desarrollo
incremental, la participación activa del cliente, el interés en
las personas y no en los procesos como elemento principal,
y aceptar el cambio y la simplicidad.
El trabajo fundamental se publicó por Kent Beck en 1999, y
tomó el nombre de Programación Extrema por las prácticas
reconocidas en el desarrollo de software y por la
participación del cliente en niveles extremos.
PE: Programación Extrema.

Principios.
Éste método, al igual que RUP y MSF, también tiene
principios los cuales son buenas prácticas a tener presente
en el desarrollo del software.
Los principios XP comprenden diez buenas prácticas que
involucran al equipo de trabajo, los procesos y el cliente; los
cuales son:

Principios.
1. Planificación incremental.
2. Entregas pequeñas.
3. Diseño sencillo.
4. Desarrollo previamente aprobado.
5. Limpieza del código o refactorización.
6. Programación en parejas.
7. Propiedad colectiva.
8. Integración continua.
9. Ritmo sostenible.
10.Cliente presente.
Se toman los
requerimientos en
Historias de
Usuario, las cuales
son negociadas
progresivamente
con el cliente.

Principios.
1. Planificación incremental.
2. Entregas pequeñas.
3. Diseño sencillo.
4. Desarrollo previamente aprobado.
5. Limpieza del código o refactorización.
6. Programación en parejas.
7. Propiedad colectiva.
8. Integración continua.
9. Ritmo sostenible.
10.Cliente presente.
Se desarrolla primero la más
mínima parte útil que le
proporcione funcionalidad al
sistema, y poco a poco se
efectúan incrementos que
añaden funcionalidad a la
primera entrega, cada ciclo
termina con una entrega del
sistema.

Principios.
El ciclo de entrega de XP.

Principios.
XP describe un conjunto de prácticas para un desarrollo
óptimo, ya que define con exactitud los requerimientos
del usuario.
Esta metodología difiere de las demás por que se basa
en la adaptabilidad y la previsión, pues propone que,
cambiar los requerimientos del sistema durante el
desarrollo constituye un mejor acercamiento con el
usuario; surge como una solución a los problemas
derivados del cambio constante en los requerimientos de
un sistema.
Metodología XP.

Roles XP.
Metodología XP.
 Pieza básica en desarrollos XP.
 Más responsabilidad que en otros modos de
desarrollo.
 Responsable sobre la generación del código
fuente.
 Responsable sobre el diseño y maquetado de la
aplicación.
 Responsable de administrar la bases de datos.
 Responsable sobre la integridad del sistema
(pruebas.)
 Acepta críticas (código colectivo.)

Roles XP.
Metodología XP.
 Pieza básica en
desarrollos XP.
 Define
especificaciones.
 Influye sin
controlar.
 Confía en el grupo
de desarrollo.
 Define pruebas
funcionales.

Roles XP.
Metodología XP.
 Apoya al cliente
en la preparación
o realización de
las pruebas
funcionales.
 Ejecuta las
pruebas
funcionales y
publica los
resultados.

Roles XP.
Metodología XP.
 Recoge, analiza y publica información
sobre la marcha del proyecto sin afectar
demasiado el proceso.
 Supervisa cumplimiento de estimaciones
en cada iteración.
 Informa sobre la marcha de la iteración en
curso.
 Controla la marcha de las pruebas
funcionales, de los errores reportados, las
responsabilidades aceptadas y la prueba
añadida por los errores.

Roles XP.
Metodología XP.
 Experto en Metodología XP.
 Responsable del proceso en su
conjunto.
 Identifica las desviaciones y reclama
atención sobre las mismas.
 Guía al grupo de forma indirecta (sin
dañar su seguridad ni confianza.)
 Interviene directamente si es
necesario.
 Captura rápidamente el problema.

Valores X.P.
Un proyecto de software posee valores esenciales,
descritos a continuación:
Comunicación.
Simplicidad.
Retroalimentación (Feedback).
Coraje.
Respeto.
Metodología XP.

Comunicación.
Todos son parte del equipo y la comunicación es
esencial, desde los requerimientos hasta la
programación. En los métodos tradicionales de
desarrollo, la comunicación de los requerimientos
a los desarrolladores se realiza a través de la
documentación. En XP la comunicación se da por
transferencia de conocimientos en reuniones
frecuentes cara a cara entre usuarios y
desarrolladores, lo que le da a ambos una visión
compartida del sistema.
Metodología XP: Valores X.P.

Simplicidad.
Todos son parte del equipo y la comunicación es
esencial, desde los requerimientos hasta la
programación. En los métodos tradicionales de
desarrollo, la comunicación de los requerimientos
a los desarrolladores se realiza a través de la
documentación. En XP la comunicación se da por
transferencia de conocimientos en reuniones
frecuentes cara a cara entre usuarios y
desarrolladores, lo que le da a ambos una visión
compartida del sistema.

Simplicidad.
El objetivo es hacer pasos simples y pequeños,
mitigando las fallas a medida que ocurran. Crear
algo de lo cual pueda sentirse orgulloso y que
pueda mantenerse en el largo plazo a costos
razonables.
Un diseño y programación simple mejora la
calidad de las comunicaciones, pues es más fácil
implementar y entender por todos en el equipo.

Compromisos con el usuario establecidos en
todas las iteraciones, entregando software en
funcionamiento en cada una.
Mostrar al usuario el software frecuente y de
forma temprana, escuchando cuidadosamente
sus observaciones y realizando los cambios
necesarios. Adaptar los procesos al proyecto y no
al contrario.

 Retroalimentar el sistema: Por medio de la ejecución de
pruebas unitarias y de integración, los programadores
reciben retroalimentación directa del estado del sistema.
 Retroalimentación del cliente (usuario): Las pruebas de
aceptación, son diseñadas conjuntamente por el cliente y
los analistas de pruebas, obteniendo en conjunto
retroalimentación del estado actual del sistema.
Esta revisión puede hacerse cada 1 o 2 semanas,
permitiendo así que el cliente sea quien guíe el
desarrollo del software.

Retroalimentación del equipo: Cuando el cliente trae
nuevos requerimientos, el equipo puede
directamente proporcionar la estimación del tiempo
que tomará implementarlos.
Coraje: Es un valor muy importante dentro
de la P.E. Un miembro de un equipo de
desarrollo extremo debe tener el coraje de
exponer sus dudas, miedos, experiencias
sin "embellecerlas." Es muy importante ya
que el equipo se basa en la confianza para
con sus miembros. Faltar a esta confianza
es una falta muy grave.

UWE

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a UWE

Similar a UWE (20)

Más de Facultad de Ciencias y Sistemas

Más de Facultad de Ciencias y Sistemas (20)

Último

Último (20)

UWE