Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 54
Текст из файла (страница 54)
Такие действия необходимы припроектировании, когда мы изобретаем новые абстракции, которые являютсясоставными частями решения. Переходя к программной реализации, мыприменяем процедуру выявления, чтобы изобрести простые абстракции, изкоторых строятся более сложные, и обнаружить общие черты существующихабстракций, дабы упростить архитектуру системы.Результаты. Главным результатом этого шага являетсяобновляющийся по мере развития проекта словарь данных. Вначаледостаточно составить список действующих лиц, состоящий из всех заметныхклассов и объектов, названых именами, отражающими их смысл [12].
Когдасловарь разрастется, можно сделать простейшую базу данных, или болееспециальный инструмент проектирования, непосред-Рис. 6-1. Микропроцессственно поддерживающий выбранный метод разработки.19 В своих болееформальных разновидностях словарь данных служит предметным указателемдля всех остальных компонентов проекта, включая диаграммы испецификации обозначений объектно-ориентированного проектирования.Таким образом, словарь данных - центральное хранилищеотносящихся к системе абстракций.
Вначале допустимо держать словарьданных открытым для изменений: некоторые персонажи могут оказатьсяклассами, некоторые - объектами, другие - атрибутами, а иные - простосинонимами других абстракций. Постепенно содержимое словаря уточняетсяпутем введения новых, исключения лишних и объединения схожихабстракций.Создание словаря данных на этом шаге дает три существенныхвыигрыша.
Во-первых, сама работа с ним помогает выработать общепринятуюи исчерпывающую терминологию, которой можно пользоваться напротяжении всего проекта. Во-вторых, словарь - естественное оглавление ковсем материалам проекта и система точек входа для доступа к проекту впроизвольном порядке. Это особенно полезно, когда в команду принимаетсяновый разработчик, который должен быстро войти в курс дел. В-третьих,словарь данных позволяет архитектору окинуть весь проект единым взглядом,что может привести к открытию новых общностей, которые иначе могли быбыть упущены.Виды деятельности. Как мы описывали в главе 4, выявление классови объектов связано с двумя видами творческих актов: открытием иизобретением.19Формально, словарь данных объектно-ориентированной разработки долженсодержать спецификации каждого элемента архитектуры.Не каждый член команды должен быть равно искусен во всем.Аналитики, особенно работающие с экспертами в предметной области,должны уметь хорошо обнаруживать абстракции, то есть находитьосмысленные классы и объекты в предметной области.
Тем временемархитекторы и старшие разработчики придумывают классы и объекты,решающие чисто программистские проблемы. Мы обсудим природу этихтворческих актов в следующей главе.В любом случае основой для выявления классов и объектов служатметоды классификации, описанные в главе 4. Обычный порядок действийтаков:•Применить классический подход к классификации (см. раздел 4.2,"Объектно-ориентированный анализ"), чтобы получить множествокандидатов в классы и объекты. В начале жизненного циклахорошими стартовыми точками являются материальные элементыи их роли.
Затем исследовать последовательности событий, чтодаст другие абстракции первого и второго порядка: в концеконцов, для каждого события мы должны иметь объект, которыйотвечает за его обнаружение и/или обработку.•Применить технику анализа поведения (см. там же) и выявитьабстракции, которые непосредственно связаны сфункциональными точками системы. Функциональные точкисистемы, как будет сказано подробнее в этой главе, берутся измакропроцесса и представляют отдельные проверяемые и внешненаблюдаемые поведения системы.
Как и в случае событий, длякаждого поведения можно найти классы и объекты, которыеинициируют его и участвуют в нем.•Для соответствующих сценариев, созданных в макропроцессе,применить технику анализа вариантов (см. там же). В началежизненного цикла мы исследуем самые общие сценарии поведениясистемы. В процессе разработки мы постепенно переходим ко всеболее детализированным сценариям, добираясь до самых темныхуголков поведения системы.В каждом из этих подходов CRC-карточки являются эффективнымкатализатором "мозгового штурма" и помогают теснее сплотить коллектив,подталкивая его членов к общению.20Некоторые классы и объекты будут определены в начале жизненногоцикла проекта неправильно, но это не всегда плохо. Многие осязаемые вещи ироли, которые мы перечислим в жизненном цикле, пройдут через весь путьвплоть до реализации - настолько они фундаментальны для нашейконцептуальной модели.
Разбираясь в задаче, мы, вероятно, будем изменятьграницы некоторых абстракций, перераспределяя ответственности, объединяяподобные или (чаще всего), разбивая большие абстракции на группывзаимодействующих, формируя таким образом некоторые механизмырешения.Путевые вехи и характеристики. Мы благополучно завершим этуфазу, когда будем иметь достаточно стабильный словарь данных. Посколькумикропроцесс развивается итеративно, следует ожидать, что словарь будетзакончен и закрыт лишь на очень поздней стадии проекта. Пока насудовлетворяет обильный, даже избыточный набор абстракций ссодержательными именами и разумным распределением обязанностей.Признаком качества, следовательно, будет то, что словарь неподвергается серьезным изменениям каждый раз, когда мы проходим новуюитерацию микропроцесса. Неустойчивость словаря показывает, что20Это ужасно банально, но некоторые проектировщики программ и в самом деле неочень общительны.разработчики еще не достигли желаемого, или в архитектуре что-то не так.
Походу разработки мы можем контролировать устойчивость нижних уровнейархитектуры, отслеживая результаты локальных измененийвзаимодействующих абстракций.Выяснение семантики классов и объектовЦель. Цель выяснения семантики классов и объектов - определитьповедение и атрибуты каждой абстракции, выявленной на предыдущем шаге.При этом мы уточняем намеченные абстракции, продуманно и измеримораспределяя между ними обязанности.На стадии анализа мы применяем этот шаг, чтобы распределитьобязанности между различными видами поведения системы. На стадиипроектирования мы применяем процедуру выяснения семантики, чтобы четкораспределить обязанности между частями реализации.
При реализации мыпродвигаемся от описаний ролей и обязанностей в свободной форме кспецификациям конкретных протоколов для каждой абстракции и, в конечномсчете, - к точным сигнатурам каждой операции.Результаты. На этом шаге получаются несколько результатов.Первым является уточнение словаря данных, с помощью которого мыизначально присвоили обязанности абстракциям. В ходе проектирования мыможем выработать спецификации к каждой абстракции (как описано в главе5), перечисляя имена операций в протоколе каждого класса. Затем, как можноскорее, мы выразим интерфейсы этих классов на языке реализации.
Для C++это означает создание .h-файлов, в Ada - спецификаций пакетов, в CLOS обобщенных функций для каждого класса, в Smalltalk - это объявление, но нереализация методов каждого класса. Если проект связан с базой данных,особенно с объектно-ориентированной, на этом шаге мы получаем общийкаркас нашей схемы данных.В добавление к этим, по сути тактическим решениям, мы составляемдиаграммы объектов и диаграммы взаимодействий, передающие семантикусценариев, создаваемых в ходе макропроцесса. Эти диаграммы формальноотражают рас-кадровку каждого сценария и, таким образом, описывают явноераспределение обязанностей среди взаимодействующих объектов. На этомшаге впервые появляются конечные автоматы для представления некоторыхабстракций.Чтобы команда разработчиков могла развивать согласованный языкобозначений и для учета обязанностей каждой абстракции, мы можем, как ина предыдущем шаге, использовать специализированную базу данных илидругие, более специфические инструменты проектирования.
Когда мынапишем на выбранном языке формальные интерфейсы классов, мы можемиспользовать наши инструменты проектирования для проверки и гарантиивыполнения принятых решений.Главная выгода большей формальности результатов на этом шагесостоит в том, что она помогает разработчику увидеть назначение всехпротоколов абстракции. Невозможность четко определить смысл - признакзыбкости самих абстракций.Виды деятельности. С этим шагом связано три вида деятельности:раскадровка, проектирование изолированных классов и поиск шаблонов.Главными объектами раскадровки являются основные ивторостепенные сценарии, полученные в макропроцессе. В ходе этойдеятельности происходит нисходящее выяснение семантики.
Там, где этокасается функциональных точек системы, принимаются стратегическиерешения. Типичный ход выполнения действий может быть таким:•Выбрать сценарий (или группу сценариев), связанный с отдельнойфункциональной точкой; на основании результатов предыдущегошага определить относящиеся к этому сценарию абстракции.•Проследить действия в этом сценарии, наделяя каждую абстракциюобязанностями, достаточными, чтобы получить требуемое общееповедение. Если необходимо - выбрать атрибуты, которые будутпредставлять структурные элементы, требуемые для выполненияотдельных обязанностей.•По ходу раскадровки перераспределить обязанности так, чтобысбалансировать поведение.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
