Раздел 1

Построение визуальной модели предметной области

Модель – это «упрощение реальности» в интересах заинтересованных лиц. Такое определение относится и к нашему моделированию. Здесь главным заинтересованным лицом является инвестор или топ-менеджер организации. Есть и другие заинтересованные лица – аналитики, архитекторы, разработчики информационной системы (ИС), и поэтому одной модели, как правило, недостаточно. Нужны разные «упрощения» для разных читателей модели².

Первым шагом процесса моделирования является определение целей моделирования. Будем содержательно разбирать процесс построения на примере ИС, учитывающей расход продуктов в кафе и ресторанах организации, которую назовем «Комбинат питания». Текст с описанием задачи, полученный от владельца комбината, приведен в начале приложения 1.

Общий взгляд на процесс, состоящий из семи шагов, можно представить следующим списком задач, выполняемых в ходе моделирования:

• Шаг №0. Определяем цели построения модели.

• Шаг №1. Определяем события-картотеки, подлежащие учету на предприятии.

• Шаг №2. Определяем справочники-картотеки, подлежащие учету.

• Шаг №3. Для события определяем картотеки, связанные с ним (для каждого события).

• Шаг №4. Для справочника определяем картотеки, связанные с ним (для каждого справочника).

• Шаг №5. Отображаем (визуально) картотеки, связанные с ней на диаграмме классов UML.

• Шаг №6. Применяем паттерны преобразования отношений на диаграммах классов UML.

Шаг №0. Определяем цели построения модели

Цель построения модели в задаче «Комбинат питания» была определена в постановке задачи.

Это учет заказов гостей, движения продуктов и денег за них в пунктах питания – кафе и ресторанах. Теперь мы не будем учитывать и вводить в модель те детали, которые не относятся к заявленной цели. Например, не учитываем события «бронирование столика в кафе».

Далее следует определить те события («бизнес-транзакции»), которые подлежат учету, согласно заданным целям. Для таких событий на предприятии будут вестись учетные записи, или – в нашей терминологии – картотеки (гроссбухи, если учет бумажный).

Шаг №1. Определяем события, подлежащие учету

Для нашего примера мы выявляем бизнес-события по «движению продуктов питания и денег за них». Очевидно, что такими событиями будут:

1. «Заказ» гостя.

2. «Оплата заказа».

3. «Покупка продуктов» в кафе.

Для каждого события определяется картотека – при возникновении события в этой картотеке должна быть создана новая учетная запись (карточка).

Для выявления других событий будем использовать паттерны³. Первым паттерном является введение «расхода» учетных сущностей – продуктов и блюд – через «брак» или «некачественную сущность», подлежащую списанию. По этому паттерну («Списание брака») вводим два новых события:

4. «Списание бракованных продуктов» (по паттерну).

5. «Списание бракованных блюд» (по паттерну).

Следующий паттерн называется «Инвентаризация»: если на предприятии есть учетная система (информационная или на бумаге), то периодически следует выявлять реальный состав предметов учета на складе. Полученные в результате инвентаризации списки предметов (в нашем случае – продуктов питания) следует сравнить со списками, полученными (как отчеты) из учетной системы. Вводим в наш список событие:

6. «Инвентаризация» склада кафе (по паттерну).

Итак, пометка «по паттерну» означает, что данное событие может быть не указано в постановке задачи, но мы применяем паттерн (стандартное решение стандартной часто встречающейся задачи). Паттерн «Списание брака» означает учет (некачественных изделий) – в нашем случае – продуктов и блюд. Паттерн «Инвентаризация» используется, если имеется некоторая учетная система и требуется периодически сравнивать фактический состав продуктов на складе со «списочным составом», полученным из учетной системы. Событие «инвентаризация» – это проведение учета фактического состава продуктов на складе кафе ресторана на данную календарную дату. Проведение сравнения двух списков («Инвентаризация» – «Отчет системы») позволяет выявить «недостачу».

Третьим паттерном является паттерн «Прайс-лист», который в комбинате питания называется «меню». Цены блюд в каждом кафе могут различаться. Для этого ведется меню как прайс-лист блюд на данную дату работы кафе. Поскольку для цен определена дата (или интервал дат) их «действия», то эту сущность мы отнесем к бизнес- событиям.

7. «Меню» кафе (по паттерну).

В результате мы выявили семь событий, подлежащих учету, – три непосредственно из постановки задачи и еще четыре на основе применения паттернов.

Шаг №2. Определяем справочники, подлежащие учету

Кроме картотек по событиям, на предприятии ведутся «учетные списки», которые можно назвать справочниками. Справочники более «стабильны» – изменения в них вносятся значительно реже и они «не зависят» от даты. Например, в комбинате питания следует вести список всех «пунктов питания» (ресторанов, кафе, закусочных). Это же относится и к списку сотрудников комбината. Такие справочники также являются картотеками, и они также подлежат учету в нашей модели как классы:

1. «Пункт питания» (ПП).

2. «Сотрудник».

3. «Блюдо» (рецепты).

4. «Продукты»⁴ (включая напитки).

Следует понимать, что на первых этапах могут быть выявлены не все события и справочники. Новые картотеки будут появляться далее в ходе итерационного построения модели, при применении паттернов и при получения обратной связи от заинтересованных лиц.