Particionamiento de eventos

El método consta de los siguientes pasos.

• 1. Identifique los sistemas externos mediante una lluvia de ideas, elaborando una lista de los " actores " (sistemas externos), que son las fuentes de los eventos externos. Si le resulta útil un gráfico, cree un diagrama de contexto que muestre los actores externos al sistema en estudio y los flujos/señales entre ellos.
• 2. Poniéndose en el lugar de un "actor" (o trabajando con representantes de actores), se debe generar una lista de los " eventos externos " o "desencadenantes" ante los cuales se espera que el sistema tenga una respuesta planificada. (Cabe destacar que el sistema no puede originar eventos externos ; solo un actor puede hacerlo).
• 3. Identifique qué permitirá al sistema detectar los eventos externos:
  • la llegada de uno o más datos ( posiblemente en forma de mensaje)
  • la llegada de uno o más puntos en el tiempo (denominados eventos "temporales" por M&P, y distinguidos por ellos de los eventos externos)
• 4. Identifique la (s) respuesta(s) planificada (s) que el sistema puede ejecutar cuando ocurren los eventos. Son la(s) respuesta(s) o caso(s) de uso los que permitirán al sistema alcanzar sus objetivos.

La técnica fue ampliada con eventos "no-evento" por Paul T. Ward y Stephen J. Mellor en Structured Development for Real-Time Systems: Essential Modeling Techniques . ^{[ 3 ]}

Dado que los terminadores [actores] están, por definición, fuera del alcance del esfuerzo de construcción del sistema representado por el modelo, los implementadores no pueden modificar la tecnología de los terminadores [actores] a su antojo para mejorar su fiabilidad. En cambio, deben incorporar respuestas a los problemas de los terminadores [actores] en el modelo esencial del sistema. Un enfoque útil para modelar las respuestas a los problemas de los terminadores [actores] consiste en crear una lista de eventos "normales" y, a continuación, preguntarse, para cada evento: "¿Debe el sistema responder si este evento no se produce como se espera?". ^{[ 4 ]} [énfasis añadido]

Se puede utilizar la notación de diccionario de datos al estilo Yourdon/DeMarco para describir la composición y la estructura de los datos.

Los elementos de la estructura de datos pueden mapearse a las estructuras de control de la programación estructurada :

• El signo "+" puede corresponder a una "secuencia" de instrucciones (aunque esto no sea necesariamente así).
• "[|]" puede corresponder a "selección" ( condicionales , sentencias switch )
• "{}", "()" puede mapearse a "iteración" ( bucle de conteo , bucle de preprueba , bucle de prueba intermedia, bucle de postprueba y bucle infinito )

Nota: Los elementos definidos pueden ser tanto "materiales" (por ejemplo, llave de la habitación) como "datos" (por ejemplo, fecha y hora de llegada).

La información de evento-respuesta se puede registrar en una tabla. El evento es la razón de ser de la respuesta, lo que proporciona " trazabilidad " desde la respuesta hasta el entorno.

Este enfoque ayuda al analista a descomponer el sistema en minisistemas manejables mediante eventos que requieren una respuesta planificada. El nivel de detalle de cada respuesta corresponde al de los casos de uso primarios . Cada respuesta planificada puede modelarse utilizando la notación DFD o como un caso de uso individual mediante la notación de diagramas de casos de uso.

El flujo básico de un proceso o caso de uso suele describirse en un número relativamente pequeño de pasos, a menudo menos de veinte o treinta, posiblemente utilizando un lenguaje estructurado . Idealmente, todos los pasos deberían ser visibles simultáneamente (generalmente en una página o menos). El objetivo es reducir uno de los riesgos asociados con la memoria a corto plazo : olvidar lo que no se ve de inmediato ("ojos que no ven, corazón que no siente").

Como alternativa, utilizando las notaciones de las técnicas estructuradas, un analista podría crear un diagrama de Nassi-Shneiderman . En UML, el caso de uso podría modelarse mediante un diagrama de actividades , un diagrama de secuencia o un diagrama de comunicación . Esto podría resultar problemático si existen muchos escenarios complejos del caso de uso; el analista podría querer modelar todos o la mayoría de los escenarios.

Si la respuesta es extensa o compleja (es decir, ocupa más de una página), un analista puede descomponerla (o "factorizarla" o eliminar duplicados ) en casos de uso secundarios más pequeños para mantener el caso de uso principal más reducido y sencillo. Estos casos de uso secundarios también pueden resultar reutilizables. (En un diagrama de casos de uso UML , se representarían como casos de uso extendidos o incluidos , relacionados con uno o más casos de uso principales).

Al describir un caso de uso, un analista también puede descubrir " reglas de negocio ". Algunos analistas sugieren capturar las reglas de negocio en un documento aparte utilizando el Lenguaje de Restricciones de Objetos u otra notación formal . Luego, cuando se deba cumplir una regla de negocio en un caso de uso, el analista hace referencia a ella. Esto minimiza la repetición ^{[ 10 ]} dentro de una especificación, pero conlleva el riesgo de fragmentarla. Una técnica que puede reducir esta tensión es usar hipervínculos en el documento de especificación.

Este enfoque reduccionista contrasta en cierto modo con un enfoque de pensamiento sistémico , representado por la metodología de sistemas blandos de Peter Checkland .

Además de los requisitos funcionales recogidos en la descripción de un caso de uso, un analista puede incluir requisitos no funcionales como el tiempo de respuesta, la facilidad de aprendizaje, etc.