2. Язык UML. Руководство пользователя. Буч_ Рамбо_ Якобсон (2-е издание) (2006) (1185732), страница 20
Текст из файла (страница 20)
6.9. Моделирование комментариевМоделирование новых сойствБазовые свойства строительных блоков UML – атрибуты и операции для классов, содержимое пакетов и др. – носят достаточноуниверсальный характер для выражения большинства моделируемых сущностей. Однако если вы хотите расширить свойства этихбазовых строительных блоков, вам придется определять стереотипы и помеченные значения.Чтобы смоделировать новые свойства, необходимо: Убедиться в том, что не существует способа решить поставленную вами задачу средствами стандартного UML. Определить стереотип и добавить к нему новые свойства.Здесь применимы правила обобщения: помеченные значения, определенные для некоторого вида стереотипов, применимы также к его потомкам.Предположим, что вы хотите привязать созданные вами моделиПодсистемыобсуждают- к системе управления конфигурацией вашего проекта.
Помимо всегося в главе 32. прочего, это означает необходимость отслеживать номера версий, текущий статус «check in/check out»3 и, может быть, даже дату и времясоздания/модификации каждой из подсистем. Поскольку все это специфичная для процесса информация, она не является базовой частьюUML (хотя вы можете добавить ее в виде помеченных значений).3Имеется в виду состояние рабочей копии на машине разработчика по отношениюк репозиторию проекта.
– Прим. перев.Общие механизмы102Более того, эта информация не выражается атрибутами классов. Номер версии подсистемы – часть метаданных, а не часть модели.Рис. 6.10 демонстрирует три подсистемы, каждая из которых расширена стереотипом «versioned» для указания номера версии и статуса.«versioned»«versioned»«versioned»«versioned»version = 2,5status = openСоветы и подсказки103 Убедитесь в том, что не существует способа решить поставленную вами задачу средствами стандартного UML.
Опишите новую семантику в ограничении, помещенном рядом с элементом, к которому она относится. Вы можете явнопродемонстрировать эту связь, установив зависимость между ограничением и элементом. Если вам нужно более точно и формально специфицировать семантику, опишите ее на языке OCL.В качестве примера на рис. 6.11 представлена модель небольшой части корпоративной системы управления человеческими ресурсами.«versioned»version = 3,2status = checkedln«versioned»version = 7,5status = lockedРис. 6.10. Моделирование новых свойствНа заметку. Значения тегов, такие как version (версия) илиstatus (состояние), могут быть установлены в ваших моделяхинструментальными средствами. Вместо того, чтобы устанавливать эти величины вручную, вы можете использоватьсреды разработки, интегрированные с инструментами управления конфигурацией и инструментами моделирования.Моделирование новой семантикиСоздавая модель с помощью UML, вы работаете по определенным правилам данного языка.
И не напрасно: благодаря этому выможете четко передать свои намерения любому, кто умеет читатьUMLFмодели. Но если вам требуется выразить новую семантику,о которой UML умалчивает или же модифицировать правила UML,придется писать ограничение.Чтобы смоделировать новую семантику, воспользуйтесь следующими рекомендациями:Captain must bemember of teamfor at least 1 yearРис. 6.11.
Моделирование новой семантикиДиаграмма показывает, что каждый человек (Person) можетбыть членом одной или нескольких команд (Team) либо не входитьни в одну из них; в каждой команде должен быть как минимум одинруководитель; каждый человек может быть руководителем однойили нескольких команд либо не руководить ни одной. Вся эта семантика может быть выражена простыми средствами UML. Однакотот факт, что руководитель должен быть членом команды, которуюон возглавляет, касается нескольких ассоциаций и не может бытьвыражен с использованием стандартного UML.
Чтобы задать этотинвариант, вы должны описать ограничение, которое показывает,что руководитель относится к числу членов команды, и связать обеассоциации ограничением. Еще одно ограничение указывает, чторуководитель должен быть членом команды не меньше года.Советы и подсказкиСнабжая модель примечаниями, пользуйтесь следующими правилами: добавляйте только те требования, оценки и пояснения, которые вы не можете выразить просто и четко другими средствами UML; используйте примечания как своеобразные электронные памятки для отслеживания хода работы;104Общие механизмы не перегружайте модель большими блоками комментариев.Если вам нужны обстоятельные комментарии, используйтепримечания, которые указывают на документы, содержащиеполный текст пояснений.При расширении модели стереотипами, помеченными значениями или ограничениями: стандартизируйте небольшой набор стереотипов, помеченных значений и ограничений, предназначенных для использования в вашем проекте, и не позволяйте отдельным разработчикам создавать новые расширения; задавайте короткие информативные имена стереотипов и помеченных значений; если требования точности не слишком строги, используйтедля спецификации ограничения текст произвольного формата.
В противном случае применяйте OCL для описанияограничений.При изображении стереотипа, помеченного значения или ограничения: используйте графические стереотипы умеренно. Вы можетеполностью переопределить базовую нотацию UML посредством стереотипов, но тем самым вы затрудните пониманиемоделей посторонними пользователями; помните о возможности цветового выделения графическихстереотипов и сложных пиктограмм. Как правило, простаянотация всегда лучше – решение модели в цвете может облегчить ее понимание.Глава 7.
ДиаграммыВ этой главе:Общиепринципымоделирования обсуждаютсяв главе 1.Диаграммы, представления и моделиМоделирование различных представлений системыМоделирование разных уровней абстракцииМоделирование сложных представленийОрганизация диаграмм и прочих артефактовЗанимаясь моделированием, вы допускаете некоторое упрощениереальности с тем, чтобы лучше описать разрабатываемую систему.С помощью UML вы строите модели из базовых блоков: классов,интерфейсов, коопераций, компонентов, узлов, зависимостей, обобщений и ассоциаций.
Диаграммы изображают эти строительныеблоки, помогая вам наглядно представить модель.Диаграмма – это графическое представление набора элементов,чаще всего отображаемых как связный граф вершин (сущностей)и дуг (связей). Диаграммы используются для визуализации системы с разных точек зрения. Поскольку ни одна сложная система неможет быть понята при одностороннем рассмотрении, UML определяет множество диаграмм, с тем чтобы вы могли сфокусироватьвнимание на различных аспектах системы, рассматриваемых обособленно.Хорошие диаграммы облегчают понимание разрабатываемойсистемы. Выбор правильного множества диаграмм для моделирования вашей системы заставляет вас задавать правильные вопросыо системе и помогает высветить последствия принятых решений.Диаграммы106ВведениеРаботая с архитектором над дизайном дома, который вы собрались построить, вы для начала совершаете три действия: составляете список пожеланий (например, «В доме должно быть три ванныхкомнаты», «Я хочу уложиться в такуюFто сумму» и т.д.), делаете рядпростых набросков, представляющих ключевые характеристикидома (допустим, набросок входа с винтовой лестницей и т.д.), а также некоторые общие идеи, касающиеся стиля (скажем, ««французский сельский домик»).
Работа архитектора состоит в том, чтобы всеэти отрывочные, изменчивые и возможно, противоречивые пожелания воплотить в дизайне.Вероятно, начнет он с плана первого этажа. Этот артефакт ляжет в основу общего представления о доме, после чего уже можно будет уточнить детали и документировать принятые решения.При каждом просмотре вы захотите внести некоторые изменения –перепроектировать комнаты, поFдругому разместив стены, дверии окна.
На начальной стадии чертежи меняются часто, но по мерепроработки дизайна он все больше соответствует вашим требованиям к форме и функциям тех или иных объектов, рабочему времени и затратам; наконец, чертежи стабилизируются настолько, чтоможно утвердить их и начать строительство. Но даже после этогоне исключено, что вы измените ряд диаграмм и создадите какиеFтоновые.Разумеется, помимо плана первого этажа вам понадобятсядругие представления дома. Например, вы захотите увидеть егос разных сторон. Кроме того, архитектору понадобится составитьпланы электропроводки, системы отопления и вентиляции, а также водопровода и канализации. Если дизайн предполагает нестандартные решения (скажем, использование арочных пролетов илиразмещение домашнего кинотеатра в непосредственной близостиот камина), придется делать дополнительные наброски.Практика создания диаграмм для представления систем с разных точек зрения широко распространена: без нее не обойтись в любой инженерной дисциплине, имеющей дело со сложными системами, – от строительства жилых домов до авиаF и судостроения,а также разработки программного обеспечения.Пять предКак уже говорилось выше, существуют пять взаимодополняющихставленийпредставлений, которые особенно важны для визуализации, специархитекту- фицирования, конструирования и документирования программнойры обсужда- архитектуры: представление вариантов использования, представлеютсяние дизайна, представление взаимодействия, представление реализав главе 2.ции и представление развертывания.