Fase 2 modelado del análisis de i web

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

INGENIERIA WEB
Modelado del Análisis de IWeb

MTI. ROSA IMELDA GARCIA CHI


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

El análisis de
requisitos •Formulación
para las •Recopilación
WebApp de requisitos
abarca tres •Modelado
grandes de análisis
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

En el contexto de la
ingeniería Web, el caso
Los casos de uso
de uso en si mismo es
relativamente informal:

un párrafo narrativo
se desarrollan para
que describe una
cada categoría de
interacción especifica
usuario descrita en la
entre el usuario y la
jerarquía de usuario.
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 que casos de uso
que los casos de uso
sumen nuevos casos específicos puedan
existentes sean
de uso a los paquetes reubicarse en
refinados y
que se han definido paquetes diferentes


Ejemplo de un diagrama de casos de uso
sistema

actor

Relación

Caso de uso

No es una
persona es otro
sistema

El modelado de análisis para WebApps


El modelado de análisis para WebApps
Se basa en la información que contienen los casos de uso
desarrollados para la aplicación.

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

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.


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

• Identifica todo el espectro del contenido que
Análisis de ofrecerá la WebApp.
contenido: • El contenido incluye texto, gráficas e
imágenes, así como datos de video y audio.

Análisis de • Describe cómo interactúa el usuario con la
interacción: WebApp

• Define las operaciones que se aplicarán al
contenido de la WebApp
Análisis de
funciones: • Describe otras funciones de procesamiento,
independientes del contenido pero
necesarias para el usuario final

Análisis de • Describe el ambiente y la infraestructura en
configuración: 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 Además incluye todas las clases de
elementos estructurales que análisis: entidades visibles para el
proporcionan una importante visión usuario que se crean o manipulan
de los requisitos de contenido para conforme éste interactúa con la
una WebApp. 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

Los objetos de
contenido se • al examinar la descripción del
escenario para referencias
extraen en los directas e indirectas al contenido.
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
Nombre de la clase
atributos
Operación disponible en la clase

asociación Nombres de rol

generalización

restricción multiplicidades

calificador

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


Un diagrama de actividades muestra un flujo de
acciones

(nodos ejecutan un proceso),

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


¿Para qué sirve?

Capturar las
acciones internas
de un proceso.

Mostrar flujos Capturar la
entre procesos del especificación de
negocio. un caso de uso.


Elementos que componen un diagrama de actividad


Ejemplo de diagrama de actividad:
Realizar consignación


Explicación 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.


Otros elementos


Particiones, calles o carriles

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


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


¿De donde se obtiene la información ?

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

Diagrama de actividad


Diagrama de actividad con calles


El diagrama de Actividad

En el Lenguaje de Modelado
Unificado, un diagrama de actividades
Un Diagrama de Actividades muestra
representa los flujos de trabajo paso a
el flujo de control general.
paso de negocio y operacionales de
los componentes en un sistema.


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
Paso 1: de secuencia. Con esto siempre se tendrá en
cuenta que es lo que debe de hacer el diagrama
de secuencia.

• 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
Paso 2: 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.


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
Paso 3: 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.

• 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.
Paso 4: Verifica que para cada control dibujado le
pertenecen los mensajes correctos dentro del
diagrama de secuencias


Elemento del diagrama de secuencia

Mensaje Mensaje
Línea de vida Actor
sincrónico asincrónico

Mensaje de
Incidencia de Crear
devolución de Auto mensaje
ejecución mensajes.
llamado

Mensaje Mensaje Uso de
Comentarios
encontrado perdido interacción

Fragmento Protección de
Interacción
combinado fragmentos


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
Ventajas: intervalos o cantidades de tiempo, solo
ordenación temporal.
• Es posible añadir restricciones temporales.

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


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


EL DIAGRAMA DE ESTADOS

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.


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

Describe un
para el
periodo de
Modelado de
tiempo para la
análisis de la
vida de un objeto
Iweb
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:

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.

INICIO FIN


CONCEPTOS IMPORTANTES

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

• condición de un objeto en un momento

Estado: 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.

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


Un estado puede contener los siguientes elementos:
Transición
externa
Transición Evento
interna disparador

Acciones de Condición de
entrada salida guarda

Estados Transición de
anidados finalización

Cambio de
Acción
estado

Transiciones de estado
Cuando un objeto está
en un estado, es
Aunque las sensible a los eventos
transiciones correspondientes a las
conectan dos estados transiciones que salen
(o más, si hay una Un conjunto de del estado.
división o unión de
control), las estados está
transiciones son
procesadas por el
conectado
estado del que salen. mediante
transiciones.


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

transición

Estado 1 Estado 2

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

