Исследование предметной области

Выше была показана необходимость проведения анализа предметной области, как начального этапа в процессе проектирования системы. Здесь необходимо сказать, что создание программной системы и базы данных, хранящей некоторую информацию, используемую системой в работе, неразрывно связаны. По словам Г. Буча, в деятельности разработчиков баз данных и программистов существуют серьезные различия, которые определяются различиями в технологии и в навыках разработки. Проектировщики баз данных обычно описывают проблемную область в терминах «долгоживущих» монолитных таблиц с информацией, в то время как программисты привыкли воспринимать мир в терминах потоков управления. Если эти два подхода не удастся совместить в рамках одного проекта, то добить­ся целостности проектного решения для более или менее сложной системы будет практически невозможно. Для системы, в которой главное – данные, мы должны добиться равновесия между базой данных и приложением.
База данных, разработанная без учета того, как она в дальнейшем будет использоваться, оказывается, как правило, неуклюжей и неэффективной.
В свою очередь изолированное приложение может предъявить невыполнимые требования к базе данных, что приведет к серьезным проблемам
с обеспечением целостности информации [1].

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

Одним из наиболее существенных моментов на начальной стадии проектирования является этап анализа. Он состоит в исследовании системных требований и проблемы, а не в поисках путей ее решения. Часто этот этап называется этапом анализа требований к системе.

На этапе исследования предметной области очень важно выделить бизнес-правила, т.е. правила, определяющие процессы в предметной облас­ти. Это требования не к конкретной БД, а ко всем БД данной предметной области.

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

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

Одним из базовых понятий в структурном, и объектно-ориентиро­ванном подходах является понятие нотации.

В рамках структурного подхода существует несколько методологий описаний предметной области, позволяющие составить модель системы
с различных точек зрения. Все методологии были разработаны Национальным институтом стандартизации и технологий, а их названия начинаются
с букв IDEF (Integration Definition for Function Modeling), вслед за которыми идет номер соответствующей методологии. В дальнейшем, при рассмотрении вопросов, связанных с описанием исследуемой предметной
области и построением ее модели, будем использовать описанную в рамках методологии IDEF0 нотацию DFD (Data Flow Diagram) – диаграммы потоков данных. Следует отметить, что в IDEF0 описана также другая нотация – SADT, также используемая для описания бизнес процессов предметной области, однако ее использование требует более строго
соблюдения правил построения моделей и хуже приспособлено для построе­ния моделей бизнес процессов экономических систем.

Читателю, желающему изучить эти вопросы более подробно можно обратиться к [1,2,6].

Диаграммы потоков данных

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

Для построения DFD традиционно используются две различные
нотации, соответствующие методам Йордана – де Марко и Гейна – Сэрсона. Эти нотации незначительно различаются друг от друга графическим изображением символов. Далее при построении примеров будет использоваться нотация Йордана – де Марко.

В соответствии с данным методом модель системы описывается как иерархия диаграмм потоков данных, описывающих процесс преобразования информации от ее ввода в систему до выдачи пользователю. Иерархия представлена диаграммами различного уровня. На верхнем уровне используются контекстные диаграммы, определяющие основные процессы
в под­системах с внешними входами и выходами. Процессы, представленные на диаграммах верхнего уровня детализируются при помощи диаграмм нижнего уровня до тех пор, пока не будет достигнут уровень
декомпозиции, на котором процессы становятся элементарными и детализировать их далее невозможно или бессмысленно.

DFD диаграммы строятся исходя из того, что источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям - потребителям информации.

Приведем краткое описание и обозначение основных элементов диаграмм DFD:

Элемент	Описание	Обозначение
Внешняя сущность	Материальный объект или физическое лицо, представляющее собой источник или приемник информации
Функция/процесс	Действие, выполняемое моделируемой системой/процесс преобразования входных потоков данных в выходные в соответствии с определенным алгоритмом (обработка данных)
Поток данных	Объект, над которым выполняется действие. Может быть информационным (логическим) или управляющим. (Управляющие потоки обозначаются пунктирной линией со стрелкой).
Хранилище данных	Абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми

Построение диаграммы DFD производится в следующей последовательности: