Объединение локальных представлений

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

• объединение в единое целое фрагментарных представлений о различных свойствах одной и той же сущности;
• введение абстрактных понятий, удобных для решения задач системы, установление их связи с более конкретными понятиями модели;
• образование классов и подклассов подобных сущностей (например, класс "изделие" и подклассы типов изделий, производимых на предприятии).

При объединении локальных представлений используют три основополагающие концепции:

1. Идентичность. Два или более элементов модели идентичны, если они имеют одинаковое семантическое значение. Например, СОТРУДНИК для отдела кадров и СОТРУДНИК для отдела закупок – это один и тот же тип сущности, возможно, с разным набором атрибутов. (Наборы атрибутов исходных сущностей при этом объединяются).
2. Агрегация. Позволяет рассматривать связь между элементами как новый элемент. Например, связь экзаменовать между сущностями ДИСЦИПЛИНА, ПРЕПОДАВАТЕЛЬ, СТУДЕНТ может быть представлена агрегированной сущностью ЭКЗАМЕН с атрибутами Название дисциплины, Фамилия преподавателя, Фамилия студента, Оценка.
3. Обобщение. Позволяет образовывать многоуровневую иерархию обобщений. Например, в объединяемых представлениях присутствуют следующие сущности:

ДЕТАЛИ СОБСТВЕННОГО ПРОИЗВОДСТВА

ДЕТАЛИ ПОКУПНЫЕ

СБОРОЧНЫЕ ЕДИНИЦЫ ПОКУПНЫЕ

СБОРОЧНЫЕ ЕДИНИЦЫ СОБСТВЕННОГО ПРОИЗВОДСТВА

Их можно объединить так, как показано на рис. 8.2.

Рис. 8.2. Использование обобщений при объединениих

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

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

По завершении объединения результаты проектирования представляют собой концептуальную инфологическую модель ПО. Она фиксируется в виде общей ER-диаграммы предметной области. Модели локальных представлений – это внешние инфологические модели (внешние схемы).

На этапе анализа ПО также решаются следующие задачи:

1. Определение правил (ограничений целостности), которым должны удовлетворять сущности ПО, атрибуты сущностей и связи между ними. Часть этих правил реализуется в схеме базы данных. Возможности реализации ограничений целостности в схеме БД определяются моделью данных той СУБД, которая будет выбрана для реализации проекта. Остальные правила реализуются с помощью программного обеспечения.
2. Выделение групп пользователей системы. Каждая группа выполняет определённые задачи и обладает разными правами доступа к системе.
3. Создание внешней спецификации тех функций (процессов), которые эта система будет выполнять. Например, для той же библиотечной системы это задачи поиска книг (по определённым критериям), выдачи/приёма книг, определение списка должников и т.д. Эта спецификация является основой для разработки приложений и выдаётся программистам в качестве задания.

5.4 Определение требований к операционной обстановке

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

Выбор зависит от таких показателей, как:

• примерный объём данных в БД;
• динамика роста объёма данных;
• характер запросов к данным (извлечение и обновление отдельных записей, обработка групп записей, обработка отдельных отношений или соединение отношений);
• интенсивность запросов к данным по типам запросов;
• требования ко времени отклика системы по типам запросов;
• режим работы (интерактивный, пакетный или режим реального времени).

Эта информация позволяет определить системные требования к объёму оперативной и дисковой памяти, а также функциональным возможностям ОС.