Цели и средства

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

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

Ясная внутренняя структура программы облегчает:

тестирование,переносимость,сопровождение,расширение,реорганизацию ипонимание.

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

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

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

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

Недостатки такого подхода состоят в следующем:

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

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

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

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

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

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

Далее будет предполагаться, что проект системы записывается как ряд определений классов (в которых частные описания опущены как лишние детали) и взаимоотношений между ними. Это упрощение, т.к. конкретный проект может учитывать: вопросы параллельности, использование глобального пространства имен, использование глобальных функций и данных, построение программы для минимизации перетрансляции, устойчивость, многомашинный режим и т.п. Но при обсуждении на данном уровне детализации без упрощения не обойтись, а классы в контексте С++ являются ключевым понятием проектирования. Некоторые из указанных вопросов будут обсуждаться ниже, а те, которые прямо затрагивают проектирование библиотек С++, будут рассмотрены в лекции 13. Более подробное обсуждение и примеры определенных методов объектно- ориентированного проектирования содержатся в [2].

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

Цели проектирования

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

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

гибкости,расширяемости ипереносимости

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

Рассмотрим пример: в задаче моделирования метеорологических объектов нужно представить дождевое облако. Как это сделать? У нас нет общего метода изображения облака, поскольку его вид зависит от внутреннего состояния облака, а оно может быть задано только самим облаком.

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

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

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

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

Дождевые облака - это не тот объект, который часто встретишь в программах, но объекты, участвующие в различных операциях ввода и вывода, встречаются часто. Поэтому можно считать пример с облаком пригодным для программирования вообще и для разработки библиотек в частности. Логически схожий пример в С++ представляют манипуляторы, которые используются для форматирования вывода в потоковом вводе-выводе (§10.4.2). Заметим, что третье решение не есть "верное решение", это просто более общее решение. Разработчик должен сбалансировать различные требования системы, чтобы найти уровень общности и абстракции, пригодный для данной задачи в данной области. Золотое правило: для программы с долгим сроком жизни правильным будет самый общий уровень абстракции, который вам еще понятен и который вы можете себе позволить, но не обязательно абсолютно общий. Обобщение, выходящее за пределы данного проекта и понятия людей, в нем участвующих, может принести вред, т.е. привести к задержкам, неприемлемым характеристикам, неуправляемым проектам и просто к провалу.

Чтобы использование указанных методов было экономично и поддавалось управлению, проектирование и управление должно учитывать повторное использование, о чем говорится в §11.4.1 и не следует совсем забывать об эффективности (см. §11.3.7).

Человеческий фактор

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

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

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

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

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

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

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

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

Цикл развития

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

Создать общее описание проекта.Выделить стандартные компоненты. [a] Подогнать компоненты под данный проект.Создать новые стандартные компоненты.[a] Подогнать компоненты под данный проект.Составить уточненное описание проекта.

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

Итак, допустим необходимо создать машину среднего размера с четырьмя дверцами и достаточно мощным мотором. Очевидно, что на первом этапе проекта не следует начинать проектирование машины (и всех ее компонентов) с нуля. Хотя программист или разработчик программного обеспечения в подобных обстоятельствах поступит именно так.

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

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

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

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

Мы не пытаемся утверждать, что все разработчики машин действуют столь разумно, как в приведенном примере, а разработчики программ совершают все указанные ошибки. Утверждается, что указанная методика разработки машин применима и для программного обеспечения. Так, в этой и следующей лекциях даны приемы использования ее для С++. Тем не менее можно сказать, что сама природа программирования способствует совершению указанных ошибок (§12.2.1 и §12.2.5). В разделе 11.4.3 опровергается профессиональное предубеждение против использования описанной здесь модели проектирования.

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

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

Использование моделей

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

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

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

Естественно, что выбор начальной модели является важным решением, и обычно оно принимается только после поиска потенциальных моделей и тщательной оценки вариантов. Более того, во многих случаях модель подходит только при условии понимания того, что потребуются значительные изменения для воплощения ее идей в иной области приложения. Но проектирование программного обеспечения - тяжелый труд, и надо использовать любую помощь. Не следует отказываться от использования моделей из-за неоправданного пренебрежения к имитации. Имитация - не что иное, как форма искреннего восхищения, а, с учетом права собственности и авторского права, использование моделей и предшествующих работ в качестве источника вдохновения - допустимый способ для всех новаторских работ во всех видах деятельности. То, что было позволено Шекспиру, подходит и для нас. Некоторые обозначают использование моделей в процессе проектирования как "проектирование повторного использования".

Эффективность

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

Лучший способ добиться эффективности - это создать ясный и простой проект. Только такой проект может остаться относительно устойчивым на весь период развития и послужить основой для настройки системы с целью повышения производительности. Здесь важно избежать "гаргантюализма", который является проклятием больших проектов. Слишком часто люди добавляют определенные возможности системы "на всякий случай" (см. §11.3.3.2 и §11.4.3), удваивая, учетверяя размер выполняемой программы ради завитушек. Еще хуже то, что такие усложненные системы трудно поддаются анализу, а по этому трудно отличить избыточные накладные расходы от необходимых и провести анализ и оптимизации на общем уровне. Оптимизация должна быть результатом анализа и оценки производительности системы, а не произвольным манипулированием с программным кодом, причем это особенно справедливо для больших систем, где интуиция разработчика или программиста не может служить надежным указателем в вопросах эффективности.

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

Эксперимент и анализ

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

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

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

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

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

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

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

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

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

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

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

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

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

Перестройка иерархии классов

Шаги 1 и 3 требуют исследования классов и их иерархии, чтобы убедиться, что они адекватно отвечают нашим требованиям. Обычно это не так, и приходится проводить перестройку для улучшения структуры, проекта или реализации.

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

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

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

Повторное использование

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

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

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

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

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

Нельзя недооценивать такие группы "стандартных компонентов".

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

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

Процесс развития

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

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

У процесса развития три стадии:

Анализ: определение области задачи.Проектирование: создание общей структуры системы.Реализация: программирование и тестирование.

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

Экспериментирование.Тестирование.Анализ проектирования и реализации.Документирование.Сопровождение.

Сопровождение программного обеспечения рассматривается просто как еще несколько проходов по стадиям процесса развития (см. также §11.3.6).

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

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

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

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

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

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

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

Размер

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

Вернемся к этапам процесса развития, перечисленным в §11.3, и к шагам проектирования, указанным в §11.3.3. Относительно просто переработать эти этапы в точный метод проектирования, когда шаг точно определен, имеет хорошо определенные входные и выходные данные и полуформальную запись для задания входных и выходных данных. Можно составить протокол, которому должно подчиняться проектирование, создать средства, предоставляющие определенные удобства для записи и организации процесса. Далее, исследуя классификацию зависимостей, приведенную в §12.2, можно постановить, что определенные зависимости являются хорошими, а другие следует считать плохими, и предоставить средства анализа, которые обеспечат проведение таких оценок во всех стадиях проекта. Чтобы завершить такую "стандартизацию" процесса создания программ, можно было бы ввести стандарты на документацию (в том числе правила на правописание и грамматику и соглашения о формате документации), а так же стандарты на общий вид программ (в том числе указания какие средства языка следует использовать, а какие нет, перечисление допустимых библиотек и тех, которые не нужно использовать, соглашения об именовании функций, типов, переменных, правила расположения текста программы и т.д.).

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

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

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

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

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

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

определение интерфейсов

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

Отметим, что общие базовые классы и друзья (friend) являются частью общего интерфейса класса (см. §5.4.1 и §12.4). Полезным упражнением может быть определение раздельного интерфейса для классов-наследников и всех остальных классов с помощью разбиения интерфейса на общую и закрытые части.

Именно на этом шаге следует продумать и описать точные определения типов аргументов. В идеале желательно иметь максимальное число интерфейсов со статическими типами, относящимися к области приложения (см. §12.1.3 и §12.4).

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

определение классов

