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

Исключение из этого правила: если новая сущность содержит только ключевые атрибуты, то мы не получим выигрыша. Однако даже в этом случае может быть лучше поступить по правилу: 1. у сущности с течением времени могут появиться еще атрибуты, 2. отдельный список можно использовать для хранения списка разрешенных значений (и выбора из него).

Списки дел. Это - ситуации, вызываемые по инициативе не пользователя, а системы. Служат для «склеивания» нескольких сеансов связи пользователя с системой в один. Нужны, если известно, что некоторое по смыслу единое действие невозможно провести за один сеанс. Например, нужно подождать некоторого внешнего события, или действие должен продолжить другой человек. Служат напоминанием пользователю и позволяют полностью восстановить контекст прерванного сеанса (набор форм, текущие записи, положение курсора и т.п.) Обычно связаны с прохождением некоторого информационного объекта (документа) через несколько ситуаций. Этот же механизм можно использовать для запоминания прерванных по желанию пользователя сеансов и восстановления их. Каждый пункт списка дел запускает определенную ситуацию при согласии пользователя (+нужна функциональность будильника: «напомнить в определенное время», «отложить на время», «пометить как сделанное (т.е. удалить из списка)», «показывать только при определенном условии», «автоматически удалить при определенном условии» …)

Пример: автоматизируемый вид деятельности – «добавление в прайс новой услуги». Информационный объект – «услуга».

Ситуации, через которые он проходит:

1. «ввод услуги в анкету», состояние объекта – «предлагаемая в анкете», список дел для занимающегося анкетированием: «бланки анкет изменились - перепечатать перед использованием», Запускает ситуацию «печать бланков».

2. «ввод результата анкетирования», возможное изменение состояния объекта – «популярная у клиентов – кандидат на добавление в прайс», список дел для директора: «клиенты хотят новую услугу – добавлять?», запускает ситуацию «рассмотрение директором новой услуги»

3. «рассмотрение директором новой услуги», возможное изменение состояния объекта – «добавляемая в прайс», список дел для бухгалтера: «составить смету на новую услугу», запускает ситуацию «составление сметы на новую услугу».

4. «составление сметы на новую услугу», возможное изменение состояния объекта – «смета готова», список дел для директора: «посмотрите смету на новую услугу», запускает ситуацию «утверждение сметы директором».

5. «утверждение сметы директором», возможное изменение состояния объекта – «смета утверждена», список дел для снабженца: «заключить договор на поставку материалов на услугу», запускает ситуацию «ввод заключенного договора» (снабженец откладывает этот пункт, пока не заключит договор).

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

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

Виды описания ИС: функции и потоки данных (DFD), статический портрет - структуры данных (ER), динамика - последовательности событий (STD) и обмен сообщениями (MSC).

Функциональное описание - DFD диаграмма. Состоит из процессов, хранилищ и потоков данных между ними. Говорит о том, какие данные циркулируют в системе и как они преобразуются друг в друга. То, что преобразует данные, называется процессами. Они отражаются на DFD-диаграмме в виде кругов с названием процесса внутри. Потоки данных – стрелки. На стрелках – краткое пояснение сущности передаваемых данных. Описание проводится иерархически: процессы – черные ящики, внутренность которых раскрывается в DFD-диаграммах следующих уровней. Проверка делается по процессам (для указанного процесса должно хватать перечисленных входящих в него данных; выходящие стрелки должны перечислять все получаемые от процесса результаты) Хранилища нужны для синхронизации разновременных процессов. Т.е. если заведомо известно, что процесс-потребитель и процесс-источник данных происходят в разное время, между ними помещают хранилище. Входы/выходы системы – "внешние сущности" – изображаются квадратами ("директор", "клиент" и т.п.)

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

Диаграммы состояний и переходов (STD). Показывают состояния информационного объекта (кружки с названиями), возможные переходы между ними (стрелки) и их условия (над стрелками). Начальное состояние изображается

Дополнительные пояснения

Пример правильного фрагмента описания ИС (наименования опущены):

В ситуации «расчет заработной платы» система создает факты вида:

§ В июне 2003 г Иванов Иван Иванович заработал 500 р. 00 коп.

Для создания этого факта ИС учитывала, что:

§ Иванов Иван Иванович имеет табельный номер 243

§ 20.06.03 работник с табельным номером 243 выполнил работу " изготовление стула " в объеме 5шт.

§ Тариф на выполнение 1 шт. работы " изготовление стула " равен 100 р.

Примеры ошибочных фактов:

§ Накладные подписывает главный бухгалтер.

Нет переменных частей. Такие факты в БД не хранятся!

§ Клиент получил определенный материал.

В факте записываются конкретные значения (взятые из гипотетической ситуации), а не их описания. (Что на самом деле будет написано на месте слова "клиент"? ФИО? Код? Расчетный счет? Или слова «наш работник», «VIP клиент» - для определения размера скидки?)

§ 20.06.03 работник с табельным номером 243 выполнил работы " изготовление стула " и " ремонт рамы ".

Перечисление должно быть оформлено как список. Правильно:

20.06.03 работник с табельным номером 243 выполнил работы:

§ " изготовление стула "

§ " ремонт рамы ".

20.06.03 отсутствовали работники Иванов, Сидоров, Гречаник.

Нарушено правило "один параметр содержит ровно одно данное". Правильно:

20.06.03 отсутствовали работники:

§ Иванов

§ Сидоров

§ Гречаник

§ Иванов Иван Иванович получил 43 кг цемента.

Когда таких фактов будет много, невозможно будет определить, когда это произошло, по какому документу и т.п.