Последние сообщения

Страницы: « 1 2 3 4 5 6 7 8 9 10 »

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

« Последний ответ от Виталий И 06 Мая 2024, 14:08:25 »

Цитата: [прилетело НЛО и...] от 06 Мая 2024, 13:36:48

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

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

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
===

Я плохо владею навыком построения диаграмм.

Я хотел бы получить что-нибудь в духе такого (см. картинку)

Ожидаемое оформление:
- классы располагаются слево-направо;
- соединительные лини перпендикулярные.

Только не знаю как правильно разместить базовый класс.
Хотел бы базовый класс вынести вверх или вниз...
Т.к. вправо предполагаются размести ь ещё классы.

ПО Аналитика / 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
===

Реализация / 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
===

Теория моделирования и нотации / 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
===

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

« Последний ответ от Виталий И 06 Мая 2024, 00:14:08 »

Как правильно структурировать диаграмму классов в PlantUml?
Пробую построить диаграмму классов в PlantUml, получаю кашу.

```cs
class MainViewModdel : BaseViewModdel
{
Entity1ViewModdel _entity1ViewModdel;
Entity2ViewModdel _entity2ViewModdel;
Entity3ViewModdel _entity3ViewModdel;

public MainViewModdel()
{
_entity1ViewModdel = new Entity1ViewModdel();
_entity2ViewModdel = new Entity2ViewModdel();
_entity3ViewModdel = new Entity3ViewModdel();
}
}

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

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

class Entity3ViewModdel : BaseViewModdel
{
+ Main(args: string[]): void
}
```

```cs
internal abstract class BaseViewModel : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;

protected virtual void OnPropertyChanged([CallerMemberName] string PropertyName = null)
{
// Код...
}

protected virtual bool Set<T>(ref T field, T value, [CallerMemberName] string PropertyName = null)
{
// Код...
}

}
```

# uml
```puml
skinparam linetype ortho
left to right direction

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

class MainViewModel {
- _entity1ViewModel : Entity1ViewModel
- _entity2ViewModel : Entity2ViewModel
- _entity3ViewModel : Entity3ViewModel
+ 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

MainViewModel --> Entity1ViewModel
MainViewModel --> Entity2ViewModel
MainViewModel --> Entity3ViewModel
```

Проектирование / 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? Будет ли оно требованием? По логике Паула Ральфа, будет.

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

« Последний ответ от [прилетело НЛО и...] 26 Марта 2024, 13:22:06 »

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

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

« Последний ответ от Galogen 22 Марта 2024, 19:08:18 »

Цитата: Resen70 от 09 Июля 2023, 10:53:22

Добрый день!

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

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

На самом деле процедура в программе определена одна, а вот вызовов конечно может быть много.

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

« Последний ответ от [прилетело НЛО и...] 23 Февраля 2024, 03:35:21 »

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

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

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

« Последний ответ от [прилетело НЛО и...] 23 Февраля 2024, 03:25:50 »

С первым куском кода не всё ОК. Имя cardDetails используется, но не описано.
На каждой приведённой диаграмме к интерфейсу от класса-реализации должно идти не обобщение (сплошная стрелка с треугольным выколотым наконечником), а реализация (пунктирная стрелка с треугольным выколотым наконечником).
Диаграммы на которых Program соединен с интерфейсом обобщением (сплошной стрелкой с треугольным выколотым наконечником) ошибочны, там должна быть ассоциация.
Статическая операция должна быть подчёркнута.
В UML в сигнатуре операции её имя предшествует типу возвращаемого значения.
Разумно нарисовать зависимость от Program к классу-реализации, т. к. он используется и его имя известно Program.

Страницы: « 1 2 3 4 5 6 7 8 9 10 »