INDICE

INDICE ......................................................................................................................... 2
INTRODUCCIÓN ..................................................................................................... 3
DESARROLLO.............................................................................................................. 5
4.1. Requisitos para el análisis de las webapps. .................................................. 5
Figura 1: Proceso de Ingeniería de Requisitos .......................................... 8
Tabla 1: Tipos de requisitos contemplados en cada propuesta ......... 12
Figura 3Trazabilidad entre las fases del desarrollo de aplicaciones
Web ................................................................................................................ 14
4.2. El modelado de análisis para webapps. ................................................. 15
4.3. Modelo de contenido. ............................................................................... 16
4.4. Modelo de interacción. .............................................................................. 16
Representación de una clase de dominio 5 .......................................... 19
Figura Diagrama de casos de uso con perfil web 6 .............................. 19
4.5. Modelo función ............................................................................................ 20
Figura 7 Diagrama de actividades ........................................................... 21
4.6. Modelo de configuración. ............................................................................. 21
Tabla 2 atributos principales ...................................................................... 23
4.7. Análisis relación-navegación. ....................................................................... 24
Figura 8 Modelo de implantación ............................................................ 26
ANEXO................................................................................................................... 30
CONCLUSIONES ................................................................................................... 30
COMO INLUIRLO EN NUESTRA PAGINA WEB ....................................................... 33
PREGUNTAS .............................................................................................................. 34
ARTICULOS ................................................................................................................ 36
REFERENCIAS ....................................................................................................... 37
 INTRODUCCIÓN
Modelado de Análisis para Aplicaciones Web Un equipo de ingeniería Web
debe emprender el modelado de análisis si:

– La Web App es grande o compleja

– El número de clientes es grande
– El número de ingenieros Web es grande
– Las metas y los objetivos afectarán la línea de referencia del negocio
– El éxito de la Web App tendrá fuerte conexión con el del negocio.

Llevar a cabo una auditoría de seguridad de una aplicación web,

realizando test de penetración o análisis de código fuente de forma manual,
es una tarea que puede resultar ardua, tediosa que difícilmente será eficaz
por la dificultad de probar toda la superficie de ataque de la aplicación.
Probar todos los campos de entrada, con todos los roles de usuario, etc. es
complicado y seguramente se dejarán no pocas vulnerabilidades en el
código. El objetivo de obtener aplicaciones web con un alto grado de
seguridad, pasa por incluir en el ciclo de vida de desarrollo de aplicaciones
web, prácticas de análisis de la seguridad en las distintas fases del SDLC
(Ciclo de vida de desarrollo seguro), utilizando e integrando herramientas
automáticas de distinta índole que existen en el mercado y de open source
para obtener un mejor resultado de conjunto que deriva en una
metodología específica para integración de las herramientas
seleccionadas. En esta ponencia se tratará de mostrar las tendencias en los
posibles tipos de herramientas a emplear en cada fase del SDLC y algunos
ejemplos concretos. Se conduce un proceso de análisis intenso de una
aplicación web, verificando que no poséa ningúna vulnerabilidad capaz de
exponer la información de su empresa o la de sus clientes. Identificando
cada uno de los riesgos y vulnerabilidades en las aplicaciones web de su
organización. Ofrecemos una detallada identificación de todas las
vulnerabilidades con un claro y preciso informe sobre su nivel de riesgo real
y recomendaciones para remediarlas.

El proceso consiste en 3 simples pasos:

1. Recopilación de información de los sistemas utilizados incluyendo

tecnologías, versiones, frameworks, entre otros.
2. Análisis del sistema basado en la información obtenida previamente,
realizando diversas pruebas para identificar cualquier amenaza y
riesgo potencial.
3. Simulaciónes de ataque: creación y simulación de ataques a fin de
medir el verdadero nivel de riesgo detrás de cada uno de las
vulnerabilidades previamente detectadas.

Finalmente preparamos y entregamos un preciso y detallado informe sobre

todas las vulnerabilidades y problemas encontrados, incluyendo las medidas
a tomar para neutralizar cualquier amenaza identificada
 DESARROLLO
4.1. Requisitos para el análisis de las webapps.
Aunque esta actividad puede abreviarse para la ingeniería Web, los
objetivos globales de la recopilación de requisitos propuestos para la
ingeniería de software permanecen inalterados, adaptados para las
WebApp, dichos objetivos se convierten en:

1. Identificar requisitos de contenido.

2. Identificar requisitos funcionales.
3. Definir escenarios de interacción para diferentes clases de usuarios.

Los siguientes pasos de la recopilación de requisitos se dirigen para lograr

estos objetivos:

1. Pedir a los clientes que definan las categorías de usuario y describan

cada categoría.
2. Comunicarse con los clientes para definir los requisitos básicos de la
WebApp
3. Analizar la información recopilada y utilizar la información para realizar
un seguimiento con los clientes.
4. Definir casos de uso que describan escenarios de interacción para
cada clase de usuario

Los ingenieros web desarrollan sistemas complejos y, al igual que otros

tecnólogos que realizan esta tarea, deben usar mediciones para mejorar el
proceso de ingeniería web y el producto. La medición de ingeniería Web, si
se caracteriza de manera adecuada, podría lograr todos estos beneficios y
también mejorar la facilidad de uso, el desempeño de la Web App y la
satisfacción del usuario. En el contexto de ingeniería Web, las mediciones
tienen tres metas principales:
 1. Proporcionar un indicador de la calidad de la Web App desde el
