Слайд 1Технология программирования
Основы объектно-ориентированного моделирования
Слайд 2Принципы объектно-ориентированного подхода
Объектно-ориентированный анализ – это методология системного анализа, направленная
на создание моделей, близких к реальным явлениям. Требования к проектируемой
системе формируются на основе понятий (классов и объектов), составляющих словарь предметной области (термины предметной области, необходимые для рассматриваемой задачи)
Слайд 3Принципы объектно-ориентированного подхода
Объектно-ориентированное проектирование – это методология проектирования на основе
объектной декомпозиции и объектного синтеза логической модели, физической модели, статической
модели и динамической модели проектируемой системы
Логическая модель: структуры классов и структуры объектов
Физическая модель: архитектура модулей и архитектура процессов
Модели объектно-ориентированного
проектирования
Слайд 4Принципы объектно-ориентированного подхода
Объектно-ориентированное программирование – методология программирования, которая основана на
представлении программы в виде совокупности объектов, каждый из которых является
реализацией определенного класса, а классы образуют иерархию наследования
Слайд 5Принципы объектно-ориентированного подхода
Объектно-
ориентированный
анализ
Объектно-
ориентированное
проектирование
Объектно-
ориентированное
программирование
Модели
реального
мира
Модели
проектируемой
системы
Программная
система
Взаимосвязь анализа, проектирования и программирования
Слайд 6Основные понятия объектного моделирования
1. Абстрагирование
struct Point {int x, int y};
class
Figure
{
private:
Point _center;
public:
Figure();
void SetCenter(Point center);
virtual void Draw();
virtual void Hide();
Point GetCenter();
}
Слайд 7Основные понятия объектного моделирования
2. Инкапсуляция (ограничение доступа)
Point point = {1,3};
Figure
figure;
figure.SetCenter(point);
figure.Draw();
figure._center = point; // Ошибка, т.к. ограничение доступа
Слайд 8Основные понятия объектного моделирования
3. Модульность
Физические модули: компонент, пакет (физическая группировка)
Логические
модули: класс, подсистема (логическая группировка)
Головная
процедура
Раздел
интерфейса
Раздел
реализации
int g();
class X
{
public:
int f()
}
#include”x.h”
const int c=3;
int g()
{
return c;
}
int X::f()
{
return c*f();
}
#include “x.h”
void main()
{
int i=g();
X x;
i = x.f();
}
x.h
x.cpp
main.cpp
main.exe
x.obj
Характеристики: связность модуля, сцепление модулей
Слайд 9Основные понятия объектного моделирования
4. Иерархия
Иерархия классов
Иерархия объектов
Слайд 10Основные понятия объектного моделирования
class Engine {float power;}
class PetrolEngine : public
Engine {}
class DieselEngine : public Engine {}
class Person {}
class MotorCar
{
double velocity;
Engine engine;
public:
void Drive() {}
}
class PassengerCar : public MotorCar
{
Person passengers[];
}
class Truck : public MotorCar
{
double weight;
double bodyCapacity;
}
Слайд 11Объекты
Объект – это сущность, обладающая индивидуальностью, состоянием и поведением
Изменение состояния
объекта
Поведение объекта
class Stack
{
private:
int top;
int *s;
int size;
public:
void
Push(int i);
int Pop();
int IsEmpty();
int IsFull();
void Copy(Stack *other);
Stack(int sz);
~Stack();
}
Слайд 12Объекты
Индивидуальность объекта
Stack r(100);
Stack q(300);
// …
q = r;
Слайд 13Объекты
Отношения:
Связь – взаимодействие между экземплярами сущностей
Агрегация (агрегация по ссылке, разделяемая
агрегация) - отношение «часть-целое»
Композиция (агрегация по значению) – строгая форма
агрегации, агрегируемый объект принадлежит только одному агрегату. Связаны жизненные циклы.
Связь
Агрегация
Слайд 14Классы
Класс – это описание структуры и поведения объектов, имеющих одинаковые
свойства, поведение и семантику
Слайд 15Классы
Отношения (relationship) между классами:
Наследование (inheritance, generalization) – отношение при котором
один класс разделяет структуру и поведение другого класса
Ассоциация (association) –
описание связей между экземплярами классов
Реализация (implementation) – отношение между интерфейсом и классом, его реализующим
Зависимость (dependency) – отношение между классами, при котором изменения в одном классе приводят к изменениям в другом классе (наследование, ассоциация и реализация – частные случаи отношения зависимости, имеющие особое назначение и специальную нотацию)
Слайд 16Наследование
При наследовании подкласс может :
добавлять поля
добавлять методы
переопределять методы
замещать методы
уточнять методы
Принцип
подстановки:
Экземпляр подкласса может быть использован при тех же условиях, при
которых используется экземпляр суперкласса
Слайд 17Наследование
class Figure
{
int _x, _y;
public:
virtual void
Show() = 0;
virtual void Hide() {/*…*/ };
void
Move(int x, int y) {
Hide();
_x=x; _y=y;
Show();
}
};
class Circle: public Figure
{
// добавление поля
int _radius;
public:
// замещение метода (реализация)
virtual void Show() {/*…*/ };
};
class Face: public Circle
{
int _eyeColor;
public:
// замещение метода
void Show();
// переопределение метода
void Move(int x, int y) {/*…*/}
// добавление метода
virtual void CloseEyes();
};
Слайд 18Наследование
int main()
{
Circle *cPtr;
cPtr=new Face; // фактический объект класса
Face
cPtr->Show(); // вызывается метод Face::Show()
cPtr->Move(10,20); // вызывается Figure::Move(),
так как невиртуальное
// замещение, а в нем методы Face::show() и
// Face::hide() в соответствии с фактическим
// классом объекта *cPtr.
// cPtr->closeEyes(); // ошибка компиляции
delete cPtr;
// ...
}
Слайд 19Наследование
Уточнение метода
class Circle: public Figure
{
virtual void Show()
{/*рисование
окружности*/ };
};
class Face : public Circle
{
virtual void Show()
{
/* рисование глаз */
Circle::Show();
/* рисование рта и ушей */
};
};
int main()
{
Face face;
face.Show(); // вызывается также
// Circle::Show()
}
В С++ уточнение реализовано для
конструкторов и деструкторов
Слайд 20Наследование
Абстрактность и полиморфизм
Слайд 21Ассоциация
class Controller
{
private:
Sensor _sensor[];
}
class Sensor
{
// нет ссылки на Conroller
}
class
Job
{
public:
Company* company;
Person* person;
double
salary;
}
Слайд 23Реализация
(realization/implementation)
class IList
{
public:
virtual void add(string& item) = 0;
virtual
void remove(string& item) = 0;
virtual void insertAt(int index, string&
item) = 0;
}
class LinkedList : public IList
{
private:
Element* _head;
public:
void add(string& item)
{… Element * p = new Element(item) … }
void remove(string& item) {… delete p; …}
void insertAt(int index, string& item) { … }
}
спецификация
реализация
class LinkedList : public IList
{
private:
Element* _head;
public:
void add(string& item)
{… Element * p = new Element(item) … }
void remove(string& item) {… delete p; …}
void insertAt(int index, string& item) { … }
}
Слайд 24Зависимость
Стереотипы отношения зависимости:
– назначение параметров шаблонному классу для получения
нового конкретного класса
– метод одного класса вызывает операцию другого
класса
<
> – один класс создает экземпляр другого класса
<> или <> – разрешение одному классу использовать реализацию другого класса
<
Слайд 25Зависимость
class List;
class Element
{
friend class List;
}
class List
{
Element* _head;
}
template
T>
class Array
{
public:
T operator[](int i) {…}
}
void main()
{
Array intArray;
Array
floatArray;
// …
}
class Product
{
public:
Product() {}
}
class Factory
{
public:
Product Create()
{
return Product();
}
}
Слайд 26Пакеты
Пакет – механизм общего назначения для распределения программных элементов по
группам с установлением владельца, а также средства для предотвращения конфликтов
имен
namespace P1
{
class С1 {}
namespace P2
{
class C1 {}
}
}
int main()
{
P1::C1 x1;
P1::P2::C1 x2;
}
Слайд 27Диаграммы UML
Представление (View) – это подмножество конструкций UML, отражающих один
аспект системы.
Описание статической структуры (Static View)
Описание вариантов использования (Use Case
View)
Описание дискретных автоматов (State Machine View)
Описание активности (Activity View)
Описание взаимодействия (Interaction View)
Описание размещения (Deployment View)
Описание проектных решений (Design View)
Рисунки из
Rumbaugh J., Jacobson I., Booch G. The Unified Modeling Language Reference Manual. – 2nd ed. Addison-Wesley. 2005
Слайд 28Описание статической структуры
Диаграммы
классов
Слайд 29Описание статической структуры
Диаграмма объектов
Слайд 31Диаграммы коммуникации
В языке UML моделируются следующие разновидности действий.
Слайд 32Диаграммы коммуникации
Для записи сообщений в языке UML принят следующий синтаксис:
имя Атрибута = имяСообщения (Аргументы): ВозвращаемоеЗначение,
где имяАтрибута задает атрибут, куда
помещается возвращаемое значение.
Слайд 33Диаграммы коммуникации
Поток синхронных сообщений.
Поток асинхронных сообщений.
Слайд 34Диаграммы коммуникации
Итерация и ветвление.
Слайд 35Диаграммы коммуникации
Для формирования диаграммы коммуникации выполняются следующие действия:
1) отображаются участники
взаимодействия;
2) рисуются связи, соединяющие этих участников;
3) связи помечаются сообщениями, которые
посылают и получают определенные участники.
Слайд 36Диаграммы коммуникации
Диаграмма коммуникации системы управления полетом.
Слайд 37Диаграммы последовательности
Диаграммы последовательности системы управления полетом.
Слайд 38Диаграммы последовательности
Создание и уничтожение обобщенного объекта.
Вложение спецификаций выполнения (активаций)
Слайд 39Диаграммы последовательности
Использование взаимодействия (interaction use)
Цикл (ключевое слово loop).
Условный
фрагмент (ключевое слово alt)
Необязательный фрагмент (ключевое слово opt)
Параллельный
фрагмент (ключевое слово par)
Наиболее популярны следующие комбинированные фрагменты:
Слайд 40Диаграммы последовательности
Диаграмма последова-тельности с вложенными фрагментами.
Слайд 41Диаграммы последовательности
Ограничения на количество итераций фрагмента-цикла указываются в скобках после
ключевого слова loop:
loop минимум = 0, максимум неограничен
lоор(количество) минимум
= максимум = количество
lоор(мин, макс) явное задание минимальной и максимальной границ.
Границы числа итераций
Слайд 42Диаграммы последовательности
Состояние объекта на диаграмме последовательности.
Слайд 43Описание вариантов использования
Слайд 44Описание дискретных автоматов
Диаграмма переходов состояний
[amount
Слайд 46Описание взаимодействия
Классификатор – модельный элемент, который описывает поведенческие свойства (в
виде операций) и структурные свойства (в виде атрибутов). Классификаторами являются:
класс, интерфейс, компонент, вариант использования, подсистема, узел размещения и т.д.
Figure 9-2. Classifiers
Слайд 47Описание взаимодействия
Диаграмма
последовательности
Слайд 48Описание взаимодействия
Диаграмма
последовательности
с детализацией
выполнения
Слайд 49Описание взаимодействия
Коммуникационная диаграмма
Слайд 50Описание размещения
Диаграмма
размещения
Слайд 51Описание проектных решений
Структурированный класс
Структурированный класс с портами
Слайд 52Описание проектных решений
Описание
сотрудничества
объектов
Использование
шаблона
Слайд 53Основные принципы детального проектирования
Принцип открытия-закрытия Бертрана Мейера (ОСР —
The Open-Closed Principle)
Слайд 54Основные принципы детального проектирования
- Принцип подстановки Барбары Лисков (LSP
— Liskov Substitution Principle)
- Принцип инверсии зависимостей Роберта Мартина
(DIP — Dependency Inversion Principle)
- Принцип отделения интерфейса (ISP — Interface Segregation Principle)
Слайд 55Основные принципы детального проектирования
- Принцип инверсии зависимостей Роберта Мартина
(DIP — Dependency Inversion Principle)
Слайд 56Принципы упаковки классов в архитектурные подсистемы
- Принцип эквивалентности повторного
применения (REP - Release Reuse Equivalency Principle). Уровень детализации повторного
применения (reuse) должен соответствовать желаемому уровню детализации новой версии.
- Принцип общего закрытия (ССР — Common Closure Principle). Классы, входящие в состав пакета, должны быть закрыты по отношению к одним и тем же изменениям. Изменение, влияющее на пакет, оказывает воздействие на все классы этого пакета, не затрагивая другие пакеты.
- Принцип общего повторного применения (CRP — Common Reuse Principle). Классы, входящие в состав пакета, повторно применяются совместно. Если вы повторно применяете один из классов пакета, вы повторно применяете их все.
Слайд 57Документирование процесса проектирования
Стандарт IEEE Std 1016-2009 «Systems Design — Software
Design Descriptions» предлагает документировать весь этап проектирования с помощью описания
программного проектирования (SDD — software design description).
Стандарт определяет следующие точки зрения:
□ Контекстная точка зрения. Отражает услуги, оказываемые пользователям и другим заинтересованным лицам, взаимодействующим с системой. Система рассматривается как черный ящик.
□ Композитная точка зрения. Описывает систему как структуру, состоящую из нескольких частей, и определяет роль каждой части.
Слайд 58Документирование процесса проектирования
□ Логическая точка зрения. Выявляет существующие и проектируемые
типы, а также их реализацию (классы и интерфейсы, их структурные
статические отношения). Могут использоваться экземпляры типов.
□ Точка зрения зависимостей. Определяются отношения взаимодействия и доступа отдельных сущностей. Эти отношения описывают разделяемую информацию, порядок выполнения, параметры интерфейсов.
□ Информационная точка зрения. Точка зрения применима, если ожидается присутствие персистентных (устойчивых) данных.
Слайд 59Документирование процесса проектирования
□ Точка зрения с использованием паттернов. Рассматривается сотрудничество
паттернов, их абстрактные роли и соединения.
□ Интерфейсная точка зрения.
Обеспечивает проектировщиков, программистов и тестировщиков информацией о правильном использовании сервисов системы. Здесь описываются детали внешних и внутренних интерфейсов, не заданные в спецификации требований. Предлагается набор интерфейсных описаний для каждой сущности.
□ Структурная точка зрения. Используется для документирования внутренних составляющих частей и организации системы в терминах элементов.
Слайд 60Документирование процесса проектирования
□ Точка зрения взаимодействий. Определяет стратегии для взаимодействия
сущностей, выделяя почему, где, как и зачем происходят действия. □
Точка зрения динамики состояний. Применима к событийно-управляемым системам. □ Алгоритмическая точка зрения. Детальное описание операций (методов, функций), внутренние детали и логика каждой сущности.
□ Ресурсная точка зрения. Моделируются характеристики и использование ресурсов системы
Слайд 61Документирование процесса проектирования
Оглавление SDD имеет следующий вид.
1. Аннотация
Дата
создания и статус
Выпускающая организация
Авторство
Перечень изменений
2. Введение
Цель
Область действия
Контекст
Выводы
3. Ссылки
4. Словарь
5. Основная часть
Заинтересованные лица и проектные понятия
Проектная точка зрения 1
Проектное представление 1
…
Проектная точка зрения N
Проектное представление N
Обоснование проектирования.