1
Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Страницы: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 »
2
Конференции Семинары и Тренинги / Re: Реклама ЛАФ-2018
« : 28 Июля 2024, 02:10:32 »
[Удалено, так как учётку не удалось снести.]
3
ПО Аналитика / Re: Новости от Visual Paradigm
« : 30 Мая 2024, 11:42:00 »
Выпущен VP 17.2
https://www.visual-paradigm.com/whats-new/
обещают, что прокачали диаграммы деятельности, последовательности, размещения, состояний, компонентов и пакетов.
Будем посмотреть.
https://www.visual-paradigm.com/whats-new/
Будем посмотреть.
4
Теория моделирования и нотации / 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
- пробовать замену "вертикальных" связей (с одинарным "-" в начертании) на "горизонтальные" (с двойным "--"). Например A <|- B vs A <|-- B
- пробовать менять местами правую и левую части. Например A <|- B vs B -|> A
- переупорядочивать строки или фрагменты в Plantuml-описании
- добавлять невидимые связи ради желаемого расположения элементов, которые ими связаны
- добавлять невидимые промежуточные пункты ради желаемого расположения сегментов связей (связь становится как бы цепью из звеньев)
Где-то там живет такая ссылка с продвинутыми магическими пассами: https://isgb.otago.ac.nz/infosci/mark.george/Wiki/wiki/PlantUML%20GraphViz%20Layout
5
Теория моделирования и нотации / 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
===
Я эту рисовалку увидело и попробовало сегодня. С Вашей подачи.
Добавляете свои директивы для стиля и получаете орто-линии + слева-направные классы.
[Обще]Принято, что суперкласс слева от своих потомков. Или сверху над своими потомками.
===
@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
===
6
ПО Аналитика / 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
===
@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
===
7
Реализация / 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
===
@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
===
8
Теория моделирования и нотации / 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
===
Что если...
===
@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
===
9
Проектирование / 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? Будет ли оно требованием? По логике Паула Ральфа, будет.
Попался материал забугорный, но тоже доставляющий в плане якобы математических обоснований.
http://arxiv.org/pdf/1304.0116
===
В более общем случае предположим, что цель g может быть достигнута с помощью n объектов проектирования (D1, D2, ... Dn), каждый из которых обладает характеристиками (F1, F2, ... Fn). Тогда множество требований Rg можно определить как пересечение свойств (Rg = F1 ∩ F2 ∩ ... ∩ Fn).
===
Это почти то же самое, что знаменитое практически все люди, страдающие хроническими заболеваниями, ели огурцы. Что если все объекты Di
10
Теория моделирования и нотации / Re: UML. Имя Activity
« : 26 Марта 2024, 13:22:06 »
Вот иллюстрация.
Деятельность Trib внутри себя содержит три рекурсивных вызова (3 узла действия вызова деятельности). Моделируется вычисление n-ого числа трибоначчи.
11
Теория моделирования и нотации / Re: UML. Имя Activity
« : 23 Февраля 2024, 03:35:21 »
Стандарт языка не запрещает одноимённые деятельности.
EA не может строить догадки о том, что Вы моделируете.
PD аллертит из-за нарушения встроенных в него правил.
По [моей] идее, очень мало поводов рисовать именно деятельность на диаграмме деятельности. В описанном Вами случае на диаграмме деятельность одна и она выполняет роль рамки всей диаграммы. Это описываемая процедура.
Вызываемая подпрограмма как деятельность на диаграмме не присутствует. Присутствуют её вызовы -- узлы действия, Action Node.
Написанное выше не является требованием стандарта. Это что-то вроде перевода написанного Вами в термины UML.
EA не может строить догадки о том, что Вы моделируете.
PD аллертит из-за нарушения встроенных в него правил.
По [моей] идее, очень мало поводов рисовать именно деятельность на диаграмме деятельности. В описанном Вами случае на диаграмме деятельность одна и она выполняет роль рамки всей диаграммы. Это описываемая процедура.
Вызываемая подпрограмма как деятельность на диаграмме не присутствует. Присутствуют её вызовы -- узлы действия, Action Node.
Написанное выше не является требованием стандарта. Это что-то вроде перевода написанного Вами в термины UML.
12
Реализация / Re: Как правильно нарисовать диаграмму классов?
« : 23 Февраля 2024, 03:25:50 »
С первым куском кода не всё ОК. Имя cardDetails используется, но не описано.
На каждой приведённой диаграмме к интерфейсу от класса-реализации должно идти не обобщение (сплошная стрелка с треугольным выколотым наконечником), а реализация (пунктирная стрелка с треугольным выколотым наконечником).
Диаграммы на которых Program соединен с интерфейсом обобщением (сплошной стрелкой с треугольным выколотым наконечником) ошибочны, там должна быть ассоциация.
Статическая операция должна быть подчёркнута.
В UML в сигнатуре операции её имя предшествует типу возвращаемого значения.
Разумно нарисовать зависимость от Program к классу-реализации, т. к. он используется и его имя известно Program.
На каждой приведённой диаграмме к интерфейсу от класса-реализации должно идти не обобщение (сплошная стрелка с треугольным выколотым наконечником), а реализация (пунктирная стрелка с треугольным выколотым наконечником).
Диаграммы на которых Program соединен с интерфейсом обобщением (сплошной стрелкой с треугольным выколотым наконечником) ошибочны, там должна быть ассоциация.
Статическая операция должна быть подчёркнута.
В UML в сигнатуре операции её имя предшествует типу возвращаемого значения.
Разумно нарисовать зависимость от Program к классу-реализации, т. к. он используется и его имя известно Program.
13
UML SysML и пр. / Re: Шутки и UML
« : 23 Февраля 2024, 03:10:02 »А что-то ничего не отображаетсяЭто хост временно лёг, на котором картинка лежит.(
14
UML SysML и пр. / Re: Шутки и UML
« : 30 Декабря 2023, 21:10:18 »
С наступающим!
UML-ёлочка вышла немного нестандартная. Это Visual Paradigm разрешает так складывать подарки под неё. В стандарте таким художествам нет места.
15
Задачи студентов / ChatGPT в приложении к составлению UML-диаграмм
« : 08 Сентября 2023, 12:45:37 »
https://link.springer.com/content/pdf/10.1007/s10270-023-01105-5.pdf
Испанские исследователи натравили ChatGPT на решение учебных задачек по составлению UML-диаграмм. Оказалось, что ИИ часто генерит диаграмму, которую составители задачи не ожидали.
Глядя с Марсу, могу судить, что такое часто происходит даже в тех случаях, когда диаграмму выдумывает неискусственный разум.
Испанские исследователи натравили ChatGPT на решение учебных задачек по составлению UML-диаграмм. Оказалось, что ИИ часто генерит диаграмму, которую составители задачи не ожидали.
Глядя с Марсу, могу судить, что такое часто происходит даже в тех случаях, когда диаграмму выдумывает неискусственный разум.