1. Технология конструирования программного обеспечения (ТКПО) – это система инженерных принципов для создания экономичного ПО, которое надежно и эффективно работает в реальных компьютерах.

Методы ТКПО обеспечивают решение следующих задач:

• планирование и оценка проекта;

• анализ системных и программных требований;

• проектирование алгоритмов, структур данных и программных структур;

• кодирование;

• тестирование;

• сопровождение.

Средства (утилиты) ТКПО обеспечивают автоматизированную или автоматическую поддержку методов. В целях совместного применения утилиты могут объединяться в системы автоматизированного конструирования ПО. Такие системы принято называть CASE-системами. Аббревиатура CASE расшифровывается как Computer Aided Software Engineering (программная инженерия с компьютерной поддержкой).

Процедуры ТКПО соединяют методы и утилиты так, что они обеспечивают непрерывную технологическую цепочку разработки.

Процедуры определяют:

• порядок применения методов и утилит;

• формирование отчетов, форм по соответствующим требованиям;

• контроль, который помогает обеспечивать качество и координировать изменения;

• формирование «вех», по которым руководители оценивают процесс.

Стратегии конструирования:

• однократный проход (водопадная стратегия) – линейная последовательность этапов конструирования с определением всех требований в начале процесса;

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

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

Классический жизненный цикл ПО:

Макетирование:

Инкрементная модель:

Быстрая разработка приложений (RAD - Rapid Application Development):

Спиральная модель:

где:

1 – начальный сбор требований и планирование проекта; 2 – та же работа, но на основе рекомендаций заказчика; 3 – анализ риска на основе начальный требований;

4 – анализ риска на основе реакции заказчика; 5 – переход к комплексной системе;

6 – начальный макет системы; 7 – следующий уровень макета;

8 – сконструированная система; 9 – оценивание заказчиком.

Компонентно-ориентированная модель:

ХР-процесс Экстремальное программирование:

2. Модели качества процессов конструирования.

3. Процесс руководства проектом.

Время

Работы, выполняемые в процессе руководства проектом:

• Начало проекта

• Измерения, меры и метрики

• Процесс оценки

• Анализ риска

• Планирование

• Трассировка и контроль

4. Планирование проектных задач.

WBS – Work Breakdown Structure (структуры распределения работ)

Системный анализ:

Системный анализ проводится с целью:

выяснения потребностей заказчика;

оценки выполнимости системы;

выполнения экономического и технического анализа;

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

определения стоимости и ограничений планирования;

создания системной спецификации.

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

Анализ требований:

Анализ требований дает возможность:

• определить функции и характеристики программного продукта;

• обозначить интерфейс продукта с другими системными элементами;

• определить проектные ограничения программного продукта;

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

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

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

Правило распределения затрат проекта

Рекомендуемое правило распределения затрат проекта – 40-20-40:

• на анализ и проектирование приходится 40% затрат (из них на планирование и системный анализ – 5%);

• на кодирование – 20%;

• на тестирование и отладку – 40%.

• 5. Понятие и предметы url.

• UML – это язык для определения, визуализации, конструирования и документирования артефактов программных систем, а также для моделирования экономических процессов и других не программных систем.

• UML обладает следующими основными характеристиками:

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

• содержит механизмы расширения и специализации базовых концепций языка.

• Структурные предметы:

• Класс реализует один или несколько интерфейсов

• Графически класс отображается в виде прямоугольника, обычно включающего секции с именем, свойствами (атрибутами) и операциями.

• Интерфейс описывает поведение элемента, видимое извне

• Интерфейс может представлять полные услуги класса или компонента или часть таких услуг

• Графически интерфейс изображается в виде кружка с именем

• Имя интерфейса обычно начинается с буквы «I».

• Кооперации имеют как структурное, так и поведенческое измерения

• Конкретный класс может участвовать в нескольких кооперациях

• Графически кооперация изображается как пунктирный эллипс, в который вписывается ее имя.

• Актер. Каждая роль требует от системы определенного поведения

• Изображается как проволочный человечек с именем.

• В модели элемент Use Case применяется для структурирования предметов поведения.

• Элемент Use Case реализуется кооперацией.

• Изображается как эллипс, в который вписывается его имя.

• Активный класс. Похож на обычный класс за исключением того, что его объекты действуют одновременно с объектами других классов

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

• Обычно компонент – это физическая упаковка различных логических элементов (классов, интерфейсов и сотрудничеств)

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

Узел. В узле размещается набор компонентов, который может перемещаться от узла к узлу. Изображается как куб с именем.

Предметы поведения:

Взаимодействие может определять динамику как совокупности объектов, так и отдельной операции

