Вендров А.М. Проектирование программного обеспечения экономических информационных систем

Подождите немного. Документ загружается.

Моделирование бизнес-процессов и спецификация требований 281

студент подтвердит это сообщение, основной поток начнется с

начала.

Система

каталога курсов недоступна.

Если окажется, что невозможно установить связь с системой

каталога курсов, то будет выдано сообщение об ошибке. После

того,

как студент подтвердит это сообщение, вариант использо-

вания завершится.

Регистрация

на

курсы

закончена.

Если в самом начале выполнения варианта использования

окажется, что регистрация на текущий семестр закончена, будет

выдано сообщение, и вариант использования завершится.

Удаление

отменено.

Если во время выполнения подчиненного потока «Удалить

график» студент решит не удалять его, удаление отменяется, и ос-

новной поток начнется с начала.

Предусловия.

Перед началом выполнения данного варианта использования

студент должен войти в систему.

Постусловия.

Если вариант использования завершится успешно, график

студента будет создан, обновлен или удален. В противном случае

состояние системы не изменится.

Вариант использования «Закрыть регистрацию».

Краткое описание.

Данный вариант использования позволяет регистратору зак-

рывать процесс регистрации. Предлагаемые курсы, на которые

не записалось достаточного количества студентов (менее трех),

отменяются.

расчетную систему передается информация о каж-

дом студенте по каждому предлагаемому курсу, чтобы студенты

могли внести оплату за курсы.

Основной

поток

событий.

Данный вариант использования начинает выполняться, когда

регистратор запрашивает прекращение регистрации.

Система проверяет состояние процесса регистрации. Если

регистрация еще выполняется, выдается сообщение и вариант

использования завершается.

Для каждого предлагаемого курса система проверяет, ведет

ли его какой-либо профессор и записалось ли на него не менее

трех студентов. Если эти условия выполняются, система фикси-

282 Глава 3

рует предлагаемый курс в каждом графике, который включает

данный курс.

Для каждого студенческого графика проверяется наличие в

нем максимального количества основных курсов; если их недос-

таточно, система пытается дополнить альтернативными курсами

из списка данного графика. Выбирается первый доступный аль-

тернативный курс. Если таких курсов нет, то никакое дополнение

не происходит.

Система закрывает все предлагаемые курсы. Если в каком-

либо предлагаемом курсе оказывается менее трех студентов (с

учетом добавлений, сделанных в п.З), система отменяет его и

исключает из каждого содержащего его графика.

Система рассчитывает плату за обучение для каждого сту-

дента в текущем семестре и направляет информацию в расчетную

систему. Расчетная система посылает студентам счета для оплаты

с копией их окончательных фафиков.

Альтернативные

потоки.

Предлагаемый

курс никто не ведет.

Если во время выполнения основного потока обнаруживает-

ся,

что некоторый курс не ведется никаким профессором, то этот

курс отменяется. Система исключает данный курс из каждого со-

держащего его фафика.

Расчетная система

недоступна.

Если невозможно установить связь с расчетной системой, че-

рез некоторое установленное время система вновь попытается

связаться с ней. Попытки будут повторяться до тех пор, пока

связь не установится.

Предусловия.

Перед началом выполнения данного варианта использования

регистратор должен войти в систему

Постусловия.

Если вариант использования завершится успешно, регистра-

ция закрывается. В противном случае состояние системы не из-

менится.

! Следует запомнить.

Моделирование бизнес-процессов является важной сос-

тавной частью проектов по созданию крупномасштабных

систем ПО. Отсутствие таких моделей является одной из

главных причин неудач многих проектов.

Моделирование бизнес-процессов и спецификация требований 283

Бизнес-процесс определяется как логически завершенный

набор взаимосвязанных и взаимодействующих видов дея-

тельности, поддерживающий деятельность организации и

реализующий ее политику, направленную на достижение

поставленных целей.

Бизнес-модель

—

это формализованное описание процес-

сов,

связанных с ресурсами и отражающих существующую

или предполагаемую деятельность предприятия. Построе-

ние бизнес-моделей заключается в применении различных

методов и средств для визуального моделирования бизнес-

процессов.

Для выявления требований используются (в различных со-

четаниях) следующие методы:

• собеседование (интервьюирование);

• анкетирование;

• моделирование и анализ бизнес-процессов;

• сессии по выявлению требований (мозговой штурм);

• создание и демонстрация пользователям работающих про-

тотипов приложений (для выявления замечаний

дополни-

тельных требований).

^ Основные понятия

Бизнес-процесс, бизнес-модель, бизнес-правила, действую-

щее лицо бизнес-процессов, вариант использования с точки зре-

ния бизнес-процессов, бизнес-объект.

? Вопросы для самоконтроля

Что такое бизнес-процесс и бизнес-модель?

Что дает построение бизнес-моделей и какие проблемы с

ним связаны?

Охарактеризуйте достоинства и область применения мето-

