1

Примеры / Re: Диаграмма деятельности. Выбор по событию

« : 29 Декабря 2025, 19:36:32 »

Некротрединга псто.
В UML 2.5 есть ещё одно использование "руны Соул" -- ExceptionHandler. Fig. 15.62. Там содом с гоморою. Молниеобразное звено, которое не звено, а ножка, растущая из узла ExceptionHandler. Всё это снова про обработку исключений.

2

UML SysML и пр. / Re: UML 3.0

« : 17 Ноября 2025, 20:34:15 »

Само написало, само себе и отвечу. В официальном ютьюбчике OMG в 2024 повесили видео, поясняющее планы OMG по части стандартов в области моделирования.
https://www.youtube.com/watch?v=Xnay02jmb0s
У меня ютьюбчик "замедлен", но через бота в tm удаётся скачать и посмотреть. Даже если не слушать, то слайды поясняют намерения по UML 3.0 и др.

3

UML SysML и пр. / UML 3.0

« : 15 Ноября 2025, 17:30:25 »

В марте этого года опубликован OMG UML3 RFI. https://www.omg.org/cgi-bin/doc?ad/25-03-01.docx
Это первый шаг на пути к стандарту UML 3.0. В планах OMG также есть продолжение работы над исправлением ошибок в UML 2.5.1, итогом чего будет стандарт UML 2.6. 3й UML задуман как «перезапуск» на базе текстовой нотации KerML 1.0 (стандарт опубликован в сентябре 2025). KerML уже лёг в основу нового SysML 2.0 (также сентябрь 2025).
Создателям сайта uml3.ru респект! Как в воду глядели.

4

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

« : 15 Ноября 2025, 17:24:05 »

В августе 2025 вышла VP 17.3. Основные нововведения состоят в прикручивании всяческого ИИ (доступного обладателям платных версий).

5

Теория моделирования и нотации / Re: Как правильно структурировать диаграмму классов в PlantUml?

« : 06 Января 2025, 21:13:22 »

По PlantUML есть длинное русскоязычное руководство "Неочевидный PlantUML", опубликованное в 4 частях:
1 часть
2 часть
3 часть
4 часть

6

Конференции Семинары и Тренинги / Re: Реклама ЛАФ-2018

« : 28 Июля 2024, 02:10:32 »

[Удалено, так как учётку не удалось снести.]

7

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

« : 30 Мая 2024, 11:42:00 »

Выпущен VP 17.2
https://www.visual-paradigm.com/whats-new/
обещают, что прокачали диаграммы деятельности, последовательности, размещения, состояний, компонентов и пакетов.
Будем посмотреть.

8

Теория моделирования и нотации / Re: Как правильно структурировать диаграмму классов в PlantUml?

« : 14 Мая 2024, 14:23:55 »

Мастера игры в Plantuml живут на Stackoverflow. Советы, которые размещены там:
- пробовать замену "вертикальных" связей (с одинарным "-" в начертании) на "горизонтальные" (с двойным "--"). Например A <|- B vs A <|-- B
- пробовать менять местами правую и левую части. Например A <|- B vs B -|> A
- переупорядочивать строки или фрагменты в Plantuml-описании
- добавлять невидимые связи ради желаемого расположения элементов, которые ими связаны
- добавлять невидимые промежуточные пункты ради желаемого расположения сегментов связей (связь становится как бы цепью из звеньев)

Где-то там живет такая ссылка с продвинутыми магическими пассами: https://isgb.otago.ac.nz/infosci/mark.george/Wiki/wiki/PlantUML%20GraphViz%20Layout

9

Теория моделирования и нотации / Re: Как правильно структурировать диаграмму классов в PlantUml?

« : 06 Мая 2024, 14:30:19 »

Обычно, обсуждая диаграммы, рассматривают языковые (uml-ьные) конструкции, а не "бантики" -- что слева, что справа.
Я эту рисовалку увидело и попробовало сегодня. С Вашей подачи.

Добавляете свои директивы для стиля и получаете орто-линии + слева-направные классы.

[Обще]Принято, что суперкласс слева от своих потомков. Или сверху над своими потомками.
===
@startuml
skinparam linetype ortho
left to right direction
class BaseViewModel {
  + event PropertyChangedEventHandler PropertyChanged
  # OnPropertyChanged([CallerMemberName] string PropertyName = null):void {abstract}
  # Set<T>(ref T field, T value, [CallerMemberName] string PropertyName = null):bool {abstract}
}

class MainViewModel {
  + MainViewModel()
}

class Entity1ViewModel {
  + Main(args: string[]): void
}

class Entity2ViewModel {
  + Main(args: string[]): void
}

class Entity3ViewModel {
  + Main(args: string[]): void
}


 BaseViewModel <|-- MainViewModel
 BaseViewModel <|-- Entity1ViewModel
 BaseViewModel <|-- Entity2ViewModel
 BaseViewModel <|-- Entity3ViewModel

 Entity1ViewModel "_entity1ViewModel" <-- MainViewModel
 Entity2ViewModel "_entity2ViewModel" <-- MainViewModel
 Entity3ViewModel "_entity3ViewModel" <-- MainViewModel
