ОО Проектирование Лекция 4

1. 4. Диаграмма классов

2. Итоги 3-й лекции

Мне понятно ЧТО вы
делаете. Не могли бы вы на
конкретном примере
показать КАК вы это
делаете?
Хороший пример. А
как быть, если
обстоятельства
сложились немного
не так?
Какие из перечисленных
функций Вы считаете
следовало бы
автоматизировать?
Что вы делаете в рамках
своих служебных
обязанностей?
А как вы поступаете
в аварийной
ситуации?
Аналитик
Исполнитель

3.

4.

Иван Ильич
Специальность= санитар
Получил травму
Вася
Наложил
шину
Назначил
парацетомол
Температура=37,20
Давление= 140/90
Зафиксировал
Андрей Андреевич
Специальность= травматолог
Поставил
диагноз
Андрей
Температура=37,50
Давление= 110/60
Выписал
больничный
Принял
лекарство
Парацетомол
Поставил
диагноз
Дозировка=5мл
Форма = сироп
Света
Температура=38,10
Давление= 190/100
Поставил
диагноз Участковый врач
Назначил.
аспирин
Гена
Аспирин
Температура=36,60
Давление= 120/80
Дозировка=100 мг
Форма = таблетка
Принял
лекарство

5. Итоги 3-й лекции

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

6. 4.1. Классы. Основные понятия и нотационные соглашения

Диаграмма классов (англ. class diagram) — структурная диаграмма, демонстрирующая
общую структуру иерархии классов системы, их коопераций, атрибутов (полей), методов,
интерфейсов и взаимосвязей между ними.
Основное назначение диаграммы — описание статического представления системы,
которое, поддерживает ее функциональные требования. При этом решаются следующие
задачи:
• моделирование словаря системы;
• моделирование простых взаимодействий классов, интерфейсов, которые работают в
совокупности для формирования некоторого совместного поведения, которое не может
быть обеспечено всеми этими элементами, взятыми в отдельности;
• моделирования логической схемы базы данных.

7. 4.1. Классы. Основные понятия и нотационные соглашения

Атрибут, признак (англ. attribute) — именованный элемент (слот)
определённого типа в классе, используемый для представления
информации о моделируемой сущности. Класс может иметь любое
количество атрибутов или не иметь их вообще, каждый объект класса
обладает частными значениями своих атрибутов.
Общий формат записи атрибута класса:
<квантор видимости> <имя атрибута> [<кратность>] : <тип атрибута> =
<исходное значение> {<строка-свойство>}

8. 4.1. Классы. Основные понятия и нотационные соглашения

Видимость (англ. visibility) — качественная характеристика
описания элементов класса, характеризующая потенциальную
возможность других объектов модели оказывать влияние на
отдельные аспекты поведения данного класса.
Видимость в языке UML специфицируется с
помощью квантора видимости.
Обозначение
Стандарт
Rational Rose
Квантор видимости
+
public (открытый), открывает доступ к данному элементу любому внешнему
классификатору
-
private (закрытый), закрывает доступ к данному элементу всем внешним
классификаторам
#
protected (защищенный), ограничивает доступ к данному элементу всем
внешним классификаторам, за исключением его наследников.
~
package (пакетный) – элемент с этой областью видимости недоступен или не
виден для всех классов за пределами пакета, в котором определен класс -владелец
данного атрибута.

9. 4.1. Классы. Основные понятия и нотационные соглашения

Операция (англ. operation) - это сервис (интерфейс), предоставляемый каждым
экземпляром класса своим клиентам, в качестве которых могут выступать другие
объекты, в том числе и экземпляры данного класса . Общий формат записи
операции:
<квантор видимости> <имя операции>(список параметров):
<тип возвращаемого значения> {строка-свойство}
Метод (англ. method) - реализация операции. Описывает процедуру или функцию,
которая формирует результаты операции.

10. 4.1. Классы. Основные понятия и нотационные соглашения

Класс (англ. class) — описание множества объектов, обладающих общими атрибутами, операциями,
методами, отношениями и поведением. Класс это поименованное описание структуры данных и
поведения некоего множества объектов. Класс используют в качестве шаблона для создания
экземпляров объектов и объявления их как переменных. Результатом операции создания будет новый
экземпляр данного класса.
Классификатор ( англ. classifier) - это обобщение понятия "класс", в которое входят и другие,
сходные с классом элементы: тип данных, действующее лицо, компонент, вариант использования.
TClass
TClass
TClass
X [1..5]: Integer=(1, 3,2,5,0)
X [1..5]: Integer=(1, 3,2,5,0)
Y : Real
Y : Real
Варианты графического
изображения
<<constructor>> Init(X1 : Real)
<<destructor>> Done()
<<procedure>> SetY(Y1 : Integer)
<<procedure>> Out()

