введение в объектно ориентированный анализ и язык UML

1. Введение в объектно-
ориентированный анализ
и проектирование

2. Сложности при разработке ПО
•Деньги
•Невозможность точно узнать, на каком этапе находится проект. Любые оценки – очень
приблизительные. В определенный момент этап разработки может меняться как по
щелчку пальцев
•Невозможность контроля. Как сказать сколько работы выполнено и сколько осталось?
•Незапланированные изменения. Заказчик постоянно меняет требования.
•Поиск багов и их исправление.
•Халатное отношение заказчиков к формулировке требований. «Я плачу деньги, так почему
я должен вообще принимать какие-либо решения?».
•Как правило – проект живет долгие годы, а разработчики на проекте меняются.
•Грамотный перенос модели реального мира в систему моделей разрабатываемого
продукта (!)
•Постоянный рост приложения – неминуемое усложнение системы.

4. Простое приложение Сложное
Где проще сосчитать точки?

5. Перед началом разработки проекта, было бы неплохо
спроектировать желаемую систему хотя бы
схематически, а так же сформулировать требования. Эта
документация нуждается в постоянной поддержке.

6. Типичный подход разработки ПО до
появления ООП - процедурно-
ориентированный стиль
•Появилась в 40-х годах 20 века
•Заключается в том, что изменяется первоначальное состояние памяти (значения данных)
путем применения определённых инструкций, разбитых на подпрограммы (совершив т.н.
декомпозицию). Подпрограммы по признаку связанности между собой в свою очередь
объединяются в модули.
•Подходит для простых программ. Не будете же вы устраивать грандиозное
проектирование для написания Hello World? 
•Данные «шарятся» между различными участками кода. Плюс это или минус?
•Много ветвлений в коде, которые со временем усложняются. К чему эту проводит?
•Языки: Pascal, C, Basic, C++ (позволяет использовать подход)

7. ООП – результат развития процедурно-
ориентированной парадигмы
•Первая попытка ООП языка – Симула (1967 год). Именно в нём были предложены
основные понятия ООП впервые – класс, объект, виртуальные методы. Был
проигнорирован разработчиками, т.к., по сути, был усложненным вариантом
процедурного Ангола.
•Первый широкораспротранённый ООП язык - Smalltalk (выпущен в 1980, разрабатывался
12 лет)

8. Так в чем же заключается ООП подход?
Вот что говорит Алан Кей (создатель SmallTalk)
•Всё является объектом.
•Вычисления осуществляются путём взаимодействия (обмена данными) между объектами, при
котором один объект требует, чтобы другой объект выполнил некоторое действие. Объекты
взаимодействуют, посылая и получая сообщения. Сообщение — это запрос на выполнение
действия, дополненный набором аргументов, которые могут понадобиться при выполнении
действия.
•Каждый объект является представителем класса, который выражает общие свойства объектов
(таких, как целые числа или списки).
•В классе задаётся поведение (функциональность) объекта. Тем самым все объекты, которые
являются экземплярами одного класса, могут выполнять одни и те же действия.
•Классы организованы в единую древовидную структуру с общим корнем, называемую
иерархией наследования. Память и поведение, связанное с экземплярами определённого
класса, автоматически доступны любому классу, расположенному ниже в иерархическом
дереве.

9. Итак, что имеем, чего не дает нам
процедурный подход?
•объектно-ориентированное программирование использует в качестве основных
логических конструктивных элементов объекты, а не алгоритмы. Объекту должны быть
приданы характеристики, которые будут четко определять его границы, которые отличают
его от других объектов (абстракция);
•каждый объект является экземпляром определенного класса;
•классы образуют иерархии – создание новых объектов от общего предка, уточняя
некоторые особенности.
Если в программе присутствуют эти три пункта, то можно уверенно сказать, что мы имеем
дело с объектно-ориентированным подходом.

10. Фундаментальные понятия ООП
•Классы - это абстрактное понятие, сравнимое с понятием категория в его обычном
смысле.

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

