Процесс разработки ПО

Кластеры

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

Кластер - это группа связанных классов или связанных кластеров (рекурсивное определение).

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

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

В отличие от пакетов кластеры - это не языковая конструкция, а инструмент управления. Они появляются в управляющих файлах Lace, используемых для сборки системы из компонентов. Успешное объединение классов в кластеры определяется главным образом здравым смыслом и опытом руководителя проекта. Этот момент заслуживает особого внимания, поскольку его роль часто недооценивается. Идентификация классов, то есть выбор надлежащих абстракций данных, - действительно трудная задача, удачное решение которой создает условия для благоприятного развития работ, а неудачное может привести к краху проекта. Группировка же классов в кластеры является организационной проблемой, она может быть решена различными способами в зависимости от доступных ресурсов и квалификации членов группы. Неоптимальное формирование кластеров может причинить неприятности и замедлить разработку, но не может стать причиной неудачи проекта.

Параллельная разработка

Одно из последствий деления на кластеры - уход от недостатков традиционной бескомпромиссной модели жизненного цикла ПО. Известная Модель Водопада, введенная в 1970 г., была реакцией против устаревшего подхода "раньше запрограммируйте, а потом опишите". Заслуга этого подхода выражается в распределении обязанностей, определении основных задач разработки ПО и в подчеркивании важности открытой спецификации.

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

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

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

Рис. 10.1. Модель Водопада

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

Вот как выглядит жизненный мини-цикл разработки кластера:

Рис. 10.2. Жизненный цикл отдельного кластера

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

Этапы и задачи

Жизненный цикл каждого кластера включает следующие этапы:

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

Иногда трудно четко разграничить этапы проектирования и реализации. Поэтому возможны варианты модели, объединяющие эти этапы в один, - "проектирования-реализации".

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