Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 52
Текст из файла (страница 52)
Использование автоматизированныхинструментов позволяет освободить разработчика от бремени согласования деталей, позволяяему сосредоточиться на творческих аспектах процесса проектирования.Увеличение и уменьшение масштабаМы считаем, что описанная здесь система обозначений годится как для маленькихсистем, содержащих несколько классов, так и для больших проектов с несколькими тысячамиклассов.
Как мы покажем в следующих двух главах, эта система обозначений особенно удобнадля организации итерационного процесса разработки. К диаграммам не следует относиться какк застывшему догмату, а скорее наоборот, нужно постоянно отражать на них все новыерешения, принятые в процессе проектирования.Мы также считаем, что эта система обозначений годится для реализации на разныхязыках объектно-ориентированного программирования.В этой главе были описаны основные результаты процесса объектно-ориентированногопроектирования, включая синтаксис и семантику.
В двух последующих главах процессразработки будет рассмотрен подробнее. Оставшиеся пять глав повествуют о примененииметода на практике.ВыводыПроектирование - это не рисование диаграмм; диаграммы просто отражают результатыпроектирования.При проектировании сложной системы важно рассмотреть ее в различных ракурсах как с точки зрения логической/физической структуры, так и статической/динамическойсемантики.Система обозначений объектно-ориентированного проектирования включает четыреосновных диаграммы (классов, объектов, модулей, процессов) и две дополнительные(состояний и переходов, взаимодействий).Диаграмма классов показывает, какие существуют классы и связи между ними влогической структуре системы. Конкретная диаграмма классов - один из ракурсов полнойструктуры классов системы.Диаграмма объектов показывает, какие существуют объекты и связи между ними влогической структуре системы. Диаграмма объектов используется для представления сценария.Диаграмма модулей показывает распределение классов и объектов по модулям вфизической структуре системы.
Диаграмма модулей - один из ракурсов модульнойархитектуры системы.Диаграмма процессов показывает распределение процессов по процессорам вфизической структуре системы. Каждая диаграмма процессов - один из ракурсов архитектурыпроцессов системы.Диаграмма состояний и переходов показывает: (1) пространство состояний экземпляровданного класса; (2) события, которые влекут переход из одного состояния в другое; (3)действия, которые происходят при изменении состояния.Диаграмма взаимодействий позволяет следить за выполнением сценария в контекстедиаграммы объектов.Дополнительная литератураСо времени выхода первого издания этой книги я без устали старался ввести в методБуча лучшие элементы обозначении, принадлежащие другим методологам, особенно Румбаху(Rumbaugh) и Джекобсону (Jacobson), удалял и упрощал элементы, неудачные или имеющиесомнительную пользу.
В то же время, концептуальное единство системы обозначенийбереглось как зеница ока. Данная глава - кульминация этих усилий.Об обозначениях в разработке программного обеспечения написано чрезвычайномного; книга Мартина и МакКлюра (Martin and McClure) [H 1988] служит хорошим общимсправочником по многим традиционным подходам. Грэхам (Graham) [F 1991] дал обзор ряданотаций, специфичных для объектно-ориентированных методов.Ранняя форма описанной в этой главе системы обозначений была впервыедокументирована в работе Буча (Booch) [F 1981].
Эта система в дальнейшем развилась ивключила выразительные средства: семантических сетей (Стилингс и др. (Stillings et al.) [A1987] и Барри Фейгенбаум (Barrand Feigenbaum) [J 1981]),диаграммы "сущность-отношение"(Чэн (Chen) [Е 1976]), модели сущности (Росс (Ross) [F 1987]), сети Петри (Petri) (Пе-терсон(Peterson) [J 1977], Сахару (Sahraoui) [F 1987] и Бруон и Балзамо (Bruon and Balsamo) [F 1986]),ассоциации (Румбах (Rumbaugh) [F 1991]) и карты состояний (Харел (Harel) [F 1987]).Особенно интересна работа Румбаха, поскольку, как он заметил, в наших подходах большесходства, чем различий.Значки для объектов и классов были инспирированы iAPX 432 [D 1981].
За основуизображения для объектных диаграмм были взяты обозначения Сейдвица (Seidewitz) [F 1985].Для семантики параллельности были приспособлены обозначения Бура (Buhr) [F1988,1989].Чэн (Chang) [G 1990] дал хороший обзор более общих аспектов визуальных языков.Глава 6ПроцессПрограммисты-любители все время ищут какой-то волшебный инструмент, который мог бы сделатьпроцесс разработки программ тривиальным.
Признак профессионализма - понимание того, что такойпанацеи не существует. Любители стремятся действовать по "поваренной книге"; профессионалы жезнают, что безупречно грамотный подход ведет к нелепым проектным решениям. За словом "системапроектирования" разработчики пытаются спрятаться от ответственности за ошибки в проектных решениях.Любители либо игнорируют документацию вообще, либо выстраивают весь проект вокруг нее, заботясьбольше о том, как продукт выглядит на бумаге, чем о его сути. Профессионал признает, что бездокументации не обойтись, но никогда не поступится ради нее полезными архитектурными новациями.Процесс объектно-ориентированного анализа и проектирования не сводится к сумме рецептов, однако онопределен достаточно хорошо, чтобы быть предсказуемым и воспроизводимым в умелых руках.
В этойглаве мы подробно рассмотрим его как итеративно развивающийся процесс, описав цели, видыдеятельности, результаты и меры прогресса, характерные для его различных фаз.6.1. Основные принципыХарактерные черты удачных проектовУдачным проектом мы назовем тот, который удовлетворил (по возможности,превзошел) ожидания заказчика, уложился во временные и финансовые рамки, легко поддаетсяизменению и адаптации. Пользуясь этим критерием, рассмотрим следующие две черты,которые оказались общими для всех встречавшихся нам удачных проектов, и, чтозамечательно, отсутствовали у тех, которые кажутся нам неудачными:•Ясное представление об архитектуре создаваемой системы;•Хорошо организованный итеративно развивающийся процесс работы над проектом.••Архитектура.
Признак добротности архитектуры - ее концептуальное единство ицелостность. По утверждению Брукса, "концептуальная целостность впроектировании важнее всего" [1]. Как показано в главах 1 и 5, архитектураобъектно-ориентированной программной системы содержит структуры классов иобъектов, имеющие горизонтальное и вертикальное слоение. Обычно конечномупользователю нет дела до архитектуры системы.
Однако, как указывает Страуструп,"ясная внутренняя структура" играет важную роль в построении системы, котораябудет понятна, тестируема, устойчива и сможет развиваться и перестраиваться [2].Более того, именно ясность архитектуры дает возможность выявить общиеабстракции и механизмы, которые можно свести воедино, тем самым делая системупроще, меньше и надежнее.•Не существует единственно верного способа классифицировать абстракции иразрабатывать архитектуру. В любой предметной области всегда достаточноглупейших путей проектирования, но, если поискать, можно найти и весьмаэлегантные.
Как же отличить хорошую архитектуру от плохой?•Как правило, хорошая архитектура тяготеет к объектной ориентированности. Это неозначает, что любая объектно-ориентированная архитектура оказывается хорошей,или что хороша только объектно-ориентированная архитектура. Однако, как былопоказано в главах 1 и 2, применение принципов объектно-ориентированнойдекомпозиции приводит к архитектуре, обладающей требуемыми свойствамиорганизованной сложности.•Хорошей архитектуре присущи следующие свойства:•Она представляет собой многоуровневую систему абстракций. На каждом уровнеабстракции сотрудничают друг с другом, имеют четкий интерфейс с внешниммиром и основываются на столь же хорошо продуманных средствах нижнегоуровня.•На каждом уровне интерфейс абстракции строго отграничен от реализации.Реализацию можно изменять, не затрагивая при этом интерфейс.
Изменяясьвнутренне, абстракции продолжают соответствовать ожиданиям внешних клиентов.•Архитектура проста, то есть не содержит ничего лишнего: общее поведениедостигается общими абстракциями и механизмами.•Мы различаем стратегические и тактические решения. Стратегическое решение имеетважное архитектурное значение и связано с высоким уровнем системы. Механизмыобнаружения и обработки ошибок, парадигмы интерфейса пользователя, политикауправления памятью, устойчивость объектов, синхронизация процессов,работающих в реальном масштабе времени, - все это стратегические архитектурныерешения.
В противоположность этому, тактическое решение имеет тольколокальное архитектурное значение и поэтому обычно связано с деталямиинтерфейса и реализации абстракций. Протокол класса, сигнатура метода, выборалгоритма - все это тактические архитектурные решения.•Хорошая архитектура всегда демонстрирует баланс между стратегическими итактическими решениями. При слабой стратегии даже очень изящно задуманныйкласс не сможет вполне соответствовать своей роли. Самые прозорливыестратегические решения будут разрушены, если не уделить должного вниманияразработке отдельных классов. В обоих случаях пренебрежение архитектуройрождает программные эквиваленты анархии и неразберихи.••Цикл итеративного развития. Рассмотрим две крайности - полное отсутствиеформализованного жизненного цикла разработки и очень жесткие, строгособлюдаемые правила разработки. В первом случае мы имеем анархию; тяжкимтрудом (преимущественно нескольких своих членов) команда разработчиков вконце концов может родить что-то стоящее, но состояние проекта всегда будетнеизмеримо и непредсказуемо.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
