Непейвода Н.Н., Скопин И.Н. Основания программирования

Подождите немного. Документ загружается.

4.2. ТРАДИЦИОННОЕ ПРЕДСТАВЛЕНИЕ

195

• программирование — начинается на фазе конструирования, когда ста-

новятся доступными основные спецификации на отдельные компонен-

ты изделия (контрольная точка 4), но не ранее утверждения соглаше-

ния о требованиях (контрольная точка 3). Совмещение данной фазы с

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

проверку проектных решений и некоторых ключевых вопросов разра-

ботки. Цель этапа — реализация программ компонентов с последую-

щей сборкой изделия. Он завершается, когда разработчики заканчива-

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

бе, выполняющей независимую оценку результатов работы (независи-

мые испытания начались — контрольная точка 7);

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

и практическим использованием изделия. Она начинается, как толь-

ко проведены внутренние (силами разработчиков) испытания изделия

(контрольная точка 6) и заканчивается, когда подтверждается готов-

ность изделия к эксплуатации (контрольная точка 9);

• использование — начинается в ходе передачи изделия на распростране-

ние и продолжается, пока изделие находится в действии и интенсивно

эксплуатируется. Этап связан с внедрением, обучением, настройкой и

сопровождением, возможно, с модернизацией изделия. Он заканчива-

ется, когда разработчики прекращают систематическую деятельность

по сопровождению и поддержке данного программного изделия (кон-

трольная точка 10).

На протяжении фаз жизненного цикла разработчики выполняют следую-

щие технологические (организационные) функции (классы функций):

1. планирование,

2. разработка,

3. обслуживание,

4. выпуск документации,

5. испытания,

6. поддержка,

196

ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ

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

Перечисленные функции на разных этапах имеют различное содержание,

требуют различной интенсивности, но, что особенно важно для модели, со-

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

ли, наложение которого на фазовое измерение дает изображение матрицы

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

функций отражается густотой закраски клеток матрицы).

Состав организационных функций и их интенсивность могут меняться

от проекта к проекту в зависимости от его особенностей, от того, что ру-

ководство проекта считает главным или второстепенным. К примеру, если

исходная квалификация коллектива не очень высока, в список функций мо-

жет быть добавлено обучение персонала. Иногда бывает важно разграничить

планирование и контроль (по Гантеру контрольные функции явно не выделя-

ются).При объектно-ориентированном проектировании роль моделирования

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

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

впереди.

Модель учитывает соотношение технологических функций и фаз жизнен-

ного цикла, чем она выгодно отличается от ранее рассмотренных «идеаль-

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

«идеальных» моделей есть следствие отождествления выделяемых этапов с

технологической операцией, преобладающей при их выполнении. В то же

время задача отражения итеративности в модели Гантера в явном виде не

предусматривается. Хотя само по себе перекрытие смежных фаз проекта и

выпуск соответствующей событиям документации — путь к минимизации

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

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

§ 4.3. ИТЕРАТИВНЫЕ МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА

Итеративность неизбежна при разработке сложных программных изде-

лий, а потому ее целесообразно внести в основу жизненного цикла и техно-

логии разратоки. Однако вплоть до появления объектно-ориентированного

проектирования (ООП) и Сообщества

Free Soft

, в настоящее время фигури-

рующего под девизом «Открытое программное обеспечение» (Open Source)

(оба эти события произошли практически одновременно) подходы к разви-

тию проектов не пытались использовать итеративность в качестве метода

4.3. ИТЕРАТИВНЫЕ МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА

197

Рис. 4.7. Матрица фазы — функции модели Гантера

198

ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ

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

поставило итеративность в основу своих технологий и своих моделей жищ-

ненного цикла, по этой причине ныне часто итеративные методы органи-

зации развития программных систем отождествяют с объектно-ориентиро-

ванными, ставя (как мы уже отмечали для сентенциального и «логического»

программирования) второстепенные признаки на главное место и абсолюти-

зируя конкретную реализацию

. Здесь выделяются те особенности итератив-

ной разработки программ, которые (хоть и были в большинстве своем в ООП

впервые либо рассмотрены и использованы,либо развиты и доведены до тех-

нологических решений) не зависят от нынешних конкретных реализаций и

могут быть перенесены, в частности, на функциональный и сентенциальный

стили, также допускающие итеративное развитие программ, но менее задей-

ствованнные в современных технологиях.

Функциональный стиль соответствует абстрактному (математическому)

мышлению, объектно-ориентированный — образному (визуальному), сен-

тенциальный — вербальному (словесному). Большие и успешные проекты,

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