дики моделирования Rational Unified Process.

Какие проблемы могут возникнуть при спецификации тре-

бований в случае отсутствия бизнес-моделей?

^|4ft^S^W«C^4N<«^^5:^^S£<¥S?^^^

АНАЛИЗ И ПРОЕКТИРОВАНИЕ

ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

Прочитав эту

главу,

вы узнаете:

•

Что представляет собой анализ и проектирование

ПО.

• В

чем заключается структурный подход

анализу

проектиро-

ванию

ПО.

• В

чем заключается объектно-ориентированный подход

анализу

и проектированию

ПО.

4.1.

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

данном подразделе рассматривается вторая часть методики

Йордона (см. подразд. 3.2.2), связанная с переходом от бизнес-

модели к модели системы. Пример применения данной методи-

ки приведен в подразд. 4.2.

Согласно данной методике в процессе проектирования вы-

полняется детальное описание функционирования системы,

дальнейший анализ используемых данных и построение реляци-

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

Определяется также структура пользовательского интерфейса.

Результатами проектирования являются:

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

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

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

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

Функциональные модели, используемые в процессе проекти-

рования, предназначены

для

описания функциональной структу-

ры проектируемой системы. Диаграммы потоков данных (DFD)

используются для описания структуры проектируемой системы,

при этом они могут уточняться, расширяться и дополняться но-

выми конструкциями. Аналогично, ERM преобразуется в схему

Анализ и проектирование программного обеспечения 285

базы данных. Данные модели могут дополняться диаграммами,

отражающими системную архитектуру ПО, структурные схемы

программ (структурные карты), иерархию экранных форм и ме-

ню

др.

Состав диафамм и степень

их

детализации определяют-

ся необходимой полнотой описания системы для непосредствен-

ного перехода к ее последующей реализации (профаммирова-

нию).

Например, для DFD переход от модели бизнес-процессов к

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

может происходить следующим об-

разом:

• внешние сущности на контекстной диафамме заменяются

или дополняются техническими устройствами (например,

рабочими станциями, принтерами и т.д.);

• для каждого потока данных определяется, посредством ка-

ких технических устройств информация передается или

производится;

• процессы на диафамме нулевого уровня заменяются соот-

ветствующими процессорами ~ обрабатывающими устрой-

ствами (процессорами могут быть как технические устрой-

ства

—

настольные компьютеры конечных пользователей,

рабочие станции, серверы баз данных, так и профаммные

средства);

• определяется и изображается на диафамме тип связи между

процессорами (например, локальная сеть);

• определяются задачи для каждого процессора (приложения,

необходимые для работы системы), для них строятся соот-

ветствующие диафаммы. Определяется тип связи между за-

дачами;

• устанавливаются ссылки между задачами и процессами ди-

афамм потоков данных следующих уровней.

Иерархия экранных форм моделируется с помощью

диаграмм

последовательностей экранных

форм.

Совокупность таких диаг-

рамм представляет собой абстрактную модель пользовательского

интерфейса

системы,

отражающую последовательность появления

экранных форм в приложении. Построение диафамм последова-

тельностей экранных форм выполняется следующим образом:

• на DFD выбираются интерактивные процессы нижнего

уровня. Интерактивные процессы нуждаются в пользова-

тельском интерфейсе, поэтому можно определить экранную

форму

для

каждого такого процесса;

286 Глава 4

• построение диаграммы последовательностей форм начи-

нается с изображения формы в виде прямоугольника для

каждого интерактивного процесса на нижнем уровне диаг-

раммы;

• определяется структура меню. Для этого интерактивные

процессы группируются в меню (либо так же, как в модели

процессов, либо другим способом

—

по функциональным

признакам или в зависимости от принадлежности к опреде-

ленным объектам);

• формы с меню изображаются над формами, соответствую-

щими интерактивным процессам,

соединяются с ними пе-

реходами в виде стрелок, направленных от меню к формам.

• определяется верхняя форма (главная форма приложения),

связывающая все формы с меню.

Техника

структурных

карт (схем) используется на стадии

проектирования для описания структурных схем профамм. При

этом наиболее часто применяются

две

техники:

структурные кар-

ты Константайна, предназначенные для описания отношений

между модулями, и структурные карты Джексона, предназначен-

ные для описания внутренней структуры модулей, являющихся

базовыми строительными блоками профаммной системы.

нас-

тоящее время структурные карты применяются сравнительно

редко.

процессе проектирования базы данных концептуальная мо-

дель данных преобразуется в схему реляционной базы данных,

основными элементами которой являются таблицы и столбцы.

Для описания схемы базы данных может использоваться отдель-

ная фафическая нотация.

Для формирования схемы базы данных из ERM применяется

Офаниченный набор правил преобразования сущностей и связей

между ними.

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

Правило

Каждая простая сущность, не являющаяся подти-

пом и не имеющая подтипов, превращается в таблицу Имя сущ-

ности становится именем таблицы.

Правило

