Стратегия проектирования, ориентированная на структуру данных.
Если при функциональной декомпозиции основное внимание сосредотачивается на структуре управляющей логики программы безотносительно к структуре ее данных, в альтернативном подходе внимание концентрируется прежде всего на структуре данных, в соответствии с которой строится структура управляющей логики. Такой подход может быть назван ориентированным на структуру данных или на модель данных.
Эта стратегия, в том или ином виде, находит отражение наиболее часто в литературе, связанной с разработкой баз данных [6,17].
В структурном плане модель данных характеризуется как совокупность взаимосвязанных понятий и правил порождения структур данных, ограничений целостности (логико-семантических свойств данных), а также операций над данными. Теория моделей данных получила развитие именно в связи с использованием концепций баз данных и проблемами специфических компьютеризованных систем ведения данных - автоматизированных банков данных.
Концепция баз данных связана с проблемами обеспечения логико-семантической и физической целостности, а также эффективности многоцелевого использования данных в условиях непрерывной и естественной эволюции приложений - процессов, оперирующих данными. Конкретная реализация этой концепции приводит к архитектуре многоуровневого представления данных, которая и является отличительным признаком базы данных.
Выделяют три уровня представления данных: концептуальный, внешний и внутренний.
Концептуальный уровень представления данных в форме концептуальной модели данных отражает объективные, не зависящие от конкретного приложения свойства данных, описывающие предметную область.
Внешний уровень представления данных отражает субъективные взгляды приложений на данные. В большинстве практических случаев внешнее представление ограничивается выделением некоторого подмножества концептуального представления.
Внутренний уровень представления данных определяет машинно-ориентированное, физическое представление данных.
Стратегия структурного проектирования, ориентированного на потоки данных.
Стратегия проектирования, о которой будет идти речь в дальнейшем, может быть названа структурным проектированием, ориентированным на потоки данных. В рамках этой стратегии сначала определяют ключевые компоненты потоков информации, циркулирующих в системе, а затем, идентифицируя функции преобразования в узловых точках информационного потока, производят своего рода функциональную декомпозицию; результатом таких действий является граф информационных потоков. Следующий шаг состоит в построении на его основе структурного графа, который описывает структуру управляющей логики системы для реализации нужного информационного потока. Та же стратегия применяется далее к подсистемам, подсистемам подсистем и т.д., и при этом умышленно игнорируются детали структуры данных. На рисунке 2.4 изображены основные элементы представления схем ориентированных на потоки данных, а на рисунке 2.5 представлены основные виды структурных преобразований схем, ориентированных на потоки данных.
Методология проектирования (неформальная):
Шаг 1. Определить в системе наиболее очевидные граничные модули-подсистемы. Центральную часть системы рассмотреть как единый центральный модуль. Приписать модулям функции неформально, только в самом общем виде.
Шаг 2. Определить информационные потоки между модулями и оценить необходимость введения дополнительных внутренних компонентов информационных потоков. Определить внутренние модули, которые целесообразно иметь в системе по соображениям обеспечения требуемых функций и модульной конструкции.
Рис. 2.4. Базовые элементы представления схем, ориентированных на потоки данных
Рис. 2.5. Структурные преобразования схем, ориентированных на потоки данных.
Шаг 3. Уточнить представление о модулях и данных. С той степенью подробности, какая возможна на данной стадии, приписать модулям конкретные функции, используя перечень технических требований к системе. Снова уточнить информационный потоковый граф с учетом произведенного распределения функций. Провести критический анализ проектных решений по системе на данной стадии и при необходимости внести изменения.
Шаг 4. Разработать один или несколько структурных графов, определяя возможные варианты архитектуры системы в виде пакетов и задач.
Шаг 5. Описать в деталях интерфейсы системы, в том числе подробности, касающиеся типов и структур данных, и опять провести критический анализ.
Шаг 6. Если приходится иметь дело с большой и сложной системой, то может оказаться необходимым рекурсивное применение описанного метода для разработки проектов по подсистемам.