Форум Сообщества Аналитиков

×


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

Страницы: « 1 2 3 4 5 6 7 8 9 10 »
11
Вакансии / Приглашаем системного аналитика КХД
« Последний ответ от Mikle2016 11 Июля 2024, 12:11:51 »
Приглашаем системного аналитика КХД, Москва, гибридный график kkosti1973@yandex.ru
Обязанности:
1.       Проработка/формирование требований к развитию КХД;
2.       Анализ источников данных исходных систем (ИС), формирование требований к загрузке данных из ИС в КХД;
3.       Проектирование моделей данных и витрин данных;
4.       Взаимодействие с внутренними командами и поставщиками IT-решений;
5.       Постановка задач разработчикам и дата-инженерам КХД;
6.       Формирование документации, необходимой для разработки, в том числе функциональные дизайны, техническое задание, регламенты, инструкции;
7.       Тестирование функционала, проверка на соответствие требованиям;
8.       Работа с большими массивами разрозненных данных, их структурирование и анализ для формирования отчетов.
Требования:
1.       Опыт работы от 3-х лет в качестве системного аналитика;
2.       Опыт работы с SAP-системами;
3.       Опыт проектирования взаимодействия различных информационных систем с учетом реализации разных требований и участков бизнес-процессов в специализированных продуктах;
4.       Опыт работы с SQL на уровне написания простых запросов к базам данных;
5.       Желателен опыт работы с различными BI-инструментами: SAP BI, Power BI, Tableau;
6.       Знание основ XML, знание SQL на уровне написания простых запросов к базам данных;
7.       Навыки написания проектной документации;
12
ПО Аналитика / Re: Новости от Visual Paradigm
« Последний ответ от [прилетело НЛО и...] 30 Мая 2024, 11:42:00 »
Выпущен VP 17.2
https://www.visual-paradigm.com/whats-new/
обещают, что прокачали диаграммы деятельности, последовательности, размещения, состояний, компонентов и пакетов.
Будем посмотреть.
13
Мастера игры в 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
14
Обычно, обсуждая диаграммы, рассматривают языковые (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
===
15
Вопрос, вероятно, по стилю оформления диаграммы.
Что если...

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




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

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

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

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

16
===
@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
===
17
===
@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
===

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

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

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

===
Это почти то же самое, что знаменитое практически все люди, страдающие хроническими заболеваниями, ели огурцы. Что если все объекты Di ели огурцы обладают некоторым свойством, которое никакого отношения не имеет к достижению цели g? Будет ли оно требованием? По логике Паула Ральфа, будет.
Страницы: « 1 2 3 4 5 6 7 8 9 10 »