La partición de eventos es una técnica de análisis de sistemas fácil de aplicar que ayuda al analista a organizar los requisitos para sistemas grandes en una colección de "minisistemas" / casos de uso más pequeños, simples, mínimamente conectados y fáciles de entender .
![](http://wikiimg.tojsiabtv.com/wikipedia/en/thumb/b/bf/ContextDiagram_LastResortHotel.png/360px-ContextDiagram_LastResortHotel.png)
Descripción general
El enfoque de partición de eventos lo explican Stephen M. McMenamin y John F. Palmer en Essential Systems Analysis . [1] Una versión breve del enfoque se describe en el artículo sobre Diagramas de flujo de datos (DFD). Una discusión más completa se encuentra en Just Enough Structured Analysis de Edward Yourdon . [2] La descripción se centra en el uso de la técnica para crear diagramas de flujo de datos, pero también se puede utilizar para identificar casos de uso .
La premisa de la partición de eventos es que existen sistemas para responder a eventos externos: identificar lo que sucede en el entorno empresarial que requiere respuestas planificadas, luego definir y construir sistemas para responder de acuerdo con las reglas del negocio. En particular, existe un sistema comercial para atender las solicitudes de los clientes. Un cliente, en la jerga del lenguaje de modelado unificado (UML), es un " actor ".
Temas de partición de eventos
Actor → Evento → Detectar → Responder
El método tiene los siguientes pasos.
- 1. Identifique los sistemas externos mediante una lluvia de ideas de una lista de los " actores " (sistemas externos), que son las fuentes de eventos externos. Si encuentra que un gráfico es útil, cree un diagrama de contexto que muestre los actores fuera del sistema en estudio y los flujos / señales entre ellos.
- 2. Poniéndose en la piel de un "actor" (o trabajando con representantes de actores), haga una lluvia de ideas de una lista de los " eventos externos " / "desencadenantes" para los que quieren que el sistema tenga una respuesta planificada. (Tenga en cuenta 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 (llamados eventos "temporales" por M&P, y distinguidos por ellos de los eventos externos)
- 4. Identifique las respuestas planificadas que el sistema puede llevar a cabo cuando ocurran los eventos. Son las respuestas / casos de uso los que permitirán que el sistema logre sus objetivos.
Paul T. Ward y Stephen J. Mellor ampliaron la técnica con eventos "sin eventos" en Structured Development for Real-Time Systems: Essential Modelling Techniques . [3]
"Dado que los terminadores [actores] están por definición fuera de los límites del esfuerzo de construcción del sistema representado por el modelo, los implementadores no pueden modificar la tecnología del terminador [actor] a voluntad para mejorar su confiabilidad. En su lugar, deben generar respuestas al terminador [ actor] problemas en el modelo esencial del sistema. Un enfoque útil para modelar las respuestas a los problemas de terminador [actor] es construir una lista de eventos 'normales' y luego preguntar, para cada evento, '¿El sistema necesita responder si este evento no ocurre como se esperaba? ' " [4] [énfasis añadido]
Notación de diccionario de datos
El estilo de notación de diccionario de datos de Yourdon / DeMarco se puede utilizar para describir la composición y estructura de los datos.
Símbolo | Significado |
---|---|
= | "contiene", "es" o "se compone de" |
+ | "y", "así como" o "junto con" ( no "más" aritmético) |
[ x ; y ; z ] | "seleccionar sólo uno de cualquiera de x o y o z ". Se puede utilizar un punto y coma (;) o una barra vertical (|) para separar los elementos de la lista. |
m { x } n o m: n { x } o | "de m a n iteraciones de x ". Si no se especifica m o n , entonces el límite inferior o superior es simplemente "desconocido" o "no especificado". Las matrices multidimensionales se pueden especificar anidando, por ejemplo, 10 {10 {x} 10} 10 define una matriz bidimensional de 10 filas con 10 columnas. |
( x ) | "opcionalmente x ". Esto es equivalente a 0 { x } 1 o 0: 1 { x } o . |
@ | prefijo para un identificador dentro de una iteración. Por ejemplo, en {@ i + @ j + x} i y j son identificadores. |
* ... * | Cualquier cosa entre asteriscos simples se considera un comentario. En el nivel del elemento de datos , un comentario puede contener etiquetas de tipo como "rango:", "límites:", "precisión:", "unidad:" o "valores:". |
Los elementos de la estructura de datos pueden correlacionarse con las estructuras de control de la programación estructurada :
- "+" se puede asignar a una "secuencia" de declaraciones (aunque esto no es necesariamente así)
- "[|]" se puede asignar a "selección" ( condicionales , declaraciones de cambio )
- "{}", "()" se puede asignar a "iteración" ( bucle de conteo , bucle de prueba previa , bucle de prueba intermedio, bucle de prueba posterior y bucle infinito )
NÓTESE BIEN. Los elementos definidos pueden ser "material" (por ejemplo, llave de la habitación) así como "datos" (por ejemplo, fecha y hora de llegada).
Identificación de requisitos y sus razones
La información de respuesta al evento se puede capturar en una tabla. El evento es la razón de ser de la respuesta, que da " trazabilidad " desde la respuesta hasta el medio ambiente.
1. Actor | 2. Evento externo / Disparador | 3. Detectado por | 4. Respuesta (s) / Caso (s) de uso |
---|---|---|---|
Huésped | El huésped solicita una habitación de cierto tipo, para una fecha de llegada, fecha de salida, a una tarifa determinada, etc. | solicitud de reserva + (validación de pago) + (* sistema de reserva externo * confirmación de reserva) [5] | Reservar habitación (puede incluir reserva garantizada, reserva de hotel alternativo, reserva en lista de espera) |
Huésped | El huésped solicita cancelar la reserva de la habitación. | solicitud de cancelación [6] | Cancelar reserva |
Huésped | El huésped llega al hotel. | mensaje de llegada = * * = [nombre del invitado; referencia de reserva] [7] | Registrarse Invitado |
Hora / Programador | El huésped no llega al hotel. [Este es un evento "que no es un evento".] | 11 pm (hora local) [Un evento "que no es un evento" es detectado por la llegada de un punto en el tiempo, una fecha límite.] | Crear factura de invitado, actualizar reserva |
Huésped | El huésped solicita el registro de salida del hotel. | solicitud de salida = * * = [nombre del invitado; número de habitación] [8] | Crear factura de huésped, actualizar la ocupación de la habitación |
Hora / Programador | El huésped no realiza el registro de salida del hotel. [Este es un evento "que no es un evento".] | 11 am (hora local) [Un evento "que no es un evento" es detectado por la llegada de un punto en el tiempo, una fecha límite.] | Crear factura de invitado |
Huésped | Invitado ofrece pago de factura. | vehículo de pago = * * = [efectivo; cheque ; tarjeta de crédito ; tarjeta de débito] + (ID de invitado) [9] | Aceptar pago de invitado |
Hora / Programador | Es hora de preparar el Informe de ocupación de la habitación para la noche anterior. | 8 am (hora local) | Informe sobre ocupación de habitaciones |
Gerente del hotel | El gerente del hotel solicita el informe de ocupación de la habitación. | solicitud de informe de ocupación | Informe sobre ocupación de habitaciones |
Alarma de humo / CO | La alarma detecta humo. | mensaje de alarma de humo | Informar alarma de humo |
Alarma de humo / CO | La alarma detecta CO (monóxido de carbono). | Mensaje de alarma de CO | Informar alarma de CO |
Definición de requisitos
![](http://wikiimg.tojsiabtv.com/wikipedia/en/thumb/4/4e/LastResortHotel_BookRoom_Process.png/240px-LastResortHotel_BookRoom_Process.png)
![](http://wikiimg.tojsiabtv.com/wikipedia/en/thumb/4/47/LastResortHotel_BookRoom_UseCase.png/240px-LastResortHotel_BookRoom_UseCase.png)
Este enfoque ayuda al analista a descomponer el sistema en minisistemas "del tamaño de un bocado mental" utilizando eventos que requieren una respuesta planificada. El nivel de detalle de cada respuesta se encuentra en el nivel de " casos de uso primarios ". Cada respuesta planificada puede modelarse usando la notación DFD o como un caso de uso único usando la notación de diagrama de casos de uso.
El flujo básico dentro de un proceso o caso de uso generalmente se puede describir en un número relativamente pequeño de pasos, a menudo menos de veinte o treinta, posiblemente usando algo como " inglés estructurado ". Idealmente, todos los pasos serían visibles todos a la vez (a menudo una página o menos). La intención es reducir uno de los riesgos asociados con la memoria a corto plazo , a saber, olvidar lo que no es inmediatamente visible ("fuera de la vista, fuera de la mente").
Alternativamente, utilizando las notaciones de técnicas estructuradas, un analista podría crear un " diagrama de Nassi-Shneiderman ". En UML, el caso de uso podría modelarse utilizando un diagrama de actividad , un diagrama de secuencia o un diagrama de comunicación . Esto podría ser problemático si hay muchos escenarios complejos del caso de uso; el analista puede desear modelar todos o la mayoría de los escenarios.
Complejidad versus fragmentación
Si la respuesta es larga o compleja (es decir, más de una página de texto), un analista puede descomponer ("factorizar" o deduplicar ) en "casos de uso secundarios" más pequeños para mantener el caso de uso primario "principal" más pequeño y simple. Estos casos de uso secundario también pueden resultar reutilizables. (En un diagrama de casos de uso de UML , se dibujarían como casos de uso extendidos o incluidos , que están relacionados con uno o más casos de uso principales).
Al describir un caso de uso, un analista también puede descubrir " reglas comerciales ". Algunos analistas sugieren capturar las reglas comerciales en un documento separado utilizando el lenguaje de restricción de objetos o alguna otra notación formal . Luego, cuando se debe obedecer 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 corre el riesgo de fragmentar una especificación. Una técnica que puede reducir esta tensión es utilizar hipervínculos en el documento de especificaciones.
Este reduccionista enfoque radica tanto en contraste con un pensamiento sistémico enfoque, representado por Peter Checkland 's metodología de sistemas blandos .
Además de los requisitos funcionales capturados en la descripción de un caso de uso, un analista puede incluir requisitos no funcionales como tiempo de respuesta, capacidad de aprendizaje, etc.
Ver también
- Caso de negocio
- SIPOC
- Caso de uso
- Use el diagrama del caso
- Historia del usuario
Referencias
- ↑ MCME-84: McMenamin, Stephen M .; John F. Palmer (1984). Análisis de sistemas esenciales . Prentice-Hall (Yourdon Press). ISBN 0-13-287905-0. ( ISBN 978-0-13-287905-7 )
- ^ TU-89: "yourdon.com - Análisis estructurado suficiente , capítulos 18, 19" . 1989. Archivado desde el original el 14 de febrero de 2007 . Consultado el 24 de abril de 2008 .
- ^ WARD-85: Ward, Paul T .; Stephen J. Mellor (1985). Desarrollo estructurado para sistemas en tiempo real: Volumen 2, Técnicas esenciales de modelado . Prentice-Hall (Yourdon Press). ISBN 0-13-854787-4. ( ISBN 978-0-13-854787-5 )
- ^ WARD-85, págs. 38-39.
- ^ diálogo de reserva = * *
= * entrada * solicitud de reserva + * salida * confirmación de
reserva solicitud de reserva = * *
= nombre del huésped + tipo de habitación + (instalaciones de la habitación) +
fecha-hora de llegada+fecha-hora de salida
tipo de habitación = * tipo de dormitorio *
= * valores: [single; doble familia] *
instalaciones de la habitación = * booleanos que indican la presencia o ausencia de una instalación *
= televisión + radio + despertador + control de temperatura + acceso a Internet +
teléfono + nevera + minibar + inodoro + lavabo + bañera + ducha + bidé
fecha de llegada -time = * *
= fecha-hora
salida fecha-hora = * *
= fecha-hora
fecha-hora = *formato ISO 8601 *
= año + mes + día del mes + 'T' + hora + minuto> - ^ diálogo de cancelación = * *
= * entrada * solicitud de cancelación + * salida * confirmación de cancelación - ^ diálogo de llegada = * *
= * entrada * mensaje de llegada + * salida * paquete de
llegada paquete de llegada = * *
= llave de la habitación + tarjeta de la habitación + cupón de bebida de cortesía - ^ diálogo de salida = * *
= * entrada * solicitud de salida + * salida * factura de invitado - ^ diálogo de pago = * *
= * entrada * vehículo de pago + * salida * recibo del invitado recibo del
invitado = * *
= nombre del invitado + dirección del invitado + {detalle del cargo} + total del cargo + (impuestos) + monto adeudado + monto pagado - ^ vea también No se repita , también conocido como "SECO"
enlaces externos
- Wiki de análisis estructurado de particiones de eventos