Элементами взаимодействия являются сообщения, последовательность действий (поведение, вызываемое сообщением) и связи (соединения между объектами)

Сообщение изображается в виде направленной линии с именем ее операции.

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

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

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

Группирующие предметы:

В пакет могут помещаться структурные предметы, предметы поведения и даже другие группировки предметов

Пакет – это чисто концептуальное понятие и существует только в период разработки

Изображается как папка с закладкой, на которой обозначено его имя и, иногда, его содержание.

Поясняющие предметы:

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

6. Отношения UML

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

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

Изображается в виде сплошной линии, возможно направленной, иногда имеющей метку и часто включающей другие «украшения», такие как мощность и имена ролей.

Обобщение. Потомок разделяет структуру и поведение родителя

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

Отношения реализации применяют в двух случаях: между интерфейсами и классами (или компонентами), реализующими их; между элементами Use Case и кооперациями, которые реализуют их

Изображается как нечто среднее между обобщением и зависимостью.

6. Диаграммы UML

• диаграммы классов

• диаграммы объектов

• диаграммы Use Case (диаграммы прецедентов)

• диаграммы последовательности

• диаграммы сотрудничества (кооперации)

• диаграммы схем состояний

• диаграммы деятельности

• компонентные диаграммы

• диаграммы размещения (развертывания).

Взаимосвязи между диаграммами UML

6. Механизмы расширения UML

Ограничение показывают как текстовую строку, заключенную в фигурные скобки { }.

Теговую величину показывают как строку в фигурных скобках { }

Строка имеет вид:

имя теговой величины = значение

Элемент со стереотипом является вариацией существующего элемента, имеющей такую же форму, но отличающуюся по сути

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

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

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

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

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

Представления (виды) архитектуры ПС:

Вид с точки зрения прецедентов (Use case view) охватывает прецеденты, которые описывают поведение системы, наблюдаемое конечными пользователями, аналитиками и тестировщиками. Статические аспекты этого вида передаются диаграммами прецедентов, а динамические – диаграммами взаимодействия, состоянии и действий.

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

Вид с точки зрения реализации (Implementation view) охватывает компоненты и файлы, используемые для сборки и выпуска конечного программного продукта. Статические аспекты этого вида передаются диаграммами компонентов, а динамические – с помощью диаграмм взаимодействия, состояний и действий.

Вид с точки зрения процессов (Process view) охватывает нити и процессы, формирующие механизмы параллелизма и синхронизации в системе. Статические аспекты этого вида передают с помощью диаграмм компонентов, а динамические – с помощью диаграмм взаимодействия, состояний и действий.

Вид с точки зрения развертывания (Deployment view) охватывает узлы, формирующие топологию аппаратных средств системы, на которой она выполняется. Статические аспекты вида описываются диаграммами развертывания, а динамические – диаграммами взаимодействия, состояний и действий.

6. Унифицированный процесс разработки программных систем.

Ключевые идеи RUP:

Управление прецедентами использования. Весь ход работ направляется итоговыми целями проекта, выраженными в виде прецедентов использования (use cases) – сценариев взаимодействия результирующей ПС с пользователями или другими системами, при выполнении которых пользователи получают значимые для них результаты и услуги. Разработка начинается с выделения прецедентов использования и на каждом шаге контролируется степенью приближения к их реализации.

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

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

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

Является итеративным и инкрементным.

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

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

Процесс, являющийся одновременно итеративным и инкрементным, называется управляемым рисками.

Фазы RUP:

Фаза начала проекта. Основная цель этой фазы – достичь компромисса между всеми заинтересованными лицами относительно задач проекта и выделяемых на него ресурсов. На этой стадии определяются основные цели проекта, руководитель и бюджет, основные средства выполнения – технологии, инструменты, ключевые исполнители. Также, возможно, происходит апробация выбранных технологий, чтобы убедиться в возможности достичь целей с их помощью, и составляются предварительные планы проекта. На эту фазу может уходить около 10% времени и 5% трудоемкости одного цикла.

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

Фаза построения. Основная цель этой фазы – детальное прояснение требований и разработка системы, удовлетворяющей им, на основе спроектированной ранее архитектуры. В результате должна получиться система, реализующая все выделенные варианты использования. На эту фазу уходит около 50% времени и 65% трудоемкости одного цикла.

Фаза внедрения. Цель этой фазы – сделать систему полностью доступной конечным пользователям. На этой стадии происходит развертывание системы в ее рабочей среде, бета-тестирование, подгонка мелких деталей под нужды пользователей. На эту фазу может уходить около 10% времени и 10% трудоемкости одного цикла.

