2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 78
Текст из файла (страница 78)
29.4 показано использование образцапроектирования Command (см. Gamma et. al. Design Patterns. – Reading,Massachusetts: AddisonFWesley, 1995)1. Как установлено в описанииданного образца, он «инкапсулирует запрос в виде объекта, позволяя тем самым параметризовать клиентов, выдающих разные запросы, ставить запросы в очередь и протоколировать их, а также поддерживать операции, допускающие отмену». Как видно из модели,этот образец проектирования имеет три параметра, которые, будучиприменены к нему, должны быть связаны с элементами в данномконтексте.
Модель демонстрирует два соединения, в которых классы PasteCommand (Команда Вставки) и OpenCommand (Команда Открытия)привязываются к параметрам образца.Здесь параметрами являются AbstractCommand (АбстрактнаяКоманда), которая должна быть связана с таким же абстрактным суперклассом в каждом случае, ConcreteCommand (КонкретнаяКоманда),которая связывается с различными конкретными классами в разныхслучаях связывания, и Receiver (Приемник), связываемый с классом,над которым команда осуществляет действие.
Класс Command (Команда) может быть создан образцом, но оформление его в виде параметра позволяет создавать множество иерархий команд.Заметьте, что PasteCommand и OpenCommand являются подклассамиCommand. Весьма вероятно, что ваша система будет использовать этотобразец много раз с разнообразными связываниями. Возможностьтакого повторного использования образца проектирования делаетпроцесс разработки на основе образцов весьма эффективным.Типичные приемы моделирования409параметрсвязыванияКомандаexecute()АбстрактнаяКомандаАбстрактнаяКомандаиспользованиеобразцаКонкретнаяКомандаКонкретнаяКомандаКомандаВставкиКомандаОткрытияexecute()Приемникexecute()askUser()DocumentПриемникApplicationopen()close()paste()document.paste()add(Document)name=askUser();doc=new Document();receiver.addDocument();doc.open()Рис.
29.4. Моделирование образца проектированияЧтобы завершить модель образца проектирования, вы должныспецифицировать его структурную и поведенческую составляющие, которые представляют собой внутренности кооперации.КооперацииРассмотрим рис. 29.5, где показана диаграмма классов, предобсуждают- ставляющая структуру этого образца. Обратите внимание на то, какся в главе 28,диаграммыклассов –в главе 8, диаграммывзаимодействия –в главе 19.АбстрактнаяКомандаexecute()КонкретнаяКомандаexecute()1Приемникприемник1Русскоязычное издание книги: Гамма Э., Хелм Р., Джонсон Р., Влиссидес Дж. Приемы объектно-ориентированного проектирования. Паттерны проектирования.
–СПб: Питер, 2001.Рис. 29.5. Моделирование структурного аспектаобразца проектирования410Образцы и каркасына этой диаграмме используются классы, которые названы параметрами образца. Рис. 29.6 показывает диаграмму последовательности,демонстрирующую поведение того же образца. Отметим, что онаносит характер предположения: образец проектирования не является жесткой конструкцией.Рис. 29.6. Моделирование поведенческого аспектаобразца проектированияМоделирование архитектурных образцовПакетыобсуждаютсяв главе 12.Образцы также подходят для моделирования типичных архитектурных решений.
При моделировании каркаса вы, собственно, разрабатываете инфраструктуру всей архитектуры, которую затем планируете повторно использовать и адаптировать к некоему контексту.Каркас изображается в виде пакета со стереотипом. Являясь пакетом, каркас представляет ряд элементов, включая классы, интерфейсы, варианты использования, компоненты, узлы, кооперациии даже другие каркасы (но не ограничиваясь ими). Фактически выпомещаете в каркас все абстракции, которые, работая совместно,формируют расширяемый шаблон для приложений в определеннойобласти.
Некоторые из этих элементов будут открыты и станут ресурсами, доступными для использования клиентами. Это те частикаркаса, которые вы можете подключать к абстракциям своего контекста. Некоторые из таких открытых элементов станут образцамипроектирования и будут представлять собой ресурсы, с которымисвязываются клиенты. Именно эти части каркаса вы наполняете, связывая с образцом проектирования. И наконец, некоторыеТипичные приемы моделирования411элементы будут закрытыми или защищенными; они соответствуютинкапсулированным элементам каркаса, не видимым снаружи.ПрограмПри моделировании архитектурного образца следует помнитьмнаяо том, что образец, по сути, является описанием архитектуры, хотяархитеки неполным, и, возможно, параметризованным.
Следовательно, все,тура обсуж- что вы знаете о моделировании хорошо структурированной архидаетсятектуры, в полной мере применимо и к хорошо структурированнымв главе 2.каркасам. Они не проектируются в отрыве от остальной системы, –такая попытка обречена на неудачу. В основе каркасов лежат ужесуществующие архитектуры, доказавшие свою работоспособность.Затем каркасы развиваются, чтобы найти те элементы управленияи стыковки, которые необходимы и достаточны для того, чтобыобеспечить возможность их адаптации к новым областям.Чтобы смоделировать архитектурный образец, необходимо: Заложить в основу каркаса проверенную существующую архитектуру. Смоделировать каркас как пакет со стереотипом, содержащий все элементы (и особенно образцы проектирования),которые необходимы и достаточны для описания разныхпредставлений каркаса.
Раскрыть включаемые элементы, интерфейсы и параметры,необходимые для адаптации каркаса, в форме образцов проектирования и коопераций. Это делается с той целью, чтобыпользователь образца понимал, какие классы должны бытьрасширены, какие операции реализованы и какие сигналыобработаны.На рис. 29.7 показана спецификация архитектурного образца Blackboard (Классная Доска), который позаимствован из книги Buschmann et al. PatternFOriented Software Architecture. – NewYork, NY: Wiley, 1996. Как говорится в его описании, этот образец«применим к задачам преобразования данных в высокоуровневыеструктуры, которые не имеют простого детерминированного решения».
В основе архитектуры лежит образец Blackboard, определяющий порядок совместной работы классов KnowledgeSource (ИсточникЗнаний), Blackboard и Controller (Контроллер). Этот каркас включаеттакже образец проектирования Reasoning engine (Процессор логического ввода), который определяет общий механизм работы классаKnowledgeSource. И наконец, как видно из рисунка, каркас раскрываетодин вариант использования – Apply new knowledge sources (Применитьновые источники знаний), поясняющий клиенту, как можно этоткаркас адаптировать.Образцы и каркасы412«»Глава 30. Диаграммы артефактовВ этой главе:Рис. 29.7. Моделирование архитектурного образцаНа заметку.
На практике полное моделирование каркаса –задача, по своей сложности сопоставимая с моделированием архитектуры всей системы. В некоторых отношенияхона даже сложнее, поскольку для того, чтобы с каркасомможно было работать, вы должны раскрыть все его элементыуправления и стыковки и, возможно, представить метаварианты использования (типа Apply new knowledge sources), которые показывают, как настраивается каркас, а также простыеварианты использования, поясняющие его поведение.Советы и подсказкиПри моделировании образцов в UML следует помнить, что ониработают на многих уровнях абстракции, начиная от отдельныхклассов и заканчивая системой в целом. Самые интересные видыобразцов – это механизмы и каркасы. Хорошо структурированныйобразец обладает следующими свойствами: решает типичную проблему типичным образом; включает структурную и поведенческую составляющие; раскрывает элементы управления и стыковки, с помощьюкоторых его можно настроить на разные контексты; охватывает различные индивидуальные абстракции в системе.Изображая образец в UML, необходимо: раскрывать те его элементы, которые следует адаптироватьдля применения в конкретном контексте; приводить варианты использования образца, а также способыего адаптации.Диаграммыразмещения – второйвиддиаграмм,используемых для моделированияфизическихаспектовобъектноNориентированныхсистем, –обсуждаются в главе 31.Моделирование исходного кодаМоделирование исполняемых версийМоделирование физических баз данныхМоделирование адаптируемых системПрямое и обратное проектированиеДиаграммы артефактов – это один из двух видов диаграмм, предназначенных для моделирования физических аспектов объектноFориентированных систем.
Диаграмма артефактов показывает организацию и зависимости между наборами артефактов.Такие диаграммы используются для моделирования статического представления реализации системы, включая моделированиефизических сущностей, размещаемых на узлах (например, исполнимых программ, библиотек, таблиц, файлов, документов разногорода). Диаграммы артефактов – это, по сути, диаграммы классов,которые сосредоточены на артефактах системы.Диаграммы артефактов важны не только для визуализации,специфицирования и документирования систем, основанных на артефактах, но также для конструирования исполняемых систем посредством прямого и обратного проектирования.ВведениеСтроительство дома не ограничивается созданием комплектачертежей.
Они, конечно, очень важны, так как помогают визуализировать, специфицировать и документировать, какой именно домвы собираетесь построить, и обеспечить выполнение замысла с соблюдением сроков и сметы. Но рано или поздно поэтажные планы и разрезы придется воплощать в реальном каркасе из реальныхматериалов – дерева, камня, металла. При этом вы, скорее всего,будете использовать и уже готовые артефакты, например встроенные шкафы, окна, двери и вентиляционные решетки. А если выДиаграммы артефактов414переоборудуете здание, то число готовых артефактов возрастет, –это будут целые комнаты и инженерные конструкции.То же самое касается программного обеспечения.
Для того чтобы можно было рассуждать о желаемом поведении системы, создаются диаграммы вариантов использования. Словарь предметнойобласти описывается диаграммами классов. Чтобы стало ясно, каксущности из этого словаря совместно работают для обеспечениянужного поведения, применяются диаграммы последовательности,коммуникации, состояний и деятельности.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