12. Виды абстракций:
• абстракция понятия: объект — это модель какого-то понятия предметной области
(например, банковский счет);
• абстракция действия: объект объединяет набор операций для выполнения какой-либо
функции (например, математические операции);
• случайная абстракция: объект объединяет не связанные между собой операции
(например, хелперы, утилиты).

13. Пример
Банкомат
Клиент
Счет Клиента
Клиент Банкомат
Счет в
банке
Начинаем работу
Выдай 100 рублей
Сообщи PIN
Проверить, есть ли деньги и снять со счета 100 руб.

14. Состояние объекта
Каждый объект в ООП характеризуется своим состоянием.
Состояние банковского счета —?
Состояние банкомата - ?
Состояние клиента - ?
Наличие состояний у объектов позволило появится ООП с явным выделением состояний.

15. Идентичность объекта
Идентичность (уникальность) – это такое свойство объекта, которое отличает его от всех
других объектов.
В большинстве языков программирования для различия объектов используют имя, тем
самым путая идентичность и адресуемость.
Источником большого количества ошибок в объектно-ориентированном
программировании является неумение отличать имя объекта от самого объекта.

16. Поведение объекта
Поведение объекта характеризуется набором его методов

17. Связи между объектами
• Актер - объект может влиять на другие объекты, но сам никогда не
поддается влиянию других объектов (например, таймер),
• Сервер - объект может лишь поддаваться влиянию со стороны других
объектов, но он никогда не выступает в роли объекта, который влияет
(например, класс, который позволяет логировать сообщения),
• Агент - такой объект может выступать как в активной, так и в пассивной,
роли

18. Отношения между классами
• Обобщение (наследование)

19. Ассоциация означает, что объекты двух классов могут
ссылаться один на другой, иметь некоторую связь между
друг другом. Например Менеджер может выписать Счет.
Соответственно возникает ассоциация
между Менеджером и Счетом.

20. Агрегация
Методика создания нового класса из уже существующих классов
путём их включения (т.е. объект является частью другого). Об
агрегировании также часто говорят как об «отношении
принадлежности» по принципу «у машины есть корпус, колёса и
двигатель». Агрегация выполяется по ссылке, т.е. если контейер
будет удален, то его соержимое – нет.

21. Композиция
Композиция (агрегирование по значению) — более строгий вариант агрегирования, когда
включаемый объект может существовать только как часть контейнера. Если контейнер будет
уничтожен, то и включённый объект тоже будет уничтожен.
class Department;
class University
{
private:
Department faculty[20];
};

22. Интерфейс класса
Интерфейс— программная/синтаксическая структура, определяющая отношение между
объектами, которые разделяют определенное поведенческое сходство и не связаны никак
иначе.
Интерфейсы позволяют наладить множественное наследование объектов.
При реализации интерфейса могут возникнуть проблема присуствия определенного
атрибута в нескольких интерфейсах. Пути решения?
• Запрет на реализацию обоих интерфейсов в одном классе. Реализация двух классов
вместо одного.
•Явное разрешение неоднозначности.
•Общая реализация одноименных методов.

23. Инстанцирование (англ. instantiation) — создание экземпляра
класса. В отличие от слова «создание», применяется не к
объекту, а к классу. То есть, говорят: (в виртуальной среде)
создать экземпляр класса или, другими словами,
инстанцировать класс.

24. •Наследование - механизм, позволяющий объектам класса
наследовать характеристики (данные и методы) более простых и
общих типов (классов); - средство получения новых классов из
существующих.
•Инкапсуляция - объединение данных с функциями,
предназначенными для манипулирования этими данными (т.е.
поведением) в новом типе – классе
•Полиморфизм - механизм, позволяющий использовать
одинаковые имена для сходных по смыслу действий и методов,
относящихся к различным объектам (типам и классам).

25. ОЧЕНЬ краткий список ООП языков:
Java, C#, Visual Basic .NET, C++, Delphi, Objective-C, Swift, PHP
Другие можно найти здесь: http://google.com 

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