punto de vista tecnológico.
2. Proporcionar una base para la estimación del esfuerzo.
3. Proporcionar una indicación del éxito de la Web App desde el punto
de vista empresarial.

Los ingenieros web desarrollan sistemas complejos y al igual que otros

tecnólogos que realizan esta tarea, deben usar mediciones para mejorar el
proceso de ingeniería web y el producto. La medición de ingeniería Web, si
se caracteriza de manera adecuada, podría lograr todos estos beneficios y
también mejorar la facilidad de uso, el desempeño de la Web App y la
satisfacción del usuario. En el contexto de ingeniería Web, las mediciones
tienen tres metas principales:

1. Proporcionar un indicador de la calidad de la Web App desde el

punto de vista tecnológico.
2. Proporcionar una base para la estimación del esfuerzo.
3. Proporcionar una indicación del éxito de la Web App desde el punto
de vista empresarial.

En el proceso de desarrollo de un sistema, sea o no para la web, el equipo

de desarrollo se enfrenta al problema de la identificación de requisitos. La
definición de las necesidades del sistema es un proceso complejo, pues en
él hay que identificar los requisitos que el sistema debe cumplir para
satisfacer las necesidades de los usuarios finales y de los clientes. Para realizar
este proceso, no existe una única técnica estandarizada y estructurada que
ofrezca un marco de desarrollo que garantice la calidad del resultado. Existe
en cambio un conjunto de técnicas, cuyo uso proponen las diferentes
metodologías para el desarrollo de aplicaciones web. Se debe tener en
cuenta que la selección de las técnicas y el éxito de los resultados que se
obtengan, depende en gran medida tanto del equipo de análisis y
desarrollo, como de los propios clientes o usuarios que en ella participen.

El proceso de especificación de requisitos se puede dividir en tres grandes

actividades (Lowe & Hall, 1999):

1- captura de requisitos

2- definición de requisitos

3- validación de requisitos

En la figura 1 se presenta el proceso de ingeniería de requisitos que incluye

estas tres actividades. Para la representación se ha usado la notación de

diagrama de actividades propuesta en UML (UML, 2001).

Figura 1: Proceso de Ingeniería de Requisitos

Captura de requisitos

La captura de requisitos es la actividad mediante la que el equipo de

desarrollo de un sistema de software extrae, de cualquier fuente de
información disponible, las necesidades que debe cubrir dicho sistema (Díez,
2001). El proceso de captura de requisitos puede resultar complejo,
principalmente si el entorno de trabajo es desconocido para el equipo de
analistas, y depende mucho de las personas que participen en él. Por la
complejidad que todo esto puede implicar, la ingeniería de requisitos ha
trabajado desde hace años en desarrollar técnicas que permitan hacer este
proceso de una forma más eficiente y precisa.

Tratamiento de Requisitos en Propuestas para la Web

El desarrollo de sistemas web agrupa una serie de características que lo

hacen diferente del desarrollo de otros sistemas (Koch, 2001). Por un lado,
hay que tener en cuenta que roles muy diferentes de desarrolladores
participan en el proceso: analistas, clientes, usuarios, diseñadores gráficos,
expertos en multimedia y seguridad, etc. Por otro lado, la existencia en estos
sistemas de una importante estructura de navegación obliga a un desarrollo
preciso de este aspecto que garantice que el usuario no se “pierde en el
espacio navegaciones del sistema” (Olsina, 1999). Estas ideas unidas al
hecho que los sistemas web suelen tratar con múltiples medios y es esencial
que ofrezcan una interfaz adecuada en cada momento, obligan a que
estos aspectos propios de la web deban ser tratados de una forma especial
en el proceso de desarrollo.

Estas características especiales también hay que tenerlas en cuenta en la

fase de especificación de requisitos (Escalona, 2002). Por ello, la mayoría de
las propuestas estudiadas ofrecen diferentes clasificaciones de los requisitos.
Sin embargo, la terminología usada no es siempre la misma. Para facilitar la
comprensión de las propuestas, antes de presentarlas, presentamos una
clasificación de requisitos relevantes en sistemas web.

• Requisitos de datos, también denominados requisitos de contenido,

requisitos conceptuales o requisitos de almacenamiento de información.
Éstos requisitos responden a la pregunta de qué información debe
almacenar y administrar el sistema.

• Requisitos de interfaz (al usuario), también llamados en algunas propuestas

requisitos de interacción o de usuario. Responden a la pregunta de cómo
va a interactuar el usuario con el sistema.

• Requisitos navegacionales, recogen las necesidades de navegación del

usuario.

• Requisitos de personalización, describen cómo debe adaptarse el sistema

en función de qué usuario interactúe con él y de la descripción actual de
dicho usuario.

• Requisitos transaccionales o funcionales internos, recogen qué debe hacer

el sistema de forma interna, sin incluir aspectos de interfaz o interacción.
También son conocidos en el ambiente web como requisitos de servicios.

• Requisitos no funcionales, son por ejemplo los requisitos de portabilidad, de

reutilización, de entorno de desarrollo, de usabilidad, de disponibilidad, etc.

En este apartado se van a presentar aquellas técnicas que incluyen el

