Основные идеи объектно-ориентированного программирования

На этапах анализа и проектирования получают модели:

1.74M

Category:

programming

Диаграммы UML

1. Диаграммы UML

2. Основные идеи объектно-ориентированного программирования

– Программа представляет собой модель некоторого реального
процесса, части реального мира; модель содержит не все признаки и
свойства представляемой ею части реального мира, а только те, которые
существенны для разрабатываемой программной системы
– Модель реального мира или его части может быть описана как
совокупность взаимодействующих между собой объектов
– Объект описывается набором атрибутов (свойств), значения
которых определяют состояние объекта, и набором операций (действий),
которые может выполнять объект
– Взаимодействие между объектами осуществляется посылкой
специальных сообщений от одного объекта к другому; сообщение,
полученное объектом, может потребовать выполнения определенных
действий, например изменения состояния объекта
– Для описания объектов, имеющих один и тот же набор атрибутов и
способных выполнять один и тот же набор операций, вводится понятие
класса
2

3. Этапы разработки программы

Постановка задачи
Анализ предметной области
Проектирование
Реализация
Тестирование и интеграция
3

4. Разработка программного обеспечения

• Постановка задачи – создание общей концепции программы
• Анализ – создание объектно-ориентированной (ОО) модели
предметной области. Включает: анализ требований (т.е.
исследование требований к системе) и объектный анализ
(исследование объектов предметной области). Этап анализа
состоит в исследовании системных требований и проблемы, а
не в поисках путей ее решения.
• Проектирование — разработка ОО модели системы ПО
(системной архитектуры) с учетом системных требований.
Включает: архитектурное и детализированное
проектирование.
• Реализация — написание программы на языке
программирования.
4

5. На этапах анализа и проектирования получают модели:

• Функциональная модель системы описывает совокупность
выполняемых системой функций.
• Информационная модель отражает структуры данных – их
состав и взаимосвязи.
• Поведенческая модель описывает информационные процессы
(динамику функционирования), в ней фигурируют такие
категории, как состояние системы, событие, переход из одного
состояния в другое, условия перехода, последовательность
событий, осуществляется привязка ко времени.
• Структурная модель характеризует построение системы –
состав подсистем, их взаимосвязи.
5

6.

Unified Modeling Language (UML) —
язык моделирования
Используется язык UML — графический язык
моделирования, предназначенный для:
• спецификации,
• визуализации,
• проектирования,
• документирования
всех артефактов, создаваемых при разработке
программных систем
6

7.

Конструктивные блоки UML
В UML задействованы три типа блоков:
• Сущность (Things)
• Отношение (Relationships)
• Диаграмма (Diagrams)
Cущности являются основой модели, отношения
обеспечивают их привязку друг к другу, а диаграммы
группируют наборы сущностей.
7

8.

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

9.

Классификация диаграмм
– Диаграммы
вариантов использования (use case
diagrams) – для моделирования бизнес-процессов и
требований к создаваемой системе)
– Диаграммы классов (class diagrams) – для
моделирования статической структуры классов системы
и связей между ними
– Диаграммы поведения системы (behavior diagrams) –
для визуализации, специфицирования, конструирования
и документирования динамических аспектов системы.
– Диаграммы реализации (implementation diagrams)
9

10.

Классификация диаграмм
Диаграммы поведения системы:
• Диаграммы взаимодействия (interaction diagrams) – для
моделирования процесса обмена сообщениями между
объектами:
o Диаграммы последовательности (sequence diagrams)
o Диаграммы кооперации (collaboration diagrams)
• Диаграммы состояний (statechart diagrams) – для
моделирования поведения объектов системы при переходе
из одного состояния в другое
• Диаграммы деятельности (activity diagrams) – для
моделирования поведения системы в рамках различных
вариантов использования, или моделирования деятельностей
10

11.

Классификация диаграмм
Диаграммы реализации:
• Диаграммы компонентов (component diagrams) –
для моделирования иерархии компонентов
(подсистем) системы
• Диаграммы развертывания (deployment diagrams) –
для моделирования физической архитектуры системы
11

