Разделение событий
Разделение событий — это простой в применении метод системного анализа , который помогает аналитику организовать требования к большим системам в набор более мелких, простых, минимально связанных и понятных «мини-систем»/ сценариев использования .
Обзор
[ редактировать ]Подход к разделению событий объясняется Стивеном М. Макменамином и Джоном Ф. Палмером в книге «Основной системный анализ» . [1] Краткая версия подхода описана в статье о диаграммах потоков данных (DFD). Более полное обсуждение можно найти в книге Эдварда Юрдона « Just Enough Structured Analysis» . [2] В описании основное внимание уделяется использованию этого метода для создания диаграмм потоков данных, но его можно использовать для определения вариантов использования также .
Предпосылка разделения событий заключается в том, что системы существуют для реагирования на внешние события: определите, что происходит в бизнес-среде и требует запланированных ответов, затем определите и создайте системы для реагирования в соответствии с правилами бизнеса. В частности, существует бизнес-система для обслуживания запросов клиентов. На жаргоне унифицированного языка моделирования (UML) клиент — это « действующее лицо ».
Темы разделения событий
[ редактировать ]Актер → Событие → Обнаружить → Реагировать
[ редактировать ]Метод состоит из следующих шагов.
- 1. Определите внешние системы путем мозгового штурма списка « актеров » (внешних систем), которые являются источниками внешних событий. Если вы считаете, что изображение полезно, создайте контекстную диаграмму, показывающую действующих лиц за пределами изучаемой системы и потоки/сигналы между ними.
- 2. Поставив себя на место «актера» (или работая с его представителями), проведите мозговой штурм по списку « внешних событий »/«триггеров», на которые они хотят, чтобы система имела запланированный ответ. (Обратите внимание, что система не может создавать внешние события; это может сделать только актор.)
- 3. Определите, что позволит системе обнаружить внешние события:
- поступление одного или нескольких фрагментов данных (возможно, в форме сообщения)
- наступление одного или нескольких моментов времени (называемых M&P «временными» событиями и отличающихся ими от внешних событий)
- 4. Определите запланированные реакции, которые система может выполнить в случае возникновения событий. Это ответ(ы)/варианты использования, которые позволят системе достичь своих целей.
Этот метод был расширен за счет «несобытийных» событий Полом Т. Уордом и Стивеном Дж. Меллором в книге «Структурная разработка для систем реального времени: основные методы моделирования» . [3]
«Поскольку терминаторы [актеры] по определению находятся за пределами усилий по созданию системы, представленных моделью, разработчики не могут по своему желанию модифицировать технологию терминаторов [актеров] для повышения ее надежности. Вместо этого они должны создавать ответы на терминаторов [актеров]. проблемы субъекта] в сущностную модель системы. Полезный подход к моделированию ответов на проблемы терминатора [актера] состоит в том, чтобы построить список «нормальных» событий, а затем задать для каждого события вопрос: «Нужно ли системе реагировать, если». это событие не происходит так, как ожидалось?' " [4] [курсив добавлен]
Обозначение словаря данных
[ редактировать ]в стиле Юрдона/ДеМарко Обозначение словаря данных может использоваться для описания состава и структуры данных.
| Символ | Значение |
|---|---|
| = | «содержит», «есть» или «состоит из» |
| + | «и», «а также» или «вместе с» ( не арифметический «плюс») |
| [ х ; й ; г ] | «выберите только один из x , y или z ». точку с запятой (;) или вертикальную черту Для разделения элементов в списке можно использовать (|). |
| м { х } п или m:n { x } или | «от m до n итераций x ». Если m или n не указаны, то нижний или верхний предел просто «неизвестен» или «не указан». Многомерные массивы могут быть заданы путем вложения, например, 10 { 10 { x } 10 } 10 определяет двумерную матрицу из 10 строк и 10 столбцов. |
| ( х ) | «необязательно х ». Это эквивалентно 0{ x }1 или 0:1{ x } или . |
| @ | префикс для идентификатора внутри итерации. Например, в {@i+@j+x} i и j — идентификаторы. |
| * ... * | Все, что находится между одиночными звездочками, рассматривается как комментарий. На уровне элемента данных комментарий может содержать такие теги типа «диапазон:», «пределы:», «точность:», «единица измерения:» или «значения:». |
структурного программирования Элементы структуры данных могут отображаться в управляющие структуры :
- «+» может соответствовать «последовательности» утверждений (хотя это не обязательно так).
- «[|]» может отображаться в «выбор» ( условные выражения , операторы переключения )
- «{}», «()» могут сопоставляться с «итерацией» ( цикл подсчета , цикл предварительного тестирования , цикл среднего теста, цикл после теста и бесконечный цикл ).
Примечание. Определяемые элементы могут быть «материальными» (например, ключ от номера), а также «данными» (например, дата и время прибытия).
Определение требований и их причин
[ редактировать ]Информация о реакции на событие может быть зафиксирована в таблице. Событие является смыслом существования реакции, что обеспечивает « отслеживаемость » реакции обратно в окружающую среду.
| 1. Актер | 2. Внешнее событие/триггер | 3. Обнаружен | 4. Ответ(ы)/варианты использования |
|---|---|---|---|
| Гость | Гость запрашивает номер определенного типа, на определенную дату прибытия, дату отъезда, по определенному тарифу и т. д. | запрос на бронирование + (подтверждение платежа) + (*внешняя система бронирования* подтверждение бронирования) [5] | Забронировать номер (может включать гарантированное бронирование, альтернативное бронирование отеля, бронирование в списке ожидания) |
| Гость | Гость просит отменить бронирование номера. | запрос на отмену [6] | Отменить бронирование |
| Гость | Гость прибывает в отель. | сообщение о прибытии = * * = [имя гостя; ссылка на бронирование] [7] | Зарегистрироваться в качестве гостя |
| Время/Планировщик | Гость не прибывает в отель. [Это событие, не являющееся событием.] | 23:00 (по местному времени) [Событие «несобытие» обнаруживается по наступлению момента времени, крайнего срока.] | Создать счет для гостей, Обновить бронирование |
| Гость | Гость просит выписаться из отеля. | запрос на выезд = * * = [имя гостя; номер комнаты] [8] | Создать счет для гостей, Обновить заполняемость номера |
| Время/Планировщик | Гость не может выехать из отеля. [Это событие, не являющееся событием.] | 11 часов утра (по местному времени) [Событие «несобытие» обнаруживается по наступлению момента времени, крайнего срока.] | Создать счет для гостя |
| Гость | Гость предлагает оплатить счет. | средство платежа = * * = [наличные; проверять ; кредитная карта ; дебетовая карта] + (идентификатор гостя) [9] | Принимайте оплату от гостя |
| Время/Планировщик | Пора подготовить отчет о занятости номеров за прошлую ночь. | 8 утра (по местному времени) | Отчет о занятости номеров |
| Менеджер отеля | Менеджер отеля запрашивает отчет о занятости номеров. | запрос отчета о занятости | Отчет о занятости номеров |
| Сигнализация дыма/CO | Сигнализация обнаруживает дым. | сообщение о дымовой сигнализации | Сообщить о дымовой сигнализации |
| Сигнализация дыма/CO | Сигнализация обнаруживает CO (окись углерода). | Сообщение о тревоге CO | Сообщить о тревоге CO |
Определение требований
[ редактировать ]
Этот подход помогает аналитику разложить систему на «мысленно небольшие» мини-системы, используя события, требующие запланированного реагирования. Уровень детализации каждого ответа находится на уровне «основных вариантов использования ». Каждый запланированный ответ может быть смоделирован с использованием нотации DFD или как отдельный вариант использования с использованием нотации диаграммы вариантов использования.
Основной поток процесса или варианта использования обычно можно описать в виде относительно небольшого количества шагов, часто менее двадцати или тридцати, возможно, используя что-то вроде « структурированного английского языка ». В идеале все шаги должны быть видны сразу (часто страница или меньше). Цель состоит в том, чтобы снизить один из рисков, связанных с кратковременной памятью , а именно забывание того, что не сразу видно («с глаз долой, из головы»).
В качестве альтернативы, используя обозначения структурированных методов, аналитик может создать « диаграмму Насси – Шнейдермана ». В UML вариант использования можно смоделировать с помощью диаграммы деятельности , диаграммы последовательности или диаграммы связи . Это может быть проблематично, если имеется много сложных сценариев варианта использования; аналитик может захотеть смоделировать все или большинство сценариев.
Сложность против фрагментации
[ редактировать ]Если ответ длинный или сложный (т. е. превышает страницу текста), аналитик может разложить («выделить» или дедуплицировать ) на более мелкие «вторичные варианты использования», чтобы «родительский» основной вариант использования был меньше и проще. Эти вторичные варианты использования также могут оказаться пригодными для повторного использования. (На диаграмме вариантов использования UML они будут отображаться как расширенные или включенные варианты использования, которые связаны с одним или несколькими основными вариантами использования.)
Описывая вариант использования, аналитик может также раскрыть « бизнес-правила ». Некоторые аналитики предлагают фиксировать бизнес-правила в отдельном документе, используя язык ограничений объектов или какую-либо другую формальную систему обозначений . Затем, когда в сценарии использования необходимо соблюдать бизнес-правило, аналитик ссылается на него. Это сводит к минимуму повторение [10] внутри спецификации, но существует риск фрагментации спецификации. Одним из методов, который может уменьшить это напряжение, является использование гиперссылок в документе спецификации.
Этот редукционистский подход несколько контрастирует с подходом системного мышления , представленным Чекленда Питера методологией мягких систем .
Помимо функциональных требований, зафиксированных в описании варианта использования, аналитик может включить такие нефункциональные требования, как время отклика, обучаемость и т. д.
См. также
[ редактировать ]Ссылки
[ редактировать ]- ^ MCME-84: Макменамин, Стивен М.; Джон Ф. Палмер (1984). Существенный системный анализ . Прентис-Холл (Yourdon Press). ISBN 0-13-287905-0 . ( ISBN 978-0-13-287905-7 )
- ^ ВАШ-89: «yourdon.com — Достаточно структурированного анализа , главы 18, 19» . 1989. Архивировано из оригинала 14 февраля 2007 г. Проверено 24 апреля 2008 г.
- ^ ОТДЕЛЕНИЕ-85: Уорд, Пол Т.; Стивен Дж. Меллор (1985). Структурированная разработка систем реального времени: Том 2, Основные методы моделирования . Прентис-Холл (Yourdon Press). ISBN 0-13-854787-4 . ( ISBN 978-0-13-854787-5 )
- ^ WARD-85, стр. 38-39.
- ^ диалог бронирования = * *
= *вход* запрос на бронирование + *выход* подтверждение бронирования
запрос на бронирование = * *
= имя гостя + тип номера + (удобства в номере) +
дата-время прибытия + дата-время отъезда
тип комнаты = * тип спальни *
= * значения: [одиночный; двойной ; семья ] *
помещения = * Логические значения , указывающие наличие или отсутствие помещения *
= телевизор + радио + будильник + климат-контроль + доступ в Интернет +
телефон + холодильник + мини-бар + туалет + раковина + ванна + душ + биде
дата-время прибытия = * *
= дата-время
дата-время вылета = * *
= дата-время
дата-время = * формат ISO 8601 *
= год + месяц + день месяца + «Т» + час + минута > - ^ диалог отмены = * *
= *вход* запрос на отмену + *выход* подтверждение отмены - ^ диалог прибытия = * *
= *входное* сообщение о прибытии + *выходной* пакет о прибытии
пакет прибытия = * *
= ключ от номера + карточка от номера + купон на бесплатный напиток - ^ диалог оформления заказа = * *
= *вход* запрос на выезд + *выход* счет гостя - ^ диалог оплаты = * *
= *вход* платежное средство + *выход* гостевая квитанция
гостевой чек = * *
= имя гостя + адрес гостя + {детализация платежа} + общая сумма платежа + (налоги) + сумма к оплате + уплаченная сумма - ^ см. также «Не повторяйся », также известный как «СУХОЙ».
Внешние ссылки
[ редактировать ]- Разделение событий Structured Analysis Wiki