СОВРЕМЕННЫЕ ТЕХНОЛОГИИ РАЗРАБОТКИ ПО Лекция 4: Сложность программных систем. Декомпозиция задач. Объектно-ориентированный анализ. Паттерны (шаблоны) проектирования. Сложность программных систем Причины Признаки сложных систем Борьба со сложностью Причины сложности • По Фредерику Бруксу: • сложность предметной области - сложный мир - пользователи не знают/не умеют объяснить, что надо - требования меняются • трудность управления процессом разработки - большая система -> много задач -> большая команда -> сложно координировать • необходимость обеспечить гибкость программы - нет стандартов, сложно выбрать нужный уровень • сложность описания поведения больших систем - «случайно залетевший дятел приводит к краху цивилизации» • Из SICP: • Computer Science – не столько про науку и компьютеры, сколько про набор методов преодоления сложности 3 Последствия для индустрии • Непонимание этой сложности • за «небольшим изменением» может стоять необходимость фундаментальной переделки всей системы • Неумение создавать сложные системы • Срыв сроков, бюджетов, непопадание в требования • Неэффективное использование кадров - избыточные трудозатраты на создание/поддержание «плохих» систем 4 Признаки сложной системы 1. Иерархия и взаимозависимые подсистемы (тоже сложные) 2. Можно выделить элементарные компоненты • разными способами (зависит от взгляда) абстрагировавшись от деталей 3. Внутрикомпонентная связь обычно сильнее, чем связь между компонентами 4. Состоит из немногих типов подсистем, по-разному скомбинированных и организованных 5. Любая сложная система – результат развития более простой системы • "с нуля" сложная система не заработает - всегда есть что-то проще 5 Подходы к организации • Архитектура системы: • структура классов - общие свойства объектов • + структура объектов - конфигурация системы во время выполнения • Проблема организации: • сложность систем превышает способности человека охватить их целиком • выход – «разделяй и властвуй» - декомпозиция - работа с каждым уровнем абстракции отдельно 6 Декомпозиция • Алгоритмическая • шаги разбиваются на подшаги иерархически, сверху-вниз • Объектно-ориентированная • критерий – принадлежность частей к абстракциям предметной области • Оба вида – взаимодополняющие • следует предпочитать более подходящий к задаче 7 Абстракция. Иерархия • Методы проектирования программных систем: • структурное проектирование сверху вниз • потоки данных - система преобразует входные потоки в выходные • объектно-ориентированное проектирование - система – совокупность взаимодействующих объектов • Иерархия • объектная схема – механизмы взаимодействия объектов • структура классов – общность структур и поведения 8 Абстракция данных • Отделяет способ использования от деталей внутреннего представления • Пример (SICP): рациональные числа. Уровни абстракции: • Программы, использующие рациональные числа: - рациональные числа в предметной области • Высокоуровневые операции - plus, minus, ..., equal - используют более простые абстракции (конструирование, селекторы) • Рациональные числа как числители со знаменателями - конструкторы, селекторы numerator, denominator • Рациональные числа как структура данных - std::pair<int, int> или просто int n, d • Реализация более простых типов (pair, int) - как это понимает компилятор или среда исполнения 9 Абстракция данных • Можно изменять представления данных • интерфейс остаётся неизменным • Или даже использовать одновременно несколько представлений • можно выбирать более удобное в данный момент 10 Абстракция алгоритмов • Пример: нужно подсчитать сумму квадратов всех нечётных чисел в дереве • Решение «в лоб», от описания: def sumOddSquares(tree): if tree is null: return 0 elif tree is instance of Leaf: return square(tree.value()) else: return sumOddSquares(tree.left()) + sumOddSquares(tree.right()) • Подход 2: конвейер обработки потока данных do all <- tree.values(), oddItems <- filter(all, isOdd), squaredItems <- map(oddItems, square), return accumulate(plus, 0, squared). 11 ООП: данные + поведение Пример: классический ГПСЧ • В языке C: srand(int seed) + int rand() • ООП: внутреннее состояние объекта – «зерно» для генерации следующего числа • конструктор Random(int seed) + модификатор int Random::rand() Внутреннее состояние изменяет картину: • Присваивание нарушает "чистоту" (побочные эффекты) • ФП vs. Императивное программирование • Два объекта с одинаковым состоянием – это не одно и то же (разные сущности) • нарушается ссылочная прозрачность 12 Объектноориентированный подход Объектная модель Отношения классов и объектов Процесс проектирования Основы ООП • В качестве базовых элементов – объекты • а не алгоритмы • Каждый объект – экземпляр определенного класса • Классы организованы иерархически 14 Объектная модель • Основные элементы: • • • • Абстрагирование Инкапсуляция Модульность Иерархия • Вспомогательные элементы: • Типизация • Параллелизм • Сохраняемость 15 Объектная модель Абстрагирование • Основные виды • Абстракция сущности - • Абстракция поведения - • обобщённое множество операций Абстракция виртуальной машины - • модель сущности предметной области набор операций более низкого уровня Произвольная абстракция 16 Объектная модель Абстрагирование • Контрактная модель • «сервер» исполняет обязательства перед «клиентом» • Протокол – полный набор операций и их порядок • способы взаимодействия с объектом • внешнее поведение абстракции • Инвариант – логическое условие • изменение инварианта нарушает контракт 17 Объектная модель Инкапсуляция • Определяет четкие границы между абстракциями • На практике, означает разделение класса на • интерфейс • и внутреннюю реализацию 18 Объектная модель Модульность • Модульность системы • внутренне связные • но слабо связанные между собой модули • Понятие модульности связано с инкапсуляцией • интерфейс модуля часто отделяется от его реализации • Пример из C++: • модуль (компиляции) - .cc/.cpp-файл • интерфейс – в заголовочном файле .h/.hpp 19 Объектная модель Иерархия • Иерархия – это упорядочение абстракций, расположение их по уровням. • Структура классов: наследование - "обобщение/специализация" • Структура объектов – агрегация - «целое/часть» - проблема владения (управление временем жизни частей) • собственно агрегация • композиция 20 Объектная модель Типизация • Типизация – способ защититься от использования объектов одного класса вместо другого • или управлять таким использованием • Сильная или слабая типизация • сильная – жёсткий контроль за приведением типов • слабая – отсутствие контроля • промежуточные варианты: возможно смешивать базовые типы (C++) • Статическое и динамическое связывание • во время компиляции или во время выполнения (полиморфное поведение) 21 Объектная модель Параллелизм • Параллелизм позволяет различным объектам действовать одновременно • Параллелизм – свойство, отличающее активные (управляющие) объекты от пассивных • Многозадачность: • "истинная" –параллельное и независимое исполнение • "легковесная" – кооперативная многозадачность • "вытесняющая" – прерывания • Возникает задача синхронизации 22 Объектная модель Сохраняемость • Сохраняемость – способность объекта существовать • во времени - переживая породивший его процесс, • и (или) в пространстве - перемещаясь из своего первоначального адресного пространства • Время жизни объекта: • • • • Промежуточные результаты вычисления выражений Локальные переменные в вызове процедур Глобальные переменные и динамически создаваемые Данные, сохраняющиеся между сеансами выполнения программы • Данные, сохраняемые при переходе на новую версию программы • Данные, которые переживают саму программу 23 Объекты • Не всё является объектами • могут быть атрибуты (без поведения) • Свойства объекта: • Состояние - свойства и их текущие значения • Поведение - Конструктор Деструктор Модификатор Селектор Итератор • Идентичность - отличительный признак объекта - время жизни 24 Отношения между объектами • Связи (ассоциации) • Actor – действующее лицо • Сервер – обслуживает запросы • Агент – промежуточное звено • Агрегация • отношения "целое-часть" • композиция – когда время жизни композита совпадает с временем жизни частей 25 Классы • Класс - это некое множество объектов, имеющих общую структуру и общее поведение. • Составные части: • интерфейс - открытая часть - защищённая • доступ себе, подклассам и друзьям - закрытая • доступ себе и друзьям • реализация 26 Отношения между классами • Ассоциация • смысловая связь (ссылки на объекты другого класса) • участники, роли, мощность отношений • Наследование • специализация • при поддержке полиморфного поведения • Aгрегация • воплощение агрегации объектов • включение по ссылке или физическое • Использование • клиент-серверные отношения • в т.ч., "дружеские" отношения - доступ с нарушением инкапсуляции • передача "серверов" в методы "клиента" • Инстанцирование • шаблонные классы и их специализации • класс как параметр шаблона • Метакласс • класс как объект 27 Процесс проектирования Макропроцесс • Концептуализация • Выявление сущности требований к программному продукту • Анализ • Разработка модели требуемого поведения системы • Проектирование • Создание архитектуры для реализации • Эволюция • Итеративное выполнение реализации • Сопровождение • Управление эволюцией продукта в ходе эксплуатации 28 Процесс проектирования Итерация (микропроцесс) • Выявление классов и объектов на данном уровне абстракции • Выяснение семантики этих классов и объектов • Выявление связей между этими классами и объектами • Спецификация интерфейса и реализация этих классов и объектов 29 Паттерны проектирования Паттерны проектирования • Идеи архитектора К. Александера • «язык шаблонов» в архитектуре зданий • Эрих Гамма и его “Gang of Four” • Design Patterns – Elements of Reusable ObjectOriented Software • Описали общие паттерны, разделив по категориям • Помимо этих общих, выделяют также и другие, частные паттерны - Model-View-Controller как самый известный - Параллельное программирование: • пулы потоков, мониторы, замки, планировщики и т.п. - Active Record – шаблон работы с БД 31 Порождающие паттерны • • • • • Abstract Factory (абстрактная фабрика) Builder (строитель) Factory Method (фабричный метод) Prototype (прототип) Singleton (одиночка) 32 Структурные паттерны • • • • • • • Adapter (адаптер) Bridge (мост) Composite (компоновщик) Decorator (декоратор) Facade (фасад) Fluweight (приспособленец) Proxy (заместитель) 33 Поведенческие паттерны • • • • • • • • • • • Chain of Responsibility (цепочка обязанностей) Command (команда) Interpreter (интерпретатор) Iterator (итератор) Mediator (посредник) Memento (хранитель) Observer (наблюдатель) State (состояние) Strategy (стратегия) Template Method (шаблонный метод) Visitor (посетитель) 34 Примеры: Фабричный метод • Порождающий шаблон • Делегирует создание объектов наследникам • определяет интерфейс для создания объекта - возможно, какое-то сложное конструирование • решение о конкретном инстанцируемом типе принимают наследники (с) http://ru.wikipedia.org/wiki/Файл:FactoryMethodPattern.png (CC BY-SA 3.0) 35 Примеры: Адаптер • Структурный шаблон • Определяет специальный интерфейс для работы с объектом • если исходный класс имеет неподходящий интерфейс • и нельзя его модифицировать (с) http://ru.wikipedia.org/wiki/Файл:AdapterPattern.svg (CC BY-SA 3.0) 36 Примеры: Декоратор • Структурный шаблон • Динамическое подключение дополнительного поведения к объекту • расширение функциональности без наследования • реализует тот же интерфейс, что и декорируемый объект (с) http://ru.wikipedia.org/wiki/Файл:Decorator_Template.png (CC BY-SA 3.0) 37 Примеры: Посетитель • Поведенческий шаблон • Выполнение аналогичных операций над набором классов • возможность определять операции, не меняя самих классов • причём, для каждого из классов – своя операция (с) http://ru.wikipedia.org/wiki/Файл:VisitorDiagram.svg (CC BY-SA 3.0) 38 Примеры: Наблюдатель • Поведенческий шаблон • Механизм оповещения об изменении состояния классов • уведомляются все заинтересованные наблюдатели 39 (с) http://ru.wikipedia.org/wiki/Файл:Observer.png (CC BY-SA 3.0) Примеры: Стратегия • Поведенческий шаблон • Позволяет абстрагировать и выбирать алгоритмы в зависимости от контекста • обобщённый интерфейс для правила/алгоритма 40 (с) http://ru.wikipedia.org/wiki/Файл:Strategy_pattern.png (CC BY-SA 3.0) Ссылки • Х. Абельсон, Дж. Сассман, «Структура и интерпретация компьютерных программ» • Г. Буч, «Объектно-ориентированный анализ и проектирование» • Ф. Брукс, «Мифический человеко-месяц» • 35 принципов ОО-дизайна: • http://www.asis.ru/posts/23 • Шаблоны проектирования: • http://ru.wikipedia.org/wiki/Шаблон_проектирования 41