12. Этапы разработки программы

• Постановка задачи
• Анализ предметной области
– Построение диаграмм вариантов использования
– Описание сценариев
– Выделение классов
• Проектирование
– Построение диаграмм классов
– Построение диаграмм последовательностей
– Построение диаграмм состояний
– Построение диаграмм компонентов
и т.д.
• Реализация
• Тестирование и интеграция
12

13. Пример

Постановка задачи:
Необходимо создать систему сбора информации с
датчиков температуры, давления, влажности и др.
Система должна включать набор датчиков и
программу, которая:
• Периодически читает информацию с датчиков
• Отображает ее на экране в специальных окнах в
числовом и графическом виде
• Сохраняет информацию в архиве
13

14. Анализ требований

Система должна позволять собирать информацию с различных
типов датчиков, работающих по разным протоколам обмена.
Следовательно, пользователь системы должен предварительно
выбрать необходимые для работы датчики, подключить их к
компьютеру и сконфигурировать программу:
Задать параметры датчиков: имя, обозначение, измеряемая
величина, единица измерения, минимальный и максимальный
пределы, протокол обмена информацией
Задать период опроса датчиков
Задать параметры архива
Задать параметры окон вывода информации: размеры, цвет,
расположение на экране, шрифт, выводимая информация
Задать параметры графиков: размеры, цвет, расположение на
экране, масштаб по горизонтали и по вертикали
14

15. Анализ требований

Пользователь запускает и останавливает периодический
опрос датчиков.
Программа должна периодически:
Опрашивать датчики в соответствии с заданным
протоколом
Выводить текущие значения датчиков в окна вывода
информации
Добавлять новые точки на графики
Добавлять информацию о текущих значениях датчиков в
архив
Обрабатывать ошибки, например: при ошибках чтения
или выходе датчиков за пределы выдавать сообщение в
окно сообщений.
15

16.

Диаграммы вариантов использования
На диаграмме прецедентов (вариантов использования)
представлены прецеденты (use case) и действующие лица (actor),
а также отношения между ними. Диаграммы прецедентов
относятся к статическому виду системы с точки зрения вариантов
использования. Они особенно важны при организации и
моделировании поведения системы.
Конфигурировать
Включить
Пользователь
16

17.

Диаграммы прецедентов
• Вариант использования представляет собой последовательность
действий (транзакций), выполняемых системой в ответ на
событие, инициируемое некоторым внешним объектом
(действующим лицом). Вариант использования описывает
типичное взаимодействие между пользователем и системой.
• Действующее лицо (actor) – это роль, которую пользователь
играет по отношению к системе. Действующие лица
представляют собой именно роли, а не конкретных людей или
наименования работ.
Ввод данных
Ввод пароля
Оператор
17

18.

Диаграммы прецедентов
Запустить периодический опрос
Обычный
пользователь
Остановить периодический опрос
Конфигурировать систему с
запросом пароля
<<extend>>
<<include>>
Задать параметры датчиков
Конфигурировать систему
Пользовательконфигуратор
<<include>>
<<include>>
Задать параметры окон вывода
Задать параметры архива
• Варианты использования могут быть связаны друг с другом тремя видами
связей: обобщением (generalization), расширением (extend) и включением
(include).
• Действующие лица могут быть связаны друг с другом с помощью связей
обобщения (generalization).
18

19.

Описание прецедента
1. Название и краткое описание.
2. Предусловия. Описываются условия, которые должны быть
выполнены, прежде чем вариант использования начнет
выполняться сам.
3. Основной успешный сценарий (основной поток событий).
4. Альтернативные сценарии (потоки событий). Каждый из
альтернативных сценариев описывается в отдельном параграфе, в
том же стиле, что и основной поток событий. Альтернативные
сценарии описывают поведение системы при любых отклонениях
от основного сценария, а также поведение в исключительных
ситуациях.
5. Постусловия. Корректно сформулированное постусловие
должно быть истинным при любом возможном сценарии
прецедента, а не только описанном в основном потоке.
6. Специальные требования. Здесь перечисляются
нефункциональные требования, имеющие непосредственное
отношение именно к этому варианту использования.
19

