Технологии разработки программных систем

Жизненный цикл проекта

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

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

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

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

Процесс «Анализ» предназначен для определения требований к системе и их представления в виде (обычной) спецификации требований. Кроме этого в этот процесс входит отнесение создаваемой системы к определённому классу систем.

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

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

Процесс «Инспектирование» представляет собой статическую верификацию исходного представления системы, к которому относятся спецификация требований, формальная спецификация, архитектура системы, программный код.

Кроме указанной последовательности процессов выделяют другую, параллельную ей последовательность процессов (рис.4.18).

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

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

Процесс «Тестирование» означает выполнение статистического тестирования системы и определения специальных характеристик этой системы по полученным результатам.

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

Обзор используемых подходов

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

Нотация Z (Z notation) - ЯФС, названный по теории множеств Цермело - Френкеля и основанный на стандартной математической системе обозначений, используемой аксиоматической теорией множеств, лямбда-исчислением и логикой предикатов первого порядка. Предложен в 1977 г. Ж.-Р. Абриалем совместно с С. Шуманом и Б. Мейером. В дальнейшем развивался Исследовательской группой по программированию Оксфордского университета, в которой Ж._Р. Абриаль работал в начале 1980_х гг. Этот язык послужил основой для многих других ЯФС (Z++, Object_Z, Alloy), подходов (B_Method) и средств (проект CZT, среда ZETA).

Язык общей алгебраической спецификации (CASL) - общецелевой ЯФС, основанный на логике первого порядка с индукцией и поддерживающий некоторые дополнительные возможности. Разработан группой Инициатива по созданию общих каркасов, целью которой является категоризация большинства существующих языков спецификации. Существует множество разнообразных расширений языка CASL (HasCASL, CoCASL, ModalCASL, CASL-LTL, HetCASL).

B_Метод (B_Method) - подход формальной разработки, использующий формальный метод B. Он базируется на языке Абстрактно-машинная нотация (AMN) - ЯФС для спецификации абстрактных машин, основанный на математической теории обобщённых подстановок. Метод B разработан Ж.-Р. Абриалем как развитие нотации Z, но является более низкоуровневым и более акцентированным на усовершенствовании кода. На основе B реализовано множество инструментальных средств (ABTools, Atelier B, B4free, jbtools, ProB, Batcave) и платформ (BRILLIANT, Rodin).

Венский метод разработки (VDM) - подход формальной разработки с использованием ЯФС VDM_SL для моделирования систем на высоком уровне абстракции. Разработан в Венской лаборатории фирмы IBM в 1970_х гг. Первоначально в виде Венского языка определения, а затем метаязыка Meta-IV, использовался для разработки компиляторов для языков программирования из определений этих языков. В дальнейшем в VDM были включены методики и средства, разработанные на VDM_SL. В частности расширение подхода под названием VDM++ поддерживает объектно-ориентированные и параллельные системы. Для VDM и VDM++ существуют и средства разработки (VDMTools, Overture).

Исчисление процессов (Process calculi, Process calculus) или Алгебры процессов (Process algebras) - разнородное семейство связанных языков и подходов формального моделирования параллельных систем. Оно обеспечивает возможность высокоуровневого описания взаимодействия, коммуникации и синхронизации набора независимых процессов, в также манипуляции описаниями процессов. Обзор подходов исчисления процессов приведён ниже.

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

1. Представление взаимодействия между независимыми процессами как коммуникации (передачи сообщений - message-passing), а не как модификации разделяемых переменных.

2. Описание процессов и систем с использованием небольшого набора примитивов, а также операторов для комбинирования этих примитивов.

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

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

Исчисление взаимодействующих систем (CCS) - подход формальной разработки в рамках исчисления процессов, тесно связанный с исследованием теоретических положений и практических методов в области организации, взаимодействия и эквивалентности процессов. Создан Р. Милнером между 1973 г. и 1980 г. (изложен в книге в 1980 г.). Под взаимным влиянием CCS и CSP для обоих подходов был разработан ряд усовершенствований. На CCS реализовано несколько языков (CBS, LOTOS), кроме того для изучения CCS_подобных систем применяются такие модели, как моноид истории и модель актёра.

