Модель ЖЦ для АРП (рис.13.2) основана на приведённой выше схеме цикла.

В модели схема конкретизируется в виде 3 фаз: 1. Обдумывание; 2. Сотрудничество; 3. Обучение.



Рис.13.2. Модель ЖЦ для подхода ASD

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

1. Определение цели и задач проекта.

2. Выявление и краткое описание ограничений и требований к системе.

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

4. Первоначальная оценка размера и масштабности проекта.

5. Определение ключевых рисков.

6. Установление временных рамок для всего проекта.

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

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

1. Определение оптимального числа циклов и временных рамок каждого из них.

2. Определение цели и задач для каждого цикла разработки.

3. Соотнесение компонентов системы с циклами разработки.

4. Планирование циклов с учётом разрабатываемых компонентов.

Распределение компонентов по циклам - непростая задача. Главным критерием здесь является поставка заказчику в конце каждого цикла некоторой видимой, осязаемой, работающей части системы. К другим критериям относят следующие:

1. Первоочередная разработка компонентов с высокой степенью риска.

2. Учёт естественных зависимостей между компонентами.

3. Балансирование расходов различных используемых ресурсов.

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

Адаптивность в АРП заключается в следующем: нужно определить цель и масштаб проекта, показать команде, какие компоненты ей необходимо разработать, а затем отойти в сторону и дать разработчикам самим решать, как они будут это делать. Чувство ответственности в команде поддерживается при помощи периодической оценки качества. В таком случае качество будет расти не благодаря дотошному контролю, а благодаря формированию соответствующих критериев для выпускаемого продукта и критическому его анализу. Постоянный анализ и оценка проделанной работы - ключ к обучению.

В конце каждого цикла нужно знать: Качество продукта с точки зрения заказчика; Качество продукта с технической точки зрения; Работоспособность команды и используемость практик; Текущее положение дел в проекте (статус проекта).

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

Экстремальное программирование (ЭП, XP - eXtreme Programming) - живой подход, предложенный Кентом Беком.

Возникновение ЭП тесно связано с выполнением проекта C3 (букв. Всеобъемлющее компенсирование для Chrysler) - разработка системы учёта выплат работникам фирмы Daimler Chrysler. Суть проекта заключалась в разработке единой системы вместо множества разрозненных приложений. Именно на этом проекте К. Беком отрабатывались практики подхода. В 1996 г. Бек стал руководить проектом, в 2000 г. фирма прервала проект. Полученная система использовалась только для 10 тысяч человек из 87 тысяч работников. Поэтому успешный на словах проект оказался провальным. Главной причиной этого является не сам подход, а его применение к неподходящему проекту. Для реализации проекта C3 (разработки формализуемой системы) нужно использовать один из строгих подходов. В 1999 г. вышло 1_е издание К. Бека «Экстремальное программирование в объяснении: Избирание изменения», а в 2004 г. - 2_е издание этой книги в соавторстве с Цинтией Андрес, переработанное с учётом опыта применения ЭП.

В ЭП гораздо больше спорных моментов, чем в каком-либо другом подходе. Ключевой и основополагающей деятельностью в ЭП считается кодирование, поэтому подход использует идею непланируемой модели - «кодирование - исправление»,- расширяя её принципами эффективной организации работ. Эти принципы доводятся до крайности их реализации в используемых практиках.

При этом практики ЭП оказываются слишком тесно взаимосвязанными, что приводит к излишней жёсткости подхода. Практики считаются фиксированной частью, в то время как ЖЦ системы - адаптивной частью ЭП, что противоречит логике разработки и приводит к проблемам в проектах, использующих этот подход.

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

В ЭП рассматривается модель ЖЦ идеального проекта для ЭП (рис.13.3).

Согласно этой модели выделено 5 фаз ЖЦ: 1. Исследование; 2. Планирование; 3. Реализация / Итерации; 4. Продуцирование / Обслуживание; 5. Смерть.

Рис.13.3. Схема модели ЖЦ для подхода XP

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

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

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

