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