Бьерн Страуструп. Язык программирования С++. Специальное издание (2011) (1004033), страница 173
Текст из файла (страница 173)
Цель лроекглированил состоит в построении ясной и относительно простой виутренней структуры программы, иногда называемой арли лек~пурой Другими словами, мы создаем инфраструктурную среду, в которую должны вписываться отдельные части программного кода, и которая сама направляла бы написание отдельных фрагментов. Проект — зто конечный результат проектирования (если, конечно, у итеративного процесса есть конечный результат).
Именно проект организует взаимодействие между проектировщиком и программистом, а также между разными группами программистов. Тут возможны две крайности. Для индивидуального программиста и небольшой задачки, которую нужно решить за пару дней, проект может заключаться в нескольких набросках на обратной стороне почтового конверта. В то же время, для разработок, в которых участвуют сотни проектировщиков и программистов, проект может вылиться во многие тома спецификаций, тщательно выполненных в соответствии с устоявшимися (формальными или полуформальными) стандартами.
Выявление подходящего уровня детализации, точности и формализации проекта — сама по себе непростая техническая и управленческая задача. В данной и двух последующих главах книги я предполагаю, что проект системы заключается в наборе объявлений классов (в типичном случае с опущенными закрытыми секциями объявлений как несущественными подробностями) и указании связей между ними. Это, конечно, упрощение. Для реального проекта имеют значение огромное множество деталей, таких как возможность параллельного исполнения кода, группировка идентификаторов в пространства имен, применение глобальных функций и данных, параметризация классов и функций, реорганизация структуры программы с целью минимизации перекомпиляций, возможность работы в распределенной сетевой среде и т.д.
Тем не менее, наше упрощение оправдано, так как позволяет сосредоточиться на том уровне проектной детализации, для которого ключевое значение имеют классы языка С++. Остальные проектные особенности частично затрагиваются в данной главе, а те из них, что напрямую связаны с особенностями языка С++ — в главах 24 и 25. За более детальными сведениями об объектно-ориентированном проектировании обратитесь к книге (Воос(з, 1994].
Я не сосредотачиваюсь на различиях между анализом и проектированием, поскольку эта тема выходит за рамки настоящей книги, и она, к тому же, очень чувствительна по отношению к разным проектным методикам. Важно так выбрать метод анализа, чтобы он соответствовал методу проектирования, а метод проектирования — чтобы соответствовал стилю программирования и языку программирования. Глава 23. Общий взгляд на разработку программ. Проектирование 818 23.4. Процесс разработки Разработка программного продукта — процесс итеративный.
За время разработки многократно возвращаются к одним и тем же промежуточным стадиям, каждый раз усовершенствуя соответствующие им состояния проекта. Вообще говоря, такой процесс не имеет конца. Начиная работать, вы обычно обращаетесь к некоторой базе ранее выполненных другими людьми проектов, к библиотекам и прикладным средам разработки. Заканчивая проект, вы оставляете его другим для улучшений и расширений, а также для переноса на иные платформы.
Естественно, конкретный проект должен иметь определенные начало и конец, и желательно (хотя это и трудно) четко планировать процесс разработки программного продукта во времени. Думая, что стартуете с чистого листа, вы лишь затрудняете себе работу. Полагая, что все в мире заканчивается с последним выпуском вашей программы, вы ставите преемников в затруднительное положение (и себя самого в этом качестве). Последующие разделы можно читать почти что в произвольном порядке, так как аспекты проектирования и реализации могут произвольно перемежаться в реальных проектах. То есть проект почти всегда переделывается, отталкиваясь от опыта предыдуших проектов и их реализаций.
Кроме того, его ограничивают календарные планы, квалификация персонала, необходимость обеспечить совместимость с предыдущими версиями или иными программами и т.д. Очень важно для проектировщиков, менеджеров и программистов внести, тем не менее, в процесс разработки определенный порядок, не удушающий творчество и не разрушающий обратные связи между людьми, способствующие конечному успеху дела.
Процесс разработки можно разделить на три этапа: ° анализ: выявление границ решаемой задачи (проблемы); ° проектировапце: создание обшей внутренней структуры системы; ° реализация: написание кода и тестирование программы. Пожалуйста, не забывайте об итеративной природе процесса — важно, что перечисленные этапы не пронумерованы. Также стоит отметить, что некоторые аспекты разработки программ не подпадают под разбиение на этапы: ° Экспериментирование ° Тестирование ° Анализ проекта и реализации ° Документирование ° Управление проектом (менеджмент) Поддержка и сопровождение программы сводятся к дополнительным проходам по всему циклу разработки (523.4.6).
Очень валено, чтобы анализ, проектирование и реализация не слишком отдалялись друг от друга, и чтобы люди, ответственные за разные виды деятельности, могли при этом взаимодействовать и обмениваться мыслями и опытом. Слишком часто в больших проектах это отсутствует. В идеале, в процессе выполнения проекта люди должны изменять свое амплуа и переходить от одного этапа к другому — только так можно осуществить перенос важной и тонкой информации, хранящейся в голове человека. К сожалению, многие организации выставляют барьеры на пути 23.4. Процесс разработки 819 таких человеческих переходов, предоставляя, например, проектировщикам более высокий статус и/или зарплату, чем «простым программистам». Если уж среди сотрудников не практикуются переходы туда-сюда с целью учить и учиться, то желательно поощрять их беседовать с участниками «других» этапов разработки.
Для небольших и средних проектов часто не делается различия между анализом и проектированием; эти две фазы сливаются в одну. А для маленьких проектов не делается различия и между проектированием и реализацией. При этом, конечно, автоматически решаются «проблемы общения». Любому проекту важно придать подходящий уровень формализации и поддерживать соответствующую степень разделения этапов (з23.5.2). Тут не существует единственно верного решения. Описанная здесь модель разработки программных продуктов радикально отличается от традиционной «модели водопада». В последней процесс разработки разворачивается в линейную последовательность шагов от анализа до тестирования.
«Модель водопада» имеет серьезный изъян, заключающийся в том, что информация в рамках этой модели «течет» лишь в одном направлении. Когда проблемы обнаруживаются «внизу по течению», возникает сильное методологическое и организационное давление с тем, чтобы решать их на месте выявления, не затрагивая предыдущие этапы процесса. Такое намеренное игнорирование обратных связей обедняет проектное решение, а исправления «по месту возникновения» часто порождают ущербные программы.
В случаях, когда информация с неизбежностью вытекает назад, приходится изменять проект, что замедляет разработку и вызывает нескладный волнообразный эффект в системе, предполагающей отсутствие таких изменений, а потому сопротивляющейся и медленно реагирующей на изменения. В качестве довода в пользу отсутствия изменений и решения проблем на месте приводят суждение о том, что одно подразделение не должно ради своего удобства перекладывать работу на плечи другого подразделения. Наконец, когда выявляется проблема, исключительно плохо преодолеваемая на месте, оказывается, что к этому моменту выполнена грандиозная бумажная работа по документированию, переделать которую столь сложно и накладно, что лучше уж любой ценой и как-нибудь все исправить по-прежнему «на месте».
Таким образом, бумажная работа оказывается важнейшим фактором в разработке программного продукта. Разумеется, при любой организации работ такие проблемы могут и наверняка возникают в рамках больших программных проектов. Ясно, что какие-то бумаги действительно необходимы. Однако применение для разработки линейной модели (модели «водопада») увеличивает вероятность того, что бумажные проблемы могут выйти из под контроля. Недостаток модели «водопада» заключается в недостаточности обратной связи и неспособности реагировать на изменения. Опасность же описанного ранее итеративного подхода заключается в возможной попытке подменить необходимость думать серией плохо сходящихся изменений.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
