Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 57
Текст из файла (страница 57)
Длядостижения эффективности может потребоваться незначительнаяреорганизация обязанностей и/или протокола абстракции нижнегоуровня.•Если семантика абстракции не может быть выражена черезнаследование, инстанцирование или делегирование, рассмотретьподходящее представление из примитивов языка. Выбрать топредставление, которое оптимизирует стереотипы использования,учитывая важность операций с точки зрения объектов-клиентовабстракции.
Однако помните, что невозможно оптимизироватькаждый случай использования. Получив эмпирическуюинформацию из последовательных версий-прототипов, мы можемвыделить абстракции, которые неэффективно используют времяили память и улучшить их реализацию, не опасаясь нарушитьпредположения клиентов относительно нашей абстракции.•Выбрать подходящий алгоритм для каждой операции. Ввестивспомогательные операции для расчленения сложных алгоритмовна более простые или более пригодные для повторногоиспользования части. Рассмотреть возможные компромиссы, вчастности, сделать выбор между хранением и вычислениемотдельных членов-данных.Путевые вехи и характеристики. На стадии анализа мы считаем, чтоблагополучно завершили фазу реализации, когда идентифицировали всеважные абстракции из тех, что необходимы для выполнения обязанностейабстракций, выявленных на этом цикле микропроцесса.
На стадиипроектирования реализация считается благополучно завершенной, когда мыполучили исполнимую или почти исполнимую программную модель нашихабстракций.Главным показателем благополучия на этой фазе является простота.Сложные, неуклюжие или неэффективные реализации свидетельствуют онедостатках самой абстракции или о плохом ее представлении.6.3. Макропроцесс проектированияОбзорМакропроцесс является контролирующим по отношению кмикропроцессу.
Макропроцесс предписывает ряд измеримых результатов идействий, которые позволяют команде разработчиков оценить риск, внестизаблаговременные изменения в микропроцесс и сосредоточиться наколлективном анализе и проектировании. Макропроцесс - это деятельностьвсего коллектива в масштабе от недель до месяцев.Многие элементы макропроцесса относятся к самой практикеменеджмента программных проектов и поэтому выполняются одинаково, какдля объектно-ориентированных, так и для других систем. Среди них управление конфигурацией, гарантии качества, разбор программы исоставление документации. В следующей главе мы рассмотрим этипрактические вопросы в контексте объектно-ориентированногопроектирования.
Данная глава сосредоточена на описании спецификиобъектно-ориентированного подхода или (по определению Парнаса) на том,как мы уродуем рациональный процесс проектирования чтобы получитьобъектно-ориентированную систему.Макропроцесс заботит в первую очередь технического руководителякоманды разработчиков, цели которого несколько отличаются от задачотдельного разработчика. Они оба заинтересованы в качестве конечногопрограммного продукта, удовлетворяющем требованиям заказчика.23 Однако,конечного пользователя мало волнует, правильно ли использованы в проектепараметризованные классы или полиморфизм; заказчик гораздо болееобеспокоен сроками, качеством, полнотой и правильностью работыпрограммы.
Поэтому макропроцесс сконцентрирован на управлении риском ивыявлении общей архитектуры - двух управляемых компонентах, имеющихрешающее значение для сроков, полноты и качества проекта.В макропроцессе в большой степени сохранены традиционные фазыанализа и проектирования и процесс в меру упорядочен. Как показано на рис.6-2, макропроцесс обычно включает следующие действия:•Выявление сущности требований к программному продукту(концептуализация).•Разработка модели требуемого поведения системы (анализ).•Создание архитектуры для реализации (проектирование).•Итеративное выполнение реализации (эволюция).•Управление эволюцией продукта в ходе эксплуатации(сопровождение).•Рис. 6-2. МакропроцессУ всех нетривиальных программных разработок макропроцесспродолжается и после создания и внедрения системы.
Это особенно видно напримере организаций, специализирующихся на создании семейств программ,на которые часто выделяются значительные капиталовложения.Основная философия макропроцесса состоит в постепенном развитии.Как его определяет Вонк, "при разработке методом последовательногоразвития, система выстраивается шаг за шагом, причем каждая новая версиясодержит функциональность предыдущей, плюс новые функции" [14]. Этотподход чрезвычайно хорошо сочетается с объектно-ориентированнойпарадигмой и дает много возможностей для управления риском. Какутверждает Гилб: "Постепенная передача программ заказчику изобретена длятого, чтобы заранее предупредить нас о надвигающихся неприятностях" [15].Теперь детально рассмотрим каждое действие в макропроцессе.Естественно, одним из показателей зрелости организации, ведущейразработку, является знание случаев, когда надо обойти эти правила, что мыбудем отдельно отмечать в нашем обзоре.23Ну, конечно, не все, а большинство.
К сожалению, некоторые менеджеры большезаинтересованы в развитии своей империи, чем в развитии программного продукта.Прибавьте к этому предыдущее примечание относительно аналитиков ипроектировщиков. Я думаю, Данте мог бы найти для них подходящее место.КонцептуализацияЦель. Концептуализация должна установить основные требования ксистеме. Для каждой принципиально новой части программы или даже длянового применения существующей системы найдется такой момент, когда вголову разработчика, архитектора, аналитика или конечного пользователязападет идея о новом приложении.Это может быть новое деловое предприятие, дополнительное изделиена поточной линии или, например, новая функция в существующейпрограммной системе. Цель концептуализации не в том, чтобы полностьюопределить идею, а в том, чтобы выработать взгляд на нее и мысленнопроверить ее.Результаты.
Первичными продуктами концептуализации являютсяпрототипы системы. Определенно, каждой существенно новой программнойсистеме необходим некоторый черновой прототип, пусть и выполненный "наскорую руку". Такие прототипы не полны по самой своей природе иразработаны лишь схематически. Однако, нужно сохранять интересные(пусть, возможно, и отвергнутые) прототипы, так как этим организацияподдерживает корпоративную память о первоначальном замысле и сохраняетсвязь с исходными предположениями. При проектировании этот архив даетнезаменимый материал для экспериментирования, к которому аналитики иархитекторы могут возвращаться, когда хотят опробовать новые идеи.Очевидно, для грандиозных приложений (национального илимеждународного значения), само построение прототипов может оказатьсябольшим свершением.
Ведь гораздо лучше столкнуться с трудностями приреализации, обнаружив, что неверны какие-то предположения офункциональности, эффективности, размере или сложности системы, чемпренебречь прогрессивным решением. Такое пренебрежение может грозитьфинансовой или социальной катастрофой.Подчеркнем: прототипы хороши, но их следует выбросить. Нельзяпозволять им непосредственно эволюционировать в готовую систему, если кэтому не имеется достаточно серьезных оснований. Сжатые сроки не являютсяуважительной причиной: оптимизация краткосрочной разработки,игнорирующая последующие затраты владельца программного продукта, типичный пример ложной экономии.Виды деятельности. Концептуализация по самой своей природе творческая деятельность, и, следовательно, она не должна быть скованажесткими правилами разработки. Возможно, самое важнее для организации создать структуру, которая обеспечивала бы достаточные ресурсы длявозникновения и исследования новых идей.24 Новые идеи могут исходить изсамых различных источников: конечных пользователей, групп пользователей,разработчиков, аналитиков, проектировщиков, распространителей и т.
д. Дляруководства важно вести регистрацию этих идей, располагая их поприоритетам и распределяя ограниченные ресурсы так, чтобы исследоватьсамые многообещающие из них. Когда для исследования выбрано конкретноенаправление, типичен следующий порядок дальнейших действий:•Решить, какие цели преследуются при опробовании концепции икаковы критерии того, что считать благополучным исходом.•Собрать подходящую команду для разработки прототипа.
Часто онасостоит из единственного члена (который и есть тот самый24Если организация не сделает этого сама, то отдельные разработчики все равносделают это, не спрашиваясь у компании, в которой они работают. Так и возникаютновые программистские фирмы.
Их появление хорошо для индустрии в целом, но недля самой осиротевшей компании.мечтатель). Самое лучшее, что организатор может сделать, чтобыоблегчить усилия команды - не стоять на ее пути.•Оценить готовый прототип и принять ясное решение опроектировании конечного продукта или о дальнейшемисследовании.
Решение приступить к разработке конечногопродукта нужно принимать с разумным учетом потенциальногориска, выявленного при опробовании концепции.Концептуализация не содержит ничего специфически объектноориентированного. Каждая программная парадигма должна предусматриватьопробование концепций. Однако, как часто бывает, разработка прототиповобычно происходит быстрее в тех случаях, когда на лицо зрелая объектноориентированная среда.Довольно часто концепции опробуются на одном языке (например, наSmalltalk), а разработка конечного продукта ведется на другом (скажем, C++).Путевые вехи и характеристики.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