лей. Если ООП является стандартным методом индустриального программи-

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

методов сообщества

Open Source

, и в качестве итеративного проекта, реа-

лизованного на этой базе, можно сослаться хотя бы на

EMACS

(или, если

Вы признаете лишь коммерческое программное обеспечение, на

AUTOCAD

Сентенциальный стиль в его

PROLOG

овском варианте послужил основой ря-

да крупных баз знаний.

Если развить модель Гантера с целью учета итеративности, то, очевидно,

придется предусмотреть расщепление линии жизненного цикла, как это пред-

ставлено на рис. 4.8. Но это влечет и расщепление матрицы интенсивностей

выполняемых функций: было бы необоснованно считать, что интенсивно-

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

к своему завершению, они должны уменьшаться. Таким образом, матрица

интенсивностей превращается в последовательность матриц, отражающую

Сообщество

Open Source

также немедленно занялось разработкой технологической под-

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

CVS

вовсю используются индустриальными фирмами. Но ООП имело преимущество в мощно-

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

время как

Open Source

делало ставку на специалистов и энтузиастов и занималось скорее

созданием общественного движения и общественного мнения. Поэтому практически все на-

ходки итеративной разработки в данный момент ассоциируются с ООП.

4.3. ИТЕРАТИВНЫЕ МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА

199

Рис. 4.8. Учет итеративности в модели фазы-функции (фазовое измерение,

показаны лишь некоторые возвраты)

итеративный характер развития проекта.

В технологическом плане итеративные подходы к развитию проекта ко-

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

диционных подходов итерация — это исправление ошибок, т. е. процесс, ко-

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

ративном подходе итерации в принципе не отменяют результаты друг друга,

а только дополняют и развивают их.

4.3.1. Базовые технологические принципы итеративного проектиро-

вания

Рассмотрим принципиальные моменты,которые стали трактоваться в ите-

ративном подходе к развитию проектов по-иному в сравнении с последова-

тельными методологиями.

Итеративность развития

Начиная с фазы анализа и до завершения реализации, процесс проекти-

рования строится как серия итераций, отбрасывая иллюзию о построе-

нии программы сразу и до конца, пронизывающую традиционные под-

200

ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ

ходы.Каждая итерация является результатом разрешения противоречий

между желаемым и достижимым, частично реализуя цели.

Возможно, этим итерациям предшествует период изучения самой пред-

метной области и задач проекта в целом (этапы определения требований

и начального планирования).

II)

Изменение функциональности

Поскольку в ходе развития проекта требования почти всегда пересма-

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

мо реализовывать функциональность таким способом,чтобы пересмотр

ее производился с минимальными затратами.

III)

Глоссарий проекта

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

цессе пересмотра требований и трассировки изменений, индуцирован-

ных пересмотром функциональности, необходимо создание и ведение

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

нимание используемыъ понятий и прослеживающую историю концеп-

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

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

IV)

Наращивание функциональности

Наращивание функциональности проектируемого изделия представля-

ется как развитие сценариев, которые соответствуют описаниям (в раз-

витых технологиях диаграммам)взаимодействия высокоуровневых объ-

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

Эти описания предписывают развитие на этапе программирования опе-

рационной базы проекта:она вырабатывается,исходя из сценариев уров-

ня проектирования (конструирования). Полная функциональность со-

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

стратегия довольно близка классическому методу пошаговой детали-

зации, при использовании которого функциональность наращивается

путем уточнения (доопределения) модулей нижнего уровня. Однако в

отличие от этого метода итеративное наращивание требует, чтобы в ре-

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

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

итерации чаще всего добавляют уже другую функциональность, кото-

рая планируется другим сценарием.

4.3. ИТЕРАТИВНЫЕ МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА

201

Ничто не делается однократно

Последовательный подход предполагает, что анализ завершен перед кон-

струированием,завершение которого предшествует программированию.

Перекрытие этапов (см. п. 4.3) ослабляет это предположение, но прин-

ципиально ситуацию не меняет. В большинстве итеративных проектов

анализ никогда не завершается в течение всего развития проекта, а про-

цесс конструирования сопровождает разработку в ходе всего ее жизнен-

ного цикла.

VI)

Оперирование на размножающихся фазах подобно

Как в начале проектирования, на последующих итерациях анализ пред-

шествует конструированию, за которым следует программирование, те-

стирование и другие виды работ.

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

обыкновенно выполняются вполне традиционные этапы:

1. Определение требований, или планирование итерации, — фиксирует-

ся, что должно быть выполнено на данной итерации в виде описания