20.

Пример описания прецедента
Снять
деньги
Проверить
ПИН-код
Клиент
банкомата
Перевести
деньги
Имя прецедента: Проверить ПИН-код.
Краткое описание: Система проверяет введенный клиентом
ПИН-код.
Actor : Клиент банкомата.
Предусловие: Банкомат свободен, на экране сообщение «Добро
пожаловать».
20

21.

Пример описания прецедента
Основной успешный сценарий:
1. Клиент вставляет карточку в устройство считывания.
2. Если система опознает карточку, она считывает ее номер.
3. Система предлагает ввести ПИН-код.
4. Клиент набирает ПИН-код.
5. Система проверяет срок действия, а также не является ли
карточка утерянной или украденной.
6. Если карточка действительна, система сравнивает указанный
клиентом ПИН-код с тем, который хранится в системе.
7. Если ПИН-коды совпали, то система выясняет, какие счета
доступны владельцу карточки.
8. Система отображает номера счетов и предлагает клиенту на
выбор транзакции: Снять деньги, Перевести деньги.
21

22.

Пример описания прецедента
Альтернативные сценарии:
1. Если карточка не опознается системой, вернуть карточку.
2. Если система определяет, что срок действия карточки истек,
конфисковать карточку.
3. Если система устанавливает, что карточка утеряна или
украдена, конфисковать карточку.
4. Если указанный клиентом ПИН-код не совпадает с ПИН-кодом.
карточки, предложить набрать ПИН-код повторно.
5. Если клиент три раза подряд вводит неправильный ПИН-код,
конфисковать карточку.
6. Если клиент нажимает клавишу отмены, прервать транзакцию
и вернуть карточку.
Постусловие: ПИН-код клиента проверен.
.
22

23.

МОДЕРНИЗИРОВАННАЯ ДИАГРАММА ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ
Запустить периодический опрос
Обычный
Конфигурировать систему с
запросом пароля
Задать протокол MODBUS
пользователь
Остановить периодический опрос
<<extend>>
Задать протокол обмена
<<include>>
<<include>>
Задать параметры датчиков
Конфигурировать систему
Пользовательконфигуратор
<<include>>
Задать параметры
текстовых окон
<<include>>
Задать параметры
графических окон
Задать параметры архива
Задать параметры окон вывода
23

24.

ОПИСАНИЕ ПРЕЦЕДЕНТА
Задать параметры датчиков
Общее описание:
Подключение нового датчика, задание его имени, обозначения, измеряемой величины, единиц
измерения, минимального и максимального пределов измерения, протокола обмена
информацией. Изменение параметров уже подключенного датчика. Удаление датчика.
Основной успешный сценарий подключения нового датчика:
1. Пользователь нажимает кнопку Создать новый датчик.
2. Пользователь задает имя датчика.
3. Пользователь задает обозначение датчика.
4. Пользователь выбирает из списка измеряемую величину (температура, давление, влажность
и т.д.).
5. Пользователь выбирает из списка соответствующие данной измеряемой величине единицы
измерения.
6. Пользователь задает минимальный и максимальный пределы измерения в выбранных
единицах измерения.
7. Пользователь выбирает протокол обмена.
8. Пользователь задает параметры протокола обмена.
9. Пользователь нажимает кнопку Сохранить.
10. Контроллер подключает к списку датчиков созданный датчик.
Дополнительный сценарий изменения параметров датчика:
1. Пользователь выбирает из списка датчик.
2. Пользователь меняет параметры датчика (см. выше).
3. Пользователь нажимает кнопку Сохранить.
Дополнительный сценарий удаления датчика:
1. Пользователь выбирает из списка датчик.
2. Пользователь нажимает кнопку Удалить.
3. Контроллер удаляет из списка датчик.
24

25.

26.

