Кони Бюрер,
специалист в области разработки ПО,
компания Rational Software

Проектирование – внутренний характер разработки ПО

Проблемы разработки программного обеспечения? Есть простое пояснение!

Тот факт, что разработка ПО изначально является проектированием, помогает объяснить некоторые зачастую трудные для понимания вопросы. Ниже приведено несколько примеров.

Вопрос. Почему намного труднее создать структуру подробного перечня работ для создания программного обеспечения, чем для строительства небоскреба?

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

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

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

Вопрос. Почему масштабирование разработки ПО не влечет за собой соответствующего роста экономической эффективности?

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

Вопрос. Возможно ли повысить экономическую эффективность при масштабировании производства ПО?

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

Вопрос. Почему так низок уровень повторного использования программного обеспечения?

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

Как же могло так случиться? Почему идеология проб и ошибок так глубоко проникла в программирование? Почему мы до сих пор не исследовали фундаментальные законы программирования и не открыли его основные принципы?

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

1. Граница между проектированием и строительством всегда четко обозначена артефактом – чертежом. Проектирование включает в себя все операции, необходимые для создания чертежа, а строительство охватывает все операции, необходимые для создания продуктов по этому чертежу. В идеальном случае чертеж должен определять создаваемый продукт во всех подробностях – что, конечно же, бывает очень редко. Тем не менее, целью чертежа является настолько подробное описание конструируемого продукта, насколько это возможно. Описывает ли проект архитектуры программной системы создаваемый продукт "во всех подробностях"? Нет. Проект архитектуры предназначен для описания существенных, но, безусловно, не всех подробностей программной системы. Поэтому очевидно, что проект архитектуры не является чертежом. Все подробности программной системы описываются только кодом на языке высокого уровня, который, таким образом, является чертежом программы. А поскольку все операции, ведущие к созданию чертежа, являются проектированием, то и вся разработка ПО должна считаться проектированием.
2. Объем работ (время, деньги, ресурсы), необходимый для создания коммерческого продукта, всегда может быть разделен на проектировочную и производственную составляющие. В чем разница? Объем работ проектирования является общим для всех копий продукта и должен быть затрачен только один раз. Объем работ с точки зрения производства должен затрачиваться при создании каждой копии продукта. Программный продукт обычно представляет собой двоичный исполняемый файл программы, поставляемой на компакт-диске. Ясно, что усилия по созданию исходного кода программы – включая проект архитектуры, подробный проект и код на языке высокого уровня – должны быть затрачены лишь однажды, независимо от количества выпущенных копий программного обеспечения. Следовательно, усилия по созданию исходного кода программы являются целиком проектировочными, а вся разработка программного обеспечения является проектированием.

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

Чтобы понять, почему программисты до сих пор не увидели и не нашли основных принципов, представим себе мир, в котором создание небоскреба не требует ничего, кроме подробного чертежа. Имея чертеж, архитектор мог бы одним нажатием кнопки построить небоскреб – мгновенно и практически без затрат. Затем архитектор мог бы проверить небоскреб и сравнить его с техническими требованиями. Если бы он разрушился или не смог пройти проверку, архитектор мог бы его снести и убрать обломки – мгновенно и опять же без затрат. Стал бы этот архитектор тратить много времени на формальную проверку согласованности проекта с физическими законами? Или хотя бы пытаться исследовать и понять эти законы? Вряд ли. Он, вероятно, смог бы получить результаты быстрее путем многократного строительства, проверки и сноса небоскреба, каждый раз внося исправления в чертеж. В мире, где строительство и разрушение бесплатны, выбирается метод проб и ошибок, а фундаментальные исследования остаются для простаков.

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

Метод проб и ошибок завел нас достаточно далеко. Но рост сложности современных программных систем подводит нас к жесткому пределу. За пределами определенного уровня сложности создание качественных архитектур методом проб и ошибок становится невозможным.

Предложение: основные принципы разработки программного обеспечения

Без основных принципов разработка ПО навсегда останется ремеслом, а кризис ПО (прерванные проекты, перерасход бюджета, задержки, низкое качество результатов) станет постоянным. Попытаемся же найти некоторые основные принципы – но где? Физические законы не применимы к программному обеспечению. Означает ли это, что основные принципы разработки ПО не существуют? Или же мы просто недостаточно внимательно их искали?

Рассмотрим, как существование основного принципа – например, закона гравитации – влияет на архитектуру системы. С абстрактной точки зрения основной принцип делает не что иное, как вводит не подлежащие обсуждению требования, которые должен учитывать архитектор. Я буду называть эти требования аксиоматическими. Например, для строительства простым аксиоматическим требованием может быть следующее: "Здание должно выдерживать силу гравитации". Отличие аксиоматических требований состоит в том, что они относятся к каждой системе, которая когда-либо была или будет построена. Аксиоматические требования являются, в сущности, настолько очевидными и общими, что они, как правило, подразумеваются. Но из аксиоматических требований установившиеся инженерные дисциплины выводят систему архитектурных правил, которым должны соответствовать все заслуживающие внимания проекты. Проекты, нарушающие эти правила, очевидно не согласуются с основными принципами и, возможно, являются ошибочными.

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

1. Программное обеспечение должно получать входные данные с одного или нескольких внешних (аппаратных) интерфейсов.
2. Программное обеспечение должно выдавать выходные данные на один или несколько внешних (аппаратных) интерфейсов.
3. Программное обеспечение должно вести внутренние данные, используемые и обновляемые в каждом цикле выполнения.
4. Программное обеспечение должно преобразовывать входные данные в выходные (возможно с использованием внутренних данных).
5. Программное обеспечение должно выполнять преобразование данных как можно быстрее.

Звучит глупо, не так ли? Но, поверьте, очень немного программных систем обладают архитектурой, которая очевидно удовлетворяет вышеприведенным аксиоматическим требованиям. Многие программные системы могут неявно соответствовать этим требованиям, но это не очевидно!^*

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

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

Следующий шаг: определение универсальной модели проектирования

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

1. Или подробный проект, если компилятор может генерировать код непосредственно по моделям проекта.
2. Итеративная разработка только отодвигает предел сложности, который может быть достигнут методом проб и ошибок.
3. Популярный метод проектирования состоит в определении существительных в документах технического задания и ассоциировании класса с каждым существительным. Функциональные возможности системы моделируются обменом сообщениями между классами. Этот метод проектирования неизменно приводит к программной архитектуре, в которой очень сложно проверить аксиоматические требования

• Эффективная разработка программного обеспечения с использованием технологий и инструментов компании Rational
• Rational Unified Process - методология создания программного обеспечения
• Здесь можно получить ознакомительные версии.

За дополнительной информацией обращайтесь в Interface Ltd.

Отправить ссылку на страницу по e-mail
Обсудить на форуме Rational