11. 4.1. Классы. Основные понятия и нотационные соглашения

Конкретный класс (англ. concrete class) — класс, на основе которого могут быть непосредственно
созданы экземпляры или объекты.
TClass
X [1..5]: Integer=(1, 3,2,5,0)
Y : Integer
Init(X1 : Real){Конструктор}
Done(){Деструктор}
SetY(Y1 : Integer)
GetY() : Real
Квантор видимости
операции
Поля (атрибуты,
свойства) класса
Процедуры и функции
(операции) класса
Элементы (члены) класса
Квантор видимости
атрибута
Имя конкретного класса

12. 4.1. Классы. Основные понятия и нотационные соглашения

Абстрактный класс (англ. abstract class) — класс, который не имеет экземпляров или объектов.
Для обозначения имени абстрактного класса используется наклонный шрифт (курсив). В
языке UML принято общее соглашение о том, что любое именование, относящееся к абстрактному
элементу, записывается курсивом.
Имя абстрактного
класса
TClass
X [1..5]: Integer=(1, 3,2,5,0)
Y : Integer
Init(X1 : Real){Конструктор}
Done(){Деструктор}
SetY(Y1 : Integer)
GetY(): Integer
Абстрактный метод

13. 4.2. Отношения. Основные понятия и нотационные соглашения

Отношение (англ. relationship) – семантическая связь между классами, дает классу
возможность узнавать об атрибутах, операциях и связях другого класса.
Основное назначение отношений – предоставление возможности одному классу
передавать сообщение другому.
Базовые отношения
Зависимость
Ассоциация
Обобщение
TClass1
TClass1
TClass1
TClass2
TClass2
TClass2

14. 4.2.1. Зависимость

Зависимость (англ. dependency) – отношение между двумя классификаторами, при котором изменение
одного элемента (поставщика) может затронуть другой элемент (клиент) или предоставить необходимую
ему информацию. Зависимость - это термин, который был введен для удобства обозначения нескольких
различных видов отношении между элементами модели.
TClass1
Поставщик
TClass2
Клиент
Зависимость всегда однонаправленная. Это самый слабый вид
отношений. Для его реализации не используются дополнительные
атрибуты. Объект класса – поставщика не может автоматически
идентифицировать объект класса – клиента. Ответственность за
этот выбор полностью в компетенции программиста.

15. 4.2.1. Зависимость

Форма редактирования абонента
ФамилияL : TLabel
ИмяL : TLabel
Форма отображения абонентов
ОтчествоL : TLabel
Список абонентов : TDBGrid
ФамилияE : TEdit
Добавить абонента : TSpidButton
ИмяE : TEdit
Изменить абонента : TSpidButton
ОтчествоE : TEdit
Клик по кнопке Добавить
Сохранить : Tbutton{ModalResult=mtOk}
Клик по кнопке Изменить
Отменить : Tbutton(ModalResult=mrCancel}
Синхронизировать
Добавить абонента : TStoredProc
Изменить абонента : TStoredProc
Клик по кнопке Сохранить

16. 4.2.1. Зависимость

procedure ФормаОтображенияАбонента.КликПоКнопкеДобавить;
begin
ФормаРедактированияАбонента.ФамилияЕ.Text := ‘’;
ФормаРедактированияАбонента.Text.ИмяЕ := ‘’;
ФормаРедактированияАбонента.Отчество.Text := ’’;
ФормаРедактированияАбонента.Tag := 0 // Форма должна будет ввести нового абонента
if ФормаРедактированияАбонента.ShowModal =mrOk then
Синхронизировать; // В Форме редактирования абонента была нажата кнопка Сохранить
end;
procedure ФормаРедактированиеАбонента.КликПоКнопкеСохранить;
begin
case Tag of
0: begin
// Добавление нового абонента
end;
1: begin
// Изменение сведений об абоненте
end;
end;

17. 4.2.2. Ассоциация