Определите понятия/классы и установите основные связи между ними. Главное в хорошем проекте - прямо отразить какое-либо понятие "реальности", т.е. уловить понятие из области приложения классов, представить взаимосвязь между классами строго определенным способом, например, с помощью наследования, и повторить эти действия на разных уровнях абстракции. Но как мы можем уловить эти понятия? Как на практике решить, какие нам нужны классы?

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

Часто говорят, что существительные играют роль классов и объектов, используемых в программе, это действительно так. Но это только начало. Далее, глаголы могут представлять операции над объектами или обычные (глобальные) функции, вырабатывающие новые значения, исходя из своих параметров, или даже классы. В качестве примера можно рассматривать функциональные объекты, описанные в §10.4.2. Такие глаголы, как "повторить" или "совершить" (commit) могут быть представлены итеративным объектом или объектом, представляющим операцию выполнения программы в базах данных.

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

Лучшее средство для поиска этих понятий / классов - грифельная доска, а лучший метод первого уточнения - это беседа со специалистами в области приложения или просто с друзьями. Обсуждение необходимо, чтобы создать начальный жизнеспособный словарь терминов и понятийную структуру. Мало кто может сделать это в одиночку. Обратитесь к [1], чтобы узнать о методах подобных уточнений.

Не все классы соответствуют понятиям из области приложения. Некоторые могут представлять ресурсы системы или абстракции периода реализации (см. §12.2.1).

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

В §11.3.3.2 и §11.3.3.5 предлагается некоторая точка зрения на классы и иерархию классов, если необходимо улучшить их структуру.

определение набора операций

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

Возможно несколько подходов к процессу определения набора операций.

Предлагаем следующую стратегию:

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

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

Причина, по которой мы требуем явного принятия решения о виртуальности данной функции, не оставляя его на стадию реализации, в том, что, объявив функцию виртуальной, мы существенно повлияем на использование ее класса и на взаимоотношения этого класса с другими. Объекты из класса, имеющего хотя бы одну виртуальную функцию, требуют нетривиального распределения памяти, если сравнить их с объектами из таких языков как С или Фортран. Класс с хотя бы одной виртуальной функцией по сути выступает в роли интерфейса по отношению к классам, которые "еще могут быть определены", а виртуальная функция предполагает зависимость от классов, которые "еще могу быть определены" (см. §12.2.3)

Отметим, что стратегия минимализма требует, пожалуй, больших усилий со стороны разработчика.

При определении набора операций больше внимания следует уделять тому, что надо сделать, а не тому, как это делать.

Иногда полезно классифицировать операции класса по тому, как они работают с внутренним состоянием объектов:

Базовые операции: конструкторы, деструкторы, операции копирования.Селекторы: операции, не изменяющие состояния объекта.Модификаторы: операции, изменяющие состояние объекта.Операции преобразований, т.е. операции порождающие объект другого типа, исходя из значения (состояния) объекта, к которому они применяются. Повторители: операции, которые открывают доступ к объектам класса или используют последовательность объектов.

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

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

и проектирования

Рассмотрим проектирование отдельного класса. Обычно это не лучший метод. Понятия не существуют изолированно, наоборот, понятие определяется в связи с другими понятиями. Аналогично и класс не существует изолированно, а определяется совместно с множеством связанных между собой классов. Это множество часто называют библиотекой классов или компонентом. Иногда все классы компонента образуют единую иерархию, иногда это не так (см. §12.3).

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

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

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

Определить понятие / класс и установить основные связи между ними.Уточнить определения классов, указав набор операций для каждого. [a] Провести классификацию операций. В частности уточнить необходимость построения, копирования и уничтожения.[b] Убедиться в минимальности, полноте и удобстве.

Уточнить определения классов, указав их зависимость от других классов.[a] Наследование.[b] Использование зависимостей.
Определить интерфейсы классов. [a] Поделить функции на общие и защищенные.[b] Определить точный тип операций класса.
Отметим, что это шаги итеративного процесса. Обычно для получения проекта, который можно уверенно использовать для первичной реализации или повторной реализации, нужно несколько раз проделать последовательность шагов. Одним из преимуществ глубокого анализа и предложенной здесь абстракции данных оказывается относительная легкость, с которой можно перестроить взаимоотношения классов даже после программирования каждого класса. Хотя это никогда не бывает просто.
Далее следует приступить к реализации классов, а затем вернуться, чтобы оценить проект, исходя из опыта реализации. Рассмотрим эти шаги в отдельности.

