Файл: Конспект лекций для студентов специальности i 53 01 07 Информационные технологии и управление в технических системах.pdf

44
описать более подробно, указав имена и типы параметров, их значения,
принятые по умолчанию, а также тип возвращаемого значения (рис. 42).
Рис. 42 Операции
При изображении класса необязательно сразу показывать все его атрибуты и операции. Их может быть много, однако для данного представления системы лишь небольшое подмножество атрибутов и операций имеет значение. В это случае класс сворачивают, и изображают только некоторые из атрибутов и операций, а дополнительные атрибуты или операции обозначают многоточием.
Для лучшей организации списков атрибутов и операций можно снабдить каждую группу дополнительным описанием (стереотипами).
Обязанности класса – это своего рода контракт, которому он должен подчиняться. Атрибуты и операции являются свойствами, посредством которых выполняются обязанности класса. Например, класс FraudAgent (агент по предотвращению мошенничества), который встречается в приложениях по обработке кредитных карточек, отвечает за оценку платежных требований –
законные, подозрительные или подложные (рис. 43). Моделирование классов лучше всего начинать с определения обязанностей сущностей, которые входят в словарь системы. Число обязанностей класса может быть произвольным, но на практике хорошо структурированный класс имеет по меньшей мере одну обязанность; с другой стороны, их не должно быть и слишком много. При уточнении модели обязанности класса преобразуются в совокупность атрибутов и операций, которые должны наилучшим образом обеспечить их выполнение.
Рис. 43 Обязанности
Классы редко существуют автономно, они взаимодействуют между собой.
Это значит, что, при моделировании системы, необходимо идентифицировать не только сущности, составляющие ее словарь, но и описать, как они соотносятся друг с другом. Существует основные три вида отношений между классами:
зависимости, обобщения, ассоциации (рис. 44).

45
Рис. 44 Отношения
Кроме перечисленных отношений на диаграммах классов также применяются отношения агрегации и композиции.
Отношение агрегации применяется для представления системных взаимосвязей типа "часть-целое". Например, деление персонального компьютера на составные части: системный блок, монитор, клавиатуру и мышь (рис. 45).
Рис. 45 Отношения агрегации
Отношение композиции является частным случаем агрегации. Оно служит для выделения специальной формы отношения "часть-целое", при которой составляющие части в некотором смысле находятся внутри целого. Специфика взаимосвязи между ними заключается в том, что части не могут выступать в отрыве от целого, т.е. с уничтожением целого уничтожаются и все его составные части. Например – окно интерфейса программы, состоящее из строки заголовка,
кнопок управления размером, полос прокрутки, главного меню, рабочей области и строки состояния (рис. 46).
Рис. 46 Отношения композиции
Кроме описанных выше элементов, на диаграмме классов также могут присутствовать примечания, дополнения, стереотипы, помеченные значения,

46
ограничения.
Стереотипом называют расширение словаря UML, позволяющее создавать новые виды строительных блоков, аналогичные существующим, но специфичные для данной задачи. Стереотип представлен в виде имени,
заключенного в кавычки и расположенного над именем другого элемента. С
помощью стереотипа создаётся новый строительный блок, который напоминает существующий, но обладает новыми свойствами (рис. 47).
Рис. 47 Стереотипы
Помеченное значение позволяет включать новую информацию в спецификацию элемента. Например, при создании нескольких версий ПО
необходимо отслеживать версию и автора какой-нибудь важной абстракции. Ни версия, ни автор не являются первичными концепциями UML, но их можно добавить к любому блоку, например, к классу, задавая для него новые помеченные значения (рис. 48).
Рис. 48 Помеченное значение
Ограничение – это расширение семантики элемента UML, позволяющее создавать новые или изменять существующие правила (рис. 49).

