Evento de partición

Diagrama de contexto del sistema Hotel ficticio. (Por Convención, los flujos bidireccionales, con flechas en ambos extremos, se suelen utilizar cuando se inicia un diálogo externamente. Por ejemplo, "diálogo de reserva" contiene el flujo de "solicitud de reserva", que es el desencadenante inicial; "la confirmación de reserva", el resultado es enviada de vuelta.)

Evento de partición es un fácil de aplicar Análisis de sistemas técnica que el analista ayuda a organizar requisitos para grandes sistemas en una colección de más pequeños, más simples, mínimamente conectada, más fácil de entender 'mini sistemas' / casos de uso.

Contenido

1 Resumen
2 Temas particionados evento
- 2.1 Evento actor → → detectar → responder
- 2.2 Notación del diccionario de datos
- 2.3 Identificación de requisitos y sus razones
- 2.4 Definición de los requisitos
- 2.5 Complejidad y fragmentación
3 Véase también
4 Referencias
5 Enlaces externos

Resumen

El enfoque de particionado de evento se explica por Stephen M. McMenamin y John F. Palmer en Análisis de los sistemas esenciales.^[1] Una versión breve del enfoque se describe en el artículo sobre Diagramas de flujo de datos. Es una discusión más completa en De Edward Yourdon Suficiente estructura análisis.^[2] La descripción se centra en el uso de la técnica para crear diagramas de flujo de datos, pero puede ser utilizado para identificar casos de uso tan bien.

La premisa del evento particionado es que existen sistemas para responder a eventos externos: identificar lo que ocurre en el ambiente de negocios que requiere respuestas planificadas, a continuación, definir y construir sistemas para responder de acuerdo con las reglas del negocio. En particular, existe un sistema de negocio para dar servicio a las peticiones de los clientes. Un cliente, en la jerga de la Unified Modeling Language (UML), es un 'actor.’

Temas particionados evento

Evento actor → → detectar → responder

El método tiene los siguientes pasos.

1. Identificar los sistemas externos por lluvia de ideas una lista de las 'Actores' (sistemas externos), ¿cuáles son las fuentes de eventos externos. Si encuentras un gráfico para ser útil, crear un Diagrama de contexto mostrando los actores fuera del sistema bajo estudio y las flujos/señales entre ellos.
2. Ponerse en los zapatos tormenta de ideas de un 'actor' (o de trabajo con los representantes del actor), una lista de las 'eventos externos' / 'activa' que quieren el sistema para tener una respuesta planificada a. (Tenga en cuenta que el sistema no puede originar externos eventos; Sólo un actor puede.)
3. Identificar lo que permitirá al sistema detectar los eventos externos:
- la llegada de una o más piezas de datos (posiblemente en la forma de un mensaje)
- la llegada de uno o más puntos en tiempo (llamados "temporal" por M & P y distinguido por ellos de eventos externos)
4. Identificar la planeado respuesta que el sistema puede llevar a cabo cuando se producen los eventos. Es la respuesta / usar casos que permitirán el sistema lograr sus objetivos.

La técnica fue ampliada con eventos 'acontecimiento' por Paul T. Ward y Stephen J. Mellor en Estructura de desarrollo de sistemas en tiempo real: esenciales, técnicas de modelado.^[3]

“

"Puesto que los terminadores [actores] son por definición fuera de los límites de los esfuerzos de construcción de sistema representado por el modelo, los implementadores no pueden modificar la tecnología terminator [actor] en la voluntad de mejorar su fiabilidad. Por el contrario, deben construir respuestas a los problemas de terminator [actor] en el modelo esencial del sistema. Es un enfoque útil para modelar las respuestas a los problemas de terminator [actor] para crear una lista de eventos 'normales' y luego preguntar, para cada evento, "el sistema necesita para responder si este evento es incapaz de ocurren como se esperaba?' ” ^[4] [énfasis añadido]

”

Notación del diccionario de datos

Estilo Yourdon/DeMarco notación del diccionario de datos puede utilizarse para describir la composición y estructura de datos.

Símbolo	Significado
=	'contiene', 'es' o 'se compone de'
+	'y', 'así como', o 'junto con' ()No aritmética 'plus')
m{x}n or ${}_m^n \{ x \}$	' de m Para n iteraciones de x’. If m o n No se especifica, entonces el límite superior o inferior es simplemente 'desconocido' o ''. Matrices multidimensionales pueden especificarse de anidación, por ejemplo, {10 {10 x}} 10 10 define una matriz bidimensional de 10 filas con 10 columnas.
(x)	' opcionalmente x’. Esto equivale a {0}x} 1 o ${}_0^1 \{ x \}$ .
@	Prefijo de número de para un identificador dentro de una iteración. Por ejemplo, en {@i + @j + x} i y j son identificadores.
[x; y; z]	' seleccionar solamente uno de cualquiera x o y o z’. Ya sea un punto y coma (;) o un barra vertical (\|) puede utilizarse para separar los elementos de la lista.
* ... *	Nada entre single asteriscos es considerado como un comentario. En el elemento de datos nivel, un comentario puede contener estas etiquetas tipo como ' gama:', ' límites:', ' precisión:', ' unidad:' o ' valores:'.

