Fase 2 modelado del análisis de i web

MTI. ROSA IMELDA GARCIA CHI

INGENIERIA WEB Modelado del Análisis de IWeb


Maestría en Tecnologías de la Información


Objetivo del Modelado de Análisis

Desarrollar la habilidad para la formulación, recopilación de requisitos y el modelado de análisis

describiendo la motivación básica (metas) y objetivos para la WebApps,

definir la categoría de usuarios, señalar los requisitos de contenido y de función para la WebApps,

establecer una comprensión básica de por qué se construirá la WebApps quien la usará y que

problema(s) les resolverá a los usuarios.


Propósito

El propósito es comprender que el equipo de ingeniería Web debe emprender el análisis de una

WebApp cuando se cumpla con requisitos mínimos.


Requisitos para el análisis de las WebApp

•Formulación

•Recopilación de requisitos

•Modelado de análisis

El análisis de requisitos para las WebApp

abarca tres grandes tareas:


La jerarquía de usuario

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

formulación y de recopilación de requisitos.

Las categorías de usuarios son relativamente limitados y no necesitan

una representación UML.

Sin embargo, cuando crece el número de categorías de usuario, a veces es

aconsejable desarrollar una jerarquía de usuarios.


Desarrollo de casos de uso

Los casos de uso

se desarrollan para cada categoría de

usuario descrita en la jerarquía de usuario.

En el contexto de la ingeniería Web, el caso de uso en si mismo es

relativamente informal:

un párrafo narrativo que describe una

interacción especifica entre el usuario y la

WebApp.


Afinación del modelo de caso de uso

A la par que se crean los diagramas de casos de uso para cada categoría de usuario,

•se desarrolla una vista superior de los requisitos de la WebApp observables de manera externa.


Diagrama de caso de uso para cliente nuevo


Cada paquete se valora para garantizar que es:

•Comprensible.

•Cohesivo

•Libremente acoplados

•Jerárquicamente superficial.


Comprensible

• Todos los clientes entienden el propósito del paquete

Cohesivo

• El paquete aborda funciones relacionadas cercanamente una con otra

Libremente acoplados

• Las funciones o clases dentro del paquete colaboran una con otra, pero la colaboración exterior del paquete se mantiene en un mínimo

Jerárquicamente superficial

• Las jerarquías funcionales profundas son difíciles de navegar y entender para los usuarios; en consecuencia el número de niveles dentro de una jerarquía de casos de uso debe reducirse siempre que sea posible


Puesto que el análisis y modelado de actividades son actividades iterativas…

es probable que se sumen nuevos casos

de uso a los paquetes que se han definido

que los casos de uso existentes sean

refinados y

que casos de uso específicos puedan

reubicarse en paquetes diferentes


Ejemplo de un diagrama de casos de uso

sistema

actor

Caso de uso

Relación

No es una persona es otro

sistema


El modelado de análisis para WebApps


El modelado de análisis para WebApps

Finalmente los requisitos específicos de la implementación se deben desarrollar de modo que el ambiente y la infraestructura que apoyan la

WebApps puedan construirse.

Se identifican el contenido que presentará la WebApp y se extraen las funciones que se desarrollarán a partir de las descripciones de caso de uso.

La descripciones de los casos de uso se analizan gramaticalmente para identificar potenciales clases de análisis y las operaciones y atributos asociados con cada clase.

Se basa en la información que contienen los casos de uso desarrollados para la aplicación.


ACTIVIDADES DE ANÁLISIS

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


Breve descripción de las Actividades de Análisis

Análisis de contenido:

• Identifica todo el espectro del contenido que ofrecerá la WebApp.

• El contenido incluye texto, gráficas e imágenes, así como datos de video y audio.

Análisis de interacción:

• Describe cómo interactúa el usuario con la WebApp

Análisis de funciones:

• Define las operaciones que se aplicarán al contenido de la WebApp

• Describe otras funciones de procesamiento, independientes del contenido pero necesarias para el usuario final