proceso de definición de requisitos dentro del ciclo de vida. Alguna de las
propuestas que describimos cubrían la captura y definición de requisitos
desde sus primeras propuestas.

NDT - Navigational Development Techniques

Es una técnica para especificar, analizar y diseñar el aspecto de la
navegación en aplicaciones web. Para este trabajo, solo es relevante la
propuesta que ofrece para la definición y captura de requisitos. El flujo de
especificación de requisitos de NDT comienza con la fase de captura de
requisitos y estudio del entorno. Para ello, plantea el uso de técnicas como
las entrevistas o el brainstorming y JAD. Tras esta fase, se propone la
definición de los objetivos del sistema. En base a estos objetivos, el proceso
continúa definiendo los requisitos que el sistema debe cumplir para cubrir los
objetivos marcados. NDT clasifica los requisitos en:

• Requisitos de almacenamiento de información

• Requisitos de actores

• Requisitos funcionales

• Requisitos de interacción, representados mediante:

– Frases, que recogen cómo se va a recuperar la información del sistema

utilizando un lenguaje especial denominado BNL (Bounded Natural

Language) (Brisaboa, Penabad, Places & Rodríguez, 2001).

– Prototipos de visualización, que representan la navegación del sistema, la

visualización de los datos y la interacción con el usuario.

• Requisitos no funcionales

Todo el proceso de definición y captura de requisitos y objetivos que

propone NDT se basa principalmente en plantillas o patrones, pero también
hace uso de otras técnicas de definición de requisitos como son los casos
de uso y los glosarios. La propuesta ofrece una plantilla para cada tipo de
requisito, lo que permite describir los requisitos y objetivos de una forma
estructurada y detallada. Algunos de los campos de los patrones son
cerrados, es decir, solo pueden tomar valores predeterminados. Estos
campos permiten que en el resto del proceso del ciclo de vida de NDT se
puedan conseguir resultados de forma sistemática. El flujo de trabajo de
especificación de requisitos termina proponiendo la revisión del catálogo de
requisitos y el desarrollo de una matriz

de trazabilidad que permite evaluar si todos los objetivos han sido cubiertos
en la especificación. La propuesta viene acompañada de una herramienta
case, NDT-Tool, que facilita la cumplimentación de los patrones y que
permite automatizar el proceso de consecución de resultados.

Design-driven Requirements Elicitation

Design-driven Requirements Elicitation es parte del proceso design-driven

que proponen Lowe y Eklund (2002) para el desarrollo de aplicaciones en el
entorno Web La propuesta consiste en realizar la captura, definición y
validación de requisitos 17 durante el proceso de diseño. Ello hace necesario
que las actividades de diseño sean realizadas de modo que los
requerimientos pueden ser tratados y administrados. El proceso se basa en
el uso de prototipos para ayudar al cliente en la exploración de las posibles
soluciones y de los problemas que tienen que ser resueltos. Los usuarios o
clientes definen sus requerimientos basándose en la observación o trabajo
con estos prototipos. Es un proceso iterativo que consiste en reducir la
incertidumbre del cliente. El ciclo tiene tres fases: evaluación, especificación
y construcción. Este proceso fue definido sobre la base de un exhaustivo
análisis de “best practices” en el desarrollo de aplicaciones comerciales
para el entorno Web. Esta metodología trata a todos los requisitos de la
misma manera; estos requisitos son: de contenido, de protocolo de
interfaces, de estructura navegacional, de “look and feel”, de
representación interna de datos, de versionamiento, de control de cambios,
de seguridad, de gestión de contenido, de acceso de control, de eficiencia,
de monitoreo del usuario, de soporte de funcionalidad, de adaptación del
sistema, de identificación del usuario y sus derechos de acceso, etc. En las
tablas comparativas usamos la abreviatura DDDP para design-driven
development process (los autores no usan esta forma abreviada).
REQ. REQ. REQ. REQ. REQ. REQ. NO
DATOS INTERFAZ NAVEGACIONALES PERSONALIZACIÓN TRANSACIONALES FUNCIONALES
AL USUARIO

NDT √ √ √ √ √ √

DDDP √ √ √ √ √ √

Tabla 1: Tipos de requisitos contemplados en cada propuesta

Analizando los resultados, y teniendo en cuenta que las propuestas están

ordenadas por orden cronológico, resulta interesante observar el avance
que han tenido los requisitos en el entorno de la web. Las primeras
propuestas estaban más centradas en los requisitos de datos y los de interfaz
de usuario. Observando la tabla puede verse que las propuestas más
actuales resaltan la necesidad de tratar los requisitos de personalización y
navegación, así como los transaccionales de forma independiente

Figura 2 de Instrumentos propuestos para el modelado de aplicaciones web

El conjunto de instrumentos que se proponen presentan las siguientes
características:
 1. Se basan en conceptos de orientación a objetos.
2. Presentan un perfil web.
3. Se orientan en las dimensiones de la arquitectura para las
aplicaciones web.
4. Para su elaboración se puede utilizar herramientas CASE.
5. Son independientes de cualquier plataforma web de implantación.
6. Son independientes de la utilización de cualquier tipo de herramienta
de tipo CMS y RADD.
7. Son independientes a cualquier proceso, por lo que permite la libertad
de aplicar el enfoque que se considere el más adecuado

Figura 3Trazabilidad entre las fases del desarrollo de aplicaciones Web

Especificación de los requisitos funcionales