области, для которой планируется разработать функциональность на

данной итерации, и что для этого нужно. Обычно этот этап включает

отбор сценариев, которые должны быть реализованы на данной итера-

ции;

2. Анализ — исследуются условия выполнения планируемых требований,

проверяется полнота отобранных сценариев с точки зрения реализации

требуемой функциональности;

3. Моделирование пользовательского интерфейса — коль скоро итерация

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

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

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

тельское представление поведения объектов данной итерации;

4. Конструирование — обычная декомпозиция проекта. Конструирова-

ние включает построение или наращивание иерархии понятий (напри-

мер, системы классов, описания событий и определения реакции на

них и т. д.) В ходе конструирования определяются понятия и их про-

граммные реализации, реализуемые и/или доопределяемые на данной

202

ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ

итерации,и набор функций, которые обеспечивают решение задачи дан-

ной итерации;

5. Реализация (программирование)—программное воплощение решений,

принятых для данной итерации. Необходимым компонентом реализа-

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

модулей их спецификациям (в частности, должно быть обеспечено тре-

буемое поведение объектов);

6. Тестирование — этап комплексной проверки результатов, полученных

на данной итерации;

7. Оценка результатов итерации — этап включает работу, связанную с

рассмотрением полученных результатов в контексте проекта в целом. В

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

с учетом результатов итерации, на какие ранее поставленные вопросы

получены ответы, какие новые вопросы возникают в новых условиях.

4.3.2. Итеративная модификация модели фазы-функции

Этапы итеративного развития проекта остаются практически традицион-

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

го наращивания как модификацию существующих моделей жизненного ци-

кла. В настоящем разделе такая модификация осуществляется для модели

фазы-функции Гантера.

В сравнении с моделью Гантера фазовое измерение жизненного цикла

при итеративном проектировании почти не изменяется:появляется лишь один

дополнительный этап:«Моделирование пользовательского интерфейса», ко-

торый в старой схеме можно рассматривать как часть этапов анализа и/или

конструирования. Однако это весьма существенное дополнение, характери-

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

в жизненном цикле при итеративном развитии проектов связан со следующи-

ми двумя особенностями:

Распределение реализуемых требований по итерациям

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

ранее реализованных сценариев всегда образуют законченную, хотя и

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

причинам, в том числе для исключения двусмысленностей в понима-

нии, необходимо представление планируемого для реализации в виде

4.3. ИТЕРАТИВНЫЕ МОДЕЛИ ЖИЗНЕННОГО ЦИКЛА

203

моделей, согласующих взгляд на систему со стороны пользователей,

заказчиков и других заинтересованных лиц (так называемых инициа-

торов работ) с точкой зрения разработчиков. Эти модели появляются

в ходе этапа анализа, что отражается в их названии: модели уровня ана-

лиза.

Конструирование системы с учетом будущего ее развития, в первую

очередь наращивания ее возможностей

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

тий, взаимосвязанных отношениями. Каждая новая итерация расширя-

ет этот набор понятий путем добавления новых понятий, вступающих

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

расширение корректно практически невозможно без абстрагирования

от деталей реализации существующего и без такого же абстрактного

представления добавляемых понятий. Иными словами, требуется по-

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

ционное представление проектируемой системы.

В приведенном выше перечне этапов жизненного цикла при итеративном

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

построению модельного представлению сценариев.Но это только один аспект

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

нее существенный аспект моделирования, проявляется при конструирова-

нии. Наконец, есть еще третий аспект моделирования, связанный с предъ-

явлением каждой версии программного изделия пользователю, представле-

ние которого о системе, разумеется, не имеет отношения к моделям уровня

конструирования и лишь косвенно связано с моделями уровня анализа. Та-

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

кла, то правильнее будет выделять не только этап моделирования (как это,

следуя уже сложившейся традиции, чаще всего делают в ООП), а технологи-

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

проекта.

В новой схеме жизненного цикла появляется строго регламентированное

расщепление,единственное для всей последовательности работ (см. рис.4.9).

Но этот маршрут отражает не корректировку ошибочно принимаемых реше-

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

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

Любой итеративно развивающийся сложный проект строится на базе уже

204

ГЛАВА 4. ЖИЗНЕННЫЙ ЦИКЛ

Начальная

фаза

проекта

Итеративное зацикливание

Пополнение базового

окружения проекта

Завершение проекта

↔

Окончание работ

Общие требования и общий

план составлены, ближайшая

и перспективные задачи,

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

итераций определены

Рис. 4.9. Фазовое измерение модели жизненного цикла при итетаривном раз-

витии проекта