47
Рис. 49 Ограничения
Каждый элемент языка UML имеет свою семантику. С помощью ограничений можно создавать новую семантику или изменять существующие семантические правила. Например, на рис. 49 показано, что информация,
передаваемая между классами “Портфель” и “Банковский счёт”, зашифрована.
При моделировании систем реального времени часто используются временные и пространственные ограничения.
5.2 Прямое и обратное проектирование
Основным результатом деятельности группы разработчиков являются не диаграммы, а программное обеспечение, поэтому модели и основанные на них реализации должны соответствовать друг другу с минимальными затратами по поддержанию синхронизации между ними. Чаще всего разработанные модели преобразуются в программный код. Хотя UML не определяет конкретного способа отображения на какой-либо объектно-ориентированный язык, он проектировался с учетом этого требования. В наибольшей степени это относится к диаграммам классов, содержание которых без труда отображается на такие известные объектно-ориентированные языки программирования, как Java, C++,
ObjectPascal, Visual Basic и др.
Прямым проектированием (Forward engineering) называется процесс преобразования модели в код путем отображения на некоторый язык реализации.
Процесс прямого проектирования приводит к потере информации, поскольку написанные на языке UML модели семантически богаче любого из существующих объектно-ориентированных языков. Фактически именно это различие и является основной причиной необходимости моделей. Некоторые структурные свойства системы, такие как кооперации, или ее поведенческие особенности, например взаимодействия, могут быть легко визуализированы в
UML, но в чистом коде наглядность теряется.
При прямом проектировании диаграммы классов следует учитывать, что так как модели зависят от семантики выбранного языка программирования,
вероятно, придется отказаться от использования некоторых возможностей UML.
Например, язык UML допускает множественное наследование, а язык

48
программирования Smalltalk – только одиночное. В связи с этим можно запретить авторам моделей пользоваться множественным наследованием. Для специфицирования языка программирования применяются помеченные значения как на уровне индивидуальных классов (если нужна тонкая настройка), так и на более высоком уровне, например для пакетов или коопераций.
На рис. 50 изображена диаграмма классов, на которой проиллюстрирована реализация образца цепочки обязанностей. В данном примере представлены три класса: Client (Клиент), EventHandler (ОбработчикСобытий) и GUIEventHandler
(ОбработчикСобытийГИП). Первые два из них являются абстрактными, а последний – конкретным. Класс EventHandler содержит обычную для данного образца операцию handleRequest (ОбработатьЗапрос), хотя в рассматриваемом случае было добавлено два скрытых атрибута.
Рис. 50 Прямое проектирование
Определенное для каждого класса помеченное значение показывает, что они будут преобразованы в код на языке Java. Прямое проектирование в данном случае легко осуществимо с помощью специального инструмента. Так, для класса EventHandler будет сгенерирован следующий код:
public abstract class EventHandler {
EventHandler successor;
private Integer currentEventID;
private String source;
EventHandler() {}
public void handleRequest () {}
}
Обратным проектированием (Reverse engineering) называется процесс преобразования в модель кода, записанного на каком-либо языке программирования. В результате этого процесса вы получаете огромный объем информации, часть которой находится на более низком уровне детализации, чем необходимо для построения полезных моделей. В то же время обратное проектирование никогда не бывает полным. Как уже упоминалось, прямое проектирование ведет к потере информации, так что полностью восстановить модель на основе кода не удастся, если только инструментальные средства не

49
включали в комментариях к исходному тексту информацию, выходящую за пределы семантики языка реализации.
Обратное проектирование диаграммы классов осуществляется следующим образом:
1. Идентифицируются правила для преобразования из выбранного языка реализации. Это можно сделать на уровне проекта или организации в целом.
2. С помощью инструментального средства указывается код, который будет подвергнут обратному проектированию.
3. Используя инструментальные средства, создаётся диаграмма классов путем опроса полученной модели. Следует начать, например, с одного или нескольких классов, а затем расширить диаграмму, следуя вдоль некоторых отношений или добавив соседние классы. При этом можно раскрыть или спрятать детали содержания диаграммы в зависимости от ваших намерений.
5.3 Примеры диаграмм классов
На рис. 51 показана совокупность классов, взятых из информационной системы вуза. Этот рисунок содержит достаточное количество деталей для конструирования физической базы данных. В нижней части диаграммы расположены классы Студент, Курс и Преподаватель. Между классами Студент и Курс есть ассоциация, показывающая, что студенты могут посещать курсы.
Более того, каждый студент может посещать любое количество курсов и на каждый курс может записаться любое число студентов.
Два класса (Вуз и Факультет) содержат несколько операций, позволяющих манипулировать их частями. Эти операции включены из-за их важности для поддержания целостности данных (например, добавление или удаление
Факультета затрагивает целый ряд других объектов).
Рис. 51 Диаграмма классов для информационной системы ВУЗа
Существует много других операций, которые стоило бы рассмотреть при

50
проектировании этих и иных классов, например запрос о необходимых предварительных знаниях перед зачислением студента на курс. Но это, скорее,
бизнес-правила, а не операции по поддержанию целостности данных, поэтому лучше располагать их на более высоком уровне абстракции.
На рис. 52 представлен пример диаграммы классов структуры компании.
Рис. 52 Диаграмма классов
6 Диаграммы состояний (statechart diagram)
Главное предназначение этой диаграммы
– описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его жизненного цикла.
Чаще всего диаграммы состояний используются для описания поведения отдельных экземпляров классов (объектов), но они также могут быть применены для спецификации функциональности других компонентов моделей, таких как варианты использования, актеры, подсистемы, операции и методы.
Диаграмма состояний по существу является графом специального вида,
который представляет некоторый автомат. Вершинами этого графа являются состояния и некоторые другие типы элементов автомата (псевдосостояния),
которые изображаются соответствующими графическими символами. Дуги

