МиСПИСиТ-Тема3

Больше похоже на это

Программная инженерия

от Меньщикова Юлия

ООП

от Ментальная Карта

Язык программирования

от Alexandr Semenovskiy

История языков программировния

от Власов Владимир

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

Введение в UML

Что нового в UML

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

• Диаграмма вариантов использования (use case diagram)

Цели UC D:

1. Определить границы и контекст моделируемой предметной области на начальных этапах проектирования системы
2. Сформулировать общие требования к функционированию проектируемой системы
3. Разработать исходную концептуальную модель системы для ее последующей детализации в форме логических и физических моделей Подготовить начальную документацию для взаимодействия разработчиков системы с ее заказчиками и пользователями. 

• Диаграмма классов (class diagram)

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

• Диаграммы поведения (behavior diagrams)
• Диаграмма объектов UML (object diagram)

Является экземпляром диаграммы классов

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

• Диаграммы реализации (implementation diagrams) 

Диаграмма реализации

Диаграммы реализации (implementation diagrams)

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

Диаграмма развертывания (deployment diagram)

Предназначена для визуализации элементов и компонентов программы, существующих лишь на этапе ее исполнения (runtime)

Представляются только компоненты-экземпляры программы, являющиеся исполнимыми файлами или динамическими библиотеками

Содержит графические изображения процессоров, устройств, процессов и связей между ними. В отличие от диаграмм логического представления, ДР едина для системы в целом, поскольку должна всецело отражать особенности ее реализации.

Цели диаграммы развертывания

• Определить распределение компонентов системы по ее физическим узлам
• Показать физические связи между всеми узлами реализации системы на этапе ее исполнения
• Выявить узкие места системы и реконфигурировать ее топологию для достижения требуемой производительности. 

Узел (node) 

• физически существующий элемент системы, обладающий некоторым вычислительным ресурсом на основе
• электронной или магнитооптической памяти и/или процессора
• В последних версиях UML понятие узла расширено и может включать в себя не только вычислительные ресурсы, но и другие механические или электронные устройства, такие как датчики, принтеры, модемы, цифровые камеры, сканеры и манипуляторы. 
• Узлы могут представляться как в качестве типов, так и в качестве экземпляров.
• Изображения узлов могут расширяться, чтобы включить некоторую дополнительную информацию о спецификации узла
• Если дополнительная информация относится к имени узла, то она записывается под этим именем в форме помеченного значения

Отношения между узлами

физические соединения между узлами и зависимости между узлами и компонентами

Соединения 

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

Характер соединения может быть дополнительно специфицирован примечанием, помеченным значением или ограничением. 

Зависимости

Это - альтернатива вложенному изображению компонентов внутри символа узла, что не всегда удобно

Диаграмма компонентов (component diagram)

Все рассмотренные ранее диаграммы отражали концептуальные аспекты построения модели системы и относились к логическому уровню представления 

Диаграмма компонентов, в отличие от ранее рассмотренных диаграмм, описывает особенности физического представления системы. 

Цели диаграммы компонентов:

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

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

Во многих средах разработки модуль или компонент соответствует файлу

Основные графические элементы диаграммы компонентов – компоненты, интерфейсы и зависимости между ними. 

Компонент (component).

• Компонент – средство представления физических сущностей в языке UML 
• Компонент реализует некоторый набор интерфейсов и служит для общего обозначения элементов физического представления модели
• Для графического представления компонента может использоваться специальный символ - прямоугольник со вставленными слева двумя более мелкими прямоугольниками

Виды компонентов

 1. Компоненты развертывания, которые обеспечивают непосредственное выполнение системой своих функций:

– (а)динамически подключаемые библиотеки (dll)

– (б) web-страницы (html),

– (в) файлы справки (hlp).

2. (г) Компоненты-рабочие продукты. Как правило - это файлы с исходными текстами программ, например, с расширениями h или срр для языка C++

3. Компоненты исполнения, представляющие исполнимые модули - файлы с расширением ехе. Они обозначаются обычным образом. 

Зависимости и реализации

• компонент с именем "main.exe" зависит от импортируемого интерфейса IDialog, который, в свою очередь, реализуется компонентом с именем "image.java". Для второго компонента этот же интерфейс является экспортируемым
• отношение между различными видами компонентов. 
• внесение изменений в исходные тексты программ или динамические библиотеки приводит к изменениям самого компонента
• Отношения зависимости между компонентами и задействованными в них классами. 
• Для обеспечения согласования логического и физического представлений модели системы.
• Следует заметить, что в данном случае из диаграммы компонентов не следует, что классы реализованы этим компонентом.