Взаимодействующие последовательные процессы (CSP) - подход для описания образцов взаимодействия в параллельных системах. Предложен (в виде параллельного языка программирования) Т. Хоаром в статье 1978 г. В дальнейшем автор совместно с С. Бруксом и А.В. Роско развили этот язык в форму исчисления процессов и изложили статье в 1984 г. Т. Хоар изложил современную форму CSP в своей книге в 1985 г. Теория CSP до сих пор остаётся предметом активных исследований. Ряд языков и подходов являются производными CSP (Timed CSP, RPT, CSPP, HCSP) или интегрируют его возможности с другими языками и подходами (TCOZ, Circus, CspCASL). Известным CSP-средством является программа проверки модели FDR (букв. Очищение от сбоев / отклонений) - коммерческий продукт фирмы Formal Systems Ltd. Другие CSP-средства: ProBE, ARC и Casper.

Алгебра взаимодействующих процессов (ACP) - алгебраический подход к обоснованию параллельных систем. Разработан Ж. Бергстрой и Ж.У. Клопом в 1982 г. Разработка ACP связана с созданием абстрактной обобщённой аксиоматической системы для процессов (отсюда и понятие «алгебра процессов»). Подход ACP послужил основой для разработки нескольких подходов для описания и анализа параллельных систем (CRL, mCRL2, HyPA).

Инженерия стерильного цеха (CrSE)

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

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

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

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

СцИП обладает следующими особенностями в ряде областей разработки.

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

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

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

Основы подхода

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

Разработка в рамках подхода выражается в виде трёх принципов:

1. Инкрементная разработка под статистическим контролем качества.

2. Разработка ПО на основе математических принципов.

3. Тестирование ПО на основе статистических принципов.

Инкрементная разработка под статистическим контролем качества означает разработку ПО с использованием инкрементной стратегии, но на основе статистического контроля качества (SQC - statistical quality control). Инкремент представляет собой полное повторение процесса ЖЦ. Измерения производительности сравниваются с предустановленными стандартами для определения контролируемости процесса. Если стандарты качества не удовлетворяются, тестирование инкремента прекращается и происходит возврат на стадию проектирования.

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

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

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

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

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

Жизненный цикл проекта

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

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

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

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

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

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

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

На фазе 3 Верификация» выполняется один процесс. Инспектирование - формальная проверка соответствия кода ПС формальной спецификации (без запуска программы). На этой фазе возможно продолжение Генерации тестов.

На фазе 4 «Сертификация» выполняются два процесса. Интеграция - сборка кода компонентов ПС в единый код ПС. Тестирование - статистическое тестирование кода ПС. При обнаружении проблем при Инспектировании и Тестировании выполняется возврат к Структурированию.

Методика подхода

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

Для разработки ПС используется специальная методика, основанная на следующих двух методах:

1. Метод специфицирования на основе последовательностей (МСОП) - метод представления спецификации ПС в виде последовательностей.

2. Метод структурирования на основе ящиков (МСОЯ) - метод представления структуры ПС в виде ящиков.

МСОП позволяет получить формальную спецификацию ПС на основе неформальной спецификации требований. МСОЯ предназначен для проектирования ПС на основе её формальной спецификации.

Рассмотрим эти методы подробнее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вопросы к §4.1

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

2. Перечислите виды каскадных подходов и примеры подходов каждого вида.

Простые каскадные подходы

3. В чём суть классического каскадного подхода?

4. В чём суть модифицированного каскадного подхода?

Развитые каскадные подходы

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

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

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

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

Вопросы к §4.2

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

10. Перечислите виды каркасных подходов и примеры подходов каждого вида.

Унифицированный процесс (УП, UP)

11. Что представляет собой подход УП?

12. Перечислите и поясните особенности УП.

13. Приведите графическое представление модели ЖЦ для УП.

14. Перечислите фазы ЖЦ проекта для УП.

15. Перечислите дисциплины ЖЦ проекта для УП.

16. Перечислите вехи ЖЦ проекта для УП.

17. Перечислите модификации УП.

Рациональный унифицированный процесс (РУП, RUP)

18. Что представляет собой подход РУП?

19. Что представляет собой Rational Unified Process как продукт?

20. Перечислите первопричины провала проекта.

21. Перечислите признаки (проявления первопричин) провала проекта.

22. Дайте определение понятию «лучшая практика».

23. Перечислите лучшие практики, используемые в РУП.

24. Перечислите ключевые принципы бизнес-управляемой разработки.

25. Приведите графическое представление модели ЖЦ для РУП.

26. Перечислите и поясните фазы ЖЦ проекта для РУП.

27. Перечислите вехи ЖЦ проекта для РУП.

28. Перечислите и поясните основные дисциплины ЖЦ проекта для РУП.