NB. Los artículos definidos pueden ser 'material' (por ejemplo, la tecla sala) así como 'datos' (por ejemplo, fecha y hora de llegada).

Identificación de requisitos y sus razones

La información del evento de respuesta puede ser capturada en una tabla. El evento es el razón ' être para la respuesta, que datrazabilidad' de la respuesta hacia el medio ambiente.

1. actor	2. evento externo / activar	3. detectados por	4. respuesta / casos de uso
Comentarios	Huésped solicita una habitación de un determinado tipo, para una fecha de llegada particular, fecha de salida, a una cierta velocidad, etc..	solicitud de reserva + (validación de pago) + (* externo sistema * reserva de confirmación) ^[5]	Reservar habitación (pueden incluir reserva garantizada, reserva de hotel alterno, en lista de espera reserva)
Comentarios	Invitado pide Cancelar reserva de habitación.	solicitud de cancelación ^[6]	Cancelar reserva
Comentarios	Huésped llega al hotel.	mensaje de llegada = ** = [nombre huésped; referencia de reserva] ^[7]	Check-in comentarios
Tiempo / programador	Comentarios es incapaz de llegar al hotel. [Esto es un evento 'acontecimiento'].	23 (hora local) [se detecta un evento 'acontecimiento' por la llegada de un punto en el tiempo, un plazo].	Crear cuenta de invitado, Actualización de reserva
Comentarios	Invitado pide revisar Hotel.	solicitud de salida = ** = [nombre huésped; número de habitación] ^[8]	Crear cuenta de invitado, Actualización Room Occupancy
Tiempo / programador	Comentarios es incapaz de Compruebe hacia fuera del hotel. [Esto es un evento 'acontecimiento'].	11 (hora local) [se detecta un evento 'acontecimiento' por la llegada de un punto en el tiempo, un plazo].	Crear cuenta de invitado
Comentarios	Guest ofrece pago de factura.	vehículo de pago = ** = [efectivo cheque tarjeta de crédito; tarjeta de débito] + (id de invitado) ^[9]	Aceptamos el pago Comentarios
Tiempo / programador	Tiempo para preparar informe de ocupación de habitación la noche anterior.	8 am (hora local)	Informe sobre ocupación de sala
Director del Hotel	Director del Hotel pide informe de ocupación de habitación.	solicitud de informe de ocupación	Informe sobre ocupación de sala
Fumar / alarma de CO	Alarma detecta humo.	mensaje de alarma de humo	Informe de alarma de humo
Fumar / alarma de CO	Alarma detecta CO (monóxido de carbono).	Mensaje de alarma de CO	Informe de alarma de CO

Definición de los requisitos

Proceso único de una empresa ficticia utilizando Diagrama de flujo de datos notación.

Caso de uso individual en una empresa ficticia utilizando Diagrama de casos de uso notación.

Este enfoque ayuda al analista a descomponer el sistema en sistemas mini 'mentalmente bocados' mediante eventos que requieren una respuesta planificada. El nivel de detalle de cada respuesta está en el nivel de ' primaria casos de uso’. Cada respuesta planificada puede ser modelada utilizando la notación DFD o como un caso de uso individual Utilice la notación diagrama de casos.

El flujo básico dentro de un proceso o uso caso generalmente puede ser descrito en un número relativamente pequeño de pasos, a menudo menos de veinte o treinta años, posiblemente usando algo como 'Inglés estructurado’. Idealmente, todos los pasos sería visibles al mismo tiempo (a menudo una página o menos). La intención es reducir uno de los riesgos asociados con memoria a corto plazo, es decir, olvidando lo que no es visible inmediatamente ("fuera de vista, fuera de mente').

Alternativamente, usando las notaciones de técnicas estructuradas, un analista podría crear un 'Diagrama de Nassi-Shneiderman’. En UML, el caso de uso puede ser modelado mediante una Diagrama de actividad, un Diagrama de secuencia, o un Diagrama de comunicación. Esto podría ser problemático si hay muchos complejos escenarios el caso de uso; el analista puede desear modelo todos o la mayoría de los escenarios.

Complejidad y fragmentación

Si la respuesta es muy larga o complejo (es decir, más de una página del texto), un analista puede descomponer ('factor de a' o Desduplique) en pequeños 'secundaria casos de uso' para mantener el 'padre' principal caso más pequeño y sencillo de uso. Estos casos de uso secundario pueden resultar ser reutilizable. (En un UML Diagrama de casos de uso, se elaborará como extendido o incluido casos de uso, que se relacionan con uno o más primaria casos de uso.)