На фазе 3 выполняются итерации разработки и функциональное (приёмочное) тестирование системы. Итерации разработки предназначены для реализации историй в рамках плана выпуска и формирования функциональных тестов. В ходе первой итерации формируется общий дизайн, для которого отбираются подходящие истории, для остальных итерации отбор историй выполняется заказчиком. Функциональное тестирование позволяет получить одобренный заказчиком выпуск, включающий истории с учётом плана выпуска.

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

На фазе 5 завершается эксплуатация системы. Это может произойти по двум причинам: 1. У заказчика нет историй для новых выпусков продукта; 2. Система находиться в плохом состоянии из-за большого числа дефектов.

На протяжении этих фаз ЖЦ выполняются 4 деятельности, связанные с программированием: 1. Кодирование; 2. Тестирование; 3. Слушание; 4. Проектирование. Основой для всех деятельностей является программный код системы.

Контрольные вопросы

1. Охарактеризуйте адаптивные технологические подходы. Перечислите виды адаптивных подходов и примеры подходов каждого вида.

2. Что представляет собой Живая разработка ПО? Перечислите основные положения Живого манифеста.

3. Что представляет собой подход АРП? Сформулируйте модель сложной адаптивной системы, используемой в АРП.

4. В чём состоит особенность модели ЖЦ для АРП? Приведите графическое представление схемы этой модели. Перечислите и поясните свойства АРП.

5. Приведите графическое представление модели ЖЦ для АРП. Перечислите фазы ЖЦ проекта для АРП.

6. Охарактеризуйте фазу «Обдумывание» подхода АРП.

7. Охарактеризуйте фазу «Сотрудничество» подхода АРП.

8. Охарактеризуйте фазу «Обучение» подхода АРП.

9. Сформулируйте и поясните суть адаптивности подхода АРП.

10. Что представляет собой подход ЭП? Перечислите категории ЭП.

11. Приведите графическое представление схемы модели ЖЦ для ЭП. Перечислите фазы ЖЦ проекта для ЭП. Перечислите и поясните деятельности ЭП.

12. Охарактеризуйте фазу «Исследование» подхода ЭП.

13. Охарактеризуйте фазу «Планирование» подхода ЭП.

14. Охарактеризуйте фазу «Реализация» подхода ЭП.

15. Охарактеризуйте фазу «Продуцирование» подхода ЭП.

16. Охарактеризуйте фазу «Смерть» подхода ЭП.

Лекция 14

Тема лекции: Подходы разработки ПО (продолжение)

Основное содержание

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

Выделяют генетические подходы следующих трёх видов:

1. Синтезирующее программирование.

2. Конкретизирующее программирование.

3. Сборочное программирование.

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

Эти виды подходов предназначены для облегчения разработки путём использования уже имеющихся частично формализованных или готовых элементов представления программного кода. Фактически генетические подходы являются облегчённой версией соответствующих формальных генетических подходов. Поэтому ряд положений, относящихся к формальным генетическим подходам, оказывается справедливым и для (обычных) генетических подходов.

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

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

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

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

3. Зафиксировать отображение понятий языка спецификаций на язык реализации, а также программно-аппаратную платформу.

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

5. Протестировать полученный код программы.

Существует ряд подходов различного уровня применения в процессах ЖЦ, которые относятся к синтезирующему программированию и связаны с соответствующим языком спецификации. К таким языкам спецификации относятся следующие: UML - язык спецификации для объектно-ориентированной разработки ПО; SDL - язык для однозначного специфицирования и описания поведения реактивных и распределённых систем; ASN.1 - стандартный гибкий язык описания структур данных для представления, кодирования, передачи и декодирования данных. Автоматическая генерация программ возможна для многих языков спецификаций, в частности для перечисленных выше языков.

Конкретизирующее программирование - вид подходов, предполагающих извлечение программы из существующей универсальной программы путём конкретизации общих элементов. Существует много подходов различного уровня применения в процессах ЖЦ, которые относятся к конкретизирующему программированию. Среди них следует отметить следующие подходы: 1. Обобщённое программирование; 2. Подход на основе паттернов и анти-паттернов; 3. Подход на основе архитектурных стилей.

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

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

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

Архитектурный стиль - это набор архитектурных структур, ориентированный на разработку системы для конкретной ПрО. М. Шоу и Д. Гарлан предложили использовать каталог таких стилей для их идентификации, документирования и облегчения использования в дальнейшем на практике. Каждый архитектурный стиль обычно имеет определённое концептуальное представление - архитектурный паттерн, и связанное с некоторой методологией разработки реализационное представление - архитектурный каркас.

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

Сборочное программирование - вид подходов, предполагающих сборку программы из уже разработанных фрагментов.

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

Выделяют следующие основные способы поддержки этого подхода:

1. Выработка стиля программирования, соответствующего принятым принципам модульности.

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

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

Сборочное программирование тесно связано с методом повторного использования кода, причём как исходного, так и бинарного. Выделяют несколько разновидностей технологических подходов сборочного программирования, которые в значительной степени определяются базисной методологией: 1. Модульное сборочное; 2. Объектное сборочное; 3. Компонентное сборочное и 4. Аспектное сборочное программирование.

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

Модульное сборочное программирование - исторически первый подход сборочного программирования, базирующийся на процедурах и функциях методологии структурного императивного программирования, точнее их объединении - программных модулях. В разных языках программные модули называются по-разному: модуль (module в Modula_2, unit в Pascal), пакет (package в Ada) или просто отдельный файл (в C/C++ и т.п.).

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

Развитием этого подхода является расширяемое программирование - модульно-основанное программирование, при котором добавление новых модулей возможно без каких-либо изменений в существующих модулях. Данный подход предложен Н. Виртом и впервые реализован при проектировании Oberon System. Фактически это компонентно-основанное программирование без ООП, так как модуль в Oberon является полноценным компонентом (т.е. выполняет соответствующие ему функции). Развитием Oberon стал Component Pascal, в своём названии отразивший своё происхождение от языка Pascal и свою нацеленность на компонентное программирование.

Объектное сборочное программирование - подход сборочного программирования, базирующийся на библиотеках классов ООП, поставляемых в виде исходного (VCL в Delphi) или бинарного кода (DLL в C/C++ для MS Windows).

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

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

Компонент - класс, доступ к которому обеспечивается через строго определённые интерфейсы. Под интерфейсом понимается набор средств и правил для обеспечения единообразного взаимодействия. Использование интерфейсов компонентов вместо непосредственного доступа к объектам позволяет снять проблему несовместимости компиляторов и обеспечивает смену версий компонентов без перекомпиляции основанного на них ПО. Наиболее известными примерами реализации этого подхода являются COM (DCOM, COM+), CORBA, .NET.

Некоторые рассматривают этот подход как соответствующий своей определённой методологии, используя для неё название компонентно-ориентированное программирование (КОП). Эта методология является дальнейшим развитием ООП. Её можно рассматривать как методологию, полученную применением специфики модульности к ООП.

Аспектное сборочное программирование - развитие предыдущего подхода, базирующееся на библиотеках многоаспектных компонентов. Данный подход связан с такими понятиями, как аспект и значимость.

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

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

Некоторые рассматривают этот подход (аналогично КОП) как соответствующий своей определённой методологии, используя для неё название аспектно-ориентированное программирование (АОП). Эта методология является дальнейшим развитием ООП и КОП. Её можно рассматривать как методологию, полученную повторным применением специфики модульности к КОП на более высоком уровне организации модульности.

Контрольные вопросы

1. Охарактеризуйте генетические технологические подходы. Перечислите виды генетических подходов. Как они связаны с методологиями разработки ПО?

2. Какая связь между генетическими и формальными генетическими подходами?

3. В чём суть синтезирующего программирования? Какие задачи необходимо решить при синтезирующем программировании?

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

5. В чём суть конкретизирующего программирования? Перечислите подходы конкретизирующего программирования.