Los requisitos funcionales son aquellos que representan las funcionalidades

o capacidades que la aplicación Web deberá cumplir a los usuarios. El
instrumento de especificación de los requisitos funcionales consta de clave,
descripción del requisito funcional y actor implicado l (Sommerville, 2016).

Especificación de los requisitos no funcionales

Los requisitos no funcionales son aquellos que especifican propiedades

especiales que la aplicación Web deberá presentar, como restricciones en
el entorno o en la implementación, rendimiento, dependencia de la
plataforma, facilidad de mantenimiento, extensibilidad y fiabilidad. Los
requisitos no funcionales son restricciones sobre la operación del sistema. El
instrumento de especificación de los requisitos funcionales consta de tipo,
clave y descripción del requisito no funcional. l (Sommerville, 2016).

4.2. El modelado de análisis para webapps.

Se identifican el contenido que presentará la WebApps y se extraen las
funciones que se desarrollarán a partir de las descripciones de caso de uso.
Cuatro actividades de análisis, cada una con su aporte a la creación de un
modelo de análisis completo son:

 Análisis de contenido.
 Análisis de interacción.
 Análisis de funciones.
 Análisis de configuración.

Los elementos estructurales identifican las clases de análisis y los objetivos de

contenido que se requieren para crear una WebApp que satisfaga las
necesidades del cliente.

Los elementos dinámicos del modelo de análisis describen como

interactúan los elementos estructurales, entre ellos y con los usuarios finales

Especificación de los actores del sistema

Los actores son los usuarios que harán uso de la aplicación Web, por usuario
se entiende cualquier cosa externa al sistema que interactúa con él. Un
actor podría ser una persona, otro sistema de software, un dispositivo de
hardware, etc. El instrumento de especificación de los actores del sistema
consta de actor y función.
 4.3. Modelo de contenido.
El modelo de contenido contiene elementos estructurales que proporcionan
una importante visión de los requisitos de contenido para una WebApp.
Además incluye todas las clases de análisis: entidades visibles para el usuario
que se crean o manipulan conforme éste interactúa con la WebApp.

El modelo de contenido se deriva a partir de un examen cuidadoso de los

casos de uso desarrollados para la WebApp.

Definición de objetos de contenido: puede ser una descripción textual de

un producto, un artículo que describa un evento noticioso. Los objetos de
contenido se extraen en los casos de uso al examinar la descripción del
escenario para referencias directas e indirectas al contenido.

Relaciones de jerarquía de contenido: El modelo de contenido puede

contener diagramas de relación de entidades o árboles de datos que
bosquejan las relaciones entre los objetos de contenido o la jerarquía de
éste que mantiene una WebApp.

El modelo de contenido contiene elementos estructurales que proporcionan

la visión de los requisitos de contenido para una aplicación web. Dichos
elementos estructurales incluyen objetos de contenido (v. g., datos, texto,
imágenes, fotografías, video y audio) que se presentarán en la aplicación

4.4. Modelo de interacción.

Este modelo de interacción lo comprende cuatro elementos: Casos de uso,
Diagramas de secuencia, Diagramas de estado, Prototipo de interfaz de
usuario.

 Casos de Uso: Un caso de uso se modela para todos los procesos que
la WebApp debe llevar a cabo. Los procesos se describen dentro del
caso de uso por una descripción textual o una secuencia de pasos
 ejecutados. Los Diagramas de Actividad se pueden usar también
para modelar escenarios gráficamente.

Un modelo de casos de uso es un modelo visual que se utiliza para modelar

las interacciones entre la aplicación Web y los actores externos a él
(Sommerville, 2011).El modelo de casos es la primera vista arquitectónica de
la aplicación Web donde se reflejan la estructura y los escenarios de alto
nivel del sistema propuesto al cliente y los usuarios (Jacobson et al., 2006)

Diagrama de empaquetamiento de casos de uso

En una aplicación web, los casos de uso deben de ser agrupados mediante
el mecanismo de paquete proporcionado por UML, que es la forma de
agrupar elementos relacionados. Los paquetes deberán tener el estereotipo
<<useCasePackage>> para representar dicho mecanismo de agrupación.
Los paquetes son estructuras jerárquicas que puede contener más paquetes
además de casos de uso La figura muestra la notación y el estereotipo de
un paquete como instrumento para el empaquetamiento de casos de uso
acompañado por un actor. El diagrama debe de ir acompañado por el
instrumento de especificación de empaquetamiento de casos de uso. Para
especificar los paquetes se puede aplicar la plantilla que se muestra en la figura 4.
 Diagrama de Secuencia: Un diagrama de Secuencia muestra una
interacción ordenada según la secuencia temporal de eventos. En
particular, muestra los objetos participantes en la interacción y los
mensajes que intercambian ordenados según su secuencia en el
tiempo. El eje vertical representa el tiempo, y en el eje horizontal se
colocan los objetos y actores participantes en la interacción, sin un
orden prefijado.
 Diagramas de Estado: El comportamiento en tiempo real de cada
clase que tiene comportamiento dinámico y significativo, se modela
usando un Diagrama de Estado. El diagrama de actividad puede ser
usado también aquí, esta vez como una extensión del diagrama de
estado, para mostrar los detalles de las acciones llevadas a cabo por
los objetos en respuesta a eventos internos. El diagrama de actividad
se puede usar también para representar gráficamente las acciones
de métodos de clases.
 Prototipo de interfaz de usuario: Algunas propuestas se basan en