Диаграмма поведения

• Диаграмма деятельности (activity diagram)
• Диаграмма состояний (statechart diagram)
• Диаграммы взаимодействия (interaction diagrams):

-Диаграмма последовательности (sequence diagram)

-Диаграмма кооперации (collaboration diagram)

Диаграммы взаимодействия (interaction diagrams)

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

Диаграмма кооперации (collaboration diagram)

Кооперация - одно из фундаментальных понятий UML.

Предназначена для спецификации структурных аспектов взаимодействия.

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

Цель кооперации – специфицировать особенности реализации отдельных наиболее значимых операций в системе.

Уровни представления кооперации

• На уровне спецификации - показывает роли классов и роли ассоциаций в рассматриваемом взаимодействии.
• На уровне примеров - указывает экземпляры и связи, образующие отдельные роли в кооперации.

Диаграмма кооперации уровня спецификации

• Показывает роли, которые играют участвующие во взаимодействии элементы 
• Изображается на диаграмме пунктирным эллипсом, внутри которого записывается имя этой кооперации 
• Относится к отдельному варианту использования и детализирует особенности его последующей реализации.

Диаграмма кооперации уровня примеров

• Представляется совокупностью объектов (экземпляры классов) и связей (экземпляры ассоциаций). 
• Связи дополняются стрелками сообщений. 
• Время не указывается в виде отдельного измерения.
• Последовательность взаимодействий может быть определена с помощью порядковых номеров.

Диаграмма последовательности (sequence diagram)

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

Фокус управления

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

Сообщения

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

Внутреннее поведение (диаграммы состояний и деятельности)

Список основных действий включает следующие значения: 

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

Диаграмма состояний (statechart diagram)

State chart Diagram (ScD)

Основные компоненты описания системы:

• Простые состояния,
• Составные состояния,
• Символы «старт» и «стоп»,
• Переходы,
• Линейки синхронизации.

Состояние 

• Диаграмма состояний позволяет описать систему в более, чем одном варианте использования.
• Состояние характеризуется именем
• Состояние может быть задано в виде набора конкретных значений атрибутов класса или объекта, при этом изменение их отдельных значений будет отражать изменение состояния моделируемого класса или объекта.

Событие

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

Переход

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

SCD - Составное состояние

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

-между подчинёнными состояниями,

-между подчинённым и внешним состояниями и

-переходы между составным и внешним состоянием.

Диаграмма деятельности (activity diagram)

Activity Diagram

Структура последовательного выполнения

Диаграмма действий позволяет проиллюстрировать вариант использования с требуемой степенью подробности.

Линейный вариант использования приводит к диаграмме действий с линейным потоком управления между действиями.

Структура параллельного выполнения

• Параллелизм – средство ускорения вычислительных процессов
• Линейка синхронизации - средство для описания параллелизма

Использование дорожек.

UML предлагает вариант с «плавательными дорожками». Это удобно, когда в варианте использования участвуют несколько акторов.

Диаграмма объектов UML

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

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

Диаграмма вариантов использования

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

Цели UCD

Цели UCD (Use Case Diagram):

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

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

SWEBOK. Область знаний «Проектирование ПО»

Типовые решения в проектировании ПО

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

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

– (другой тип приложения, другая платформа или другой язык программирования),

– все обычно заканчивается повторением проектирования и реализации данного решения,

– тем самым возникает ситуация «повторного изобретения колеса».

Преимущества "Расслоения"

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

Эталонная трехслойная модель

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

Иерархия типовых решений

1. Архитектурные стили (шаблоны архитектуры) - п. 3.2 в Swebook

– Описывают фундаментальные способы структурирования программных систем.

– Относятся к уровню систем и подсистем, а не классов

2. Шаблоны проектирования - п. 3.3 в Swebook

– Описывают структуру программных систем в терминах классов и объектов

3. Идиомы, специфичные для конкретного языка программирования.

Зачем нужны шаблоны:

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

Опредение

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

Схема решения проблемы задается путем:

– определения используемых (составляющих) компонент;

– их ответственностей;

– способов их взаимодействия.

