В июне 2015 года публике была представлена финальная версия UML 2.5 (до этого UML 2.5 существовал в версии 2.4.1 аж с августа 2011 года). Событие это для UML весьма значимо, но значимо ли оно для нас? Ниже – попытка разобраться и поразмышлять об основных изменениях и, в частности, их применимости к использованию UML бизнес-аналитиком.
Сразу поясню, что читать от начала и до конца спецификацию UML (http://www.omg.org/spec/UML/2.5), а тем более, сравнивать ее с предыдущей версией (учитывая еще, что «косметически» она была существенно переработана) ‒ дело поистине героическое, и я так и не нашел в себе силы это осуществить. В качестве основного источника информации были взяты пометки от OMG, точечные и разрозненные упоминания изменений на http://www.uml-diagrams.org/ и различные обсуждения сего события в интернете (с перепроверкой, конечно).
Итак, что сами OMG выделяют в версии 2.5:
Основное, что было сделано, это реорганизация и упрощение спецификации языка (включая объединение нескольких разрозненных описательных документов в одну спецификацию). Compliance levels («уровни строгости соответствия языку» — L1-L4) убраны, и теперь есть только «по UML» и «не по UML» (что полезно для нас с точки зрения заявления соответствия инструмента моделирования языку UML).
Теперь по частностям.
Диаграмма вариантов использования (Use case diagram):
– UML 2.0-2.4 описывали диаграмму ВИ как производную диаграммы классов (т.е. структурной диаграммы). Но в то же время, сама диаграмма ВИ была представлена в списке поведенческих диаграмм. По сути, диаграмма ВИ дуальна в этом аспекте: отражает поведенческие моменты (что можно сделать с системой), но при этом и структурна (показывает некий срез-структуру того, как системой можно пользоваться).UML 2.5 определяет теперь варианты использования как вспомогательное понятие (supplementary concept), а не поведенческий элемент (хотя сама диаграмма так и осталась в списке поведенческих):
«Clauses 7 – 12 are primarily concerned with the modeling of structure. Clauses 13 – 17 are primarily concerned with the modeling of behavior. Clauses 18 – 20 cover supplementary concepts including Use Cases, Deployments, and Information Flows.”
Что это значит: а то, что, как и раньше, черт его однозначно поймет, частью чего теоретически является диаграмма ВИ. Но шаг в сторону вынесения диаграммы в область «особых» сделан. Что это практически означает: ничего :).
– В UML 2.0-2.4 Use case subject (граница, показывающая систему, предметную область и т.п. – многие знают это как boundary) был определен как «a classifier extended with the capability to own use cases». В UML 2.5 теперь любой элемент (classifier) может в качестве subject иметь варианты использования. Вряд ли кто-то из аналитиков это и раньше знал (включая и меня), но, тем не менее, для галочки пусть будет. Практически для типовых задач моделирования это не имеет никакого значения.
– В UML 2.5 появилось требование о том, что наименование у subject должно быть в верхнем левом углу этого элемента. Предыдущие версии UML нас в этом не ограничивали (актуальная версия Sparx Enterprise Architect, кстати, отражает название в центре :().
– Что интересно, меняется определение того, что такое вариант использования (ВИ, use case).
UML 2.4.1: «A use case is the specification of a set of actions performed by a system, which yields an observable result that is, typically, of value for one or more actors or other stakeholders of the system.»
UML 2.5: «A UseCase may apply to any number of subjects. When a UseCase applies to a subject, it specifies a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject.»
Что это значит для нас: сомневаюсь, что замена system на subject (см. выше про subject) и typically useful на useful что-то критичное несет в себе для моделирования, т.к. несмотря на то, что мы традиционно считаем, что ВИ должен быть дискретно-полезным, все так же не учтены расширяющие и включаемые ВИ (которые самостоятельно полезными могут и не быть), плюс многие практики отходят от концепции «полезности» в угоду показать большее количество функциональности в системе на диаграмме.
– Предыдущие версии UML требовали, чтобы ВИ инициировались актером.
2.4.1: «When a use case has an association to an actor with a multiplicity that is greater than one at the actor end, it means that more than one actor instance is involved in initiating the use case.»
2.5: «When a UseCase has an association to an Actor with a multiplicity that is greater than one at the Actor end, it means that more than one Actor instance is involved in the UseCase.»
Что это значит: предполагаю, что это просто исправление текста. Те же примеры в спецификации UML и ранее не отрицали существования вторичных актеров (хотя и не называли их так явно и не дифференцировали их от первичных на самой диаграмме). С другой стороны, это может означать допустимость ситуаций, когда первичный актер ВИ не инициирует ВИ. В общем, простор для трактовок дан, но смысл изменения не донесен.
Также, стоит отметить, что убран текст, поясняющий что ВИ отражают нужды актеров. Трактовка, опять же, открыта.
Диаграмма классов (Class diagram):
– В предыдущих версиях UML наследуемые свойства элемента (а для нас это обычно наследуемые атрибуты класса) ничем визуально не отличались от собственных свойств производного элемента. В UML 2.5 такие свойства можно показывать на диаграмме с символом ‘^’. Это полезно показывать (и как утверждает UML, делать это нужно именно с данным символом), если не все свойства родительского класса передаются по наследованию и/или есть свойства в дочернем классе с таким же именем, но не унаследованные от родителя. Пример оформления:
Диаграммы состояний (State machine diagrams):
– Немногие, наверное, знают, что есть фактически 2 подвида диаграмм состояний: поведенческие (Behavioral state machines) и протокольные (Protocol state machines). Разница не столь очевидна, и чтобы хоть немного ее нащупать, нужно серьезно покопаться в материалах (хотя, если честно, для базовых задач моделирования ‒ не нужно J). Ранее, чтобы пометить, что диаграмма таки протокольная, а не поведенческая, рядом с названием диаграммы в ее рамке нужно было использовать {protocol} (ограничение). В UML 2.5 формат записи ‒ «protocol» (стереотип). В примере ниже – старый вариант, но представлен он для того, чтобы визуально было понятно, где нужно указывать иной формат.
Общее:
– Множественные отношения наследования/обобщения в UML можно объединять в Generalization Sets (пример). В UML 2.0 — UML 2.4.1 эти самые generalization sets по умолчанию имели свойство {incomplete, disjoint}. Т.е. а) является ли набор производных классов полным (по умолчанию – нет, вашим набором вы этого не обещаете: объект родительского класса не факт, что будет объектом какого-либо из производных классов в наборе) и 2) могут ли производные классы пересекаться (по умолчанию ‒ нет: экземпляр одного из производных классов не мог быть экземпляров и другого в то же самое время). В UML 2.5 это поменялось на {incomplete, overlapping} по умолчанию. Т.е. теперь экземпляр производного класса в наборе таки может быть экземпляром и другого класса в наборе, если вы явно не укажете свойством связи обратное. Пример, над которым нужно немного подумать:
Вот, собственно, и все, что для нас значимо. Что в сухом остатке:
– Всем, кто использует UML, стоит обратить внимание на оформление наследуемых элементов и use case subjects (но если не обратите, мир точно не рухнет ‒ ничего значимого по сравнению с версией 2.4.1 в языке не поменялось). Ну может только если значимое упрощение формата спецификации UML простимулирует вас ее осилить…
– Продвинутым практикам, возможно, полезным будет знать про изменение свойства generalization sets по умолчанию и маркировку протокольных диаграмм состояний.
– И тех, и других, а также теоретиков приглашаю в комментарии (например, если кто-то из читателей сам разобрался во всех нововведениях, встречал их качественный детальный анализ или не согласен с представленной информацией и/или ее трактовкой) для обсуждения.
«Множественные отношения наследования/обобщения в UML можно объединять в Generalization Sets» наверно следует читать как «Множество отношений наследования/обобщения в UML можно объединять в Generalization Sets» или «Различные отношения наследования/обобщения в UML можно объединять в Generalization Sets».
Если Generalization Set с {incomplete, overlapping}, то это равносильно тем же отношениям наследования/обобщения, но не объединенным в Generalization Set. По умолчанию определен не тот вариант, который наиболее часто встречается, а тот, которого вообще быть не должно.
На последнем рисунке («Пример, над которым нужно немного подумать»):
если в Generalization Set с именем CoverageType указано overlapping, то coverage должно быть не 1, а 1..*;
если в Generalization Set с именем InsurancePlan указано incomplete, то plan должно быть не 1, а 0..1
Вадим, спасибо за комментарий.
Насчет первого («множество» или «различные», вместо «множественные»): можете пояснить, что не так с исходной формулировкой? Я так понимаю, что «множественные» с вашей точки зрения вносит какую-то иную семантику во фразу?
Насчет примера: можем ли мы трактовать Generalization Set Insurance Plan и ассоциацию соответствующую (1) как «Health Insurance таки в любом случае имеет Insurance Plan, но модель не перечисляет все возможные?» Не есть наглядно, согласен, но допустимо ведь?
Согласен про CoverageType. Спасибо, что подметили.
«Если Generalization Set с {incomplete, overlapping}, то это равносильно тем же отношениям наследования/обобщения, но не объединенным в Generalization Set.» Вот этого не понял — поясните, пожалуйста. В примере как раз и показан удобный вариант группировки Coverage Types для Insurance в набор, и в этом наборе Insurance может иметь 1..3 типа (и давайте предположим, что набор не полон).
Словосочетание «множественные отношения» наводит на мысль (возможно только меня), что не все отношения наследования/обобщения можно объединять в Generalization Set, а только те из них, которые «множественные». Слово «множественная» входит в устоявшиеся сочетания «множественная классификация», «множественное наследование» и от него ждешь определенный смысл. Если оставить фразу в виде: «отношения наследования/обобщения в UML можно объединять в Generalization Sets» будет яснее, что речь идет о любых отношениях наследования/обобщения.
При одновременном отражении классификации и как Generalization Set, и как ассоциации вообще достаточно мутно — например, исходя из кратности полюса ассоциации уже следует каким будет Generalization Set: complete или incomplete — по нижней границе (по трактовке, которую Вы привели — не всегда!), disjoint или overlapping — по верхней границе.
Есть класс А, а в нем Generalization Set с {incomplete, overlapping} и подклассами Б, В и Г. То же самое будет, если у класса А есть подклассы Б, В и Г (без Generalization Set).