29. Перечислите и поясните вспомогательные дисциплины ЖЦ проекта для РУП.

30. Как распределяются фазы ЖЦ для РУП по трудоёмкости и затратам времени? Приведите графическое представление распределения фаз.

31. Как распределяется нагрузка дисциплин РУП по фазам ЖЦ?

32. Приведите графическое представление итеративности разработки для РУП.

Каркас решений Microsoft (МСФ, MSF)

33. Что представляет собой подход МСФ?

34. Что представляет собой Microsoft Solutions Framework как продукт? Охарактеризуйте пакет руководств МСФ 4.0.

35. Перечислите основополагающие принципы МСФ.

36. Перечислите ключевые концепции МСФ.

37. Перечислите особенности модели руководства МСФ.

38. Приведите графическое представление модели ЖЦ для МСФ.

39. Перечислите и поясните фазы ЖЦ проекта для МСФ.

40. Перечислите и поясните вехи ЖЦ проекта для МСФ.

41. Охарактеризуйте фазу «Представление» подхода МСФ.

42. Охарактеризуйте фазу «Планирование» подхода МСФ.

43. Охарактеризуйте фазу «Разработка» подхода МСФ.

44. Охарактеризуйте фазу «Стабилизация» подхода МСФ.

45. Охарактеризуйте фазу «Развёртывание» подхода МСФ.

Процесс ICONIX

46. Что представляет собой Процесс ICONIX?

47. Как связан Процесс ICONIX с подходами RUP и XP?

48. Перечислите основные особенности ICONIX.

49. Перечислите условия построения хороших моделей объектов в ICONIX.

50. Перечислите и поясните ключевые принципы ICONIX.

51. Приведите графическое представление модели ЖЦ для ICONIX.

52. Перечислите и поясните этапы ЖЦ проекта для ICONIX.

53. Перечислите и поясните вехи ЖЦ проекта для ICONIX.

54. Охарактеризуйте этап «Анализ требований» Процесса ICONIX.

55. Охарактеризуйте этап «Предварительное проектирование» Процесса ICONIX.

56. Охарактеризуйте этап «Детализированное проектирование» Процесса ICONIX.

57. Охарактеризуйте этап «Реализация» Процесса ICONIX.

Вопросы к §4.3

58. Охарактеризуйте эволюционные технологические подходы.

59. Перечислите виды эволюционных подходов и примеры подходов каждого вида.

60. Что представляет собой непланируемый подход? Охарактеризуйте подход.

Подходы прототипирования

61. Что представляют собой подходы прототипирования?

62. Перечислите основные подходы прототипирования.

63. Охарактеризуйте подход Эволюционная доставка. В чём суть модели ЖЦ для этого подхода. Приведите графическое представление данной модели.

64. Охарактеризуйте подход Итеративная доставка. В чём суть модели ЖЦ для этого подхода. Приведите графическое представление данной модели.

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

Итеративная инкрементная разработка (ИИР, IID)

66. Что представляет собой подход ИИР?

67. В каких подходах ИИР является одним из основных компонентов?

Быстрая разработка приложений (БРП, RAD)

68. Что представляет собой подход БРП?

69. Какие подходы созданы на основе БРП?

70. Перечислите и поясните особенности БРП.

71. Перечислите и поясните основные принципы БРП.

72. Каким образом в БРП определяется оценка размера приложения? Что понимается под функциональным элементом?

73. Приведите графическое представление модели ЖЦ для БРП.

74. Перечислите фазы ЖЦ проекта для БРП.

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

76. Охарактеризуйте фазу «Проектирование» подхода БРП.

77. Охарактеризуйте фазу «Построение» подхода БРП.

78. Охарактеризуйте фазу «Внедрение» подхода БРП.

Вопросы к §4.4

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

80. Перечислите виды адаптивных подходов и примеры подходов каждого вида.

Особенности адаптивных подходов

81. Что представляет собой Живая разработка ПО?

82. Перечислите основные положения Живого манифеста.

83. Перечислите принципы Живой разработки ПО.

Адаптивная разработка ПО (АРП, ASD)

84. Что представляет собой подход АРП?

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

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

87. Перечислите и поясните свойства АРП.

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

89. Перечислите фазы ЖЦ проекта для АРП.

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

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

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

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

Экстремальное программирование (ЭП, XP)

94. Что представляет собой подход ЭП?

95. Перечислите категории ЭП. Поясните их взаимосвязь.

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