6. Охарактеризуйте обобщённое программирование.

7. Охарактеризуйте подход на основе паттернов и анти-паттернов.

8. Охарактеризуйте подход на основе архитектурных стилей.

9. В чём суть сборочного программирования? Какие есть способы поддержки этого вида подходов? Перечислите подходы сборочного программирования.

10. Охарактеризуйте модульное сборочное программирование.

11. Охарактеризуйте объектное сборочное программирование.

12. Охарактеризуйте компонентное сборочное программирование.

13. Охарактеризуйте аспектное сборочное программирование.

Лекция 15

Тема лекции: Подходы разработки ПО (продолжение)

Основное содержание

Формальные подходы основаны на применении математических принципов к разработке ПО. Выделяют формальные подходы следующих трёх видов:

1. Формальные генетические подходы.

2. Подходы формальной разработки.

3. Смешанные формальные подходы: Инженерия стерильного цеха (CrSE).

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

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

В 1975 г. Э.В. Дейкстра в работе «Охраняемые команды, недетерминированность и формальное порождение программ» высказал идею и сформулировал свои положения по доказательству программ. В 1984 г. А.П. Ершов в своём докладе предложил термин «доказательное программирование». Доказательное программирование - разработка ПО, обладающая свойством доказательности правильности создаваемого продукта. А.П. Ершов указал три вида доказательного программирования, которые тесно связаны с видами генетических подходов. Поэтому эти виды получили в дальнейшем название формальных генетических подходов.

Выделяют следующие формальные генетические подходы: 1. Формальное синтезирующее программирование; 2. Формальное конкретизирующее программирование; 3. Формальное сборочное программирование.

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

Формальное синтезирующее программирование основывается на применении математической спецификации - совокупности логических формул, представляющих постановку проблемы. Под синтезом программы понимается разработка этой программы по её математической спецификации. В случае явно существующего разделения постановки проблемы и метода её решения синтез заключается в правильном представлении метода решения в виде программы. Однако на практике метод решения проблемы присутствует лишь неявно - в постановке этой проблемы и её ПрО. Тогда синтез заключается в извлечении метода решения с помощью некоторой систематической процедуры для его дальнейшего воплощения в виде программы.

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

В настоящее время формальное синтезирующее программирование является редко используемым подходом доказательного программирования.

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

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

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

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

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

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

Модели ЖЦ для подходов формальной разработки являются модификацией и/или конкретизацией описанной ниже модели трансформации. Трансформационная модель или Модель трансформации аналогична каскадной, но ориентирована на использование формальных методов в процессах ЖЦ. Принцип модели этого подхода (рис.15.1) заключается создании формальной спецификации и её трансформации путём формальных преобразований в код системы.

Рис.15.1. Схема трансформационной модели

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

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

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

Процесс «Сопровождение» имеет стандартное назначение.

Рассмотрим кратко языки и подходы формальной разработки.

Нотация Z (Z notation) - ЯФС, названный по теории множеств Цермело - Френкеля и основанный на стандартной математической системе обозначений, используемой аксиоматической теорией множеств, лямбда-исчислением и логикой предикатов первого порядка. Язык общей алгебраической спецификации (CASL) - общецелевой ЯФС, основанный на логике первого порядка с индукцией и поддерживающий некоторые дополнительные возможности. B_Метод - подход формальной разработки, использующий формальный метод B. Метод базируется на языке Абстрактно-машинная нотация (AMN) - ЯФС для спецификации абстрактных машин, основанный на теории обобщённых подстановок. Венский метод разработки (VDM) - подход формальной разработки с использованием ЯФС VDM_SL для моделирования систем на высоком уровне абстракции.

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

Самыми известными до сих пор подходами исчисления процессов являются CCS, CSP и ACP. Современными подходами исчисления процессов являются _исчисление, исчисление среды, PEPA (Алгебра процессов для оценки производительности), исчисление слияния.

Контрольные вопросы

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

2. Охарактеризуйте формальные генетические подходы.