Ассоциация (англ. association) – это отношение между двумя или несколькими классификаторами,
которое описывает связи между их экземплярами посредством упорядоченной системы ссылок или
ключей. Ассоциации связывает систему воедино, обеспечивают возможность классам
взаимодействовать друг с другом. Является общим случаем композиции и агрегации. Ассоциация
может быть именованной, и на концах представляющей её линии могут быть подписаны роли,
принадлежности, индикаторы, мультипликаторы, видимости или другие свойства.
TClass1
TClass1
TClass1
TClass2
Однонаправленная
ассоциация
Двунаправленная
ассоциация
Рефлексивная
ассоциация
TClass2
TClass2

18. 4.2.2. Ассоциация

Множественность, кратность (англ. multiplicity) показывает, сколько экземпляров одного класса
взаимодействуют с помощью этой связи с одним экземпляром другого класса.
Типовые значения множественности:
Множественность
Значение
*
Много
0
Ноль
1
Один
0..*
Ноль или больше
1..*
Один или больше
0..1
Ноль или один
1..1
Ровно один
<число>
Ровно <число>
<число1>..<число2>
Между <числом1> и <числом2>
<число>..*
<число> или больше
<число 1>, <число2>
<число1> или <число2>
<число1>,<число2>..<число3> Ровно <число 1> или между
<числом2> и <числом3>
<число1>..<число2>,
Между <числом1> и <числом2> или
..<число3>..<число4>
между <числом3> и <числом4>
TClass1
1
1..*
TClass2
В отношении
ассоциации каждый
объект класса TClass1
связан с одним или
более экземпляров
класса TClass2

19. 4.2.2. Ассоциация

Роль (англ. role) - имеющее имя специфическое поведение некоторой сущности, рассматриваемой в
определенном контексте. Имя роли представляет собой строку текста рядом с
концом ассоциации для соответствующего класса. Имя роли не обязательный элемент обозначений и
может отсутствовать на диаграмме.
Роль класса Крестьянин в ассоциации
Крестьянин
Имя ассоциация Крестьянин может
иметь в собственности 0 и более
Земельных участков
владелец
1..1
Количество экземпляров
класса Крестьянин
задействованных в ассоциации
Роль класса Земельный
участок в ассоциации
Количество экземпляров класса
Земельный участок задействованных
в ассоциации
владеет
0..*
имущество
Земельный участок

20. 4.2.2.1. Простая ассоциация. Способы организации

Ассоциация в UML подразумевает лишь то, что связанные объекты обладают
достаточной информацией для организации взаимодействия. Возможность
взаимодействия означает, что объект одного класса может послать сообщение объекту
другого класса
Непосредственно с помощью
указателя
TClass2
TClass1
Y : ^TClass2
TClass1
Y : ^TClass2
TClass1
ID_TClass1: Integer
TClass2
TClass2
ID_TClass2: Integer
ID_TClass1: Integer
Посредством динамического
вычисления с помощью ключа или
другого уникального
идентификатора объекта
Посредством динамического
вычисления с помощью
указателя

21. 4.2.2.2. Агрегация. Способы организации

Агрегация (англ. aggregation) – форма ассоциации,
описывающая отношение часть-целое между агрегатом
(целое) и композитом (частное).
Агрегация встречается, когда один класс
является коллекцией или контейнером других.
Причём по умолчанию, агрегацией
называют агрегацию по ссылке, то есть когда
время существования содержащихся классов
не зависит от времени существования
содержащего их класса. Если контейнер будет
уничтожен, то его содержимое — нет.
Фонарь
целое
1
целое
1
часть 2
часть
Лампочка
целое
1
1
Батарея
часть
1
Корпус

22. 4.2.2.3. Композиция. Способы организации

Композиция (англ. composition) – более строгий вариант агрегации, при котором время
существования частей совпадает со временем существования композита.
Композит
Лампа накаливания
1
1
1
Цоколь
1
1
1
Нить накаливания
Колба
Композиция имеет жёсткую
зависимость времени
существования экземпляров
класса контейнера и
экземпляров содержащихся
классов. Если контейнер будет
уничтожен, то всё его
содержимое будет также
уничтожено.

23. 4.2.2.3. Композиция. Способы организации

Композиция (англ. composition) – более строгий вариант агрегации, при котором время
существования частей совпадает со временем существования композита (целого).
Дом
Квартира№[1..90] : Квартира
Подъезд№ {1..6} : Подъезд
1
В отличие от простой
ассоциации композиция
допускает организацию связи по
значению
1
24..90
2..6
Квартира
1
Подъезд
Подъезд №: ^Подъезд
12..15
В композиции объект семантически не может принадлежать двум
контейнерам, даже если он реализован в виде связи по ссылке

24. 4.2.2.4. Классы ассоциаций

