Лекция 9: Моделирование объектно-ориентированного жизненного цикла программных проектов

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

Принципы объектно-ориентированного проектирования

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

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

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

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

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

3. Формирование системы понятий проекта.

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

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

Задание ситуаций использования (use cases) для определения того, как контактирует пользователь с системой, — первый уровень моделей, предполагаемый объектно-ориентированным проектированием. Эти модели фиксируют ситуации, которые возникают при взаимодействии пользователя с системой. Содержательные действия системы с пользователями выводятся из них в виде сценариев. Ситуации использования и сценарии — основа формулирования требований в том виде, в котором их можно предъявлять для разработки архитектуры.

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

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

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

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

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

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

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

• Определение требований, или планирование итерации, — фиксируется, что должно быть выполнено на данной итерации в виде описания области, для которой планируется разработать функциональность на данной итерации, и что для этого нужно. Обычно этот этап включает отбор сценариев, которые должны быть реализованы на данной итерации.
• Анализ — исследуются условия выполнения планируемых требований, проверяется полнота отобранных сценариев с точки зрения реализации требуемой функциональности.
• Моделирование пользовательского интерфейса — коль скоро итерация должна обеспечивать функционально законченную реализацию, требуется определить правила взаимодействий, необходимые для активизации предоставляемых функций. Модель интерфейса задает пользовательское представление поведения объектов данной итерации.
• Конструирование — обычная декомпозиция проекта, проводимая в объектно-ориентированном стиле. Конструирование включает построение или наращивание иерархии системы классов, описание событий и определение реакции на них и т.д. В ходе конструирования определяются объекты, реализуемые и/или доопределяемые на данной итерации, и набор функций (методов объектов), которые обеспечивают решение задачи данной итерации.
• Реализация (программирование) — программное воплощение решений, принятых для данной итерации. Необходимым компонентом реализации здесь считается автономная проверка соответствия составляемых модулей их спецификациям (в частности, должно быть обеспечено требуемое поведение объектов).
• Тестирование — этап комплексной проверки результатов, полученных на данной итерации. Как и в традиционных схемах, тестирование в качестве этапа часто объединяют со следующим этапом жизненного цикла.
• Оценка результатов итерации — этап включает работу, связанную с рассмотрением полученных результатов в контексте проекта в целом. В частности, должно быть выяснено, какие задачи проекта можно решать с учетом результатов итерации, на какие ранее поставленные вопросы получены ответы, какие новые вопросы возникают в новых условиях.