Дисциплины RUP:

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

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

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

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

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

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

Управление конфигурациями и изменениями. Задачи – определение элементов, подлежащих хранению в репозитории проекта и правил построения из них согласованных конфигураций, поддержание целостности текущего состояния системы, проверка согласованности вносимых изменений. управление изменениями и поддержание целостности артефактов проекта

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

Управление средой проекта. Задачи – подстройка процесса под конкретный проект, выбор и замена технологий и инструментов, используемых в проекте. рассматриваются вопросы инфраструктуры, необходимой для разработки системы

Модели RUP:

• модель бизнес-процессов – формализует абстракцию организации;

• модель предметной области – формализует контекст системы;

• модель вариантов использования – формализует функциональные требования к системе;

• модель анализа – формализует идею проекта;

• модель проектирования – формализует словарь предметной области и области решения;

• модель процессов (необязательная) – формализует механизмы параллелиз­ма и синхронизации в системе;

• модель развертывания – формализует топологию аппаратных средств, на которых выполняется система;

• модель реализации – описывает части, из которых собирается физическая система;

• модель тестирования – формализует способы проверки и приемки системы.

Технические артефакты:

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

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

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

• группа развертывания – содержит все данные, необходимые для конфигурирования предоставленной системы. Группа развертывания сообщает о том, как программный комплекс разбит на пакеты, в каком виде он поставляется, как устанавливается и запускается на площадке заказчика.

6. Управление риском

Влияние риска вычисляют по выражению: RE = P(UO) x L(UO), где:

RE – показатель риска (Risk Exposure – подверженность риску);

P (UO) – вероятность неудовлетворительного результата (Unsatisfactory Outcome);

L (UO – потеря при неудовлетворительном результате.

Управление риском включает шесть действий:

1. Идентификация риска – выявление элементов риска в проекте.

2. Анализ риска – оценка вероятности и величины потери по каждому элементу риска.

3. Ранжирование риска – упорядочение элементов риска по степени их влияния.

4. Планирование управления риском – подготовка к работе с каждым элементом риска.

5. Разрешение риска – устранение или разрешение элементов риска.

6. Наблюдение риска – отслеживание динамики элементов риска, выполнение корректирующих действий.

6. Принципы объектно-ориентированного представления программных систем.

Декомпозиция программных систем:

В основе алгоритмической декомпозиции лежит разбиение по действиям – алгоритмам. Эта схема представления применяется в обычных ПС.

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

Абстрагирование:

Абстрагирование сводится к формированию абстракций.

Каждая абстракция фиксирует основные характеристики объекта, которые отличают его от других видов объектов и обеспечивают ясные понятийные границы.

Абстракция концентрирует внимание на внешнем представлении объекта, позволяет отделить основное в поведении объекта от его реализации.

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

Инкапсуляция и абстракция – взаимодополняющие понятия: абстракция выделяет внешнее поведение объекта, а инкапсуляция содержит и скрывает реализацию, которая обеспечивает это поведение.

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

Инкапсуляция является процессом разделения элементов абстракции на секции с различной видимостью.

Инкапсуляция служит для отделения интерфейса абстракции от ее реализации. Модульность:

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

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

Как правило, модуль состоит из интерфейсной части и части-реализации.

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

• Каждая модульная структура должна быть достаточно простой, чтобы быть полностью понятой.

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

Свойства модулей:

Информационная закрытость утверждает (автор – Д. Парнас, 1972): содержание модулей должно быть скрыто друг от друга.

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

Информационная закрытость означает следующее:

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

• доступ к операциям и структурам данных модуля ограничен.

Связность модуля – это мера зависимости его частей.

Связность – внутренняя характеристика модуля.

Чем выше связность модуля, тем лучше результат проектирования.

Измерение связности – сила связности (СС):

Связность по совпадению (СС=0)

Логическая связность (СС=1)

Временная связность (СС=3)

Процедурная связность (СС=5)

Коммуникативная связность (СС=7)

Информационная (последовательная) связность (СС=9)

Функциональная связность (СС=10)

Сцепление – это мера взаимозависимости модулей по данным.

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

Сцепление по данным (СЦ=1)

Сцепление по образцу (СЦ=3)

Сцепление по управлению (СЦ=4)

Сцепление по внешним ссылкам (СЦ=5)

Сцепление по общей области (СЦ=7)

Сцепление по содержанию (СЦ=9)

Иерархическая организация:

Иерархическая организация – это формирование из абстракций иерархической структуры.

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

Двумя важными инструментами иерархической организации в объектно-ориентированных системах являются: