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

Кластеры

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кластерная модель жизненного цикла ПО

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

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

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

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

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

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

Обобщение

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

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

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

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

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

Даже если дополнительные ресурсы предусмотрены, то только этого недостаточно. Залогом успеха служит комбинация усилий a priori и a posteriori:

Не верьте в готовность ПО к повторному использованию, пока не увидите, что оно действительно использовано.

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

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

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

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

Бесшовность и обратимость

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

Бесшовная разработка

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

Выгоды от бесшовного подхода многочисленны:

Обратимость: мудрость иногда расцветает слишком поздно

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

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

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

Это явление отражает поговорка - esprit de l'escalier, ("лестничное остроумие", остроумие задним числом). Вообразите приятный обед в фешенебельной парижской квартире на третьем этаже. Со всех сторон звучат остроты по поводу телятины Marengo, а Вы будто онемели. Суаре заканчивается, Вы попрощались с хозяевами, спускаетесь по лестнице и вдруг - вот она, разящая остроумная реплика, которая сделала бы Вас героем вечера! Но слишком поздно.

Имеют ли место приступы esprit de l'escalier в программном обеспечении? Они существуют с тех пор, как стали замораживать спецификацию прежде, чем приступить к решению. Плохие менеджеры подавляют программистов - пишите код и помалкивайте. Хорошие менеджеры стараются использовать в своих интересах запоздалые идеи спецификации, не обращая внимания на то, кто отвечает за данную проблему, и невзирая на требования стиля водопада.

С развитием OO-разработки стало ясно, что явление esprit de l'escalier - не только результат лени при анализе, но и отражение самой природы процесса разработки ПО. Мудрость иногда приходит слишком поздно. Нигде более, чем в объектной технологии, не проявляется так явно связь между проблемой и решением. Не только потому, что мы иногда понимаем аспекты проблемы только в процессе решения, но и по более глубокой причине. Решение воздействует на проблему и может предложить лучший функциональный подход.

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

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

У нас все - лицо

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

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

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

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

Следующая история, заимствованная из книги Романа Якобсона " Essays on General Linguistics ", поможет поставить точку:

Так же обстоит дело с объектной технологией. У нас все - лицо!

Ключевые концепции

Библиографические замечания

Монография [M 1995] посвящена подробному обсуждению тематики данной лекции. В ней содержится подробное изложение кластерной модели, обсуждается влияние ОО-метода на организацию работы групп, роль менеджера, экономику разработки ПО.

[Baudoin 1996] посвящена проблемам жизненного цикла, связанным с объектной технологией, а также охватывает много других важных тем, включая организацию проекта, роль стандартов и некоторые социологические аспекты.

Кластерная модель была впервые представлена в [Gindre 1989]. Другая ОО-модель жизненного цикла, "модель фонтана", была предложена в [Henderson-Sellers 1990] и далее разработана в [Henderson-Sellers 1991], [Henderson-Sellers 1994]. Подчеркивая необходимость итераций, она скорее дополняет кластерную модель, нежели ей противоречит.

Ряд публикаций по ОО-анализу, в частности [Rumbaugh 1991] (оригинальная работа по методу OMT) и [Henderson-Sellers 1991], особое внимание уделяют бесшовности разработки. Детальное рассмотрение проблем бесшовности и обратимости см. в [Walden 1995].

***

		Wisdom sometimes blooms late in the season
		Or half-way down the stairs.
		Is it, my Lords, a crime of high treason
		To trust the  implementersУ мудрости цветы цветут зимой,
И встречи с ней на лестнице не редки.
Прости, господь, но разве грех большой,
Что программисту доверяются проекты?