Гради Буч - Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (1158635), страница 41
Текст из файла (страница 41)
5-1. Объектные моделидеталей отделки. Глупо было бы заранее указывать на чертеже трехмерныекоординаты этого выключателя (конечно, если это не является функциональноважной деталью для заказчика: может быть, все члены его семьи имеют ростнамного выше или ниже среднего). Если разработчики большой программнойсистемы - высококвалифицированные специалисты и уже сработались друг сдругом, им будет достаточно и грубых набросков, хотя и в этом случае онидолжны оставить свое творческое наследие эксплуатационщикам вудобоваримом виде. Если же разработчики неопытны, отделены друг от другаво времени или пространстве или если так установлено контрактом, то напротяжении всего процесса проектирования необходимы более детальныеэскизы проекта.
Система обозначений, которую мы представляем в этой главе,учитывает эти ситуации.Различные языки программирования описывают одни и те же понятияразлично. Наша система обозначений не зависит от конкретного языка.Конечно, некоторые ее элементы могут не иметь аналогов в языке, на которомбудет написана проектируемая система. В этом случае просто не надо имипользоваться. Например, в Smalltalk не бывает свободных подпрограмм,следовательно, в проект нет смысла закладывать утилиты классов.Аналогично, C++ не поддерживает метаклассы, следовательно, этот элементдолжен быть исключен.
Но нет ничего предосудительного в подгонкеобозначений под конструкции выбранного языка. Например, в CLOS операцииможно снабдить специальными пометками, чтобы определить методы:before, :after и :around. Подобным же образом, в системеавтоматического проектирования для C++ вместо спецификаций класса можнопользоваться прямо заголовочными файлами.Цель этой главы - определить синтаксис и семантику нашихобозначений для объектно-ориентированного анализа и проектирования. Вкачестве примера мы будем использовать гидропонную теплицу, котораярассматривалась в главе 2. В настоящей главе не обсуждается, как,собственно, были получены представленные в примерах решения: это задачаглавы 6.
В главе 7 обсуждаются практические аспекты этого процесса, а вглавах 8-12 система обозначений демонстрируется в деле на серии примеровразработки приложений.Модели и ракурсыВ главе 3 мы объяснили, что такое классы и объекты, а также каковасвязь между ними.
Как показано на рис. 5-1, при принятии решений в анализеи проектировании полезно рассмотреть взаимодействие классов и объектов вдвух измерениях: логическом/физическом и статическом/динамическом. Обаэтих аспекта необходимы для определения структуры и поведения объектнойсистемы.В каждом из двух измерений мы строим несколько диаграмм, которыедают нам вид моделей системы в различных ракурсах. Таким образом, моделисистемы содержат всю информацию о ее классах, связях и других сущностях,а каждая диаграмма представляет одну из проекций модели.
Вустановившемся состоянии проекта, все такие диаграммы должны бытьсогласованы с моделью, а, следовательно, и друг с другом.Рассмотрим для примера систему, включающую в себя несколькосотен классов; эти классы образуют часть модели. Невозможно, а на самомделе и не нужно представлять все классы и их связи на единственнойдиаграмме. Вместо этого мы можем описать модель в нескольких диаграммахклассов, каждая из которых представляет только один ее ракурс.
Однадиаграмма может показывать структуру наследования некоторых ключевыхклассов; другая - транзитивное замыкание множества всех классов,используемых конкретным классом. Когда модель "устоится" (придет вустойчивое состояние), все такие диаграммы становятся семантическисогласованными друг с другом и с моделью. Например, если по данномусценарию (который мы описываем на диаграмме объектов), объект A посылаетсообщение M объекту B, то M должно быть прямо или косвенно определено вклассе B.
В соответствующей диаграмме классов должна быть надлежащаясвязь между классами A и B, так, чтобы экземпляры класса A действительномогли посылать сообщение M.Для простоты на диаграммах все сущности с одинаковыми именами водной области видимости рассматриваются как ссылки на одинаковыеперсонажи системы. Исключением из этого правила могут быть толькооперации, имена которых могут быть перегружены.Чтобы различать диаграммы, мы должны дать им имена, которыеотражали бы их предмет и назначение.
Можно снабдить диаграммы и другимикомментариями или метками, которые мы вскоре опишем; эти комментарии,как правило, не имеют дополнительной семантики.Логическая и физическая моделиЛогическое представление описывает перечень и смысл ключевыхабстракций и механизмов, которые формируют предметную область илиопределяют архитектуру системы. Физическая модель определяет конкретнуюпрограммно-аппаратную платформу, на которой реализована система.При анализе мы должны задать следующие вопросы:•Каково требуемое поведение системы?•Каковы роли и обязанности объектов по поддержанию этогоповедения?Как было отмечено в предыдущей главе, чтобы выразить наширешения о поведении системы мы пользуемся сценариями. В логическоймодели важнейшим средством для описания сценариев служат диаграммыобъектов.
При анализе могут быть полезны диаграммы классов, позволяющиеувидеть общие роли и обязанности объектов.При проектировании мы должны задать следующие вопросыотносительно архитектуры системы:•Какие существуют классы и какие есть между ними связи?•Какие механизмы регулируют взаимодействие классов?•Где должен быть объявлен каждый класс?•Как распределить процессы по процессорам и как организоватьработу каждого процессора, если требуется обработка несколькихпроцессов?Чтобы ответить на эти вопросы, мы используем следующиедиаграммы:•диаграммы классов•диаграммы объектов•диаграммы модулей•диаграммы процессов.Статическая и динамическая моделиЧетыре введенные нами типа диаграмм являются по большей частистатическими.
Но практически во всех системах происходят события: объектырождаются и уничтожаются, посылают друг другу сообщения, причем вопределенном порядке, внешние события вызывают операции объектов. Неудивительно, что описание динамических событий на статическом носителе,например, на листе бумаги, будет трудной задачей, но эта же трудностьвстречается фактически во всех областях науки. В объектно-ориентированномпроектировании мы отражаем динамическую семантику двумядополнительными диаграммами:диаграммами переходов из одного состояния в другоедиаграммами взаимодействия.Каждый класс может иметь собственную диаграмму переходов,которая показывает, как объект класса переходит из состояния в состояниепод воздействием событий. По диаграмме объектов, имея сценарий, можнопостроить диаграмму взаимодействий, чтобы показать порядок передачисообщений.Инструменты проектированияПлохой разработчик, имея систему автоматического проектирования,сможет создать своего программного монстра за более короткий срок чемраньше.
Великие проекты создаются великими проектировщиками, а неинструментами. Инструменты проектирования дают возможность проявитьсяиндивидуальности, освобождают ее, чтобы она могла сосредоточитьсяисключительно на творческих задачах проектирования и анализа. Существуютвещи, которые автоматизированные системы проектирования могут делатьхорошо, и есть вещи, которые они вообще не умеют. Например, если мыиспользуем диаграмму объектов, чтобы показать сценарий с сообщением,посылаемым от одного объекта другому, автоматизированная системапроектирования может гарантировать, что посылаемое сообщение будет впротоколе объекта; это пример проверки совместимости.
Если мы введеминвариант, например, такой: "существует не более трех экземпляров данногокласса", то мы ожидаем, что наш инструмент проследит за соблюдениемданного требования; это пример проверки ограничения. Кроме того, системаможет оповестить вас, если какие-либо объявленные классы или методы неиспользуются в проекте (проверка на полноту). Наконец, более сложнаяавтоматическая система проектирования может определить длительностьконкретной операции или достижимость состояния на диаграмме состояний;это пример автоматического анализа.
Но, с другой стороны, никакаяавтоматическая система не сможет выявить новый класс, чтобы упроститьвашу систему классов. Мы, конечно, можем попытаться создать такойинструмент, используя экспертные системы, но для этого понадобятся, вопервых, эксперты как в области объектно-ориентированногопрограммирования, так и в предметной области, а во-вторых, четкосформулированные правила классификации и много здравого смысла. Мы неожидаем появления таких средств в ближайшем будущем. В то же время, унас есть вполне реальные проекты, которыми стоит заняться.5.2. Диаграммы классовСущественное: классы и отношения между нимиДиаграмма классов показывает классы и их отношения, тем самымпредставляя логический аспект проекта.
Отдельная диаграмма классовпредставляет определенный ракурс структуры классов. На стадии анализа мыиспользуем диаграммы классов, чтобы выделить общие роли и обязанностисущностей, обеспечивающих требуемое поведение системы. На стадиипроектирования мы пользуемся диаграммой классов, чтобы передатьструктуру классов, формирующих архитектуру системы.Два главных элемента диаграммы классов - это классы и их основныеотношения.Классы. На рис. 5-2 показано обозначение для представления классана диаграмме. Класс обычно представляют аморфным объектом, вродеоблака..11Выбор графических обозначении - это трудная задача.
Требуется осторожнобалансировать между выразительностью и простотой, так что проектирование значков- это в большой степени искусство, а не наука. Мы взяли облачко из материаловкорпорации Intel, документировавшей свою оригинальную объектноориентированную архитектуру iAPX432 [б]. Форма этого образа намекает нарасплывчатость границ абстракции, от которых не ожидается гладкости и простоты.Пунктирный контур символизирует то, что клиенты оперируют обычно сэкземплярами этого класса, а не с самим классом. Можно заменить эту формупрямоугольником, как сделал Румбах [7]:Однако, хотя прямоугольник проще рисовать, этот символ слишком частоиспользуется в разных ситуациях и, следовательно, не вызывает ассоциаций.
Крометого, принятое Румбахом обозначение классов обычными прямоугольниками, аобъектов - прямоугольниками с закругленными углами конфликтует с другимиэлементами его нотации (прямоугольники для актеров в диаграммах потоков данных изакругленные прямоугольники для состояний в диаграммах переходов). Облачкоболее удобно и для расположения пометок, которые, как мы увидим дальше,потребуются для абстрактных и параметризованных классов, и поэтому онопредпочтительнее в диаграммах классов и объектов. Аргумент простоты рисованияпрямоугольников спорен при использовании автоматизированной поддержки системыобозначений. Но чтобы сохранить возможность простого рисования и подчеркнутьКаждый класс должен иметь имя; если имя слишком длинно, егоможно сократить или увеличить сам значок на диаграмме.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