@enduml
===

10

ПО Аналитика / Re: Как генерировать диаграмму последовательностей из существующего проекта SparxEA?

« : 06 Мая 2024, 14:08:19 »

===
@startuml
[-> ParserWorker : Worker()
loop for i in parserSettings.StartPoint..parserSettings.EndPoint
  break isActive
  note over ParserWorker: выход из цикла
  end
  ParserWorker -> loader : GetSourceByPageId(i)
  loader --> ParserWorker : source
  create HtmlParser
  ParserWorker --> HtmlParser : new
  ParserWorker -> HtmlParser : ParseAsync(source)
  HtmlParser --> ParserWorker : document
  ParserWorker -> parser : Parse(document)
  parser --> ParserWorker : result
  opt OnNewData != NULL
   ParserWorker -> OnNewData : Invoke(this, result)
  end
end
opt OnCompleted != NULL
   ParserWorker -> OnCompleted : Invoke(this)
end
ParserWorker -> ParserWorker : isActive = FALSE
[<-- ParserWorker:return
@enduml
===

11

Реализация / Re: Как правильно нарисовать диаграмму классов?

« : 06 Мая 2024, 13:48:04 »

===
@startuml
class Program {
   {static}  + Main(args: string[]): void
}

class MoneyBack {
    + GetCardType(): string
    + GetCreditLimit(): int
    + GetAnnualCharge(): int
}


interface ICreditCard {
  + GetCardType(): string
  + GetCreditLimit(): int
  + GetAnnualCharge(): int
}

ICreditCard "cardDetails" <-- Program
ICreditCard <|.. MoneyBack
Program ..> MoneyBack
@enduml
===

12

Теория моделирования и нотации / Re: Как правильно структурировать диаграмму классов в PlantUml?

« : 06 Мая 2024, 13:36:48 »

Вопрос, вероятно, по стилю оформления диаграммы.
Что если...

===
@startuml
class BaseViewModel {
  + event PropertyChangedEventHandler PropertyChanged
  # OnPropertyChanged([CallerMemberName] string PropertyName = null):void {abstract}
  # Set<T>(ref T field, T value, [CallerMemberName] string PropertyName = null):bool {abstract}
}

class MainViewModel {
  + MainViewModel()
}

class Entity1ViewModel {
  + Main(args: string[]): void
}

class Entity2ViewModel {
  + Main(args: string[]): void
}

class Entity3ViewModel {
  + Main(args: string[]): void
}


 BaseViewModel <|-- MainViewModel
 BaseViewModel <|-- Entity1ViewModel
 BaseViewModel <|-- Entity2ViewModel
 BaseViewModel <|-- Entity3ViewModel

 Entity1ViewModel "_entity1ViewModel" <-- MainViewModel
 Entity2ViewModel "_entity2ViewModel" <-- MainViewModel
 Entity3ViewModel "_entity3ViewModel" <-- MainViewModel
@enduml
===

13

Проектирование / Re: Математическое обоснование S.O.L.I.D принципов

« : 29 Апреля 2024, 20:16:11 »

[Очередная попытка некротредить]
Попался материал забугорный, но тоже доставляющий в плане якобы математических обоснований.
http://arxiv.org/pdf/1304.0116
===
 В более общем случае предположим, что цель g может быть достигнута с помощью n объектов проектирования (D1, D2, ... Dn), каждый из которых обладает характеристиками (F1, F2, ... Fn). Тогда множество требований Rg можно определить как пересечение свойств (Rg = F1 ∩ F2 ∩ ... ∩ Fn).

===
Это почти то же самое, что знаменитое практически все люди, страдающие хроническими заболеваниями, ели огурцы. Что если все объекты Di ели огурцы обладают некоторым свойством, которое никакого отношения не имеет к достижению цели g? Будет ли оно требованием? По логике Паула Ральфа, будет.

14

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

« : 26 Марта 2024, 13:22:06 »

Вот иллюстрация.
Деятельность Trib внутри себя содержит три рекурсивных вызова (3 узла действия вызова деятельности). Моделируется вычисление n-ого числа трибоначчи.

15

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

« : 23 Февраля 2024, 03:35:21 »

Стандарт языка не запрещает одноимённые деятельности.
EA не может строить догадки о том, что Вы моделируете.
PD аллертит из-за нарушения встроенных в него правил.

По [моей] идее, очень мало поводов рисовать именно деятельность на диаграмме деятельности. В описанном Вами случае на диаграмме деятельность одна и она выполняет роль рамки всей диаграммы. Это описываемая процедура.
Вызываемая подпрограмма как деятельность на диаграмме не присутствует. Присутствуют её вызовы -- узлы действия, Action Node.
Написанное выше не является требованием стандарта. Это что-то вроде перевода написанного Вами в термины UML.