Главная » UML » Отличия версий языка UML 1.2 (и 1.1) и 1.3 (и 1.5)

0

 

Прецеденты

 

В прецедентах появились новые отношения. В UML 1.1 имелись только два типа отношений между прецедентами: «uses» (использует) и «extends» (расширяет), каждое их которых является стереотипом обобщения. UML 1.3 предлагает три типа отношений:

•       Конструкция «includes» (включает) является стереотипом зависимости. Она означает, что выполнение одного прецедента включает в себя другой прецедент. Обычно это отношение встречается в ситуации, когда несколько прецедентов имеют общие этапы или части. Включаемый прецедент может предоставлять другим некоторое общее поведение. В качестве примера можно рассмотреть банкомат (ATM), в контексте которого оба прецедента Withdraw Money (Получить деньги) и Make Transfer (Сделать перевод) используют прецедент Validate Customer (Проверить подлинность клиента). Это отношение в общем случае заменяет применение стереотипа «uses».

•       Обобщение (generalization) прецедента означает, что один прецедент представляет собой вариацию другого. Таким образом, можно иметь один прецедент для сценария «Получить деньги» (базовый вариант использования) и другой прецедент для ситуации, когда выдача денег невозможна по причине отсутствия средств на счету
клиента. Отказ от выплаты денег можно представить в виде отдель ного прецедента, который уточняет базовый прецедент. (Кроме того, можно определить еще и дополнительный сценарий для прецедента «Получить деньги».) В этом случае специальный прецедент, подобно рассмотренному выше, может изменить какой-либо аспект базового прецедента.

•       Конструкция «extends» (расширяет) является стереотипом зависи
мости. Она обеспечивает более управляемую форму расширения по

 

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

Существует некоторая путаница насчет старой и новой интерпретаций указанных отношений. Большинство разработчиков применяют стереотип «uses» в ситуациях, когда версия 1.3 рекомендует указывать стереотип «includes», поскольку для многих из них стереотип «includes» может быть заменен стереотипом «uses». И большинство разработчиков применяют стереотип «extends» из версии 1.1 в более широком смысле, предполагая не только отношение «extends» из версии 1.3, но также и важнейшую составляющую отношения обобщения в версии 1.3. Поэтому можно считать, что отношение со стереотипом «extends» расщепляется в версии 1.3 на два отношения: со стереотипом «extends» и обобщение (generalization).

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

 

Диаграммы деятельности

 

С появлением версии 1.2 языка UML осталось лишь несколько открытых вопросов относительно семантики диаграмм деятельности. В версии 1.3 на большинство из этих вопросов были даны ответы, которые были закреплены в семантике языка UML.

При разработке условного поведения теперь можно обозначать принятие решения в форме ромба – как для слияния (merge), так и для ветвления (branch). Хотя для описания условного поведения ни ветвления, ни слияния не являются необходимыми, все более общепринятым становится способ изображения, заключающий условное поведение в скобки.

Символ синхронизации в форме черты теперь относится как к ветвлению (когда управление расщепляется), так и к объединению (когда синхронизируемое управление объединяется снова). Однако теперь никаких дополнительных условий на объединение не накладывается. Необходимо лишь придерживаться правил, гарантирующих соответствие ветвлений и объединений. По существу это означает, что каждое ветвление должно иметь соответствующее объединение, которое соединяет все параллельные нити процесса, берущие начало в исходном ветвле-

 

нии. Хотя ветвления и объединения могут быть вложенными, их можно удалить с диаграммы, если потоки соединяют ветвления (или объединения) напрямую.

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

Свойство множественной инициализации больше не поддерживается. Вместо него можно определить динамическую параллельность в некоторой деятельности с помощью символа «*» внутри прямоугольника деятельности. Такая деятельность может выполняться параллельно несколько раз; все ее вызовы должны быть завершены, прежде чем сможет быть выполнен какой-либо выходящий из нее переход. Это в некоторой степени эквивалентно множественной инициализации и сответ-ствующему условию синхронизации, хотя такой способ и менее гибок.

Эти правила в какой-то степени уменьшают гибкость диаграмм деятельности, однако они гарантируют, что диаграммы деятельности являются на самом деле частными случаями конечных автоматов. Отношение между диаграммами деятельности и конечными автоматами стало предметом дискуссии инициативной группы RTF. Последующие версии языка UML {после 1.4) вполне могут определить диаграммы деятельности как диаграммы совершенно другой формы.

 

Источник: Фаулер М.UML. Основы, 3-е издание. – Пер. с англ. – СПб: Символ-Плюс, 2006. – 192 с.,ил.

По теме:

  • Комментарии