obtener de la definición de requisitos prototipos que, sin tener la
totalidad de la funcionalidad del sistema, permitan al usuario
hacerse una idea de la estructura de la interfaz del sistema con el
usuario. Esta técnica tiene el problema de que el usuario debe
entender que lo que está viendo es un prototipo y no el sistema final.
Modelo de dominio

El diagrama del dominio se centra en conocer el dominio del problema para

el que se va a desarrollar una aplicación Web. Un diagrama de dominio está
conformado por un conjunto de clases de muy alto nivel de abstracción
donde se representan los objetos del dominio del problema y sus relaciones
(Fowler y Scott, 2003; Schwinger y Koch, 2006; Koch, 2007; Koch, 2010). EL
diagramade dominio puede fácilmente transformarse a un modelo de
persistencia de datos.

Representación de una clase de dominio 5

Diccionario de las clases de dominio

El diccionario de clases de dominio tiene como función describir el

contenido de las clases definidos en el diagrama de dominio. En él se listan
todos los elementos de datos que conforman a la clase de dominio para
permitir su mejor comprensión l (Sommerville, 2016).

Figura Diagrama de casos de uso con perfil web 6

 4.5. Modelo función
Este modelo funcional aborda dos elementos de procesamiento de la
WebApp y cada uno representa un gráfico diferente de la abstracción de
procedimiento: Funcionalidad observable respecto al usuario y que entrega
al usuario final de WebApp .Las operaciones dentro de las clases de análisis
que implementan comportamientos asociados con la clase.

Diagrama de actividades

Un diagrama de actividades modela el flujo de proceso de un caso de uso.

En conjunto con la especificación del caso de uso representan a nivel visual
la dinámica la aplicación Web (Jacobson et al., 2006) Los diagramas de
actividades con perfil Web representan las acciones que son parte de un
caso de uso, así como los datos presentados al usuario y aquellos requeridos
como entrada de datos pueden ser modelados con precisión como
actividades

Para su mejor comprensión en la utilización del estereotipado propuesto, la

figura esquematiza como un ejemplo de diagrama de actividades con
perfil web para un caso de uso de Inicio de sesión.

Figura 7 Diagrama de actividades

4.6. Modelo de configuración.

Las WebApps se deben diseñar e implementar de forma que se acomoden
a una diversidad de ambientes, tanto del lado del servidor como del cliente.
Se deben especificar el hardware del servidor y el ambiente del sistema
operativo. Las WebApp deben someterse a una amplia prueba de cada
configuración de navegador que se especifique como parte del modelo de
configuración.
Configuración de aplicaciones web

Configuración desde Tomcat: el contexto

Aunque el comportamiento interno de cada aplicación se define desde su

propio fichero web.xml, se pueden especificar también sus características a
nivel global.

Dónde configurar la aplicación

Para configurar una aplicación web en Tomcat se puede:

Crear un nuevo elemento Context dentro del fichero de configuración

server.xml Utilizar el despliegue automático de aplicaciones, en cuyo caso
se puede configurar la aplicación: Definiendo un elemento Context en un
fichero XML independiente dentro del directorio
conf/Catalina/nombre_del_host/ (en nuestro caso el nombre será
localhost).

Dejando un WAR con la aplicación o bien la estructura de directorios que la

componen en el mismo directorio appBase. En este caso, Tomcat despliega
de manera automática la aplicación, y sus propiedades se tomarán del
elemento DefaultContext del fichero de configuración server.xml.

Cuando se instala una aplicación con el manager, si está activado el

despliegue automático es simplemente como si hubiéramos dejado
manualmente la aplicación en el directorio appBase. Si se desactiva el
despliegue automático (poniendo liveDeploy y autoDeploy a false en el
Host), entonces el manager crea un Context en el server.xml o bien lo toma
del fichero XML que le indiquemos.

El elemento "Context"
Como ya se ha comentado, un elemento Context representa una
aplicación web. Cada una de ellas debe tener un path único, definido
mediante el atributo path. Además, se debe definir un contexto con path
vacío que se considera la aplicación web por defecto, utilizada para
resolver aquellas peticiones que no encajen con ninguno de los otros
contextos.

A continuación se muestran algunos de sus atributos principales:

Tabla 2 atributos principales

Atributo Significado Valor por defecto

crossContext indica si la aplicación web puede false (por
comunicarse con otras razones de
seguridad)
debug nivel de mensajes de depuración 0
docBase directorio donde está la aplicación, ninguno
bien especificado de modo
absoluto o con respecto
al appBase del Host

path path de esta aplicación, que se ninguno

hace coincidir con la URL de la
petición para ver qué aplicación
debe servirla.
reloadable permite monitorizar los cambios false (se suele
de clases en /WEB- poner
INF/classes y /WEB- a true durante el
INF/lib para que no sea desarrollo)
necesario reiniciar Tomcat
 4.7. Análisis relación-navegación.
El análisis relación-navegación proporciona una serie de pasos de análisis
que luchan por identificar relaciones entre los elementos descubiertos
como parte de la creación del modelo de análisis. El enfoque de ARN se
organiza en cinco pasos:

Análisis de los participantes.

 Análisis de los elementos.

 Análisis de relaciones.
 Análisis de navegación.
 Análisis de evaluación.

