Этапы проектирования ИС с использованием UML

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

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

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

видов деятельности,
для описания бизнес-объектов:
модели бизнес-объектов;
диаграммы последовательностей.

На этапе создания логической

модели ИС описание требований к системе задается в виде модели и описания системных прецедентов.

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

На этапе создания физической модели детальное проектирование выполняется с использованием диаграмм классов, диаграмм компонентов, диаграмм развертывания.

ИС

Диаграммы прецедентов (диаграммы вариантов использования, use case diagrams) – это

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

Диаграммы видов деятельности (диаграммы деятельностей, activity diagrams) – модель бизнес-процесса или поведения системы в рамках прецедента.

Диаграммы взаимодействия (interaction diagrams) – модель процесса обмена сообщениями между объектами, представляется в виде диаграмм последовательностей (sequence diagrams) или кооперативных диаграмм (collaboration diagrams).

ее компонентов при переходе из одного состояния в другое.

Диаграммы классов

(class diagrams) – логическая модель базовой структуры системы, отражает статическую структуру системы и связи между ее элементами.

Диаграммы базы данных (database diagrams) — модель структуры базы данных, отображает таблицы, столбцы, ограничения и т.п.

размещение баз данных, приложений и интерфейсов ИС.

Диаграммы развертывания (диаграммы размещения,

deployment diagrams) – модель физической архитектуры системы, отображает аппаратную конфигурацию ИС.

бизнес-процессы с точки зрения внешнего пользователя, т.е. отражает взгляд на

деятельность организации из вне.

Общая диаграмма деятельности медицинского центра по обслуживанию пациента

обслуживание пациента
Для включения в диаграмму выбранные прецеденты должны удовлетворять следующим критериям:

прецедент должен описывать, ЧТО нужно

делать, а не КАК ;

прецедент должен описывать действия с точки зрения ИСПОЛНИТЕЛЯ ;

прецедент должен возвращать исполнителю некоторое СООБЩЕНИЕ ;

последовательность действий внутри прецедента должна представлять собой одну НЕДЕЛИМУЮ цепочку.

для прецедента "Оказание медицинской помощи"

"Ответ на запрос"

на запрос"
Разработка модели бизнес-объектов

данных в виде диаграммы классов

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

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

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

Источником данных для создания модели системных прецедентов являются разработанные на предыдущем этапе бизнес-модели.

прецедентов
включает следующие разделы:

заголовок (название прецедента, ответственный за исполнение, дата создания

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

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

на новые диаграммы.

прецедентов

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

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

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

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

общий предварительный проект для всех команд разработчиков (проектировщиков баз данных, разработчиков приложений, системных архитекторов и пр.)

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

UML
Диаграмма классов "Защита доступа"

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

в элементы моделей базы данных и приложений:

классы отображаются в таблицы;
атрибуты – в столбцы;
типы – в типы данных используемой СУБД;
ассоциации – в связи между таблицами (ассоциации "многие-ко-многим" преобразуются в ассоциации "один-ко-многим" посредством создания дополнительных таблиц связей)
приложения – в отдельные классы с окончательно определенными и связанными с данными в базе методами и атрибутами.

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

таблица, включающая столбцы, соответствующие атрибутам класса.

Отображение классов подтипов в таблицы осуществляется одним из стандартных способов:

одна таблица на класс;

одна таблица на суперкласс;

одна таблица на иерархию.

UML
Преобразование иерархии в таблицу

UML
Разработка проекта базы данных осуществляется с использованием специального UML-профиля (Profile

for Database Design), который включает следующие основные компоненты диаграмм:

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

с использованием UML

технических средствах разрабатываемой системы

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

компонент – самостоятельный

физический модуль системы;

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

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

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

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

развертывания ИС

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

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

Суть функционального разбиения может быть выражена формулой: " Программа = Данные + Алгоритмы ". При функциональной декомпозиции программной системы ее структура описывается блок-схемами, узлы которых представляют собой "обрабатывающие центры" (функции), а связи между узлами описывают движение данных.

При объектном разбиении в системе выделяются "активные сущности" – объекты (или компоненты), которые взаимодействуют друг с другом, обмениваясь сообщениями и выполняя соответствующие функции (методы) объекта.

следующем:

процессы и данные существуют отдельно друг от друга
(как

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

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

заключается в объектной декомпозиции.

При этом статическая структура системы описывается

в терминах объектов и связей между ними,

а

поведение системы описывается в терминах обмена сообщениями между объектами.

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

базируется на устойчивых формах.

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