Análisis de configuración:

• Describe el ambiente y la infraestructura en la que reside la WebApp


La información recopilada durante la tarea de estos cuatros

análisis se deben revisar, modificar cuando se

requiera y luego organizarse en un

modelo que pueda pasarse a los

diseñadores de WebApp


El modelo en si mismo contiene elementos estructurales y dinámicos.


El modelo de contenido


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


Al igual que otros elementos del

modelo de análisis,

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

Un objeto de contenido puede ser

una descripción textual de un

producto, un articulo que describa un

evento noticioso.


…Definición de objetos de contenido

• al examinar la descripción del escenario para referencias directas e indirectas al contenido.

Los objetos de contenido se

extraen en los casos de uso

Aunque no existe referencia directa al contenido, está implícita.


El ingeniero web podría reunirse con el autor del caso de uso y comprender en forma más detallada lo que significa “información descriptiva”.

En este caso, el autor del caso de uso puede indicar que “información descriptiva” incluye:

1) una descripción general del producto o servicio en un párrafo

2) una fotografía del producto o servicio que se ofrece

3) una descripción técnica del producto o servicio, en varios párrafos

4) un diagrama esquemático del componente que muestre cómo encaja en un sistema típico

5) un breve video que muestre cómo utilizar lo que se ofrece en la página


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.


Ejemplo de árbol de datos


Puede utilizar para este tipo de diagrama: Mapa de Sitio Web que se encuentra disponible en Microsoft Visio

En Software y base de datos - Mapa de sitio web


Clases de Análisis para las WebApps

Las clases de análisis se derivan al examinar cada caso de uso

Un rápido análisis gramatical del caso de uso, permitirá identificar las clases candidatas

Por ejemplo, un caso de uso de Seleccionar Producto, daría un análisis que tiene o incluye dos clases: Características del producto y Factura de Venta.


Ejemplo de clases de análisis para un caso de uso


Una clase en UML se contruye:

clase

atributos

Operación disponible en la clase

Nombres de rol asociación

generalización

multiplicidades restricción

calificador

Nombre de la clase


TIPOS DE RELACIONES


El modelo de interacción


El 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


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 casos de uso son el elemento dominante del modelo de

interacción para las WebApps.

No es raro describir 100 o más casos de uso cuando se analizan, diseñan y construyen grandes y

complejas WebApps.

Sin embargo, un porcentaje relativamente bajo de estos casos

de uso describe las principales interacciones entre las categorías

de usuario final (actores) y el sistema.

Otros casos de uso refinan las interacciones y proporcionan el

detalle de análisis necesario para guiar el diseño y la construcción


…Casos de Uso

Los Diagramas de Actividad se pueden usar también para modelar escenarios gráficamente.

Una vez que el comportamiento de la aplicación está captado de esta manera, los casos de uso se examinan y amplían para mostrar qué objetos se interrelacionan para que ocurra este comportamiento.


Breve explicación de un Diagrama de actividad

en UML


generalmente secuenciales además presenta los resultados de dichas acciones.

Un diagrama de actividades muestra un flujo de acciones

(nodos ejecutan un proceso),


Capturar las acciones internas

de un proceso.

Capturar la especificación de un caso de uso.

Mostrar flujos entre procesos del

negocio.

¿Para qué sirve?


Elementos que componen un diagrama de actividad


Ejemplo de diagrama de actividad:

Realizar consignación


En el diagrama anterior puede verse la secuencia de acciones que se realiza para hacer una consignación en una entidad bancaria.

Cada actividad se realiza cuando finaliza la actividad anterior.

Por ejemplo, primero se debe llenar el formato antes de entregarlo, junto con el dinero, al cajero.

Explicación realizar consignación


Otros elementos


Cuando se tiene un conjunto de Actividades que están relacionadas, generalmente la relación esta dada por los actores que ejecutan las acciones. Para modelar

esta relación se divide el diagrama en carriles

Particiones, calles o carriles


Objetos

