2532

Этап 5. Анализ требований и предварительное проектирование си-

стемы

Основные задачи этапа:

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

требованиям;

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

работчиков (проектировщиков баз данных, разработчиков прило-

жений, системных архитекторов и пр.)

Основным инструментом на данном этапе являются диаграммы классов системы, которые строятся на основе разработанной модели си-

стемных прецедентов. Одновременно на этом этапе уточняются диаграм-

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

дит к изменениям в составе объектов и диаграммах классов. Это есте-

ственное отражение средствами UML итеративного процесса разработки системы.

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

стемных прецедентов. Они содержат описание этих объектов в виде клас-

сов и описание взаимодействия между классами. Диаграмма классов, опи-

сывающая процедуры защиты доступа к данным, приведена на рис. 2.39.

1..1

Рисунок 2.39. Диаграмма классов «Защита доступа» Таким образом, в результате этого этапа проектирования появляется

достаточно подробное описание состава и функций проектируемой систе-

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

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

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

чика.

Этап 6. Разработка модели базы данных и приложения

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

классы отображаются в таблицы;

атрибуты – в столбцы;

типы – в типы данных используемой СУБД;

ассоциации – в связи между таблицами («один – к одному», «мно-

гие – ко многим» и «один – ко многим»);

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

Разработка проекта базы данных осуществляется с использованием специального UML-профиля (Profile for Database Design), который включа-

ет следующие основные компоненты диаграмм:

таблица – набор записей базы данных по определенному объекту;

столбец – элемент таблицы, содержащий значения одного из ат-

рибутов таблицы;

первичный ключ (РК) – атрибут, однозначно идентифицирующий строку таблицы;

внешний ключ (FK) – один или группа атрибутов одной таблицы,

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

лицы;

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

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

дая из таблиц может существовать независимо от другой;

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

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

домен – множество допустимых значений для столбца таблицы.

На рис. 2.41 представлен фрагмент модели базы данных – две табли-

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

ствовать без «Студента».

Рисунок 2.41. Фрагмент модели базы данных Результатом этапа является детальное описание проекта базы данных

и приложений системы.

Этап 7. Проектирование физической реализации системы

На этом этапе проектирования модели баз данных и приложений до-

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

рабатываемой системы. На рис. 2.42 приведено изображение разделения таблицы «Студент» на три экстента (<<Tablespace>>) в соответствии с первой буквой фамилии студента.

Рисунок 2.42. Экстенты таблицы «Студент»

Основными понятиями UML, которые используются на данном эта-

пе, являются следующие:

компонент – самостоятельный физический модуль системы;

зависимость – связь между двумя элементами, при которой изме-

нения в одном элементе вызывают изменения другого элемента;

устройство – узел, не обрабатывающий данные;

процессор – узел, выполняющий обработку данных;

соединение – связь между устройствами и процессорами.

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

Рисунок 2.43. Фрагмент диаграммы развертывания ИС

В результате получаем готовую ИС, созданную при помощи UML.

Визуализированные средства UML модели ИС позволяют наладить плодо-

творное взаимодействие между заказчиками, пользователями и командой разработчиков. Они обеспечивают ясность представления выбранных ар-

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

Выводы. Таким образом, при проектировании сложной ИС она раз-

деляется на части, и каждая из них затем исследуется и создается отдельно.

В настоящее время используются (и рассмотрены в данном разделе) два различных способа такого разбиения ИС на подсистемы: структурное (или функциональное) разбиение и объектная (компонентная) декомпозиция.

С позиций проектирования ИС суть функционального разбиения может быть выражена известной формулой: «Програм-

ма = Данные + Алгоритмы». При функциональной декомпозиции про-

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

представляют собой «обрабатывающие центры» (функции), а связи между узлами описывают движение данных.

При объектном разбиении в системе выделяются «активные сущно-

сти» – объекты (или компоненты), которые взаимодействуют друг с дру-

гом, обмениваясь сообщениями и выполняя соответствующие функции

(методы) объекта.

Если при проектировании ИС разбивается на объекты, то для ее ви-

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

ектирования положена функциональная декомпозиция ИС, то UML не ну-

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

В то же время, при выборе подхода к разработке ИС следует учиты-

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

ющих технологиях управления проектированием систем, сложность, мас-

штабы и функциональность которых постоянно возрастают. Они хорошо приспособлены для решения таких часто возникающих при создании си-

стем задач как: физическое перераспределение вычислений и данных,

обеспечение параллелизма вычислений, репликация БД, обеспечение без-

опасности доступа к ИС, оптимизация балансировки нагрузки ИС, устой-

чивость к сбоям и т.п. Визуализированные средствами UML модели ИС позволяют наладить плодотворное взаимодействие между заказчиками,

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

2.2.4. Методология RAD

Методология создания ИС, основанная на использовании средств быстрой разработки приложений, получила в последнее время широкое распространение и приобрела название методологии быстрой разработки приложений (Rapid Application Development, RAD). Данная методология

охватывает все этапы жизненного цикла современных информационных систем.

Методология RAD – это комплекс специальных инструментальных средств, позволяющих оперировать с определенным набором графических объектов, функционально отображающих отдельные информационные компоненты приложений. Основные принципы методологии RAD можно свести к следующим:

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

полное завершение работ на каждом из этапов жизненного цикла не обязательно;

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

щими пользователями в процессе разработки ИС;

применение САSЕ-средств и средств быстрой разработки прило-

жений;

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

использование прототипов приложений, позволяющих полнее вы-

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

осуществление тестирования и развитие проекта одновременно с разработкой;

обеспечение грамотного руководства разработкой системы, чет-

кого планирования и контроль выполнения работ, выполняемых немногочисленной и хорошо управляемой командой профессио-

налов.

Фазы жизненного цикла в рамках методологии RAD. При исполь-

зовании методологии быстрой разработки приложений жизненный цикл

ИС состоит из четырех фаз:

анализ и планирование требований;

процесс проектирования ИС;

процесс построения ИС;

фаза внедрения ИС.

Ограничения методологии RAD. Применение методологии RAD

наиболее эффективно при создании сравнительно небольших систем, раз-

рабатываемых для конкретного заказчика.

Методология RAD не подходит для создания:

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

ставляющих собой совокупность типовых элементов ИС;

сложных расчетных программ, операционных систем и программ управления сложными инженерно-техническими объектами, то есть программ, требующих написания большого объема уникаль-

ного кода;

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

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

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

тростанциями. Это обусловлено тем, что итеративный подход, яв-

ляющийся одной из основ RAD, предполагает, что первые версии системы не будут полностью работоспособными, что в данном случае может привести к серьезнейшим катастрофам.

2.2.5. Разработка интерфейса ИС

Еще один класс задач, решаемых при проектировании информаци-

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