Сопровождение

"Сопровождение программного обеспечения" - неудачный термин. Слово "сопровождение" предлагает неверную аналогию с аппаратурой. Программы не требуют смазки, не имеют движущихся частей, которые изнашиваются так, что требуют замены, у них нет трещин, в которые попадает вода, вызывая ржавчину. Программы можно воспроизводить в точности и передавать в течении минуты на длинные расстояния. Короче, программы это совсем не то, что аппаратура. (В оригинале: "Software is not hardware").

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

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

Список литературы с комментариями

В этой лекции мы только поверхностно затронули вопросы проектирования и управления программными проектами. По этой причине ниже предлагается список литературы с комментариями. Значительно более обширный список литературы с комментариями можно найти в [2].

Bruce Anderson and Sanjiv Gossain: An Iterative Design Model for Reusable Object-Oriented Software. Proc. OOPSLA'90. Ottawa, Canada. pp. 12-27. Описание модели итеративного проектирования и повторного проектирования с некоторыми примерами и обсуждением результатов.Grady Booch: Object Oriented Design. Benjamin Cummings. 1991. В этой книге есть детальное описание проектирования, определенный метод проектирования с графической формой записи и несколько больших примеров проекта, записанных на различных языках. Это превосходная книга, которая во многом повлияла на эту лекцию. В ней более глубоко рассматриваются многие из затронутых здесь вопросов.Fred Brooks: The Mythical Man Month. Addison Wesley. 1982. Каждый должен перечитывать эту книгу раз в пару лет. Предостережение от высокомерия. Она несколько устарела в технических вопросах, но совершенно не устарела во всем, что касается отдельного работника, организации и вопросов размера.Fred Brooks: No Silver Bullet. IEEE Computer, Vol.20 No.4. April 1987. Сводка различных подходов к процессу развития больших программных систем с очень полезным предостережением от веры в магические рецепты ("золотая пуля"). De Marco and Lister: Peopleware. Dorset House Publishing Co. 1987. Одна из немногих книг, посвященных роли человеческого фактора в производстве программного обеспечения. Необходима для каждого менеджера. Достаточно успокаивающая для чтения перед сном. Лекарство от многих глупостей.Ron Kerr: A Materialistic View of the Software "Engineering" Analogy. in SIGPLAN Notices, March 1987. pp 123-125. Использование аналогии в этой и следующей лекциях во многом обязано наблюдениям из указанной статьи, а так же беседам с Р. Керром, которые этому предшествовали.Barbara Liskov: Data Abstraction and Hierarchy. Proc. OOPSLA'87 (Addendum). Orlando, Florida. pp 17-34. Исследуется как использование наследования может повредить концепции абстрактных данных. Укажем, что в С++ есть специальные языковые средства, помогающие избежать большинство указанных проблем (§12.2.5).C. N. Parkinson: Parkinson's Law and other Studies in Administration. Houghton-Mifflin. Boston. 1957. Одно из забавных и самых язвительных описаний бед, к которым приводит процесс администрирования.Bertrand Meyer: Object Oriented Software Construction. Prentice Hall. 1988. Страницы 1-64 и 323-334 содержат хорошее описание одного взгляда на объектно-ориентированное программирование и проектирование, а также много здравых, практических советов. В остальной части книги описывается язык Эйффель (Eiffel).Alan Snyder: Encapsulation and Inheritance in Object-Oriented Programming Languages. Proc. OOPSLA'86. Portland, Oregon. pp.38-45. Возможно первое хорошее описание взаимодействия оболочки и наследования. В статье так же на хорошем уровне рассматриваются некоторые понятия, связанные с множественным наследованием.Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener: Designing Object-Oriented Software. Prentice Hall. 1990. Описывается антропоморфный метод проектирования основанный на специальных карточках CRC (Classes, Responsibilities, Collaboration) (т.е. Классы, Ответственность, Сотрудничество). Текст, а может быть и сам метод тяготеет к языку Smalltalk.

