Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++, страница 3

Я общался ссотнями профессиональных программистов и менеджеров и благодарю их всех за то,что они помогли сделать эту книгу отвечающей проблемам реальной жизни.Особая благодарность - компании Rational за поддержку моего труда. Спасиботакже моему редактору Дэну Йоранстаду (DanJoraanstad) за его постоянную поддержкуи Тони Холлу (Tony Hall), рисунки которого внесли жизнь в то, что без них осталосьбы еще одной скучной технической книгой.

Наконец, спасибо трем моим кошкам,Кэми (Сату), Энни (Annie) и Тени (Shadow), составлявшим мне компанию в долгиечасы ночной работы.ЧАСТЬ ПЕРВАЯКонцепцииСэр Исаак Ньютон по секрету признавался друзьям, что он знает, какгравитация ведет себя, но не знает, почему.Лили Томлин (Lily Tomlin)В поисках признаков разумной жизни во Вселенной(The Search for Signs of Intelligent Life in the Universe)Глава 1СложностьВрач, строитель и программистка спорили о том, чья профессия древнее. Врач заметил: «В Библии сказано,что Бог сотворил Еву из ребра Адама. Такая операция может быть проведена только хирургом, поэтому я поправу могу утверждать, что моя профессия самая древняя в мире».

Тут вмешался строитель и сказал: «Ноеще раньше в Книге Бытия сказано, что Бог сотворил из хаоса небо и землю. Это было первое и,несомненно, наиболее выдающееся строительство. Поэтому, дорогой доктор, вы не правы. Моя профессиясамая древняя в мире». Программистка при этих словах откинулась в кресле и с улыбкой произнесла: «А ктоже по-вашему сотворил хаос?»1.1. Сложность, присущая программному обеспечениюПростые и сложные программные системыЗвезда в преддверии коллапса; ребенок, который учится читать; клетки крови, атакующиевирус, — это только некоторые из потрясающе сложных объектов физического мира.Компьютерные программы тоже бывают сложными, однако их сложность совершенно другогорода.

Брукс пишет: «Эйнштейн утверждал, что должны существовать простые объясненияприродных процессов, так как Бог не действует из каприза или по произволу. У программиста неттакого утешения: сложность, с которой он должен справиться, лежит в самой природе системы»[I].Мы знаем, что не все программные системы сложны. Существует множество программ,которые задумываются, разрабатываются, сопровождаются и используются одним и тем жечеловеком. Обычно это начинающий программист или профессионал, работающий изолированно.Мы не хотим сказать, что все такие системы плохо сделаны или, тем более, усомниться вквалификации их создателей. Но такие системы, как правило, имеют очень ограниченную областьприменения и короткое время жизни.

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

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

Увы, носложность, о которой мы говорим, по-видимому, присуща всем большим программных системам.Говоря «присуща», мы имеем в виду, что эта сложность здесь неизбежна: с ней можно справиться,но избавиться от нее нельзя.Конечно, среди нас всегда есть гении, которые в одиночку могут выполнить работугруппы обычных людей-разработчиков и добиться в своей области успеха, сравнимого сдостижениями Франка Ллойда Райта или Леонардо да Винчи. Такие люди нам нужны какархитекторы, которые изобретают новые идиомы, механизмы и основные идеи, используемыезатем при разработке других систем.

Однако, как замечает Петере: «В мире очень мало гениев, ине надо думать, будто в среде программистов их доля выше средней» [2]. Несмотря на то, что всемы чуточку гениальны, в промышленном программировании нельзя постоянно полагаться набожественное вдохновение, которое обязательно поможет нам. Поэтому мы должны рассмотретьболее надежные способы конструирования сложных систем. Для лучшего понимания того, чеммы собираемся управлять, сначала ответим на вопрос: почему сложность присуща всем большимпрограммным системам?Почему программному обеспечению присуща сложность?Как говорит Брукс, «сложность программного обеспечения — отнюдь не случайное егосвойство» [З].

Сложность вызывается четырьмя основными причинами: сложностью реальнойпредметной области, из которой исходит заказ на разработку;трудностью управления процессом разработки; необходимостью обеспечить дос-таточнуюгибкость программы; неудовлетворительными способами описания поведения большихдискретных систем.Сложность реального мира. Проблемы, которые мы пытаемся решить с помощьюпрограммного обеспечения, часто неизбежно содержат сложные элементы, а к соответствующимпрограммам предъявляется множество различных, порой взаимоисключающих требований.Рассмотрим необходимые характеристики электронной системы многомоторного самолета,сотовой телефонной коммутаторной системы и робота. Достаточно трудно понять, даже в общихчертах, как работает каждая такая система. Теперь прибавьте к этому дополнительные требования(часто не формулируемые явно), такие как удобство, производительность, стоимость, выживаемость и надежность! Сложность задачи'и порождает ту сложность программного продукта, окоторой пишет Брукс.Эта внешняя сложность обычно возникает из-за «нестыковки» между пользователямисистемы и ее разработчиками: пользователи с трудом могут объяснить в форме, понятнойразработчикам, что на самом деле нужно сделать.

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

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

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

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

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

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

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