En un diagrama de actividad es posible presentar los objetos que entran o salen de una actividad o que simplemente son “afectados” por ella.


Objeto en un diagrama de actividad


La información para elaborar los diagramas de actividad se obtiene de los casos de uso y los requerimientos.

¿De donde se obtiene la información ?


Diagrama de actividad


Diagrama de actividad con calles


El diagrama de Actividad

En el Lenguaje de Modelado Unificado, un diagrama de actividades representa los flujos de trabajo paso a

paso de negocio y operacionales de los componentes en un sistema.

Un Diagrama de Actividades muestra el flujo de control general.


En UML 1.x, un diagrama de Actividades es una variación del Diagrama de estados UML donde los

"estados" representan operaciones, y las transiciones representan las actividades que ocurren cuando la

operación es completa..

El diagrama de Actividades UML 2.0, mientras que es similar en aspecto al diagrama de Actividades UML

1.x, ahora tiene semánticas basadas en redes de Petri.

En UML 2.0, el diagrama general de Interacción está basado en el diagrama de Actividades.


Diagrama de actividad.

Es una forma especial de diagrama de estado usado para modelar una

secuencia de acciones y condiciones tomadas dentro de un proceso.


La especificación del Lenguaje de Modelado Unificado UML define un diagrama de actividad como:

“… una variación de una máquina estados, lo cual los estados representan el rendimiento de las acciones o subactividades y las transiciones se provocan por la

realización de las acciones o subactividades.”


El propósito del diagrama de actividad:

Es modelar un proceso de flujo de trabajo (workflow) y/o modelar operaciones.

Una Operación es un servicio proporcionado por un objeto, que está disponible a través de una interfaz.

Una Interfaz es un grupo de operaciones relacionadas con la semántica.


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.

Cada objeto o actor tiene una línea vertical, y los mensajes se representan mediante flechas entre los distintos objetos.

El tiempo fluye de arriba abajo.

Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren.


Ejemplo: Diagrama de Secuencia


¿Que Es Un Diagrama De Secuencia?

Es una forma de diagrama de interacción que muestra los objetos como líneas de vida a lo largo de la página y con sus interacciones en el tiempo representa das como mensajes dibujados como flechas desde la línea de vida origen hasta la línea de vida destino.

Los diagramas de secuencia son buenos para mostrar qué objetos se comunican con qué otros objetos y qué mensajes disparan esas comunicaciones.

Los diagramas de secuencia no están pensados para mostrar lógicas de procedimientos complejos.


Utilidad De Un Diagrama De Secuencia

Se utiliza para una gran variedad de propósitos y con diferentes niveles de detalle sobre el programa.

Si tiene un diagrama de casos de uso en el que se resumen los usuarios del sistema y sus objetivos,

Si ha identificado los mensajes que llegan a una interfaz de un componente, puede crear diagramas de secuencia en los que se describa cómo interactúan los elementos internos del componente para lograr el resultado necesario para cada mensaje entrante.


Características Diagrama De Secuencia:

Los diagramas de secuencia muestran gráficamente las interacciones del actor y de las operaciones a quedan origen

Los diagramas de secuencia se preparan durante la fase de análisis de un ciclo de desarrollo

Su creación depende de la formulación previa de los casos de uso.


Características Diagrama De Secuencia:

El comportamiento del sistema es una descripción delo que hace, y no como lo hace.

El diagrama de secuencia muestra un determinado escenario de un caso de uso, los eventos generados por actores externos, su orden y los eventos internos del sistema.

A todos los sistemas se les trata como una caja negra, y se centran en los eventos que van de los actores a los sistemas.


Tipos De Diagrama De Secuencia

Existen dos tipos de diagrama de secuencia:

· Diagramas de secuencia basados en código se pueden generar a partir del código de programa .NET,

y se pueden colocar dentro de cualquier proyecto.

· Los diagramas de secuencia UML forman parte de un modelo UML y sólo existe dentro de los proyectos de

modelado UML.


