Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 53
Текст из файла (страница 53)
Следует ожидать, что команда отработает весьманеэффективно, а, может быть, и вообще не создаст ничего пригодного для передачизаказчику. Это - пример проекта в свободном падении.17 Во втором случае мыимеем диктатуру, в которой инициативы наказуемы, экспериментирование, котороемогло бы привнести больше элегантности в архитектуру, не поощряется, идействительные требования заказчика никогда корректно не доходят доразработчиков нижнего уровня, скрытых за настоящей бумажной стеной,воздвигнутой бюрократией.•Встречавшиеся нам удачные объектно-ориентированные проекты не следовали нианархическому, ни драконовскому жизненному циклу. Зато мы заметили, чтоудачная объектно-ориентированная архитектура создается в итеративноразвивающемся процессе. Проектирование является итеративным,повторяющимся, в том смысле, что уже созданная архитектура вновь и вновьподвергается анализу и проектированию. При этом в каждом цикле анализпроектирование-эволюция стратегические и тактические решения развиваются,приближаясь к требованиям конечного пользователя (часто даже не высказанным),оставаясь при этом простыми, надежными и открытыми для дальнейшегоизменения.•Итеративно развивающийся процесс является антитезой традиционного "водопада" ине сводится к одностороннему движению сверху-вниз или снизу-вверх.Обнадеживающие прецеденты этого стиля есть в опыте создания как аппаратуры,так и программ [3, 4].
Например, пусть надо сформировать штат фирмы,занимающейся проектированием и изготовлением сложной уникальной аппаратуры.Можно использовать горизонтальный подход, когда проект катится водопадом, так,что архитекторы передают его конструкторам, а те электронщикам.
Это - примерпроектирования сверху-вниз, когда мы приглашаем узких (хотя и глубоких)специалистов в своей области [5]. Можно пойти по другому пути, наняв мастеров навсе руки, каждому из которых можно поручить вертикальный сегмент проекта отначала до конца. Это уже гораздо больше похоже на итеративно развивающийсяпроцесс.17Есть шанс, что проект в свободном падении приземлится благополучно, но вам ненужно ставить в связи с этим на кон будущее своей компании.•По нашему мнению, процесс объектно-ориентированного проектирования не сводитсяк одностороннему движению сверху-вниз или снизу-вверх. Друк считает, чтохорошо структурированные сложные системы можно создать методом "возвратногопроектирования" (round-trip gestalt design).
В этом методе основное вниманиеуделяется процессу поступательного итеративного развития путемсовершенствования различных, но, тем не менее, совместимых между собойлогических и физических моделей системы. Мы считаем, что возвратноепроектирование составляет необходимую основу процесса объектноориентированного проектирования.•В отдельных случаях решаемая задача может быть уже хорошо изучена и много раззапрограммирована. Процесс разработки можно привести в идеальный порядок:проектировщики новой системы уже понимают, какие абстракции являютсяглавными; они уже знают, какие механизмы нужно использовать и каким, в общихчертах, будет поведение системы.
Творчество все еще важно в таком процессе, ноздесь проблема достаточно сужена и большинство стратегических решенийпредопределены. Тогда, поскольку риск исключен, можно достичь очень высокихпоказателей производительности [б]. Чем больше мы знаем о задаче, тем легче еерешить.•Большинство промышленных задач не таковы: они связаны с балансированиемуникальных требований к функциональности и эффективности и требуют полнойтворческой отдачи всего коллектива разработчиков. Более того, любая человеческаядеятельность, которая требует творчества и инноваций, идет путем проб и ошибок,итеративно развивающегося процесса, который опирается на опыт, компетентностьи талант каждого члена коллектива.18 Так что нет и не будет стандартных рецептовдля проектирования программных систем.•Рациональный процесс проектирования•Однако мы не можем обойтись без рецептов, описывая обещанную выше зрелую,воспроизводимую в любой организации технологию разработки.
Поэтому мы ихарактеризовали ее, как управляемый итеративно развивающийся процесс управляемый в том смысле, что он поддается проверке и измерению, но оставляетдостаточную свободу для творчества.•Упорядоченный процесс проектирования чрезвычайно важен для организаций,разрабатывающих программное обеспечение. Хэмфри перечисляет следующие пятьуровней зрелости таких процессов [7]:••• НачальныйПользователь извне системы управляет переключением процессов.• РучноеПереключением процессов управляет некоторый алгоритм.• АлгоритмическоеПроцессам по очереди выделяется равное количество процессорного времени, обычноназываемое квантом времени, по истечении которого управление передается другому процессу.Процесс может получать время в квантах и подквантах.• Циклическое18Эксперименты Кертиса и его коллег подкрепляют эти наблюдения.
Они изучалиработу профессиональных разработчиков программного обеспечения, записываявидеокамерой их действия и затем анализируя их содержание (анализ,проектирование, реализация и т. п.) и время на выполнение. В результатеисследований был сделан вывод, что "создание программ представляется наборомитеративных, плохо упорядоченных и взаимно перекрывающихся процессов подприспосабливающимся управлением... Развитие по сбалансированной схеме сверхувниз проявляется как особый случай, когда схема проектирования оказалась вполнеподходящей или задача мала по размеру... Хорошие проектировщики работаютодновременно на нескольких уровнях абстракции и детализации" [8].Текущий процесс продолжает выполняться на процессоре до тех пор, пока сам неуступит контроль над ним.• ВытесняющееПроцесс с более высоким приоритетом, может отнимать процессор у исполняемого процесса с болеенизким приоритетом; обычно процессы с одинаковым приоритетом получают равные промежуткивремени для выполнения, так что вычислительные ресурсы распределены справедливо.• Невытесняющее• ВоспроизводимыйОрганизация в разумной степениуправляет своими планами иобязательствами.• ОпределенныйПроцесс разработки в разумнойстепени определен, понятен иприменяется на практике; онпозволяет выбирать команду ипредсказывать ход разработки.Следующая цель - оформитьвыработанную практику разработкикак инструментальную среду.• УправляемыйОрганизация выработалаколичественные показателипроцесса.
Цель состоит в снижениизатрат на сбор данных иналаживание механизмов обратнойсвязи, позволяющих данным влиятьна процесс.• ОптимальныйОрганизация имеет отлаженныйпроцесс, устойчиво выдающийрезультаты высокого качества,своевременно, предсказуемо иэффективно.К сожалению, как отмечают Парнас и Клеменс: "Мы никогда неотыщем процесс, который дал бы нам возможность проектировать программыстрого рациональным образом", поскольку дело это творческое и новаторскоепо определению. Однако, продолжают они, "хорошей новостью является, то,что мы можем его имитировать... (Поскольку) разработчики нуждаются вруководстве, мы приблизимся к рациональной разработке, если будемследовать процессу, а не действовать, как попало. Когда организация занятамногими программными продуктами, есть смысл иметь стандартнуюпроцедуру... Если мы держим в голове идеальный процесс, становится легчеизмерять успехи проекта" [9].С приобретением опыта у организации встает вопрос: "Как примиритьтворчество и новации с возрастающей управляемостью?".
Ответ состоит вразграничении макро- и микроэлементов процесса проектирования.Микропроцесс родственен спиральной модели развития, предложеннойБоемом, и служит каркасом для итеративного подхода к развитию [10].Макропроцесс близок к традиционному "водопаду" и задает направляющиерамки для микропроцесса. Примиряя эти два в корне различных процесса, мыимитируем полностью рациональный процесс разработки и обретаем основудля определенного уровня зрелости в деле создания программногообеспечения.Мы должны подчеркнуть, что каждый проект уникален, и,следовательно, разработчик сам должен поддерживать баланс междунеформальностью микропроцесса и формальностью макропроцесса. Дляисследовательских приложений, разрабатываемых тесно сплоченнойкомандой высококвалифицированных разработчиков, чрезмернаяформальность негативно отразится на новациях; для очень сложных проектов,разрабатываемых большим коллективом разработчиков, отделенных друг отдруга пространством и временем, недостаток формальности приводит к хаосу.Оставшаяся часть этой главы дает обзор и детальное описание целей,результатов, видов деятельности и измеримых характеристик, составляющихмикро- и макропроцессы разработки.
В следующей главе мы рассмотримпрактические проявления этих процессов, в первую очередь с точки зренияменеджеров, которые должны надзирать за ходом объектно-ориентированногопроекта.6.2. Микропроцесс проектированияОбзорМикропроцесс объектно-ориентированной разработки приводится вдвижение потоком сценариев и архитектурных продуктов, которыепорождаются и последовательно уточняются в макропроцессе. Микропроцесс,по большей части, - повседневный труд отдельного разработчика илинебольшого коллектива разработчиков.Микропроцесс относится в равной степени к программисту иархитектору программной системы.
С точки зрения программиста,микропроцесс предлагает руководство в принятии бесчисленного числаежедневных тактических решений, которые являются частью процессасоздания и подгонки архитектуры системы. С точки зрения архитектора,микропроцесс является основой для развития архитектуры и опробованияальтернатив.В микропроцессе традиционные фазы анализа и проектированияумышленно перемешаны, а управление осуществляется "по возможности".Как отмечает Стра-уструп, "не существует рецептов, которые могли бызаменить ум, опыт и хороший вкус в проектировании и программировании...Различные фазы программного проекта, такие, как проектирование,программирование и тестирование, неотделимы друг от друга" [II].Как показано на рис.
6-1, микропроцесс обычно состоит из следующихвидов деятельности:•выявление классов и объектов на данном уровне абстракции•выяснение семантики этих классов и объектов•выявление связей между этими классами и объектами•спецификация интерфейса и реализация этих классов и объектов.Теперь рассмотрим каждый из этих видов деятельности подробно.Выявление классов и объектовЦель. Цель выявления классов и объектов состоит в том, чтобы найтиграницы предметной области. Кроме того, эта деятельность является первымшагом в продумывании объектно-ориентированной декомпозицииразрабатываемой системы.Мы применяем этот шаг в анализе, когда обнаруживаем абстракции,составляющие словарь предметной области и ограничиваем нашу задачу,решая, что важно, а что - нет.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
