СТРУКТУРНОЕ ПРОЕКТИРОВАНИЕ ПО

 

В данном подразделе рассматривается вторая часть методики Йордона (см. подразд. 3.2.2), связанная с переходом от бизнес-модели к модели системы. Пример применения данной методи­ки приведен в подразд. 4.2.

Согласно данной методике в процессе проектирования вы­полняется детальное описание функционирования системы, дальнейший анализ используемых данных и построение реляци­онной модели для последующего проектирования базы данных. Определяется также структура пользовательского интерфейса. Результатами проектирования являются:

· модель системных процессов;

· архитектура системы;

· модели данных приложений;

· модель пользовательского интерфейса.

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

Например, для DFD переход от модели бизнес-процессов к модели системных процессов может происходить следующим об­разом:

· внешние сущности на контекстной диаграмме заменяются или дополняются техническими устройствами (например, рабочими станциями, принтерами и т.д.);

· для каждого потока данных определяется, посредством ка­ких технических устройств информация передается или производится;

· процессы на диаграмме нулевого уровня заменяются соот­ветствующими процессорами — обрабатывающими устрой­ствами (процессорами могут быть как технические устрой­ства — настольные компьютеры конечных пользователей, рабочие станции, серверы баз данных, так и программные средства);

· определяется и изображается на диаграмме тип связи между процессорами (например, локальная сеть);

· определяются задачи для каждого процессора (приложения, необходимые для работы системы), для них строятся соот­ветствующие диаграммы. Определяется тип связи между за­дачами;

· устанавливаются ссылки между задачами и процессами ди­аграмм потоков данных следующих уровней.

Иерархия экранных форм Моделируется с помощью диаграмм последовательностей экранных форм. Совокупность таких диаг­рамм представляет собой абстрактную модель пользовательского интерфейса системы, отражающую последовательность появления экранных форм в приложении. Построение диаграмм последова­тельностей экранных форм выполняется следующим образом:

· на DFD выбираются интерактивные процессы нижнего уровня. Интерактивные процессы нуждаются в пользова­тельском интерфейсе, поэтому можно определить экранную форму для каждого такого процесса;

· построение диаграммы последовательностей форм начи­нается с изображения формы в виде прямоугольника для каждого интерактивного процесса на нижнем уровне диаг­раммы;

· определяется структура меню. Для этого интерактивные процессы группируются в меню (либо так же, как в модели процессов, либо другим способом — по функциональным признакам или в зависимости от принадлежности к опреде­ленным объектам);

· формы с меню изображаются над формами, соответствую­щими интерактивным процессам, и соединяются с ними пе­реходами в виде стрелок, направленных от меню к формам.

· определяется верхняя форма (главная форма приложения), связывающая все формы с меню.

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

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

Для формирования схемы базы данных из ERM применяется ограниченный набор правил преобразования сущностей и связей между ними.

Правила преобразования сущностей:

Правило 1. Каждая простая сущность, не являющаяся подти­пом и не имеющая подтипов, превращается в таблицу. Имя сущ­ности становится именем таблицы.

Правило 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столб­цы, соответствующие необязательным атрибутам, могут содер­жать неопределенные значения; столбцы, соответствующие обя­зательным атрибутам, — не могут.

Правило 3. Уникальный идентификатор сущности превраща­ется в первичный ключ таблицы. Если имеется несколько аль­тернативных уникальных идентификаторов, выбирается наибо­лее используемый. Если уникальный идентификатор является относительным, то в качестве первичного ключа используется копия уникального идентификатора сущности, находящейся на дальнем конце связи, в которой данная сущность играет роль за­висимой.

Правила преобразования связей:

Правило 1. Если тип бинарной связи — один-к-одному и класс принадлежности обеих сущностей является обязательным, то из двух связанных сущностей формируется одна таблица. Первич­ным ключом этой таблицы может быть идентификатор любой из двух сущностей.

Правило 2. Если тип бинарной связи — один-к-одному и класс принадлежности одной сущности является обязательным, а дру­гой — необязательным, то формируются две таблицы (под каж­дую сущность), при этом идентификатор каждой сущности дол­жен служить первичным ключом соответствующей таблицы. Кроме того, идентификатор сущности, для которой класс при­надлежности является необязательным, добавляется в качестве атрибута в таблицу, выделенную для сущности с обязательным классом принадлежности.

Правило 3. Если тип бинарной связи - один-к-одному и класс принадлежности ни одной сущности не является обязательным, то формируются три таблицы: по одной для каждой сущности (при этом идентификатор каждой сущности должен служить пер­вичным ключом соответствующей таблицы) и одна для связи. Таблица связи включает в качестве атрибутов по одному иденти­фикатору от каждой сущности.

Правило 4. Если тип бинарной связи — один-ко-многим и класс принадлежности сущности с мощностью «n» является обязатель­ным, то формируются две таблицы (под каждую сущность), при этом идентификатор каждой сущности должен служить первич­ным ключом соответствующей таблицы. Кроме того, идентифи­катор сущности с мощностью «1» добавляется в качестве атрибу­та в таблицу, выделенную для сущности с мощностью «n».

Правило 5. Если тип бинарной связи — один-ко-многим и класс принадлежности сущности с мощностью «n» является необяза­тельным, см. правило 3.

Правило 6. Если тип бинарной связи — многие-ко-многим, см. правило 3.

Правило 7. Для представления N-арной связи требуется N+1 таблица. Например, в случае тернарной связи формируются че­тыре таблицы, по одной для каждой сущности и одна для связи. Таблица связи будет иметь среди своих атрибутов ключи от каж­дой сущности.

Правило 8. Для связи «супертип-подтип» возможны два спо­соба преобразования:

а) все подтипы в одной таблице;

б) для каждого подтипа — отдельная таблица.

При применении способа (а) для супертипа создается табли­ца, а для подтипов могут создаваться представления (view). В таб­лицу добавляется по крайней мере один столбец, содержащий код типа; он становится частью первичного ключа.

При использовании способа (б) для каждого подтипа супертип воссоздается с помощью операции объединения (UNION) — из всех таблиц подтипов выбираются общие столбцы - столбцы супертипа.

Преимущества способа (а): все данные хранятся вместе, обес­печивается легкий доступ к супертипу и подтипам, требуется меньше таблиц.

Недостатки способа (а): усложняется логика работы с раз­ными наборами столбцов и ограничениями, возможно сниже­ние производительности (в связи с блокировками общей табли­цы), столбцы подтипов должны допускать неопределенные зна­чения.

Преимущества способа (б): наглядное соответствие схемы БД и ERM, приложения работают только с нужными таблицами.

Недостатки способа (б): формируется слишком много таблиц, возможно снижение производительности при выполнении опе­рации объединения, невозможны модификации супертипа.

 

4.2.

ПРИМЕР СТРУКТУРНОГО

ПРОЕКТИРОВАНИЯ ПО

 

Здесь продолжено рассмотрение примера из подразд. 3.2.5.