Свод правил

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

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

Узнайте, что вам предстоит создать.Ставьте определенные и осязаемые цели.Не пытайтесь с помощью технических приемов решить социальные проблемы. Рассчитывайте на большой срок в проектировании, иуправлении людьми.Используйте существующие системы в качестве моделей, источника вдохновения и отправной точки.Проектируйте в расчете на изменения: гибкость,расширяемость,переносимость, иповторное использование.Документируйте, предлагайте и поддерживайте повторно используемые компоненты.Поощряйте и вознаграждайте повторное использование проектов,библиотек, иклассов.Сосредоточьтесь на проектировании компоненты. Используйте классы для представления понятий.Определяйте интерфейсы так, чтобы сделать открытым минимальный объем информации, требуемой для интерфейса.Проводите строгую типизацию интерфейсов всегда, когда это возможно.Используйте в интерфейсах типы из области приложения всегда, когда это возможно.Многократно исследуйте и уточняйте как проект, так и реализацию.Используйте лучшие доступные средства для проверки и анализа проекта, иреализации.Экспериментируйте, анализируйте и проводите тестирование на самом раннем возможном этапе.Стремитесь к простоте, максимальной простоте, но не сверх того.Не разрастайтесь, не добавляйте возможности "на всякий случай".Не забывайте об эффективности.Сохраняйте уровень формализации, соответствующим размеру проекта.Не забывайте, что разработчики, программисты и даже менеджеры остаются людьми.

Еще некоторые правила можно найти в §12.5

Тестирование

Программа, которая не прошла тестирование, не работает. Идеал, чтобы после проектирования и (или) верификации программа заработала с первого раза, недостижим для всех, за исключением самых тривиальных программ. Следует стремиться к идеалу, но не заблуждаться, что тестирование простое дело.

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

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

Более важной, чем набор тестов, является подход, когда структура системы такова, что есть реальные шансы убедить себя и пользователей, что ошибки можно исключить с помощью определенного набора статических проверок, статического анализа и тестирования. Если разработана стратегия построения системы, устойчивой к ошибкам (см.§9.8), стратегия тестирования обычно разрабатывается как вспомогательная.

Если вопросы тестирования полностью игнорируются на этапе проектирования, возникнут проблемы с тестированием, временем поставки и сопровождением системы. Лучше всего начать работать над стратегией тестирования с интерфейсов классов и их взаимозависимостей (как предлагается в §12.2 и §12.4).

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

Создание любой нетривиальной программной системы

