31

Задачи студентов / Re: UseCase diagram. Include и Extend

« Последний ответ от [прилетело НЛО и...] 16 Августа 2023, 23:17:55 »

[некробурения псто]
Вопрос актуален [всё ещё]. В стандарте UML нет решения до сих пор. Вероятно, авторам этого стандарта не хватает столь ценимого кое-кем "практического опыта чего-то-там".

Есть сложившиеся практики, которые почти не описываются в учебниках, но следы их применения можно заметить на примерах UC-диаграмм.
Вот пример от Скотта Амблера:

Мы тут видим, что включённый ВИ имеет тот же набор связанных экторов, что и базовый, и поэтому явных ассоциаций от него к экторам нет. Также видим, что расширяющий ВИ имеет изменённый набор экторов по сравнению с базовым, и поэтому есть явная ассоциация. Можно заметить, что Амблер предлагает нам додумать такой момент: UC "Perform Security Check" связан неявно со Student, Registrar, Applicant и явно -- с International Student или же ассоциация-коммуникация к International Student перекрывает/переопределяет коммуникацию к Student, как-бы унаследованную от базового UC. 

32

Примеры / Re: Примеры сказок, оформленных в виде UML диаграмм

« Последний ответ от [прилетело НЛО и...] 16 Августа 2023, 20:18:07 »

[некробурения приступ]
То, что в теме представлено как диаграммы ВИ, взрывает мой марсианский мозг. Их невозможно прочесть по стандартным UMLьным смыслам.

33

Теория моделирования и нотации / Re: UML. Правильное отображение Decision на диаграмме (длинное условие)

« Последний ответ от [прилетело НЛО и...] 07 Августа 2023, 23:40:47 »

Да, конечно. Только по стандарту тип объединяющего узла = Merge.
Можно как на рисунке: на каждый Desicion свой Merge. Можно один общий Merge с тремя входами.

34

Теория моделирования и нотации / Re: UML. Правильное отображение Decision на диаграмме (длинное условие)

« Последний ответ от Resen70 04 Августа 2023, 16:41:03 »

А нужно ли в конце "блока" обработки условия делать "объединяющий" Desicion, в котором соединяются все разветвления?
Вот так как на рисунке:

35

Теория моделирования и нотации / Re: UML. Правильное отображение Decision на диаграмме (длинное условие)

« Последний ответ от Resen70 04 Августа 2023, 16:28:17 »

Понял, спасибо!

36

ПО Аналитика / Re: Новости от Visual Paradigm

« Последний ответ от [прилетело НЛО и...] 29 Июля 2023, 01:05:24 »

Выпущен VP 17.1
https://www.visual-paradigm.com/whats-new/

37

Теория моделирования и нотации / Re: UML. Правильное отображение Decision на диаграмме (длинное условие)

« Последний ответ от [прилетело НЛО и...] 14 Июля 2023, 13:47:20 »

Написание условия внутри Decision node -- это уступка со стороны авторов UML тем, кто привык к ibm-овским блок-схемам.
Хардкорные UML-щики берут условие в прямоугольные скобки и рисуют его при исходящем потоке:

38

Теория моделирования и нотации / Re: UML. Имя Activity

« Последний ответ от [прилетело НЛО и...] 14 Июля 2023, 13:40:17 »

Activity -- это вызываемая процедура. Она одна.
Шагами алгоритма являются вызовы этой процедуры. Это узлы действия -- Action node. Тип этих узлов Call Behaviour Action. Вызываемое поведение -- Activity -- указывается как параметр узла (не как его имя).

39

Теория моделирования и нотации / UML. Правильное отображение Decision на диаграмме (длинное условие)

« Последний ответ от Resen70 09 Июля 2023, 11:04:23 »

Здравствуйте!

Делаю простую диаграмму Activity Diagram с помощью PowerDesigner.

Текст условия, который должен быть отображен довольно длинный.
Если его вписать в поле "Name" или в поле "Condition", то значок условия сильно "раздувается", и как результат - условие коряво отображается на диаграмме.
Пример - во вложенной картинке.

Как в соответствии с требованиями стандарта UML нужно отображать такие условия?
Объясните, пожалуйста.

40

Теория моделирования и нотации / UML. Имя Activity

« Последний ответ от Resen70 09 Июля 2023, 10:53:22 »

Добрый день!

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

Объясните, пожалуйста, в соответствии с требованиями стандарта UML разве имена всех объектов должны быть уникальными?
Какой в этом смысл?
А если имя уникальное, то как на диаграмме отобразить тот факт, что несколько объектов Activity вызывают одну и ту же подпрограмму?