La gran mayoría de las propuestas metodológicas para sistemas WebApp

resaltan este aspecto ofreciendo modelos que permitan diseñarlo e
implementarlo asegurando la calidad del resultado. Sin embargo,
analizando dichos modelos y técnicas y viendo los resultados de diferentes
estudios comparativos, se puede observar que este aspecto, en la mayoría
de las propuestas, se trata solamente en las últimas fases del ciclo de vida,
principalmente en diseño e implementación.

Los mecanismos de navegación se definen como parte del diseño. En esta

etapa, los desarrolladores deben considerar requisitos de navegación
globales.

El modelado de navegación incluye enlaces entre nodos o elementos

externos, así como herramientas de navegación. Dicho modelo permite
representar la navegación a páginas relacionadas a través de asociaciones
o enlaces hipertextuales. Dichas asociaciones se etiquetan, pueden tener
asociados atributos y pueden ser unidireccionales o bidimensionales.
Además, pueden incluirse relaciones n-arios con varios orígenes o destinos.
El modelo de navegación deberá importarlos elementos definidos en el
modelo estructural Web, pero agrega un elemento más en la notación
presente en la tabla. (MEDINA & GUZMAN, 2013)

Notación para el diagrama estructural con perfil web

Modelo de implantación

El modelo de implantación es representado mediante un diagrama de

despliegue que es la encargada de definir la arquitectura física de la

aplicación web por medio de nodos interconectados y que en el interior de

cada nodo presentan la distribución de componentes que servirán para el
funcionamiento del sistema. La tabla representa la notación de un
diagrama de despliegue en UML.
Figura 8 Modelo de implantación

Interfaces gráficas de la aplicación

La interfaz gráfica del usuario es la parte de la aplicación web ya terminada

que permite al usuario interaccionar con él. Las interfaces gráficas de
usuario ofrecen al usuario ventanas, cuadros de diálogo, barras de
herramientas, botones, listas desplegables y muchos otros elementos. Estas
interfaces gráficas están relacionadas con los esquemas de las interfaces
del usuario, es decir, las interfaces gráficas del usuario son la implementación
del modelo de presentación obtenido en la fase de análisis (Jacobson et al.,
2006).

Características en el desarrollo de aplicaciones web

Es importante darse cuenta de que el desarrollo de las aplicaciones Web

tiene ciertas características que lo hacen diferente del desarrollo del
software tradicional. Las aplicaciones Web presentan las siguientes
características de desarrollo descritas por:

• La constante evolución en los requisitos y funcionalidades.

• Son intrínsecamente diferentes del software tradicional ya que el

contenido incluye texto, gráficas, imágenes, audio y/o video integrados.

• Están hechos para ser utilizados por una muy variable comunidad de
usuarios.
• Están conducidos por contenido: incluyen la creación y desarrollo del
contenido.

• Demandan una buena apariencia y comportamiento, favoreciendo la

creatividad visual y la incorporación de multimedia en la presentación y la
interfaz.

• Se desarrollan de acuerdo a un calendario apretado y bajo presión de

tiempos.

•Las repercusiones de una falla o la insatisfacción de los usuarios pueden ser

bastante peor que los sistemas de aplicaciones convencionales.

• Son desarrollados por equipos pequeños de personas con diversos

trasfondos, habilidades y conocimientos que son comparados a un equipo
de desarrolladores de software multidisciplinario.

• Una rápida respuesta a los cambios constantes que existen en los avances
de las tecnologías web y en el surgimiento de nuevos estándares que
puedan ser utilizados.

• Su entrega es completamente diferente a la del software tradicional ya

que se enfrentan a una variedad de dispositivos de despliegue, soporte de
hardware, software y redes con una muy variada velocidad de acceso.

• La seguridad y privacidad son necesarios y demandan más que el

software tradicional.

• La web ejemplifica un vínculo muy grande entre el arte y la ciencia que

generalmente se encuentran en el desarrollo del software.

La ingeniería web
La ingeniería web, según Pressman (2009), toma para sí muchos conceptos,
principios y prácticas de la ingeniería del software. Además, acentúa
actividades técnicas y administrativas similares. Los principios fundamentales
de la ingeniería Web son los mismos que los de la ingeniería de software
(Kappel et al., 2006):

a) La formulación clara de los objetivos y requisitos.

b) El desarrollo sistemático de una aplicación web mediante modelos de

proceso y fases.

c) La planeación cuidadosa de las fases.

d) La auditoría continúa de todo el proceso.

Las aplicaciones web

Una aplicación web es un sistema hipermedia en donde los recursos se

encuentran vinculados unos a otros, por lo que debe de verse como un
sistema de nodos interconectados a través de vínculos. Estos vínculos
proporcionan la forma para navegar entre los recursos de la aplicación.
Muchos de los vínculos conectan a documentos textuales, pero el sistema
puede ser utilizado para distribuir hipermedia y datos personalizados de igual
forma.

Un software se considera un producto triunfante cuando satisface las

