Язык моделирования UML

Лекция №7. Язык моделирования UML

1. Основные понятия языка UML

2. Пример использования языка UML

1. Основные понятия языка UML

В настоящее время в процессе разработки объектно-ориентированных программных систем широко используются модели документирования, предлагаемые UML:

• на этапе анализа и уточнения спецификаций - модель использования;

• на этапе логического и физического проектирования - логическую мо­дель, модель реализации и модель процессов;

• на этапе реализации при планировании размещения компонентов - мо­дель развертывания.

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

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

Модель реализации показывает реальную компоновку про­граммных модулей.

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

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

Для того чтобы продемонстрировать некоторые особенности разработки программного обеспечения с использованием UML, рассмотрим относитель­но сложный пример.

2. Пример использования языка UML

Условие задачи. Разработать программу, которая строит на экране компьютера графики функций вида y=f(x) и обеспечивает возможность просмотра результатов вычислений в виде таблицы.

Дополнительные требования:

1) исходными параметрами должны быть: интервал исследования функции, ко­личество вычисляемых точек и множество функций;

2) предусмотреть возможность вывода в одной области нескольких графиков функций;

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

4) предусмотреть возможность расширения функций программного продукта.

Модель использования. Определим возможные варианты использования раз­рабатываемой программы. Для этого выделим характерные процедуры применения программы пользователем (рис. 2.14).

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

Выполним описание основных вариантов использования для рассматриваемого примера.

Рис. 2.14. Диаграмма вариантов использования

Название варианта Просмотр результатов вычислений

Цель Просмотр значений аргументов и функций

Действующие лица Пользователь

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

Тип варианта Основной

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

Действия пользователя 1. Запускает режим просмотра результатов вычислений 3. Дает команду выдать следующую порцию информации. 5. Дает команду выхода из режима просмотра.

Отклик системы 2. Выводит первую порцию информации, которая может быть отображена в за­данной области вывода. 4. Выдает очередную порцию информации. 6. Выходит из режима просмотра.

Альтернатива отклика системы:

4. Если информации больше нет, то система выходит из режима просмотра.

Название варианта Просмотр графиков функций

Цель Отображение графиков зависимостей выбранных функций на интервале исследования

Действующие лица Пользователь

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

Тип варианта Основной

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

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

функция — аналитическое выражение, значение аргумента, значение функции;

таблица - область вывода, количество значений, множество значений аргу­ментов и функций, интервал исследования, строка значений (номер точки, значение аргумента и значение функции), комментарии;

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

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

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

Если исходить из принципа минимизации количества классов, то количество классов может быть равно количеству основных объектов предметной области зада­чи. В нашем примере минимальное число классов может быть равно трем: Функция, Таблица, График. В чистом виде такой подход не обеспечивает минимизацию кода программы, поэтому целесообразно ввести вспомогательные объекты.

Проанализировав результаты декомпозиции, можно увидеть, что вспомогатель­ный объект Область вывода является составной частью объектов Таблица и График. В связи с этим объект Область вывода целесообразно описать в виде отдельного класса, а статические и динамические его свойства могут быть наследованы класса­ми Таблица и График. Альтернативой наследованию в данном случае может быть композиция или агрегация (наполнение). Предпочтение отдадим наследованию, так как композиция и агрегация предполагают более длинный программный код и созда­ние экземпляров класса Область вывода от одного и более, а в данном случае в этом нет необходимости.

Анализируя вспомогательные объекты, можно увидеть, что значения аргумен­тов и значения функции также являются общими. Наследование здесь использовать нецелесообразно, поскольку оно автоматически подразумевает отношение «один к одному», а чтобы построить график или вывести значения, необходимо несколько экземпляров значений аргументов и функции. Одним из возможных решений явля­ется объединение значений аргументов и функции в одной структуре и обеспечение возможности динамического создания и удаления этой структуры, т. е. описание зна­чений аргументов и функций в виде класса Список значений. При этом появляется возможность создания множества экземпляров такого класса, что упрощает реализа­цию вывода в одной области нескольких графиков. Основные классы Таблица и Гра­фик будут использовать экземпляры значений, а также создавать и уничтожать эти экземпляры. Соответственно, классы Таблица и График должны иметь поля-ссылки на класс Список значений, т. е. будут связаны с ним отношением агрегации.

Объект Функция можно описать в виде абстрактного класса, в котором инкап­сулированы общие поля и методы, используемые в конкретных представлениях

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

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

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

Логическая модель. В процессе логического проектирования определяем мно­жество атрибутов и операций классов. Для этого еще раз проанализируем сценарии и построим диаграммы последовательностей действий. Указанный вид диаграммы позволяет отображать развернутое во времени взаимодействие объектов в процессе выполнения программой различных действий.

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

Аналогично строим диаграмму последовательности действий для сценария Просмотр графиков функций (рис. 2.17). В отличие от предыдущего сценария в дан-

Рис. 2.15. Контекстная диаграмма классов

Рис. 2.17. Диаграмма последовательности действий сценария Просмотр графиков функций при наложении фиксированных осей

Рис. 2.18. Диаграмма последовательности действий сценария Просмотр графиков функций при наложении плавающих осей

ном случае для каждой функции должен создаваться свой объект Список значений. Следовательно, операция Создать список должна вызываться многократно, что и по­казано на диаграмме символом «*». Аналогично в процессе выполнения сценария многократно должны выполняться операции получения значений и уничтожения. Кроме того, при построении графиков появляется дополнительная операция Нало­жить оси, которая по-разному выполняется для графика с фиксированными и плава­ющими осями: при выводе фиксированных осей не происходит обращения к списку значений, а при выводе плавающих - происходит (рис. 2.18).

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

Аналогично определив списки полей других классов, получаем уточненную ди­аграмму классов, которая приведена на рис. 2.19.

Модель реализации. Для решаемой задачи можно предложить следующую схему компоновки:

Рис. 2.19. Уточненная диаграмма классов программы

• описание классов помещаем в отдельной библиотеке (появится возможность защитить поля и методы классов);

• в основной программе объявляем экземпляры классов, инициализируем объ­екты, вызываем основные методы обработки и уничтожаем объекты после заверше­ния работы;

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

Рис. 2.20. Диаграмма компоновки

На рис. 2.20 представлена модель реализации разработанной программы в виде диаграммы компоновки. Текст программы полностью приведен в прил. 2.

При необходимости возможности программы могут быть расширены. Напри­мер, можно добавить меню, которое сделает программу более гибкой.