Новая семантика

Создавая с помощью UML новые модели, вы используете принятые в этом языке правила. Это естественно, поскольку при соблюдении данного условия

ваши модели будут однозначно восприняты каждым, кто знаком с этим языком. Но иногда требуется выразить новую семантику, которая отсутствует в UML, или изменить существующую. В таком случае вам помогут ограничения. Моделирование новой семантики производится следующим образом:

1. Убедитесь, что с помощью базовых средств UML невозможно реализовать ваш замысел. Если вам предстоит решить типичную задачу моделирования. то, надо полагать, уже существует стандартное ограничение, которое подой­дет для этой цели.

2. Если вы уверены, что никакого другого способа выразить нужную семантику не существует, оформите новую семантику в виде текста в ограничении и рас положите рядом с элементом, к которому она относится. Более явно описать ограничение можно, связав его с элементами отношениями зависимости.

3. Если вы хотите описать новую семантику более четко и формально, восполь­зуйтесь языком OCL.

В качестве примера на рис. 6.11 представлена модель небольшого фрагмента корпоративной системы управления человеческими ресурсами.

Н а этой диаграмме показано, что каждый Человек может быть сотрудником любого числа Отделов (включая ноль), а в каждом Отделе должен быть хотя бы один сотрудник. При этом в роли начальника Отдела может выступать только один Человек; в то же время любой Человек может быть начальником любого числа Отделов (включая ноль). Эта семантика выражается с помощью базовых правил UML. Однако то обстоятельство, что начальник должен быть также и сотрудником

отдела, подразумевает несколько ассоциаций и не может быть выражено с помощью базового UML. Для формулирования такого инварианта необходи­мо написать ограничение, которое показывает, что начальник «принадлежит» (subset на диаграмме) множеству сотрудников отдела, и соединить две ас­социации с этим ограничением зависимостью, на­правленной от подмножества к надмножеству.

Советы

Включая в модель примечания в виде дополнений:

• используйте примечания для описания только тех требований, наблюдений, обзоров и пояснений, которые нельзя выразить с помощью стандартных средств UML;

• используйте примечания в качестве электронной памятки, отслеживая с их помощью ход работы.

Изображая примечания, не перегружайте модель большими объемными ком­ментариями. Если длинный комментарий действительно необходим, помещайте в примечания ссылку на документ, содержащий полный текст.

Расширяя модель за счет новых стереотипов, помеченных значений и ограни­чений, руководствуйтесь следующими принципами:

• определите небольшое число этих механизмов в качестве стандартных для проекта и не позволяйте разработчикам создавать ничего лишнего;

• выбирайте короткие осмысленные названия для стереотипов и помеченных значений;

• если точность описания не слишком важна, определяйте ограничения в свободной форме; в противном случае используйте язык OCL.

Изображая стереотипы, помеченные значения и ограничения, действуйте согласно следующим правилам:

• прибегайте к графическим стереотипам только в случае острой необходимости. С помощью стереотипов можно полностью изменить базовую нотацию : UML, но тогда уже никто, кроме вас, не поймет модель;

• подумайте, не стоит ли раскрасить или оттенить графические стереотипы и более сложные пиктограммы. Как правило, чем проще нотация, тем она лучше, и даже самых простых визуальных образов бывает вполне достаточно для передачи смысла.