"Серебряной пули не существует."
Ф. Брукс
Создание любой нетривиальной программной системы - сложная и часто выматывающая задача. Даже для отдельного программиста собственно запись операторов программы есть только часть всей работы. Обычно анализ всей задачи, проектирование программы в целом, документация, тестирование, сопровождение и управление всем этим затмевает задачу написания и отладки отдельных частей программы. Конечно, можно все эти виды деятельности обозначить как "программирование" и затем вполне обоснованно утверждать: "Я не проектирую, я только программирую". Но как бы не назывались отдельные виды деятельности, бывает иногда важно сосредоточиться на них по отдельности, так же как иногда бывает важно рассмотреть весь процесс в целом. Стремясь поскорее довести систему до поставки, нельзя упускать из вида ни детали, ни картину в целом, хотя довольно часто происходит именно это.
Эта лекция сосредоточена на тех частях процесса развития программы, которые не связаны с написанием и отладкой отдельных программных фрагментов. Обсуждение здесь менее точное и детальное, чем во всех остальных частях книги, где рассматриваются конкретные черты языка или определенные приемы программирования. Это неизбежно, поскольку нет готовых рецептов создания хороших программ. Детальные рецепты "как" могут существовать только для определенных, хорошо разработанных областей применения, но не для достаточно широких областей приложения. В программировании не существует заменителей разума, опыта и вкуса. Следовательно, в этой лекции вы найдете только общие рекомендации, альтернативные подходы и осторожные выводы.
Сложность данной тематики связана с абстрактной природой программ и тем фактом, что приемы, применимые для небольших проектов (скажем, программа в 10000 строк, созданная одним или двумя людьми), не распространяются на средние или большие проекты. По этой причине иногда мы приводим примеры из менее абстрактных инженерных дисциплин, а не только из программирования. Не преминем напомнить, что "доказательство по аналогии" является мошенничеством, и аналогии служат здесь только в качестве примера. Понятия проектирования, формулируемые с помощью определенных конструкций С++, и поясняемые примерами, мы будем обсуждать в лекциях 12 и 13. Предложенные в этой лекции рекомендации, отражаются как в самом языке С++, так и в решении конкретных программных задач по всей книге.
Снова напомним, что в силу чрезвычайного разнообразия областей применения, программистов и среды, в которой развивается программная система, нельзя ожидать, что каждый вывод, сделанный здесь, будет прямо применим для вашей задачи. Эти выводы применимы во многих самых разных случаях, но их нельзя считать универсальными законами. Смотрите на них со здоровой долей скептицизма.
Язык С++ можно просто использовать как лучший вариант С. Однако, поступая так, мы не используем наиболее мощные возможности С++ и определенные приемы программирования на нем, так что реализуем лишь малую долю потенциальных достоинств С++. В этой лекции излагается такой подход к проектированию, который позволяет полностью использовать возможности абстрактных данных и средства объектного программирования С++. Такой подход обычно называют объектно-ориентированным проектированием. В лекции 12 обсуждаются основные приемы программирования на С++, там же содержится предостережение от сомнительных идей, что есть только один "правильный" способ использования С++, и что для получения максимального выигрыша следует всякое средство С++ применять в любой программе (§12.1).
Укажем некоторые основные принципы, рассматриваемые в этой лекции:
из всех вопросов, связанных с процессом развития программного обеспечения, самый важный - четко сознавать, что собственно вы пытаетесь создать.Успешный процесс развития программного обеспечения - это длительный процесс.Системы, которые мы создаем, стремятся к пределу сложности по отношению как к самим создателям, так и используемым средствам.Эксперимент является необходимой частью проекта для разработки всех нетривиальных программных систем. Проектирование и программирование - это итеративные процессы.Различные стадии проекта программного обеспечения, такие как: проектирование, программирование и тестирование - невозможно строго разделить.Проектирование и программирование нельзя рассматривать в отрыве от вопросов управления этими видами деятельности.


Недооценить любой из этих принципов очень легко, но обычно накладно. В то же время трудно воплотить эти абстрактные идеи на практике. Здесь необходим определенный опыт. Подобно построению лодки, езде на велосипеде или программированию проектирование - это искусство, которым нельзя овладеть только с помощью теоретических занятий.
Может быть все эти емкие принципы можно сжать в один: проектирование и программирование - виды человеческой деятельности; забудь про это - и все пропало.
Слишком часто мы забываем про это и рассматриваем процесс развития программного обеспечения просто как "последовательность хорошо определенных шагов, на каждом из которых по заданным правилам производятся некоторые действия над входными данными, чтобы получить требуемый результат". Сам стиль предыдущего предложения выдает присутствие человеческой природы!
Эта лекция относится к проектам, которые можно считать честолюбивыми, если учитывать ресурсы и опыт людей, создающих систему. Похоже, это в природе как индивидуума, так и организации - браться за проекты на пределе своих возможностей. Если задача не содержит определенный вызов, нет смысла уделять особое внимание ее проектированию. Такие задачи решаются в рамках уже устоявшейся структуры, которую не следует разрушать. Только если замахиваются на что-то амбициозное, появляется потребность в новых, более мощных средствах и приемах. Кроме того, существует тенденция у тех, кто "знает как делать", перепоручать проект новичкам, которые не имеют таких знаний.
Не существует "единственного правильного способа" для проектирования и создания всей системы. Я бы считал веру в "единственный правильный способ" детской болезнью, если бы этой болезнью слишком часто не заболевали и опытные программисты. Напомним еще раз: только по той причине, что прием успешно использовался в течение года для одного проекта, не следует, что он без всяких изменений окажется столь же полезен для другого человека или другой задачи. Всегда важно не иметь предубеждений.
Убеждение в том, что нет единственно верного решения, пронизывает весь проект языка С++, и, в основном, по этой причине в первом издании книги не было раздела, посвященного проектированию: я не хотел, чтобы его рассматривали как "манифест" моих личных симпатий. По этой же причине здесь, как и в лекциях 12 и 13, нет четко определенного взгляда на процесс развития программного обеспечения, скорее здесь просто дается обсуждение определенного круга, часто возникающих, вопросов и предлагаются некоторые решения, оказавшиеся полезными в определенных условиях.
За этим введением следует краткое обсуждение целей и средств развития программного обеспечения в §11.2, а дальше лекция распадается на две основных части:
§11.3 содержит описание процесса развития программного обеспечения.§11.4 содержит некоторые практические рекомендации по организации этого процесса.


