Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 59

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

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

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

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

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

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

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

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

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

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

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

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

Производство - управляемый методичный процессподъема качества изделия к надлежащему уровню" [24].Пейдж-Джонс называет ряд преимуществ такой поступательнойразработки:•"Обеспечивается обратная связь с пользователями, когда это большевсего необходимо, полезно и значимо.•Пользователи получают несколько черновых версий системы длясглаживания перехода от старой системы к новой.•Менее вероятно, что проект будет снят с финансирования, если онвдруг выбился из графика.•Главные интерфейсы системы тестируются в первую очередь инаиболее часто.•Более равномерно распределяются ресурсы на тестирование.•Реализаторы могут быстрее увидеть первые результаты работысистемы, что их морально поддерживает.•Если сроки исполнения сжатые, то можно приступить к написанию иотладке программ до завершения проектирования".Результаты.

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

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

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

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

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

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