Инструментальные средства. Диаграмма классов. Class diag

1.

Инструментальные ср-ва
Диаграмма классов. Class diag.
Авторы:
Добрынин А.С.
2015-2018
Сибирский государственный
индустриальный университет
г. Новокузнецк.

2.

Назначение диаграммы
1) Основная диаграммы описания объектно-ориентированных
систем.
2) Прояснение архитектуры сложной объектно-ориентированной
системы.
3) Позволяет описывать статический состав классов и
отношения между ними с использованием типовых
отношений.
4) Важно понимать, что все отношения можно описать в виде
конечного множества типовых связей.
5) Структуру зависимостей в системе гораздо проще
воспринимать, глядя на диаграмму, а не на исходный код
системы.
6) Диаграмму могут использовать системные архитекторы и
интеграторы для прояснения компонентов объектной
системы при разработке системы.
7) Основная логическая модель (диаграмма) для ИТ-систем.

3.

Обозначения классов
Многократно повторим, класс обозначается прямоугольником,
см. пример, ниже.

4.

Интерфейсы, статические классы
Стереотип – это элемент модели UML,используемый для
уточнения семантики (смысла) модели. Чтобы разработчик не
парил себе мозг, что там нарисовано на самом деле. Для
обозначения интерфейсов будем использовать текстовые
стереотипы, см. ниже.
Все методы и переменные класса со стереотипом «utility»
статические. Буч (Booch) называет их служебными.
4

5.

Абстрактные классы
Абстрактные классы содержат “виртуальные” методы. Для
обозначения абстрактных классов в UML используется курсив или
свойство {abstract}.
5

6.

Изображение классов
Имя класса
Имя класса
Имя класса
атрибуты класса
Имя класса
операции класса
операции класса
Видимость
Shape
+origin : Point
+move(p:Point)
+resize(s:Scale)
+disply()
#invalidateRegion()
Responsibilities
- - manage shape state
- - handle basic shape
transformations
Имя класса
Атрибуты
Операции
Сигнатура
операции
Дополнительная
секция
6

7.

Атрибуты и методы класса
Атрибуты.
Закрытые, открытые и защищенные поля и свойства
классов.
private int Age; //Поле, целое число.
protected List<string> Words; //Поле, список строк.
public IComparable<int> C; //Поле, любая коллекция
(список, стек и т.д.), которая реализует интерфейс
Iсomparable<T>
public string loginName {get; set;} //Свойство
Операции. Это методы внутри класса.
(аналог процедуры. Не возвр. значение)
public void summa(int a, int b) { Console.Write(a+b); }
(аналог функции. Возвращает значение)
public int summa(int a, int b) { return a+b ; }
public void nothing() { Assert.AreEqual(summa(2,2),4); } 7

8.

Отношение между классами
Таких отношений – конечное множество, если быть
точным, 5 штук.
1) Ассоциация.
2) Обобщение.
3) Агрегирование и композиция (частный случай
ассоциации).
4) Реализация (частный случай обобщения).
5) Зависимость.
Что используется на практике чаще всего?
Отношение ассоциации и его частные случаи
(агрегирование и композиция) используется в более
чем 60% связей
8

9.

Отношение ассоциации
1) Является важнейшим и фундаментальным в ООП и
UML. Самое распространенное на диаграммах UML
(более 50% связей).
2) Обозначает наличие логической связи между
классами.
Она
может
быть
однонаправленной,
двунаправленной или не иметь специфического
направления. Концы ассоциации могут иметь имена,
обозначающие роли, которые играют классы друг для
друга. Кроме направления и имени с ассоциацией
связано понятие мощности. Можно выделить следующие
разновидности мощности ассоциаций, которые широко
применяются в ER – диаграммах при создании моделей
данных:
1) Один к одному;
2) Один ко многим;
3) Многие ко многим;
Пример ассоциации показан на рисунке ниже.
9

10.