Паттерны

Паттерн проектирования ПО – это описание взаимодействия объектов и классов, адаптированных для решения общей задачи проектирования в конкретном контексте [GoF]

Следует отличать паттерны проектирования от идиом.

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

– Идиомы — это паттерны, описывающие типичные решения на конкретном языке программирования.

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

1. Имя является уникальным идентификатором паттерна. Имена паттернов проектирования, описанных в [GoF], являются общепринятыми.
2. Задача описывает ситуацию, в которой можно применять паттерн.
3. Решения задачи проектирования в виде паттерна определяет общие функции каждого элемента дизайна и отношения между ними.
4. Результаты представляют следствия применения паттерна. 

Классификация шаблонов Gamma и др

• 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

Критерии классификации

Паттерны проектирования различаются степенью детализации и уровнем абстракции

Паттерны можно классифицировать по двум критериям :

– Цель -- отражает назначение паттерна.

– Уровень -- говорит о том, к чему обычно применяется паттерн.

Классификация архитектурных стилей Show&Garlan

Классификация архитектурных стилей Show&Garlan

• Архитектура потоков данных

– Последовательные пакеты

– Каналы и фильтры

Обрабатывающие модули ждут данных, чтобы начать свою работу

–Каждый процесс обработки данных проектируется независимо

–Данные поступают, обрабатываются и передаются.

• Независимые компоненты

Состоит из компонент, работающих независимо и обменивающихся между собой информацией

– Параллельно взаимодействующие процессы

– Клиент-серверные системы

– Системы, управляемые событиями.

• Виртуальные машины
• Репозиторные архитектуры
• Уровневые архитектуры.

Классификация по целям и уровням паттернов проектирования

Классификация паттернов по целям:

1. Порождающие паттерны (Creational Patterns). – Определяют способы создания объектов в системе.
2. Структурные паттерны (Structural Patterns). – Описывают способы построение сложных структур из классов и объектов.
3. Поведенческие паттерны (Behavioral Patterns). – Описывают способы взаимодействия между объектами.

Классификация паттернов по уровням:

уровень - говорит о том, к чему обычно применяется паттерн:

– уровень классов - описывают отношения между классами и их подклассами.

• такие отношения выражаются с помощью наследования, поэтому они статичны, то есть зафиксированы на этапе компиляции.

–уровень объектов - описывают отношения между объектами, которые могут изменяться во время выполнения и потому более динамичны.

Появление паттернов

Идея паттернов проектирования первоначально возникла в архитектуре. 

Архитектор Кристофер Александр – автор двух революционных книг, содержащих описание шаблонов в строительной архитектуре и городском планировании

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

В 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) программного кода все паттерны при этом были переосмыслены с позиций тестируемости.

Шаблоны проектирования

Шаблоны проектирования это шаблоны среднего уровня.

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

Применение шаблонов проектирования не влияет на базовую структуру ПС, но может оказать сильное влияние на архитектуру подсистем.

Шаблоны Архитектуры ПО

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

Влияют на:

– коммуникацию и взаимодействие между разными частями системы;

– их последующее расширение.

Каждый архитектурный шаблон помогает разработчику достигнуть некоторого глобального свойства разрабатываемой системы,

– Например, адаптируемости пользовательского интерфейса.

Примеры архитектурных шаблонов

1. Layers (Уровни),
2. Pipes and Filters (каналы и фильтры),
3. Blackboard (информационная "доска"),
4. Broker (брокер),
5. Model-View-Controller (Модель- Представление-Контроллер), Presentation-Abstraction-Control (Представление-Абстракция-Контроллер),
6. Microkernel (микроядро),
7. Reflection (отражение).

Шаблоны для архитектур

Клиент-серверная архитектура

• Серверы обслуживают клиентов с помощью запросов
• Низкое сцепление между компонентами
• «Узкий» интерфейс
• Шаблон «Facade»

Архитектура параллельно взаимодействующих процессов

• Параллельный запуск нескольких процессов (потоков, нитей)
• Шаблон «Observer» (наблюдатель)

Репозиторные архитектуры 

• Виды репозиторных архитектур:

– Базы данных

– Гипертекстовые системы

– Доски объявлений 

• Шаблон «Iterator»

Уровневые архитектуры 

