Как представить систему в UML?
Мы можем использовать элемент Subsystem, чтобы показать разбивку систем в UML. И мы можем сгруппировать компоненты в подсистемы.
Но есть ли элемент, представляющий систему?
Система здесь означает надмножество подсистем.
Что ж, суперсет (вы, вероятно, имеете в виду только набор) не обязательно сделает систему. У вас может быть набор подсистем, которые по-прежнему являются подсистемами.
Ответы 3
Единственная диаграмма UML, на которой вы видите систему во внешнем мире, — это диаграмма вариантов использования. Рассматриваемая система представлена в виде окружающего прямоугольника, в котором показаны варианты использования.
На всех других диаграммах мы должны показать некоторые внутренние элементы системы, и нет никаких обозначений (и даже необходимости), чтобы показать всю систему. На некоторых структурных схемах можно показать более крупные подсистемы. Вы показываете их как компонент, возглавляемый стандартным стереотипом «Subsystem».
Теперь границы сложных систем может быть нечетким: вы вполне можете работать с очень сложной «системой систем». В этом случае у вас есть система, состоящая из других систем. С точки зрения UML эти другие системы были бы просто подсистемами «системы систем».
Если вам нужно сделать более четкое различие между уровнями подсистем, вы можете просто создать профиль UML со стереотипом «System». В другом крайнем диапазоне вы можете использовать SysML с выделенным профилем SoS.
Чтобы создать стереотип, вам нужно иметь профиль, которому этот стереотип принадлежит. Возможно, немного overtkill для этой цели.
Я предполагаю, что термин система четко не определен ОП.
@qwerty_so действительно, как указано, «вы можете просто создать профиль с профилем «Система»». Люди регулярно создают профили для использования конкретных языковых типов. Это действительно перебор, чтобы создать профиль? Если вы работаете над системами систем, это немного больно для большой дополнительной выразительности. Главный вопрос заключается в том, действительно ли это необходимо. Если вы делаете иерархическую декомпозицию системы, просто начните с первого уровня подсистемы ниже системы, которая неявно включает их.
@qwerty_so Я не буду винить OP: система произвольна: вы можете считать ее ИТ-системой с ограничениями. Но вы можете уменьшить масштаб и рассматривать группу связанных систем как настоящую систему. И вы могли бы рассмотреть организационную систему, состоящую из человеческих, организационных и ИТ-активов. Это потому, что рекурсивное определение систем.
Вот почему я сомневаюсь в понимании/самоанализе ОП. Что такое его идея системы. Обычно вы моделируете рассматриваемую систему, и это понимается как система. Но то, как задается вопрос, я сомневаюсь, что ОП принял решение.
Система — это всего лишь компонент, состоящий из подсистем. А в системе систем она сама будет подсистемой. Итак, каждый компонент всегда является одновременно и системой, и подсистемой — просто это зависит от точка зрения моделлера. Поэтому одни и те же диаграммы можно использовать для демонстрации разложения систем и подсистем.
Чтобы показать, какой из компонентов представляет интерес с точки зрения ваш, вы можете создать стереотип «system», как предложил @Christophe. Как ни странно, для этого нет стандартного стереотипа даже в SysML.
Здесь тот же комментарий, что и ниже...
@qwerty_so: Да, для создания профиля необходимы некоторые усилия. Тем не менее, большинство проектов все равно будут иметь свой собственный профиль, поэтому стереотип может быть просто добавлен туда. Кроме того, его не так сложно создать, по крайней мере, если у вас есть хороший инструмент для моделирования. На самом деле я использую стереотип «системы» в большинстве своих проектов.
У меня есть свои профили. Но я предполагаю, что процедура его создания недоступна обычному пользователю UML. EA представила настоящие профили совсем недавно. Тем не менее, вы можете создавать «дикие» стереотипы, которые, я думаю, до сих пор являются обычной практикой. Лишь бы возразить. Кстати. Я все еще думаю, что ОП не подумал о система. Это настолько распространенный термин, что, кажется, все знают его значение. Но на самом деле это не то же самое в реальности. Хорошо...
Поскольку подсистема уже является стереотипом компонента в стандартном профиле, вам просто нужно создать «системный» стереотип, который также расширяет метакласс компонента в вашем собственном профиле. Это с учетом того, что областью вашей системы является только программное и аппаратное обеспечение без активности актера. Как упомянул Кристоф, единственная вещь в UML, представляющая систему, - это предмет, который окружает его варианты использования, причем предмет даже не является элементом модели...
Чтобы создать стереотип, вам нужно иметь профиль, которому этот стереотип принадлежит. Возможно, немного overtkill для этой цели.
На самом деле, subjectявляется элемент модели. Это свойство UseCase. Любой Classifier может быть subjectUseCase. Следовательно, диаграмма вариантов использования также не позволяет моделировать систему. Мы можем подумать, что предметом варианта использования является интересующая нас система, но это всего лишь интерпретация. Что делать, если вариант использования имеет несколько субъектов?
Формально, как видно из раздела 18.1 спецификации OMG, Subject не является метаклассом, а метакласс UseCase не имеет атрибутов. Впрочем, здесь это не имеет большого значения. Кроме того, в третьем предложении раздела 18.1.1 говорится: «Каждый предмет варианта использования представляет собой рассматриваемую систему, к которой применяется вариант использования». Насколько я понимаю, конкретный вариант использования может быть частью более чем одной системы. Следовательно, «общий» вариант использования будет указан один раз для всех систем, в которых он участвует.
Да, subject — это не метакласс. Однако метакласс UseCaseделает имеет атрибуты, одним из которых является subject. Имейте в виду, что ассоциации, оканчивающиеся точкой, являются атрибутами класса.
Я не помнил, что в спецификации явно упоминаются системы, и мне нравится эта цитата, так как она подтверждает мою интерпретацию выше. Тем не менее, было бы полезно сделать систему более узнаваемой, добавив стереотип. Если вариант использования имеет более одного субъекта, возможно, обе системы описаны в нашей модели. Также возможно, что один из них упоминается здесь лишь вкратце, а модель в основном посвящена другому. Тогда мне нужно сделать различие. Опять же, я мог бы использовать стереотип.
Спасибо, Аксель, за эти полезные разъяснения.
Что, с вашей точки зрения, будет система?