А.3.2.3. Спецификация проекта а.3.2.3.1. Связывание модулей с базами данных
В спецификации проекта на уровне функционального представления модули первоначально создаются исключительно на основе информации в виде данных без знания конкретной схемы базы данных. Затем эти модули и миниспецификации связываются с базами данных.
А.3.2.3.1.1. Привязка схемы
Прикладным модулям не нужно общаться со всей концептуальной схемой
базы данных: достаточно лишь некоторых фрагментов.
В концептуальной схеме для отдельных приложений имеет смысл изменить имена, поскольку иногда — при автономной разработке приложения — к спецификации проекта добавляются описания, которые не совпадают с независимо разработанной моделью данных.
Внешние схемы баз данных, связывающие пользователей с концептуальной схемой, описывают логические представления баз данных с точки зрения конкретного приложения или отдельных пользователей. На основе реляционной схемы можно вывести новые отношения, опустив атрибуты или некоторые кортежи базисных отношений, скомбинировав базисные отношения в соответствии с определенными критериями или, наоборот, разложив их на ряд более детальных отношений. Один из важнейших методов состоит в описании так называемых представлений. В общем виде это выглядит следующим образом (Mayr, Dittrich, Lockemann. Datenbankentwurf. 1987, с. 537):
• ОПИСАТЬ ПРЕДСТАВЛЕНИЕ [имя представления],
• ВЫБРАТЬ [выражение].
Метаструктура таких представлений показана на рис. 120. Вся концептуальная схема, состоящая из отношений, атрибутов и условий целостности, представлена сложным объектом КОНЦЕПТУАЛЬНАЯ СХЕМА. Ассоциации связывают ВНЕШНИЕ СХЕМЫ с КОНЦЕПТУАЛЬНЫМИ СХЕМАМИ. К одному МОДУЛЮ можно привязать несколько внешних схем и, наоборот, внешние схемы можно привязать к нескольким модулям.
Рис. 120. Связывание модулей со схемой базы данных
А.3.2.3.1.2. Выведение структур управления
Как правило, модули состоят из трех частей: описание данных, управляющая логика и инструкции. Для целей управления в структурном программировании допускаются следующие структуры: последовательность, итерация и выбор.
Структуры управления можно связывать со структурами данных. Ассоциации 1:1 между классами соответствуют последовательности; ассоциации 1:* соответствуют итерации, а операции конкретизации (разбивающие информационные объекты на подчлены) соответствуют выбору.
К информационному объекту КЛИЕНТ однозначным образом привязывается счет (ассоциация 1:1). Один клиент может порождать множество бизнес-событий, однако любое бизнес-событие всегда связано только с одним клиентом. БИЗНЕС-СОБЫТИЯ можно конкретизировать, подразделив их на ЗАКАЗ и ОТМЕНУ, (см. рис. 121).
Рис. 121. Отношения между структурами управления и структурами данных
Разные бизнес-события инициируют разные события бухгалтерской проводки. Результатом является управляющая процедура, представленная на рис. 122 в виде структурограммы. Сначала считывается запись, содержащая данные о конкретном клиенте. Затем считывается соответствующий счет. Эти два действия образуют последовательность, поскольку мощность (со стороны клиента) равна 1.
Рис.122. Структура управления
Различные бизнес-события с мощностью * (со стороны клиента), обрабатываемые для данного клиента, представлены как итерация.
В зависимости от типа бизнес-события выполняются различные бухгалтерские проводки в соответствии с их конкретным значением.
Метаописания опускаются. Такое проектирование программы, ориентированное на структуру данных, аналогично построению обмена сообщениями на основе ассоциаций диаграммы классов в контексте объектно-ориентированных методов.