Взаимосвязь между проектированием и языком программирования обсуждается в лекции 12, а лекция 13 посвящена вопросам проектирования библиотек для С++.
Очевидно, большая часть рассуждений относится к программным проектам большого объема. Читатели, которые не участвуют в таких разработках, могут сидеть спокойно и радоваться, что все эти ужасы их миновали, или же они могут выбрать вопросы, касающиеся только их интересов. Нет нижней границы размера программы, начиная с которой имеет смысл заняться проектированием прежде, чем начать писать программу. Однако все-таки есть нижняя граница, начиная с которой можно использовать какие-либо методы проектирования. Вопросы, связанные с размером, обсуждаются в §11.4.2.
Труднее всего в программных проектах бороться с их сложностью. Есть только один общий способ борьбы со сложностью: разделяй и властвуй. Если задачу удалось разделить на две подзадачи, которые можно решать в отдельности, то можно считать ее решенной за счет разделения более, чем наполовину. Этот простой принцип применим для удивительно большого числа ситуаций. В частности, использование модулей или классов при разработке программных систем позволяет разбить программу на две части: часть реализации и часть, открытую пользователю - которые связаны между собой (в идеале) вполне определенным интерфейсом. Это основной, внутренне присущий программированию, принцип борьбы со сложностью.
Подобно этому и процесс проектирования программы можно разбить на отдельные виды деятельности с четко определенным (в идеале) взаимодействием между людьми, участвующими в них. Это основной, внутренне присущий проектированию, принцип борьбы со сложностью и подход к управлению людьми,занятыми в проекте.
В обоих случаях выделение частей и определение интерфейса между частями - это то место, где требуется максимум опыта и чутья. Такое выделение не является чисто механическим процессом, обычно оно требует проницательности, которая может появиться только в результате доско- нального понимания системы на различных уровнях абстракции (см. §11.3.3, §12.2.1 и §13.3). Близорукий взгляд на программу или на процесс разработки программного обеспечения часто приводит к дефектной системе. Отметим, что как программы, так и программистов разделить просто. Труднее достигнуть эффективного взаимодействия между участниками по обе стороны границы, не нарушая ее и не делая взаимодействие слишком жестким.
Здесь предложен определенный подход к проектированию, а не полное формальное описание метода проектирования. Такое описание выходит за предметную область книги. Подход, предложенный здесь, можно применять с различной степенью формализации, и он может служить базой для различных формальных спецификаций. В тоже время нельзя считать эту лекцию рефератом, и здесь не делается попытка рассмотреть каждую тему, относящуюся к процессу разработки программ или изложить каждую точку зрения. Это тоже выходит за предметную область книги. Реферат по этой тематике можно найти в [2]. В этой книге используется достаточно общая и традиционная терминология. Самые "интересные" термины, как: проектирование, прототип, программист - имеют в литературе несколько определений, часто противоречащих друг другу, поэтому предостерегаем вас от того, чтобы, исходя из принятых в вашем окружении определений терминов, вы не вынесли из книги то, на что автор совершенно не рассчитывал.

---

---