Диаграммы классов
• Определяет типы классов системы и различного рода
статические связи, которые существуют между ними. На
диаграммах классов изображаются также атрибуты
классов, операции классов и ограничения, которые
накладываются на связи между классами.
Имя класса
Имя класса
Атрибуты
Операции
Имя класса
Атрибуты
Имя класса
Атрибуты
<<Стереотип>>
Имя класса
Атрибуты
Операции
Обязанность
Операции
Обязанность
26

27.

Диаграммы классов
• Над именем класса может стоять Стереотип класса
Стереотипы – это механизм, позволяющий разделять классы на
категории. В языке UML определены три основных стереотипа
классов: Boundary (граница), Entity (сущность) и Control (управление).
Граничными называются такие классы, которые расположены на
границе системы и всей окружающей среды. Это экранные формы,
отчеты, интерфейсы с аппаратурой и с другими системами. Каждому
взаимодействию между actor’ом и вариантом использования должен
соответствовать, по крайней мере, один граничный класс.
Классы-сущности содержат хранимую информацию. Они имеют
наибольшее значение для пользователя, и потому в их названиях
часто используют термины из предметной области.
Управляющий класс отвечает за координацию действий других
классов, но сам не несет в себе никакой функциональности, так
как остальные классы не посылают ему большого количества
сообщений. Вместо этого он сам посылает множество сообщений. Его
часто называют классом-менеджером.
Помимо упомянутых выше стереотипов можно создавать и свои
собственные.
27

28.

Диаграммы классов
• Атрибуты
Видимость Имя Атрибута [0..*] : Тип = Нач. значение
Видимость атрибута (attribute visibility):
– Public – « + ».
– Private – « – »
– Protected – « # ».
– Package or Implementation (пакетный)
# LineColor: TColor = (255,0,0)
o Имя должно быть уникальным в пределах данного класса
o Перед атрибутом может стоять стереотип
o Ограничение – произвольный текст в {} с правилами
ограничений
28

29.

Диаграммы классов
• Операции
Видимость Имя Операции (аргумент1 : тип данных
аргумента1, аргумент2 : тип данных аргумента2, ...) :
тип возвращаемого значения
+ SetUnit(val : SUnits) : void
+ Summ(a :Point, b:Point) : Point
• Обязанности – описание выполняемой классом функции
29

30.

Диаграммы классов
<< Entity >>
FilmTitle
<< PK >> Code : int
Title: String
Director: String
IsInStock : bool
Set()
Get()
Хранить
информацию о
фильме
MeasureVal
# Name : AnsiString
# Title : AnsiString
# CurrentVal : double
# MinVal : double
# MaxVal : double
# Error : SErroros
# Unit : SUnits
+ GetUnitsList() : const char**
+ GetUnitName() : const char*
+ GetUnit() : SUnits
+ SetUnit(val : SUnits) : void
+ GetType() : const char *
+ IfMinMax() : int
+ LastError() : SErrors
30

31.

Диаграммы классов
Spectrum
- Count : int
- Data[Count ]: Complex
{Count = 2n }
+ Calculate():bool
+ SetCount(n:int)
+ GetCount():int
+ SetData(arr:Complex)
+ GetData(i:int):Complex
Вычисление спектра
cигнала с помощью
БПФ
31

32.

Диаграммы классов
Интерфейсы и шаблоны
Формальные
параметры
<<interface>>
Датчик температуры
Имя шаблона
Атрибуты шаблона
Значение температуры()
Операции шаблона
32

33.

Диаграммы классов
Ассоциации между классами
• Агрегация
• Композиция
• Обобщение
• Реализация
• Зависимости
33

34.

Диаграммы классов
Ассоциации между классами
34

35.

Диаграммы классов
Агрегация и композиция
35

36.

Диаграммы классов
Обобщение
36

37.

Диаграммы классов
Реализация
<<interface>>
Датчик температуры
Значение температуры()
Резистивный
датчик температуры
Токовый
датчик температуры
Значение температуры()
Значение температуры()
37

38.