Si una señal tiene El evento puede
descendientes, tener parámetros,
cualquier que estarán
descendiente de disponibles para
la señal permite la una acción en la
transición 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…

Se evalúa
solamente
una vez: Cuando ocurre el evento disparador.
• 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 Una transición de
evento disparador explícito es terminación puede tener una
accionada por la terminación condición de guarda, que se
de la actividad del estado del evalúa en el momento en
que sale (esto es una que termina la actividad en
transición de terminación) 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
Esto puede activar
acción, el estado
acciones de salida y
destino de la
acciones de entrada.
transición pasa a ser
el estado activo.


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…
Las acciones de entrada y de
Son útiles para modelar las salida utilizan la misma notación
acciones de interrupción que no que las transiciones internas, pero
cambian el estado usan las palabras reservadas entry
y exit (entrada y salida)

• (como recuento de • en lugar del nombre del
ocurrencias de un evento disparado, aunque
estas acciones son
evento o desplegar activadas por las
una pantalla de transiciones externas que
ayuda) entra o salen del estado.


NOTACION: COMPOSICION DE UN DIAGRAMA


PASOS QUE SE SIGUEN EN LA CONSTRUCCION

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


2. dibujar el diagrama de estados

Considerar las Distinguir entre Considerar sólo los
necesidades de la
aplicación de los
actividades y atributos
Sucesos y Estados acciones relevantes.

Intentar mantener los Poner acciones de
Utilizar Estados anidados
Diagramas de estados de entrada cuando todas las
cuando las mismas
las subclases transiciones entrantes
transiciones se apliquen
independientes de los de generen la misma acción.
a varios Estados.
las superclases. Igual para las de Salida.

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.


¿ PARA QUE NOS SIRVEN LOS DIAGRAMAS DE ESTADO?

describiendo todos los estados
Los diagramas de estado son posibles en los que puede entrar
una técnica que nos sirve para un objeto particular y la manera
describir el comportamiento de en que cambia el estado del
un sistema, objeto, como resultado de los
eventos que lleguen a él.


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

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


¿ CUAL ES LA SINTAXIS DE LA
ETIQUETA DE TRANSICION ?

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

Evento [Guard Guardia] / Acción


¿CUANDO SON UTILES LOS DIAGRAMAS
DE ESTADOS CONCURRENTES?

Los diagramas de
Estados Concurrentes
son útiles cuando un
objeto dado tiene
conjuntos de
comportamientos
independientes


¿CUANDO DEBEMOS UTILIZAR ESTADOS
ANIDADOS?

Debemos cuando las
utilizar mismas
transiciones se
Estados apliquen a varios
Estados.
anidados


Estados compuestos


Estados compuestos

Un estado simple Un estado
no tiene ninguna compuesto es un
estructura, apenas estado que se ha
tiene un conjunto descompuesto en
de transiciones y subestados
posiblemente secuenciales o
acciones de subestados
entrada y salida. 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 Content

Diseño del Sitio. Texto, Fotografías, sonido y
video que el sitio contiene.

Commerce Community

Capacidad del sitio de habilitar Maneras en que el sitio habilita
transacciones comerciales. la comunicación de usuario-
usuario.

Connection Customization

Grado en el que el sitio está Site’s ability to self-tailor to
ligado con otros sitios. different users or to allow users
to personalize the site

Communication

The ways sites enable site-to-
user communication or two-way
communication

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


El modelo funcional


El modelo funcional

Funcionalidad observable
respecto al usuario y que
Este modelo funcional aborda entrega al usuario final de
dos elementos de WebApp.
procesamiento de la WebApp
y cada uno representa un
grafico diferente de la Las operaciones dentro de las
abstracción de clases de análisis que
procedimiento: 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 se deben especificar las
datos o ínter operar con las interfaces apropiadas, los
aplicaciones corporativas protocolos de comunicación
existentes en el lado del y la información.
servidor,


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 Análisis de los Análisis de
participantes elementos relaciones

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


Análisis de Relaciones
• Identifica las diversas
Análisis de los categoría de usuario y
participantes: establece una apropiada
jerarquía de participantes

• Identifica los objetos de
Análisis de contenido y los elementos
elementos: funcionales de interés
para los usuarios finales


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

relaciones:

• Examina como los usuarios pueden
Análisis de acceder a elementos individuales o
grupos de elementos
navegación:

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


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

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (20)

Similar a Fase 2 modelado del análisis de i web

Similar a Fase 2 modelado del análisis de i web (20)

Más de ROSA IMELDA GARCIA CHI

Más de ROSA IMELDA GARCIA CHI (20)

Último

Último (20)

Fase 2 modelado del análisis de i web