Отношение ассоциации
Ассоциация между классами чаще всего представляют переменные
экземпляра, в которых хранятся ссылки на объекты других классов
(объекты других классов). Возможно три варианта для ассоциации:
1) Экземпляр класса содержит ссылку на объект другого класса
public class Room { public Picture myRoomPict {get; set; } }
///в классе “комната” висит (одна) картина.
2) Экземпляр класса содержит массив объектов другого класса
public class Room { private Picture[] myRoomPicts = null; }
То же самое, но будет в итоге “упаковано” в object..
public class Room { private ArrayList myRoomPicts = null; }
////в классе “комната” висит (несколько) картин.
3) Экземпляр класса содержит (список, стек, словарь) объектов
другого класса. То же самое, что и (2) за исключением нюансов.
public class Room { private List<Picture> myRoomPicts = null; }
public class Room { private Stack<Picture> myRoomPicts=null; }
//////Через интерфейсы
public class Room { private IList <Picture> myRoomPicts = null; }
public class Room { private Idictionary<int,Picture> myRoomPicts=null;}
///в классе “комната” висит (несколько) картин.
10

11.

Отношение ассоциации
Представьте себе смартфон (SmartPhone), у которого
есть 23 кнопки (допустим, старый Nokia N97). Ниже
показана ассоциация между классами SmartPhone и
Button и код класса.
Со смартфоном связано 23 кнопки. А что, если их должно
быть просто МНОГО? В С# такое можно сделать
типизированной коллекцией (generic). В телефонной
книге очень много телефонных номеров.
Можно сказать «Phonebook имеет много PhoneNumber».
Или Phonebook связан с множеством PhoneNumber.
11

12.

Отношение наследования
Отношение наследования (обобщения) – это отношение
“специализация/обобщение”
при
котором
объект
специализированного
элемента
(потомок)
вместо
объекта обобщенного элемента (родителя или предка).
Таким образом, потомок наследует поведение своего
родителя. Графическое представление обобщения
представлено ниже.
В UML нужно очень внимательно относится к остриям
стрелок, это играет значение. Рассмотрим пример
наследования
для
типовых
звеньев
теории
автоматического управления. У всех звеньев есть
коэффициент передачи, его можно объявить в базовом
классе и наследовать от него инерционное звено первого
порядка.
12

13.

Отношение наследования
Отношение наследования (обобщения) – это отношение
“специализация/обобщение”
при
котором
объект
специализированного
элемента
(потомок)
вместо
объекта обобщенного элемента (родителя или предка).
Таким образом, потомок наследует поведение своего
родителя. Графическое представление обобщения
представлено ниже.
В UML нужно очень внимательно относится к остриям
стрелок, это играет значение. Рассмотрим пример
наследования
для
типовых
звеньев
теории
автоматического управления. У всех звеньев есть
коэффициент передачи, его можно объявить в базовом
классе и наследовать от него инерционное звено первого
порядка.
13

14.

Отношение реализации
Реализация это тоже самое, что и наследование за
исключением,
что
подразумевается
реализация
интерфейса. Другими словами, базовым классом является
интерфейс, от него происходит наследование.
Интерфейс это умозрительное понятие, которое
содержит методы, но не имеет их реализации, поскольку
их не может быть. Интерфейс – это контракт для
абстракций! Допустим, имеется класс – “птица” что это?
Птица умеет летать, бегать, но как она это делает, не
описывается. Летают и бегают – конкретные птицы,
воробей, голубь. А просто птица – это умозрительное
понятие, чтобы писать ее реализацию в коде, нужно
сначала конкретизировать, какая птица. “Птица”-это
фантазия, абстракция. Таким образом, все интерфейсы
содержат просто методы без их реализации. Это
называется полиморфизмом, но объяснять бесполезно,
нужны годы практического программирования.
В чем смысл? Допустим, на сцене в игре летит стая птиц,
они все разные. В цикле, для всех объектов, которые
реализуют интерфейс IBird будет вызван метод fly()
foreach(IBird any_bird in <контейнер_птиц>) {any_bird.fly();}
14

15.

Отношение реализации
Отношение реализации представлено ниже.
Пример
отношения
реализации
отношению к птице показан ниже.
интерфейса,
по
Если есть некоторый метод, который, допустим красит
птицу в определенный цвет, он может красть любую птицу,
которая реализует интерфейс IBird
public class crazy_bird_service
{ public void
set_bird_color(Color color, IBird <любая реализация> ) { };
/// В частности, объект bloodwing…
}
Интерфейс – это контракт, который определяет поведение
для группы абстракций. Но они должны его наследовать! 15

