Б. Страуструп - Язык программирования С++ (1119446), страница 77

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 77)

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

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

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

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

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

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

Именно,"проект" почти всегда подвергается перепроектированию на основе предыдущего проекта,определенного опыта реализации, ограничений, накладываемых сроками, мастерством работников,вопросами совместимости и т.п. Здесь основная трудность для менеджера или разработчика илипрограммиста в том, чтобы создать такой порядок в этом процессе, который не препятствуетусовершенствованиям и не запрещает повторные проходы, необходимые для успешного развития.У процесса развития три стадии:287Бьерн Страуструп.Язык программирования С++-Анализ: определение области задачи.-Проектирование: создание общей структуры системы.-Реализация: программирование и тестирование.Не забудьте об итеративной природе этих процессов (неспроста стадии не были пронумерованы), изаметьте, что никакие важные аспекты процесса развития программы не выделяются в отдельныестадии, поскольку они должны допускать:-Экспериментирование.-Тестирование.-Анализ проектирования и реализации.-Документирование.-Сопровождение.Сопровождение программного обеспечения рассматривается просто как еще несколько проходов постадиям процесса развития (см.

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

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

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

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

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

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

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

Основной цикл сводится к повторяемым вследующей последовательности шагам:[1]Создать общее описание проекта.[2]Выделить стандартные компоненты.[a] Подогнать компоненты под данный проект.[3]Создать новые стандартные компоненты.[a] Подогнать компоненты под данный проект.[4]Составить уточненное описание проекта.В качестве примера рассмотрим автомобильный завод.

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

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

Характеристики

Список файлов книги