necesidades de las personas que lo utilizan, en cuanto se desempeña sin
fallas durante un largo periodo, cuando es fácil de modificar e incluso más
fácil de usar. Para cumplir con esto es indispensable que al desarrollar un
software se aplique una adecuada ingeniería. Las aplicaciones web son
demasiado complejas que su desarrollo, construcción y mantenimiento han
llevado a definir una nueva área dentro de la ingeniería de las ciencias
computacionales: la llamada ingeniería Web (Kappel et al., 2006). La
ingeniería Web es una rama alterna a la ingeniería del software, pero que
también muchos de sus preceptos se basan en conceptos definidos y
demostrados por la ingeniería del software. La ingeniería Web es un enfoque
relacionado al desarrollo, construcción y mantenimiento de los sistemas
basados en Web

La web

La web es un sistema gráfico de información de hipertexto e hipermedia,

distribuido, global, interactivo, dinámico e independiente de la plataforma,
que funciona en Internet. La Web hace uso del lenguaje de hipertexto
conocido como HTML (Hypertext Markup Language, lenguaje marcador de
hipertexto) que sirve para crear una red de documentos, los cuales están
enlazados unos a otros y que se encuentran localizados alrededor del
mundo. La Web es un nivel de infraestructura, es un espacio creado bajo
ingeniería con la meta de especificar lenguajes y protocolos (World Wide
Web, 2011, 18 de octubre). La figura 9 esquematiza de manera sencilla la idea
fundamental de lo que es la Web.
 ANEXO
CONCLUSIONES
En el punto 4.1 ha presentado el estado del arte de las propuestas que se
ofrecen en las metodologías para la web en el proceso de definición de
requisitos. Se ha comenzado planteando la estructura básica de dicho
proceso y las técnicas más comunes aplicadas de forma clásica en la
ingeniería de requisitos.

En el punto 4.2 se identifican como será el análisis y son 4 que como tal
veremos las funcionalidades y el objetivo para las webapps. Considero que
son elementos estructurales para un buen diseño de una página que al final
satisface las necesidades del cliente.

En el punto 4.3, es como se va estructurar primero los contenidos, tener muy

importante la visión de cómo será el contenido para atracción para los
usuarios. Como se acomodarán los artículos, el cómo van interactuar con
los usuarios cuando requieran una sugerencia o emergencia, que el
contenido no sea tan rigurosa, si no que sea amigable para el usuario y
satisface también las necesidades del cliente. Se basa en lo que será visto
por el usuario, como imágenes, videos y formularios. Es importante por la
forma que el usuario va interactuar en el sitio web y tener muy en claro lo
que se tendrá como títulos y la jerarquía de esas etiquetas html y tener una
pequeña descripción de cada contenido que será visto por el usuario ya
que, sin importar lo que se encuentre tenemos que organizar el texto.

En el punto 4.4 tenemos 4 elementos esenciales que nos ayudara tener más
claro el flujo del sitio web Casos de uso Diagramas de secuencia, Diagramas
de estado, Prototipo de interfaz de usuario.

 Diagramas de secuencia, será que pasará si (botón inicio, realiza esta

función y que hará para que el usuario regrese), en particular muestra
 que cada botón dentro de la página tenga una función y que hace
ese botón.
 Diagramas de estados, es la parte más detallista en eventos internos
(métodos y clases).
 Prototipo de interfaz de usuario. Aquí en este apartado son las
propuestas que tenga el usuario, ya que también le permita al cliente
tener una idea más clara de la estructura de la interfaz.

En el punto 4.5 aborda dos elementos que es la parte funcional del sitio web
donde el usuario, va interactuar. Un ejemplo es donde el usuario va
depositar inquietudes o ponerse en contacto con el vendedor o
administrador del sitio web, también si vende algún producto la parte
monetaria donde va a subir la tarjeta débito.

En el punto 4.6 deben de diseñar e implementar de forma que se

acomoden, así como la forma del servidor como del cliente. Ya que deben
de acoplarse a la configuración, que sería el inicio de sesión, la forma tan
optima de la página.

En el punto 4.7 Es más que nada el ciclo de vida ya que definen el diseño y
las tecnicas de cada espacio que tenga el sitio web Muchos de los sitios
Web que encontramos en Internet presentan una serie de enlaces hacia sus
diferentes secciones a lo largo de todas sus páginas, como una manera de
mostrar al usuario los contenidos del sitio. Estos menús de navegación
pueden presentarse en diferentes formatos y organización, ya sean simples
listas de opciones, sistemas gráficos, sistemas de pestañas, menús
desplegables, etc.

En primer lugar, este trabajo define los sistemas y menús de navegación más
utilizados que se pueden encontrar en las sedes
Web. En segundo lugar, analiza los diferentes tipos de sitios Web en función
de la estructura, tipo de contenido, volumen de información y perfil de
usuario y presenta los menús de navegación más comunes que podemos
encontrar.

Por último, se analizan con más detalle los diferentes sistemas de

navegación, descritos bajo los aspectos de usabilidad y accesibilidad tanto
desde el punto de vista del diseño como desde el punto de vista
tecnológico.
 COMO INLUIRLO EN NUESTRA PAGINA WEB
En el punto 4.1 Va mucho de la mano cómo es que el cliente visualiza mucho
el sitio web. Y nosotros como desarrolladores Tenemos que dar ese análisis

-Carrito de compras que yo lo añadí con sus descripciones del producto ya

que es muy necesario y eso nos ayuda con diagrama de casos para que la
función.

En el punto 4.2 Es como ira el contendió, yo puse carrusel, productos,