97. Перечислите фазы ЖЦ проекта для ЭП.

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

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

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

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

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

103. Перечислите и поясните деятельности ЭП.

Вопросы к §4.5

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

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

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

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

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

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

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

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

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

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

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

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

114. Что такое шаблонно-ориентированное программирование?

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

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

116. Какие существуют способы поддержки сборочного программирования?

117. Перечислите подходы сборочного программирования.

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

119. Что такое модульно-ориентированное программирование?

120. Охарактеризуйте расширяемое программирование.

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

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

123. Что такое компонентно-ориентированное программирование?

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

125. Что такое аспектно-ориентированное программирование?

Вопросы к §4.6

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

127. Перечислите виды формальных подходов и примеры подходов каждого вида.

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

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

129. Что такое доказательное программирование?

130. Перечислите формальные генетические подходы.

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

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

133. Что такое математическая спецификация?

134. Что понимается под синтезом программы?

135. Перечислите способы синтеза программы.

136. Поясните логический способ синтеза программы.

137. Поясните аналитический способ синтеза программы.

138. Как проявляется творчество в синтезирующем программировании?

139. Как связан синтез программы с манипулированием знанием?

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

141. Что такое универсальная программа?

142. Что понимается под конкретизацией программы?

143. Какой математический аппарат используется в конкретизирующем программировании? Как он используется для конкретизации программы?

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

145. Что такое программный модуль?

146. Что понимается под сборкой программы?

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

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

148. Что такое формальные методы?

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

150. Перечислите и поясните процессы ЖЦ для формальных подходов.

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

152. Дайте определение понятию «операционный профиль».

153. Охарактеризуйте язык формальной спецификации Z notation и CASL.

154. Охарактеризуйте семейство подходов Исчисление процессов.

155. Охарактеризуйте подход B_Метод (B_Method).

156. Охарактеризуйте подход Венский метод разработки (VDM).

157. Перечислите особенности подходов Исчисления процессов.

158. Охарактеризуйте подходы Исчисления процессов.

Инженерия стерильного цеха (СцИП, CrSE)

159. Что представляет собой подход СцИП?

160. Дайте определение понятию «стерильный цех».

161. Перечислите правила стерильного цеха.

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

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

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

165. Перечислите фазы ЖЦ проекта для СцИП.

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

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

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

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

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

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

172. Что такое перечисление последовательностей стимулов?

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

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

175. Перечислите и поясните ящики, используемые в МСОЯ.

176. Как связаны между собой ящики? Приведите графическое представление схемы уточнения на основе ящиков. Как связаны представления ПС и ящики?

177. Сформулируйте функцию преобразования для чёрного ящика.

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

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



Раздел 5. Инженерия и инструментарий ПО

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

5.1 Инженерия ПО

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



5.2 Инструментарий ПО

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

Методологические и технологические подходы разработки становятся эффективными и экономически выгодными при их автоматизации. Системы автоматизации программной / системной разработки получили название «CASE-средства».

CASE-средство (CASE - букв. компьютерная автоматизированная программная / системная инженерия) - система автоматизированной разработки ПО / систем с помощью компьютеров.

Обычно CASE-средством считается программное средство, автоматизирующее некоторую совокупность ЖЦ и обладающее следующими особенностями:

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

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

3. Использование репозитория - единого хранилища информации о проекте.

Интегрированное CASE-средство включает в себя следующие компоненты:

1. Репозиторий - основа CASE-средства: база данных со специальными возможностями по хранению и управлению информацией о проекте.

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

3. Компоненты программирования: кодирование и тестирование / инспектирование, а также интеграция и сопровождение.

4. Компоненты поддержки: документирование и управление конфигурацией, верификация и аттестация, обзор и аудит.

5. Компоненты организации: управление проектом, инфраструктура.

CASE-средства обычно классифицируются по типам и категориям.

Тип CASE-средства отражает его функциональное назначение:

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

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

3. Программирование (разработка приложений): автоматизированное кодирование, тестирование и/или инспектирование, интеграция.

4. Сопровождение и поддержка: сопровождение всех категорий, документирование и другие связанные действия.

5. Управление проектом: руководство, планирование, контроль.

6. Инфраструктура: создание и управление инфраструктурой.

Таким образом, классификация по типам определяется компонентным составом CASE-средств.

Категория CASE-средства связана со степенью взаимодействия его компонентов в рамках охватываемых им стадий ЖЦ:

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

