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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В далекой стране миссионер ругал аборигенов: "Вы не должны ходить обнаженными, показывая ваше тело!". Однажды маленькая девочка возразила, указывая на него: "Но Вы, Отец, также показываете часть вашего тела!". "Ну конечно", - величественно произнес миссионер. - "Это мое лицо". Девочка ответила: "То, что видите Вы, Отец, на самом деле то же самое. Только у нас все - лицо".

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