Материал: 695_Poletajkin_A.N._Uchebno-metodicheskoe_posobie_Realizatsija_zhiznennogo_ch.1_
отношения. Если это условие выполняется, исходная последовательность действий расширяется посредством включения действий расширяющего варианта использования. Следует заметить, что условие отношения расширения проверяется лишь один раз – при первой ссылке на точку расширения, и если оно выполняется, то все зависимые прецеденты вставляются в базовый прецедент.
Обобщение представляет собой реализацию принципа наследования в ООП. Помимо вариантов использования, может также связывать два и более актера, которые могут иметь общие свойства, т.е. взаимодействовать с одним и тем же множеством вариантов использования одинаковым образом. Такая общность свойств и поведения представляется в виде отношения обобщения с другим, возможно, абстрактным прецедентом/актером, который моделирует соответствующую общность действий/ролей.
Графически отношение обобщения обозначается сплошной линией со стрелкой в форме треугольника без заливки, которая указывает на родительский прецедент или действующее лицо (рис. 4, г). Эта линия со стрелкой имеет специальное название – стрелка-обобщение, – которая используется также и в других канонических диаграммах UML. В данном примере отношение обобщения указывает на то, что вариант использования "Предоставление кредита корпоративным клиентам" есть специальный случай варианта использования "Предоставление кредита клиентам банка". Другими словами, первый прецедент является специализацией второго прецедента. При этом вариант использования "Предоставление кредита клиентам банка" называют предком или родителем по отношению к варианту использования "Предоставление кредита корпоративным клиентам", а последний прецедент называют потомком по отношению к первому прецеденту. Следует отметить, что потомок наследует все свойства поведения своего родителя, а также может обладать дополнительными особенностями поведения.
Отношение обобщения между элементами модели прецедентов применяется в том случае, когда необходимо отметить, что дочерние элементы обладают всеми особенностями поведения родительских. Дочерние актеры/прецеденты участвуют во всех отношениях родительских актеров/прецедентов. По аналогии с принципом наследования ООП, дочерние актеры/прецеденты могут наделяться новыми свойствами поведения, которые отсутствуют у их предков, а также уточнять или модифицировать наследуемые от них свойства поведения.
3.4. Модель классов
Диаграмма классов (class diagram) – диаграмма языка UML, на которой представлена совокупность декларативных или статических элементов модели, таких как классы с атрибутами и операциями, а также связывающие их отношения. Предназначена для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы, т.е. графическое
26
представление таких структурных взаимосвязей логической модели системы, которые не зависят от времени.
Класс (class) – абстрактное описание множества однородных объектов, имеющих одинаковые атрибуты, операции и отношения с объектами других классов.
Графически класс в нотации UML изображается в виде прямоугольника, который дополнительно может быть разделен горизонтальными линиями на разделы или секции (рис. 5). В этих секциях указываются имя класса, атрибуты и операции класса.
На начальных этапах разработки диаграммы отдельные классы могут обозначаться простым прямоугольником, в котором должно быть указано его имя (рис. 5, а). По мере проработки отдельных компонентов диаграммы описания классов дополняются атрибутами (рис. 5, б) и операциями (рис. 5, в). Четвертая секция (рис. 5, г) не обязательна и служит для размещения дополнительной информации справочного характера, например, об исключениях или ограничениях класса, сведения о разработчике или языке реализации класса. Предполагается, что окончательный вариант диаграммы содержит наиболее полные описания классов, которые состоят из трех или четырех секций.
Рис. 5. Варианты графического изображения класса на диаграмме
Имя класса должно быть уникальным в пределах пакета, который может содержать одну или несколько диаграмм классов. Имя указывается в самой верхней секции прямоугольника, поэтому она называется секцией имени класса. В дополнение к общему правилу именования элементов языка UML, имя класса записывается по центру секции полужирным шрифтом и должно начинаться с заглавной буквы. Рекомендуется в качестве имен классов использовать имена существительные, записанные по практическим соображениям без пробелов. Необходимо помнить, что имена классов образуют словарь предметной области при проектировании системы.
В секции имени класса могут также находиться стереотипы или ссылки на стандартные шаблоны, от которых образован данный класс и, соответственно, от которых он наследует свои свойства: атрибуты и операции.
27
В этой секции может также приводиться информация о разработчике класса и статус состояния разработки.
Атрибут (attribute) – содержательная характеристика класса, описывающая множество значений, которые могут принимать отдельные объекты этого класса. Атрибут класса служит для представления отдельного свойства или признака, который является общим для всех объектов данного класса. Атрибуты класса записываются в секции атрибутов (рис. 5, б).
Операция (operation) – это сервис, предоставляемый каждым экземпляром или объектом класса по требованию своих клиентов, в качестве которых могут выступать другие объекты, в том числе и экземпляры данного класса. Операции класса записываются в секции операций (рис. 5, в). Совокупность операций характеризует функциональный аспект поведения всех объектов данного класса, который описывается другими каноническими диаграммами UML. Имя операции представляет собой строку текста, которая используется в качестве идентификатора соответствующей операции и должна быть уникальной в пределах данного класса. Имя операции должно начинаться со строчной буквы, и, как правило, записываться без пробелов.
Идентификация классов анализа заключается в предварительном определении набора классов системы (так называемых, классов анализа) на основе описания предметной области и спецификации требований к системе. Прежде всего, выделяются основные абстракции предметной области. Способы идентификации основных абстракций аналогичны способам идентификации сущностей в модели "сущность-связь" – поиск абстракций, описывающих физические или материальные объекты, процессы и события, роли людей, организации и другие понятия предметной области. Единственным формальным способом идентификации сущностей является анализ текстовых описаний предметной области, выделение из описаний имен существительных и выбор их в качестве "кандидатов" на роль абстракций. Каждая сущность должна иметь наименование, выраженное существительным в единственном числе. Далее абстракции идентифицируются по трем типам, которые используются для уточнения семантики отдельных классов при построении различных диаграмм:
1.Управляющий класс (control class) – класс, отвечающий за координацию действий других классов на диаграмме. На каждой диаграмме классов должен быть хотя бы один управляющий класс, который контролирует последовательность выполнения действий данного варианта использования. Данный класс является активным и инициирует рассылку множества сообщений другим классам модели. Управляющий класс изображается в форме прямоугольника класса со стереотипом <<control>> в секции имени. Примеры управляющих классов: менеджер транзакций, журнал операций, координатор ресурсов, обработчик событий, обработчик ошибок, и т.п.
2.Класс-сущность (entity class) – пассивный класс, информация о котором должна храниться постоянно и не уничтожаться с выключением системы или завершением работы программы. Как правило, этот класс
28
соответствует отдельной сущности логической модели данных системы. В этом случае его атрибуты являются потенциальными полями таблицы, а операции – присоединенными или хранимыми процедурами. Этот класс пассивный и лишь принимает сообщения от других классов модели, реагируя на них посредством своих операций.
Источники выявления классов-сущностей:
ключевые абстракции, созданные в процессе архитектурного анализа,
глоссарий проекта,
описание потоков событий вариантов использования.
Класс-сущность может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом <<entity>> с секции имени класса.
3.Граничный класс (boundary class) – класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но, тем не менее, является составной частью системы.
Как правило, для каждой пары "действующее лицо – вариант использования" определяется один граничный класс. Типы граничных классов:
пользовательский интерфейс, выражающий обмен информацией с пользователем без деталей интерфейса: кнопок, списков, окон, и т.п.
системный интерфейс с надсистемой или другой системой (используемые протоколы обмена без деталей их реализации);
аппаратный интерфейс для связи с внешними техническими устройствами (аппаратные средства, протоколы, драйверы).
Граничный класс может быть изображен также стандартным образом в форме прямоугольника класса со стереотипом <<boundary>> в секции имени.
3.5. Отношения между классами
Классы вступают друг с другом в отношения. На диаграмме классов выделяют такие виды отношений: ассоциация, наследование, агрегирование и использование. При изображении конкретной связи ей можно сопоставить текстовую метку, документирующую имя этой связи и/или ее роль. Имя отношения должно быть уникально в своем контексте. Также связь может иметь по ее концам обозначения кратности (множественности) отношений между классами, некоторые из которых показаны ни рис. 6.
*неопределенное множество
1..* |
один или много |
0..1 |
ноль или 1 |
1..8 |
от 1 до 8 |
12 |
точно 12 |
{2,3,5,7,11} |
определенное множество |
ассоциация
наследование (обобщение)
агрегирование
композиция (структурный состав)
использование (зависимость)
Рис. 6. Обозначения множественности и значки отношений между классами
Значок ассоциации соединяет два класса и означает наличие семантической связи между ними. Ассоциации часто отмечаются
29
существительными (например, Выбор), описывающими природу связи. Одна пара классов может иметь одну или несколько ассоциативных связей.
Наследование представляет отношение типа "общее/частное", выглядит как значок ассоциации со стрелкой, которая указывает от подкласса к суперклассу. При этом подкласс наследует структуру и поведение своего суперкласса. Класс может иметь один (одиночное наследование), или несколько (множественное наследование) суперклассов.
Агрегирование обозначает отношение "целое/часть" и получается из значка ассоциации добавлением закрашенного кружка на конце, обозначающем агрегат. Экземпляры класса на другом конце стрелки будут в определенном смысле частями экземпляров класса-агрегата. Разрешается рефлексивная и циклическая агрегация. Агрегация не требует обязательного физического включения части в целое.
Композиция – это разновидность агрегирования с четко выраженным отношением владения, причем время жизни частей и целого совпадают. Части с нефиксированной кратностью могут быть созданы уже после создания самого композита, живут и уничтожаются вместе с ним. Также части могут быть удалены явным образом еще до уничтожения композита. Кроме того, в композитном агрегировании целое отвечает за диспозицию своих частей, то есть композит должен управлять их созданием и уничтожением.
Использование обозначает отношение типа "клиент/сервер" и изображается как ассоциация с пустым кружком на конце, соответствующем клиенту. Эта связь выражает зависимость клиента от сервера и означает, что клиент нуждается в услугах сервера, то есть операции класса-клиента вызывают операции класса-сервера или имеют сигнатуру, в которой возвращаемое значение и/или аргументы принадлежат классу сервера. Фактически отношение использования показывает, что один элемент использует другой.
Общие рекомендации по построению диаграмм классов:
использовать зависимость, только в случае, если моделируемое отношение не является структурным;
использовать обобщение, только если имеет место отношение типа "является";
располагать элементы так, чтобы свести к минимуму число пересекающиеся линий отношений;
пространственно организовывать элементы так, чтобы семантически близкие сущности располагались рядом;
-чтобы привлечь внимание к важным особенностям диаграммы, использовать примечания (комментарии) и выделение цветом;
3.6. Рациональный унифицированный процесс
Процесс построения отдельных типов диаграмм UML имеет свои особенности, которые тесно связаны с семантикой элементов этих диаграмм. Сам процесс ООП в контексте языка UML получил специальное название – рациональный унифицированный процесс (Rational Unified Process, RUP).
30