3. Перечислите формальные генетические подходы. Как определяются генетические технологические подходы по формальным генетическим подходам?

4. В чём суть формального синтезирующего программирования?

5. В чём суть формального конкретизирующего программирования?

6. В чём суть формального сборочного программирования?

7. Охарактеризуйте подходы формальной разработки. Что такое формальные методы?

8. В чём суть трансформационной модели? Приведите графическое представление схемы этой модели. Перечислите и поясните процессы ЖЦ.

9. Дайте определение понятиям «формальная спецификация» и «операционный профиль».

10. Охарактеризуйте языки и подходы формальной разработки.

Лекция 16

Тема лекции: Подходы разработки ПО (продолжение)

Основное содержание

Инженерия стерильного цеха или Стерильно-цеховая инженерия ПО (СцИП, CrSE, Cleanroom SE - Cleanroom Software Engineering) - подход формальной разработки, предложенный сотрудником фирмы IBM Х. Миллзом.

Стерильный цех - это производственное помещение, в котором специальными мерами обеспечивается низкий контролируемый уровень загрязнителей в окружающей среде. Это понятие отражает главную идею подхода - переход от устранения дефектов к их предотвращению. Разработка ПС в виде стерильного цеха требует использования правил: 1. Разработчики могут и должны производить ПО, которое почти свободно от ошибок уже перед выполнением тестирования; 2. Целью тестирования является измерение качества, а не его обеспечение. Для учёта правил необходимо использовать формальные методы. СцИП как раз и является развитием подхода IID на основе применения формальных методов.

С середины 1980_х гг. подход СцИП использовался подразделением FSD фирмы IBM в рамках проектов военного назначения. В 1987 г. Х. Миллз, М. Дайер и Р. Лингер опубликовали статью «Инженерия стерильного цеха», после которой подход стали использовать и для коммерческих критически важных проектов.

СцИП обладает следующими особенностями в ряде областей разработки. В области командной разработки считается, что команда проекта должна быть небольшой (6 _ 8 человек) и работать в рамках определённой дисциплины для обеспечения разумного контроля над продвижением проекта. В области распределения времени по фазам ЖЦ считается, что для предотвращения дефектов следует выделять больше времени под фазу проектирования. В области существующих организационных практик СцИП позволяет применять сложившиеся у разработчиков методики и практики, если они не противоречат принципам подхода.

Подход СцИП рассматривает процесс разработки ПО не как ремесло, а как инженерную деятельность, используя вместо обычных методов разработки строгие точные методы. 3 принципа разработки: 1. Инкрементная разработка под статистическим контролем качества; 2. Разработка ПО на основе математических принципов; 3. Тестирование ПО на основе статистических принципов.

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

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

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

Таким образом, СцИП позволяет получить ПО, корректное математически спецификационным проектированием и заверенное статистически обоснованным тестированием.

Основой модели ЖЦ для подхода служит модель трансформации, ориентированная на использование формальных методов (рис.16.1).

Особенностью модели ЖЦ для СцИП (рис.16.1) является использование специальной методики вместо процесса трансформации. Это снижает затраты на разработку ПС по сравнению с подходами формальной разработки, но обеспечивает высокий уровень приемлемого качества ПС. Поэтому СцИП оказывается сопоставимым по стоимости с другими подходами, превосходя их в качестве ПС.

Рис.16.1. Схема модели ЖЦ для СцИП

В СцИП можно (условно) выделить следующие фазы: 1. Формализация; 2. Проектирование; 3. Верификация; 4. Сертификация. При этом для сложных систем используется постепенное наращивание функциональности ПС на основе цикла инкремента путём реализации выделяемых заказчиком подмножеств требований на следующий инкремент разработки.

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

В рамках подхода ПС рассматривается как система, в которой входные данные называются стимулами, получаемые результаты - ответами. На практике ответ системы определяется некоторой последовательностью стимулов. Таким образом, ПС представляется как преобразователь стимулов в ответы.