Al describir un caso de uso, un analista también puede destapar 'reglas de negocio’. Algunos analistas sugieren que las reglas del negocio en un documento separado mediante la captura del Object Constraint Language o algún otro notación formal. Entonces cuando una regla de negocio debe ser obedecida en un caso de uso, el analista hace referencia a ella. Esto minimiza la repetición dentro de una especificación, pero la fragmentación de una especificación de riesgos. Una técnica que puede reducir esta tensión es utilizar hipervínculos en el documento de especificación.

Además de requisitos funcionales capturada en una descripción del caso de uso, un analista puede incluir tales requisitos no funcionales como tiempo de reacción, aprendizaje, etc.

Véase también

Caso de negocio
SIPOC
Caso de uso
Diagrama de casos de uso
Historia de usuario

Referencias

^ MCME-84: McMenamin, Stephen M.; John F. Palmer (1984). Análisis de los sistemas esenciales. Prentice-Hall (Yourdon Press). ISBN0-13-287905-0. (ISBN 978-0-13-287905-7)
^ SU-89: "yourdon.com- Suficiente estructura análisisCapítulos 18, 19". 1989.
^ WARD-85: Ward, Paul T.; Stephen J. Mellor (1985). Estructura de desarrollo de sistemas en tiempo real: volumen 2, esenciales, técnicas de modelado. Prentice-Hall (Yourdon Press). ISBN0-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 la reserva
solicitud de reserva = **
= nombre del huésped, tipo de habitación + (facilidades) +
fecha y hora de llegada + fecha y hora de salida
tipo de habitación = * tipo de habitación *
= * valores: [single; doble; familia] *
salas = * valores booleanos que indican la presencia o ausencia de una instalación *
= televisión + radio + climatizador + despertador, acceso a Internet +
teléfono refrigerador mini bar + tocador + lavabo + baño + ducha + bidé
fecha y hora de llegada = **
= fecha y hora
fecha y hora de salida = **
= fecha y hora
fecha y hora = * ISO 8601 formato *
= año + mes + dia del mes + t ' + hora + minutos >
^ 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 + tarjeta de la habitación + cupón de bebida de cortesía
^ diálogo de salida = **
= * entrada * solicitud de salida + * salida * cuenta de invitado
^ diálogo de pago = **
= * entrada * vehículo pago + * salida * recibo comentarios
recibo comentarios = **
= invitado nombre + dirección invitado + {carga detalle} carga total + (impuestos) + cantidad debida + monto pagado

Enlaces externos

Evento de partición Análisis estructurado Wiki

Otras Páginas

[1] MCME-84: McMenamin, Stephen M.; John F. Palmer (1984). Análisis de los sistemas esenciales. Prentice-Hall (Yourdon Press). ISBN0-13-287905-0. (ISBN 978-0-13-287905-7)

[2] SU-89: "yourdon.com- Suficiente estructura análisisCapítulos 18, 19". 1989.

[3] WARD-85: Ward, Paul T.; Stephen J. Mellor (1985). Estructura de desarrollo de sistemas en tiempo real: volumen 2, esenciales, técnicas de modelado. Prentice-Hall (Yourdon Press). ISBN0-13-854787-4. (ISBN 978-0-13-854787-5)

[4] WARD-85, págs. 38-39.

[5] álogo de reserva = **
= * entrada * solicitud de reserva + * salida * confirmación de la reserva
solicitud de reserva = **
= nombre del huésped, tipo de habitación + (facilidades) +
fecha y hora de llegada + fecha y hora de salida
tipo de habitación = * tipo de habitación *
= * valores: [single; doble; familia] *
salas = * valores booleanos que indican la presencia o ausencia de una instalación *
= televisión + radio + climatizador + despertador, acceso a Internet +
teléfono refrigerador mini bar + tocador + lavabo + baño + ducha + bidé
fecha y hora de llegada = **
= fecha y hora
fecha y hora de salida = **
= fecha y hora
fecha y hora = * ISO 8601 formato *
= año + mes + dia del mes + t ' + hora + minutos >

[6] álogo de cancelación = **
= * entrada * solicitud de cancelación + * salida * confirmación de cancelación

[7] álogo de llegada = **
= * entrada * mensaje de llegada + * salida * paquete de llegada
paquete de llegada = **
= llave + tarjeta de la habitación + cupón de bebida de cortesía

[8] álogo de salida = **
= * entrada * solicitud de salida + * salida * cuenta de invitado

[9] álogo de pago = **
= * entrada * vehículo pago + * salida * recibo comentarios
recibo comentarios = **
= invitado nombre + dirección invitado + {carga detalle} carga total + (impuestos) + cantidad debida + monto pagado

﻿Evento de partición

﻿Contenido

﻿Resumen

﻿Temas particionados evento

﻿Evento actor → → detectar → responder

﻿Notación del diccionario de datos

﻿Identificación de requisitos y sus razones

﻿Definición de los requisitos

﻿Complejidad y fragmentación

﻿Véase también

﻿Referencias

﻿Enlaces externos