Диаграммы классов
Зависимости
Класс_Б — источник
некоторой зависимости
Класс_А — клиент этой
зависимости
Стереотипы:
<<access>> — служит для обозначения доступности открытых
атрибутов и операций класса-источника для классов-клиентов;
<<bind>> — класс-клиент может использовать некоторый шаблон
для своей последующей параметризации;
<<derive>> — атрибуты класса-клиента могут быть вычислены по
атрибутам класса-источника;
<<import>> — открытые атрибуты и операции класса-источника
становятся частью класса-клиента, как если бы они были
объявлены непосредственно в нем;
<<friend>> — дружественный класс.
38

39.

Диаграммы классов
Зависимости
T
TemplateList
Size : int = 0
Add(Val : T)
Delete(i : int)
GetSize() : int
operator[](i : int) : T
<<bind>>
<Sensors*>
ListSensors
1
1..n
Sensor
39

40.

Диаграммы классов
Лепесток
Цветок
Божья
коровка
n
Вредит
Ест
Вредитель
Маргаритка
Красная
роза
Роза
Желтая
роза
40

41.

Диаграммы классов
T
TemplateList
WindowText
ListWindows
WindowInf
1
1..n
WindowGraph
Timer
<<Actor>>
Controller
ListUnits
ListMeasureVals
ListSensors
Archive
1
Protocol
1..n
Units
MeasureVal
Sensor
FormConfig
41

42.

Диаграммы классов
MeasureVal
Name : AnsiString
Title : AnsiString
CurrentVal : double
MinVal : double
MaxVal : double
CalculateVal
Класс Вычислительный
параметр, может быть создан
при необходимости
расширить возможности
системы
ProtocolType1
ProtocolType2
Protocol
Sensor
Identificator : int
..........
Read()
ProtocolMODUS
Registr : int
COMPort : int
CodeReading : int
TemperatureSensor
PressureSensor
SUnit : Units
SUnit : Units
HumiditySensor
......
SUnit : Units
42

43.

Диаграммы взаимодействия
• Диаграммы взаимодействия (диаграммы
последовательности, диаграммы кооперации)
описывают поведение взаимодействующих групп
объектов.
• Как правило, диаграмма взаимодействия охватывает
поведение объектов в рамках только одного варианта
использования. На такой диаграмме отображается ряд
объектов и те сообщения, которыми они
обмениваются между собой.
43

44.

Диаграммы взаимодействия
• Сообщение (message) – это средство, с помощью
которого объект-отправитель запрашивает у объекта
получателя выполнение одной из его операций.
• Информационное (informative) сообщение – это
сообщение, снабжающее объект-получатель некоторой
информацией для обновления его состояния.
• Сообщение-запрос (interrogative) – это сообщение,
запрашивающее выдачу некоторой информации об
объекте-получателе.
• Императивное (imperative) сообщение – это
сообщение, запрашивающее у объекта-получателя
выполнение некоторых действий.
44

45.

Диаграммы последовательности
• Диаграммы последовательности отражают поток событий,
происходящих в рамках варианта использования.
• На диаграмме последовательности объект изображается
в виде прямоугольника, от которого вниз проведена
пунктирная вертикальная линия. Эта линия называется
линией жизни объекта. Она представляет собой фрагмент
жизненного цикла объекта в процессе взаимодействия.
• Каждое сообщение представляется в виде стрелки
между линиями жизни двух объектов.
45

46.

Снятие
клиентом
денег
со счета
46

47.

Диаграммы последовательности
: FormConfig
: Пользовательконфигуратор
: Sensor
: ListSensors
: MeasureVal
ListUnits
Выбрать тип датчика
Создать
Create()
Create()
Create()
GetListInfo()
Задать имя
Задать название
Выбрать ед. измер.
Задать пределы
Выбрать протокол
CreateProtocol()
Далее
задаются
параметры
протокола
Сохранить
Add()
47

48.

Диаграммы кооперации
• Если диаграммы последовательности упорядочены по времени,
то диаграммы кооперации больше внимания заостряют на
связях между объектами.
• На диаграмме стрелки обозначают сообщения, обмен
которыми осуществляется в рамках данного варианта
использования. Их временнáя последовательность, указывается
путем нумерации сообщений.
a: Вызывающий
абонент
1. Создать
: Соединение
: Текстовый
редактор
A:
: Принтеры
1. Выбрать
2. Печать
: Принтер
48

