Проектирование ИС. Основные подходы и модели

Машинное программирование Алгоритмическое П/П Структурное П/П Модульное П/П Объектно-ориентированное П/П Компонентное П/П.

Э. Дэйкстра (60-е годы): Для любой простой программы можно построить функционально эквивалентную ей структурную программу, т.е. программу, сформированную на основе фиксированного базисного множества, включающего: структуру последовательного действияструктуру выбора одного из двух действийструктуру цикла, то есть многократного повторения некоторого действия с проверкой условия остановки повторения.Простая программа – ровно один вход и один выход.Стандартизация и линейность программы – снижение сложности. Некоторые соображения: Алгоритм должен иметь 1 вход и 1 выходНикаких gotoНет зависимости от языка программированияЯсен набор операторов, который необходим в языках программированияАлгоритмы + структуры данных = программа.

Основная идея: разбиваем сложную задачу на подзадачи, каждую из них при необходимости разбиваем снова и т.д.; Получаем простые задачи, их решаем, объединяем.Модульное П/П – специфичный для задачи базис из модулей. – Более высокий уровень абстракции.– Настройка на конкретную задачу. – Возможности повторного использования. – Возможности коллективной разработки – разделение труда.

Дальнейшая борьба со сложностьюТехнология работает, начиная с этапа анализаАнализ – Проектирование – ПрограммированиеВ основе – объектная модель и объектная декомпозицияОсновные принципы объектной модели: – абстракция; – инкапсуляция; – иерархичность (наследование, агрегация); – полиморфизм; – модульность Объектная декомпозиция (в отличие от алгоритмической): элементы проекта – классы и объекты (а не алгоритмы). Затем – детализация (данные и алгоритмы).

Объект - это экземпляр класса. В качестве экземпляра класса объект обладает всеми характеристиками своего классаНаследовать могут не только объекты, но и классы. Наследование – уточнение задаваемого множества объектовБолее общий класс – «базовый» класс или «суперкласс»Более частный класс – наследник

«Один интерфейс – много реализаций»Наследование позволяет использовать экземпляр унаследованного класса, как экземпляр базового класса.Виды полиморфизма: Переопределение (override): в унаследованном классе можно переопределить метод базового класса. Перегрузка (overload): один и тот же класс может иметь методы с одинаковыми именами, но разными сигнатурами. – Перегрузку методов следует использовать, когда методы выполняющие подобные действия, могут принимать различные аргументы.

Модель есть упрощение исходного объекта Абстракция = выделение необходимых свойств объекта Необходимость набора свойств определяется решаемой задачей Однотипные объекты, обладающие одинаковыми наборами характеристик, объединяются в группы В ООП такие группы называются Классами Объект = экземпляр класса.

А) Процесс разделения элементов абстракции, которые образуют ее структуру и поведение. Отделение внешних обязательств объекта от его реализации Б) Сокрытие внутренней структуры данных и реализации методов объекта от остальной программы Другим объектам доступен только интерфейс объекта, через который осуществляется взаимодействие

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

Объекты + отношения = программа;Программные объекты часто описывают реальные объекты. Это позволяет моделировать систему «естественно»;Объекты, их поведение и отношения между ними описываются UML-диаграммами.

Древние греки – «мир можно рассматривать в терминах объектов и событий» Декарт (XVII): люди обычно имеют объектно-ориентированный взгляд на мирОсновы ООП сформулированы в 1960е- 80- е годы независимо разными авторами (Кей, Джонс, Вильямс, Дийкстра, Буч др.) ООА, ООПроек, ООПрог – язык Simula.

Unified Modeling Language Де-факто и де-юре стандартный язык моделирования в современной ИТ-индустрии

1995-96 гг. – “Три Амиго” работают над предварительными версиями UML в Rational Software Corporation 1996-97 гг. – представители софтверной индустрии организуют консорциум для работы над проектом стандарта UML 1997 г. – OMG принимает стандарт UML 1.1 2005 г. UML 1.4.2 принят в качестве международного стандарта ISO/IEC 19501:2005 2005 г. – опубликована версия 2.0. 2011 г. – опубликована версия 2.4.1. 2012 г. она получила статус ISO/IEC 19505 2015 г. – опубликована версия 2.5. 

Диаграмма классов UML (class diagram)Служит для представления статической структуры модели системыОтражает взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывает их внутреннюю структуру и типы отношенийНе указывает информацию о динамике функционирования системы.Именование классовКласс может не иметь конкретных экземпляров. Такой класс называют абстрактным.Имя абстрактного класса на диаграмме отображается наклонным шрифтомКлассы группируются в ПакетыИмя класса уникально в пределах пакета.Для уникальной идентификации в пределах проекта – синтаксис <Имя_пакета>::<Имя_класса>

Основные отношения между классами:ассоциация (именованная связь)зависимость (изменения в одном классе приводят к изменениям в другом)обобщение / генерализация (родовидовое отношение)агрегация (отношение «часть-целое»)композиция (отношение «часть-целое» », однозначно регламентирующее количество и состав частей целого  Отношение зависимости (dependency relationship): Возникает, когда один класс использует другой. Используется, когда изменение одного элемента модели может потребовать изменения другого зависимого от него элемента моделиАссоциация (association relationship)Бинарная ассоциация Имя ассоциации Кратность ассоциации Порядок классов в ассоциацииn-арная ассоциация - Каждый экземпляр n-арной ассоциации представляет собой n-арный кортеж значений объектов из соответствующих классовИсключающая ассоциация - из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один ее экземпляр. Агрегация (aggregation relationship) -имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущностиКомпозиция (composition relationship) - частный случай агрегации. Части не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его составные частиОбобщение (generalization relationship) - между более общим элементом (предком) и более частным или специальным элементом (потомком)

Предоставить в распоряжение пользователей легко воспринимаемый и выразительный язык визуального моделирования, специально предназначенный для разработки и документирования моделей сложных систем самого различного целевого назначения Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области Описание языка UML должно поддерживать такую спецификацию моделей, которая не зависит от конкретных языков программирования и инструментальных средств проектирования программных системОписание языка UML должно включать в себя семантический базис для понимания общих особенностей ООАППоощрять развитие рынка объектных инструментальных средствСпособствовать распространению объектных технологий и соответствующих понятий ООАП Интегрировать в себя новейшие и наилучшие достижения практики ООАП.

Диаграмма вариантов использования (use case diagram) Диаграмма классов (class diagram) Диаграммы поведения (behavior diagrams) –Диаграмма состояний (statechart diagram) –Диаграмма деятельности (activity diagram) –Диаграммы взаимодействия (interaction diagrams):Диаграмма последовательности (sequence diagram)Диаграмма кооперации (collaboration diagram)Диаграммы реализации (implementation diagrams) –Диаграмма компонентов (component diagram) –Диаграмма развертывания (deployment diagram) 

1980е – начало 90х – гг. OOSE (Ivar Jacobson) OMT (James Rumbaugh), Booch (Grady Booch).OOSE – средства представления вариантов использования ОМТ-2 –анализ процессов обработки данных в информационных системах Booch'93 – нашел наибольшее применение на этапах проектирования и разработки различных программных систем. 

ООП как развитие структурного анализа данныхМоделирование объектов РМ при помощи «объектов» - конструктов языка программированияОбъект представляет собой модель объекта РМ, с выделенным набором атрибутов (свойств) и операцийНечто, чем можно оперировать.Имеет состояние, поведение и идентичность.Термины "экземпляр" и "объект" взаимозаменяемы.Поведение объектаПоведение реализуется через набор операцийОперация, operation - нечто, проделываемое одним объектом над другим, чтобы вызвать реакциюТермины "операция", "метод" и "сообщение" взаимозаменяемы

Модель есть упрощение исходного объектаАбстракция = выделение необходимых свойств объектаНеобходимость набора свойств определяется решаемой задачейОднотипные объекты, обладающие одинаковыми наборами характеристик, объединяются в группыВ ООП такие группы называются КлассамиОбъект = экземпляр класса.

Объект - это экземпляр класса.В качестве экземпляра класса объект обладает всеми характеристиками своего классаНаследовать могут не только объекты, но и классы.Наследование – уточнение задаваемого множества объектовБолее общий класс – «базовый» класс или «суперкласс»Более частный класс – наследник.

Внешний вид класса, объекта или модуля, выделяющий его существенные черты и не показывающий внутреннего устройства и внутренних механизмов поведения

«Один интерфейс – много реализаций»Наследование позволяет использовать экземпляр унаследованного класса, как экземпляр базового класса.Виды полиморфизма: Переопределение, Перегрузка.Переопределение методов (override): в унаследованном классе можно переопределить метод базового класса.Перегрузка методов (overload): один и тот же класс может иметь методы с одинаковыми именами, но разными сигнатурами. – Перегрузку методов следует использовать, когда методы выполняющие подобные действия, могут принимать различные аргументы.

А) Процесс разделения элементов абстракции, которые образуют ее структуру и поведение.Отделение внешних обязательств объекта от его реализацииБ) Сокрытие внутренней структуры данных и реализации методов объекта от остальной программы.Другим объектам доступен только интерфейс объекта, через который осуществляется взаимодействие

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

Класс может не иметь конкретных экземпляров. Такой класс называют абстрактным.Имя абстрактного класса на диаграмме отображается наклонным шрифтомКлассы группируются в ПакетыИмя класса уникально в пределах пакета.Для уникальной идентификации в пределах проекта – синтаксис <Имя_пакета>::<Имя_класса>

ассоциация (именованная связь)зависимость (изменения в одном классе приводят к изменениям в другом)обобщение / генерализация (родовидовое отношение)агрегация (отношение «часть-целое»)композиция (отношение «часть-целое» », однозначно регламентирующее количество и состав частей целого

Бинарная ассоциацияИмя ассоциацииКратность ассоциацииПорядок классов в ассоциации

Каждый экземпляр n-арной ассоциации представляет собой n-арный кортеж значений объектов из соответствующих классов

Из нескольких потенциально возможных вариантов данной ассоциации в каждый момент времени может использоваться только один ее экземпляр.

частный случай агрегациичасти не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его составные части

между более общим элементом (предком) и более частным или специальным элементом (потомком)

{complete} - указаны все классы-потомки, и других потомков быть не может. {incomplete} - противоположный случай{disjoint} - классы-потомки не могут содержать объектов, одновременно являющихся экземплярами двух или более классов. {overlapping} - отдельные экземпляры классов- потомков могут принадлежать одновременно нескольким классам

Требования1.1. Основы требований1.2. Процесс1.3.Извлечение требований1.4. Анализ требований1.5. Спецификация требований1.6. Утверждение требований1.7. Практические требования 2. Проектирование2.1. Основы проектирования 2.2. Ключевые вопросы проектирования2.3. Структура и архитектура2.4. Анализ качества и оценка дизайна 2.5. Нотации дизайна2.6. Стратегии и методы проектирования 3. Конструирование3.1. Основы конструирования3.2. Управление конструированием3.3. Практические соображения 4. Тестирование4.1. Основы тестирования4.2. Уровни тестирования4.3. Техники тестирования4.4. Метрики, связанные с тестированием4.5. Процесс тестирования 5. Поддержка и эксплуатация 5.1. Основы поддержки и эксплуатации5.2. Ключевые вопросы поддержки и эксплуатации 5.3. Процесс5.4. Техники

1. Основы проектирования1.1. Общие концепции проектирования1.2. Контекст проектирования ПО1.3. Процесс проектирования ПО1.4. Принципы проектирования ПО2. Ключевые вопросы проектирования3. Структура и архитектура ПО4. Анализ качества и оценка результатов проектирования5. Нотации проектирования ПО6. Стратегии и методы проектирования ПО

Основы проектирования ПО 1.1. Общие концепции проектирования 1.2. Контекст проектирования ПО 1.3. Процесс проектирования ПО 1.4. Принципы проектирования ПО

Абстракция (Abstraction)Связанность и связанность (Coupling and Cohesion)Декомпозиция и разбиение на модули (Decomposition and Modularization)Инкапсуляция/сокрытие информации (Encapsulation/information hiding)Разделение интерфейса и реализации (Separation of interface and implementation)Достаточность, полнота и простота (Sufficiency, completeness and primitiviness)

Абстракция (Abstraction)Абстракция данных (статическая, в отношении информации);Процедурная абстракция (динамическая, в отношении поведения);Абстракция контроля (в отношении управления системой и обрабатываемой ею информации)

Связанность и связанность (Coupling and Cohesion)Связность, соединение (Cohesion) модуля – это мера зависимости его частей.Чем выше связность модуля, тем лучше результат проектирования (тем «чернее» его ящик (С.Орлов))Связанность, сцепление (Coupling) – определяет силу связи (часто, взаимного влияния) между модулямиСвязанность — внешняя характеристика модуля, которую желательно уменьшать.

Декомпозиция и разбиение на модули (Decomposition and Modularization)Модуль — фрагмент программного текста, являющийся строительным блоком в структуре системы. Как правило, модуль состоит из интерфейсной части и части- реализации.Модульность — свойство системы, которая может подвергаться декомпозиции на ряд внутренне связных и слабо зависящих друг от друга модулей, каждый из которых несет свою функциональность.

Инкапсуляция/сокрытие информации (Encapsulation/information hiding)Предполагает группировку и упаковку (с точки зрения подготовки к развертыванию и эксплуатации) элементов и внутренних деталей абстракции (то есть модели) в отношении реализации с тем, чтобы эти детали были недоступны пользователям элементов (компонент). 

Разделение интерфейса и реализации (Separation of interface and implementation)Данная техника предполагает определение компонента через специфицирование интерфейса, который: известен (описан) , доступен клиентам (или другим компонентам), независим от непосредственных деталей реализации.

Достаточность, полнота и простота (Sufficiency, completeness and primitiviness)Этот подход подразумевает, что создаваемые программные компоненты обладают всеми необходимыми характеристиками, определенными абстракцией (моделью), но не более того.То есть не включают функциональность, отсутствующую в модели.Данный принципy наиболее ярко представлен в гибких (agile) подходах к разработке ПО через метафору YAGNI“You Aren’ t Going to Need It”, то есть “не делай этого, пока не понадобится”.

Параллелизм (Concurrency) Множественные потоки управления Совместно используемые данные Синхронизация и конкуренция процессов 2. Контроль и обработка событий (Control and Handling of Events)Системы, ориентированные на обработку событий. 3. Распределение компонентов (Distribution of Components)Распределение (и выполнение) по различным узлам обработки в терминах аппаратного обеспечения, сетевой инфраструктуры и т.п. . 4. Обработка ошибок и исключительных ситуаций и обеспечение отказоустойчивости (Errors and Exception Handling and Fault Tolerance ) 5. Взаимодействие и представление (Interaction and Presentation)Представление информации пользователям и взаимодействие пользователей с системой, с точки зрения реакции системы на действия пользователей с точки зрения внутренней организации взаимодействия, например, в архитектурном стиле Model-View-Controller. Вопросы организации пользовательского интерфейса относятся к смежной дисциплине “Эргономика программного обеспечения” – Software Ergonomics. 6. Сохраняемость данных (Data Persistence).Суть вопроса – поиск “долгоживущих” объектов (структур данных) и их отображение на базу данных.

1. Архитектурные структуры и точки зрения (Architectural Structures and Viewpoints)2. Архитектурные стили (Architectural Styles)3. Шаблоны проектирования (Design Patterns)4. Семейства программ и фреймворков (Families of Programs and Frameworks)

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

Архитектурные стилиАрхитектурный стиль определяет – номенклатуру компонентов и типов соединительных звеньев, а также – набор условий, в соответствии с которыми они могут соединяться.

Gamma - Braude – Эрик Брауде. Технология разработки программного обеспечения – СПб, Питер, 200423 базовых шаблона Шаблоны создания (Creational patterns) - builder, factory, prototype, singleton Структурные шаблоны (Structural patterns) - adapter, bridge, composite, decorator, façade, flyweight, proxy Шаблоны поведения (Behavioral patterns) - command, interpreter, iterator, mediator, memento, observer, state, strategy, template, visitor Show & Garlan – Mary Shaw and David Garlan, Software Architecture -- Perspectives on an Emerging Discipline, Prentice Hall, 1996 Архитектура потоков данных Независимые компоненты Виртуальные машины Репозиторные архитектуры Виды репозиторных архитектур: – Базы данных – Гипертекстовые системы – Доски объявленийШаблон «Iterator» 5. Уровневые архитектуры.Fowler – М.Фаулер. Архитектура корпоративных программных приложений.: — М.: Из­дательский дом "Вильямс", 2006.Архитектура потоков данных – Последовательные пакеты – Каналы и фильтры Каждый процесс обработки данных проектируется независимо Данные поступают, обрабатываются и передаются.Архитектура каналов и фильтровОбрабатывающие модули ждут данных, чтобы начать свою работуАрхитектура независимых компонентСостоит из компонент, работающих независимо и обменивающихся между собой информацией– Параллельно взаимодействующие процессы Параллельный запуск нескольких процессов (потоков, нитей). Шаблон «Observer» (наблюдатель)– Клиент-серверные системы Серверы обслуживают клиентов с помощью запросов Низкое сцепление между компонентами «Узкий» интерфейс Шаблон «Facade»– Системы, управляемые событиями.Уровневые архитектурыУровень = Слой (Layer)Видимость «сверху вниз»Инкапсуляция внутренних слоевВысокая степень автономности слоевКоличество уровнейОсобенности реализации уровней.

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

Анализ качества и оценка результатов проектирования ПО (Software Design Quality Analysis and Evaluation)Атрибуты качества (Quality Attributes)Анализ качества и техники оценки (Quality Analysis and Evaluation Techniques)Измерения (Measures).Атрибуты качестваприменимые к run-time, то есть ко времени выполнения системы - например, атрибут «среднее время отклика системы», позволяющий оценить качество проекта с точки зрения производительности;ориентированные на design-time, то есть позволяющие оценивать качество получаемого проекта еще на этапе проектирования - например, средняя нагруженность классов бизнес- методами; непротиворечивость, полнота, завершенность. Анализ качества и техники оценкипросмотр (software design review); например, неформальный обзор архитектуры членами проектной команды; статический анализ (static analysis); например, трассировка с требованиями; симуляция и прототипирование (simulation and prototyping) – динамические техники проверки проекта в целом или отдельных его атрибутов качества - например, для оценки производительности используемых архитектурных решений при симуляции нагрузки, близкой к прогнозируемым пиковым.Измерения (метрики)Могут быть использованы для количественной оценки ожиданий в отношении различных аспектов конкретного проекта - например, размера проектной спецификации, сложности ее структуры, ее качества. Обычно, все метрики разделяют по двум категориям: функционально-ориентированные объектно-ориентированные

Структурные описания, статический взгляд (Structural Descriptions, static view)Текстовые языки описания архитектуры (Architecture description language, ADL); Диаграммы классов и объектов (Class and object diagrams); Диаграммы компонентов (Component diagrams); Карточки ответственности и связей класса (Class responsibility collaborator card, CRC); Диаграммы развёртывания (Deployment diagrams) ->Диаграммы «сущность-связь» (Entityrelationship diagram, ERD или ER); Языки описания/определения интерфейса (Interface Description Languages, IDL): языки, подобные языкам программирования, не включающие возможностей описания логики; Структурные диаграммы Джексона (Jackson structure diagrams); Структурные схемы (Structure charts): описывают структуру вызовов в программах (какой модуль вызывает, кем и как вызываем) 2. Поведенческие описания, динамический взгляд (Behavioral Descriptions, dynamic view)Диаграммы деятельности (Activity diagrams) Диаграммы кооперации (Collaboration diagrams) Диаграммы последовательности (Sequence diagrams) Диаграммы перехода и карты состояний (State transition and statechart diagrams): Диаграммы потоков данных (Data flow diagrams, DFD) Блок-схемы и структурированные блок-схемы (Flowcharts and structured flowcharts): Псевдокод и программные языки проектирования (Pseudocode and program design languages, PDL): языки, используемые для описания поведения процедур и методов, в основном на стадии детального проектирования; подобны структурным языкам программирования.Формальные языки спецификации (Formal specification languages): текстовые языки, использующие основные понятия из математики (например, множества) для строгого и абстрактного определения интерфейсов и поведения программных компонентов, часто в терминах пред- и пост-условий; Таблицы и диаграммы <принятия> решений (Decision tables and diagrams): используются для представления сложных комбинаций условий и действий (операций).

Общие стратегии (General Strategies) Декомпозиция и пошаговое уточнение Проектирование “сверху-вниз” Проектирование “снизу-вверх” Абстракция данных и сокрытие информацииИтеративный и инкрементный подход и др... 2. Функционально-ориентированное или структурное проектирование (Function-Oriented – Structured Design) 3. Объектно-ориентированное проектирование (Object-Oriented Design) 4. Проектирование на основе структур данных (DataStructure-Centered Design) 5. Компонентное проектирование (Component-Based Design)

Модель проектирования Система проектирования Класс - это наиболее приближенная к реальности абстракция класса системы.Свойства класса проектированияЯзык Видимость Семантика отношений, отображение на атрибуты Методы, отображение на методы Отложенные решения: требования к реализации класса Класс может быть реализован в виде интерфейса ЯП Класс может быть активнымПроект реализации - это кооперация, определяющая реализацию конкретного варианта использования в терминах классов проектирования и их объектов. Содержит: – Диаграммы классов – Диаграммы взаимодействий – Текстовое описание потока событий – Требования к реализацииИнтерфейс Описание архитектуры (представления модели проектирования и модели развертывания) Модель развертывания

Конфигурационное управление1.1. Управление процессами1.2. Идентификация конфигураций1.3. Контроль конфигураций1.4. Отчетность по статусу конфигураций1.5. Конфигурационные аудит1.6 Конфигурационный аудит1.7. Управление выпуском ПО и развертывание 2. Управление инженерной деятельностью2.1. Инициирование и определение содержания2.2. Планирование проектов2.3. Проектные работы (реализация плана)2.4. Обзор и оценка2.5. Закрытие (работ) 2.6. Количественная оценка инженерной деятельности 3. Процессы инженерной деятельности3.1. Реализация и изменение процессов3.2. Определение процессов3.3. Оценка процессов3.4. Измерение процессов и продуктов 4.Инженерные инструменты и методы 4.1. Программные инструменты 4.1.1. Управление требованиями4.1.2. Проектирование4.1.3. Конструирование 4.1.4. Тестирование4.1.5. Сопровождение4.1.6. Конфигурационное управление4.1.7. Управление инженерной деятельностю4.1.8. Поддержка инженерных процессов4.1.9. Обеспечением качества4.1.10. Другие инструменты4.2. Методы программной инженерии 4.2.1. Эвристические методы 4.2.2. Формальные методы4.2.3. Методы прототипирования 5. Качество 5.1. Основы качества5.2. Процессы управления качеством 5.3. Практические соображения

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

При решении конкретных проблем эксперты обычно не пытаются разработать новое решение, который отличается от уже имеющихся. Действия эксперта: – вспоминают аналогичную проблему, которую они уже решали, – стараются повторно используют суть ранее принятого решения для решения новой проблемы. Такой «стиль мышление» в терминах пар «проблема - решение», является общим для множества различных предметных областей, таких, как: – архитектура;– экономика; – программная инженерия.Кристофер Александер:Каждое типовое решение описывает задачу, которая снова и снова возникает в нашей работе, а также принцип её решения, причем таким образом, что решение можно использовать миллион раз, ничего не изобретая заново. (Кристофер Александр). 

В конце 80-х годов XX века в области разработки ПО (в частности, ОО проектировании) накопилось много различных похожих по своей сути решений. Эти решения требовали – систематизации, – обобщения на всевозможные ситуации, – доступного описания, способствующего пониманию их людьми, которые до этого никогда их не использовали. Такое упорядочение знаний в ОО проектировании позволило бы повторно использовать готовые и уже проверенные решения. Решение данной проблемы взяли на себя шаблоны (паттерны) проектирования.

Зачем нужны шаблоны:Основываются на коллективном опыте квалифицированных инженеров по проектированию.Фиксируют существующий, хорошо зарекомендовавший себя опыт разработки и помогает содействовать хорошим методам проектирования.Каждый шаблон имеет дело с конкретной, многократно встречающейся проблемой в области проектирования и реализации.ОпредениеШаблон – это описание хорошо проверенной, обобщенной схемы решения некоторой часто повторяющейся проблемы (задачи) разработки ПО, которая возникает в некоторых специфических условиях (контексте) Схема решения проблемы задается путем: – определения используемых (составляющих) компонент; – их ответственностей;– способов их взаимодействия.

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

Являются шаблонами самого высокого уровня в системе шаблонов ПОПомогают определить базовую структуру программной системы.Предоставляют набор заранее определенных подсистем,Определяют их ответственности,Включают правила и рекомендации по организации взаимодействия между ними.Влияют на:– коммуникацию и взаимодействие между разными частями системы;– их последующее расширение.Каждый архитектурный шаблон помогает разработчику достигнуть некоторого глобального свойства разрабатываемой системы,– Например, адаптируемости пользовательского интерфейса.Примеры архитектурных шаблоновLayers (Уровни), Pipes and Filters (каналы и фильтры), Blackboard (информационная "доска"), Broker (брокер),Model-View-Controller (Модель- Представление-Контроллер), Presentation-Abstraction-Control (Представление-Абстракция-Контроллер), Microkernel (микроядро), Reflection (отражение).

Клиент-серверная архитектураСерверы обслуживают клиентов с помощью запросовНизкое сцепление между компонентами«Узкий» интерфейсШаблон «Facade»Архитектура параллельно взаимодействующих процессовПараллельный запуск нескольких процессов (потоков, нитей)Шаблон «Observer» (наблюдатель)Репозиторные архитектуры Виды репозиторных архитектур: – Базы данных – Гипертекстовые системы – Доски объявлений Шаблон «Iterator»Уровневые архитектуры Уровень = Слой (Layer) Видимость «сверху вниз» Инкапсуляция внутренних слоев Высокая степень автономности слоев Количество уровней Особенности реализации уровней.

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

Паттерн проектирования ПО – это описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте [GoF]Следует отличать паттерны проектирования от идиом. – Паттерны проектирования не зависят от выбора языка (хотя их реализации, зачастую, зависимы от языка программирования). – Идиомы — это паттерны, описывающие типичные решения на конкретном языке программирования.В общем случае каждый паттерн состоит из таких составляющих: Имя является уникальным идентификатором паттерна. Имена паттернов проектирования, описанных в [GoF], являются общепринятыми. Задача описывает ситуацию, в которой можно применять паттерн. Решения задачи проектирования в виде паттерна определяет общие функции каждого элемента дизайна и отношения между ними. Результаты представляют следствия применения паттерна. 

Идея паттернов проектирования первоначально возникла в архитектуре.  Архитектор Кристофер Александр – автор двух революционных книг, содержащих описание шаблонов в строительной архитектуре и городском планировании Предложил общие идеи, которые используются и в областях, не имеющих отношения к архитектуре, в том числе и в программировании.  В 1987 году Кент Бэк (Kent Beck) и Вард Каннигем (Ward Cunningham) разработали шаблоны разработки ПО для графических оболочек на языке Smalltalk В 1991 году Эрих Гамма совместно с Ричардом Хелмом (Richard Helm), Ральфом Джонсоном (Ralph Johnson) и Джоном Влиссидсом (John Vlissides) публикует книгу «Design Patterns — Elements of Reusable Object-Oriented Software» [GoF91].  – Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. «Приемы объектно-ориентированного проектирования. Паттерны проектирования.» - СПб: Питер, 2001. - 386 с. В этой книге описаны 23 паттерна проектирования.  Мэри Шоу (Mary Shaw), Дэвид Гарлан (David Garlan), 1996 Опубликовали книгу «Архитектура программного обеспечения» – классификация архитектурных стилей;  Мартин Фаулер (Martin Fowler) опубликовал книгу «Архитектура корпоративных программных приложений» - типовые решения при разработке КИС, – Например, работа с базами данных, транзакциями и т.п.; Джошуа Кериевски (Joshua Kerievsky) показал, как можно постоянным рефакторингом, руководствуясь базовыми принципами ООП, обеспечить эволюцию кода, перемещая его от одного паттерна к другому в зависимости от требований; После начала активного использования модульного тестирования (Unit Testing) программного кода все паттерны при этом были переосмыслены с позиций тестируемости.

23 базовых шаблонаШаблоны создания (Creational patterns) - builder, factory, prototype, singletonСтруктурные шаблоны (Structural patterns) - adapter, bridge, composite, decorator, façade, flyweight, proxyШаблоны поведения (Behavioral patterns) - command, interpreter, iterator, mediator, memento, observer, state, strategy, template, visitorКритерии классификации Паттерны проектирования различаются степенью детализации и уровнем абстракцииПаттерны можно классифицировать по двум критериям :– Цель -- отражает назначение паттерна.– Уровень -- говорит о том, к чему обычно применяется паттерн.

Классификация паттернов по целям:Порождающие паттерны (Creational Patterns). – Определяют способы создания объектов в системе. Структурные паттерны (Structural Patterns). – Описывают способы построение сложных структур из классов и объектов. Поведенческие паттерны (Behavioral Patterns). – Описывают способы взаимодействия между объектами.Классификация паттернов по уровням:уровень - говорит о том, к чему обычно применяется паттерн: – уровень классов - описывают отношения между классами и их подклассами. такие отношения выражаются с помощью наследования, поэтому они статичны, то есть зафиксированы на этапе компиляции. –уровень объектов - описывают отношения между объектами, которые могут изменяться во время выполнения и потому более динамичны. 

Классификация архитектурных стилей Show&GarlanАрхитектура потоков данных– Последовательные пакеты– Каналы и фильтрыОбрабатывающие модули ждут данных, чтобы начать свою работу–Каждый процесс обработки данных проектируется независимо–Данные поступают, обрабатываются и передаются.Независимые компонентыСостоит из компонент, работающих независимо и обменивающихся между собой информацией– Параллельно взаимодействующие процессы – Клиент-серверные системы – Системы, управляемые событиями.Виртуальные машиныРепозиторные архитектурыУровневые архитектуры.

1. Архитектурные стили (шаблоны архитектуры) - п. 3.2 в Swebook – Описывают фундаментальные способы структурирования программных систем. – Относятся к уровню систем и подсистем, а не классов 2. Шаблоны проектирования - п. 3.3 в Swebook – Описывают структуру программных систем в терминах классов и объектов 3. Идиомы, специфичные для конкретного языка программирования.

Слой представления (Presentation) Слой предметной области или домен (Domain) Источник данных (Data Source)

Отдельный слой можно воспринимать как единое самодостаточное целое, не особенно заботясь о наличии других) Можно выбирать альтернативную реализацию базовых слоев Зависимость между слоями можно свести к минимуму.Каждый слой является удачным кандидатом на стандартизацию (например, TCP иСозданный слой может служить основой для нескольких различных слоев более высокого уровня 

Предоставить легко воспринимаемый и выразительный язык визуального моделирования, предназначенный для разработки и документирования моделей сложных систем самого различного целевого назначенияСнабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей систем в конкретной предметной области Описание языка UML должно поддерживать такую спецификацию моделей, которая не зависит от конкретных языков программирования и инструментальных средств проектирования программных систем. Обеспечить семантический базис для понимания общих особенностей ООАП Поощрять развитие рынка объектных инструментальных средств Способствовать распространению объектных технологий и соответствующих понятий ООАПИнтегрировать в себя новейшие и наилучшие достижения практики ООАП. 

1995-96 гг. – “Три Амиго” работают над предварительными версиями UML в Rational Software Corporation 1996-97 гг. – представители софтверной индустрии организуют консорциум для работы над проектом стандарта UML 1997 г. – OMG принимает стандарт UML 1.1 2005 г. UML 1.4.2 принят в качестве международного стандарта ISO/IEC 19501:2005 2005 г. – опубликована версия 2.0. 2011 г. – опубликована версия 2.4.1. 2012 г. она получила статус ISO/IEC 19505 2015 г. – опубликована версия 2.5. 

Диаграмма вариантов использования (use case diagram)Цели UC D:Определить границы и контекст моделируемой предметной области на начальных этапах проектирования системыСформулировать общие требования к функционированию проектируемой системыРазработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей Подготовить начальную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. Диаграмма классов (class diagram)Служит для представления и документирования статической структуры модели системыОтражает взаимосвязи между отдельными сущностями предметной области, такими как классы и подсистемы, а также описывает их внутреннюю структуру и типы отношенийНе указывает информацию о динамике функционирования системы.Диаграммы поведения (behavior diagrams)Диаграмма объектов UML (object diagram)Является экземпляром диаграммы классовДиаграммы объектов имеют вспомогательный характер —это примеры, показывающие, какие имеются объекты и связи между ними в некоторый конкретный момент функционирования системы.Диаграммы реализации (implementation diagrams) 

Диаграмма вариантов использования (Use Case Diagram)

Цели UCD (Use Case Diagram):Определить границы и контекст моделируемой предметной области на начальных этапах проектирования системыСформулировать общие требования к функционированию проектируемой системыРазработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделейПодготовить начальную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. 

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

Является экземпляром диаграммы классовДиаграммы объектов имеют вспомогательный характер — это примеры,показывающие, какие имеются объекты и связи между ними в некоторый конкретный момент функционирования системы.

Диаграмма деятельности (activity diagram)Диаграмма состояний (statechart diagram)Диаграммы взаимодействия (interaction diagrams): -Диаграмма последовательности (sequence diagram) -Диаграмма кооперации (collaboration diagram)

Activity DiagramСтруктура последовательного выполненияДиаграмма действий позволяет проиллюстрировать вариант использования с требуемой степенью подробности.Линейный вариант использования приводит к диаграмме действий с линейным потоком управления между действиями.Структура параллельного выполненияПараллелизм – средство ускорения вычислительных процессовЛинейка синхронизации - средство для описания параллелизмаИспользование дорожек.UML предлагает вариант с «плавательными дорожками». Это удобно, когда в варианте использования участвуют несколько акторов.

State chart Diagram (ScD)Основные компоненты описания системы:Простые состояния,Составные состояния,Символы «старт» и «стоп»,Переходы,Линейки синхронизации.Состояние Диаграмма состояний позволяет описать систему в более, чем одном варианте использования.Состояние характеризуется именемСостояние может быть задано в виде набора конкретных значений атрибутов класса или объекта, при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта.СобытиеПереход системы из состояния в состояние осуществляется при наступлении событий. В языке UML события играют роль стимулов, которые инициируют переходы из одних состояний в другие. В качестве событий можно рассматривать сигналы, вызовы, окончание фиксированных промежутков времени или моменты окончания выполнения определенных действий.ПереходПри наступлении событий переход срабатывает.Переход может быть безальтернативным, либо содержать альтернативы.Альтернативный переход обусловлен наступлением сторожевых условий. Событие может сопровождаться выражением действия, которое происходит в случае, если срабатывает переход.

Можно объединить часть состояний в одно составное состояние.При этом возможны переходы:-между подчинёнными состояниями,-между подчинённым и внешним состояниями и-переходы между составным и внешним состоянием.

Список основных действий включает следующие значения: entry - действие, которое выполняется в момент входа в данное состояние (входное действие);exit - действие, которое выполняется в момент выхода из данного состояния (выходное действие);do - выполняющаяся деятельность ("do activity") в течение всего времени, пока объект находится в данном состоянии.

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

Крайним слева на диаграмме изображается объект, который является инициатором взаимодействия.Правее изображается другой объект, который непосредственно взаимодействует с первым. Все объекты на диаграмме последовательности образуют некоторый порядок, определяемый степенью активности этих объектов при взаимодействии друг с другом. Второе измерение диаграммы последовательности - вертикальная временная ось, направленная сверху вниз. Начальному моменту времени соответствует самая верхняя часть диаграммы. Взаимодействия объектов реализуются посредством сообщений, которые посылаются одними объектами другим.Сообщения изображаются в виде горизонтальных стрелок с именем сообщения и также образуют порядок по времени своего возникновения. Сообщения, расположенные на диаграмме последовательности выше, инициируются раньше тех, которые расположены ниже. При этом масштаб на оси времени не указывается, поскольку диаграмма последовательности моделирует лишь временную упорядоченность взаимодействий типа "раньше-позже".Отдельные объекты, выполнив свою роль в системе, могут быть уничтожены (разрушены), чтобы освободить занимаемые ими ресурсы. Для таких объектов линия жизни обрывается в момент его уничтожения. Для обозначения момента уничтожения объекта в языке UML используется специальный символ в форме латинской буквы "X" Ниже этого символа пунктирная линия не изображается, поскольку соответствующего объекта в системе уже нет, и этот объект должен быть исключен из всех последующих взаимодействий. не обязательно создавать все объекты в начальный момент времени. Отдельные объекты могут создаваться по мере необходимости, экономя ресурсы системы и повышая ее производительность.Прямоугольник такого объекта изображается не в верхней части диаграммы последовательности, а в той ее части, которая соответствует моменту создания объекта Прямоугольник объекта располагается в месте диаграммы, которое по оси времени совпадает с моментом его возникновения в системе. Объект обязательно создается со своей линией жизни и, возможно, с фокусом управления.Фокус управленияВ процессе функционирования объектно- ориентированных систем одни объекты могут находиться в активном состоянии, непосредственно выполняя определенные действия или в состоянии пассивного ожидания сообщений от других объектов. Чтобы явно выделить подобную активность объектов, в языке UML применяется специальное понятие, получившее название фокуса управления (focus of control)Фокус управления изображается в форме вытянутого узкого прямоугольника, верхняя сторона которого обозначает начало получения фокуса управления объекта (начало активности), а ее нижняя сторона - окончание фокуса управления (окончание активности).Этот прямоугольник располагается ниже обозначения соответствующего объекта и может заменять его линию жизни, если на всем ее протяжении он является активным.С другой стороны, периоды активности объекта могут чередоваться с периодами его пассивности или ожидания. В этом случае у такого объекта имеются несколько фокусов управления.Получить фокус управления может только существующий объект, у которого в этот момент имеется линия жизни. Если же некоторый объект был уничтожен, то вновь возникнуть в системе он уже не может. Вместо него лишь может быть создан другой экземпляр этого же класса, который, строго говоря, будет являться другим объектомСообщенияСообщения не только передают некоторую информацию, но и требуют или предполагают от принимающего объекта выполнения ожидаемых действий.Сообщения могут инициировать выполнение операций объектом соответствующего класса, а параметры этих операций передаются вместе с сообщением.На диаграмме последовательности все сообщения упорядочены по времени своего возникновения в моделируемой системе.

Кооперация - одно из фундаментальных понятий UML.Предназначена для спецификации структурных аспектов взаимодействия.Обозначает множество взаимодействующих с определенной целью объектов. Цель кооперации – специфицировать особенности реализации отдельных наиболее значимых операций в системе.Уровни представления кооперацииНа уровне спецификации - показывает роли классов и роли ассоциаций в рассматриваемом взаимодействии.На уровне примеров - указывает экземпляры и связи, образующие отдельные роли в кооперации.Диаграмма кооперации уровня спецификацииПоказывает роли, которые играют участвующие во взаимодействии элементы Изображается на диаграмме пунктирным эллипсом, внутри которого записывается имя этой кооперации Относится к отдельному варианту использования и детализирует особенности его последующей реализации.Диаграмма кооперации уровня примеровПредставляется совокупностью объектов (экземпляры классов) и связей (экземпляры ассоциаций). Связи дополняются стрелками сообщений. Время не указывается в виде отдельного измерения.Последовательность взаимодействий может быть определена с помощью порядковых номеров.

Диаграммы реализации (implementation diagrams)Диаграмма компонентов (component diagram)Диаграмма развертывания (deployment diagram)

Все рассмотренные ранее диаграммы отражали концептуальные аспекты построения модели системы и относились к логическому уровню представления Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. Цели диаграммы компонентов:Визуализация общей структуры исходного кода программной системы Спецификация исполнимого варианта программной системы Обеспечение многократного использования отдельных фрагментов программного кода.Документирует архитектуру разрабатываемой системы, установив зависимости между программными компонентами, в роли которых может выступать исходный, бинарный и исполняемый кодВо многих средах разработки модуль или компонент соответствует файлуОсновные графические элементы диаграммы компонентов – компоненты, интерфейсы и зависимости между ними. Компонент (component).Компонент – средство представления физических сущностей в языке UML Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления моделиДля графического представления компонента может использоваться специальный символ - прямоугольник со вставленными слева двумя более мелкими прямоугольникамиВиды компонентов 1. Компоненты развертывания, которые обеспечивают непосредственное выполнение системой своих функций:– (а)динамически подключаемые библиотеки (dll)– (б) web-страницы (html),– (в) файлы справки (hlp).2. (г) Компоненты-рабочие продукты. Как правило - это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++3. Компоненты исполнения, представляющие исполнимые модули - файлы с расширением ехе. Они обозначаются обычным образом. Зависимости и реализациикомпонент с именем "main.exe" зависит от импортируемого интерфейса IDialog, который, в свою очередь, реализуется компонентом с именем "image.java". Для второго компонента этот же интерфейс является экспортируемымотношение между различными видами компонентов. внесение изменений в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонентаОтношения зависимости между компонентами и задействованными в них классами. Для обеспечения согласования логического и физического представлений модели системы.Следует заметить, что в данном случае из диаграммы компонентов не следует, что классы реализованы этим компонентом.

Предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime)Представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотекамиСодержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, ДР едина для системы в целом, поскольку должна всецело отражать особенности ее реализации.Цели диаграммы развертыванияОпределить распределение компонентов системы по ее физическим узламПоказать физические связи между всеми узлами реализации системы на этапе ее исполненияВыявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности. Узел (node) физически существующий элемент системы, обладающий некоторым вычислительным ресурсом на основеэлектронной или магнитооптической памяти и/или процессораВ последних версиях UML понятие узла расширено и может включать в себя не только вычислительные ресурсы, но и другие механические или электронные устройства, такие как датчики, принтеры, модемы, цифровые камеры, сканеры и манипуляторы. Узлы могут представляться как в качестве типов, так и в качестве экземпляров.Изображения узлов могут расширяться, чтобы включить некоторую дополнительную информацию о спецификации узлаЕсли дополнительная информация относится к имени узла, то она записывается под этим именем в форме помеченного значенияОтношения между узламифизические соединения между узлами и зависимости между узлами и компонентамиСоединения Являются разновидностью ассоциации и изображаются отрезками линий без стрелок. Наличие такой линии указывает на необходимость организации физического канала для обмена информацией между соответствующими узлами. Характер соединения может быть дополнительно специфицирован примечанием, помеченным значением или ограничением. ЗависимостиЭто - альтернатива вложенному изображению компонентов внутри символа узла, что не всегда удобно

Диаграмма автомата (State machine diagram) – вместо диаграммы состояний Диаграмма коммуникации (Communication diagram) – вместо диаграммы кооперации Диаграмма пакетов (Package diagram) Обзорная диаграмма взаимодействия (Interaction Overview diagram) Диаграмма внутренней структуры (Composite Structure diagram) Диаграмма синхронизации (Timing diagram).