2. Инструментальный пакет (букв. набор инструментов) - связанная совокупность инструментальных средств для решения класса задач обычно в рамках одной стадии ЖЦ.

3. Инструментарий (букв. верстак) - организованная совокупность инструментальных средств для решения класса задач в рамках всего ЖЦ.

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

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

Уровень CASE-средства выражает область его действия в рамках ЖЦ:

1. Верхний уровень: организация, управление.

2. Средний уровень: моделирование, анализ и проектирование.

3. Нижний уровень: программирование и поддержка.

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

Кроме этого, существуют и другие классификации CASE-средств.

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

Большинство технологий разработки и соответствующих им CASE-средств ориентировано на одну из двух наиболее популярных методологий - структурную или объектно-ориентированную.

Для бизнес-моделирования, анализа и проектирования CASE-средства на основе структурной методологии используют подходы на основе DFD, ERD, STD и IDEF0 (SADT) с применением при необходимости других моделей и методов, а CASE-средства на основе объектно-ориентированной методологии применяют подход на основе UML.

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

Вопросы к §5.1

1. Дайте определение понятию «стиль программирования».

2. Перечислите свойства хорошего стиля программирования.

3. Как формируется стиль программирования?

4. Как связан стиль программирования с методологиями разработки?

5. Дайте определение понятию «защитное программирование».

6. Перечислите основные принципы защитного программирования.

7. Перечислите общие рекомендации по защитному программированию.

8. Перечислите и поясните механизмы защитного программирования.

9. Как защитное программирование связано с аспектным сборочным программированием?

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

11. Поясните механизм, используемый Проектированием по контракту?

Вопросы к §5.2

12. Что такое CASE-средство?

13. Перечислите особенности CASE-средств.

14. Перечислите компоненты CASE-средств.

15. Перечислите основные признаки классификации CASE-средств.

16. Приведите классификацию CASE-средств по типам.

17. Приведите классификацию CASE-средств по категориям.

18. Приведите классификацию CASE-средств по уровням.

19. Кратко охарактеризуйте системы автоматизации.



Раздел 6. Методические указания

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

6.1 Лабораторные работы

Наиболее известной CASE-системой на основе объектно-ориентированной (ОО) методологии является семейство CASE-средств ОО анализа и проектирования Rational Rose (RR) от IBM Rational. RR предназначен для автоматизации анализа и проектирования ПО, а также для генерации кодов на различных языках программирования (ЯП) и выпуска проектной документации. Он использует ОО методологию, основанную на языке UML.

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

RR можно рассматривать как графический редактор, позволяющий моделировать сложные системы на основе графических диаграмм UML. В составе RR можно выделить 6 основных компонент: репозиторий, графический интерфейс пользователя, средства просмотра проекта (browser), средства контроля проекта, средства сбора статистики и генератор документов. К ним добавляются генератор кода (индивидуальный для каждого ЯП) и анализатор, обеспечивающий реинжиниринг - восстановление модели проекта по исходному коду программ.

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

В результате разработки проекта с помощью RR формируются следующие документы: диаграммы прецедентов; диаграммы классов; диаграммы взаимодействия (диаграммы последовательности и кооперации); диаграммы переходов состояний (диаграммы состояний и деятельности); диаграммы реализации (диаграммы компонентов и развертывания); спецификации классов, объектов, атрибутов и операций; заготовки текстов программ; модель разрабатываемой программной системы. Тексты программ являются заготовками для последующей работы программистов и в дальнейшем развиваются программистами в полноценные программы. Для групповой работы в RR возможно разбиение модели на подмодели. Каждая из них независимо сохраняется на диске или загружается в модель. Наиболее эффективно групповая работа организуется при интеграции RR со средствами управления конфигурацией и контроля версий (PVCS).

RR функционирует на платформах: IBM PC (Windows), станции Sun SPARC (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

В стандартной поставке RR не предусмотрена возможность работы с Delphi, но IBM Rational ведёт программу по поддержке сторонних производителей программ-мостов (Links) между RR и другими средствами разработки. В рамках этой программы фирмой Ensemble Systems была разработана программа-мост Rose Delphi Link (RDL), связывающая RR и Delphi. Основные функции кодогенератора RDL - генерация кода и обратное проектирование.

Среду Rose также можно расширить с помощью встроенного ЯП RoseScript. На RoseScript можно написать код для автоматического внесения изменений в модель, для создания отчётов и выполнения других задач.

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

1. Введение в Rational Rose