Класс-ассоциация (англ association class) – это ассоциация, которая в то же время является и
классом. У класса-ассоциации присутствуют как свойства класса, так и свойства ассоциации.
Экземплярами класса-ассоциации являются связи, у которых есть не только ссылки на
объекты, но и значения атрибутов.
Год обучения
Учебный год
1..*
Студент
ФИО
Год обучения
1..*
Курс
№ курса
Год обучения

25. 4.3. Обобщение

Обобщение (англ. generalization) – таксономическое отношение между более общим и более
специализированным элементами. Более специализированный элемент полностью совместим с
более общим, и может содержать дополнительную информацию или функциональность.
Наследование (англ. inheritance) - специальный концептуальный механизм, посредством которого
более специальные элементы включают в себя структуру и поведение более общих элементов.
Родитель, прямой предок (англ. parent) - в отношении обобщения более общий элемент.
Прямой потомок (англ. child) – более конкретизированный элемент отношения обобщения. Прямой
потомок наследует черты своего прямого предка (и через него - дальних предков) и может при этом
объявлять свои собственные дополнительные черты. Кроме того, он наследует все отношения,
которые были у его прямого предка.

26. 4.3. Обобщение

Летательный аппарат
Воздушный шар
Самолет
Ан – 24
Вертолет
Boeing – 747
Ракета

27. 4.3. Обобщение

ClassA
ClassB
ClassC
ClassD
Потомок подчиняется принципу
подстановочности – его экземпляр
может использоваться вместо предка.
Объекты классов ClassC и ClassD
могут обмениваться сообщениями
используя связь ассоциации, которую
они унаследовали от своих предков.
Точно так же этой связью могут
пользоваться объекты классов ClassA
и ClassD, ClassB и ClassC.

28. Пример модели классов предметной области

Герой сказки
1
воздействовать
воздействовать()
0..*
Человек
пол : [мужской, женский]
+дед воздействовать() {Бить-бить} +владелец
+имущество
Жить-быть() {конструктор}
1 Плакать()
1
Курица
Имя : String =‘Ряба’
Была у них() {конструктор}
воздействовать() {снести}
кудахтать()
Яйцо
сорт[простое, золотое]
Персонаж : ^Герой сказки
снеслось() {конструктор}
Бить()
упасть и разбиться(){деструктор}
Мышь
воздействовать() {хвостиком махнуть}
бежать() {конструктор}
+баба
Хвост
махнуть()

29. 4.4. Расширение языка UML для построения моделей программного обеспечения

Стереотип (англ. stereotype) – новый вид элемента модели, созданный на основе существующего
элемента. Стереотипы могут расширять семантику классов метамодели, но не ее структуру.
Стереотипы - это механизм, позволяющий разделять классы на категории. В UML определены три
основных стереотипа: Граница, Сущность и Управление

30. 4.4. Расширение языка UML для построения моделей программного обеспечения

Пограничные классы (англ. boundary classes) – классы, которые расположены на границе
проектируемой системы и всей окружающей среды. Они включают формы, отчеты,
интерфейсы с и другими системами. Каждому взаимодействию между действующим лицом и
вариантом использования должен соответствовать по крайней мере один пограничный класс.
Чтобы найти пограничные классы, надо исследовать диаграммы вариантов использования.
Классы-сущности (англ. entity classes) содержат информацию, сохраняемую постоянно. Их
обычно можно обнаружить в потоке событий и на диаграммах взаимодействия. Они наиболее
значимы для для пользователя, и часто именуются терминами из предметной области. Как
правило,
класс-сущность
соответствует
отдельной
таблице
БД.
При
этом
его атрибуты являются полями таблицы, а операции – присоединенными или хранимыми
процедурами. Этот класс пассивный и лишь принимает сообщения от других классов модели.
Управляющие классы (англ. control classes) – это классы, отвечающие за координацию
действий других классов. Управляющий класс отвечает за координацию действий других
классов, но сам не несет в себе никакой функциональности – он просто делегирует
ответственность другим классам. Поэтому причине управляющий класс часто называют
классом-менеджером.

31.

Разработанная модель хорошо
показывает, что от нас хочет
заказчик. Но над тем как это
будет сделано в программе,
следует еще хорошо подумать.
Не менее нескольких месяцев
и еще несколько месяцев на
разработку программы,
тестирование и внедрение.
Возможно у нас скоро
Хорошо, я готовлю
появится крупный
коммерческое
заказ. Мы с этим
предложение..
справимся?
Архитектор ПО
Аналитик