• Уровень = Слой (Layer)
• Видимость «сверху вниз»
• Инкапсуляция внутренних слоев
• Высокая степень автономности слоев
• Количество уровней
• Особенности реализации уровней.

Свойства шаблонов

Свойства:

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

Причины возникновения типовых решений в проектировании ПО

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

Эти решения требовали – систематизации, – обобщения на всевозможные ситуации, – доступного описания, способствующего пониманию их людьми, которые до этого никогда их не использовали.

Такое упорядочение знаний в ОО проектировании позволило бы повторно использовать готовые и уже проверенные решения.

Решение данной проблемы взяли на себя шаблоны (паттерны) проектирования.

Стиль мышления эксперта

• При решении конкретных проблем эксперты обычно не пытаются разработать новое решение, который отличается от уже имеющихся.

Действия эксперта:

– вспоминают аналогичную проблему, которую они уже решали,

– стараются повторно используют суть ранее принятого решения для решения новой проблемы.

• Такой «стиль мышление» в терминах пар «проблема - решение», является общим для множества различных предметных областей, таких, как:

– архитектура;

– экономика;

– программная инженерия.

Кристофер Александер:

Каждое типовое решение описывает задачу, которая снова и снова возникает в нашей работе, а также принцип её решения, причем таким образом, что решение можно использовать миллион раз, ничего не изобретая заново. (Кристофер Александр). 

Дополнительные области SWEBOK

1. Конфигурационное управление

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. Практические соображения

Основные области SWEBOK

1. Требования

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. Язык
2. Видимость
3. Семантика отношений, отображение на атрибуты
4. Методы, отображение на методы
5. Отложенные решения: требования к реализации класса
6. Класс может быть реализован в виде интерфейса ЯП
7. Класс может быть активным

• Проект реализации - это кооперация, определяющая реализацию конкретного варианта использования в терминах классов проектирования и их объектов. 

Содержит:

– Диаграммы классов

– Диаграммы взаимодействий

– Текстовое описание потока событий

– Требования к реализации

• Интерфейс
• Описание архитектуры (представления модели проектирования и модели развертывания)
• Модель развертывания

Стратегии и методы проектирования ПО

1. Общие стратегии (General Strategies)

• Декомпозиция и пошаговое уточнение
• Проектирование “сверху-вниз”
• Проектирование “снизу-вверх”
• Абстракция данных и сокрытие информации
• Итеративный и инкрементный подход
• и др...

2. Функционально-ориентированное или структурное проектирование (Function-Oriented – Structured Design)

3. Объектно-ориентированное проектирование (Object-Oriented Design)

4. Проектирование на основе структур данных (DataStructure-Centered Design)

5. Компонентное проектирование (Component-Based Design)

Нотации проектирования

1. Структурные описания, статический взгляд (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): используются для представления сложных комбинаций условий и действий (операций).

Анализ качества и оценка результатов

Анализ качества и оценка результатов проектирования ПО (Software Design Quality Analysis and Evaluation)

1. Атрибуты качества (Quality Attributes)
2. Анализ качества и техники оценки (Quality Analysis and Evaluation Techniques)
3. Измерения (Measures).

Атрибуты качества

• применимые к run-time, то есть ко времени выполнения системы - например, атрибут «среднее время отклика системы», позволяющий оценить качество проекта с точки зрения производительности;
• ориентированные на design-time, то есть позволяющие оценивать качество получаемого проекта еще на этапе проектирования - например, средняя нагруженность классов бизнес- методами; непротиворечивость, полнота, завершенность. 

Анализ качества и техники оценки

• просмотр (software design review); например, неформальный обзор архитектуры членами проектной команды;
• статический анализ (static analysis); например, трассировка с требованиями;
• симуляция и прототипирование (simulation and prototyping) – динамические техники проверки проекта в целом или отдельных его атрибутов качества - например, для оценки производительности используемых архитектурных решений при симуляции нагрузки, близкой к прогнозируемым пиковым.

Измерения (метрики)

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

1. функционально-ориентированные
2. объектно-ориентированные

Структура и архитектура ПО

1. Архитектурные структуры и точки зрения (Architectural Structures and Viewpoints)

2. Архитектурные стили (Architectural Styles)

3. Шаблоны проектирования (Design Patterns)

4. Семейства программ и фреймворков (Families of Programs and Frameworks)

Шаблоны

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

Применяется как на стадии архитектурного, так и детального проектирования.

