Лабораторные работы (задания) / Лабораторная работа 8

.docx

Скачиваний:

174

Добавлен:

28.06.2014

Размер:

28.43 Кб

Скачать

☆

Применение UML для построения моделей анализа и проектирования

Цель работы

Изучить процесс разработки UML диаграмм с применением IBM Rational Enterprise Architect или IBM Rational Rose. Подготовить модель анализа и проектирования с применением UML.

Краткое введение

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

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

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

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

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

операционные системы всех вовлеченных машин;
используемые языки программирования;
интерфейсы и классы конкретных компонентных сред, таких как J2EE, .NET, COM или CORBA;
интерфейсы выбранных для использования систем управления базами данных, СУБД, например, Oracle или MS SQL Server;
используемые библиотеки разработки пользовательского интерфейса, такие как Windows Forms, Swing или Swt в Java, MFC, VCL или Gtk;
интерфейсы взаимодействующих систем и пр.

Рекомендации по построению диаграмм классов:

При выделении классов следует учитывать тот факт, что они являются обобщенными (укрупненными) сущностями, которые в дальнейшем подлежат уточнению и возможному разбиению на несколько более мелких классов. Можно провести аналогию между ними и накопителями данных на DFD, которые, как правило, являются крупными концептуальными объектами (совокупностями тесно взаимосвязанных таблиц), подлещами уточнению на стадии информационного проектирования с помощью одной из методологий ERD.
Для выделения классов сущностей необходимо определить все реальные либо воображаемые объекты, имеющие существенное значение для рассматриваемой предметной области, информация о которых подлежит хранению. При этом из спецификаций вариантов использования следует выделить все объекты, которые могут существовать независимо от других. Например, объект «билет» является независимой сущностью, потому что любой билет существует независимо от того, знаем мы его номер, стоимость или нет. Т. е. при выделении классов-сущностей действуют те же правила, что при построении концептуальной модели БД [14, лекция № 7]).
Для каждого актера следует предусмотреть, как минимум, один граничный класс в целях организации интерфейса между ним и системой. Аналогично для каждого класса сущности, как правило, должен быть граничный класс – ведь по каждому объекту класса сущности должна быть предусмотрена возможность просмотра, ввода и/или корректировки информации через определенную форму ввода/вывода или чтения/записи через определенный интерфейс.
Для управления, обеспечения взаимодействия и координации работы объектов, реализующих одну из функций системы (обычно, вариант использования), необходимо предусмотреть, как минимум, один управляющий класс. Как правило, взаимодействие между граничным классом и классом сущности происходит через управляющий класс.
В целях облегчения восприятия специфики связей между классами рекомендуется использовать отношения агрегации, композиции и обобщения.
При разработке диаграммы основное внимание должно быть уделено определению и детализации классов сущностей, управляющих и граничных классов, обеспечивающих взаимодействие с внешними системами. Граничные классы, обеспечивающие взаимодействие с пользователями, не требуют излишней детализации до уровня отдельного поля ввода или ниспадающего списка, так как современные среды программирования обладают богатыми возможностями по быстрому созданию пользовательского интерфейса.

Рекомендации по построению диаграмм последовательности:

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

Рекомендации по построению диаграмм кооперации:

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

Порядок выполнения работы

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

Требования

Наличиее диаграммы классов, содержащей не менее 7 классов
Наличие на диаграмме классов отношений обобщения, агрегации, композиции, ассоциации. Наличие мощностей связей. Наличие у классов атрибутов и методов.
Наличие диаграммы последовательности. Наличие разветвления на диаграмме последовательности. Наличие создаваемого и уничтожаемого объектов на диаграмме последовательности.
Наличие диаграммы кооперации
Наличие диаграммы деятельности, наличие ветвлений, распараллеливаний и синхронизаций на диаграмме деятельности. Наличие дорожек на диаграмме деятельности.
Наличие диаграммы состояний