Los modelos de comportamiento se utilizan para describir el
comportamiento del sistema en su totalidad. Entre los modelos de comportamiento
existentes se distinguen dos de estos:
Modelo de flujo de datos:
Modelan el procesamiento de datos en el sistema
Modelo de máquinas de estado:
Modelan como el sistema reacciona a estos eventos
Estos modelos pueden usarse de forma separada o
conjuntamente, dependiendo del tipo de sistema que se esté desarrollando.
La mayoría de los sistemas de negocio están fundamentalmente
dirigidos por los datos. Están controlados por las entradas de datos al sistema
con relativamente poco procesamiento de eventos externos.
Un
modelo de flujo de datos puede ser todo lo que se necesite para representar el
comportamiento de estos sistemas. Por el contrario, los sistemas de tiempo real
a menudo están dirigidos por eventos con un mínimo procesamiento de datos.
Modelado dirigido por datos:
Los modelos dirigidos por datos muestran la secuencia de
acciones involucradas en el procesamiento de datos de entrada, así como la
generación de una salida asociada.
Son particularmente útiles durante el análisis de
requerimientos, pues sirven para mostrar procesamiento “extremo a extremo” en
un sistema. Esto es, exhiben toda la secuencia de acciones que ocurren desde
una entrada a procesar hasta la salida correspondiente, que es la respuesta del
sistema.
Modelado dirigido por un evento:
Muestra cómo responde un sistema a eventos externos e
internos. Se basa en la suposición de que un sistema tiene un número finito de
estados y que los eventos (estímulos) pueden causar una transición de un estado
a otro. Por ejemplo, un sistema que controla una válvula puede moverse de un
estado de “válvula abierta” a un estado de “válvula cerrada”, cuando recibe un
comando operador (el estímulo).
CREACIÓN DE UN MODELO DE COMPORTAMIENTO
Para generar un modelo deben seguirse los siguientes pasos:
Evaluar todos los casos de uso para entender por completo la
secuencia de interacción dentro del sistema
Identificar los eventos que conducen la secuencia de
interacción y que entienden el modo en el que estos se relacionan con objetos
específicos
Crear una secuencia para cada caso de uso
Construir un diagrama de estado para el sistema
Revisar el modelo de comportamiento para verificar la
exactitud y la consistencia
En las siguientes secciones se estudian los siguientes pasos:
Identificar los eventos con el caso de uso:
Un evento ocurre siempre que el sistema y un actor
intercambian información. Un caso de uso se estudia para efectos del
intercambio de información.
Representaciones de estado:
En el contexto del modelado del comportamiento deben
considerarse dos caracterizaciones diferentes de los estados
1 ) El estado de cada clase cuando el sistema
ejecuta su función
2)
El estado del sistema según se observa desde el
exterior cuando realiza su función
El estado de una clase tiene características tanto pasivas
como activas, un estado pasivo es sencillamente el estado actual de todos los
atributos de un objeto
El estado activo de un objeto indica el estado actual del
objeto conforme pasa por una transformación o procesamiento continuos
Diagrama de secuencia:
Indica la forma en que los eventos provocan transiciones de
un objeto a otro.
Una vez identificados los objetos por medio del análisis del
caso de uso, el modelador crea un diagrama de secuencia: representación del
modo en el que los eventos causan el flujo de uno a otro como función del
tiempo. En esencia el diagrama de secuencia es una versión taquigráfica del
caso de uso
Diagramas de estado para clases de análisis:
Un componente de modelado de comportamiento es un diagrama
de estado UML que representa estados activos para cada clase y los eventos que
causan cambios en dichos estados activos.
PATRONES PARA EL MODELADO DE REQUERIMIENTOS
Los patrones de software son un mecanismo para capturar
conocimiento del dominio, en forma que permita que vuelva a aplicarse cuando se
encuentre un problema nuevo.
Descubrimientos de patrones de análisis:
El modelado de requerimientos está formado por una amplia
variedad de elementos:
Basados en el escenario (caso de uso)
Orientados a datos (el modelo de datos)
Basados en clases, orientados al flujo y del comportamiento.
Cada uno de estos elementos estudia el problema desde una
perspectiva diferente y da la oportunidad de descubrir patrones que tal vez
suceden en un dominio de aplicación o por analogía en distintos dominios de
aplicación.
Ejemplo de patrón de requerimientos: Actuador-Sensor
Uno de los requerimientos de la función de seguridad de casa
segura es la capacidad de vigilar sensores de seguridad
Por ejemplo
Sensores de frenado, de incendio, de humo o contenido de CO,
de agua etc.
Las extensiones basadas en internet para casasegura
requerirán la capacidad de controlar el movimiento, por ejemplo, apertura,
acercamiento etc. De una cámara de seguridad dentro de una residencia, la
ampliación es que el software de casasegura debe manejar varios sensores y
actuadores como los mecanismos de control de cámara
A continuación, se presenta una versión abreviada del patrón
Actuador-Sensor, desarrollada originalmente para aplicaciones automotrices.
NOMBRE DEL PATRON: Actuador-Sensor
Objetivo: especifica distintas clases de sensores y
actuadores en un sistema incrustado
Motivación: por lo general los sistemas incrustados tienen
varias clases de sensores y actuadores conectados en forma directa o indirecta
con una unidad de control
Restricciones:
Cada sensor debe tener algún método para leer la entrada de
un sensor y los atributos que representan al valor del sensor
Cada sensor activo debe tener capacidades para emitir
mensajes actualizados cuando su valor cambie
Cada sensor activo debe enviar un latido de vida, mensaje de
estado que se emite cada cierto tiempo para detectar fallas
Cada actuador debe tener un método para invocar la respuesta
apropiada determinada por el calculodecomponente
Comportamiento:
la figura muestra un diagrama de secuencia de UML para un
ejemplo de patrón Actuador-Sensor según podría aplicarse la función de casasegura
que controla el posicionamiento de una cámara de seguridad. Aquí el panel de
control consulta un sensor y un actuador para comprobar el estado de operación
con los fines de diagnóstico antes de leer o establecer un valor
Participantes:
Esta sección de la descripción de patrones clasifica las clases u objetos incluidos en
el patrón de requerimientos
A continuación, se presenta una lista abreviada:
Resumen de sensor
pasivo: define una interfaz para los sensores pasivos
Sensor booleano pasivo: define los sensores booleanos
pasivos
Sensor entero pasivo: define los sensores enteros
pasivos
Sensor real pasivo: define los sensores reales
pasivos
Resumen de sensor
activo: define una interfaz para los sensores activos
Sensor booleano activo: define los sensores booleanos
activos
Sensor entero activo: define los sensores enteros
activos
Sensor real activo: define los sensores reales
activos
Resumen de actuador: define
una interfaz para los actuadores
Actuador booleano: define los actuadores booleanos
Actuador entero: define los actuadores enteros
Actuador real: define los actuadores reales
Calculo de componente: parte central del controlador
obtiene los datos de los sensores y calcula la respuesta requerida para los
actuadores
Sensor complejo activo: los sensores complejos
activos tienen la funcionalidad básica de la clase sensor activo pero es
necesario especificar métodos y atributos adicionales más elaborados
Actuador completo: tienen la funcionalidad básica de
la clase abstracta actuador, pero se requiere especificar, pero se requiere
especificar métodos y atributos adicionales más elaborados
Colaboraciones:
Esta sección describe cómo interactúan los objetos y clases
entre sí, y como efectúa cada uno sus responsabilidades
·
Cuando calculodecomponente
necesita actualizar el valor de un sensor pasivo consulta a los sensores y
solicita el valor enviando el mensaje apropiado
·
Los sensores
activos no son consultados. Inician la trasmisión de los valores del sensor
a la unidad de cálculo, con el uso del método apropiado para establecer el
valor en calculodecomponente
·
Cuando
calculodecomponente necesita establecer el valor de un actuador, envía el
valor a este.
·
Calculodecomponente
consulta y establece el estado de operación de los sensores y actuadores
por medio de los métodos apropiados. Si un estado de operación es cero,
entonces se envía el error al manejador de fallas, clase que contiene métodos para
manejar mensajes de error tales como reiniciar un mecanismo más elaborado de
recuperación o un dispositivo de respaldo
Consecuencias:
Las clases sensor y actuador tienen una interfaz
común
Solo puede accederse a los atributos de la clase
atraes de mensajes y la clase decide si se aceptan o no.
La complejidad del sistema es potencialmente
reducida a la uniformidad de las interfaces para los actuadores y sensores.
Modelado de
requerimiento para webapps:
El análisis de los requerimientos lleva tiempo, pero
resolver el problema equivocado toma aun mas tiempo. La pregunta que debe
responder todo desarrollador en web es sencilla
¿estas seguro de que entiendes los requerimientos del
problema? Si la respuesta es si inequívoco, entonces tal vez sea posible omitir
el modelado de los requerimientos pero si la respuesta es no, este debe
llevarse acabo
El grado en el que se profundice en el modelado de los
requerimientos para las webapps depende de los factores siguientes:
Ø
Tamaño y complejidad del incremento de la
webapps
Ø
Numero de particiones
Ø
Tamaño del equipo de la webapp
Ø
Grado en el que los miembros del equipo han
trabajado juntos antes
Ø
Medida en la que el éxito de la organización
depende directamente del éxito de la webapp
Entrada del modelado
de los requerimientos:
El proceso incorpora una actividad de comunicación que
identifica a los participantes y las categorías de usuario, el contexto del
negocio, las metas definidas de información y aplicación, requerimientos generales
de webapps y los escenarios de uso, información que se convierte en la entrada
del modelado de los requerimientos, esta información se presenta en forma de
descripciones hechas en lenguaje natural a grandes rasgos en bosquejos y otras
representaciones no formales.
Pero cierta información faltante si podría influir en el
diseño general y se relaciona mas con la comprensión real de los
requerimientos.
Por ejemplo:
¿Cuál es la resolución del video de salida que dan las
cámaras de casasegura?
¿Qué ocurre si se encuentra una condición de alarma mientras
la cámara está siendo vigilada?
¿Cómo maneja el sistema las cámaras con vistas panorámicas y
de acercamiento?
Ninguna de estas preguntas fue identificada o considerada en
el desarrollo inicial del caso de uso; no obstante, las respuestas podrían tener
un efecto significativo en los diferentes aspectos del diseño
Por tanto, es razonable concluir que, aunque la actividad de
comunicación provea un buen fundamento para entender, el análisis de los
requerimientos mejora este entendimiento al dar una interpretación adicional. Como
la estructura del problema se delinea como parte del modelo de requerimientos,
invariablemente surgen preguntas. Son estas las que llenan los huecos y, en
ciertos casos, en realidad ayudan a encontrarlos
Salida del modelado
de los requerimientos:
El análisis de los requerimientos provee un mecanismo
disciplinado para representar y evaluar el contenido y funcionamiento de las
webapp, los modos de interacción que hallaran los usuarios y el ambiente e
infraestructura en las que reside la webapp.
Cada una de estas características se representa como un
conjunto de modelos que permiten que los requerimientos de la webapp sean
analizados en forma estructurada. Si bien los modelos específicos dependen en
gran medida de la naturaleza de la webapp, hay cinco clases principales de
ellos:
Modelo de contenido:
identifica el espectro completo de contenido que dará la webapp.
Modelo de interacción:
describe la manera en que los usuarios interactúan con la webapp
Modelo funcional:
define las operaciones que se aplicaran al contenido de la webapp y describe
otras funciones de procesamiento que son independientes del contenido pero necesarias
para el usuario final.
Modelo de navegación:
define la estrategia general de navegación para la webapp
Modelo de configuración:
describe el ambiente e infraestructura en la que reside la webapp
Es posible desarrollar cada uno de estos modelos con el
empleo de un esquema de representación llamado con frecuencia “lenguaje” que
permite que su objetivo y estructura se comuniquen y evalúen con facilidad
entre los miembros del equipo de ingeniería de web y otros participantes
Modelo de contenido
de las webapps:
El modelo de contenido incluye elementos estructurales que
dan un punto de vista importante de los requerimientos del contenido de una
webapp. Estos elementos agrupan los objetos del contenido y todas las clases de
análisis, entidades visibles para el usuario que se crean o manipulan cuando
este interactúa con la webapp
Modelo de la interacción
para webapps:
La gran mayoría de webapps permiten una conversación entre
un usuario final y funcionalidad, contenido y comportamiento de la aplicación. Esta
conversación se describe con el uso de un modelo de interaccion que se compone
de uno o mas de los elementos siguientes
1)casos de uso
2)diagramas de secuencia
3)diagramas de estado
4)prototipos de la interfaz de usuario
Modelo funcional para
las webapps:
Muchas webapps proporcionan una amplia variedad de funciones
de computación y manipulación que se asocia directamente con el contenido
(porque lo utilizan o porque lo producen) y es frecuente que sean un objetivo
importante de la interacción entre el usuario y la webapp.
Por esta razón, deben analizarse los requerimientos
funcionales y modelarlos cuando sea necesario
El modelo funcional enfrenta dos elementos de procesamientos
de la webapp, cada uno de los cuales representa un nivel distinto de abstracción
del procedimiento
1)funciones observables por los usuarios que entrega la
webapp a estos
2)las operaciones contenidas en las clases de análisis que
implementan comportamientos asociados con la clase.
Modelos de configuración
para las webapps:
En ciertos casos, el modelo de configuración no es sino una
lista de atributos del lado del servidor y del lado del cliente. Sin embargo,
para webapps más complejas, son varias las dificultades de configuración (por
ejemplo, distribuir la carga entre servidores múltiples, arquitecturas caches,
bases de datos remotas, distintos servidores que atienden a varios objetos en
la misma página web, etc.). Que afectan el análisis y diseño. El diagrama de
despliegue UML se utiliza en situaciones en las que deben considerarse
arquitecturas de configuración compleja.
