Л10. ДИАГРАММЫ КЛАССОВ и КООПЕРАЦИИ
1. Подходы к выделению
классов и объектов
Объектно-ориентированные модели разрабатывают с использованием следующих абстракций:
объектов,
отношений,
классов объектов.
Отношения устанавливают роли каждого объекта проекта во взаимодействии, их отличия и сходство. Отношения между объектами можно определить, сформулировав ответы на следующие вопросы:
принадлежит ли объект другому объекту?
является ли объект разновидностью другого объекта?
использует ли объект другой объект?
Выработаны следующие подходы к выделению классов и объектов (см. рис.):
классический,
анализ поведения,
анализ предметной области,
анализ вариантов,
неформальное описание,
структурный анализ.
Классический подход опирается на классическую категоризацию. Этот подход связан с именами таких ученых как Шлаер, Меллор, Росс, Коуд, Йордон.
Источниками классов и объектов являются:
осязаемые предметы,
роли,
события,
взаимодействия.
Рис. Основные подходы к выделению классов и объектов
Кандидатами в классы и объекты могут быть:
люди,
места,
предметы,
организации и организационные единицы,
концепции,
события,
структуры,
устройства,
разыгрываемые роли.
Анализ поведения представляет такой подход к объектно-ориентированному анализу, при котором классы и объекты выделяют не на основе осязаемых предметов, а на основе анализа динамики поведения проектируемой системы.
Этот подход в большей степени опирается на концептуальную кластеризацию: в классы объединяются группы объектов, демонстрирующих сходное поведение.
Анализ предметной области представляет такой способ выделения классов и объектов (операции и связей), при котором используют мнение экспертов предметной области об их важности и учитывают имеющийся опыт (результаты) практической разработки подобных систем.
Кандидатами в классы и объекты проектируемой системы выбирают наиболее важные объекты предметной области с точки зрения экспертов.
По мнению Мура и Байлини в анализе предметной области должны присутствовать следующие этапы:
построение модели предметной области при консультациях с экспертами в этой области;
изучение существующих в данной области систем;
определение сходства и различий между системами при участии экспертов;
уточнение модели предметной области для приспособления к нуждам конкретной системы.
В роли эксперта может выступать обычный пользователь, хорошо представляющий требования к системе.
Анализ вариантов (сценариев) - это подход, который впервые сформулировал Джекобсон, определивший вариант как частный пример или образец использования, то есть сценарий, начинающийся с того, что пользователь системы инициирует операцию или последовательность взаимосвязанных событий.
В этом виде анализа пользователи, эксперты и разработчики перечисляют сценарии, наиболее существенные для работы системы, не углубляясь в детали.
Затем сценарии подвергаются детальной проработке. Здесь выделяют объекты, которые участвуют в сценарии, устанавливают обязанности каждого объекта и их взаимодействие.
Набор сценариев может быть расширен для проработки исключительных ситуаций и побочных эффектов.
Неформальное описание. Согласно этому подходу надо описать часть или всю задачу, для автоматизации решения которой разрабатывается программа, на естественном для человека языке, а потом подчеркнуть существительные и глаголы. При таком неформальном описании имена существительные будут кандидатами на роль классов, а глаголы могут стать именами операций (связей).
Структурный анализ более согласуется с процедурно-ориентированными методологиями разработки.
После проведения структурного анализа получают модель программного комплекса, описанную диаграммами потоков данных и другими средствами структурного анализа (диаграммы "сущность - связь", диаграммы переходов состояний, словари данных). Исходя из этой модели, можно приступить к определению осмысленных классов и объектов.
В UML после выделения классов и их связей можно приступить к построению диаграммы классов.
2. Диаграммы классов
Диаграмма классов – основной способ отображения статической структуры разрабатываемой системы в терминологии классов объектно-ориентированного программирования.
Диаграмма классов может содержать:
классы,
интерфейсы,
пакеты,
отношения
и даже отдельные экземпляры классификаторов, такие как объекты и связи.
Когда говорят о данной диаграмме, имеют в виду статическую структурную модель проектируемой системы, т. е. графическое представление таких структурных взаимосвязей логической модели системы, которые не зависят от времени.
Рис. Пример диаграммы классов книжного Интернет-магазина
ДК связаны с дисциплиной анализа и используются в дисциплине проектирования.
ДК является основным логическим представлением (Logical View) модели.
Классы
Класс (class) — абстрактное описание множества однородных объектов (экземпляров), имеющих одинаковые атрибуты, операции и отношения с объектами других классов.
Рис. Варианты графического изображения класса на диаграмме классов
В секциях могут указываться имя класса, атрибуты и операции класса.
Если секции атрибутов и операций пусты, в обозначении класса они должны быть выделены горизонтальной линией, с тем чтобы отличить класс от других элементов языка UML (рекомендуется).
Имена классов образуют словарь предметной области при ООАП.
Класс может иметь или не иметь экземпляров (объектов). В зависимости от этого в языке UML различают конкретные и абстрактные классы.
В языке UML принято общее соглашение о том, что любой текст, относящийся к абстрактному элементу, записывается курсивом.
В VS.NET статические классы изображаются прямоугольником с пунктирным контуром.
Атрибуты класса (поля, переменные)
Общий формат записи отдельного атрибута класса следующий:
<квантор видимости> <имя атрибута> [кратность] :
<тип атрибута> = <исходное значение>
{строка-свойств}
Видимость (visibility) — качественная характеристика описания элементов класса, характеризующая потенциальную возможность других объектов модели оказывать влияние на отдельные аспекты поведения данного класса.
Видимость:
символ "+" – public
символ "#" – protected
символ "-" – private
символ "~" – package (C#: internal) виден только в пакете, в котором определен.
Кратность атрибута:
[ нижняя граница .. верхняя граница, ...]
[ нижняя граница .. * ]
[ * ] - от 0 до неопределенное число
[число]
По умолчанию – 1.
Тип: string, int и т.д.
Подчеркивание строки атрибута означает static.
Знак «/» перед именем атрибута указывает на то, что данный атрибут является производным от некоторого другого атрибута этого же класса.
Строка-свойств:
1. Если в строке имеется знак равенства, то вся запись Строка-свойств служит для обозначения фиксированного значения соответствующего атрибута для класса в целом, которое должны принимать все вновь создаваемые экземпляры класса без исключения. Это значение принимается за исходное значение атрибута, которое не может быть переопределено в последующем.
2. Changeable – изменяемый, addOnly – только добавление, frozen – заморожен (значения нельзя изменять). Операции класса (методы)
Общий формат записи отдельной операции:
<квантор видимости> <имя операции>(список параметров):
<выражение типа возвращаемого значения>
{строка-свойство}
Список параметров является перечнем разделенных запятой формальных параметров, каждый из которых, в свою очередь, может быть представлен в следующем виде:
<направление параметра> <имя параметра>: <выражение типа> =
<значение параметра по умолчанию>
Направление параметра : in, out или inout.
In - по умолчанию.
Имена операций, так же как атрибутов и параметров, записываются со строчной (малой) буквы, а их типы параметров — с заглавной (большой) буквы.
При этом обязательной частью строки записи операции является наличие имени операции и круглых скобок.
Расширение языка UML
Язык UML содержит два специальных расширения:
- профиль для процесса разработки программного обеспечения (The UML Profile for Software Development Processes) и
- профиль для бизнес-моделирования (The UML Profile for Business Modeling).
Моделирование программного обеспечения:
Рис. Графическое изображение классов для моделирования программного обеспечения
У каждой диаграммы классов должен быть хотя бы один управляющий класс, контролирующий последовательность выполнения действий этого варианта использования.
Как правило, данный класс является активным и инициирует рассылку множества сообщений другим классам модели.
Класс-сущность (entity class) — пассивный класс, информация о котором должна храниться постоянно и не уничтожаться с выключением системы.
Пример: отдельная таблица базы данных.
Граничный класс (boundary class) — класс, который располагается на границе системы с внешней средой и непосредственно взаимодействует с актерами, но является составной частью системы.
Пример: Элементы управления в окне.