Для разработки ПС используется методика, основанная на следующих двух методах: 1. Метод специфицирования на основе последовательностей (МСОП) - метод представления спецификации ПС в виде последовательностей; 2. Метод структурирования на основе ящиков (МСОЯ) - метод представления структуры ПС в виде ящиков. МСОП позволяет получить формальную спецификацию ПС на основе неформальной спецификации требований. МСОЯ предназначен для проектирования ПС на основе её формальной спецификации.

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

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

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

МСОП разбивает бесконечное множество последовательностей стимулов на конечное множество классов эквивалентности. Две последовательности считаются эквивалентными, если их всевозможные расширения приводят к одному и тому же поведению (состоянию) системы. Каждый такой класс характеризуется последовательностью минимальной длины - канонической последовательностью. Если таких последовательностей оказывается несколько, то выбирается по перечислению первая из них. Пустая последовательность по определению также является канонической последовательностью.

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

1. Выбрать пустую (каноническую) последовательность.

2. Сформировать новый набор последовательностей путём расширения канонической последовательности соответствующими стимулами.

3. Для каждой новой последовательности определить ответ системы.

4. Для каждой новой последовательности определить класс эквивалентности.

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

6. Если рассмотрены все классы эквивалентности, то перейти к шагу 8.

7. Выбрать очередную каноническую последовательность и перейти к шагу 2.

8. Завершить перечисление последовательностей.

Совокупность таблиц определяет формальную спецификацию как требуемую математическую функцию, заданную в табличном виде.

Целью МСОЯ является постепенное преобразование формальной спецификации ПС в программный код системы. Для выполнения этого МСОЯ определяет представления ПО в виде так называемых ящиков - моделей системы, характеризующих определённый уровень информации о неизвестной системе.

В МСОЯ выделены три ящика: 1. Чёрный ящик; 2. Ящик состояний; 3. Прозрачный ящик. Чёрный ящик определяет видимое извне поведение системы или компонента в терминах её / его видимых взаимодействий с внешней средой; ответ формируется по стимулам. Ящик состояний задаёт поведение в виде состояний и переходов между ними; ответ формируется по текущему стимулу и состоянию. Прозрачный ящик представляет собой реализацию требуемого поведения - код переходов между состояниями и формирования ответов на стимулы.

Рис.16.2. Схема уточнения на основе ящиков

Эти представления образуют иерархию абстракции, которая учитывает: пошаговое уточнение и может применяться как к системе в целом, так и к её компонентам; верификацию, так как каждое следующее представление системы / компонента получается из предыдущего. Во время каждого уточнения требуется использовать все 3 представления (рис.16.2): определить чёрный ящик, на его основе разработать ящик состояний, по которому реализовать прозрачный ящик.

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

Чёрный ящик получает на вход стимулы S и выдаёт на выход ответ R. Генерация каждого ответа чёрного ящика определяется текущим стимулом S и (возможно) историей стимулов SH - предыдущей последовательностью стимулов. Тогда функция преобразования чёрного ящика имеет вид: (S, SH) (R).

Ящик состояний получается из чёрного ящика путём выделения состояний, инкапсулирующих части истории стимулов (инварианты), на основе таблиц перечисления последовательностей. Влияние истории стимулов SH на ответ заменяется изменением старого состояния So на новое состояние Sn ПС. Следовательно, функция преобразования ящика состояний имеет вид: (S, So ) (R, Sn ). Если существует несколько ящиков состояний, получаемых из чёрного ящика, осуществляется выбор одного из них.

Прозрачный ящик получается из ящика состояний реализацией требуемого преобразования в виде программного кода. Поэтому функция преобразования прозрачного ящика имеет вид: (S, So ) КОД (R, Sn ). Данная реализация выполняется постепенным определением логики изменения состояний и метода генерации ответов ПС. При этом прозрачный ящик часто выражается как композиция новых заданных чёрных ящиков. В подходе определены правила композиции чёрных ящиков аналогично правилам для конструкций, используемым в структурном программировании. Если существует несколько прозрачных ящиков, получаемых из ящика состояний, осуществляется выбор одного из них.