Tipos De Mensajes


Los 4 pasos a seguir para dibujar un Diagrama de

Secuencia

• Copia el texto de la especificación de tu caso de uso y pégalo en la parte superior de tu diagrama de secuencia. Con esto siempre se tendrá en cuenta que es lo que debe de hacer el diagrama de secuencia.

Paso 1:

• Cada uno de los objetos entidad de tu diagrama de robustez es una instancia de la clase que debe de ser agregada a tu diagrama de secuencias ya que representa tu modelo estático. Hay que ser muy meticuloso con este paso, ya que representa el ultimo de tu modelo estático antes de codificar.

Paso 2:


Los 4 pasos a seguir para dibujar un Diagrama de

Secuencia

• Agrega las interfaces del diagrama de robustez. Con esto ya tenemos el diagrama de secuencias construido. Ahora, el cuarto paso es para decidir cuales métodos irían en cuales clases, lo cual es la esencia del modelo de iteraciones.

Paso 3:

• Pon los métodos en las clases, lo cual significa convertir los controles uno por uno de tu diagrama de robustez en métodos y mensajes. Verifica que para cada control dibujado le pertenecen los mensajes correctos dentro del diagrama de secuencias

Paso 4:


Elemento del diagrama de secuencia

Línea de vida Actor Mensaje

sincrónico Mensaje

asincrónico

Incidencia de ejecución

Mensaje de devolución de

llamado Auto mensaje

Crear mensajes.

Mensaje encontrado

Mensaje perdido

Comentarios Uso de

interacción

Fragmento combinado

Protección de fragmentos

Interacción


Elemento del diagrama de secuencia


Ventajas y Desventajas

• Da la posibilidad de representar los mensajes en función del tiempo.

• La separación de los mensajes no indica intervalos o cantidades de tiempo, solo ordenación temporal.

• Es posible añadir restricciones temporales.

Ventajas:

• Una representación de un diagrama de secuencia demasiado largo, puede ser difícilmente entendido por alguien ajeno al Sistema.

Desventajas:


Ejemplos: El sencillo y mas común que se usa ya que es directo


Un buen diagrama de secuencia debe dejar claro cuáles son los objetos involucrados, cómo colaboran dichos objetos para realizar el caso de uso, y qué objetos se crean durante el caso de uso y cuáles existían previamente.

No es necesario indicar el algoritmo para validar el número de una credencial o la sintaxis de una dirección de email, eso le corresponde al programador, pero si es imprescindible indicar qué objeto es el responsable de validar y además a qué clase pertenece


Diagramas de Estado


Es una técnica para describir el comportamiento de un sistema.

Consiste en describir, todos los estados posibles en los que puede entrar un objeto particular y la manera en que cambia el estado del objeto, como resultado de los eventos que lleguen a él.

Su objetivo es mostrar los diferentes estados de un objeto durante su vida, y los estímulos que provocan los cambios de estado en un objeto.

Representa un resumen de los valores y atributos que puede tener la clase.

EL DIAGRAMA DE ESTADOS


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.


Los diagramas de estado

constituyen una de las

herramientas más importantes

para el Modelado de análisis de la

Iweb

Describe un periodo de

tiempo para la vida de un objeto

de una clase


¿Qué son los Estados?

Son los ladrillos de los diagramas de estado

Pertenece a una clase y representa un resumen de los valores y atributos que puede tener la clase

Un estado UML describe el estado interno de un objeto de una clase particular


Un estado

Puede ser caracterizado de tres maneras complementarias:

• Como un conjunto de valores de objeto cualitativamente similares en cierta forma

• Como período de tiempo, durante el cual un objeto espera que ocurra algún evento o eventos

• Como período de tiempo, durante el cual un objeto realiza una cierta actividad

Un estado puede tener un nombre, aunque a menudo es anónimo y viene descrito simplemente por sus acciones


Representación de un Estado

Un estado se muestra como un rectángulo con las

puntas redondeadas


TIPOS DE ESTADO ESPECIALES:

INICIO FIN

Son especiales en el sentido de que no hay ningún evento que pueda devolver a un objeto a su estado inicio y de la misma forma no hay ningún evento que pueda sacar a un objeto de su estado fin.


• acontecimiento importante o digno de señalar. Ejemplo: levantar el auricular telefónico.

Evento:

• condición de un objeto en un momento determinado. Ejemplo: un teléfono se encuentra en estado “ocioso” una vez que el auricular es puesto en su sitio y mientras no lo levantemos.

Estado:

• relación entre dos estados, indica que, cuando ocurre un evento, el objeto pasa del estado anterior al siguiente. Ejemplo: cuando ocurre el evento “levantar el auricular”, el teléfono realiza la transición del estado “ocioso” al estado “activo”.

Transición:

CONCEPTOS IMPORTANTES


Un estado puede contener los siguientes elementos:

Transición externa

Evento disparador

Condición de guarda

Transición de finalización

Acción Cambio de

estado

Estados anidados

Acciones de entrada salida

Transición interna


Transiciones de estado

Un conjunto de estados está conectado mediante

transiciones.

Aunque las transiciones

conectan dos estados (o más, si hay una división o unión de

control), las transiciones son

procesadas por el estado del que salen.

Cuando un objeto está en un estado, es

sensible a los eventos correspondientes a las transiciones que salen

del estado.


Las transiciones

Una transición que deja un estado define la respuesta de un objeto en ese estado a la ocurrencia de un evento.

En general, una transición tiene:

• un evento que la activa (evento disparador)

• una condición de guarda

• una acción y un estado destino.

La siguiente tabla muestra los tipos de las transiciones y de las acciones implícitas invocadas por transiciones


Transición externa

Una transición externa es una transición que cambia el estado activo.

Éste es el tipo más común de transición.

Se dibuja como una flecha dessde el estao origen al estado destino, con otras propiedades mostradas como una cadena de texto asociada a la flecha


Representación de una transición

Estado 1 Estado 2

transición

La transición se representa con una flecha etiquetada por una acción o evento disparador


Evento disparador

El disparador es un evento cuya

ocurrencia permite la transición

El evento puede tener parámetros,

que estarán disponibles para una acción en la

transición

Si una señal tiene descendientes,

cualquier descendiente de

la señal permite la transición


Ejemplo de Transiciones externas

con evento disparador


Condición de guarda

Una transición puede tener una condición de guarda, que es una expresión booleana

Puede referirse a los atributos del objeto que posee la máquina de estados, así como a los parámetros del evento disparador.

Se evalúa la condición de guarda cuando ocurre un evento disparador

Si la expresión se evalúa como verdadera, entonces se dispara la transición, es decir, ocurren sus efectos

Si la expresión se evalúa como falsa, entonces la transición no se dispara


La condición de guarda…

Cuando ocurre el evento disparador.

Se evalúa solamente

una vez: • Si la condición es falsa y llega a ser más adelante

verdad, es demasiado tarde para disparar la transición.


Transición de finalización

Una transición que carece de evento disparador explícito es accionada por la terminación de la actividad del estado del

que sale (esto es una transición de terminación)

Una transición de terminación puede tener una condición de guarda, que se evalúa en el momento en

que termina la actividad en ese estado (y no después)


Acción

Cuando se dispara una transición, su acción (si la hay), es ejecutada.

Una acción es un cómputo atómico y normalmente breve, a menudo una declaración de asignación o un cómputo aritmético

simple.

Otras acciones incluyen enviar una señal a otro objeto, llamar a una operación, fijar los valores de retorno, crear o destruir un objeto y

las acciones indefinidas de control especificadas en un lenguaje externo.

Una acción puede ser también una secuencia de acciones, es decir, una lista de acciones simples.


Tipos de acciones


Cambio de estado

Cuando se completa la ejecución de una

acción, el estado destino de la

transición pasa a ser el estado activo.

Esto puede activar acciones de salida y acciones de entrada.


Estados anidados

Los estados se pueden anidar dentro de otros estados compuestos.

Una transición que deja el estado más externo es aplicable a todos los estados anidados sobre él.

La transición es elegible para ser disparado siempre que cualquier estado anidado esté activo.

Los estados compuestos son útiles para expresar condiciones de excepción y de error, porque las transiciones en ellos se aplican a todos los estados anidados sin necesidad de que cada estado anidado maneje la excepción explícitamente.


Acciones de entrada salida

Una transición a través de uno o más niveles de anidamiento puede salir y entrar en estados.

Un estado puede tener acciones que se realicen siempre que se entre o se salga del estado.

Entrando al estado destino, se ejecuta una acción de entrada unida al estado.

Si la transición sale del estado original, entonces su acción de salida se ejecuta antes de la acción, de la transición y de la acción de entrada en el nuevo estado.


Transiciones internas y acciones de entrada salida


Transición interna

Una transición interna tiene un estado origen pero ningún estado destino.

Las reglas de disparo para una transición interna son iguales que para una transición que cambie el estado.

Una transición interna no tiene ningún estado destino, así que el estado activo no cambia como resultado de su activación.

Si una transición interna tiene un acción, se ejecuta, pero no ocurre ningún cambio de estado, y por lo tanto no se ejecuta ninguna acción de las acciones de salida o de entrada.


Las transiciones internas…

Son útiles para modelar las acciones de interrupción que no

cambian el estado

• (como recuento de ocurrencias de un evento o desplegar una pantalla de ayuda)

Las acciones de entrada y de salida utilizan la misma notación

que las transiciones internas, pero usan las palabras reservadas entry

y exit (entrada y salida)

• en lugar del nombre del evento disparado, aunque estas acciones son activadas por las transiciones externas que entra o salen del estado.


NOTACION: COMPOSICION DE UN DIAGRAMA


PASOS QUE SE SIGUEN EN LA CONSTRUCCION

2. Dibujar el diagrama de estados

1. Identifique todos los sucesos y estados para esto se debe analizar el caso de uso u

otra herramienta con la que este trabajando


2. dibujar el diagrama de estados

Considerar las necesidades de la aplicación de los Sucesos y Estados

Distinguir entre actividades y

acciones

Considerar sólo los atributos

relevantes.

Poner acciones de entrada cuando todas las

transiciones entrantes generen la misma acción. Igual para las de Salida.

Intentar mantener los Diagramas de estados de

las subclases independientes de los de

las superclases.

Utilizar Estados anidados cuando las mismas

transiciones se apliquen a varios Estados.

Respetar notación inicial y final (círculos), rectángulos, flechas de

transición y las expresiones (Nombre De

Evento[ExpresiónGuarda]/acción)


EJEMPLO DIAGRAMA DE ESTADOS: PEDIDOS


DIAGRAMA DE ESTADOS SIN SUPERESTADOS


DIAGRAMA DE ESTADOS CON SUPERESTADOS


DIAGRAMA DE ESTADOS CONCURRENTES: AUTORIZACION DE PAGOS


DIAGRAMA DE ESTADOS CONCURRENTES


Los diagramas de estado describen gráficamente los eventos y los

estados de los objetos.

No nos debemos plantear el diseñar diagramas de estados para todas las clases en el sistema, sino sólo para aquellas que exhiban un

comportamiento interesante de forma que la elaboración del

diagrama de estados nos ayude a entender dicho comportamiento.


Los diagramas de estado son una técnica que nos sirve para

describir el comportamiento de un sistema,

describiendo todos los estados posibles en los que puede entrar un objeto particular y la manera

en que cambia el estado del objeto, como resultado de los

eventos que lleguen a él.

¿ PARA QUE NOS SIRVEN LOS DIAGRAMAS DE ESTADO?


La mas popular que se emplea en las técnicas de OO se basa en La Tabla de

Estados de DAVID HAREL

EXISTEN MUCHAS FORMAS DE DIAGRAMAS DE ESTADOS. ¿CUAL ES LA TECNICA MAS POPULAR Y DE QUIEN?


La sintaxis de una etiqueta de transición tiene tres partes, las cuales son optativas:

Evento [Guard Guardia] / Acción

¿ CUAL ES LA SINTAXIS DE LA ETIQUETA DE TRANSICION ?


Los diagramas de Estados Concurrentes son útiles cuando un

objeto dado tiene conjuntos de

comportamientos independientes

¿CUANDO SON UTILES LOS DIAGRAMAS DE ESTADOS CONCURRENTES?


Debemos utilizar Estados

anidados

cuando las mismas transiciones se apliquen a varios Estados.

¿CUANDO DEBEMOS UTILIZAR ESTADOS ANIDADOS?


Estados compuestos


Estados compuestos

Un estado simple no tiene ninguna

estructura, apenas tiene un conjunto de transiciones y

posiblemente acciones de

entrada y salida.

Un estado compuesto es un estado que se ha descompuesto en

subestados secuenciales o

subestados concurrentes


Ejemplo de máquina de estados


Ejemplo máquina de estados con un estado compuesto concurrente


Ejemplo submáquina de estados


Sugerencia: para crear los diagramas UML utilice el Microsoft Visio: en Software y Base de datos – Diagrama de Modelo UML


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.


Puesto que las herramientas de desarrollo de la WebApp son abundantes y funcionalmente poderosas, es mejor crear prototipos de la interfaz mediante tales herramientas.


Las 7Cs de la interfaz del cliente

Context

Diseño del Sitio.

Commerce

Capacidad del sitio de habilitar

transacciones comerciales.

Connection

Grado en el que el sitio está

ligado con otros sitios.

Communication

The ways sites enable site-to-

user communication or two-way

communication

Customization

Site’s ability to self-tailor to

different users or to allow users

to personalize the site

Community

Maneras en que el sitio habilita

la comunicación de usuario-

usuario.

Content

Texto, Fotografías, sonido y

video que el sitio contiene.


En microsoft Visio puede utilizar el diagrama reticular para elaborar el prototipo de interfaz


El modelo funcional


El modelo funcional

Este modelo funcional aborda dos elementos de

procesamiento de la WebApp y cada uno representa un

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


La funcionalidad observable para el usuario comprende cualesquiera funciones de procesamiento que éste indicia directamente.

Por ejemplo, un sitio Web financiero puede implementar una variedad de funciones financieras.


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



Si las WebApp deben tener acceso a una gran base de

datos o ínter operar con las aplicaciones corporativas existentes en el lado del

servidor,

se deben especificar las interfaces apropiadas, los

protocolos de comunicación y la información.


Las WebApp deben someterse a una amplia prueba de cada configuración de

navegador que se especifique como parte del modelo de configuración.


Análisis relación – navegación


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.


Análisis de Relaciones

• Identifica las diversas categoría de usuario y establece una apropiada jerarquía de participantes

Análisis de los participantes:

• Identifica los objetos de contenido y los elementos funcionales de interés para los usuarios finales

Análisis de elementos:


• Describe las relaciones entre los elementos WebApp Análisis de

relaciones:

• Examina como los usuarios pueden acceder a elementos individuales o grupos de elementos

Análisis de navegación:

• Considera temas pragmáticos (por ejemplo :costo/beneficioes) asociados con la implementación de las relaciones definidas con anterioridad

Análisis de evaluación:


Análisis de relaciones: preguntas claves

En este análisis se formulan una serie

de preguntas que nos ayudará a

comprender mas la relación.


Preguntas clave

¿el elemento es miembro de una categoría de elementos más amplia?

¿Qué atributos o parámetros se han identificado para el elemento?

¿Ya existe información descriptiva acerca del elemento? Si es así, ¿Dónde está?

¿El elemento aparece en diferentes ubicaciones dentro de la WebApp? Si es así ¿dónde?