49.

Диаграммы кооперации
Снятие
клиентом
денег
со счета
49

50.

Диаграммы состояний
• Диаграммы состояний определяют все возможные
состояния, в которых может находиться конкретный
объект, а также процесс смены состояний объекта
в результате наступления некоторых событий.
начальное состояние
конечное состояние
Выход из строя
Исправен
Неисправен
Ремонт
50

51.

Диаграммы состояний
Имя состояния
Имя состояния
Список внутренних
действий в данном
состоянии
Список внутренних действий:
Общий вид:
Метка действия / выражение действия
Метки:
Entry
Exit
Do
Include
51

52.

Диаграммы состояний
Переходы
• Сигнатура события [сторожевое условие] выражение действия
Ожидание
Наж.лев.кн. (коорд.)
[коорд. в обл. объекта]
Выделить объект
Выполнение
действия над
объектом
52

53.

Диаграммы состояний
Подсостояния
53

54.

Диаграммы состояний
Подсостояния
54

55.

Диаграммы состояний
Начальная
инициализация
системы, чтение
конфигурации из
реестра
Запуск программы
Сохранение
конфигурации
Инициализация
do/ WriteConfiguration
do/ ReadConfiguration
Режим периодического опроса
Режим конфигурации
[ Выход ]
Включение
таймера
Блокировать конфигурацию
do/ EnableButtons(false)
Ожидание
нажатия кнопки
Выключение
таймера
[ Стоп ]
[ Конфигурация ]
[ Пуск ]
[ Ошибка ]
[ ОК ]
Ожидание таймера
или кнопки Стоп
Проверка конфигурации
[ OnTimer ]
do/ IsConfigCorrectly
Чтение и анализ всех
датчиков в цикле
[ Ошибка ]
Запрос
пароля
do/ ReadSensors
[ ОК ]
Разблокировать
конфигурацию
Конфигурация
системы
do/ EnableButtons(true)
Вывод информации в
цикле
do/ ViewInfo
Сохранение информации
в архиве
do/ WriteArchive
55

56.

Диаграммы деятельности
• Диаграмма деятельности - это блок-схема, которая
описывает последовательность элементарных действий.
• Диаграмма используется для детального описания
алгоритмов и операций.
• Графически диаграмма деятельности представляется в
виде графа, имеющего вершины (действия) и ребра
(переходы между действиями).
• Действие может заключаться в вызове другой операции,
посылке сигнала, создании или уничтожении объекта либо
в простом вычислении, например, значения выражения.
56

57.

Диаграммы деятельности
Начало
Конец
index = index + 1
Прочитать датчик
[index > count]
[index <= count]
Ветвление
Соединение
57

58.

Диаграммы деятельности
Нарисовать график
Разделение
Сложное действие
Символ под-деятельности
Слияние
58

59.

Диаграммы деятельности
Диаграмма деятельности для алгоритма
нахождения корней квадратного уравнения
59

60.

Параллельные потоки
Найти кофе
Засыпать кофе в
фильтр
Налить воду в
резервуар
Взять чашку
Вставить фильтр
в кофеварку
Включить
кофеварку
Сварить кофе
Налить кофе
в чашку
60

61.

Диаграммы компонентов
• Диаграммы компонентов отображают типы компонентов и
зависимости между программными компонентами,
возникающие на этапе компиляции или в процессе
выполнения программы, в частности связь файлов
исходного кода с динамическими библиотеками DLL. На
диаграммах компонентов изображается вхождение
классов и объектов в программные компоненты системы
(модули, библиотеки и т.д.).
• Каждый класс модели (или подсистема) преобразуется
в компонент исходного кода. Между отдельными
компонентами изображают зависимости,
соответствующие зависимостям на этапе компиляции
или выполнения программы.
61

62.

Диаграммы компонентов
• Компоненты исходного кода – это программные
файлы, содержащиеся внутри пакетов.
PackageLists.h
PackageLists.cpp
62

63.

Диаграммы компонентов
63

64.

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