contacto, y formularios
En el punto 4.3 El modelo de contenido es como va ir el flujo del contenido
•Encabezado
•Galería (carrusel)
• Productos (catalogo digital)
•Video sobre el (quienes somos)
•contactos
•Ubicación
•Formulario

En el punto 4.4 En el modelo de interacción son sobre los diagramas me iría

más por el del caso, siento que es más óptimo es decir casa botón funciona
para, esto y regresa al inicio, eso lo incluiría para que el cliente tenga una
manera más grafica cómo funciona la Webapps

En el punto 4.5 La parte funcional, se ve implicado el carrito de compras

como va a funcionar cuando el usuario le dé (comprar) y depositara el
dinero y como será su transacción y la comunicación al cliente con el
vendedor durante todo ese tiempo.

En el punto 4.6 En la parte de la configuración debe someterse a la

seguridad e investigar los servidores que tipo de seguridad me brinda, para
configurar

En el punto 4.7 Ya la página funcionando con todo sus enlaces que lleve
para su funcionamiento ya que estaría asegurando su calidad del resultado
final
 PREGUNTAS
1. ¿Cuáles son los principales 3 grandes tareas?
a) Formulación
Recopilación de requisitos
Modelado de análisis
b) Modelado de datos
Análisis de contenido.
Análisis de interacción
c) Diagramas de Estado
Prototipo de interfaz de usuario
Formulación
2. ¿La jerarquía de usuario en qué consiste?

a) Las categorías de los usuarios finales se identifican como parte de las

tareas de formulación
b) Diagramas de estado
c) Modelado de análisis
3. ¿Cuales son las 4 actividades de análisis para las WebApps?
a) Análisis de contenido.
Análisis de interacción.
Análisis de funciones.
Análisis de configuración
b) Análisis de datos.
Análisis de formulario.
Análisis de diseño.
Análisis de configuración
c) Análisis de contenido.
Análisis de datos.
Análisis de navegación.
Análisis de configuración
4. ¿El modelo de contenido consiste en?
a) contiene elementos estructurales
b) contiene datos de diseño
c) consiste en diagramas de casos
5. ¿Relaciones de jerarquía de contenido en que cosiste?
a) etiquetas de encabezado de html
b) contenido de mayor interacción
c) Diagrama de caso
6. ¿El Modelo de Interacción en qué consiste?
a) diseño
b) diagramas
c) evaluación
7. ¿En qué consiste el diagrama de caso?
a) modela para todos los procesos que la WebApp debe llevar a cabo.
b) El diseño que se presentará al cliente
c) Comportamiento en tiempo real de cada clase
8. ¿El análisis relación-navegación proporciona?
a) identificar relaciones entre los elementos
b) lucha para la satisfacción del cliente
c) organiza y optimiza la webApps
9. ¿Qué es ARN?
a) Análisis relación-navegación.
b) Análisis regestionar-necesidad del cliente.
c) Análisis razones-navegación estructurales.
10. ¿Qué es el modelo funcional?
a) aborda elementos de procesamiento de la WebApp
b) comportamientos de las webApps
c) Prototipo de interfaz

ARTICULOS
 REFERENCIAS
1. Koch, N. (2001). Software Engineering for Adaptative Hypermedia Applications. Ph.
Thesis, FAST Reihe Softwaretechnik Vol(12), Uni-Druck Publishing Company,
Munich. Germany
2. Olsina, L. (1999). Metodología cualitativa para la evaluacióny comparación de la
calidad de sitios web. Ph. Tesis. Facultad de Ciencias Exactas. Universidad de la
Pampa. Argentina
3. Koch, N. & Escalona, M. (2002). Ingeniería de Requisitos en Aplicaciones para la Web
– Un estudio comparativo. LSI. http://www.lsi.us.es/docs/informes/LSI-2002-4.pdf
4. MEDINA, J. C. & GUZMAN, L. A. (2013). Diagramas de navegación en aplicaciones
Web. CORE. https://core.ac.uk/download/pdf/229161269.pdf
5. P. Díaz, I. Aedo y S. Montero, Desarrollo de hipermedia y web como ADM. En Díaz,
Ma. Paloma, Montero, Susana y Aedo Ignacio (coordinadores). Ingeniería de la Web y
patrones de diseño. pp. 39-70. España: Pearson Educación. 2005
6. M. Fowler y K. Scott,UML gota a gota, México: Addison-Wesley Longman. 1999.

7. Sandeau, J. 1. (2016). Madame de Sommerville. Wentworth Press.

8. S. Castejon Garrido, “Arquitectura y diseño de sistemas Web modernos”, InforMAS,
Revista de Ingeniería Informática del CIIRM, num. 1, diciembre, 2004. [En línea]
disponible en http://www.ciimurcia.es/informas/ene05/articulos/ Arquitectura_y_
disenyo_de_sistemas_ web_modernos.pdf. [02 de noviembre de 2022]

9. Desarrollo y configuración de aplicaciones web. (s. f.). Recuperado 2 de noviembre de

2022, de http://www.jtech.ua.es/j2ee/2006-2007/restringido/servd-web/sesion02-
apuntes.html
10. L. Shklar y R. Rosen, Web application architecture: principles, protocols and practice.
Great Britain: John Wiley & Sons, Ltd. 2003
11. S. Pressman, Ingeniería del software: Un enfoque práctico. Sexta edición. México:
McGraw-Hill/interamericana Editores. 2009.