¿El elemento lo componen otros pequeños elementos? Si es así, ¿cuáles son?

¿El elemento es miembro de una colección de elementos mayor? Si es así, ¿cuál es y cuál es su esctructura?


¿al elemento lo describe una clase de análisis?

¿Otros elementos son similares al elemento considerado? Si es así, ¿es posible que pudieran combinarse en un elemento?

¿El elemento se usa en un ordenamiento específico de otros elementos? ¿su aparición depende de otros elementos?

¿Otro elemento siempre sigue a la aparición del elemento considerado?

¿Qué condiciones previas y posteriores se deben satisfacer para utilizar el elemento?


¿Categorías de usuario específicas aprovecha al elemento? ¿Las diferentes categorías de usuario emplean de manera diferente al elemento? Si es así, ¿cómo?

¿El elemento puede esta asociado con una meta u objetivo de formulación específico? ¿con un requisito WebApp específico?

¿Este elemento siempre aparece al mismo tiempo que aparecen otros elementos? Así es, ¿Cuáles son los otros elementos?

¿Existen elementos siempre aparece ene l mismo lugar (por ejemplo, misma ubicación de la pantalla o página que otros elementos? Si es así ¿cuáles son los otros elementos?


Las respuesta a éstas preguntas….

Ayudan al ingeniero Web a posicionar el elemento en cuestión dentro de la WebApp y a establecer relaciones entre elementos.

Es posible desarrollar una relación taxonómica y categorizar cada relación identificada debido a las preguntas anotadas.


Análisis de navegación

Uno de los aspectos más importantes en los sistemas de información en las WebApp es el de la navegació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.


Las siguientes preguntas se deben plantear y responder:

¿ciertos elementos deben ser más fáciles de alcanzar (es decir, requieren menos pasos de navegación) que otros? ¿Cuál es la prioridad de presentación?

¿Ciertos elementos deben resaltarse para forzar a los usuarios a navegar en su dirección?

¿cómo se manejan los errores de navegación?

¿La navegación hacia grupos de elementos relacionados debe ser prioritaria sobre la navegación hacia un elemento específico?


¿La navegación se debe lograr por medio de vínculos, de acceso basado en búsqueda o por otros medios?

¿ciertos elementos se deben presentar a los usuarios con base en el contexto de acciones de navegación previa?

¿El acceso a la navegación debe mantenerse para los usuarios?

¿En cada punto de la interacción del usuario debe estar disponible un mapa o menú de navegación completo ?


¿para qué categoría de usuarios se debe diseñar una navegación óptima?

¿cómo se manejarán los vínculos externos a la WebApp? ¿superponiendo la ventana de navegador existente? ¿cómo una nueva ventana de navegador? ¿cómo un marco separado?


El equipo de ingeniería web y sus participantes…

Deben determinar los requisitos globales para la navegación.

Por ejemplo

• ¿se proporcionará un “mapa del sitio” para brindar a los usuarios un panorama integral de la estructura de la WebApp?

• ¿El usuario puede realizar un “recorrido” que subraye los elementos más importantes (objetos de contenido y funciones) disponibles?

• ¿un usuario tendrá la capacidad de acceder a los objetos de contenido o funciones con base en los atributos definidos de dichos elementos, un usuario talvez desee acceder a todas las fotografías de una construcción específica o a todas las funciones que permitan el cálculo del peso?


Sugerencia para este punto:

Para el análisis de navegación se puede utilizar el diagrama: sitio web conceptual disponible en Microsoft Visio, aunque se sugiere hacerlo con detalle en la fase de diseño IWebb


Bibliografía utilizada

PRESSMAN, ROGER, Ingeniería de Sottware, 6ta ed. Mc. Graw Hill.

RUMBAUGH, JACOBSON, BOOCH, El lenguaje unificado de Modelado. Manual de Referencia. Addison Wesley

Fase 2 modelado del análisis de i web

Education

Transcript of Fase 2 modelado del análisis de i web