Каждый атрибут становится возможным столбцом

тем же

именем; может выбираться

более

точный формат. Столб-

цы,

соответствующие необязательным атрибутам, могут содер-

жать неопределенные значения; столбцы, соответствующие обя-

зательным атрибутам, - не могут.

Анализ и проектирование программного обеспечения 287

Правило

Уникальный идентификатор сущности превраща-

ется в первичный ключ таблицы. Если имеется несколько аль-

тернативных уникальных идентификаторов, выбирается наибо-

лее используемый. Если уникальный идентификатор является

относительным, то в качестве первичного ключа используется

копия уникального идентификатора сущности, находящейся на

дальнем конце связи, в которой данная сущность играет роль за-

висимой.

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

Правило

Если тип бинарной связи

— один-к-одному

и класс

принадлежности обеих сущностей является обязательным, то из

двух связанных сущностей формируется одна таблица. Первич-

ным ключом этой таблицы может быть идентификатор любой из

двух сущностей.

Правило

Если тип бинарной связи

— один-к-одному

и класс

принадлежности одной сущности является обязательным, а дру-

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

дую сущность), при этом идентификатор каждой сущности дол-

жен служить первичным ключом соответствующей таблицы.

Кроме того, идентификатор сущности, для которой класс при-

надлежности является необязательным, добавляется в качестве

атрибута в таблицу, выделенную для сущности с обязательным

классом принадлежности.

Правило

J. Если тип бинарной связи

— один-к-одному

и класс

принадлежности ни одной сущности не является обязательным,

то формируются три таблицы: по одной для каждой сущности

(при этом идентификатор каждой сущности должен служить пер-

вичным ключом соответствующей таблицы) и одна для связи.

Таблица связи включает в качестве атрибутов по одному иденти-

фикатору от каждой сущности.

Правило

Если тип бинарной связи

— один-ко-многим и

класс

принадлежности сущности с мощностью «п» является обязатель-

ным, то формируются две таблицы (под каждую сущность), при

этом идентификатор каждой сущности должен служить первич-

ным ключом соответствующей таблицы. Кроме того, идентифи-

катор сущности с мощностью

«1»

добавляется в качестве атрибу-

та

таблицу, выделенную для сущности с мощностью «п».

Правило

Если тип бинарной связи

— один-ко-многим

и класс

принадлежности сущности с мощностью «п» является необяза-

тельным, см. правило 3.

288 Глава 4

Правило

Если тип бинарной связи

—

многие-ко-многим,

см.

правило 3.

Правило

Для представления Л^-арной связи требуется 7V+1

таблица. Например, в случае тернарной связи формируются че-

тыре таблицы, по одной для каждой сущности и одна для связи.

Таблица связи будет иметь среди своих атрибутов ключи от каж-

дой сущности.

Правило

5. Для связи «супертип-подтип» возможны два спо-

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

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

б) для каждого подтипа

—

отдельная таблица.

При применении способа (а) для супертипа создается табли-

ца,

а для

подтипов могут создаваться представления

(view).

таб-

лицу добавляется по крайней мере один столбец, содержащий

код

типа;

он становится частью первичного ключа.

При использовании способа (б) для каждого подтипа супер-

тип воссоздается с помощью операции объединения (UNION)

—

из всех таблиц подтипов выбираются общие столбцы

—

столбцы

супертипа.

Преимущества способа

(а):

все

данные хранятся вместе, обес-

печивается легкий доступ к супертипу и подтипам, требуется

меньше таблиц.

Недостатки способа (а): усложняется логика работы с раз-

ными наборами столбцов и ограничениями, возможно сниже-

ние производительности (в связи с блокировками общей табли-

цы),

столбцы подтипов должны допускать неопределенные зна-

чения.

Преимущества способа

(б):

наглядное соответствие схемы БД

и ERM, приложения работают только с нужными таблицами.

Недостатки способа

(б):

формируется слишком

много

таблиц,

возможно снижение производительности при выполнении опе-

рации объединения, невозможны модификации супертипа.

4.2.

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

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

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

Анализ и проектирование программного обеспечения

289

Построение диаграмм системных процессов

диаграмм последовательностей экранных форм

Результаты перехода от модели бизнес-процессов к модели

системных процессов представлены на рис. 4.1—4.2. На диаграм-

ме системных процессов первого уровня вместо отдельных про-

цессов введены процессоры

—

компьютеры, на которых выпол-

няются соответствующие процессы.

Рис.

4.1.

Диафамма системных процессов нулевого уровня

290

Глава 4

Отчет

пациентах

для администрации

больницы

Сервер

БД

системы приема

{Администрация

больницы

Обзор

курсов

лечения

ПК врача

База данных

системы приема

Рис. 4.2. Диаграмма системных процессов первого уровня

Результаты построения абстрактной модели пользователь-

ского интерфейса системы, отражающей последовательность

появления экранных форм

приложении, представлены

на

рис.

4.3.