51
графа служат для обозначения переходов из состояния в состояние. Для понимания семантики конкретной диаграммы состояний необходимо представлять не только особенности поведения моделируемой сущности, но и знать общие сведения по теории автоматов.
6.1. Автоматы
Автомат (state machine) в языке UML представляет собой некоторый формализм для моделирования поведения элементов модели и системы в целом.
Автомат описывает поведение отдельного объекта в форме последовательности состояний, которые охватывают все этапы его жизненного цикла, начиная от создания объекта и заканчивая его уничтожением. Каждая диаграмма состояний представляет некоторый автомат.
Простейшим примером визуального представления состояний и переходов на основе формализма автоматов может служить ситуация с исправностью технического устройства, такого как компьютер. В этом случае вводятся в рассмотрение два самых общих состояния: "исправен" и "неисправен" и два перехода: "выход из строя" и "ремонт". Графически эта информация может быть представлена в виде изображенной ниже диаграммы состояний компьютера
(рис. 53).
Рис. 53 Простейший пример диаграммы состояний для технического устройства типа компьютер
Основными понятиями, входящими в формализм автомата, являются состояние и переход. Главное различие между ними заключается в том, что длительность нахождения системы в отдельном состоянии существенно превышает время, которое затрачивается на переход из одного состояния в другое. Предполагается, что в пределе время перехода из одного состояния в другое равно нулю (если дополнительно ничего не сказано). Другими словами,
переход объекта из состояния в состояние происходит мгновенно.
В языке UML под состоянием понимается абстрактный метакласс,
используемый для моделирования отдельной ситуации, в течение которой имеет место выполнение некоторого условия. Состояние может быть задано в виде набора конкретных значений атрибутов класса или объекта, при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта.

52
Рис. 54 Графическое изображение состояний на диаграмме состояний
Состояние на диаграмме изображается прямоугольником со скругленными вершинами (рис. 54). Этот прямоугольник, в свою очередь, может быть разделен на две секции горизонтальной линией. Если указана лишь одна секция, то в ней записывается только имя состояния (рис. 54, а). В противном случае в первой из них записывается имя состояния, а во второй – список некоторых внутренних действий или переходов в данном состоянии (рис. 54, б).
Начальное состояние представляет собой частный случай состояния,
которое не содержит никаких внутренних действий. В этом состоянии находится объект по умолчанию в начальный момент времени. Графически начальное состояние в языке UML обозначается в виде закрашенного кружка (рис. 55, а), из которого может только выходить стрелка, соответствующая переходу.
Рис. 55 Графическое изображение начального и конечного состояний на диаграмме состояний
Конечное (финальное) состояние представляет собой частный случай состояния, которое также не содержит никаких внутренних действий . В этом состоянии будет находиться объект по умолчанию после завершения работы автомата в конечный момент времени. Графически конечное состояние в языке
UML обозначается в виде закрашенного кружка, помещенного в окружность
(рис. 55, б), в которую может только входить стрелка, соответствующая переходу.
Простой переход (simple transition) представляет собой отношение между двумя последовательными состояниями, которое указывает на факт смены одного состояния другим. Пребывание моделируемого объекта в первом состоянии может сопровождаться выполнением некоторых действий, а переход во второе состояние будет возможен после завершения этих действий, а также после удовлетворения некоторых дополнительных условий. На диаграмме состояний переход изображается сплошной линией со стрелкой, которая направлена в целевое состояние (рис. 56).

53
Рис. 56 Диаграмма состояний для моделирования почтовой программы-клиента
6.2 Пример диаграммы состояний
Рассмотрим пример диаграммы состояний для моделирования поведения банкомата (рис. 57).
Рис. 57 Диаграмма состояний для моделирования поведения банкомата
Следует заметить, что в разрабатываемой модели диаграмма состояний является единственной и описывает поведение системы управления банкоматом в целом. Главное достоинство данной диаграммы состояний – возможность моделировать условный характер реализации всех вариантов использования в форме изменения отдельных состояний разрабатываемой системы. Иногда разработку диаграммы состояний, особенно в условиях дефицита времени,
отпущенного на выполнение проекта, опускают, т.к. часто происходит