Метод моделирования UML
Метод UML (United Modeling Language – унифицированный язык моделирования) является результатом совместной разработки специалистов программной инженерии и инженерии требований [6, 7]. Он широко используется ведущими разработчиками программного обеспечения как метод моделирования программных продуктов на всех стадиях жизненного цикла разработки программных систем.
В основу метода положена парадигма объектного подхода, при котором концептуальное моделирование проблемы происходит в терминах взаимодействия объектов:
– онтология домена определяет состав классов объектов домена, их атрибутов и взаимоотношений, а также услуг (операций), которые могут выполнять объекты классов ;
– модель поведения определяет возможные состояния объектов, инциденты, инициирующие переходы с одного состояния к другому, а также сообщения, которыми обмениваются объекты;
– модель процессов определяет действия, которые выполняют объекты.
UML концептуальная модель требований рассматривается как совокупность нотаций – диаграмм, которые визуализируют основные элементы структуры системы.
Метод UML обеспечивает эффективное представление взаимодействий между разными участниками разработки с заданием комментариев. Допускаются два вида комментариев: традиционный неформальный текст или стереотип.
Стереотип – это средство метаклассификации элемента в UML, т.е. стандартизированный комментарий элемента, который представлен какой–нибудь из диаграмм и характеризует содержание элемента диаграммы или его назначение. Они задаются на диаграммах названием, которое приводится в двойных угловых скобках (например, <<треугольник>>,<<кривая>>).
Некоторые стереотипы являются фиксированными в UML и имеют стандартные названия, например, <<актер>>, <<система>>, <<подсистема>>, <<исключительная ситуация>>, <<интерфейс>> и т.п.
Кроме того, разработчик может вводить стереотипы, типичные для своего домена, т.е.
UML разрешает расширять и адаптировать стереотипы к конкретным областям применения и облегчают понимание конкретных моделей.
Совокупность диаграмм метода отображает наиболее важные случаи функционирования системы. Рассмотрим более подробно основные диаграммы.
Диаграмма классов (Class diagram) отображает онтологию домена и по содержанию эквивалентна информационной модели метода С.Шлаера и С.Меллора. Она определяет состав классов объектов и их взаимоотношения.
Диаграмма задается иконами и связями между ними. Икона –стандартизированное и фиксированное визуальное изображение определенного понятия, имеет вид прямоугольника, который может быть разделен на две или три части. Верхняя часть – обязательная, определяет имя класса. Вторая и третья части определяют соответственно – список атрибутов класса и список операций класса.
Атрибутами могут быть типы значений в UML:
– рublic (общий), что означает операцию класса, вызванную из любой части программы любым объектом системы,
– protected (защищенный) означает операцию, вызванную лишь объектом того класса, в котором она определена или наследована,
– private (частный ) означает операцию, вызванную только объектом того класса, в котором она определена.
В то же время пользователь может определять специфические для него атрибуты. Под операцией понимается сервис, который экземпляр класса может выполнять, если к нему будет произведен соответствующий вызов. Операция имеет название и список аргументов.
Классы могут находиться в следующих отношениях или связях.
Ассоциация – взаимная зависимость между объектами разных классов, каждый из которых является равноправным ее членом. Она может обозначать количество экземпляров объектов каждого класса, которые принимают участие в связи (0 – если ни одного, 1 – если один, * – если много).
Зависимость между классами, при которой класс–клиент может использовать определенную операцию другого класса; классы могут быть связаны отношением трассирования, если один класс трансформируется во второй в результате определенного процесса ЖЦ.
Экземпляризация – зависимость между параметризированным абстрактным классом–шаблоном (template) и реальным классом, который инициирует параметры шаблона (например, контейнерные классы языка С++).
Диаграмма сценариев. Содержание и нотация этой диаграммы полностью совпадает с той, которая описана в методе Э.Джекобсона (см.п.3.).
Диаграммы моделирования поведения системы. Под поведением системы понимается множество объектов, которые обмениваются сообщениями с помощью следующих диаграмм:
– последовательность, упорядочивающей взаимодействие объектов при обмене сообщениями;
– сотрудничество, определяющей роль объектов во время их взаимодействия;
– активность, показывающей потоки управления при взаимодействии объектов;
– состояний, указывающих на динамику изменения объектов.
Диаграмма последовательности применяется для задания взаимодействия объектов. Любому из объектов сценария ставится в соответствие его линия жизни, которая отображает ход событий от его создания до разрушения. Диаграмма представляет все объекты, которые принимают участие во взаимодействии. Их порядок не имеет принципиального значения и выбирается произвольно, руководствуясь наглядностью взаимодействия.
Взаимодействие объектов контролируется событиями, которые происходят в сценарии и стимулируют посылки сообщений другому объекту.
Диаграммы сотрудничества представляют совокупность объектов, поведение которых имеет значение для достижения целей системы, и взаимоотношения тех ролей, которые важны в сотрудничестве. На этой диаграмме можно моделировать статическое взаимодействие объектов без учета фактора времени. При параметризации диаграмма представляет абстрактную схему сотрудничества – паттерн, для которого может быть создано определенное множество конкретных схем сотрудничества.
Диаграмма деятельности представляет поведение системы в виде определенных работ, которые может выполнять система или актер и эти работы могут зависеть от принятия решений в зависимости от условий, которые сложились. Эта диаграмма напоминает блок–схемы алгоритмов и программ, но в отличие от них, предусмотрена возможность выполнять параллельно несколько деятельностей и точки синхронизации их завершения.
Диаграмма состояний базируется на использовании расширенной модели конечного автомата и определяет:
– условия переходов и действия при переходе;
– действия при входе в состояние, его активности и при выходе из состояния;
– вложенные и параллельно действующие состояния.
Переход по списку данных инициирует некоторое событие. Состояние зависит от условий перехода, что подобно тому, как взаимодействуют две параллельно работающие машины, если изменение состояния одной машины влияет на другую машину.
Диаграмма реализации состоит из диаграммы компонента и диаграммы размещения.
Диаграмма компонента отображает структуру системы как композицию компонентов и связей между ними. Это граф, узлами которого являются компоненты, а дуги отображают отношения зависимости.
Диаграмма размещения задает состав физических ресурсов системы (узлов системы) и отношений между ними. Разрабатывается не только программная часть, но и необходимые аппаратные устройства, которые должны взаимодействовать с программными компонентами. В диаграмме обычно используются стереотипы: <<процессор>>, <<устройство>>, <<дисплей>>, <<память>>, <<диск>> и др.
Пакеты в UML Предусмотрен общий механизм организации некоторых элементов (объектов, классов, подсистем и т.п.) в группы. Группирование возможно начиная от системы к подсистемам разного уровня детализации, вплоть до классов. Результат группирования называется пакетом.
Пакет определяет название пространства, занимаемого элементами, которые являются его составляющими и средством ссылки на это пространство. Это важно для больших систем, которые насчитывают сотни, а иногда и тысячи элементов, и потому требуют иерархического структурирования.
Подсистема в UML рассматривается как случай пакета, который имеет самостоятельную функцию. Пакет может быть вложенным, то есть состоять из пакетов, классов, подсистем и т.п.
Объединение элементов в пакеты может происходить из разных соображений, например, если они используются совместно или созданы одним автором, или касаются определенного аспекта рассмотрения, как например, интерфейс с пользователем, устройства ввода/вывода и т.п.
На стадии реализации к одному пакету могут быть отнесены все подсистемы, которые в диаграмме размещения связаны с одним узлом.
Пакет может быть элементом конфигурации, как элемент композиции при построении системы, на которую можно ссылаться в разных диаграммах. Термином конфигурация
обозначается структура программной системы из отдельных модулей или из заведомо определенного состава их вариантов. Так, например, ОС может включать конфигурацию модулей, которые позволяют взаимодействие с разнообразными устройствами, но лишь отдельные из них подключаться к данному компьютеру с созданной версией ОС в виде конкретной конфигурации.
Среди фиксированных стереотипов для обозначения разновидностей пакета введены такие: система, прикладная система, подсистема, элемент конфигурации, составная системы, охватывающая система и др. Например, стереотип <<унаследовано>> может прибавляться к пакету, который является элементом старой версии системы и без переработки включен в новую версии системы.