16.

Агрегирование и композиция.
Оба случая – частные случаи ассоциации. Это значит, что
в программном коде изменений по сравнению с
ассоциацией будет не много. Реализация неотличима от
ассоциации общего вида, см. рисунок ниже.
Композиция, в свою очередь это частный случай
агрегирования, когда часть сильно связана с целым. Лист
может оторваться от дерева и улететь. Композиция
«сильно» связана с целым, а точнее она без целого не
существует. Отображается закрашенным ромбом.
При композиции целый (укрупненный объект) несет
ответственность за время жизни своей части. Если
укрупненный объект уничтожается, часть должна быть
уничтожена вместе с ним.
В С# это “трудно” контролировать, в С++ за уничтожение
объекта отвечает деструктор.
16

17.

Примеры моделей.
Примитивы и фигуры
17

18.

Примеры моделей.
Цветы и насекомые
18

19.

Примеры моделей.
Торговая сделка.
19

20.

Практические задания.
а) Постройте, нарисуйте class диаграммы с
использованием case – инструментария (Software
Architect, Visual UML, Rational Rose, MS Visual Studio, MS
Visio)
б) Создайте WPF приложение с реализацией на языке
С# всех классов, указанных в диаграмме. Построение
работающего решения не обязательно.
1) Постройте диаграмму классов для предметной
области торгов на аукционе, пригодную для реализации
на языке высокого уровня (С#, Java, WPF)
2) Постройте диаграмму классов для программы –
графического редактора, пригодную для реализации на
языке высокого уровня (С#, Java , WPF)
3) Постройте диаграмму классов для приложения игры
в боулинг, пригодную для реализации на языке высокого
уровня (С#, Java , WPF)
4) Постройте диаграмму классов для приложения
мультимедийного проигрывателя, пригодную для
реализации на языке высокого уровня (С#, Java , WPF)
5) Постройте диаграмму классов для приложения игры
«крестики - нолики», пригодную для реализации на
20
языке высокого уровня (С#, Java , WPF)

21.

Практические задания.
а) Постройте, нарисуйте class диаграммы с
использованием case – инструментария (Software
Architect, Visual UML, Rational Rose, MS Visual Studio, MS
Visio)
б) Создайте WPF приложение с реализацией на языке
С# всех классов, указанных в диаграмме. Построение
работающего решения не обязательно.
1) Постройте диаграмму классов для предметной
области торгов на аукционе, пригодную для реализации
на языке высокого уровня (С#, Java , WPF)
2) Постройте диаграмму классов для программы –
графического редактора, пригодную для реализации на
языке высокого уровня (С#, Java , WPF)
3) Постройте диаграмму классов для приложения игры
в боулинг, пригодную для реализации на языке высокого
уровня (С#, Java , WPF)
4) Постройте диаграмму классов для приложения
мультимедийного проигрывателя, пригодную для
реализации на языке высокого уровня (С#, Java , WPF)
5) Постройте диаграмму классов для приложения игры
«крестики - нолики», пригодную для реализации на
21
языке высокого уровня (С#, Java , WPF)

22.

Практические задания.
Продолжение.
6) Постройте диаграмму классов для приложения
«Интернет-магазин», пригодную для реализации на
языке высокого уровня (С#, Java , WPF)
7) Постройте диаграмму классов для приложения
«Электронный документооборот», пригодную для
реализации на языке высокого уровня (С#, Java , WPF).
8) Постройте диаграмму классов для приложения
«Рулетка», пригодную для реализации на языке
высокого уровня (С#, Java , WPF).
9) Постройте диаграмму классов для приложения
«Фотоальбом», пригодную для реализации на языке
высокого уровня (С#, Java , WPF).
10) Постройте диаграмму классов для моделирования
абстракции типа “иерархия”, “дерево” пригодную для
реализации на языке высокого уровня (С#, Java , WPF).
11) Постройте диаграмму классов для моделирования
абстракции типа “сеть”, “граф” пригодную для
реализации на языке высокого уровня (С#, Java , WPF).
12) Постройте диаграмму классов программы
автоматизации «Деканат» управления ВУЗом
22

23.

Спасибо за
внимание!
23