П1.4. Фрагменты этапа Проектирование

Этап Проектирование включает шаги Диаграммы анализа, Диаграммы последовательности, Диаграмма классов этапа проектирования, Структура базы данных. Начнем с шага Диаграммы анализа с иллюстративными фрагментами для книжного Internet-магазина.

Диаграммы анализа

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

· объекты, участвующие в варианте использования,

· способы взаимодействия этих объектов.

Диаграммы анализа облегчают выявления объектов, которые необходимы для выполнения варианта использования. В процессе ICONIX диаграммы анализа служат связующим звеном между анализом (что) и проектированием (как), а создание этого связующего звена можно трактовать как предварительное проектирование. Связь между анализом и проектированием показана на рис. П.1.24. 

    Диаграмма           Диаграмма           Диаграмма

       вариантов             анализа                 последовательности

       использования

 

              Рис. П.1.24. Связь между анализом и проектированием

Диаграмма анализа объясняет, почему процесс разработки ПО такой сложный.         Дело в том, что разработчики начинают с уровня требований, на котором размышляют только о том, что нужно пользователям от системы, не задумываясь о деталях реализации, а затем меняют угол зрения, сосредотачиваясь исключительно на проектировании. По существу, диаграмма анализа в UML – это диаграмма классов, хотя она ближе к диаграммам кооперации, на которых показываются не классы, а их экземпляры (объекты).    В настоящее время это диаграмма классов, на которой вместо обычных в UML символов классов изображаются пиктограммы трех видов (см. рис. П.1.25).

              Рис. П.1.25 Символы на диаграммах анализа

 

 

Граничные объекты актеры используют для взаимодействия с системой.     Сущностные объекты – это обычно объекты из модели предметной области. Управляющие объекты (обычно называются контроллерами, так как им ничего не соответствует в реальном мире) выполняют функции «клея» между граничными и сущностными объектами.

Существуют четыре основных правила:

1. Актеры могут общаться только с граничными объектами.

2. Граничные объекты могут общаться только с актерами и контроллерами.

3. Сущностные объекты могут общаться только с контроллерами.

4. Контроллеры могут общаться с граничными объектами, сущностными объектами и другими контроллерами, но не с актерами.

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

 

Разрешено

Запрещено

Разрешено

Запрещено

Рис. П.1.26. Правила построения диаграмм анализа

 

Разделение объектов диаграммы анализа на три вида (граничные, сущностные, управляющие) позволяет предположить, что будущая программная система может иметь трехуровневую архитектуру, которая предписывает необходимость четкого разделения программной системы на три уровня:

· уровень представления (интерфейса),

· уровень приложения (бизнес-логики),

· уровень хранения данных (базы данных).

К граничным объектам (уровень представления) относятся: экранные формы, диалоговые окна, меню. Если у разработчиков есть прототип графического интерфейса пользователя, то граничные объекты легко можно извлечь из текстов вариантов использования.

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

Управляющие объекты (уровень приложения) не только выполняют функции «клея» между граничными и сущностными объектами, но и заключают в себе логику приложения или бизнес-логику (например, вычисление чего-то, получение списка чего-либо, удаление или создание чего-то). Согласно правилам построения диаграмм анализа не допускаются на уровне представления вызовы методов и инициализации у классов, относящихся к уровню приложения; исключением являются лишь контроллеры, которые должны передавать информацию нужным классам. Следовательно, если необходимо что-то посчитать, получить список чего-либо, что-то удалить или создать, то сначала нужно с помощью контроллера уведомить об этом уровень приложения, а уж затем классы уровня приложения сделают то, что необходимо.

На рис. П.1.27. приведен иллюстративный пример диаграммы анализа для варианта использования Изменить Содержимое Корзины

 

Заказ

Изменяет количество

Страница Просмотра Корзины

Удалить Товар

Отобразить

Обновить количество и стоимость

Изменить стоимость

Корзина (из Модели Предметной Области)

нажимает кнопку Обновить

 Рис. П.1.27. Диаграмма анализа варианта использования Изменить Содержимое Корзины

Теперь перейдем к шагу Диаграммы последовательности