Цикл уточнения (рис.16.2) завершается, когда все чёрные ящики преобразованы в прозрачные. В итоге получается полный прозрачный ящик - код ПС.

Контрольные вопросы

1. Что представляет собой подход СцИП? Дайте определение понятию «стерильный цех». Перечислите правила стерильного цеха.

2. Перечислите области разработки, в которых СцИП имеет особенности. Охарактеризуйте эти особенности.

3. Перечислите и поясните основные принципы разработки в рамках СцИП.

4. Приведите графическое представление схемы модели ЖЦ для СцИП. Перечислите фазы ЖЦ проекта для СцИП.

5. Охарактеризуйте фазу «Формализация» подхода СцИП.

6. Охарактеризуйте фазу «Проектирование» подхода СцИП.

7. Охарактеризуйте фазу «Верификация» подхода СцИП.

8. Охарактеризуйте фазу «Сертификация» подхода СцИП.

9. В чём суть специальной методики, используемой в рамках СцИП.

10. Охарактеризуйте метод специфицирования на основе последовательностей (МСОП) подхода СцИП.

11. Сформулируйте правило Чёрного ящика.

12. Охарактеризуйте метод структурирования на основе ящиков (МСОЯ) подхода СцИП. Что понимается под ящиком?

13. Сформулируйте функции преобразования для ящиков.

Лекция 17

Тема лекции: Инженерия и инструментарий ПО

Основное содержание

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

Ряд направлений инженерии ПО представляет интерес с методологической и технологической точек зрения.

Стиль программирования - набор приёмов, методик и практик кодирования, которые используются, чтобы получить правильные, эффективные, простые для понимания и удобные для применения программы.

Б.В. Керниган и Р. Пайк уточняют, что код должен быть прост и понятен, т.е. обладать следующими свойствами: очевидная логика; естественные выражения; использование соглашений, принятых в языке; осмысленные имена; аккуратное форматирование; развёрнутые комментарии; отсутствие хитрых трюков и необычных конструкций.

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

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

Защитное программирование - подход к программированию, при котором появляющиеся ошибки легко обнаруживаются и идентифицируются программистом. Существуют три основных принципа защитного программирования:

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

2. Немедленное обнаружение: Каждая ошибка должна быть выявлена как можно раньше, это упрощает установление её причины.

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

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

- Проверка области значений переменных.

- Контроль правдоподобности значений переменных.

- Проверка результатов вычислений.

- Автоматические проверки (например, контроль переполнения).

- Проверка длины элементов информации.

- Проверка кодов возврата функций.

К механизмам защитного программирования относят:

- директивы проверки - команды компилятору для использования встроенных средств генерации элементарных проверок перед использованием операций;

- утверждения - логические операторы для проверки правильности выполнения программы с помощью ограничений, наложенных на программу;

- исключения - представление ошибок или некорректных ситуаций для управления их обработкой в нужном месте программы;

- баррикады - изоляция повреждений путём организации проверок при передаче данных между определёнными программными модулями;

- отладочный код - специальный код для выполнения дополнительных проверок и облегчения поиска ошибок.

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

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

Проектирование по контракту - подход к проектированию и программированию, основанный на документировании прав и обязанностей подпрограмм и модулей для корректности программы. Предложен Б. Мейером и изложен им в 1997 г. в книге «Конструирование объектно-ориентированного ПО».

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

Проектирование по контракту использует утверждения трёх видов: предусловия, постусловия и инварианты. Предусловие - утверждение о требовании для выполнения подпрограммы. Предусловие проверяется перед выполнением подпрограммы для обеспечения правильности исходных данных этой подпрограммы. Постусловие - утверждение о требовании к выполнению подпрограммы. Постусловие проверяется после выполнения подпрограммы для обеспечения правильности результатов этой подпрограммы. Инвариант - утверждение о требовании по выполнению программного модуля. Инвариант является истинным при взаимодействии модуля с другими модулями, но может быть ложным при выполнении подпрограммы этого модуля.

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

...