Архитектурные стили

Архитектурные стили

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

Классификация архитектур

• Gamma - Braude – Эрик Брауде. Технология разработки программного обеспечения – СПб, Питер, 2004

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

• Show & Garlan – Mary Shaw and David Garlan, Software Architecture -- Perspectives on an Emerging Discipline, Prentice Hall, 1996

1. Архитектура потоков данных
2. Независимые компоненты
3. Виртуальные машины
4. Репозиторные архитектуры

Виды репозиторных архитектур:

– Базы данных

– Гипертекстовые системы

– Доски объявлений

Шаблон «Iterator»

5. Уровневые архитектуры.

• Fowler – М.Фаулер. Архитектура корпоративных программных приложений.: — М.: Из­дательский дом "Вильямс", 2006.
• Архитектура потоков данных

– Последовательные пакеты – Каналы и фильтры

Каждый процесс обработки данных проектируется независимо Данные поступают, обрабатываются и передаются.

• Архитектура каналов и фильтров

Обрабатывающие модули ждут данных, чтобы начать свою работу

• Архитектура независимых компонент

Состоит из компонент, работающих независимо и обменивающихся между собой информацией

– Параллельно взаимодействующие процессы

Параллельный запуск нескольких процессов (потоков, нитей). Шаблон «Observer» (наблюдатель)

– Клиент-серверные системы

Серверы обслуживают клиентов с помощью запросов

Низкое сцепление между компонентами

«Узкий» интерфейс

Шаблон «Facade»

– Системы, управляемые событиями.

• Уровневые архитектуры

Уровень = Слой (Layer)

Видимость «сверху вниз»

Инкапсуляция внутренних слоев

Высокая степень автономности слоев

Количество уровней

Особенности реализации уровней.

Точки зрения

Точки зрения

Любая система может рассматриваться с разных точек зрения – например,

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

Ключевые вопросы проектирования

1. Параллелизм (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.1. Общие концепции проектирования

1.2. Контекст проектирования ПО

1.3. Процесс проектирования ПО

1.4. Принципы проектирования ПО

Принципы проектирования ПО

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

Достаточность, полнота и простота

Достаточность, полнота и простота (Sufficiency, completeness and primitiviness)

Этот подход подразумевает, что создаваемые программные компоненты обладают всеми необходимыми характеристиками, определенными абстракцией (моделью), но не более того.

То есть не включают функциональность, отсутствующую в модели.

Данный принципy наиболее ярко представлен в гибких (agile) подходах к разработке ПО через метафору YAGNI

“You Aren’ t Going to Need It”, то есть “не делай этого, пока не понадобится”.

Разделение интерфейса и реализации

Разделение интерфейса и реализации (Separation of interface and implementation)

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

Инкапсуляция/сокрытие информации

Инкапсуляция/сокрытие информации (Encapsulation/information hiding)

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

Декомпозиция и разбиение на модули

Декомпозиция и разбиение на модули (Decomposition and Modularization)

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

Связанность и связанность

Связанность и связанность (Coupling and Cohesion)

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

Абстракция (Abstraction)

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

Объектно-ориентированный подход. Основы UML

Диаграмма классов UML (class diagram)

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

Именование класса

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

Основные отношения между классами

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

Строки-ограничения для отношения обобщения

{complete} - указаны все классы-потомки, и других потомков быть не может.

{incomplete} - противоположный случай

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

{overlapping} - отдельные экземпляры классов- потомков могут принадлежать одновременно нескольким классам

Обобщение (generalization relationship)

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

Композиция (composition relationship)

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

Агрегация (aggregation relationship)

Ассоциация (association relationship)

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

Исключающая ассоциация

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

n-арная ассоциация

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

Интерфейс

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

А) Процесс разделения элементов абстракции, которые образуют ее структуру и поведение.

Отделение внешних обязательств объекта от его реализации

Б) Сокрытие внутренней структуры данных и реализации методов объекта от остальной программы.

Другим объектам доступен только интерфейс объекта, через который осуществляется взаимодействие

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

Объекты

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

Поведение объекта

• Поведение реализуется через набор операций
• Операция, operation - нечто, проделываемое одним объектом над другим, чтобы вызвать реакцию
• Термины "операция", "метод" и "сообщение" взаимозаменяемы

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

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

"Война методов"

1980е – начало 90х – гг.

• OOSE (Ivar Jacobson)
• OMT (James Rumbaugh),
• Booch (Grady Booch).

OOSE – средства представления вариантов использования

ОМТ-2 –анализ процессов обработки данных в информационных системах

Booch'93 – нашел наибольшее применение на этапах проектирования и разработки различных программных систем. 

UML

Unified Modeling Language

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

Представления сложной системы в UML

Диаграмма вариантов использования (use case diagram) 

• Диаграмма классов (class diagram) 
• Диаграммы поведения (behavior diagrams) 

–Диаграмма состояний (statechart diagram)

–Диаграмма деятельности (activity diagram)

–Диаграммы взаимодействия (interaction diagrams):

Диаграмма последовательности (sequence diagram)

Диаграмма кооперации (collaboration diagram)

• Диаграммы реализации (implementation diagrams) 

–Диаграмма компонентов (component diagram)

–Диаграмма развертывания (deployment diagram) 

Назначение UML

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

Диаграмма классов UML

Диаграмма классов UML (class diagram)

Служит для представления статической структуры модели системы

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

Не указывает информацию о динамике функционирования системы.

Именование классов

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

Основные отношения между классами

Основные отношения между классами:

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

Отношение зависимости (dependency relationship): Возникает, когда один класс использует другой. Используется, когда изменение одного элемента модели может потребовать изменения другого зависимого от него элемента модели

Ассоциация (association relationship)

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

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

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

Агрегация (aggregation relationship) -имеет место между несколькими классами в том случае, если один из классов представляет собой некоторую сущность, включающую в себя в качестве составных частей другие сущности

Композиция (composition relationship) - частный случай агрегации. Части не могут выступать в отрыве от целого, т. е. с уничтожением целого уничтожаются и все его составные части

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

Краткая история 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. 

Объектно-ориентированное программирование (ООП)

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

Истоки ООП

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

Технологии Программирования/Проектирования (П/П)

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

Компонентное П\П

Компонентный подход – развитие объектно- ориентированной идеологии;

Введен следующий уровень абстракции – классы объединяются в компоненты;

Основной принцип компонентного подхода: сборка приложения из готовых компонент, в общем случае написанных на разных языках.

Компонент:

– программный код в виде самостоятельного модуля

– м.б. использован в неизменном виде

– может допускать настройку

– обладает поведением (функциональностью)

Компонент изолирован от внешнего мира своим интерфейсом – набором методов (их сигнатурами)

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

Объектно-ориентированное П\П

• Дальнейшая борьба со сложностью
• Технология работает, начиная с этапа анализа
• Анализ – Проектирование – Программирование
• В основе – объектная модель и объектная декомпозиция

Основные принципы объектной модели:

– абстракция;

– инкапсуляция;

– иерархичность (наследование, агрегация);

– полиморфизм;

– модульность

Объектная декомпозиция (в отличие от алгоритмической): элементы проекта – классы и объекты (а не алгоритмы). Затем – детализация (данные и алгоритмы).

Инкапсуляция

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

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

Абстракция

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

Полиморфизм

«Один интерфейс – много реализаций»

Наследование позволяет использовать экземпляр унаследованного класса, как экземпляр базового класса.

Виды полиморфизма:

• Переопределение (override): в унаследованном классе можно переопределить метод базового класса. 
• Перегрузка (overload): один и тот же класс может иметь методы с одинаковыми именами, но разными сигнатурами. – Перегрузку методов следует использовать, когда методы выполняющие подобные действия, могут принимать различные аргументы.

Наследование

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

Модульное П\П

Основная идея: разбиваем сложную задачу на подзадачи, каждую из них при необходимости разбиваем снова и т.д.;

Получаем простые задачи, их решаем, объединяем.

Модульное П/П – специфичный для задачи базис из модулей.

– Более высокий уровень абстракции.

– Настройка на конкретную задачу.

– Возможности повторного использования.

– Возможности коллективной разработки – разделение труда.

Структурное программирование

Э. Дэйкстра (60-е годы):

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

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

Простая программа – ровно один вход и один выход.

Стандартизация и линейность программы – снижение сложности. Некоторые соображения:

• Алгоритм должен иметь 1 вход и 1 выход
• Никаких goto
• Нет зависимости от языка программирования
• Ясен набор операторов, который необходим в языках программирования
• Алгоритмы + структуры данных = программа.