27. Проблема проектирования актуальна
столько, сколько люди пишут программы
Попытки и работающие подходы:
• Середина 1970-х – Можель сущность-связь. С её помощью можно выделить ключевые
сущности и обозначить связи, которые могут устанавливаться между этими сущностями.
• Середина 60-х– Диаграммы функционального моделирования
• Диаграммы потоков данных, показывающие, как каждый процесс преобразует свои
входные данные в выходные, а также выявить отношения между этими процессами.

29. UML
Отличный инструмент для проведения анализа и проектирования.
UML (англ. Unified Modeling Language — унифицированный язык моделирования) —
язык графического описания для объектного моделирования в области разработки
программного обеспечения, моделирования бизнес-процессов, системного
проектирования и отображения организационных структур.
Создан в 1994 году Гради Бучем и Джеймсом Рабмо, которые работали в Rational Software.

30. За основу были взяты два метода анализа и проектирования:
•Booch (ориентирован на проектирование)
•Object-Modeling Technique (ориентирован на анализ)

31. Метод Буча (Booch)
Объекты изображаются в виде облаков, соединённых между собой.
Процесс построение модели должен пройти через следующие стадии:
Conceptualization (Осмысление) – установить основные требования
Analysis (Анализ) – разработать модель желаемого поведения
Design – Создание архитектуры
Evolution - Разработка
Maintenance – Доработка после уточнения требований/в процессе разработки

33. ОМТ - Object Modeling Technique
Т.е. ориентирован на анализ, то призван был выявить компоненты в предметной области,
помочь в общении с клиентами, визуализировать предметную область и понизить
сложность диаграмм.
Предложено три типа моделей:
Модель объекта – статичные и наиболее устойчивые понятия в моделируемой области
Динамическая модель – представляет собой состояние или переход состояния
Функциональная модель – потоки данных, хранилища данных.

35. В результате объединения усилий и слияния двух подходов, в 1996 были выпущены версии
0.9 и 0.91 спецификации UML.
В результате растущего интереса к UML к разработке присоединились такие корпорации,
как IBM, Microsoft, Oracle, HP и другие. Результатом совместной работы стала
спецификация UML 1.0 в январе 1997 году. Через 10 месяцев была выпущена версия 1.1,
где были сделаны некоторые уточнения. Последующие версии 1.3, 1.4, 1.5 выпускались с
периодичностью раз в два года до 2003 года.
Актуальная версия – 2.5, выпущена в июне 2015 года.

36. Плюсы UML
Объектно-ориентирован – легко переносится на ООП языки программирования
Широко распространен – можете рассчитывать, что при общении с разработчиками на
другом конце земного шарика, вас поймут.
UML позволяет описать систему практически со всех возможных точек зрения и разные
аспекты поведения системы.
Диаграммы UML сравнительно просты для чтения после достаточно быстрого
ознакомления с его синтаксисом

37. Минусы UML
Избыточность языка. UML часто критикуется как неоправданно большой и сложный. Он
включает много избыточных или практически неиспользуемых диаграмм и конструкций.
Только код отражает код. Ещё одно мнение — важны рабочие системы, а не красивые
модели.
Пытается быть всем для всех. UML — это язык моделирования общего назначения, который
пытается достигнуть совместимости со всеми возможными языками разработки. В
контексте конкретного проекта, для достижения командой проектировщиков
определённой цели, должны быть выбраны применимые возможности UML.

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

39. Задача №1
Необходимо разработать систему учета рекламных объектов компании по городу Минску.
Типы объектов:
•Билборды
•Автомобильные указатели
•Световые короба
Так же необходимо иметь возможность сообщать о нелегально установленной рекламе в
городе, помочь контролирующим органам мониторить ситуацию.
Приложением будут пользоваться все организации, которые занимаются рекламой в
городе, а так же контролирующие организации (ГАИ).

40. Задача №2
Компания нуждается во внутренней системе учета сотрудников. Необходимо иметь
информацию о навыках сотрудника, дате рождения, номере автомобиля, телефоне,
сведения об отпусках и, естественно, должности.
Компания имеет множество клиентов, и хотела бы иметь сведения о том, какие работники
работали/работают с тем или иным клиентом.
В системе так же должен быть предусмотрена возможность автоматизированного ввода
отпусков.