Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Разработка информационных систем Новый топик    Ответить
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8      [все]
 Просветите в UML. Вопрос.  [new]
Charles Weyland
Member

Откуда: Feorina "Fury" 161
Сообщений: 4286
Смотрю на все академические примеры использования UML и создаётся такое ощущение, будто они для программ в 1 мегабайт годятся.
Смотрю на стройную диаграмму классов. У меня каждый класс имеет по несколько десятков методов (есть, конечно, маленькие, но есть и до 50). И классов реально куча.
Не могу понять практический смысл описания подобным образом промышленных приложений.


Или, предположим, ведётся разработка программы Excel.
Необходимо создать Use-Case диаграмму. Не понимаю, что на ней отображать.
Могу компактно перечислить возможности Excel. И мне видится это наглядным. Могу расписать каждую подробнее, если потребуется.
Но раздувать из каждой строки громоздкие рисунки, плюс, непонятно, что на них рисовать, и плюс вариантов использования слишком дохрена.
14 апр 19, 23:35    [21861807]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
hVostt
Member

Откуда:
Сообщений: 16164
Charles Weyland,

UML плохо подходит для моделирования реального программного кода.
Разве что академические алгоритмы, или паттерны.

Максимум, это архитектура без деталей реализации.
И вообще, UML неудобен.
15 апр 19, 02:10    [21861838]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Charles Weyland,

Поэтому UML в лучшем случае используется манагерами для презентаций заказчику.
По идее в нулевых были попытки создать кодогенераторы на основе UML, но как-то "не взлетело"
15 апр 19, 10:56    [21862111]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
Charles Weyland
Не могу понять практический смысл описания подобным образом промышленных приложений.


смысл в


mad_nazgul
По идее в нулевых были попытки создать кодогенераторы на основе UML, но как-то "не взлетело"
15 апр 19, 11:19    [21862152]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
mad_nazgul
Поэтому UML в лучшем случае используется манагерами для презентаций заказчику.


манагеры кроме use case с человечками вообще ничего не воспринимают
15 апр 19, 11:20    [21862155]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
Charles Weyland
Но раздувать из каждой строки громоздкие рисунки, плюс, непонятно, что на них рисовать, и плюс вариантов использования слишком дохрена.

Когда придётся это всё кодить, то от раздувания никуда не денешься. Поэтому, хотя бы иногда, надо иметь карту боя.
15 апр 19, 12:24    [21862282]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
hVostt
Member

Откуда:
Сообщений: 16164
МодальноеОкно
манагеры кроме use case с человечками вообще ничего не воспринимают


по большему счёту это тоже им не нужно :)
15 апр 19, 19:33    [21862955]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
ViPRos
Member

Откуда:
Сообщений: 9630
mad_nazgul
Charles Weyland,

Поэтому UML в лучшем случае используется манагерами для презентаций заказчику.
По идее в нулевых были попытки создать кодогенераторы на основе UML, но как-то "не взлетело"

есть даже интерпретаторы
15 апр 19, 20:07    [21862967]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
hVostt
Member

Откуда:
Сообщений: 16164
ViPRos,

https://yuml.me/diagram/scruffy/class/draw

а можно не рисовать мышкой )
15 апр 19, 21:25    [21863017]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
betelgeizex
Member

Откуда:
Сообщений: 87
hVostt
ViPRos,

https://yuml.me/diagram/scruffy/class/draw

а можно не рисовать мышкой )


PlantUML же! Лет N-цать как :)

P.S. Не дай бох когда еще столкнуться с энтой красотой
15 апр 19, 22:56    [21863072]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Relic Hunter
Member

Откуда: AB
Сообщений: 7088
Унас был УМЛ и начале нулевых. Когда консультант превисил 600+ страниц Use-Case его уволили (хотя он утверждал это только начало ), тк.т стока мусора никто читать nе будет.
15 апр 19, 23:07    [21863074]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Bsplesk
Member

Откуда:
Сообщений: 126
Relic Hunter,

Забыли дополнить, потом уволили всех разработчиков и закрыли/обанкротили фирму - т.к. что наделали разработчики осталось великой тайной - зачем оно вообще бизнесу и как это поддерживать/дорабатывать после ухода "аксакалов".
Без USE CASE в первую очередь выгодно разработчикам - т.к. они становятся "незаменимыми", от части это решает "микросервисная ахитертура" - когда в случае чего просто выкидывают "поделие" без особых затрат заменяют другим не затрагивая остальные системы.

USE CASE - по факту основа любого ТЗ (и предварительно сбора требований) если вы делаете что-то для бизнеса.

Возмём для примера:

https://habr.com/en/company/yandex/blog/442762/ - интересны в первую очередь "комменты".

И смотрим, как при появлении 100/500 вопросов автор приходит сам того не осознавая к необходимости выделения "Кейсов/Сценариев использования". Ведь можно "не потом", а сразу - описать возможные кейсы (да возможно не все будет определено на начальном этапе - на этом кстати базируется оценка). И вот тут будет очень кстати UML activity/sequence. Чтобы была возможность у "предлагающих" "решения" - прогнать его по "кейсам".

jirfag
Есть следующий кейс:
1. клиент отправляет заявку, заявка создается, но ответ от сервера не был получен, интернет вообще пропал на какое-то время
2. проходит какое-то время
3. сервер начинает шедулить заявки: искать дубли заявок и выбирать исполнителя.
4. сервер назначает водителя
5. у клиента отвисает интернет и он повторяет исходный запрос создания заявки
6. создается дублирующая заявка
7. по этой дублирующей заявке позже приезжает второе такси

Не понимаю идеи, чем заявки на создание заказа помогают?
16 апр 19, 09:56    [21863303]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Bsplesk,

Минутка КО

Разработчики пишут код, в соответствии со спецификациями (ТЗ).
Кто будет писать/документировать эти спецификации (ТЗ) это уже вопрос организации.
Спецификации (ТЗ) должны быть написаны так, чтобы они были понятны как разработчикам, так и заказчикам (бизнесу).
Главное здесь "ПОНЯТНЫЙ".

Т.к. программист не понимает что ему говорит заказчик/бизнес пример.

Хотя если подумать

А теперь вопрос - кому понятен UML?
Понятен он заказчику (бизнесу) - нет.
Т.к. для "чтения" UML нужно учиться, а заказчику (бизнесу) это не надо.
Понятен они программисту?
Тоже - нет!
Опять же из-за того, что надо учить новый ЯП!
А потом переводить этот ЯП в другой "нативный" ЯП.
Т.е. имеем некоторый птичий язык, который понятен только тем кто его знает и который не решает никаких проблем. :-)
17 апр 19, 08:41    [21864400]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
mad_nazgul
Понятен он заказчику (бизнесу) - нет.


на уровне use case и диаграммы взаимодействия - вполне. ничего там непонятного нет. а остальное всё (ER, классы) бизнесу не интересно
17 апр 19, 10:47    [21864582]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
WebSharper
Member

Откуда:
Сообщений: 487
Диаграммы на UML удобны как иллюстрация - чтобы нарисовать на доске коллеге при обсуждении дизайна, как часть документации для программистов, для описания паттернов проектирования и т.д.

+
Картинка с другого сайта.


Насчет обсуждения задачи с заказчиком, не знаю. Я думаю для описания бизнес процессов какая-нибудь swimlane diagram будет вполне себе понятна с небольшими объяснениями, но сам не пробовал.

+
Картинка с другого сайта.



Поддерживать постоянную модель всего в UML мне не представляется разумным - чтобы удобно работать с диаграммами надо не только описывать модель, но и размещать эти квадратики, чтобы стрелочки пересекались поменьше и т.д. - мне кажется в этом нет особого смысла.
17 апр 19, 10:50    [21864586]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
WebSharper
но и размещать эти квадратики, чтобы стрелочки пересекались поменьше и т.д. - мне кажется в этом нет особого смысла.


если в вашей диаграмме пересекаются стрелки - она гавно (с) один мудрый аналитик
17 апр 19, 10:52    [21864592]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Bsplesk
Member

Откуда:
Сообщений: 126
Тема на самом деле "холливарная", я за умеренное/разумное применение UML.

На моей практике - бизнес отлично - без обучения понимает USE CASES.
Причем совсем не обязательно рисовать "огурчики" достаточно оформить в виде "Содержания"/CASES-->[GROUP XX]-->CASE XXX.
Но "диаграмма" с "огурчиками" лучше передает обзорную картину, что условная роль (да-да роли/права enterprise) "Вася" делает XYZ, а "Петя" ABCDE, а "Вера" XYDE или вообще динамически, но тогда "огурчики" не нужны.
"Пограммисты" отлично понимают activity (граф. отображение алгоритмов) - без доп. обучения и sequence (это больше для интеграции) с обучением 30 мин. на объяснение "альтернативных" сценариев.

Что касается Class Diagram - на моей практике если есть задачи, которые требуют необходимость генерации кода (причем под "кодом" может подразумеваться шаблон документа/меню интерфейса), то UML вполне, как один из вариантов. Другими вариантами могут быть xml schema+xlst/json schema (есть хочется приключений) или "IDL" какого-нибудь "чудного" шаблонизатора, который может "сдохнуть" еще до окончания проекта.

p.s. Программировать бизнес логику на UML не предлагаю - для этого лучше подходят бизнес правила/drools, dmn .. etc.
17 апр 19, 11:32    [21864661]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Bsplesk
Member

Откуда:
Сообщений: 126
p.s. Для обсуждения процесса с бизнесом к дополнению к тексту есть BPMN (гораздо человечнее UML) и для бизнеса достаточно.
Для "Общего введения" есть продающие презентации в "картинках с котиками" аля "мемы".
17 апр 19, 11:50    [21864705]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
МодальноеОкно
mad_nazgul
Понятен он заказчику (бизнесу) - нет.

на уровне use case и диаграммы взаимодействия - вполне. ничего там непонятного нет. а остальное всё (ER, классы) бизнесу не интересно


Был у меня один проект, где аналитик нарисовал страниц то-ли 15 то-ли 20 USE-CASE диаграмм.
Причем в предметной области как бы должен был шарить.
"Заказчик" с умным видом покивал головой.
Начали мы делать все по диаграммам, точь-в-точь.
В общем бизнес процессы там были нарисованы, какие вообще не существовали никогда.
Аналитик через месяц "смылся".
Поставили "парня от сохи". Т.е. кто реально работал и знал все бизнес процессы "изнутри".
Он нам (программистам) "на пальцах" объяснял что и как работает.
Мы это быстро делали.

Так что "заказчик" понимает USE-CASE - это слишком оптимистичное предположение.
17 апр 19, 12:00    [21864732]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Bsplesk
p.s. Для обсуждения процесса с бизнесом к дополнению к тексту есть BPMN (гораздо человечнее UML) и для бизнеса достаточно.
Для "Общего введения" есть продающие презентации в "картинках с котиками" аля "мемы".


BPMN это вообще "АДъ и Израиль".
Потому что в лучшем случае на нем описывают "успешный сценарий".
А вот что делать при тех или иных ошибках или сбоях, обычно "забивают".

Опять же картинка получается "вумная" много квадратиков, стрелочек.
"Заказчик" делает вид, что "да так мы и работаем".
А потом "ваша программа не правильно работает!!!!!"
17 апр 19, 12:05    [21864740]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
mad_nazgul
МодальноеОкно
пропущено...

на уровне use case и диаграммы взаимодействия - вполне. ничего там непонятного нет. а остальное всё (ER, классы) бизнесу не интересно


Был у меня один проект, где аналитик нарисовал страниц то-ли 15 то-ли 20 USE-CASE диаграмм.
Причем в предметной области как бы должен был шарить.
"Заказчик" с умным видом покивал головой.
Начали мы делать все по диаграммам, точь-в-точь.
В общем бизнес процессы там были нарисованы, какие вообще не существовали никогда.
Аналитик через месяц "смылся".
Поставили "парня от сохи". Т.е. кто реально работал и знал все бизнес процессы "изнутри".
Он нам (программистам) "на пальцах" объяснял что и как работает.
Мы это быстро делали.

Так что "заказчик" понимает USE-CASE - это слишком оптимистичное предположение.


и чо?

вы собрали все паттерны "как не надо делать". теперь пытаетесь натянуть сову на глобус?
17 апр 19, 12:08    [21864746]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
mad_nazgul
BPMN это вообще "АДъ и Израиль".
Потому что в лучшем случае на нем описывают "успешный сценарий".
А вот что делать при тех или иных ошибках или сбоях, обычно "забивают".


казалось бы - причем тут нотация
17 апр 19, 12:09    [21864748]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
WebSharper
Member

Откуда:
Сообщений: 487
Bsplesk
p.s. Для обсуждения процесса с бизнесом к дополнению к тексту есть BPMN (гораздо человечнее UML) и для бизнеса достаточно.


А можете сказать в чем человечнее? Вы сравниваете голый UML или профиль для бизнес моделирования?
17 апр 19, 14:00    [21864982]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
МодальноеОкно
и чо?

вы собрали все паттерны "как не надо делать". теперь пытаетесь натянуть сову на глобус?


Идеальных заказчиков не существует.
А UML это язык который надо знать и понимать.
И надеяться на то что "заказчик" знает и понимает UML - наивно.
17 апр 19, 14:58    [21865096]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
МодальноеОкно
mad_nazgul
BPMN это вообще "АДъ и Израиль".
Потому что в лучшем случае на нем описывают "успешный сценарий".
А вот что делать при тех или иных ошибках или сбоях, обычно "забивают".


казалось бы - причем тут нотация


При том, что BPMN - это ЯП, а не нотация.
А программировать надо уметь и надеяться, что "заказчик" умеет программировать - наивно.
17 апр 19, 15:01    [21865104]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
mad_nazgul
При том, что BPMN - это ЯП, а не нотация.


не курите больше Картинка с другого сайта.
17 апр 19, 15:12    [21865127]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
ViPRos
Member

Откуда:
Сообщений: 9630
МодальноеОкно
mad_nazgul
При том, что BPMN - это ЯП, а не нотация.


не курите больше Картинка с другого сайта.

это сложный визуальный ЯП
17 апр 19, 15:39    [21865169]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul
Поэтому UML в лучшем случае используется манагерами для презентаций заказчику.
По идее в нулевых были попытки создать кодогенераторы на основе UML, но как-то "не взлетело"

На самом деле взлетело, но немного не так как тогда представляли. Есть две области где это используется:

1) Какие-то уникальные, очень большие и долговременные проекты. Например, такой. Там рисуется UML модель в соответствии с методикой. На основе модели генерятся 1) нормативные документы, которые утверждаются чиновниками, 2) XML схемы, предназначенные для разработчиков и 3) валидаторы XML документов (статья, презентация). В принципе, можно было бы ещё много всего генерить.

Тут специфика в том, что писать все эти методики, кодогенераторы и т.п. - достаточно сложное занятие. И чтобы это было оправдано, должно генериться очень много типовых документов, типового кода. Какое-то уникальное приложение конечно так не сгенерить. Но можно сгенерить какие-то типовые фрагменты. Но тут мы переходим ко второй области.


2) Какие-то очень массовые вещи. Например, есть Eclipse Modeling Framework. Он позволяет описать модель (Ecore или реже диаграмма классов UML) и генерить для неё разные вещи. 1) Тут я генерю объектную модель на Java и древовидный редактор для работы с данными, соответствующими этой модели, 2) тут добавляю ещё одну модель, описывающую визуальную нотацию для данных, и получаю визуальный редактор, 3) тут кроме визуального редактора ещё всякие таблички, 4) тут и тут я описываю в виде модели структуру абстрактных синтаксических деревьев для некоторого языка и генерю парсер, сериализатор и редактор выражений этого языка. Там ещё несколько наркоманских статей.

В каждом из этих примеров 90% работы - это нарисовать или описать текстом модель. Затем из неё генерится код и по мелочи что-то ещё дописывается.

На самом деле генерация кода из модели сейчас везде. Тот же Swagger. Там описываешь API на специальном DSL и генеришь из него 1) скелет реализации API, 2) документацию 3) пользовательский интерфейс.

На самом деле грань между визуальными языками моделирования и DSL практически отсутствует. Для того же UML уже приводили примеры текстовой нотации.
17 апр 19, 16:53    [21865337]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
Там для примера можно открыть любой процесс и посмотреть документы по процессу. Они все генерятся из UML модели.
17 апр 19, 17:01    [21865362]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
hVostt
Member

Откуда:
Сообщений: 16164
ViPRos
это сложный визуальный ЯП


тогды русский матерный вполне себе сложный лингвистический ЯП :)
17 апр 19, 17:13    [21865391]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb,

Это противоречит современному тренду "фигак-фигак и в продакшен".
Если что на тестах упадет.

А так - да. Так и предполагали, что надо программировать.
Но практика показала, что это дорого.
18 апр 19, 07:45    [21865698]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
hVostt
Member

Откуда:
Сообщений: 16164
Ares_ekb
В каждом из этих примеров 90% работы - это нарисовать или описать текстом модель. Затем из неё генерится код и по мелочи что-то ещё дописывается.


Одно непонятно. Почему этого не делать в рантайме? Если всё итак уже забивается гвоздями и затягивается болтами, да и все "рисунки" не применимы в принципе повторно.

В рантайме DSL, не? Зачем эта кодогенерация, которая уже абсолютно безбожно устарела и выглядит анахронизмом на пример повозки с лошадью. Можно обделать её золотом, поставить на крышу вайфай, но что это изменит?

Суть всех нотаций -- передача информации о сути между людьми. Если один будет рисовать человечков, а другой козликов, явно будет провал в коммуникации. Потом кому-то показалось, что из этого можно генерить кучу всего, запахло автоматизацией. Мы и сами в 2007-м году генерили БД и ПО по трёх-звенке чисто из диаграмм. Было круто, но тупо. Потому что потом допиливали, и там через пол года ничего уже не оставалось от того, что было нагенерено, а поддерживать диаграммы -- это дорогущее удовольствие, оправданное ничем кроме фана )
18 апр 19, 23:00    [21866667]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
hVostt,

не очень понял что забивается гвоздями и почему кодогенерация устарела. Например, TypeScript транслируется в JavaScript, а Sass транслируется в CSS, Kotlin может транслироваться в JavaScript. Ещё есть Xtend (так же как и Kotlin - один из вариантов улучшенной Java, на нём как-раз удобно писать кодогенераторы) - транслируется в Java код. Кодогенерация очень много где используется.

В качестве примера могу привести такую задачку. Мне нужно было запилить рисовалку моделей с веб-интерфейсом. Для этого мне на сервере были нужны Java классы для работы с этими моделями, на клиенте - JavaScript классы. Ещё мне на сервере были нужны DTO для сериализации/десериализации этих моделей в JSON. Сначала всё это писалось руками, потом оно всё усложнялось, я пытался использовать ModelMapper, для мапинга основных Java классов в DTO и обратно. В нём, если я не ошибаюсь как-раз всё делалось в рантайме и я хлебнул тогда сложностей с тем, что: 1) чтобы всё это отлаживать нужно запускать приложение, без запуска невозможно понять что куда замапится 2) оно не хило тормозило. Потом стал использовать MapStruct, в нём код для мапинга объектов генерился на этапе написания этих мапингов. Во-первых это дало существенный прирост в производительности, вот, кто-то делал сравнение. Во-вторых, стало просто на порядок проще отлаживать эти мапинги, ещё до запуска приложения можно посмотреть какой код генерится и что с ним не так - очень удобно.

А потом меня задолбало писать эти DTO, мапинги и т.п. Я запилил кодогенератор конкретно под это приложение, который из одной модели, написанной на Xcore, генерил мне абсолютно всё: 1) Java классы для работы с моделью на сервере 2) DTO 3) мапинги в оба направления 4) JavaScript классы. И наступило счастье: правишь модель и все эти тонны кода перегенирируются. Интерпретация в рантайме мне тут никак не помогла бы. Обычно люди вообще не парятся с такими вещами, проще нанять десяток студентов, которые будут делать всю эту рутинную работу.
20 апр 19, 19:07    [21867884]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

насчет дорого - всё относительно. Для примера этот транслятор из OCL в XPath (о котором писал выше) я написал где-то за месяц в первом приближении. Тут можно посмотреть старую версию. Потом я несколько раз сталкивался с ситуацией, что сгенеренные XPath работают немного не так как ожидалось. Где-то я неправильно понимал спецификацию XPath. Например, в нём есть value comparision и general comparision. Сначала было не очевидно что когда лучше использовать. Были всякие особенности с обработкой null или ошибочных значений. Грубо говоря, для OCL какое-то выражение совершенно нормально, а при трансляции в XPath оно работало не так как ожидалось. Вообще OCL и XPath очень похожи друг на друга, но есть не очевидные отличия даже в простейших вещах. Например, в OCL 4-значная логика (истина, ложь, null, ошибка) и логические операторы (and, or и т.п.) определены для всех этих значений. В XPath 3-значная логика (null неявно преобразуется в false) и к тому же недетерминированная, например, "false and error" может быть равен либо false, либо error в зависимости от реализации. Хотя в OCL это всегда будет false.

Короче, я озадачился вопросом: а где гарантия, что этот транслятор вообще работает корректно. Поначалу я конечно пытался придумывать какие-то тестовые примеры, но тестирование для лохов и я решил формально доказать, что преобразование корректно. Потратил на это года полтора, не спал, не ел, даже на хабр перестал статьи писать и всё что смог родить - это вот эту штуку. Там формальное описание абстрактного синтаксиса OCL, его системы типов, правил типизации выражений и т.п. Это примерно 1/5 из того, что я планировал сделать. Причём даже тут нужно допилить ещё много всего. Размер этой теории уже где-то под 200 страниц в последней версии.

В общем, если всякие модельно-ориентированные штуки писать дорого, то использовать в разработке формальные методы и всякий "матан" ещё раз в 100 дороже. Поэтому всё относительно.
20 апр 19, 19:31    [21867892]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
mad_nazgul,
...
В общем, если всякие модельно-ориентированные штуки писать дорого, то использовать в разработке формальные методы и всякий "матан" ещё раз в 100 дороже. Поэтому всё относительно.


Так ваш пример и показывает, что "дорого". :-)

Тот же UML или BPMN в начале что-то проектируем "на бумажке", потом пишем программу.
И тут выясняется, что логических значений больше чем 2. Как минимум три (true, false, ошибка)
А в используемом ЯП вообще штук пять (true, false, null, undifined, ошибка)
Вот и получается "испорченный телефон". Кто как понял, тот так и записал, на своем языке.

Поэтому аджайл и микросервисы сейчас "цветут пышным цветом".
Т.к. изменений происходят маленькими порциями. Всегда есть что-то хоть как-то работающее.
"Переводчиков" между заказчиком и исполнителем минимум.
Ну а микросервис не жалко переписать с нуля.
22 апр 19, 12:18    [21868743]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

все эти формальные методы не обязательно было использовать. Можно было бы нафигачить просто каких-нибудь тестов или вообще не париться с этим, как большинство и делает.

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

Есть нормативные документы, выпускаемые разными регулирующими органами - ФНС, ФТС, ЦБ, ЕЭК и т.п. Эти документы обычно пишутся и утверждаются чиновниками, возможно совместно с аналитиками - не суть важно. И они на столько далеки от реализации и вообще какого-либо кода. В лучшем случае там просто в целом описываются процессы обмена сведениями, в целом описывается состав сведений без детализации.

Затем эти документы читают аналитики, интерпретируют их в силу своего опыта, скорее всего, с ошибками. Пишут постановки для разработчиков. Разработчики всё это реализуют скорее всего тоже с ошибками. И потом оно как-то работает.


Представь, что таких процессов обмена сведениями, скажем, штук 100. В каждом процессе штук 10 видов сообщений. Для каждого сообщения 1000 правил. Получаем 1 млн. правил заполнения сообщений на все процессы. Они описываются в сотнях нормативных документов. Эти документы пишут разные подразделения регулятора, совместно с разными подрядчиками, в разные моменты времени.

Если учесть ещё, что участников взаимодействия, которые должны реализовывать все эти правила порядка 1000. То получаем, грубо говоря, 1 млрд. правил, реализованных в разных системах.


Тут возникают вопросы:

1) Как сделать, чтобы эти нормативные документы разрабатывались по какой-то единой схеме, чтобы они хотя бы внешне и по структуре были похожи друг на друга? Если в одном документе процессы будут просто описываться словами, в другом - с помощью BPMN, в третьем - диаграмм деятельности UML, в четвертом - диаграмм последовательностей UML, в пятом - EPC диаграмм, в шестом - блок-схем, в седьмом - с помощью какой-то своей нотации, которую им удобно использовать и т.п. - то будет полный хаос.

2) Как сделать, чтобы при выпуске нового нормативного документа, процесс, описываемый в этом документе, запускался максимально быстро? Как сделать, чтобы при изменении нормативки максимально быстро обновлялась и реализация?

3) Как избежать ошибок в реализации? При таком количестве процессов и правил они однозначно будут.

И есть решения:

1) Регулятор сам пишет информационную систему, где всё это реализовано. Упрощает этим жизнь пользователям. Сокращает количество ошибок, которые они наверняка сделали бы, если бы писали это сами.

2) Какая-нибудь компания пишет информационную систему и продаёт её пользователям.

3) Регулятор пишет и отдаёт в мир не просто тонны страниц бумажных документов с правилами. А создаёт и отдаёт всё это в машинночитаемом виде, в виде модели. А если есть модель, то сгенерить из неё какие-нибудь типовые формочки или валидаторы документов - это дело техники. Как и сгенерить из модели документы по единым шаблонам.



Короче, есть две крайние точки: 1) нормативка, которая вообще оторвана от реализации и 2) реализация. И между ними модель, причем гораздо ближе к 1-ому, чем ко 2-ому.
22 апр 19, 12:55    [21868781]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul
Тот же UML или BPMN в начале что-то проектируем "на бумажке", потом пишем программу.
И тут выясняется, что логических значений больше чем 2. Как минимум три (true, false, ошибка)
А в используемом ЯП вообще штук пять (true, false, null, undifined, ошибка)
Вот и получается "испорченный телефон". Кто как понял, тот так и записал, на своем языке.

Тут есть ещё один момент. Грубо говоря, лет через 10 любой ЯП устареет, появится какая-то новая, модная, супер-хрень, с которой все будут носиться.

Например, раньше для обмена данными был очень популярен EDI (EDIFACT, ASC X.12 и т.п.) - он и сейчас много где используется. Потом все стали массово переходить на XML. Потом появились всякие RDF, OWL - они используется в некоторых областях, например, ISO 15926. Сейчас все носятся с JSON. Кто-то всё это время передавал данные вообще в CSV формате и будет использовать его и дальше. За каждой из этих технологий стоит ещё какой-то стек технологий, например, по валидации передаваемых данных. Их можно бесконечно перечислять: DTD, XSD, JSON схемы, RDF/OWL схемы, SWRL, Schematron и т.п. - огромное количество языков для описания правил. И они постоянно устаревают, постоянно появляются новые. Либо одна компания использует одни технологии, другая - другие, как им взаимодействовать?

Чтобы абстрагироваться от всего этого разнообразия и нужны платформенно-независимые модели. Ты один раз описываешь всё что нужно (структуры сообщений, правила валидации, процессы и т.п.) в виде модели. А потом, пусть хоть каждый день меняются технологии - модель остается неизменной на десятилетия. Просто фигачим новый генератор под нужную платформу и всё.
22 апр 19, 13:10    [21868806]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
mad_nazgul,

все эти формальные методы не обязательно было использовать. Можно было бы нафигачить просто каких-нибудь тестов или вообще не париться с этим, как большинство и делает.

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


Скажем так. Модели нормативных документов изначально противоречивы и по ним нельзя построить универсальное-расширяемое приложение.
Попытка есть (см. 1С). Результат всем известен.
Поэтому надо писать как есть.
Т.е. писать сервис под конкретную задачу.
И безжалостно его выкидывать, если он устарел или не актуален.
22 апр 19, 15:11    [21868918]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
Чтобы абстрагироваться от всего этого разнообразия и нужны платформенно-независимые модели. Ты один раз описываешь всё что нужно (структуры сообщений, правила валидации, процессы и т.п.) в виде модели. А потом, пусть хоть каждый день меняются технологии - модель остается неизменной на десятилетия. Просто фигачим новый генератор под нужную платформу и всё.


Ага. Вот точно с такими же словами вводили SOAP.
Практика показала, что "тупой" JSON гораздо удобнее "платформенно-независимые модели" на основе SOAP (где все что вы перечислили есть).
Есть еще GraphQL и Apache Thrift.
Это никоим образом проблему не решает, а только усугубляет.

По мне, сейчас стандарт "платформенно-независимые модели" это протокол HTTP.
Все ЯП его знают, понимают, используют. И проблем с интеграцией и работой с ним нет. :-)
22 апр 19, 15:20    [21868933]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

а вам с чем удобней было бы работать?

1) С описанием вида:
Такая-то декларация должна содержать следующие сведения:
Страна происхождения товара
Дата отправки партии
Дата получения партии
Направление (импорт, экспорт)
Цель ввоза
...

И ещё по ходу документа вкрапления правил вида:
Если цель ввоза такая-то, то должны указываться такие-то сведения о транспортном средстве

И сиди думай страна - это код, краткое название, полное название или и то, и другое.
Стоит ли проверять, что дата получения не раньше даты отправки? Это правило просто забыли упомянуть или оно не нужно?
Цель ввоза указывается на уровне всей товарной партии и на уровне каждой товарной позиции. Какое именно поле имеется ввиду в правиле?
Сколько вообще правил в документе, если они идут все вперемежку? Все ли они реализованы? Правильно ли они реализованы?

2) Всё то же самое но в виде модели и со спецификацией правил на формальном языке.


1С, SOAP, HTTP - это всё технические детали. Речь о том как сделать нормативку однозначно интерпретируемой, желательно автоматически без участия человека.
22 апр 19, 15:48    [21868977]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
SOAP, GraphQL, Apache Thrift, 1С - это всё конкретные технические решения.

1С - это вообще коммерческий программный продукт. Ни один регулятор не может обязать кого-либо использовать 1С. Всё, что они могут - это описывать правила, рекомендовать какие-то стандарты, но не навязывать конкретные программные решения. 1С исключен абсолютно, но даже системы, разработанные самим регулятором - тоже не очень хорошо.

GraphQL, Apache Thrift - это тоже решения конкретных вендоров. Если регулятор будет их проталкивать везде, то моментально возникнут вопросы у антимонопольного комитета, Навального и т.п.

SOAP - лучше, потому что это международный стандарт. Он реализован множеством вендоров в их программных продуктах. Но SOAP описывает маленький кусочек того, что нужно. Процессы информационного взаимодействия не ограничиваются веб-службами. Какие-то этапы процессов выполняются в реальности (в физическом мире, а не в информационных системах), какие-то данные вносятся руками в формочки или приносятся на бумаге. Это всё не описать на SOAP. А на UML можно.


Самый сложный момент здесь - это связь между нормативкой и пусть SOAP, WSDL или чем угодно. Предметный специалист, который сидит где-нибудь в таможенной службе и пишет нормативные документы он же не будет утверждать WSDL. Ему вся эта техника вообще по барабану. Если завтра WSDL и вообще все ИТшники исчезнут, таможенные-то процессы никуда не денутся! Он как писал правила в нормативных документах, так и будет писать, товары как шли через границу, так и будут идти.

Равно как и для участников таможенных или любых других процессов технические детали по барабану. Единственное как можно оптимизировать весь этот процесс - это двигаться от неформальных "бумажных" нормативных документов к каким-то более формальным документам, к спецификациям, к моделям. А каким образом эта спецификация/модель будет реализована - это вообще вопрос десятый, может и вообще не будет реализована в виде ПО.
22 апр 19, 16:19    [21869026]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
Ares_ekb
Речь о том как сделать нормативку однозначно интерпретируемой, желательно автоматически без участия человека.

Вывести её из под влияния попильных госконтор.

Сама по себе стандартизация нужна, но не таким идиотским способом, который рожают оналитеги из попильных контор. А оналитеги (то есть и ты тоже) сегодня пишут "как умеют", интерпретируют веяния и намёки, но никакой вменяемой структуры в этих веяниях нет. Частично на своём участке некий ares_ekb может и убедит своего конкретного начальника, мол вот это - круто. Но все остальные начальники будут убеждены другими оналитками, предварительно просчитав попильные потенциалы и способы их максимизации, что оставляет оналитегам совсем микроскопическое поле для творчества.

Хотя да, работой оналитеги будут обеспечены всегда, ибо начальство меняется, попильные ветры меняются, ну и мысли в головах начальников за всем этим не успевают. Поэтому формализовать попильный бред всегда кому-то будет надо. И если это всё замутить в виде моделей, то можно даже выбиться в старшие оналитеги, мол прозрел да предсказал, вот какой полезный для начальства кадр!

В общем - есть попытка хоть как-то оформить бардак. И есть предложение - а давайте бардак смоделируем! Ну и пошла писать контора...
22 апр 19, 16:52    [21869062]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
alex55555
Сама по себе стандартизация нужна, но не таким идиотским способом
А каким?
22 апр 19, 17:11    [21869090]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
Ares_ekb
Речь о том как сделать нормативку однозначно интерпретируемой, желательно автоматически без участия человека.


сие невозможно.

"Решайте дела по правде, наши бы виноваты не были бы" (с) Иван Грозный
22 апр 19, 17:13    [21869097]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
Ares_ekb
И сиди думай страна - это код, краткое название, полное название или и то, и другое.
Стоит ли проверять, что дата получения не раньше даты отправки? Это правило просто забыли упомянуть или оно не нужно?
Цель ввоза указывается на уровне всей товарной партии и на уровне каждой товарной позиции. Какое именно поле имеется ввиду в правиле?
Сколько вообще правил в документе, если они идут все вперемежку? Все ли они реализованы? Правильно ли они реализованы?


отличный повод для судебных исков, а потом для новой нормативки с учетом судебной практики
22 апр 19, 17:18    [21869102]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
МодальноеОкно,

есть вещи, которые очень сложно или невозможно формализовать. Есть вещи, которые уже давно успешно формализуются - например, структуры электронных документов. Есть вещи, которые кто-то формализует, кто-то - нет, Например, это правила заполнения документов или процессы. Весь мир идёт этим путём. Меня лично очень радует, что в каких-то вещах мы этот весь мир опережаем.

Судебные иски никому не нужны, кроме адвокатов :)
22 апр 19, 19:04    [21869200]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
mad_nazgul,
а вам с чем удобней было бы работать?


Мне удобнее, все таки с текстовым описанием.

Ares_ekb
И сиди думай страна - это код, краткое название, полное название или и то, и другое.
Стоит ли проверять, что дата получения не раньше даты отправки? Это правило просто забыли упомянуть или оно не нужно?
Цель ввоза указывается на уровне всей товарной партии и на уровне каждой товарной позиции. Какое именно поле имеется ввиду в правиле?
Сколько вообще правил в документе, если они идут все вперемежку? Все ли они реализованы? Правильно ли они реализованы?


Опять же тут вопрос как будет реализовано.
Как минимум обычно есть печатная форма, которую надо заполнять.
Вот от нее обычно и отталкиваемся.

Ares_ekb
2) Всё то же самое но в виде модели и со спецификацией правил на формальном языке.


Зачем, когда с точно таким же результатом и затратами можно написать сервис (сделать реализацию)?!

Ares_ekb
1С, SOAP, HTTP - это всё технические детали. Речь о том как сделать нормативку однозначно интерпретируемой, желательно автоматически без участия человека.


Никак. Т.к. для разных "доменных моделей" нужна разная информация.
Даже на одном предприятии для бухгалтерии нужна одна модель, а для производства немного другая.
И в некоторых моментах они могут друг-другу противоречить/мешать.
23 апр 19, 09:58    [21869519]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
alex55555
Ares_ekb
Речь о том как сделать нормативку однозначно интерпретируемой, желательно автоматически без участия человека.

Вывести её из под влияния попильных госконтор.
...
В общем - есть попытка хоть как-то оформить бардак. И есть предложение - а давайте бардак смоделируем! Ну и пошла писать контора...


Проблема немного в другом - "нельзя объять необъятное".
Попытка сделать полную номенклатуру натыкается на то, что любой предмет в реальном мире (который отражает номенклатура) является уникальным. И его классифицировать можно как угодно. Поэтому если у вас есть два приложения, для которых нужна интеграция, есть не нулевая вероятность делать три классификатора.
23 апр 19, 10:21    [21869542]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

Не всегда можно сразу сделать реализацию. Конкретно в тех проектах, про которые писал, есть 1) регулирующая организация, которая может только задавать правила обмена (в виде обычных нормативных документов, спецификаций, рекомендаций, моделей), брать на себя ещё и реализацию она не может в силу нескольких причин и 2) есть целый ряд организаций, отвечающих за реализацию, они находятся в разных странах, у них уже есть какая-то своя инфраструктура со своим стеком технологий. Регулятору просто ни к чему брать на себя ещё и реализацию, это не его задача, да, он и не имеет права навязывать участникам какие-либо программные решения.

Насчет противоречия разных доменных моделей согласен! В этом и прикол. Если они даже в рамках одной организации не очень совместимы, то представьте на сколько они несовместимы между разными отраслями или ведомствами. Гармонизировать их между собой - это целая история. Например, некоторый груз перевозится из Китая в Польшу, я не уверен, что бывают такие автомобильные перевозки, ну, допустим. При этом груз проходит несколько видов контроля: 1) таможенный, 2) транспортный, 3) ветеринарный, ... За каждый вид контроля отвечает отдельное ведомство со своей нормативкой, причём в каждой стране это своё ведомство со своей нормативкой. Их всех интересуют разные сведения, в разном разрезе. При транспортном контроле важны общие габариты транспортного средства с грузом, нагрузки на оси. При таможенном - детальная информация по каждой товарной позиции. При ветеринарном - тоже своя специфическая информация. Причём, у них даже терминология отличается. Товар, груз, продукция - это разные роли одного и того же реального объекта. Свести всё это между собой очень непросто, но как без этого.

Насчёт текстового описания. Да, от него пока никуда не уйти. В любом случае, ни модель, ни какая-нибудь XML схема не могут быть утверждены. Но если документы, схемы и т.п. генерятся из одного источника (из модели), то они хотя бы не противоречат друг другу, они все еднинообразные, делаются по одним шаблонам, экономится куча времени на рутине.
23 апр 19, 10:43    [21869566]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul
Поэтому если у вас есть два приложения, для которых нужна интеграция, есть не нулевая вероятность делать три классификатора.

А если наверху находится отдел или организация, которая говорит, что с такого-то момента будем использовать единый гармонизированный классификатор, то на переходном этапе это возможно будет не очень удобно, но в перспективе это лучше.

Причём, классификаторы - это самое простое. Ещё элементы данных в разных системах могут называться как угодно: country_code, CodeOfCounty, cd_country_alpha2 и т.п. Агрегированные типы могут иметь какую угодно структуру. Сведения одни и те же, реальные объекты одни и те же, но в информационных системах они могут выглядеть очень по-разному.
23 апр 19, 10:53    [21869580]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
ViPRos
Member

Откуда:
Сообщений: 9630
Ares_ekb,

никому такие системы в реале нафиг не нужны
все норовят пилить свою фигню по последним высерам фаулера, мартина и т.д.
23 апр 19, 12:51    [21869733]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
ViPRos,

нужны для каких-то очень крупных интеграционных проектов, они вполне реальные, но их очень мало.

У меня есть идея и частичная реализация массового проекта на эту тему - рисовалка моделей с кодогенерацией. Но тупо нет времени, чтобы довести его до запуска. Я сейчас хочу доделать эту штуку и вернуться к моделям.
23 апр 19, 13:18    [21869765]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
mad_nazgul,Не всегда можно сразу сделать реализацию.


На этом можно заканчивать дискуссию :-)
Если нельзя сделать реализацию, значить ее нельзя описать на тьюринг полном ЯП.
Каким является всякие UML и BPMN.
23 апр 19, 13:19    [21869768]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
А если наверху находится отдел или организация, которая говорит, что с такого-то момента будем использовать единый гармонизированный классификатор, то на переходном этапе это возможно будет не очень удобно, но в перспективе это лучше.


Еще раз - "нельзя объять необъятное".
Для полной и точной номенклатуры надо чтобы любой предмет был описан данной номенклатурой, полностью как есть.
Т.е. грубо говоря любой предмет/объект должен быть в данной номенклатуре причем на всем протяжении времени.
Например та же номенклатура стран имеет кучу проблем.
Например статистика населения России за 1977 год есть или как?

Поэтому делать общую номенклатуру... Это очень увлекательное и абсолютно бесполезное занятие :-)
23 апр 19, 13:30    [21869777]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

я же пишу, что реализация не может быть сделана сразу не по каким-то техническим причинам, а по организационным. Есть 1) регулятор, который задает правила обмена информацией 2) есть организации которые отвечают за реализацию 3) есть участники взаимодействия. Между 1 и 2 просто огромная пропасть. Вопрос о том, чтобы 1 что-то реализовывал вообще не стоит. 1 может выдавать правила взаимодействия а) просто в виде "бумажного" документа или б) дополнять бумажный документ моделью. На мой взгляд, с моделью лучше.

И не нужно объимать необъятное. Но некоторые "бумажные" нормативные документы вполне можно заменить/дополнить формальными спецификациями или моделями. Если в этих моделях 1) какие-то классификаторы не будут сразу же гармонизированы 2) структуры сведений об одних и тех же объектах не будут гармонзированы, ну и невозможно сделать это одномоментно. Сначала их в принципе нужно описать в виде модели, затем гармонизировать - займёт всё это годы и десятилетия. Но всё равно другого пути нет.
23 апр 19, 14:33    [21869828]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
mad_nazgul,я же пишу, что реализация не может быть сделана сразу не по каким-то техническим причинам, а по организационным.


Если нельзя сделать, значит их нельзя сделать.
Тогда зачем их переводить на "птичий язык" UML/BPMN, когда можно оставить на естественном языке?
Который как раз и предназначен для выражения "нечетких"/"неоднозначных" вещей.

Т.к. данные не полны, то их нельзя описать формально.
Даже модель построить проблематично.
Точнее при недостатке информации модель не получиться непротиворечивой.

Насчет опыта "гармонизации" и построения моделей, можно посмотреть, например, в сторону SAP, давно занимаются.
Но все равно при каждом внедрении случается регулярно случается веселое приключение. Когда реальность никак не хочет ложиться в прокрустово ложе "универсальной" модели.
23 апр 19, 15:11    [21869867]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

SAP, 1С и т.п. - это совершенно другая история. Они реально пытаются сделать какую-то универсальную модель, которая должна адаптироваться под специфику каждой отдельной компании.

Есть куча компаний со своей нормативкой, своими особенностями законодательства в их отрасли или в их стране в целом. А SAP с 1С - универсальные программные продукты с заложенной в них универсальной моделью, которые должны адаптироваться под всю эту специфику. Понятно, что при каждом внедрении всё это нужно очень сильно допиливать.

В проектах же, про которые я говорю, ситуация прямо противоположная. Там нет цели сделать универсальную модель, которая подходила бы под разную нормативку. Всё ровно наоборот - сначала делается универсальная, гармонизированная модель, в которой сведения об организации структурируются таким-то образом, сведения об адресах, о транспортных средствах, продукции и т.п. - таким-то. И уже в соответствии с этой единой моделью фигачится нормативка.

Таких проектов в мире полно:
https://www.niem.gov/
https://www.iso20022.org/
https://www.unece.org/cefact/codesfortrade/unccl/ccl_index.html
https://eomi.eaeunion.org
и они вполне успешные, поэтому всё возможно и давно делается.
23 апр 19, 15:44    [21869904]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
Ares_ekb
Понятно, что при каждом внедрении всё это нужно очень сильно допиливать.


не обязательно. в мире 1с есть понятие "отраслевая конфигурация" - там более глубокое следование нормативки различных резуляторов
23 апр 19, 18:14    [21870039]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
Таких проектов в мире полно:
https://www.niem.gov/
https://www.iso20022.org/
https://www.unece.org/cefact/codesfortrade/unccl/ccl_index.html
https://eomi.eaeunion.org
и они вполне успешные, поэтому всё возможно и давно делается.


Э-э-э-э вы вообще знаете зачем в 90-е - 00-е внедряли SAP?!
Для прохождения сертификации по стандартам ISO.
Потому что все эти стандарты, без реализации, всего лишь набор букв, понятный только "избранным".
А вот когда начинают вводить данные стандарты, то начинают всплывать "нюансы", которые портят идеальную картину мира, в плоть до ее полного отрицания.
24 апр 19, 07:11    [21870253]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

SAP или 1С решают внутренние задачи предприятия: учет, автоматизация процессов. Видимо, если все процессы предприятия прорисованы в SAP, то оно может пройти сертификацию по каким-нибудь стандартам управления качеством и т.п.

Стандарты, про которые я пишу, вообще не имеют отношения к внутренней кухне предприятия. Есть, например, ISO 20022 - стандарт обмена финансовыми сообщениями. Если предприятию нужно совершать платежи или обменивать ещё какой-то информацией с финансовыми организациями, то оно может передавать соответствующее сообщение. У SAP есть модуль, который может формировать эти сообщения ISO 20022.

И никаких нюансов тут быть не может. Внутри компании они могут вносить всё что угодно в каком угодно формате. Но когда обмениваешься с внешним миром будь добр использовать общие стандарты. Вся эта нормативка и модели, про которые я пишу, они не касаются внутренней кухни организаций, они описывают только взаимодействие между организациями.
24 апр 19, 08:32    [21870288]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Serguei
Member

Откуда: Papua New Guinea
Сообщений: 683
Ares_ekb
SAP, 1С и т.п. - это совершенно другая история. Они реально пытаются сделать какую-то универсальную модель, которая должна адаптироваться под специфику каждой отдельной компании.

Есть куча компаний со своей нормативкой, своими особенностями законодательства в их отрасли или в их стране в целом. А SAP с 1С - универсальные программные продукты с заложенной в них универсальной моделью, которые должны адаптироваться под всю эту специфику. Понятно, что при каждом внедрении всё это нужно очень сильно допиливать.


Сорри, что встреваю в беседу, но похоже вы слабо владеете информацией по SAP. Концепция SAP проста: если ваши процессы не подходят под программные возможности SAP, то они признаются "неправильными" и их нужно изменить под стандарты SAP. Вся "универсальность" как вы сказали в SAP заключается именно в этом. Им наплевать на "специфику каждой отдельной компании" , и если ваши бизнес процессы были просты и понятны, то с SAP они станут громоздкими и неуклюжими, с лишними шагами, потому что так захотел этот монстр.
24 апр 19, 10:42    [21870354]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
Serguei,

да, я ни SAP, ни 1С никогда не занимался, только какое-то общее представление. В 1С по-моему всё менее категорично, ставятся базовые конфигурации, потом допиливаются под нужды компании. Странно, что в SAP это по-другому...

Видимо, из-за того что мы говорим про разные вещи и развивается эта дискуссия. Все стандарты, модели, нормативные документы, про которые я пишу, касаются только взаимодействия между компаниями или государственными органами (B2B, B2G, G2G), но никак не затрагивают внутренние процессы. И это ключевой момент. Ровно по этой причине не может быть никакой универсальной программной реализации. Потому что у каждой компании, в каждой стране используются свои программные продукты, свои технологии. И максимум на чём может закончиться формализация нормативки - это модель или спецификация. А всё, что касается реализации - это дело уже каждой компании. По этой же причине регулятор не может разрабатывать какие-то универсальные интерпретаторы для правил заполнения документов. Максимум - это несколько кодогенераторов под разные платформы, причём каждая компания сама решает: 1) использовать им сгенеренный код, 2) взять модель и самим что-то сгенерить из неё или написать интерпретатор или 3) просто взять нормативные документы без модели и сделать всё по ним вручную.

Хотя нормативка на внутренние процессы тоже существует, видимо это что-то из области сертификации, но я никогда этим не занимался.
24 апр 19, 11:04    [21870369]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
Serguei,
Видимо, из-за того что мы говорим про разные вещи и развивается эта дискуссия. Все стандарты, модели, нормативные документы, про которые я пишу, касаются только взаимодействия между компаниями или государственными органами (B2B, B2G, G2G), но никак не затрагивают внутренние процессы. И это ключевой момент.


Мы говорим про одно и то же.
Т.к. я тот самый программист который реализует все эти B2B, B2G, G2G.
И говорю про свой опыт.
Обычно аналитики рисуют красивые презентации.
А потом нам (программистам) приходиться находить контакты друг с другом, и реализовывать, чтобы работало, а не как "нарисовано".
Обычно приходиться строить 3 (три) доменных модели.
1) Поставщика данных
2) Получателя данных
3) Модель преобразования из одной модели в другую
24 апр 19, 12:54    [21870458]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul
Обычно приходиться строить 3 (три) доменных модели

Это в том случае если в этой области ещё нет стандартных (общих) моделей для обмена сведениями. У каждого участника своя модель. И для каждой пары участников делаются мапинги моделей. Но со временем участники организуются, создают комитет, который отвечает за разработку этой единой модели и совместными усилиями, путем гармонизации множества своих частных моделей создают единую модель.

После этого каждому участнику достаточно мапить свою модель на единую. Если это не так и всё равно каждый участник с каждым продолжают договариваться напрямую, значит стандарт не работает. Значит этим участникам нужно активней участвовать в разработке единой модели.
24 апр 19, 14:11    [21870557]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
Ares_ekb
alex55555
Сама по себе стандартизация нужна, но не таким идиотским способом
А каким?

Оптимизировать нужно сверху. Надеюсь столь тривиальное правило не вызывает возражений? И если нет - ну так где же тот "верх", который реально оптимизирует? А нету верха. Оптимизируют под себя все подряд особо модные рогозины и прочие табуреткины.

Бесконечное количество возможностей открывает всего лишь простейшее сведение данных о населении в единую базу, и где оно? Возможно будет лет через 100. И это самое простейшее сведение данных в одно хранилище. Самое простейшее. И оно будет только через 100 лет. И на этом фоне имеем разговоры про какие-то модели. Простейшие данные никто и, по сути - никогда, не соберёт, а уже про модели разговариваем.

Когда надо показать бурную деятельность - да, за все эти модели тут же ухватятся и будут махать как флагом. Но суть этой деятельности примерно как и у махания флагом - разгонять воздух. Прикрыть попил умными словами - это польза, не спорю. А всё остальное - сплошной пар в свисток. Иногда где-то локально по странному стечению причудливых обстоятельств кому-то это принесёт пользу, но в среднем по стране это всего лишь очередная причуда, под которую вся страна будет в очередной раз привычно подстраиваться и материть того выдумщика, который опять заставил их всё и вся переделывать.

Ну и выход - менять тех, кто в принципе не способен на оптимизацию сверху. Под корень. Всех.
24 апр 19, 14:46    [21870602]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
alex55555
Бесконечное количество возможностей открывает всего лишь простейшее сведение данных о населении в единую базу, и где оно? Возможно будет лет через 100. И это самое простейшее сведение данных в одно хранилище. Самое простейшее.


самое простейшее - есть. база юр. лиц. по ней декларация проверяется ндс и т.п. сервисы

к чему эти истерики?
24 апр 19, 15:19    [21870659]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
alex55555
Ну и выход - менять тех, кто в принципе не способен на оптимизацию сверху. Под корень. Всех.


на кого?

у нас нет конкуренции, тем более для "манагеров" такого уровня. а вновь избранные такие эксперименты на населении ставить начнут - через 5-10 лет стонать начнут о счастливом путинском застое
24 апр 19, 15:22    [21870664]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
alex55555,

я не могу согласиться с тем, что всех нужно посадить в гулаг, уволить, расстрелять или хз что и наступит счастье :)

"Верх" в лучшем случае может создать условия для появления стандартов, моделей: разработать методику, предоставить какую-нибудь платформу, инструменты. Вот, например, американская Национальная модель обмена информацией (NIEM). Изначально Министерство юстиции США пилило для своих личных нужд модель данных. Затем они создали совместный с Министерством внутренней безопасности проект NIEM. Стали активно разрабатывать методические документы, инструменты, предоставили к этой модели свободный доступ. К ним стали подключаться другие ведомства. Любая частная компания может взять эту модель и что-то разрабатывать на её основе. Сейчас она объединяет уже полтора десятка предметных областей. Не пришёл кто-то умный сверху и не дал им готовую модель. Они сами организовались и создали её.

ISO 20022 - совершенно аналогично создаётся совместными усилиями SWIFT и разных финансовых организаций или регуляторов в финансовой сфере.

Я вообще не знаю ни одного стандарта, который возник бы откуда-то сверху. Всегда есть группа инициативных частных компаний или ведомств, которые организуются и создают стандарты.

А кому и зачем нужна единая база населения? Все эти стандарты и модели делаются для решения конкретных задач. Будет запрос на это - будет и база. Мне лично не хотелось бы, чтобы меня включали в какую-то единую базу :)
24 апр 19, 15:35    [21870688]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
Ares_ekb
А кому и зачем нужна единая база населения? Все эти стандарты и модели делаются для решения конкретных задач. Будет запрос на это - будет и база. Мне лично не хотелось бы, чтобы меня включали в какую-то единую базу


мы там уже есть - инн же всем выдали
24 апр 19, 15:54    [21870722]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
МодальноеОкно,

Представляю, сменится власть, и из этой базы всем онолитегам типа меня, грабящим бюджет, будут автоматически приходить приглашения в гулаг :)

Реестр налогоплательщиков не совсем единый, там банально нет сведений о штрафах ГИБДД, об образовании, семейном положении и т.п. Вообще, что меня удивляет в работе налоговой службы, это то, что налоги и штрафы ты платить обязан, а, вот, получение льгот - это всего лишь твоё право. Мне налоговая просто выела мозг совершенно не обоснованными штрафами. Но проще заплатить эту тыщу рублей и забыть. А что мешает налоговой так же рьяно давать людям, скажем, налоговые вычеты за медицинские услуги. Ведь, вся эта информация об оплате услуг, уж, тем более в медицинских учреждениях собирается. Вообще ничего не стоит автоматически делать вычет, это ничем не сложнее, чем высасывать штрафы из пальца. Но хрен.
24 апр 19, 16:08    [21870737]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
ViPRos
Member

Откуда:
Сообщений: 9630
Ares_ekb,

что бы подтвердить право надо представить кучу бумаг
мне положено не платить налог на недвижимость, посмотрел на список доков, плюнул и плачу налог пока есть деньги
24 апр 19, 16:13    [21870746]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
Ares_ekb
об образовании


кому это может быть интересно в наше время?
24 апр 19, 16:16    [21870751]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
Ares_ekb
А что мешает налоговой так же рьяно давать людям, скажем, налоговые вычеты за медицинские услуги.


а кто будет оплачивать эту "активность"? штраф - это деньги которые государство можно направить на свои нужды. а вычеты, да еще живыми деньгами
24 апр 19, 16:18    [21870753]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
ViPRos
Ares_ekb,

что бы подтвердить право надо представить кучу бумаг
мне положено не платить налог на недвижимость, посмотрел на список доков, плюнул и плачу налог пока есть деньги


п.э. и если заморачиваются с этим - то по крупному, ипотека там... да и то кто работает в белую и не за копейки
24 апр 19, 16:20    [21870754]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Bsplesk
Member

Откуда:
Сообщений: 126
Ares_ekb
mad_nazgul
Обычно приходиться строить 3 (три) доменных модели

Это в том случае если в этой области ещё нет стандартных (общих) моделей для обмена сведениями. У каждого участника своя модель. И для каждой пары участников делаются мапинги моделей. Но со временем участники организуются, создают комитет, который отвечает за разработку этой единой модели и совместными усилиями, путем гармонизации множества своих частных моделей создают единую модель.

После этого каждому участнику достаточно мапить свою модель на единую. Если это не так и всё равно каждый участник с каждым продолжают договариваться напрямую, значит стандарт не работает. Значит этим участникам нужно активней участвовать в разработке единой модели.


Сумбур.
Сейчас - это делают в рамках DDD и микросервисов на более приземлённом уровне.
Выделяют условные бизнес объекты (считай высокоуровневая модель - которую могут вести просто в Excel/Confluence).
Часто один бизнес объект = один сервис*.
К примеру условная "банковская карта" - и набор всевозможных операций над ней (не только CRUD, а всё, что нужно бизнесу). Далее все это стекается в общее API - зашел "жмакнул" в карты и сразу все операции (и соответствующий контракт сервиса в том числе для генерации обвязки - нет генератора под ваш язык - не беда, просто используйте http вызовы/запросы), "жмакнул" еще раз и видишь всех подписчиков (потребителей) [зависимости], при желании просмотр цепочек, рядом статистика вызовов, тайминги и соответствующая цена сервиса (в идеале с привязкой к бизнес процессам) - удобно и понятно (всё это уже было в "шинах", но контейнерезация/виртуализация даёт свои плюсы в виде выбора разного стека - хотя на деле это больше минус - выгода копейка, а поддержание это "барахла" $ - но это сродни страховки, так сказать задел на будущее).

Самое сложное тут - выделение тех самых объектов (по факту моделей), как только кол-во полей переваливает за 100-5000-10000, а конкретному потребителю нужно получить несколько "частичек" разных объектов желательно за один запрос - приходит понимание, что работа с жёстко (валидацию никто не отменял) описанным объектом (схемой/моделью) должна быть гибкой (Odata/GraphQL/или просто своя реализация на REST) [испаряются задачи по правки кучи маппингов на интеграции] + "композитники" (эволюционирует в engine/ORM) - всё это уже было - ORMмам и языкам 100 лет в обед - таже Jira имела и имеет поддержку "очеловеченного" JQL (Сейчас + запилили CQL для любителей JSON/REST - опять же "ближе к народу", проще).

Что касается UML - никуда он не делся и отдельные его части прекрасно дополняют текст в ТЗ, а вот для генерации применяется всё реже, т.к. при описании концептуальных моделей в UML можно словить непонимание (тоесть быть "далеко от народа"), куда проще родимый и всем понятный (бизнес) "эксельничек" или страничка в Confluence, для разработчиков xsd=готовые классы через минуту, ну а перевод концептуальной модели из Excel/Confluence пока в ручном режиме или с написанием "наколеночных конвертеров" - т.к. вчера, сегодня xsd, завтра Swagger, вечером graphql/odata ...

Как только появляется "простое" API - тут же возникает магазин по продажи доступа к нему и возникает совершенно иной уровень интеграции и возможностей.
25 апр 19, 00:05    [21871031]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
ViPRos
Member

Откуда:
Сообщений: 9630
Bsplesk,

Еще круче сумбур.
25 апр 19, 00:30    [21871041]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
Bsplesk,

а теперь представь, что таких компаний тысяча, у каждой уже реализованы какие-то системы, у кого-то микросервисы, у кого-то монолиты, у кого-то вообще непонятно что написанное 30 лет назад, у кого-то ничего. Более того, эти компании находятся в разных странах с разным законодательством. И у них даже криптографические стандарты разные! А, ведь, данные при передаче нужно как-то подписывать или шифровать. Все эти программы сертифицируются разными органами.

И над всем этим стоит регулирующая организация, которой нужно, чтобы все эти компании могли как-то обмениваться между собой информацией. Понятно, что вариант "давайте все эти тыщи систем перепишем на микросервисах и GraphQL" не реален. И зачем вообще это нужно, пусть они используют у себя внутри всё что угодно, главное чтобы наружу выдавали данные в понятном для других формате.

Причём, сами данные, которые передаются, они же не хранятся где-то в одном месте. Нельзя написать один REST сервис, к которому люди будут обращаться. Все эти данные распределены между этими тыщами компаний. У кого-то будет OData, у кого-то - нет.

Насчет модели, лично у нас это не просто диаграмма классов UML. Там запилен профиль с кучей стереотипов, с кучей дополнительных атрибутов (человеческое название элемента, определение, идентификатор и т.п.), с кучей правил валидации модели. На выходе из модели можно генерить всё что угодно: 1) описание модели в виде нормативного документа, 2) xsd, 3) xslt, 4) Java, 5) перечень элементов в Excel. Кстати, Excel, действительно, один из самых популярных форматов для представления модели данных! Абсолютно у всех моделей, с которыми я плотно работал (NIEM, ISO 20022, WCO DM, UN/CEFACT CCL, EAEU DM) есть выгрузка элементов и типов данных в Excel. Но с другой стороны во всех этих случаях модель изначально рисуется на UML или в виде Ecore-модели.
25 апр 19, 08:10    [21871167]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
И зачем вообще это нужно, пусть они используют у себя внутри всё что угодно, главное чтобы наружу выдавали данные в понятном для других формате.


Это уже давным давно есть - HTTP протокол.
Понятный всем формат. Работает надежно. Все его понимают. :-)
25 апр 19, 08:47    [21871189]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

вам нужно передать таможенную декларацию по протоколу HTTP. Откуда вы узнаете 1) какая у неё должна быть структура, 2) что она соответствует всем правилам из нормативки (что в ней заполнены все нужные реквизиты для данной цели ввоза товаров и т.п.)? Чтобы получатель смог вообще понять, что содержится в этом документе, и чтобы не отправил её обратно с сотней ошибок, которые нужно исправить?
25 апр 19, 10:11    [21871271]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
mad_nazgul
Это уже давным давно есть - HTTP протокол.


щито?

кому понятный? это транспорт
25 апр 19, 10:17    [21871274]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
МодальноеОкно
mad_nazgul
Это уже давным давно есть - HTTP протокол.


щито?

кому понятный? это транспорт


Транспорт это TCP/IP ;-)
А это протокол.
Который имеет структуру которая понятна всем, и через него можно передать любую информацию, которая будет понятна всем.
25 апр 19, 11:44    [21871413]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
mad_nazgul,

вам нужно передать таможенную декларацию по протоколу HTTP. Откуда вы узнаете 1) какая у неё должна быть структура, 2) что она соответствует всем правилам из нормативки (что в ней заполнены все нужные реквизиты для данной цели ввоза товаров и т.п.)? Чтобы получатель смог вообще понять, что содержится в этом документе, и чтобы не отправил её обратно с сотней ошибок, которые нужно исправить?


Зачем?!

Принимающая сторона должна фильтровать данные которые получает.
На ее стороне происходит ФЛК.
Так что ошибки - это нормально.

Кроме того "принятие" таможенной декларации может быть реализовано кучей способов.
Начиная от скана декларации, заканчивая сложным SOAP-сервисом.
И скан декларации это не самый плохой способ. Как минимум для него будет бумажный оригинал, который ему соответствует с подписью и печатями. ;-)
25 апр 19, 11:59    [21871436]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
ViPRos
Member

Откуда:
Сообщений: 9630
mad_nazgul
МодальноеОкно
пропущено...


щито?

кому понятный? это транспорт


Транспорт это TCP/IP ;-)
А это протокол.
Который имеет структуру которая понятна всем, и через него можно передать любую информацию, которая будет понятна всем.

ерунду гришь
25 апр 19, 12:08    [21871455]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

Для подписи электронных документов есть электронная подпись, за окном 2к19 вообще-то :)

Т.е. вы предлагаете

1) отправлять невалидные документы, получать список ошибок, править документ по этому списку и отправлять снова?

2) а лучше вообще обмениваться сканами документов, чтобы получатель не мог их провалидировать, не присылал этот список ошибок, тогда и править ничего не надо? :)

Ок, в каких-то областях это может работать. В других - каждый такой невалидный документик может превратиться в судебные иски и штрафы.
25 апр 19, 12:12    [21871459]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
МодальноеОкно
у нас нет конкуренции, тем более для "манагеров" такого уровня. а вновь избранные такие эксперименты на населении ставить начнут - через 5-10 лет стонать начнут о счастливом путинском застое

То есть оставим всё как есть и будем славить путина?
25 апр 19, 12:53    [21871540]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
mad_nazgul
МодальноеОкно
пропущено...


щито?

кому понятный? это транспорт


Транспорт это TCP/IP ;-)
А это протокол.
Который имеет структуру которая понятна всем, и через него можно передать любую информацию, которая будет понятна всем.


вы несете херню
25 апр 19, 13:07    [21871569]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
Ares_ekb
"Верх" в лучшем случае может создать условия для появления стандартов, моделей: разработать методику, предоставить какую-нибудь платформу, инструменты.

Если исходить из либеральных догматов - да, верха вообще быть не должно, всё должен решать некий невидимый "бизнес". Ну а на самом деле втихушку всё будет решать группа ворюг, примерно как мы сегодня и наблюдаем. А оболваненные такой пропагандой будут свято верить, что "только так, и не иначе!", ведь мы что, майдан хотим, что ли?

И есть масса альтернативных примеров, где либеральную уйню послали куда-нибудь в гулаг и просто спланировали потребности страны.

Здесь важно понять одно - если кто-то считает себя сытым и довольным при путине, то он никогда не примет плановый подход, поскольку такой подход может пойти вразрез с установкой на сытость "как при путине". При этом чаще это всего лишь детский страх неизвестности, а не реальная опасность, но сытые предпочитают железные гарантии, то есть путина. А что будет лет через 5-10 - сытых не волнует, у них горизонт планирования - до ближайшей поездки на очередной подогрев пуза на канарах.
Ares_ekb
Вот, например, американская Национальная модель обмена информацией (NIEM). Изначально Министерство юстиции США пилило для своих личных нужд модель данных. Затем они создали совместный с Министерством внутренней безопасности проект NIEM. Стали активно разрабатывать методические документы, инструменты, предоставили к этой модели свободный доступ. К ним стали подключаться другие ведомства. Любая частная компания может взять эту модель и что-то разрабатывать на её основе. Сейчас она объединяет уже полтора десятка предметных областей. Не пришёл кто-то умный сверху и не дал им готовую модель. Они сами организовались и создали её.

Я ещё круче пример знаю - сначала была пустота, потом появился свет, потом появилась темнота, потом появились камни, вода, и прочая химия, потом в этом всём завелась живность, и вот сегодня даже двуногие обезьяны имеются, которые думают, что они цари природы. Вот какой прекрасный прогресс в мире произошёл! И всё само! Ну и что, если десятки миллиардов лет на это надо? Зато путин будет счастлив до скончания дней! Ну и сытые будут на своё счастье надеяться. Правда надежды не оправдаются, но зато как прекрасен мир безделья и праздности пока мы можем им наслаждаться!!!
Ares_ekb
Я вообще не знаю ни одного стандарта, который возник бы откуда-то сверху.

Да, маразм крепчает...

Читаем хотя бы про ГОСТы.
Ares_ekb
А кому и зачем нужна единая база населения?

Ты вот наверняка недвижимость покупал/продавал? Встречался с необходимостью её проверять? Но сам же говоришь - нахрен базы нужны. Вот и плати за риск потери собственности.
25 апр 19, 13:11    [21871571]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
Ares_ekb
Представляю, сменится власть, и из этой базы всем онолитегам типа меня, грабящим бюджет, будут автоматически приходить приглашения в гулаг :)

Приглашения пока что приходят отдать побольше денег любимому путину. И детские страхи мешают подумать об альтернативах.
25 апр 19, 13:12    [21871574]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
alex55555
МодальноеОкно
у нас нет конкуренции, тем более для "манагеров" такого уровня. а вновь избранные такие эксперименты на населении ставить начнут - через 5-10 лет стонать начнут о счастливом путинском застое

То есть оставим всё как есть и будем славить путина?


ну у нас две модели - "застой" и "революция"

ввп уже забронзовел и система близится к точке преобразований. просто они все проходят на шкуре обывателей, причем болезненно... не все хотят проходить 1917-ый заново
25 апр 19, 13:12    [21871576]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
Ares_ekb
Насчет модели, лично у нас это не просто диаграмма классов UML. Там запилен профиль с кучей стереотипов, с кучей дополнительных атрибутов (человеческое название элемента, определение, идентификатор и т.п.), с кучей правил валидации модели. На выходе из модели можно генерить всё что угодно: 1) описание модели в виде нормативного документа, 2) xsd, 3) xslt, 4) Java, 5) перечень элементов в Excel. Кстати, Excel, действительно, один из самых популярных форматов для представления модели данных! Абсолютно у всех моделей, с которыми я плотно работал (NIEM, ISO 20022, WCO DM, UN/CEFACT CCL, EAEU DM) есть выгрузка элементов и типов данных в Excel. Но с другой стороны во всех этих случаях модель изначально рисуется на UML или в виде Ecore-модели.

Вообще, здесь имеет место посыл о стандартизации обмена данными и предлагается принять за основу формат EMF.

Вопрос - чем хуже XML? Или другие форматы? Валидация и прочее прикручивается и к ним.

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

Когда нужна кувалда и есть что-то похожее на кувалду (например - кирпич), то многие порываются хватать кирпич и уячить, уячить, уячить...

Но все мы знаем, что кувалдой элементарно удобнее, долговечнее, надёжнее и т.д.

Но некоторые упрямо тянутся за кирпичом. Просто кирпич есть, а кувалды нет. Кувалду делать надо, а путин её делать не будет, поэтому давайте забивать всё кирпичами! Отличный подход, путину бы понравилось.
25 апр 19, 13:21    [21871592]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
МодальноеОкно
просто они все проходят на шкуре обывателей, причем болезненно... не все хотят проходить 1917-ый заново

Есть и третий путь - подумать головой.

И когда включается голова, то сразу находятся пути без 17-го года, без адских болей и шкуры обывателя.

Знаний уже нагенерировали огромное количество - бери да пользуй. Но нет, всё о несчастной шкуре обывателя разговоры разговаривают. Как будто сто лет с той поры не прошло и абсолютно никаких новых знаний не появилось.
25 апр 19, 13:25    [21871603]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
МодальноеОкно
Member

Откуда:
Сообщений: 2583
alex55555
Есть и третий путь


нету у нас третьего пути

у нас два состояния - застой и революция
25 апр 19, 13:27    [21871606]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mayton
Member

Откуда: loopback
Сообщений: 42897
Я для себя иногда рисую sequence diagram.
25 апр 19, 15:04    [21871748]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
alex55555
Вообще, здесь имеет место посыл о стандартизации обмена данными и предлагается принять за основу формат EMF.

Вопрос - чем хуже XML? Или другие форматы? Валидация и прочее прикручивается и к ним.
Нет, в этом и идея. Все эти XML, RDF, JSON, стандарты семейства EDI и остальные - тлен. Они бесконечно сменяют друг друга, сегодня модно одно, завтра другое. То же самое касается и языков для валидации документов - Schematron, ЯП общего назначения и т.п.

Идея в том, чтобы описывать структуру документов и правила заполнения в платформенно-независимом виде - либо в виде UML модели, либо на специально разработанном языке моделирования. Например, для ISO 20022 есть два варианта: UML модель и специально разработанный ими язык. Оба варианта обладают своими +/-, это большая отдельная тема.

Если сегодня для обмена используется XML - ок, генерим из модели XSD и XSLT для валидации. Если завтра будет использоваться JSON - ок, сгенерим JSON схемы и какой-нибудь Java код для правил ФЛК. Если понадобится хранить документы в нормализованном виде в базе данных (разложенном по табличкам, а не одним XML) - ок, сгенерим схему данных и ФЛК на SQL. Вот, кстати, делал когда-то давно демонстрацию генерилки схемы данных из модели ЕАЭС:



Более того, ту же схему базы данных можно сгенерить из модели множеством способов:
1) разные схемы именования таблиц, столбцов (CamelCase, snake_case и т.п.)
2) разные степени нормализации данных и способы раскладывания их по таблицам (на видео на 20 секунде видны параметры) - простые реквизиты составного типа можно складывать в одну табличку, можно каждый реквизит - в отдельную, можно делать это в зависимости от обязательности реквизита (если он опциональный, то складываем в отдельную табличку, чтобы избежать NULL - 6НФ). Связи между сущностями тоже можно просто делать внешним ключом, можно выносить в отдельную таблицу.

Короче, вариантов дофига. Смысл в том, что в модели всё это представлено в универсальном (платформенно-независимом виде). И эта модель на десятилетия, она вообще не зависит от конкретного выбора технологий. А из модели уже можно фигачить артефакты (XSD, схемы данных и т.п.) под любую нужную платформу. Ещё и с кучей параметров.


Насчет Путина и отдыха на Канарах. Я вообще в отпуске заграницей был один раз в жизни в Турции ещё по старому курсу доллара. Но дело не в Путине, просто хочется заниматься интересными вещами, а не зарабатывать какие-то большие деньги. У меня пока не получается совмещать эти вещи, есть 3 работы:
1) очень тупая работа - всякие учетно-аналитические системы, их можно делать левой ногой с закрытыми глазами, вообще не напрягая мозг, но зато это приносит больше всего денег
2) более интеллектуальная работа, связанная со всякими моделями и т.п., но зарплата почему-то в 5 раз меньше
3) и всякие просто гениальные штуки, разумеется бесплатные
Если свержение Путина как-то поможет мне совместить всё это в одной работе, то я за :)
25 апр 19, 15:30    [21871782]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
Ares_ekb
Идея в том, чтобы описывать структуру документов и правила заполнения в платформенно-независимом виде - либо в виде UML модели, либо на специально разработанном языке моделирования.

Структуру описывают множеством способов. Есть UML, есть XSD, есть ER схемы, есть и куча всего остального. О какой-то платформной зависимости ни в одном из этих случаев речи не идёт. Потому что на любой платформе например xml будет всё тем же набором байт. Значит какие-то слова про платформо-независимость здесь вообще не к месту.

Другое дело обычный стандарт. Если налоговая выдаёт приказ №ХХХ с описанием формата принимаемых ею документов - это уже стандарт. Формат бинарного хранения стандарта при этом может быть любым, ибо нет того самого "верха", который бы сказал, что пользуем только "вот это". Конкретный формат EMF точно так же ложится на весь этот зоопарк в виде очередной животины, которую все будут вынуждены кормить с рук (то есть мануально настраивать свой обмен в очередном формате).

При этом правила описания стандарта могут быть лишь двух типов - произвольные и фиксированные. Произвольные - это ворд и прочие эксели. Фиксированные - это когда для используемых терминов есть вменяемая трактовка, а сами термины не позволяется использовать произвольно. Всё, более никакого разнообразия нет.

Фиксированный формат далее делится на миллион доморощенных "схем", включая EMF и всё остальное. Ну и вот мы видим предложение начать всё с EMF, типа круто. А всё то, что выше написано (и вообще-то важнее узко заточенного формата) тупо игнорируется. Ну и результат будет всё тем же - зоопарк расширится, попил пойдёт шустрее, а толку практически не будет.

Я понимаю, что есть молодое желание продвинуть своё понимание, но проблема в том, что понимание-то тоже детское. Просто очередной формат, очередной зверь в зоопарке. Ну да, ещё чсв у кое-кого почешется, ибо нравящийся ему формат кого-то нагнут использовать. Вот и все радости.
Ares_ekb
Если сегодня для обмена используется XML - ок, генерим из модели XSD и XSLT для валидации. Если завтра будет использоваться JSON - ок, сгенерим JSON схемы и какой-нибудь Java код для правил ФЛК. Если понадобится хранить документы в нормализованном виде в базе данных (разложенном по табличкам, а не одним XML) - ок, сгенерим схему данных и ФЛК на SQL.

Разного рода преобразования форматов мало кому интересны. Они по сути тривиальны, а потому - ну что тут вообще обсуждать? Как camelized в underscored перевести? Охренительно глубокая тема! Правда только для детского сада.
Ares_ekb
Смысл в том, что в модели всё это представлено в универсальном (платформенно-независимом виде). И эта модель на десятилетия, она вообще не зависит от конкретного выбора технологий.

Ещё как зависит. EMF должен кто-то читать. Значит ему нужен парсер. Модели документов надо рисовать - нужен редактор. Преобразования форматов надо делать - нужны преобразователи. И т.д.

Это всё в каком-то виде есть в виде плагинов к эклипсине, поэтому по сути просто предлагается взять именно этот набор инструментов. То есть мало того, что новая зверюга заводится в зоопарке, но к ней ещё и специальные мётлы, скребки и прочий хлам прикручивается.

Вот сочиняет молодёжь новые ЯП чуть ли не каждый день, а зачем? Примерно то же самое и имеем и с очередным форматом. Из плюсов у него только поддержка плагинами в эклипсине. При этом поддержка не особо документированная. То есть теоретически плагинов тьма, но практически с кучей из них просто дороже разбираться, чем написать аналог. Так что плюсов не густо. А из минусов - всем надо учить не только новый формат, но и очередной зоопарк плагинов к эклипсине. А если люди вообще на сях пишут? И куды крестьянину податься?
Ares_ekb
всякие просто гениальные штуки

Скромный гений, ничего не скажешь...
Ares_ekb
Если свержение Путина как-то поможет мне совместить всё это в одной работе, то я за :)

После свержения путина будет централизованная выработка решений по информационной инфраструктуре государства, поэтому на таком довольно большом уровне модельный подход обязательно будет использоваться. Но не в его сегодняшнем виде, а в существенно расширенном. Ну и спрос на специалистов в этой области будет, разумеется.

Вообще глубокие исследования возможны только при наличии большого масштаба и качестве организации работ. При путине ни масштаба ни качества. Отсюда вывод - ну какая глубина возможна при путине?
26 апр 19, 14:12    [21872683]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
alex55555
поэтому на таком довольно большом уровне модельный подход обязательно будет использоваться. Но не в его сегодняшнем виде, а в существенно расширенном

Хорошо, т.е. необходимость использовать модельный подход вы признаете?

Тогда возникают следующие вопросы. 1) Какие языки моделирования использовать? 2) В соответствии с какими методиками разрабатывать модели? 3) Какие форматы для обмена моделями использовать?


1) В мире в основном используется 4 подхода:

а) В большинстве подобных проектов используется UML. В силу того, что это один из самых известных языков моделирования, разработано много инструментов, поддерживающих UML, в нём можно моделировать и данные, и процессы.

б) Правда UML капец как неудобен для работы с древовидными структурами (а электронные документы как-раз древовидные), поэтому иногда разрабатывают специализированные языки моделирования и соответствующие инструменты. Так делают в ISO 20022, GEFEG и т.п.

в) Ещё UML капец как не удобен для моделирования реальности, для создания концептуальных моделей. Это просто огромная отдельная тема. Кому интересно можно погуглить книгу Business Objects: Re-Engineering for Re-Use. После её прочтения вообще меняется взгляд на моделирование, формы документов. Поэтому в особо сложных предметных областях используют онтологические языки моделирования (RDF, OWL) - например, ISO 15926.

г) Самый примитивный подход - когда не запариваются с моделями, просто публикуют набор XML схем или Excel файлы.


2) Чтобы нарисовать модель одного языка моделирования мало. Нужна методика моделирования. Под каждый проект в силу разных причин обычно пишется своя методика. Вот, например, методика моделирования для модели ЕАЭС. Методика реализуется в виде UML профиля с дополнительными "правилами ФЛК" для моделей. Для модели ЕАЭС, например, порядка 200 дополнительных правил. Либо реализуется в виде MOF-метамодели, вот, например, метамодель для ISO 20022.


3) Очевидно, что разработанными моделями нужно как-то обмениваться, в каком-то виде предоставлять к ним доступ. К сожалению или к счастью, есть только одна организация, которая занимается стандартизацией в данной области - это Object Management Group. Именно они разрабатывают и утверждают практически все стандарты в области модельно-ориентированной разработки: UML, BPMN, MOF, OCL. И в том числе, они разработали стандарт обмена моделями - XMI, который поддерживается в подавляющем большинстве инструментов моделирования и альтернатив у него просто нет.


Eclipse Modeling Framework (EMF) - это всего лишь одна из реализаций стандартов OMG. Я вообще не понимаю о каких "форматах EMF" вы говорите. В рамках EMF просто реализованы стандарты UML, OCL, XMI и т.п. Есть другие реализации. Никто EMF никому не навязывает.

Более того, XMI вообще используется только для обмена моделями, а не для обмена самими электронными документами. Обмен электронными документами может осуществляться в каком угодно формате: XML, JSON, CSV, RDF, ... Идея только в том, чтобы под каждый из этих форматов не фигачить XSD, JSON схему, RDF схему и т.п. А описать схему данных нейтрально в виде модели. И уже из модели генерить все эти XSD, JSON схемы, RDF схемы, описание структуры в виде Word документа или Excel.

Я просто не понимаю с чем конкретно вы не согласны:

1) Нужны другие языки моделирования - предложите какие.

2) Нужна какая-то специальная методика моделирования - предложите.

3) Другие форматы для обмена моделями - предложите. Ничего кроме XMI для этого нет, это единственный формат, если не считать всякие RDF/OWL, которые используются для специфических проектов.

4) С использованием EMF - ну, никто его и не навязывает, это всего лишь одна из реализаций стандартов OMG. Не нужны никакие преобразователи форматов из EMF. Модель, нарисованную с помощью EMF, можно открыть в любой адекватной UML рисовалке. Они все основаны на OMGшных стандартах.

5) С использованием стандартов OMG - ну, других просто нет.



Насчет того, что сгенерить из модели реализацию - это легкотня. Ну если сводить всё к CamelCase, snake_case, то наверное легкотня. Если генерить ФЛК из модели, то это уже немного сложнее. У нас единственный проект в мире, в котором это делается в таком объёме.


alex55555
Структуру описывают множеством способов. Есть UML, есть XSD, есть ER схемы, есть и куча всего остального. О какой-то платформной зависимости ни в одном из этих случаев речи не идёт.

Я понял, это терминологический спор.

При проектировании баз данных можно рисовать 3 вида моделей:
1) Концептуальные (тут мы просто моделируем реальность как есть, вообще не думая о хранении)
2) Логические (тут мы уже задумываемся, например, связь между сущностями нам лучше реализовать просто в виде внешнего ключа или в виде отдельной сущности)
3) Физические (реализуем всё под конкретную СУБД)

У этой схемы есть куча вариаций. Кто-то считает, что на концептуальном уровне нужно рисовать только сущности без атрибутов. Кто-то считает, что концептуальные модели нужно рисовать на UML, а логические - в виде ER диаграмм и т.п. Это не принципиально.
Однако, все согласны, что проектирование должно идти сверху вниз.
Иногда начинают сразу со 2-го или 3-го уровня. Иногда идут в обратном направлении - реверс-инжиниринг существующих схем. Не важно.

Важно то, что консорциум OMG взял эту идею и распространил её на любые модели, не только модели данных. При этом уровни они назвали немного иначе:
1) Вычислительно-независимые модели (Computation Independent Model, CIM)
2) Платформенно-независимые модели (Platform Independent Model, PIM)
3) Платформенно-зависимые модели (Platform Specific Model, PSM)

Но смысл совершенно аналогичный:
1) CIM - моделирование реальности (процессов, предметной области) как есть
2) PIM - моделирование с акцентом на реализацию (конкретные информационные взаимодействия, конкретные структуры электронных документов)
3) PSM - моделирование с акцентом на реализацию (конкретный стек технологий - WSDL, XSD, схемы реляционных баз данных и т.п.)

1) Например, на уровне CIM мы описываем сущности: товар, транспортное средство, товарная партия, отправитель, грузоперевозчик. На этом уровне нам важно максимально полно описать эти сущности со всеми возможными свойствами и отношениями. Максимально корректно определить виды этих сущностей: где реально сущность, где её роли. Например, сущность - организация и роли - отправитель, грузоперевозчик и т.п. А, вот, порядок свойств: 1) фамилия 2) имя 3) отчество или 1) имя 2) отчество 3) фамилия нам вообще не важны. Как не важны и ограничения на области значений атрибутов - 100 или 200 символов ограничение на имя.

По этой причине UML плох для таких моделей, какие-то вещи в нём просто лишние - например, фиксированный порядок атрибутов, типы данных и т.п. Каких-то вещей наоборот нет.

2) На уровне PIM мы начинаем проектировать конкретные структуры документов. Здесь нужно из всего многообразия свойств и отношений объектов выбрать те, которые нам нужны в этом документе. Например, у транспортного средства штук 100 разных свойств и отношений. А конкретно в этом документе нам нужны регистрационный номер, сведения о прицепах, о водителе и всё. Также на этом уровне нам важен порядок реквизитов в документе, важно что во что вкладывается: транспортное средство в грузоперевозчика или наоборот. Важно задать ограничения на область значений, например, длина рег. номера до стольки-то символов или соответствует такому-то регулярному выражению. Вот, тут UML как-раз на много лучше всяких RDF/OWL.

Но есть ещё один момент. Когда мы указываем в модели, что фамилия должна быть не длиннее 100 символов, нам глубоко по барабану будет эта фамилия передаваться в XML документе, в JSON документе, будет ли она храниться в базе данных. Нам глубоко по барабану какие типы данных будут использоваться для фамилии: xs:string, NVARCHAR(100), java.lang.String, System.String и т.п.

3) Все эти типы данных и т.п. определяются уже на уровне PSM, в конкретных схемах под конкретные платформы. С одной стороны, схемы достаточно тривиально могут быть сгенерены из моделей с уровня PIM (UML моделей или ещё каких-то). С другой стороны, это преобразование не всегда очевидное и тривиальное. Для тех же XSD есть 4 шаблона (матрёшка, райский сад, жалюзи, салями), типы данных нужно как-то мапить. Для реляционных СУБД всё ещё сложнее, там не 4 шаблона, а просто дофига вариантов. Причём, это только структура, а если добавить мапинг правил ФЛК, то это ещё интересней.

Короче, когда я пишу про UML и XSD я имею в виду то, что UML используется на уровне PIM, а XSD - на уровне PSM. И ставить их в один ряд - типа всё это про одно и то же немного странно. Хотя, с другой стороны, и на UML можно продублировать XSD, просто нарисовать XSD в виде UML диаграммы, такая UML конечно на уровне PSM. И, наоборот, модель можно представить в виде XSD, причем это будет не XSD для обмена, а XSD a la словарь данных, например, NIEM так делает.
26 апр 19, 16:21    [21872827]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mayton
Member

Откуда: loopback
Сообщений: 42897
На курсах системного анализа в универе нам рассказывали о Фреймах представления знаний (ФЗ).

Конспект я утерял. Но пытался восстановить что это и о чём. У кого есть какая-либо информация об этом
прошу накидайте книжек и ссылок по ФЗ.
26 апр 19, 16:26    [21872837]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
Ares_ekb
Хорошо, т.е. необходимость использовать модельный подход вы признаете?

Да.

Но осмысленно.

Сейчас же будет просто зоопарк. Ну и зачем там ещё один медведь?
Ares_ekb
1) Какие языки моделирования использовать?

К моему представлению ближе всего онтологии.
Ares_ekb
2) В соответствии с какими методиками разрабатывать модели?

Методики мало. Требуется целенаправленное массовое обучение.

На выходе любого ВУЗа должен быть специалист, способный работать с моделями мира. Любого ВУЗа. То есть все выпускники должны иметь понимание основ моделирования и работы со стандартизованными средствами обеспечения процесса.
Ares_ekb
3) Какие форматы для обмена моделями использовать?

Это вообще дело десятое. Хоть на брейнфаке, хоть в крестик, хоть на языке майя.

Этим будет заниматься писюк, а не человек.
Ares_ekb
а) В большинстве подобных проектов используется UML. В силу того, что это один из самых известных языков моделирования, разработано много инструментов, поддерживающих UML, в нём можно моделировать и данные, и процессы.

Не надо заглядываться на мир. Маразм в мире никуда не делся.
Ares_ekb
3) Очевидно, что разработанными моделями нужно как-то обмениваться, в каком-то виде предоставлять к ним доступ. К сожалению или к счастью, есть только одна организация, которая занимается стандартизацией в данной области - это Object Management Group.

Плод стихийного (но неявно управляемого) процесса не стоит преподносить как что-то стоящее.
Ares_ekb
альтернатив у него просто нет.

Альтернатив нет и в плане развития. То есть вот что подано, то и ешь. Но так быть не должно.
Ares_ekb
Eclipse Modeling Framework (EMF) - это всего лишь одна из реализаций стандартов OMG. Я вообще не понимаю о каких "форматах EMF" вы говорите. В рамках EMF просто реализованы стандарты UML, OCL, XMI и т.п. Есть другие реализации. Никто EMF никому не навязывает.

У эклипсины на выходе после моделирования есть файлик с расширением emf. И этот файлик нужен для всего остального. Хотя там ещё ecore и тому подобные расширения бывают, но все их объединяет именно использование общего плагина EMF.
Ares_ekb
Я просто не понимаю с чем конкретно вы не согласны

С убожеством подхода.
Ares_ekb
Насчет того, что сгенерить из модели реализацию - это легкотня. Ну если сводить всё к CamelCase, snake_case, то наверное легкотня. Если генерить ФЛК из модели, то это уже немного сложнее. У нас единственный проект в мире, в котором это делается в таком объёме.

После задания маппинга, включая алгоритмические конвертеры, всё остальное - детский сад.
Ares_ekb
При проектировании баз данных можно рисовать 3 вида моделей:
1) Концептуальные (тут мы просто моделируем реальность как есть, вообще не думая о хранении)
2) Логические (тут мы уже задумываемся, например, связь между сущностями нам лучше реализовать просто в виде внешнего ключа или в виде отдельной сущности)
3) Физические (реализуем всё под конкретную СУБД)

Логические выделяются несколько натянуто. То есть это просто детализация концепции. Физика, в принципе, тоже детализация, но здесь важна привязка к конкретным ограничениям используемого инструмента.
Ares_ekb
При этом уровни они назвали немного иначе:
1) Вычислительно-независимые модели (Computation Independent Model, CIM)
2) Платформенно-независимые модели (Platform Independent Model, PIM)
3) Платформенно-зависимые модели (Platform Specific Model, PSM)

Если даже названия не логичные (а не "немного иначе"), то и в глубине обнаруживается адский ад.
Ares_ekb
По этой причине UML плох для таких моделей, какие-то вещи в нём просто лишние - например, фиксированный порядок атрибутов, типы данных и т.п. Каких-то вещей наоборот нет.

Ну вот, то есть понимание неудобства есть, но вывод о необходимости другого подхода, почему-то, не делается.
Ares_ekb
Важно задать ограничения на область значений, например, длина рег. номера до стольки-то символов или соответствует такому-то регулярному выражению. Вот, тут UML как-раз на много лучше всяких RDF/OWL.

Это следствие концепции. Кто-то когда-то решил, что "вот здесь я рыбу заворачивал", а "вот здесь я умный вид делал". На самом же деле разница лишь в детализации. Никаких концептов, тупо "больше/меньше".
Ares_ekb
Короче, когда я пишу про UML и XSD я имею в виду то, что UML используется на уровне PIM, а XSD - на уровне PSM. И ставить их в один ряд - типа всё это про одно и то же немного странно.

Это типичный подход "едим что есть".

Да, когда есть только дерьмо и подсохшее дерьмо, то при попытке отвернуться кто-то обязательно скажет - так это же стандарт! Другого всё равно нет.

Качество организации деятельности общества есть главная цель (если общество вменяемое). При этом в современном мире всем плевать на само общество. Отсюда борьба потребностей. Без общества не будет ни моделирования ни даже дерьма подсохшего - некому его будет делать, да и жрать тоже. Поэтому как-то, по остаточному принципу, выделяются деньги на поддержание процессов функционирования общества. Но цель-то - ни разу не помочь обществу. Поэтому как только появляется возможность для попила под благим предлогом "всё для людей", так сразу получается дерьмо. Ну и моделирование в современных условиях именно в эту сторону идёт. Удовлетворяются узкие интересы некой группы контор, задача которых - прибыль, а не какое-то там общество. И раз важна прибыль - нафиг нужны какие-то долгие исследования, нафиг нужно кого-то учить, если он здесь и сейчас не приносит бабло.

Ну и где в этой картине находишься ты? Ты понимаешь?

Тебя приставили к станку по нагибанию кучи народа на отдачу денег через ту контору, в которой ты работаешь. Никакое моделирование там даже близко не стояло. Оно в лучшем случае есть благая отмазка для дурачков, которым рассказывают, мол мы команда, мы всё для людей, мы должны много работать, что бы мир стал лучше! А на самом деле дурачков нагибают приносить в зубах бабло. Ну ты и носишь им красиво выглядящие обоснования этого процесса.
27 апр 19, 12:05    [21873292]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
mayton
У кого есть какая-либо информация об этом
прошу накидайте книжек и ссылок по ФЗ.

Так с первых же ссылок в гугле:
Фреймовая модель знаний
Фрейм (инженерия знаний)
27 апр 19, 12:06    [21873297]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
alex55555
И раз важна прибыль - нафиг нужны какие-то долгие исследования, нафиг нужно кого-то учить, если он здесь и сейчас не приносит бабло.

Ну и где в этой картине находишься ты? Ты понимаешь?

Я понимаю: уже 6 лет пишу всякие методики моделирования, научные статьи, выступаю на конференциях, пишу статьи для хабра, чтобы нести всё это для широкого круга людей, фигачу инструменты. Например, первый прототип генерилки ФЛК из модели под разные платформы был ещё 5 с лишним лет назад и только пару лет назад он попал в продакшн. И, вот, приходите вы и говорите, что всё дерьмо и распил, всех отправить в гулаг и делать всё по-другому. С одной стороны, такая позиция немного задевает, с другой - хочется понять что люди вообще думают по поводу модельно-ориентированной разработки и т.п. И я понимаю, что это очень узкая ниша. Разработчики что-то разрабатывают. Все эти модели для них - другая вселенная.
27 апр 19, 15:15    [21873360]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Bsplesk
Member

Откуда:
Сообщений: 126
Ares_ekb
Bsplesk,
а теперь представь, что таких компаний тысяча, у каждой уже реализованы какие-то системы, у кого-то микросервисы, у кого-то монолиты, у кого-то вообще непонятно что написанное 30 лет назад, у кого-то ничего. Более того, эти компании находятся в разных странах с разным законодательством. И у них даже криптографические стандарты разные! А, ведь, данные при передаче нужно как-то подписывать или шифровать. Все эти программы сертифицируются разными органами.


Именно так и работаем, как внутри и снаружи куча разных систем с совершенно различными архитектурами и стеком.
Но нет никакой "регулирующей организации". Каждая компания/вендор предоставляет способ интеграции - в виде того или иного api (PublicAPI), при это чтобы все могли нормально с ним работать это должен быть определенный и не обязательно строгий стандарт. При данных требованиях рулит http/REST - да он "кривой и косой", да это "натягивание совы на глобус", но он работает и позволяет интегрироваться с минимум затрат/времени. Тот-же wsdl/soap на три головы круче, но нужна соответствующая поддержка на уровне стека, а это может быть "очень доооолгой пластинкой", которая отобьёт всё желание, да и экономический эффект будет не очевиден (а доброго Васи на голубом вертолете, который качественно и бесплатно создаст реализацию под ваш стек и будет её поддерживать все нет).

автор
Причём, сами данные, которые передаются, они же не хранятся где-то в одном месте. Нельзя написать один REST сервис, к которому люди будут обращаться.

Достаточно, чтобы у каждой компании был "REST Public API" - каждое API уникально, но разобраться можно.
https://developer.paypal.com/
https://www.developer.ebay.com/docs
https://developers.digitalocean.com/documentation/v2/
https://developer.americanexpress.com/
https://docs.aws.amazon.com/AmazonS3/latest/API/Welcome.html
https://developer.sberbank.ru/
https://developer.qiwi.com/ru/pull-payments/
https://oplata.tinkoff.ru/landing/develop/documentation
https://developer.mercedes-benz.com/apis/dealer_api/docs
https://developer.equifax.com/products
... etc

Ares_ekb
Bsplesk,
И над всем этим стоит регулирующая организация,


ЦБ - XBRL. Нужен ли UML если есть регулирующая организация?
https://habr.com/en/post/333636/
http://www.xbrl.org/Specification/XBRL-2.1/REC-2003-12-31/XBRL-2.1-REC-2003-12-31 corrected-errata-2013-02-20.html
+
The logos of our sustaining partnersFujitsu, SAP, Workiva, ACRA and the Association of International Certified Professional Accountants – are all registered to their respective organisation and are used with permission.

The IFRS Foundation’s logo and the IASB®, IFRS®, IFRS for SMEs®, IFRS Foundation®, International Accounting Standards®, International Financial Reporting Standards® are registered trade marks of the IFRS Foundation.

The W3C’s logo, as well as terms including XML, DOM, HTML, XHTML, HTML5, XSL and XSLT are registered and unregistered Trademarks of the Massachusetts Institute of Technology (MIT), European Research Consortium for Informatics and Mathematics (ERCIM), or Keio University (Keio) on behalf of the World Wide Web Consortium. All use of the W3C Trademarks is governed by the W3C Trademark and Service Mark License.

Зачем носиться исключительно с ребятами/теоретиками из OMG головного мозга, когда есть практики из w3c? (хотя часть компаний дублируется?)
uml
+
Copyright © 2009-2013 88Solutions
Copyright © 2009-2010 Artisan Software Tools
Copyright © 2001-2013 Adaptive
Copyright © 2009-2010 Armstrong Process Group, Inc.
Copyright © 2001-2010 Alcatel
Copyright © 2001-2010 Borland Software Corporation
Copyright © 2009-2010 Commissariat à l'Energie Atomique
Copyright © 2001-2010 Computer Associates International, Inc.
Copyright © 2009-2010 Computer Sciences Corporation
Copyright © 2009-2013 Data Access Technologies, Inc. (Model Driven Solutions)
Copyright © 2009-2013 Deere & Company
Copyright © 2009-2013 European Aeronautic Defence and Space Company
Copyright © 2001-2013 Fujitsu
Copyright © 2001-2010 Hewlett-Packard Company
Copyright © 2001-2010 I-Logix Inc.
Copyright © 2001-2013 International Business Machines Corporation
Copyright © 2001-2010 IONA Technologies
Copyright © 2013 Ivar Jacobson International SA
Copyright © 2001-2010 Kabira Technologies, Inc.
Copyright © 2009-2010 Lockheed Martin
Copyright © 2001-2010 MEGA International
Copyright © 2009-2010 Mentor Graphics Corporation
Copyright © 2009-2013 Microsoft Corporation
Copyright © 2001-2010 Motorola, Inc.
Copyright © 2009-2010 National Aeronautics and Space Administration
Copyright © 2009-2013 No Magic, Inc.
Copyright © 1997-2017 Object Management Group, Inc
Copyright © 2009-2010 oose Innovative Informatik GmbH
Copyright © 2001-2010 Oracle Corporation
Copyright © 2009-2010 Oslo Software, Inc.
Copyright © 2009-2010 Purdue University
Copyright © 2012-2013 Simula Research Laboratory
Copyright © 2009-2010 SINTEF
Copyright © 2001-2010 SOFTEAM
Copyright © 2009-2013 Sparx Systems Pty Ltd
Copyright © 2001-2010 Telefonaktiebolaget LM Ericsson
Copyright © 2009-2010 THALES
Copyright © 2001-2013 Unisys
Copyright © 2001-2010 X-Change Technologies Group, LLC

w3c (xml schema)
+
At the time this document is published, the members in good standing of the XML Schema Working Group are:

David Ezell, National Association of Convenience Stores (NACS) (chair)
Shudi (Sandy) Gao 高殊镝, IBM
Mary Holstege, Mark Logic
Sam Idicula, Oracle Corporation
Michael Kay, Invited expert
Jim Melton, Oracle Corporation
Dave Peterson, Invited expert
Liam Quin, W3C (staff contact)
C. M. Sperberg-McQueen, invited expert
Henry S. Thompson, University of Edinburgh
Kongyi Zhou, Oracle Corporation

The XML Schema Working Group has benefited in its work from the participation and contributions of a number of people who are no longer members of the Working Group in good standing at the time of publication of this Working Draft. Their names are given below. In particular we note with sadness the accidental death of Mario Jeckle shortly before publication of the first Working Draft of XML Schema 1.1. Affiliations given are (among) those current at the time of the individuals' work with the WG.

Paula Angerstein, Vignette Corporation
Leonid Arbouzov, Sun Microsystems
Jim Barnette, Defense Information Systems Agency (DISA)
David Beech, Oracle Corp.
Gabe Beged-Dov, Rogue Wave Software
Laila Benhlima, Ecole Mohammadia d'Ingenieurs Rabat (EMI)
Doris Bernardini, Defense Information Systems Agency (DISA)
Paul V. Biron, HL7; later Invited expert
Don Box, DevelopMentor
Allen Brown, Microsoft
Lee Buck, TIBCO Extensibility
Greg Bumgardner, Rogue Wave Software
Dean Burson, Lotus Development Corporation
Charles E. Campbell, Invited expert
Oriol Carbo, University of Edinburgh
Wayne Carr, Intel
Peter Chen, Bootstrap Alliance and LSU
Tyng-Ruey Chuang, Academia Sinica
Tony Cincotta, NIST
David Cleary, Progress Software
Mike Cokus, MITRE
Dan Connolly, W3C (staff contact)
Ugo Corda, Xerox
Roger L. Costello, MITRE
Joey Coyle, Health Level Seven
Haavard Danielson, Progress Software
Josef Dietl, Mozquito Technologies
Kenneth Dolson, Defense Information Systems Agency (DISA)
Andrew Eisenberg, Progress Software
Rob Ellman, Calico Commerce
Tim Ewald, Developmentor
Alexander Falk, Altova GmbH
David Fallside, IBM
George Feinberg, Object Design
Dan Fox, Defense Logistics Information Service (DLIS)
Charles Frankston, Microsoft
Matthew Fuchs, Commerce One
Andrew Goodchild, Distributed Systems Technology Centre (DSTC Pty Ltd)
Xan Gregg, TIBCO Extensibility
Paul Grosso, Arbortext, Inc
Martin Gudgin, DevelopMentor
Ernesto Guerrieri, Inso
Dave Hollander, Hewlett-Packard Company (co-chair)
Nelson Hung, Corel
Jane Hunter, Distributed Systems Technology Centre (DSTC Pty Ltd)
Michael Hyman, Microsoft
Renato Iannella, Distributed Systems Technology Centre (DSTC Pty Ltd)
Mario Jeckle, DaimlerChrysler
Rick Jelliffe, Academia Sinica
Marcel Jemio, Data Interchange Standards Association
Simon Johnston, Rational Software
Kohsuke Kawaguchi, Sun Microsystems
Dianne Kennedy, Graphic Communications Association
Janet Koenig, Sun Microsystems
Setrag Khoshafian, Technology Deployment International (TDI)
Melanie Kudela, Uniform Code Council
Ara Kullukian, Technology Deployment International (TDI)
Andrew Layman, Microsoft
Dmitry Lenkov, Hewlett-Packard Company
Bob Lojek, Mozquito Technologies
John McCarthy, Lawrence Berkeley National Laboratory
Matthew MacKenzie, XML Global
Nan Ma, China Electronics Standardization Institute
Eve Maler, Sun Microsystems
Ashok Malhotra, IBM, Microsoft, Oracle
Murray Maloney, Muzmo Communication, acting for Commerce One
Paolo Marinelli, University of Bologna
Lisa Martin, IBM
Noah Mendelsohn, Lotus; IBM; invited expert
Adrian Michel, Commerce One
Alex Milowski, Invited expert
Don Mullen, TIBCO Extensibility
Murata Makoto, Xerox
Ravi Murthy, Oracle
Chris Olds, Wall Data
Frank Olken, Lawrence Berkeley National Laboratory
David Orchard, BEA Systems, Inc.
Paul Pedersen, Mark Logic Corporation
Shriram Revankar, Xerox
Mark Reinhold, Sun Microsystems
Jonathan Robie, Software AG
Cliff Schmidt, Microsoft
John C. Schneider, MITRE
Eric Sedlar, Oracle Corp.
Lew Shannon, NCR
Anli Shundi, TIBCO Extensibility
William Shea, Merrill Lynch
Jerry L. Smith, Defense Information Systems Agency (DISA)
John Stanton, Defense Information Systems Agency (DISA)
Tony Stewart, Rivcom
Bob Streich, Calico Commerce
William K. Stumbo, Xerox
Hoylen Sue, Distributed Systems Technology Centre (DSTC Pty Ltd)
Ralph Swick, W3C
John Tebbutt, NIST
Ross Thompson, Contivo
Matt Timmermans, Microstar
Jim Trezzo, Oracle Corp.
Steph Tryphonas, Microstar
Scott Tsao, The Boeing Company
Mark Tucker, Health Level Seven
Asir S. Vedamuthu, webMethods, Inc
Fabio Vitali, University of Bologna
Scott Vorthmann, TIBCO Extensibility
Priscilla Walmsley, XMLSolutions
Norm Walsh, Sun Microsystems
Cherry Washington, Defense Information Systems Agency (DISA)
Aki Yoshida, SAP AG
Stefano Zacchiroli, University of Bologna
Mohamed Zergaoui, Innovimax


Почему так упорно не хотите спуститься с Олимпа научных статей к людям (услышать их)?
Вот создали конвертер uml2xsd (посмотрю повнимательней, как раз выходные) - ну Ок - хорошо, а мнение людей (простых людей) спросили, что им нужно в работе ?
- Вот бесплатный совет (да хотелка), по развитию uml2xsd. Сделайте поддержку (для моделей) формата "Excel" (С возможностью выбора в качестве базового (тоесть создаем в нём) при "концептуальном" моделировании - в моём частном (больном) случае - выделение бизнес объектов/модели + связи) и предоставьте информацию или напишите "Readmi", как добавить/разработать конвертер - допустим в swagger (OpenAPI) - в части моделей (там всё просто до "нельзя" - хипстерский формат) - сейчас у меня собственное "поделие" на VBA/Excel, которые худо бедно позволяет переводить xml schema <--> swagger/openapi (data model) с хранением общей модели в Excel - которую можно частично загрузить допустим произвольного PDF файла с "табличками".
Кстати да, кое где мы используем (исторически тащим) Data Transfer Object (DTO)/производства IBM.
27 апр 19, 19:45    [21873476]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mayton
Member

Откуда: loopback
Сообщений: 42897
alex55555
mayton
У кого есть какая-либо информация об этом
прошу накидайте книжек и ссылок по ФЗ.

Так с первых же ссылок в гугле:
Фреймовая модель знаний
Фрейм (инженерия знаний)

Марвин Минский - Фреймы знаний. Это гуд. Буду искать.
27 апр 19, 20:17    [21873486]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
Bsplesk
ЦБ - XBRL. Нужен ли UML если есть регулирующая организация?

XBRL только для отчетности. Для национальной платежной системы они, например, внедряют стандарт ISO 20022. Там внутри как-раз всё описывается в виде моделей, из которых генерятся документы, Excel, XSD, XSLT и отдаются пользователям НПС.

Bsplesk
Сделайте поддержку (для моделей) ...

Я ровно этим сейчас и занимаюсь :) Делаю нормальный инструмент моделирования, который позволяет генерить разные вещи из моделей (там дофига ещё разных идей на самом деле - я очень много пользовался разными инструментами и хорошо понимаю чего там не хватает). Но если учесть, что кроме этого проекта у меня ещё 3 работы, то идёт всё это очень не быстро. У меня уже запилена рисовалка моделей (JavaScript + d3.js), серверная часть на Spring (хранилище моделей, версионирование и т.п.), парсер и генератор SQL. Даже куплен прикольный домен и сервак стоит :) Для запуска первоначальной версии нужно по сути только довести немного до ума рисовалку моделей и исправить баги. Я вполне потянул бы этот проект один, если бы не 3 других работы. Сейчас ищу разные варианты не то, чтобы с инвесторами. Потому что деньги тут не нужны, больше нужны разработчики.
27 апр 19, 20:31    [21873492]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
Ares_ekb
уже 6 лет пишу всякие методики моделирования, научные статьи, выступаю на конференциях, пишу статьи для хабра, чтобы нести всё это для широкого круга людей, фигачу инструменты.

Это всё занимательно, но суть-то отсутствует.

Есть конторы, которые имеют право нагибать весь окружающий мир. Эти конторы выдают нагибательные приказы. И есть предложение в нагибательные приказы вставить некие модели. Звучит занимательно, но толку-то нет. Зачем при чтении неких данных модель? Только что бы понять, что очередной нагибатель от тебя хочет. И для этого достаточно простейших XSD с их ограничениями на длину полей и прочими комментариями. На основе XSD худо-бедно большинство что-то умеют делать. А что дадут некие более широкие модели? Ну что? Какую к чертям конвертацию, генерацию и прочее? Сначала это будет геморой по изучению предмета и сопутствующих инструментов, а потом будет ни на грамм не лучше обычной XSD. Ну и зачем?
Ares_ekb
хочется понять что люди вообще думают по поводу модельно-ориентированной разработки и т.п.

Это перспективное направление.

Но не у нас.

Где-то внутри какого-то ведомства, возможно, при наличии кучи важных факторов, таких как поддержка начальства и наличие собственно реальной потребности (а не фантазии со стороны оналитегов), можно пытаться реализовывать внутренние задачи на основе такого подхода. Но снаружи - ну зачем? Просто нет никакого смысла.
28 апр 19, 12:02    [21873652]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
alex55555,

ответ на вопрос "зачем?" очень простой. Как минимум 3 причины:

1) Лет 20-30 назад для обмена данными были очень популярны форматы семейства EDI (EDIFACT, ASC X12, HL7 и др.). Потом начал набирать популярность XML и на базе этих стандартов стали создавать аналогичные стандарты, но на основе XML. Например, UN/EDIFACT стал основой для UN/CCL, HL7, я могу ошибаться, но кажется в 3-ей версии в качестве альтернативы получил и XML-ый вариант. Американские ASC X12 я смотрел совсем немного, но на сколько я помню там тоже были какие-то рекомендации по преобразованию EDI<->XML и соответствующие инструменты.

Именно в тот момент (лет 20 уже как) и начала развиваться вся эта тема с платформенно-независимыми моделями. Люди осознали, что 1) требования к структуре сообщения и 2) требования к формату передачи - это две разные вещи. Стандарт обмена данными должен описывать структуру сообщений в технически нейтральном виде, не нужно в стандарт тащить технические детали, детали реализации. И отдельно должны даваться рекомендации как эти структуры укладываться в EDI, XML или что угодно.

Самый хороший пример - это стандарт ISO 20022. Он состоит из нескольких частей. В 1-ой части описывается метамодель, т.е. набор правил как вообще нужно проектировать сообщения и т.п. Во 2-ой части описывается как делать всё то же самое, но на языке UML. А, самое интересное - это 3 и 8 части. В 3-ей части описывается как на основе технически нейтральной структуры сообщений сформировать XML схему, если обмен будет в формате XML. А 8-ой части описывается как формировать ASN.1 схемы. На случай, если участники взаимодействия хотят использовать этот бинарный формат. Ну, вот, исторически там этот формат уже давно используется, написан софт, заточенный под ASN.1 и этот ваш XML им вообще невсрался.

Ещё один пример - модель NIEM для межведомственного взаимодействия в штатах. Они уже изначально всё строили на XML, никакого ASN.1. Но так случилось, что некоторые участники больше не хотят использовать XML, подавай им теперь JSON. И что теперь? Перефигачивать все XSD в JSON схемы? Есть ещё куча не столь прогрессивных людей, которые всё ещё хотят XML и JSON им никак не всрался. В итоге NIEM теперь тоже уходит от XML схем, но не в JSON, а в технически нейтральные модели, из которых хош - получишь XSD, хошь - JSON схему.

Короче, модели нужны чтобы отделить структуру сообщений от формата их передачи. Потому что структура - относительно стабильная вещь, она меняется вместе с изменением бизнес-требований. А форматы - это всё техника, от компании к компании реализация может меняться. Какой смысл всех заставлять использовать XML?

Вы почему-то эту идею ставите с ног на голову: "зачем нам эти модел-наци, которые заставляют всех использовать какие-то модели, давайте лучше заставим всех использовать XML".


2) И вторая причина в том, что XSD, REST API и т.п. - это техническая реализация, понятная только разработчикам и абсолютно непонятная предметным специалистам. Никакой предметник не будет разрабатывать XSD и API и утверждать их какими-то документами. XSD - это в лучшем случае просто дополнение к нормативному документу. А в этом нормативном документе предметники для предметников на человеческом языке описывают состав сведений, различные правила.

Здесь получается разрыв. С одной стороны, есть нормативка, которая пишется людьми для людей. Эта нормативка утверждается, имеет официальный статус. С другой стороны, есть реализация этой нормативки в XSD, API и т.п. Тот вариант, который уже неоднократно высказывался в этой теме, типа дайте нам XSD и API, а нормативку засуньте себе в ж..у, он не работает. Всё равно нормативка первична.

Короче, проблема в том, что нет никакой гарантии, что нормативка и реализация соответствуют друг другу. Вполне возможно, что в нормативке описана одна структура и одни правила. А когда всё это переводили в XSD и API, то всё напутали, неправильно поняли и сделали какую-то хрень.

Чтобы такого расхождения не было и используются модели. В модели мы, с одной стороны, на формальном, однозначном (в отличие от русского) языке, а с другой стороны без лишних технических деталей (в отличие от XSD, REST API и т.п.) описали структуру сообщений, правила обмена и т.п. И затем из этого эталона генерим всё что нужно: нормативный документ, XSD, API и остальное. Это гарантирует, что 1) в правилах обмена нет неоднозначностей и тупых ошибок 2) нормативка и реализация на 100% соответствуют друг другу, потому что сгенерены из одного источника без участия человека.


3) Ну, и 3 причина - это тупо экономия времени. Если бы вы попробовали написать технологические документы по какому-нибудь процессу, в котором только описание структуры сообщения - это страниц 200 текста и сверху ещё тыща правил заполнения этой структуры, а потом реализовать эту структуру в XSD и тыщу правил в коде, то сами захотели бы какой-нибудь инструмент для автоматизации всей этой тупой и рутинной работы. Так чтобы один раз описать структуру и правила (в виде модели, Excel файла или чего угодно), а всю эту жесть генерить автоматом.
28 апр 19, 13:11    [21873678]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb,

1) "Короче, модели нужны чтобы отделить структуру сообщений от формата их передачи." - Это было бы прекрасно, если бы не одно "но". Закон Дырявых Абстракций

2) Классика же

3) Пока это только слова без подтверждения.
Почему нельзя сразу описать модель в виде XSD.
Это не сложнее чем UML.
А т.к. XSD могут быть скомпилированы в классы, то заодно при "компиляции" (проебразовании), можно увидеть ошибки.
29 апр 19, 08:41    [21873929]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

1) Я правильно понял из статьи, что SQL, TCP и остальное - это зло и без них лучше? С другой стороны, я кстати отчасти согласен с этой статьей. На примере одного своего проекта. Когда я писал клиентскую часть на HTML, CSS и JavaScript мне хватало Far в качестве текстового редактора и браузера. Что-то подправил - сразу обновил страничку - затестил. Из сторонних библиотек я использовал только d3.js. У меня 90% уходило на разработку, 10% - на какие-то необъяснимые баги в верстке и т.п.

Потом начал писать серверную часть (Spring, Hibernate - все дела). Примерно 90% времени я тратил на гугление ошибок, которые выкидывает Hibernate, на чтение документации Spring и т.п. Причём, даже сами авторы Hibernate признают, что у них совершенно неадекватные исключения, вообще не указывающие на реальную причину ошибки, какие-то вещи из JPA не реализованы. В итоге я перешел на EclipseLink и всё стало проще, но всё равно сидела мысль зачем мне этот ад, когда легко и просто всё это делать на SQL. Gradle, Xtext - тоже отдельная история.


3) Потому что XSD описывает только структуру сообщений. Опишите мне на XSD процессы и правила ФЛК. Для ФЛК теоретически есть xs:assert в XSD 1.1, есть Schematron. Но XSD 1.1 очень мало где используется, нельзя заставить всех его использовать. Schematron - ещё более специфическая штука.

А, во-вторых, не все используют для обмена XML.


2) Вот, вы ровно это и предлагаете. Использовать XML как универсальный формат для передачи данных на все случаи в жизни. И использовать XSD как универсальный язык моделирования. Хотя ни один, ни другой таковыми не являются.



Не понимаю какое нужно подтверждение. Опишите мне всё это на XSD, особенно процессы и правила заполнения документов из регламента начиная с 40 страницы. Да, ещё так чтобы в перспективе можно было использовать JSON или любой другой формат для обмена.
29 апр 19, 10:26    [21873990]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb,

1) Нет это значит, то что нельзя абстрагироваться полностью и надо знать на чем будет реализовываться та или иная модель.
На примере того же SQL, для Oracle есть такие понятия как денормализация и хинты. Которые используют при реализации БД.
Ну просто потому что абстрактная модель "разбивается" об конкретную реализацию.

2) Вообще-то через XSD можно полностью описать модель, вплоть до поведения. А если еще подключить и схемы.
Баян большой, кнопок много.

"Не все" много чего не используют. Мы же говорим об API, соответственно и диктуем и формат сообщения.

3) Нет. Я про другое. Полет наших фантазий ограничиваться конкретными реализациями. И чем меньше будет "переводов" с одного птичьего языка на другой. Тем лучше.

Тот же БП лучше сразу хранить в "коде" на исполняемом ЯП. И при смене БП, безжалостно его выкидывать.
Модель данных то же лучше сразу иметь в виде БД на СУРБД (например).

А создание "универсального" справочника...
Пока мой опыт говорит, что это фантастика и даже не научная.

Если говорить о номенклатурном справочнике, который внедрен и даже работает.
Посмотрите на библиотечные каталоги (ISBN, БИК и пр.).
Кстати есть еще стандарт каталожных карточек. Который поддерживает любая библиотека, но у каждой есть свои "особенности"
Реализовывал проект электронного каталога библиотеки.
Есть куча международных стандартов.
В общем большего бардака нигде не видел.
Две библиотеки 3 системы каталогов (утрированно).
29 апр 19, 11:55    [21874121]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
Ares_ekb
Люди осознали, что 1) требования к структуре сообщения и 2) требования к формату передачи - это две разные вещи.

И что? Как это осознание используется?

По факту речь идёт о наличии информации вроде конкретного места нахождения данных, наименований тегов и форматов дат, чисел и т.д.

Вот убрали мы всю эту информацию из приказа по очередному рейхскомиссариату для населения покорённой территории, и что произойдёт? Рейхскомиссар всё так же будет расстреливать за неверные форматы, просто потому, что он сам в любом случае будет делать для себя некую физическую реализацию, которую, собственно, и будет требовать от холопов. А информацию холопам (с вашей лёгкой руки) выдаст, естественно, без деталей реализации. Да, это круто в плане навара рейхскомиссара на штрафах с податного сословия, но с точки зрения нагибаемых - башку надо отрывать таким выдумщикам. Нет?

Вы просто живёте на марсе и не знаете ситуацию на земле.
Ares_ekb
Самый хороший пример...

Да нет хороших примеров.

Взаимодействие с моделями появляется только при наличии всеобщей грамотности в этом вопросе. А нагибание всех приказами о расстрелах неправильно подающих челобитную - это к мазохистам (ну или к садистам, если вы с другой стороны).
Ares_ekb
Короче, модели нужны чтобы отделить структуру сообщений от формата их передачи. Потому что структура - относительно стабильная вещь, она меняется вместе с изменением бизнес-требований. А форматы - это всё техника, от компании к компании реализация может меняться. Какой смысл всех заставлять использовать XML?

Массы необразованы. Поэтому им понятнее XML. А введение дополнительного уровня абстракции у нас всегда превращается в издевательство над населением.

Вы же не думаете, что ваш рейхскомиссариат будет учить население? Так с чего вдруг польза будет?
Ares_ekb
Вы почему-то эту идею ставите с ног на голову: "зачем нам эти модел-наци, которые заставляют всех использовать какие-то модели, давайте лучше заставим всех использовать XML".

Что это за хрень - модел-наци?

Я говорю, что выдернуть структуру из XSD - задачка для детского сада. И потому все ваши позывы что-то упростить всегда столкнутся с банальной проблемой - всё будет усложнено и кого-то из холопов обязательно расстреляют.

Пока есть знакомые массам подходы - зачем вводить лишнее? Вы предлагаете сказать - а вот здесь у нас дерево, а вот здесь - дата. Ну и чем весь это текст лучше XSD, в которой всем сразу видно, что там действительно дерево и там действительно дата? И формат даты сразу есть. И не надо искать новый приказ по реийхскомиссариату с указанием на использование форматов дат с такого-то по такое-то число и с переходом на другой формат с ещё какого-то числа.

Для всех будет только хуже. Вы почему такую тривиальную истину понять не способны?

То есть я понимаю, что по детски вы там увлеклись рисованием моделек, вам это нравится, вы даже какие-то части этого рисования называете гениальными, но понять нужно одно - ваше детское увлечение есть именно ваш личный таракан. Вот вы его и кормите. А зачем другим навязывать? Зачем? Ради выделения структуры, которая и так очевидна? Ради одного мелкого преимущества создавать повод штрафовать всех, кто обязан сдавать подати рейхскомиссару?

Одно мельчайшее преимущество. Одно. И сколько раз про это я должен написать? И сколько раз надо писать про огромные минусы в существующей системе?
Ares_ekb
2) И вторая причина в том, что XSD, REST API и т.п. - это техническая реализация, понятная только разработчикам и абсолютно непонятная предметным специалистам.

А вот здесь не надо сочинять.

Есть техническая реализация, ей всегда занимаются технические специалисты, и если специалистам что-то непонятно - пинок под зад и забыть про таких специалистов.

И есть творчество по изданию приказов рейхскомиссара. Это как раз то, чем у вас там в рейхскомиссариате занимаются. Ну так и творите не выходя из своего рейхскомиссариата. Ваяйте модели, нагибайте рейхскомиссара их учить. Но наружу-то вы всё равно выставите REST-API и какой-нибудь XML. А что за титанические игрища с моделями будут в рейхскомиссариате - всем плевать (ну кроме сотрудников, которых тоже будут расстреливать).

И со стороны населения покорённой территории всё давно налажено - есть технические специалисты, которые понимают, что такое XSD и всё прочее. Вот им и спустят задачу реализации взаимодействия. И они её, без сомнений, реализуют. Без всяких модных моделей. Так зачем же их всех нагибать на не нужное им обучение, на кучу ошибок, ну и на штрафы и расстрелы?
Ares_ekb
Здесь получается разрыв. С одной стороны, есть нормативка, которая пишется людьми для людей. Эта нормативка утверждается, имеет официальный статус. С другой стороны, есть реализация этой нормативки в XSD, API и т.п. Тот вариант, который уже неоднократно высказывался в этой теме, типа дайте нам XSD и API, а нормативку засуньте себе в ж..у, он не работает. Всё равно нормативка первична.

Сотый раз повторю - население безграмотно. Отсюда все разрывы. И в вашем рейхскомиссариате все поголовно безграмотны, потому что они тоже часть населения. То есть причина очевидна, но решение вы по прежнему ищете не в обучении, а в модном изподвыподверте. Вы тупо увлеклись своими модельками. И не замечаете реальность.
Ares_ekb
Короче, проблема в том, что нет никакой гарантии, что нормативка и реализация соответствуют друг другу. Вполне возможно, что в нормативке описана одна структура и одни правила. А когда всё это переводили в XSD и API, то всё напутали, неправильно поняли и сделали какую-то хрень.

Так это же ответственность рейхскомиссариата. Или вы покрываете свою контору? Если у вас там дятлы не способны перевести священные изречения рейхскомиссара на технический язык, то кто-ж вам злобный буратино? Я что ли? Или всё остальное население?

Вы опять не видите причину, вы опять рассуждаете о каких-то глупостях.
Ares_ekb
Чтобы такого расхождения не было и используются модели.

Нет.

Рейхскомиссар никогда не будет учиться. Он лишком толстый для этого. Поэтому он никогда не будет читать эти ваши модели. Ну и поэтому всегда будет проблема конвертации его священных изречений во что-то технически вменяемое.

Ну и помимо рейхскомиссара - это всё внутреннее дело рейхскомиссариата. Зачем его выносить наружу? Плюс (микроскопический) один - будет чуть-чуть понятнее общая схема. Но минус огромный - у нас это всё тупо приведёт к расстрелам и штрафам.
Ares_ekb
Если бы вы попробовали написать технологические документы по какому-нибудь процессу, в котором только описание структуры сообщения - это страниц 200 текста и сверху ещё тыща правил заполнения этой структуры, а потом реализовать эту структуру в XSD и тыщу правил в коде, то сами захотели бы какой-нибудь инструмент для автоматизации всей этой тупой и рутинной работы.

Я опять в очередной раз повторяю - внедряйте в своём рейхскомиссариате что угодно, но людей не расстреливайте из-за непонимания причин ваших проблем.
29 апр 19, 13:35    [21874272]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

1) Хорошо, совершенно конкретный пример из презентации:
На 35-ом слайде описание правила на русском языке и его спецификация на формальном языке OCL (в UML модели).
На 36-ом слайде - сгенеренный Java код.
На 37-ом слайде - сгенеренный XSLT код.

На самом деле там очень замороченное правило. Это связано с тем, что какие-то поля не уложились в стандарт ISO 20022 и эти данные передаются в расширенной секции и связываются с данными в основной секции по идентификатору. Это очень редкий случай. Обычно правила выглядят как-то так:

+

GroupHeader.ControlSum =
PaymentInformation.CreditTransferTransactionInformation.Amount.InstructedAmount->sum()

GroupHeader.InitiatingParty.Identification.
  OrganisationIdentification.Other->forAll(
    SchemeName.Code = 'TXID'
    implies
    Identification.matches('^[0-9]{10}$'))

Тут описывается только содержательная составляющая правила. А когда оно реализуется в коде, то там добавляется очень много логики. Например, если проверяемая секция отсутствует в документе, то это не является ошибкой, но всё равно выдается предупреждение, что типа правило запускали, но подходящих под него элементов не нашли. Если для правила не выполнено предусловие, то аналогично - это не ошибка, но ещё один вид уведомления для пользователей. Ещё валидатор документов должен выдавать путь к XML элементам, которые проверялись. На Java это делается относительно просто, на XSLT - нужно генерить существенно больше кода. Скажем, если обязательный по ФЛК элемент отсутствует, то нужно пройти к этому элементу от корня и выдать путь до последнего присутствующего в документе элемента, и вывести ещё отдельно отсутствующий хвост этого пути.

Короче, ФЛК в модели может занимать 1-2 строки. При реализации на Java - это будет строк 10. При реализации на XSLT - строк 200.

Все эти дополнительные требования к реализации, которые я описал (что нужно выводить уведомления при невыполненном предусловии, что нужно определенным образом вычислять путь к провалидированным элементам и т.п.), возникали уже в процессе.


Если внимательно посмотреть на примеры ФЛК выше, то видно, что там вообще нет ничего, связанного с выводом ошибок, с поддержкой разных видов сообщений (ошибка, успех, не проверялось, не найдено и т.п.), нет никакой логики по определению того есть в документе элементы для валидации или нет, нет проверки выполняется предусловие или нет, нет никакой логики поиска проверяемых элементов. Всё что там есть - это просто бизнесовая спецификация правила (если поле имеет такое-то значение, то другое поле должно быть таким-то).

Если бы вся эта жесть, связанная с реализацией, тянулась в бизнесовые правила, то, во-первых, они были бы просто здоровенными и очень сложными. Во-вторых, при малейших изменениях в реализации (понадобилось вместо XML использовать JSON, понадобилось более точно выводить список провалидированных элементов) нужно переписывать все эти бизнесовые правила.

Например, раньше мы выводили путь только к провалидированной секции документа, а какие поля сравниваются внутри мы не учитывали. Допилили немного генератор кода, теперь он более интеллектуально анализирует правила ФЛК и выдает более точный путь к элементам. Если бы эта логика определения элементов была сразу зашита в правилах, то пришлось бы переписывать все эти правила.

Или, например, раньше были просто правила, мы не заморачивались с предусловиями. Было два исхода валидации: ошибка и успех. Но потом для удобства пользователей решили, давайте всё что в правиле идет до implies считать предусловием и генерить под это соответствующий код. Если бы эту логику зашили сразу на уровне бизнес правил, то опять-таки простым допиливанием генератора не смогли бы это реализовать, пришлось бы переписывать все правила.

А правила переписывать очень долго, дорого и вообще невозможно. Потому что после утверждения считай они отлиты в граните и в них даже запятую изменить нельзя.



То, что в SQL требуются хинты, совершенно не означает, что они требуются везде и что абстрагироваться от реализации невозможно. Конкретно в нашем случае это возможно. Я лично написал тыщи этих правил и лично занимался их реализацией (а не так, что берите модель и реализуйте как хотите). И ни разу потребности ни в каких хинтах не возникало. Если в реализации чего-то не хватает, то допиливается генератор.


Хотя с другой стороны, иногда хинты конечно нужны и это ничему не противоречит. Тут может быть три вида условно "хинтов":

1) Хинты жестко реализованные в генераторе. Например, если мы из модели генерим схему реляционной БД, то можем всегда для каждого внешнего ключа генерить ещё и индекс. Или генерить его в зависимости от каких-то условий. Т.е. зашиваем разные эвристики прямо в генераторе. По мере необходимости правим их или добавляем новые.

2) Хинты как параметры генератора. Например, у нас генератор, который из UML модели генерит XSD. На этапе генерации мы можем задавать какой шаблон XSD должен использоваться (матрешка, райский сад, жалюзи, салями), можем задавать правила преобразования имен в модели в имена в XSD. Или в видео на предыдущей странице (21871782) при генерации схемы БД как-раз задаётся много параметров-хинтов, определяющих какая схема получится на выходе.

3) Хинты на уровне модели. Такое тоже бывает, но это самый крайний случай (если варианты 1 и 2 не подходят). И то даже в этом случае хинт должен быть максимально абстрактным. Хотя на самом деле это никакой не хинт. Просто модель изначально недостаточно адекватно описывала реализацию и мы эту модель немного расширили.


mad_nazgul
"Не все" много чего не используют. Мы же говорим об API, соответственно и диктуем и формат сообщения.

mad_nazgul
Тот же БП лучше сразу хранить в "коде" на исполняемом ЯП. И при смене БП, безжалостно его выкидывать.

Мы говорим о разных вещах. В проектах, про которые я говорю, есть регулирующая организация, которая определяет правила обмена. Ей запрещено диктовать API, формат сообщений, системы управления БП, языки программирования и т.п.

Меня вообще это поражает. Представьте, что вам аналитик, собственник вашей фирмы (который сам допустим не является разработчиком) или вообще предметник со стороны заказчика будет диктовать какой код и как писать. Куда вы пошлете бухгалтера или кассира, который скажет "я тут набросал XSD и API и ещё реализовал несколько процессов в коде, бери их и используй"? Такое возможно вообще?

Или сверху какая-то организация будет вам диктовать как что реализовывать. У вас уже написано куча всего. Кто приходит и говорит, так а теперь быстренько переписали всё под JSON. И передавать его будем в SOAP конвертах ( я видел такое :) ), пофиг, что он для XML, но мы считаем что так правильно. И вы пойдете всё переделывать?
29 апр 19, 13:55    [21874318]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
alex55555,

для вас будет XSD, я вообще не понял с чего вы взяли что будет иначе
29 апр 19, 14:15    [21874353]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb,

1) 20 лет прошло, ничего не поменялось. Опять маркетолухи втюхивают рисовалку, как решение всех проблем.
Это дерьмо я вижу на каждой презентации.
После которой наступает лютый п-ц. Т.к. эти картинки настолько же близки к реальности, как единороги к лошадям.

2) Денормализация и хинты платформориентированы. Т.е. то что подходит для Oracle, может быть вредно для MySQL

3) Правила обмена сейчас везде одинаковы - HTTP.

Но без API нету никакого протокола обмена данными.
Т.к. реализация (API) жестко задает доменную модель, в рамкой которой можно проводить интеграцию/обмен.
Все остальное лирика, которая никому не интересна, а нужна для красоты.
30 апр 19, 11:14    [21875339]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
serge79y
Member

Откуда: Москва
Сообщений: 31
Ares_ekb
Bsplesk
ЦБ - XBRL. Нужен ли UML если есть регулирующая организация?

XBRL только для отчетности. Для национальной платежной системы они, например, внедряют стандарт ISO 20022. Там внутри как-раз всё описывается в виде моделей, из которых генерятся документы, Excel, XSD, XSLT и отдаются пользователям НПС.

Bsplesk
Сделайте поддержку (для моделей) ...

Я ровно этим сейчас и занимаюсь :) Делаю нормальный инструмент моделирования, который позволяет генерить разные вещи из моделей (там дофига ещё разных идей на самом деле - я очень много пользовался разными инструментами и хорошо понимаю чего там не хватает). Но если учесть, что кроме этого проекта у меня ещё 3 работы, то идёт всё это очень не быстро. У меня уже запилена рисовалка моделей (JavaScript + d3.js), серверная часть на Spring (хранилище моделей, версионирование и т.п.), парсер и генератор SQL. Даже куплен прикольный домен и сервак стоит :) Для запуска первоначальной версии нужно по сути только довести немного до ума рисовалку моделей и исправить баги. Я вполне потянул бы этот проект один, если бы не 3 других работы. Сейчас ищу разные варианты не то, чтобы с инвесторами. Потому что деньги тут не нужны, больше нужны разработчики.


Я думал, вы завязали с UML. Как человек, делавший инструменты моделирования 18 лет и не так давно завязавший с этим, скажу, что скорей всего у вас затея провалится :)

1. Хранилище моделей. Вы использовали EMFStore ? Или что-то свое сделали ?

2. Хранить модели в БД не совсем хорошая идея в плане интеграции моделей в процесс разработки. Т.к модели так или иначе связаны с внешними либами, кодом и так далее, то куда удобней хранить модели там же где и код. Разбивка по разным репозиториям усложняет все процессы. Мы в рамках Rational Design Manager-а делали единое хранилище для артефактов разного типа (на базе RTC), но там свои проблемы, это не Git, стоит дофига и в одиночку такое гарантировано не напишите.
Помимо прочего, конкурентная работа над моделью в БД это геммор.

3. В любом случае, версионирование моделей подразумевает diff/merge. Diff/merge моделей это большая проблема для юзера с пониманием что именно поменялось. Особенно когда вовлечены диаграммы, а не только семантическая часть. Я этой темой много занимался и надо когда-нить написать статью, пока все не забыл :)

4. Сделать удобную рисовалку для моделей почти невозможно, если мы хотим использовать модели для генерации кода.
В модели надо писать код. В итоге нам надо иметь и нормальный текстовой редактор (c content assist-ом и т.п) и рисовлку в одном флаконе. Т.к иначе писать код в operation-ах/transition-ах/guard-ах и т.д будет крайне не удобно. Отдельная проблема - бесплатных качественных библиотек с line routing-ом для диаграмм особо нет. Можно доводить Joint.js , но и он далеко не идеален.

5. Такие вещи как "Open Type" (из JDT) или поиск по проектам в контексте моделей становятся не удобны. Если с текстом мы можем
показать кусок кода вокруг для обозначения контекста, то с моделями это сложно.

6. Однонаправленная генерация кода будет всех раздражать. Если нет roundtrip-а (aka code to model synchronization) т.е апдейт модели после изменения сгенеренного кода, то продукт гарантировано провалится.

7. Делая продукт для моделирования, стоит сразу делать так, чтоб его можно было юзать в headless env (т.е на серваках ) и легко интегрировать со всеми билд системами - make/ant/gradle/etc. В общем, у него должен быть command line API. В первую очередь он должен поддерживать генерацию кода из command line-а.

8. Если бываете в Москве, можете попробовать выступить тут http://sdat.ispras.ru/ . Я как раз в ИСП вернулся, наелся IBM-а и HCL-я.
Будет интересно вас послушать.
4 май 19, 21:18    [21877866]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
serge79y,

1. На моей основной работе мы делали несколько репозиториев для моделей. Я очень настаивал на каких-то готовых решениях для хранилища типа EMFStore. Но в итоге сделали своё хранилище в БД. Для внутренней работы мы используем RSA+Git, потом выгружаем модели в XMI и загружаем в хранилище. Для тех проектов такая схема вполне рабочая. Хотя именно для постоянной совместной работы над моделями это действительно очень не удобно.

В своём проекте я тоже храню всё в БД. Но схема гораздо сложнее:

Есть много разных видов моделей данных (я пока сосредоточился только на них) - UML, ER, IDEF1x, Anchor, Object-role model и др. Они конечно отличаются друг от друга, но в целом они похожи. Например, где-то есть наследование, где-то - нет. Где-то атрибуты упорядочены и не могут повторно использоваться, а где-то - не упорядочены и могут повторно использоваться. Там ещё куча интересных особенностей типа inner and outer multiplicity и т.п. Короче, в БД все эти виды моделей хранятся в виде некой унифицированной модели данных. Причём, хранятся в нормализованном виде (атрибуты, классы, отношения и т.п. - всё отдельно, а не одним XMI файлом или что-то подобное). Семантическая составляющая (сама модель) и визуальная (диаграммы) тоже хранятся отдельно.

Чтобы отобразить в браузере, например, диаграмму классов UML происходит следующее:
1) Она достаётся из базы в объектную унифицированную JPAшную модель.
2) Преобразуется в Ecore'вскую унифицированную модель данных (она проще, без версионирования)
3) С помощью QVTo преобразований преобразуется в Ecore'вскую UML модель
4) Она преобразуется в DTO для UML моделей
5) Они сериализуются в JSON и передаются на клиент
6) На клиенте JSON преобразуется в экземпляры JavaScript классов

Потом всё это преобразуется в обратном направлении.

Честно говоря там просто огромное количество кода. Но метамодели для этой унифицированной/обобщенной модели данных, для UML моделей, для ER моделей и т.п. у меня описаны на Xcore. А большая часть кода генерится автоматом из Xcore: DTO, JavaScript классы, отображения из Ecore'вских моделей в DTO и обратно.

Эта часть уже реализована и работает.


2. Я пока предполагал, что код будет просто выгружаться и копироваться руками в проект. С другой стороны, уже есть всякие облачные IDE типа Eclipse Orion. Может быть в будущем эта проблема решится сама собой. Я пока не очень об этом думаю.

Насчет конкурентной работы. У меня сделано пока так. Версии моделей неизменяемые, при сохранении всегда создаётся новая версия модели. При одновременном редактировании возникнут параллельные ветки, которые потом придется объединять. Но на начальном этапе будет просто выдаваться предупреждение, что над моделью в данный момент кто-то уже работает. Ещё можно разбивать модели на кусочки, чтобы каждый редактировался и версионировался отдельно. В перспективе, конечно нужен инструмент слияния. Но реально по своему опыту, если модель нормально разбита на части, если за каждую часть отвечает один человек либо работа над моделью идёт поочередно, то конфликтов не возникает и объединять ничего не нужно. Для начала этого будет достаточно.


3. Версионирование у меня реализовано хитрым способом. Как я говорил, модели храняться в базе в нормализованном виде. При любом сохранении создается новая версия. Причём, если в модели переименовали какой-то один атрибут, то в базе создается только этот новый атрибут, а все остальные классы, атрибуты и отношения повторно используются из предыдущей версии модели. При таком подходе можно хоть после каждого изменения сохранять модель и создавать новую версию. Версии неизменяемые поэтому это работает.

Это не то, чтобы хранение diff'ов для каждой последующей версии, но чем-то похоже.

Я серьезно ещё не думал над diff/merge, но наверное если в двух версиях большая часть элементов - это физически одни и те же записи в базе, то сравнение и слияние должно упрощаться.

Да, слияние диаграмм - отдельная жесть. К тому же, диаграммы у меня сейчас для каждой версии хранятся целиком, там нет такого повторного использования как для семантической части.


4. Я пока ограничиваюсь только моделями данных. Поэтому текстовая составляющая там не очень большая. Хотя она есть и это отдельная история. Короче у меня на Xtext сделаны парсер и сериализатор SQL. Там реализовано только нужное мне подмножество (CREATE TABLE, ALTER TABLE и всё, что с ними связано - типы данных, выражения, которые можно писать в ограничениях (это самая объёмная часть), индексы, ключи и т.п. - наверное порядка 70% от стандарта + немного нестандартных вещей из PostgreSQL и T-SQL). Получился такой усредненный SQL.

Оно вполне нормально работает. Есть QVTo преобразования ER моделей в SQL модели. Причем редактор SQL вполне норм работает в браузере с автодополнением и т.п. - Xtext поддерживает это из коробки.

SQL - немного отдельно отдельно от модели. А, вот, типы данных для атрибутов как-раз пишутся непосредственно на диаграмме и там тоже нужно автодополнение, нужно парсить выражения типа VARCHAR(42) и т.п. У меня это реализовано с помощью совершенно безумной схемы. Короче на Xtext описана грамматика SQL (в том числе для SQLных типов данных), из неё автоматом генерится Ecore'вская модель для абстрактных синтаксических деревьев (AST), парсер и сериализатор на Java. А я запилил кодогенератор, который из той же Xtext'овой грамматики генерит JavaScript классы для AST, парсер, сериализатор и автодополнятель(!) на JavaScript.

Я смотрел всякие готовые либы на JavaScript для парсинга/сериализации. Ближе всего был peg.js, но там очень стремно делается автодополнение. И, вообще, все эти либы - это какие-то монстры, проще было написать своё.

С типами данных кроме их редактирования есть ещё одна сложность. Мне хотелось хранить их в базе тоже в унифицированном виде (вместо varchar некий универсальный строковый тип). Есть даже ISOшный стандарт на эту тему и это отчасти у меня реализовано, но не до конца. Мапинг этих унифицированных типов в типы T-SQL, PgSQL, XSD, Java и в обратном направлении - большая отдельная тема.


С рисовалками ровно та же история. Я посмотрел наверное абсолютно все готовые рисовалки на JavaScript. И это просто жесть. Чтобы сделать какие-то банальные вещи типа автодополнения для имен атрибутов или классов, нужно часами курить документацию, вникать в дурацкое API. В итоге всё равно ничего не получится. Сами по себе рисовалки очень не удобны. Во многих из них огромное количество legacy кода для поддержки IE 5.0 или чего-то подобного. Кстати в одном из репозиториев у нас используется joint.js, но как по мне полный отстой. Самая большая их проблема то, что это просто рисовалки картинок, а не моделей. Там куча лишнего типа шрифтов, цветов и т.п., а нужных вещей нет. Я посмотрел на всё это, плюнул и сделал свою рисовалку на d3.js. Она вполне работает, есть line routing, но пока там много багов. Но как по мне, это в 100 раз лучше и удобней любой существующей рисовалки. Например, между атрибутами класса там можно перемещаться с помощью стрелочек. Для удаления атрибута достаточно удалить его имя, для добавления нового - нажать Enter. В том же RSA - куча каких-то дополнительных окон со свойствами, контекстных меню, выпадающих списков, там нужно постоянно куда-то кликать. У меня класс можно полностью отредактировать с клавиатуры, никуда не кликая.


5. Я пока мало думаю о коде. Больше об аналитиках или разработчиках БД.


6. Об этом я конечно думал! Ровно для этого у меня и запилен парсер/сериализатор SQL на Xtext. Пока я рассматривал такой сценарий. Рисуем схему данных, генерим SQL, создаем базу, потом что-то с ней делают, теперь генерим измененный SQL для базы, загружаем его в рисовалку, преобразуем в модель, сравниваем с исходной моделью. В значительной степени это уже реализовано (за исключением сравнения, о котором я пока не думаю, хотя это самое сложное). Совершенно аналогично это будет работать для других языков типа Java и т.п. Кроме SQL я писал парсер/сериализатор XPath, генерил XSLT, Java - там схема везде одна. Эти парсеры и кодогенераторы относительно легко пилятся на Xtext. После парсера SQL мне кажется я смогу сделать любой. SQL - это лютая жесть, там на уровне грамматики описаны вещи, которые в большинстве языков выносятся в стандартную библиотеку, поэтому язык очень большой. Хотя, с другой стороны, при написании кодогенераторов это наоборот удобней.

Единственное, по идее, это должны быть какие-то разовые операции. Например, у нас есть схема БД, мы её преобразовали в модель и затем меняем только модель, а схему перегенерируем на основе модели. Аналогично с кодом: должно быть четкое разделение между автогенерируемым и редактируемым кодом.


7. Тут я не вижу сложностей. Кодогенерация происходит на свервере. Причём, там используются готовые инструменты (Xtext, QVTo) и в принципе, они могут быть отчуждаемыми от рисовалки. Более того, они даже могут быть встроены в каждый проект, в котором используются. Например, в моей рисовалке уже используется несколько кодогенераторов. Это будет выглядеть примерно следующим образом. Рисуем модель, сохраняем её рядом с исходниками в проект. При сборке проекта генерятся нужные артефакты. Я ровно к этой схеме сейчас и стремлюсь. Чтобы, например, схему данных я описывал не в виде JPA классов, а рисовал бы её и JPA классы уже генерил автоматом. Также как у меня сейчас генерятся DTO, всякие мапинги или JavaScript классы.


8. Я кстати как-раз выступал на вашей конференции PSI 2017 :) рассказывал про один из наших репозиториев для моделей, в котором из OCL генерится XSLT и Java для валидации документов (статья и презентация). Эта штука используется в реальных проектах, о которых я не могу много писать. Например, упоминается в СТО БР НПС-1.0-2017.

Мне пока пришлось забить на рисовалку. Последний год занимался этой штукой. Оказалось, что там много чего не доделано, хочу доделать и вернуться к рисовалке. Хочется сначала запилить какую-то первую рабочую версию и потом уже её продвигать. Но, блин, там очень большой объём работы, хотя и сделано уже очень много. У меня есть ощущение, что я крякну раньше, чем доделаю её :) Спасибо за предложение! Разберусь с текущими проектами, попробую запустить первую рабочую версию, тогда будет повод для выступления у вас.
5 май 19, 00:28    [21877935]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
serge79y
Member

Откуда: Москва
Сообщений: 31
Ares_ekb,

1. Понятно, слишком много конверсий данных. На больших моделях будут тормоза.
В design manager-е EMF модели переводили в RDF вид и потом обратно. В рез-те перфоманс был далеко не ахти, а у вас конверсий еще больше.

Советую бинарные протоколы (Protocol buffers + gRPC). В принципе, у меня была идея отмэпить модели на определенную структуру директорий и файлов и использовать просто Git (JGit если сервак на Java) для трэкинга изменений и версионирования. Только руки не дошли. Второй идеей была использовать operational transformation и хранить модели как цепочки операций их создающих..

2. Вы оптимистичны и просто не сталкивались с ворохом проблем при мерже моделей. Мержить и сравнивать надо даже при одиночной работе (чтоб понять что менял, к примеру). Для нормального разбития модели на части нужно понимание как все внутри крутится. От рядового юзера такого ждать нельзя.
Плюс черезмерная гранулированность приводит к своим проблемам при рефакторинге. EMF при сериализации кросс-ресурсные референсы сериализует в духе platform:/resource/<path>#<id>, т.е включает имя физического ресурса где лежит элемент. Тем самым любой cross-resource move требует обновления всех href(обратных ссылок).
Можно, конечно, переопределить механизмы сериализации, но если исходная модель из RSA/Papyrus/etc то от platform:/resource URI-ев не убежать.

Далее, подразумевать что продукт будет применяться лишь для небольших коллективов и одиночной работы, то там с большой долей вероятности можно вообще отказаться от визуального моделирования. MDA/MDD хотело решить проблему разработки больших систем, но так и не решило.

3. Попробуйте реализовать модель Git-а поверх своей системы хранения.

Ну а проблему с диаграммами в общем виде вообще не решить. Для UML это 100%, т.к для полноценного сравнения диаграмм требуется загрузка всей модели (в случае 3-way merge это 4 копии - ancestor/left/right + result). Без полной загрузки мы не можем нормально отобразить те элементы диаграммы, которые автоматические синтезируются из parent-ов (такое есть в RSA и в большем обьеме в RSA-RTE)

Я за текстовые DSL и диаграммы как средство визуализации. Т.е диаграмма должна генериться из текста для просмотра, а работа только с текстом. Текст мержить и версионировать куда проще :)

4. Ну я занимался исполняемыми моделями главным образом (генерили С++/Java). И в этом контексте без редактирования кода никуда.
Вот презентация нашего продукта (после продажи нас HCL-ю RSA-RTE переименовался RTist)
В районе 3.15 показан Code View, это то, что мы для редактирования кода в модели запилили (на базе CDT Editor-а, запихнут во View, поддерживает табы и автокоммит изменений в модель после потери фокуса)
А где-то с начала 9-й минуты есть демка Compare/Merge-а. Для сего продукта я делал custom версии EGit/JGit-а с заточкой на модели (чтоб можно было мержить наборы файлов как атомарные сущности)
Правда как раз в конце того года ушел из HCL-я, да и коллеги порасходились. Нынче на продукте народу мало осталось...

Для более декларативных вещей как модели данных с мэппингом в/из SQL все попроще. Но мое мнение тут, что визуальные языки (и тем более UML) не нужны. Текстовой DSL будет куда проще и понятней, да и поддержку делать легче.

Точнее так, UML плох во всех случаях, за исключением неформальных диаграмм для презентаций и визуализаций.

Идеал для редактирования класса с клавиатуры это просто текстовой синтаксис. До IBM-а мы на Telelogic работали и делали там продукт Tau, который включал полный текстовой синтаксис почти для всего UML2 (включая statemachine-ы) и у нас можно было на диаграммах использовать и символы и текстовой синтаксис, последний парсился в модель и можно было одновременно иметь
представление и визуальном виде и в виде текста (причем во множестве мест). Синхронизация модели и текста постоянно поддерживалась. Более того, весь текст (имена атрибутов, их типы и т.д) в символах так же получался в рез-те parse/unparse-а модели и тем самым была постоянна синхронизация представлений (поменял имя класса и везде ссылки в текстах обновились автоматом)
К сожалению, IBM зарезал продукт в угоду RSA после покупки :( небольшое описание того, чего понаделали можно найти тут http://www.cas.mcmaster.ca/~smiths/CSRS/Sibbald.pdf )

7. Генерация на серваке не проблема пока обьем генерации не большой. А что если генерится несколько гигов исходников, которые должны билдиться и включаться в общий процесс сборки продуктов ? И параллельно работает много людей которые запускают билды для проверки своих изменений. Черезмерная нагрузка на сервак будет, плюс время на загрузку рез-ов если компиляции должна идти на другой машине (т.е сервак с моделями лишь генерит код но не билдит его)

8. В 2017 я еще в HCL -е был :) В общем, если будет время - заезжайте в ИСП. Мы касались MDD с разных сторон, у каждого свой опыт а истина где-то в середине будет.
5 май 19, 11:24    [21878024]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
serge79y
Я за текстовые DSL и диаграммы как средство визуализации. Т.е диаграмма должна генериться из текста для просмотра, а работа только с текстом. Текст мержить и версионировать куда проще :)

Работа только с текстом убьёт большие модели. Поэтому вашим уделом будет рисование примитивных презентаций вместо реально полезных моделей.

Хотя да, некоторые склонны уверять, мол "мои модели страшно полезны!", но на самом деле выхлопа в виде полезных и реально работающих систем (сгенерированных или как-то частично отображённых с моделей) у таких авторов просто нет. И польза здесь не в умении сконвертировать модель в UML или в XSD, а в возможности ускорить разработку ПО. Примитивные модели разработку ПО только замедляют.
5 май 19, 12:42    [21878045]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mayton
Member

Откуда: loopback
Сообщений: 42897
Интересно. А какие ЯП наиболее приближены к созданию DSL.

Не на библиотечном а именно на языковом уровне.
5 май 19, 13:00    [21878053]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mayton
Member

Откуда: loopback
Сообщений: 42897
alex55555,

Я так думаю что между DSL и моделью нужен некий слой биндинга. Чтобы разделять дизайн и контент.
5 май 19, 13:02    [21878056]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
ViPRos
Member

Откуда:
Сообщений: 9630
mayton,

LINQ
5 май 19, 13:40    [21878065]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
ViPRos
Member

Откуда:
Сообщений: 9630
ViPRos,

К сообщению приложен файл. Размер - 145Kb
5 май 19, 13:44    [21878069]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
serge79y,

спасибо за описание вашей системы! Мне немного напомнило Eclipse Sirius, на нём сделаны похожие инструменты (что-то на тему генерации кода для роботов, мобильных приложений и т.п.). Он хорош тем, что вместо UML там делаются свои специализированные языки моделирования под каждую задачу. Если в UML приходится постоянно применять стереотипы к элементам, заполнять на отдельной вкладке дополнительные атрибуты стереотипов, то в кастомных языках всё гораздо проще. Создаёшь сразу сущность нужного вида без всяких стереотипов, все дополнительные атрибуты можно вытащить сразу на диаграмму. Ну, и визуально для пользователей это гораздо наглядней, чем UML.

Но в моих проектах специфика совсем другая. На самом деле, рисовалка моделей, версионирование, слияние и т.п. - это вещи достаточно технические и вторичные, изначально я хотел взять что-то готовое. Если бы у Eclipse Sirius была веб-версия, я бы просто взял её и не стал бы ничего делать сам. Основная идея в том, чтобы сделать нормальный инструмент моделирования данных.

1) В нём должны быть подсказки по классам, атрибутам, отношениям. Например, пользователь рисует сущность "Транспортное средство", рисовалка может сразу предложить ему на выбор атрибуты для ТС из словаря, связанные сущности (водитель, перевозчик и т.п.). Это основная идея рисовалки. С одной стороны, полно инструментов моделирования, в которых есть словари. Но тут всё немного сложнее чем просто словарь. Поэтому я уделял так много внимания тому, чтобы разные виды моделей данных хранились в нормализованном и унифицированном виде. И проблемы связанные с производительностью для меня совершенно вторичны, главное, что и UML, и ER, и остальные виды моделей укладываются в единую структуру. Если один человек описал какие-то структуры на UML, то все эти сущности, атрибуты и отношения могут повторно использоваться другим человеком, например, в ER модели.

2) Вторая идея - это поддержка разных нотаций для моделей данных. Например, для IDEF1x есть только какая-то древняя жесть. Для Anchor - один единственный редактор. Для Object-role моделей - я вообще не видел редакторов. Хочется собрать всё это в одном месте и чтобы было легко добавлять новые нотации.

3) Преобразования моделей данных из одной нотации в другую. Я хочу реализовать просто все мыслимые преобразования для моделей данных и чтобы они были максимально настраиваемыми. Начиная с банальных вещей типа схемы именования классов, атрибутов и т.п.

4) Поддержка разных платформ. Это разные кодогенераторы и парсеры для SQL, Java, XSD и т.п. И мапинг типов данных (xs:string, varchar, System.String и т.п.)

5) Разделение а) семантической составляющей модели б) представления модели (диаграмма или текст) и в) стилей. Хочется, чтобы модель можно было редактировать хоть в текстовом виде, хотя в виде диаграммы. Тут я совершенно согласен с вами, что для моделей данных текстовая нотация гораздо удобней. Поэтому в моём проекте все модели описаны на Xcore, а не Ecore. Но с другой стороны, диаграммы тоже иногда нужны для наглядности. Кстати, на моей основной работе нам модели данных нужны для проектирования структур документов - для них оптимальная нотация древовидная. На UML их очень неудобно рисовать. Текст тоже не очень подходит, потому что там здоровенные структуры на тысячи реквизитов, дерево удобней всего. Всё равно какой-то одной идеальной нотации нет. Кстати Eclipse Sirius на сколько я помню интегрируется с Xtext и там есть параллельное редактирование модели в виде диаграмм, деревьев, таблиц и текста.

И ещё важная фишка, которой нет ни в одном инструменте моделирования - это отделение стилей. Мне совершенно не нужно раскрашивать и менять шрифты для каждого квадратика на диаграмме. Очень хочется задавать такие вещи через стили в одном месте.

6) Наконец, редактор должен быть максимально простым и удобным. Чтобы его не нужно было скачивать, устанавливать, чтобы там не было вообще никаких визардов, менюшек, вкладок и т.п. На столько минималистичный интерфейс на сколько это возможно. Если там не будет сложной функциональности по слиянию моделей или чего-то подобного, то в принципе и фиг с ним. Это вторичные вещи. На основной работе мы делали большие модели и данных, и процессов для межгосударственного взаимодействия - реально, слияние моделей - это одна из последних вещей, которая там нужна.

Т.е. у меня не какой-то инструмент моделирования общего назначения, а достаточно узконаправленный. Но такой, чтобы в этом узком направлении всё было идеально.


Насчет сравнения моделей. У нас запилен инструмент, который формирует лист изменений, этого было вполне достаточно. Зато у нас есть специфика, которой наверняка нет в ваших проектах :) Это валидация и оценка качества моделей. Для валидации порядка 200 OCL правил. И ещё с полсотни правил на оценку качества (типа отсутствие смысловых дублей, правильное выделение объектов, сохранение обратной совместимости и т.п.).


Насчет применения MDD для больших систем. У нас системы достаточно большие :) Вопрос только для чего используется MDD. Если нужно полностью сгенерить какое-то приложение с нетиповой функциональностью то, да, это проблема. Но сгенерить правила ФЛК из модели - проще. Я бы не сказал, что это прям на столько просто, что школьник за пару вечеров запилит. Там очень много своих нюансов. Мы 5 с лишним лет назад сделали этот генератор, и всё равно до сих пор там находятся какие-то вещи для улучшения. ФЛК - это конечно очень узкое направление, но если учесть сколько этих правил ФЛК, какое количество участников взаимодействия, сколько аналитиков проектируют эти процессы, структуры и ФЛК и т.п. - то это вполне себе большая система.

Если у вас модели ориентированы на реализацию. То у нас они более бизнесовые, в основном из моделей генерятся документы. А из технических вещей - только XSD и XSLT/Java для ФЛК. В принципе, можно было бы генерить и больше технических артефактов, но заказчикам это просто не нужно. В моём проекте кода генерится уже гораздо больше, но тоже всё это вертится вокруг моделей данных (схемы данных, валидация данных, мапинг данных и т.п.). Какой-то код общего назначения у меня вряд ли будет генериться.


Насчет проблем с генерацией на серваке. Во-первых, у меня пока только модель данных и там не очень много кода и меняются модели медленно. Во-вторых, да, генератор будет отчуждаемый.
5 май 19, 14:54    [21878101]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mayton,

классический пример - это Lisp. У него нет как такового синтаксиса, фактически ты пишешь код сразу в виде синтаксического дерева. Что это даёт... Например, в Java или C# уже из коробки определен синтаксис для классов, методов, интерфейсов и т.п. А в лиспах или схемах в ядре языка ничего этого нет, и объектная система пишется уже на самом лиспе - например CLOS или какой-то её аналог. Аспектно-ориентированное программирование тоже реализуется аналогично - не нужно придумывать какие-то аннотации, какие-то инструменты для их обработки. Лисп очень легко расширять подобными DSL для объектной системы и т.п.

Ещё интересный пример - Isabelle HOL. Это не ЯП, а помощник для доказательства теорем. У него фишка в том, что в нём есть два синтаксиса - внешний и внутренний. Внешний достаточно фиксированный, а внутренний можешь определять как хочешь. Например, мне понадобился DSL для описания всё тех же объектных моделей и чтобы ещё методы у классов можно было писать на языке OCL. Кусок кода на Isabelle HOL на картинке ниже. Внешний синтаксис - это definition, nonterminal, syntax и т.п. А всё что внтури двойных кавычек - это внутренний синтаксис. Я запилил себе всякие конструкции - enum, class, association и т.п. (слева на картинке). А справа на картинке определение этого DSL. На первый взгляд ничего не понятно, но если вникнуть - это просто офигенная штука, там используются priority grammars.

Короче, в Isabelle HOL очень легко встраивать разные DSL. Isabelle HOL используется для формальной верификации, для генерации верифицированного кода и т.п.

А, вообще, очень прикольно писать DSL на Xtext. Если не стоит задача встраивать DSL в какой-то другой код, то Xtext - оптимальный вариант.

К сообщению приложен файл. Размер - 103Kb
5 май 19, 15:36    [21878126]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
serge79y
Member

Откуда: Москва
Сообщений: 31
Ares_ekb
serge79y,
Насчет сравнения моделей. У нас запилен инструмент, который формирует лист изменений, этого было вполне достаточно. Зато у нас есть специфика, которой наверняка нет в ваших проектах :) Это валидация и оценка качества моделей. Для валидации порядка 200 OCL правил. И ещё с полсотни правил на оценку качества (типа отсутствие смысловых дублей, правильное выделение объектов, сохранение обратной совместимости и т.п.).


Ну продукт, какой мы в Telelogic-е делали имел под 500 правил. Причем ряд правил применялись автоматические когда юзер редактирует модель (скажем репорт unresolved имен и т.п, полноценный name resolution был), ряд когда нажимал кнопку check/check all (можно было чекать подмножество) и ряд когда генерация кода.
Изначально, мы сделали генератор OCL -> C++ для написания правил, но оказалось, что императивно писать правила удобней. Я сделал моторчик для semantic checker-а, который так же имел Tcl API/COM/public C++ API и позволял группировать чеки в иерархии групп с динамическими зависимостями меж собой и возможностью включать и отключать в зависимости от разных событий. Так можно было пометить часть модели как informal и чеки ее игнорили.
Минус OCL-я для чеков - не удобно репортить ошибки где в текст надо запихать ссылки на обьекты из контекста. Ну там "Тип Х не может быть использован в данном месте, возможные типы А, Б,С". OCL подразумевает, что если constraint не сработал, то репортим какой-то текст. А текст желательно информативным делать. Еще одна проблема - производительность. В императивном стиле проще оптимизировать, кэши добавить и т.п.
Хотя для декларативных моделей OCL подойдет, где constraint-ы простые. Если constraint-ы приближаются по сложности к семантическому анализу и разрешению имен в С++-подобных языках, то OCL-ем не отделаешся.
5 май 19, 16:41    [21878154]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
serge79y
Member

Откуда: Москва
Сообщений: 31
alex55555
serge79y
Я за текстовые DSL и диаграммы как средство визуализации. Т.е диаграмма должна генериться из текста для просмотра, а работа только с текстом. Текст мержить и версионировать куда проще :)

Работа только с текстом убьёт большие модели. Поэтому вашим уделом будет рисование примитивных презентаций вместо реально полезных моделей.

Хотя да, некоторые склонны уверять, мол "мои модели страшно полезны!", но на самом деле выхлопа в виде полезных и реально работающих систем (сгенерированных или как-то частично отображённых с моделей) у таких авторов просто нет. И польза здесь не в умении сконвертировать модель в UML или в XSD, а в возможности ускорить разработку ПО. Примитивные модели разработку ПО только замедляют.



Я сказал не просто так а исходя из опыта, где у нас были здоровые модели заточенные на генерацию кода. Наши customer-ы потихоньку все переходят либо напрямую на код, либо на некие аналоги текстовых DSL (или мета-программирования средствами языка, если С++ ) Так что текст круче чем визуальное моделирование (само собой в контексте софта, а не всяких САПР, схемотехники и т.п)
5 май 19, 16:44    [21878157]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
serge79y
Точнее так, UML плох во всех случаях, за исключением неформальных диаграмм для презентаций и визуализаций.


Согласен с вашими тезисами.
Что лучше из текста делать диаграмму, а не наоборот.
Но если есть текст и те кто его могут читать, то зачем диаграммы?
Текст можно сразу писать на нужном ЯП :-)
6 май 19, 06:55    [21878353]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
serge79y
Member

Откуда: Москва
Сообщений: 31
mad_nazgul
serge79y
Точнее так, UML плох во всех случаях, за исключением неформальных диаграмм для презентаций и визуализаций.


Согласен с вашими тезисами.
Что лучше из текста делать диаграмму, а не наоборот.
Но если есть текст и те кто его могут читать, то зачем диаграммы?
Текст можно сразу писать на нужном ЯП :-)


Вы забываете про манагеров и прочих сопуствующих товарищей. А так же про конференции и презентации.
Текст на слайде любят не все. Люди хотят картинки.

Ну и диаграммы могут помочь в понимании системы. Особенно в контексте reverse engineering-а. Или показ Type Hiearchy/ Call Graph-а и т.п - это примеры, когда диаграмма (точнее визуальное представление) генерится из текста, но не является первичным артефактом.

UML плох еще по собственным фундаментальным причинам. Кстати. по стандарту, диаграмм в нем тоже нет (и в этом одна из причин проблем "стандарта"). UML не был приспособлен для больших систем, т.к механизм деления модели на физические куски не был рассмотрен на уровне стандарта.

Плюс в UML не было предусмотрено такое понятие как "ссылка по имени". Скажем, Generalization должен идти к обьекту, нельзя просто указать имя parent-a. Т.е понятие "связывание имен" в UML модели нет (в отличии от любого языка программирования)
Это сильно затрудняет модульность. Производители тулов вынуждены были делать свои решения.

Да, EMF тоже от этого страдает. Понятие Proxy-обьекта есть, но конкретно ссылок по имени с состоянием resolved (bound)/unresolved(unbound) нет. В EMF proxy это URI, обычно с именем ресурса и xmi:id обьекта. Это тоже не удобно.
Нельзя указать тип атрубта по имени и биндить его к нужному объекту в зависимости от контекста (скажем, загруженных model library). Да и синтаксиса для типов с template parameter-ами нет. Механизм использования шаблонов в UML неудобоварим на практике. TemplateBinding...бррр
6 май 19, 09:14    [21878392]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

можно писать сразу на ЯП.

Например, вот, правило ФЛК:
если реквизит «Цель представления предварительной информации (casdo:PreliminaryInformationUsageCode)» содержит 1 из значений: «11», «12», «13», реквизит «Цель представления предварительной информации (casdo:PreliminaryInformationUsageCode)» не содержит значение «01», реквизит «Регистрационный номер предварительной информации (cacdo:PreliminaryInformationIdDetails)» не заполнен, то реквизит «Регистрационный номер транспортного средства (csdo:TransportMeansRegId)» должен быть заполнен

Вот, оно на DSL:
PreliminaryInformationUsageCode->exists(code | Set{'11', '12', '13'}->includes(code)) and
PreliminaryInformationUsageCode->excludes('01') and
PreliminaryInformationIdDetails->isEmpty()
implies
PIATBorderTransportDetails->forAll(TransportMeansRegId->notEmpty())

Вот, оно на Java:
@RuleMetadata(id = "782", description = "если реквизит ...", ocl = "PreliminaryInformationUsageCode->exists(...")
public void check_782(List<RuleResult> results) {
    final XdmNode _j_self = Helper.getNode(root, "/atpi:AutoPreliminaryInformation");
    final Variable _x_self = Helper.variable(_j_self, "self");
    if (Helper.evaluateBool(_j_self,
            "$self/[. = (\'11\',\'12\',\'13\')] and fn:not(\'01\' = $self/) and fn:not($self/)",
            Arrays.asList(_x_self))) {
        final Iterable<XdmNode> _list__1 = Helper.iterate(_j_self, "$self/", Arrays.asList(_x_self));
        if (!_list__1.iterator().hasNext()) {
            results.add(Helper.absent(_j_self, Arrays.asList(_x_self), Arrays.asList("$self/")));
            return;
        }
        for (final XdmNode _j__1 : _list__1) {
            final Variable _x__1 = Helper.variable(_j__1, "_1");
            results.add(Helper.check(_j__1, "fn:boolean($_1/)", Arrays.asList(_x_self, _x__1),
                    Arrays.asList(), Arrays.asList("$_1/")));
        }
    }
    else {
        results.add(Helper.irrelevant(_j_self, Arrays.asList(_x_self), Arrays.asList("$self/")));
    }
}

Вот, на XSLT:
<xsl:variable name="__code">782</xsl:variable>
<xsl:variable name="__definition">если реквизит ...</xsl:variable>
<xsl:variable name="__ocl">PreliminaryInformationUsageCode-&gt;exists(...</xsl:variable>
<xsl:choose>
  <xsl:when test="$__context/casdo:PreliminaryInformationUsageCode[. = ('11','12','13')]
                  and fn:not('01' = $__context/casdo:PreliminaryInformationUsageCode)
                  and fn:not($__context/cacdo:PreliminaryInformationIdDetails)">
    <xsl:variable name="__items" as="item()*">
      <xsl:for-each select="$__context/cacdo:PIATBorderTransportDetails">
        <xsl:variable name="_1" select="."/>
        <xsl:call-template name="validate">
          <xsl:with-param name="code" select="$__code"/>
          <xsl:with-param name="isValid" select="fn:boolean($_1/csdo:TransportMeansRegId)"/>
          <xsl:with-param name="elements">
            <xsl:choose>
              <xsl:when test="$_1/csdo:TransportMeansRegId">
                <xsl:call-template name="element">
                  <xsl:with-param name="nodes" select="$_1/csdo:TransportMeansRegId"/>
                </xsl:call-template>
              </xsl:when>
              <xsl:when test="$_1">
                <xsl:call-template name="element">
                  <xsl:with-param name="nodes" select="$_1"/>
                  <xsl:with-param name="tail">csdo:TransportMeansRegId</xsl:with-param>
                </xsl:call-template>
              </xsl:when>
            </xsl:choose>
            <xsl:choose>
              <xsl:when test="$__context">
                <xsl:call-template name="element">
                  <xsl:with-param name="nodes" select="$__context"/>
                </xsl:call-template>
              </xsl:when>
            </xsl:choose>
          </xsl:with-param>
          <xsl:with-param name="definition" select="$__definition"/>
          <xsl:with-param name="ocl" select="$__ocl"/>
          <xsl:with-param name="error"/>
        </xsl:call-template>
      </xsl:for-each>
    </xsl:variable>
    <xsl:copy-of select="$__items"/>
    <xsl:if test="fn:empty($__items)">
      <xsl:call-template name="info">
        <xsl:with-param name="kind">absent</xsl:with-param>
        <xsl:with-param name="code" select="$__code"/>
        <xsl:with-param name="elements">
          <xsl:choose>
            <xsl:when test="$__context/cacdo:PIATBorderTransportDetails">
              <xsl:call-template name="element">
                <xsl:with-param name="nodes" select="$__context/cacdo:PIATBorderTransportDetails"/>
              </xsl:call-template>
            </xsl:when>
            <xsl:when test="$__context">
              <xsl:call-template name="element">
                <xsl:with-param name="nodes" select="$__context"/>
                <xsl:with-param name="tail">cacdo:PIATBorderTransportDetails</xsl:with-param>
              </xsl:call-template>
            </xsl:when>
          </xsl:choose>
        </xsl:with-param>
        <xsl:with-param name="definition" select="$__definition"/>
        <xsl:with-param name="ocl" select="$__ocl"/>
      </xsl:call-template>
    </xsl:if>
  </xsl:when>
  <xsl:otherwise>
    <xsl:call-template name="info">
      <xsl:with-param name="kind">irrelevant</xsl:with-param>
      <xsl:with-param name="code" select="$__code"/>
      <xsl:with-param name="elements">
        <xsl:choose>
          <xsl:when test="$__context/casdo:PreliminaryInformationUsageCode">
            <xsl:call-template name="element">
              <xsl:with-param name="nodes" select="$__context/casdo:PreliminaryInformationUsageCode"/>
            </xsl:call-template>
          </xsl:when>
          <xsl:when test="$__context">
            <xsl:call-template name="element">
              <xsl:with-param name="nodes" select="$__context"/>
              <xsl:with-param name="tail">casdo:PreliminaryInformationUsageCode</xsl:with-param>
            </xsl:call-template>
          </xsl:when>
        </xsl:choose>
        <xsl:choose>
          <xsl:when test="$__context/casdo:PreliminaryInformationUsageCode">
            <xsl:call-template name="element">
              <xsl:with-param name="nodes" select="$__context/casdo:PreliminaryInformationUsageCode"/>
            </xsl:call-template>
          </xsl:when>
          <xsl:when test="$__context">
            <xsl:call-template name="element">
              <xsl:with-param name="nodes" select="$__context"/>
              <xsl:with-param name="tail">casdo:PreliminaryInformationUsageCode</xsl:with-param>
            </xsl:call-template>
          </xsl:when>
        </xsl:choose>
        <xsl:choose>
          <xsl:when test="$__context/cacdo:PreliminaryInformationIdDetails">
            <xsl:call-template name="element">
              <xsl:with-param name="nodes" select="$__context/cacdo:PreliminaryInformationIdDetails"/>
            </xsl:call-template>
          </xsl:when>
          <xsl:when test="$__context">
            <xsl:call-template name="element">
              <xsl:with-param name="nodes" select="$__context"/>
              <xsl:with-param name="tail">cacdo:PreliminaryInformationIdDetails</xsl:with-param>
            </xsl:call-template>
          </xsl:when>
        </xsl:choose>
        <xsl:choose>
          <xsl:when test="$__context/cacdo:PIATBorderTransportDetails">
            <xsl:call-template name="element">
              <xsl:with-param name="nodes" select="$__context/cacdo:PIATBorderTransportDetails"/>
            </xsl:call-template>
          </xsl:when>
          <xsl:when test="$__context">
            <xsl:call-template name="element">
              <xsl:with-param name="nodes" select="$__context"/>
              <xsl:with-param name="tail">cacdo:PIATBorderTransportDetails</xsl:with-param>
            </xsl:call-template>
          </xsl:when>
        </xsl:choose>
      </xsl:with-param>
      <xsl:with-param name="definition" select="$__definition"/>
      <xsl:with-param name="ocl" select="$__ocl"/>
    </xsl:call-template>
  </xsl:otherwise>
</xsl:choose>


В реализации так много кода, потому что нужно различать ситуации: успех, ошибка, не выполнено предусловие в правиле и поэтому нечего проверять, нет подходящих элементов в документе и поэтому нечего проверять. Также нужно в результатах выводить путь к провалидированным элементам.

Понятно, что конкретно под это правило можно написать более оптимальный и компактный код. Но в этом смысла столько же сколько в том, чтобы отказаться от языков высокого уровня и писать всё на ассемблере. Или отказаться от SQL.

DSL нужны чтобы скрыть технические детали реализации. Выражения на DSL можно анализировать и добавлять в реализацию кучу логики, которой в исходном выражении нет. В этом примере видно, что в коде появляются условия и циклы, которых в исходном выражении даже близко нет. Ровно также когда вы пишите код на SQL или LINQ вы не пишите условия, циклы и т.п.
6 май 19, 09:33    [21878402]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
serge79y
Кстати. по стандарту, диаграмм в нем тоже нет (и в этом одна из причин проблем "стандарта").
Это проблема, нам приходилось выгружать модель в XMI, а диаграммы в SVG для загрузки в хранилище. Но в UML 2.5 диаграммы уже добавили, осталось дождаться когда это реализуют хотя бы в нескольких основных редакторах.

Ещё в стандарте были разные мелкие неоднозначности. Например, разработчики Eclipse OCL считали, что у типов данных в UML не может быть операций, а только у классов. А мы понимали стандарт так, что у типов они тоже могут быть.

В целом, UML плох для 1) концептуального моделирования, для этого лучше подходят модели с "открытым миром" - RDF, OWL и т.п. 2) для проектирования структур документов, потому что они древовидные (а если каждый узел дерева - это отдельный класс, то запаришься переходить от класса к классу в UML модели).

Ещё профили и стереотипы конечно позволяют не изобретать новый язык моделирования. Но если стереотипов достаточно много, то проще сделать специализированный язык моделирования, чем использовать UML.
6 май 19, 09:55    [21878434]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
Java-код в примере выше неправильный :) Я как-раз переделываю генератор под другую модель, съелись имена XML элементов.

В этом и плюс кодогенераторов, нашел ошибку, исправил генератор, перегенерил всё:
@RuleMetadata(id = "782", name = "782", description = "если реквизит ...", ocl = "PreliminaryInformationUsageCode->exists(...")
public void check_782(List<RuleResult> results) {
    final XdmNode _j_self = Helper.getNode(root, "/atpi:AutoPreliminaryInformation");
    final Variable _x_self = Helper.variable(_j_self, "self");
    if (Helper.evaluateBool(_j_self,
            "$self/casdo:PreliminaryInformationUsageCode[. = (\'11\',\'12\',\'13\')]"
            + " and fn:not(\'01\' = $self/casdo:PreliminaryInformationUsageCode)"
            + " and fn:not($self/cacdo:PreliminaryInformationIdDetails)",
            Arrays.asList(_x_self))) {
        final Iterable<XdmNode> _list__1 = Helper.iterate(_j_self, "$self/cacdo:PIATBorderTransportDetails",
                Arrays.asList(_x_self));
        if (!_list__1.iterator().hasNext()) {
            results.add(Helper.absent(_j_self, Arrays.asList(_x_self),
                    Arrays.asList("$self/cacdo:PIATBorderTransportDetails")));
            return;
        }
        for (final XdmNode _j__1 : _list__1) {
            final Variable _x__1 = Helper.variable(_j__1, "_1");
            results.add(Helper.check(_j__1, "fn:boolean($_1/csdo:TransportMeansRegId)",
                    Arrays.asList(_x_self, _x__1), Arrays.asList(),
                    Arrays.asList("$_1/csdo:TransportMeansRegId")));
        }
    }
    else {
        results.add(Helper.irrelevant(_j_self, Arrays.asList(_x_self),
                Arrays.asList("$self/casdo:PreliminaryInformationUsageCode",
                        "$self/cacdo:PreliminaryInformationIdDetails",
                        "$self/cacdo:PIATBorderTransportDetails")));
    }
}
6 май 19, 10:20    [21878461]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
serge79y
Member

Откуда: Москва
Сообщений: 31
Ares_ekb
serge79y
Кстати. по стандарту, диаграмм в нем тоже нет (и в этом одна из причин проблем "стандарта").
Это проблема, нам приходилось выгружать модель в XMI, а диаграммы в SVG для загрузки в хранилище. Но в UML 2.5 диаграммы уже добавили, осталось дождаться когда это реализуют хотя бы в нескольких основных редакторах.

Ещё профили и стереотипы конечно позволяют не изобретать новый язык моделирования. Но если стереотипов достаточно много, то проще сделать специализированный язык моделирования, чем использовать UML.


Все GMF-based редакторы базируются на GMF Notation model. Переделывать под стандарт навряд ли будут.
RSA точно не будут. Он ведь продан HCL, пишется теперь одними индусами, причем из изначальной команды, кто хоть как-то был причастенкс истокам продукта осталось два индуса и они совершенно не хотят заниматься RSA. Да и в скиллов нема у них для такой работы....

Переход на новую notation model это большой геммор. Существующие продукты навряд ли будут передывать.

Профайлы - это еще одна беда UML. Как раз в контексте контроля версий. Если у нас есть две версии, их общий предок и каждая версия и предок имеют профайлы разных версий, то сравнивать и мержить такое проблематично.
Плюс в UML2 SDK в Eclipse есть дефект с миграцией модели на профайл новой версии. Миграция может менять xmi:id на рэндомные для stereotype application-ов в ресурсе. Мне пришлось свой метод писать для апгрейда версий профайла из-за этого....
6 май 19, 10:37    [21878484]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
DSL нужны чтобы скрыть технические детали реализации. Выражения на DSL можно анализировать и добавлять в реализацию кучу логики, которой в исходном выражении нет. В этом примере видно, что в коде появляются условия и циклы, которых в исходном выражении даже близко нет. Ровно также когда вы пишите код на SQL или LINQ вы не пишите условия, циклы и т.п.


Ну дык DSL можно писать и на Java для Java.
Хотя больше эту тему форсят JetBrains в Kotlin.

Насчет "манагеров", то пусть рисуют, только с этими картинками к программистам не надо лезть.
Все равно программировать не умеют. :-)
6 май 19, 11:08    [21878512]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

а вы думаете на чём у меня этот DSL реализован? На Java все парсеры/сериализаторы и реализованы + преобразования моделей на QVTo.
6 май 19, 11:14    [21878522]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul
Насчет "манагеров", то пусть рисуют, только с этими картинками к программистам не надо лезть.
Все равно программировать не умеют. :-)

А программисты тут для написания ФЛК нафиг и не нужны. Их пишут аналитики, а программист нужен только чтобы написать кодогенератор один раз и всё.
6 май 19, 11:18    [21878526]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
mad_nazgul
Насчет "манагеров", то пусть рисуют, только с этими картинками к программистам не надо лезть.
Все равно программировать не умеют. :-)

А программисты тут для написания ФЛК нафиг и не нужны. Их пишут аналитики, а программист нужен только чтобы написать кодогенератор один раз и всё.


Абстракции дырявы.
Есть правда одна "универсальная" система для написания ФЛК - regexp.
Но как то, для среднестатистического менеджера - "СЛОЖНА".
Да и для среднестатистического программиста то же не просто.
6 май 19, 14:15    [21878912]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

и какой выход? Уволить маркетологов/менеджеров и дать программистам спокойно писать ФЛК в коде? Спасибо, но, нет, я слишком ленивый, чтобы писать их руками. Пусть их пишут аналитики, а я буду просто генерить нужный код. Мне проще и интересней написать генератор, чем заниматься тупой рутиной.

Для regexp достаточно XSD, там вообще писать ничего не надо.
6 май 19, 15:17    [21879049]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mayton
Member

Откуда: loopback
Сообщений: 42897
Ares_ekb
mayton,

классический пример - это Lisp. У него нет как такового синтаксиса, фактически ты пишешь код сразу в виде синтаксического дерева. Что это даёт... Например, в Java или C# уже из коробки определен синтаксис для классов, методов, интерфейсов и т.п. А в лиспах или схемах в ядре языка ничего этого нет, и объектная система пишется уже на самом лиспе - например CLOS или какой-то её аналог. Аспектно-ориентированное программирование тоже реализуется аналогично - не нужно придумывать какие-то аннотации, какие-то инструменты для их обработки. Лисп очень легко расширять подобными DSL для объектной системы и т.п.

Ещё интересный пример - Isabelle HOL. Это не ЯП, а помощник для доказательства теорем. У него фишка в том, что в нём есть два синтаксиса - внешний и внутренний. Внешний достаточно фиксированный, а внутренний можешь определять как хочешь. Например, мне понадобился DSL для описания всё тех же объектных моделей и чтобы ещё методы у классов можно было писать на языке OCL. Кусок кода на Isabelle HOL на картинке ниже. Внешний синтаксис - это definition, nonterminal, syntax и т.п. А всё что внтури двойных кавычек - это внутренний синтаксис. Я запилил себе всякие конструкции - enum, class, association и т.п. (слева на картинке). А справа на картинке определение этого DSL. На первый взгляд ничего не понятно, но если вникнуть - это просто офигенная штука, там используются priority grammars.

Короче, в Isabelle HOL очень легко встраивать разные DSL. Isabelle HOL используется для формальной верификации, для генерации верифицированного кода и т.п.

+100

В своих книжных развалах (натырил книг на гос-предприятиях) у меня завлалялась книжка по языку Forth.
Вобщем из нее следует что Форт это самый что ни есть DSL и вообще круче некуда. Попробую найти цитату.

По поводу современных DSL. Что вы думаете про Groovy?
6 май 19, 15:26    [21879056]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
mad_nazgul,

и какой выход? Уволить маркетологов/менеджеров и дать программистам спокойно писать ФЛК в коде? Спасибо, но, нет, я слишком ленивый, чтобы писать их руками. Пусть их пишут аналитики, а я буду просто генерить нужный код. Мне проще и интересней написать генератор, чем заниматься тупой рутиной.


Так не надо даже писать.
Есть regexp-же :-)

Ares_ekb
Для regexp достаточно XSD, там вообще писать ничего не надо.


Чта?!
Какое отношение XSD имеет к регулярным выражения?!
6 май 19, 15:34    [21879065]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

слишком наркоманский тролинг. Регулярки можно зашить в XSD и никакие дополнительные ФЛК писать не надо:
<xs:simpleType name="CountryCodeType">
  <xs:restriction base="xs:string">
    <xs:pattern value="[A-Z]{2}"/>
  </xs:restriction>
</xs:simpleType>

Очевидно, что регулярками не покрыть все ФЛК, пример был выше.
6 май 19, 16:45    [21879152]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mayton
Member

Откуда: loopback
Сообщений: 42897
Гуглил ФЛК....

Футбольный любительский клаб? Финансы Лизинг Кредитование?
6 май 19, 16:48    [21879158]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
форматно-логический контроль
6 май 19, 17:06    [21879184]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mayton,

Groovy как таковым я никогда не пользовался, если не считать Gradle. Интересная штука. Но это всё в основном надстройки над языками программирования - EDSL или синтаксический сахар. Сейчас из "улучшенных Java" гораздо популярнее Scala или Kotlin. У Groovy мне кажется очень ограниченное применение.

Я лично больше занимаюсь вещами, которые с другого конца относительно языков программирования - прикладные (бизнесовые) модели процессов, данных. Возможно я вообще сильно оторвался от мира программирования. Например, у нас были лютые споры с разработчиками на некоторых проектах. Они считали полным бредом использовать OCL для написания правил ФЛК. Что это вообще за язык, нет ни одной вакансии где требовалось бы его знание. И кажется они как-раз предлагали запилить DSL на Groovy или использовать JavaScript или что-то подобное - я не помню уже точно, но приближенное именно к языкам программирования, а не языкам моделирования или спецификации. Или они считали полным бредом писать на QVTo транслятор с одного языка на другой, когда это можно сделать на Java (правда они так и не сделали). А с другой стороны есть предметники, для которых что OCL, что JavaScript, что Groovy - это всё какая-то жесть, в которой они ничего не понимают и им это не нужно. Нормативный документ с JavaScript кодом ни один предметник никогда не подпишет. А нам нужно найти какой-то баланс, чтобы эти модели и DSL для предметников не были слишком техническими, привязанными к какому-то конкретному стеку технологий, но чтобы с другой стороны были более формальными, чем русский язык, к которому они привыкли.
6 май 19, 21:00    [21879380]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
serge79y
Member

Откуда: Москва
Сообщений: 31
Ares_ekb
mayton,

Groovy как таковым я никогда не пользовался, если не считать Gradle. Интересная штука. Но это всё в основном надстройки над языками программирования - EDSL или синтаксический сахар. Сейчас из "улучшенных Java" гораздо популярнее Scala или Kotlin. У Groovy мне кажется очень ограниченное применение.

Я лично больше занимаюсь вещами, которые с другого конца относительно языков программирования - прикладные (бизнесовые) модели процессов, данных. Возможно я вообще сильно оторвался от мира программирования. Например, у нас были лютые споры с разработчиками на некоторых проектах. Они считали полным бредом использовать OCL для написания правил ФЛК. Что это вообще за язык, нет ни одной вакансии где требовалось бы его знание. И кажется они как-раз предлагали запилить DSL на Groovy или использовать JavaScript или что-то подобное - я не помню уже точно, но приближенное именно к языкам программирования, а не языкам моделирования или спецификации. Или они считали полным бредом писать на QVTo транслятор с одного языка на другой, когда это можно сделать на Java (правда они так и не сделали). А с другой стороны есть предметники, для которых что OCL, что JavaScript, что Groovy - это всё какая-то жесть, в которой они ничего не понимают и им это не нужно. Нормативный документ с JavaScript кодом ни один предметник никогда не подпишет. А нам нужно найти какой-то баланс, чтобы эти модели и DSL для предметников не были слишком техническими, привязанными к какому-то конкретному стеку технологий, но чтобы с другой стороны были более формальными, чем русский язык, к которому они привыкли.


Можно использовать синтаксис существующего ЯП, но наделить все другой семантикой. Тогда просто используем весь арсенал парсеров и трансформаторов АСТа для данного ЯП, но со своим целями. Для этих целей лучше подходят языки типа Java, где грамматика может иметь несколько точек входа - compilation unit, expression, method/statement. Это позволит парсить куски текста без полного контекста.
7 май 19, 23:39    [21880449]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
mad_nazgul,

слишком наркоманский тролинг. Регулярки можно зашить в XSD и никакие дополнительные ФЛК писать не надо:
<xs:simpleType name="CountryCodeType">
  <xs:restriction base="xs:string">
    <xs:pattern value="[A-Z]{2}"/>
  </xs:restriction>
</xs:simpleType>

Очевидно, что регулярками не покрыть все ФЛК, пример был выше.


Прошу прощения я спрашивал, не какое отношение регулярные выражения имеют к XSD (регулярные выражения можно использовать почти во всех ЯП и не только). А какое отношение XSD имеет к регулярным выражениям. Для чего в регулярных выражениях нужно XSD?!
8 май 19, 08:07    [21880603]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
Я лично больше занимаюсь вещами, которые с другого конца относительно языков программирования - прикладные (бизнесовые) модели процессов, данных. Возможно я вообще сильно оторвался от мира программирования. Например, у нас были лютые споры с разработчиками на некоторых проектах. Они считали полным бредом использовать OCL для написания правил ФЛК. Что это вообще за язык, нет ни одной вакансии где требовалось бы его знание.


Так правильно спорили.
"Манагеры" на своем птичьем языке что-то накалякают, а им потом это дерьмо разгребать.
Любая DSL (не важно на чем) это все таки ЯП, а не язык предметной области. Соответственно для работы с ним нужно быть программистом.
Тот кто знает предметную область редко когда бывает хорошим программистом.
Поэтому зачем его мучить изучением программирования, когда можно мучить программистом предметной областью.
Причем программисту не надо знать глубоко предметную область, достаточно знать основные термины и определения.
Что гораздо проще, чем не программисту (предметнику) глубоко изучать программирование.
8 май 19, 08:14    [21880606]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

не всё сводится к программированию. Например, если вы полистаете эту штуку, то найдете там очень много вещей из функциональных языков программирования: алгебраические типы данных, pattern-matching, функции высшего порядка и т.п. Когда я только начинал писать на Isabelle HOL я воспринимал её исключительно как ФЯП и формулировал всё через функции. Потом я надсадился доказывать для этих функций теоремы и открыл для себя индуктивные предикаты (или отношения), которые являются сугубо логической конструкцией. Опционально для них можно сгенерить исполняемый код, но далеко не всегда. Для индуктивных предикатов на порядок проще доказывать теоремы, также в отличие от функций они могут быть недетерминированными ("возвращать" несколько значений), могут быть частично определенными, могут "вычисляться" в разных направлениях (например, для заданного результата вычисляем исходные аргументы).

В итоге я пришел к такой схеме. Описываю теорию преимущественно через логические конструкции (которые не факт, что вообще вычисляемые и реализуемые на ЯП), доказываю для них все нужные теоремы. Затем, если для этих логических конструкций можно сгенерить код, то генерю его. Если нельзя, то пишу функцию и доказываю, что логическая и функциональная формулировки эквиваленты.

Вывод 1: не всё можно или удобно описывать на языках программирования. Есть формальные языки (языки спецификации), которые очень далеки от ЯП.

При этом предметные специалисты могут владеть такими языками на много лучше программистов.

Например, я пытался доказать, что если тип S является подтипом типа T, то это верно и для типов C(S) и C(T), где C обладает какими-то специальными свойствами. Например, если Integer - это подтип Real, то Set(Integer) - это подтип Set(Real). Знание ЯП никак не помогало мне в доказательстве, тут нельзя написать какую-то функцию, которая что-то вычислит, это сугубо логическая задача. А помог мне доказать это чел, который близко не программист, а математик. Или ещё он помог мне доказать теорему, связанную с наследованием кортежных типов. В итоге он вдохновился моими вопросами и пошёл писать какую-то жесть основанную на преобразованиях типов в множества и обратно, которую я даже близко понять не могу.

Вывод 2: предметники могут на порядок лучше знать свои формальные языки, чем программисты. Эти языки могут быть на столько сложными, что программист вообще хрен поймёт там что-либо.

Там в принципе требуется другой тип мышления. Если очень сильно упростить, то в программировании 99% задач могут быть решены по такой схеме: написал код, запустил, если работает как надо идём дальше, иначе исправляем. В других областях бывает, что просто нечего запускать.


Конечно, какая-нибудь таможенная или банковская сфера немного отличаются от "матана". Но опыт показывает, что в их структурах документов или правилах ФЛК часто не может разобраться не то, что программист, но даже аналитик, который уже давно в этой сфере и прочитал тонны нормативки. Правила ФЛК могут быть неоднозначными (например, в декларации цель ввоза товаров указывается в нескольких местах и неясно какое именно поле имеется в виду, или поле множественное и неясно все экземпляры должны удовлетворять условию или хотя бы один или должен быть только один экземпляр, или для опционального поля написано, что оно должно соответствовать шаблону, при этом не ясно это только при условии, что оно заполнено или оно обязательно должно быть заполнено и соответствовать шаблону), могут быть противоречивыми (и если на документ тыща правил, вы в жизни это противоречие не увидите), могут быть избыточными, неполными.

Наконец, нормативка одна. А компаний и программистов, которые её реализуют много, равно как и языков программирования много. Схема "давайте сделаем одну эталонную реализацию и все будут ей пользоваться" сведётся к тому что это будет какая-то жесть на устаревших технологиях, от которой все будут плеваться. Мне кажется до сих пор где-то используются dbf файлы в кодировке cp866 для обмена данными. А в реальности кто-то хочет использовать XML, кто-то - JSON, кто-то - бинарные форматы. С реализаций правил ФЛК ещё сложнее, нельзя заставить всех использовать, например, Java.

С одной стороны есть русский язык, с другой - XML, JSON, языки программирования и т.п. Между ними, очевидно, могут предметные формальные языки. Иначе, давайте запретим математику. Правила ФЛК как-раз пишутся на языке формальной логики, только немного адаптированном для предметников. Это логический язык, а не язык программирования.

Насчёт птичьего языка и разгребания дерьма программистами я повторюсь:
1) Есть нормативка на русском языке, которая никуда не девается. Программист берёт её и реализует как ему надо.
2) Есть та же самая нормативка но на формальных языках, из которой автоматически генерится код и программист здесь только один - который писал кодогенератор, остальные программисты не нужны, не нужно никому ничего разгребать.
3) Если по какой-то причине программистов не устраивает сгенеренный код, то либо см. пункт 1, либо можно написать нужный кодогенератор под свой стек технологий и под свои требования.
8 май 19, 10:17    [21880706]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb,

Кто мешает использовать ФЯП, например Scala или Haskel?!
Хотя, судя по BigData математикам проще писать на Python, чем на ФЯП.

Вывод 1 - Если что-то нельзя описать на ЯП, то для этого нельзя написать исполняемую программу. ;-)
Вывод 2 - Конечно, предметники лучше знают, свой язык если он есть. Он нужен для общения между собой. А вот со внешним миром все таки нужно что-то "попроще". Программисты же не объясняются с "бизнесом" кодом ЯП, а все таки используют естественный язык.

Насчет написания кода.
Так вся сложность/легкость программирования, что прототип (декорация) не отличим от готового продукта.
Т.е. "программа работает" и "программа работает и в нее легко вносить изменения" это две большие разницы.
На этом уже "обожглись" в нулевых с "индусами".
Когда была идея, что умные аналитики нарисуют красивые диаграммы, а дешевые-программисты на аутсорсе по ним все накодят.

Оказалось, что это работает очень плохо.
Что гораздо дешевле нанять дорогих-программистов, чем дешевых-программистов. Вот такой парадокс :-)

Сейчас вообще дошли до того что нужны программисты-мастера

Т.е. как бы, что аналитики, ПМ, тестировщики и пр. не нужны, должны быть только программисты-мастера.
8 май 19, 12:24    [21880851]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
Ares_ekb
Вывод 1: не всё можно или удобно описывать на языках программирования. Есть формальные языки (языки спецификации), которые очень далеки от ЯП.

Ёперный театр, ты же модельками балуешься, и не понимаешь таких простейших вещей, как формализация знаний. Однобокий из тебя ботаник...
Ares_ekb
Вывод 2: предметники могут на порядок лучше знать свои формальные языки, чем программисты. Эти языки могут быть на столько сложными, что программист вообще хрен поймёт там что-либо.

Это те же модели. И ты даже пишешь, что на Изабель их курил. Но не в коня корм...

Повторюсь - мир шире твоих представлений, а ты этого не замечаешь. Узколобо мыслишь, потому что.
8 май 19, 12:40    [21880888]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
mad_nazgul
Сейчас вообще дошли до того что нужны программисты-мастера

Ну это же самореклама "группы товарищей". Не стоит так экзальтированно её воспринимать.
8 май 19, 12:42    [21880892]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mayton
Member

Откуда: loopback
Сообщений: 42897
Ares_ekb
mad_nazgul,

не всё сводится к программированию. Например, если вы полистаете эту штуку, то найдете там очень много вещей из функциональных языков программирования: алгебраические типы данных, pattern-matching, функции высшего порядка и т.п. Когда я только начинал писать на Isabelle HOL я воспринимал её исключительно как ФЯП и формулировал всё через функции. Потом я надсадился доказывать для этих функций теоремы и открыл для себя индуктивные предикаты (или отношения), которые являются сугубо логической конструкцией. Опционально для них можно сгенерить исполняемый код, но далеко не всегда. Для индуктивных предикатов на порядок проще доказывать теоремы, также в отличие от функций они могут быть недетерминированными ("возвращать" несколько значений), могут быть частично определенными, могут "вычисляться" в разных направлениях (например, для заданного результата вычисляем исходные аргументы).

Хорошая линка. Почитаем.
8 май 19, 13:38    [21880978]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

ФЯП очень ограничены. Мне нужно было описать систему типов языка, описать его синтаксис, правила типизации и нормализации выражений. Это всё можно сделать на ФЯП. Синтаксис описывается в виде алгебраического типа данных (АТД), у которого каждый конструктор соответствует определенному виду выражений. Систему типов можно либо тоже описать в виде АТД (deep embedding), либо использовать типы базового языка (shallow embedding). У меня ровно так и сделано: типы, синтаксис. Эта часть идентичная, что в ФЯП, что в Isabelle HOL. Правила типизации и нормализации выражений тоже можно было бы описать в виде функций, которые принимают абстрактное синтаксическое дерево и возвращают соответственно тип этого выражения, либо нормализованное выражение.

Но когда начинаешь для всего этого доказывать теоремы, например: 1) выражение, которое имеет тип имеет и значение 2) причем тип значения соответствует типу выражения 3) транслятор с одного языка на другой язык сохраняет семантику выражений 4) система типов образует решетку и т.п., то в ФЯП это сделать практически невозможно. Во-первых, в ФЯП просто отсутствует такая возможность, там нельзя ни формулировать, ни доказывать теоремы. Во-вторых, даже в Isabelle HOL, где можно доказывать теоремы, для функций всё это доказывать очень сложно, гораздо проще для индуктивных предикатов (которых в ФЯП вообще нет).

mad_nazgul
Если что-то нельзя описать на ЯП, то для этого нельзя написать исполняемую программу
Бывает, что можно описать на ЯП, но не удобно. Конкретный пример с правилами ФЛК. Правила ФЛК пишутся на языке формальной логики: "если такое-то поле имеет такое-то значение, то такое-то поле должно иметь такое-то значение". ФЛК пишутся с использованием логических конструкций "и", "или", "если, то", "для каждого", "существует" и т.п. Есть 3 варианта как можно писать ФЛК:
1) На русском языке - при этом возможны неоднозначные формулировки, ошибки и т.п.
2) На формальном логическом языке - это могут быть либо математические формулы, либо какой-то адаптированный для предметников язык типа OCL
3) На языке программирования - тут появляется очень много деталей реализации (условия, циклы, вывод сообщений и т.п.)

Я выше уже приводил пример ФЛК: 5 строк на OCL против 30 на Java или 129 на XSLT. Очевидно, что в 5 строках проще разобраться, чем в 30 или 129.

mad_nazgul
А вот со внешним миром все таки нужно что-то "попроще". Программисты же не объясняются с "бизнесом" кодом ЯП, а все таки используют естественный язык.
В том-то и прикол, что естественный язык нифига не проще! Например правило: "для налоговых платежей должно заполняться то-то". Вот, сиди и думай, как определить, что этот платеж налоговый. Или правило: "при указании пересылающего банка для его идентификации может использоваться российский БИК, ИНН/КИО или УИС" - что это значит 1) если указан идентификатор, то должен быть обязательно один из этих, другие идентификаторы запрещены 2) может указываться несколько произвольных идентификаторов, но хотя бы один из них должен быть таким 3) это не требование, а просто информация "может использоваться, а может и не использоваться".

Одно из решений - это ввести четкие правила написания правил: когда использовать слово "должен", когда "может" и т.п. Но всё равно этого недостаточно.

mad_nazgul
Т.е. "программа работает" и "программа работает и в нее легко вносить изменения" это две большие разницы.
В сгенеренный код не нужно вносить изменения. Вы же после компиляции программы не вносите изменения в бинарник.

mad_nazgul
На этом уже "обожглись" в нулевых с "индусами".
Когда была идея, что умные аналитики нарисуют красивые диаграммы, а дешевые-программисты на аутсорсе по ним все накодят.

Оказалось, что это работает очень плохо.
Что гораздо дешевле нанять дорогих-программистов, чем дешевых-программистов.
Я ровно об этом и говорю :) Дешевле нанять одного программиста, который напишет нужные кодогенераторы, а другие программисты для реализации правил ФЛК просто не нужны.

mad_nazgul
Т.е. как бы, что аналитики, ПМ, тестировщики и пр. не нужны, должны быть только программисты-мастера.
Я лично всю жизнь так и работаю: занимаюсь всем сразу. Разумеется ничего хорошего в этом нет
8 май 19, 14:07    [21881044]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
alex55555
mad_nazgul
Сейчас вообще дошли до того что нужны программисты-мастера

Ну это же самореклама "группы товарищей". Не стоит так экзальтированно её воспринимать.


Ну "идея брошенная в массы..."
Агиле-манифест тоже был пиар "группы товарищей", а во что вылилось. ;-)
8 май 19, 14:10    [21881053]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
alex55555,

я и пишу о формализации знаний в виде моделей и на DSL уже какую страницу
8 май 19, 14:11    [21881058]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
mad_nazgul,
ФЯП очень ограничены.


Они как минимум тьюринг полные.
И если на них нельзя что-то описать, то это "что-то" вообще нельзя реализовать на компьютере.

Ares_ekb
Я выше уже приводил пример ФЛК: 5 строк на OCL против 30 на Java или 129 на XSLT. Очевидно, что в 5 строках проще разобраться, чем в 30 или 129.


Не факт.
Примеры те же ФЯП.
Там 5 строк могут быть непонятнее, чем 30 строк императивном ЯП.
Хотя красота в глазах смотрящего.
Но мы же про бизнес. а не про науку.
А в бизнесе чем дешевле, тем лучше.


Ares_ekb
В том-то и прикол, что естественный язык нифига не проще!


Проще, т.к. его понимают все.
А вот птичий язык математиков, химиков, программистов и пр. не все. Для этого нужно долго и упорно трудиться.

Ares_ekb
В сгенеренный код не нужно вносить изменения. Вы же после компиляции программы не вносите изменения в бинарник.


Чта?!
Тогда зачем его генерить, когда можно сразу компилировать?
Еще раз. Если вы пишите программу, то вы пишите программу.
Для этого нужно долго и упорно учиться программировать.

Я не спорю, что есть уникальные люди, которые могут одинаково разбираются в разных областях, но их мало.
Соответственно таким людям нужно платить не много и очень много.

Обычные люди в лучшем случае могут освоить одну специализацию.


Ares_ekb
Я ровно об этом и говорю :) Дешевле нанять одного программиста, который напишет нужные кодогенераторы, а другие программисты для реализации правил ФЛК просто не нужны.


Нужны. Просто вместо одного программиста будут нужны два.
Первый пишет кодогенераторы, второй пишет на птичем языке ФЛК.

Для примера можно плосмотреть на SQL.
Помниться SQL продвигался, как инструмент, для которого программисты не нужны.

Ares_ekb
Я лично всю жизнь так и работаю: занимаюсь всем сразу. Разумеется ничего хорошего в этом нет


ИМХО Универсал - это тот кто все делает одинаково плохо.

Но программирование еще незрелая отрасль, поэтому в ней все еще экономически выгодны мастера-универсалы, а не узкие-специалисты.
8 май 19, 14:28    [21881091]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
mad_nazgul
Но программирование еще незрелая отрасль, поэтому в ней все еще экономически выгодны мастера-универсалы, а не узкие-специалисты.

Тоже неправильное понимание.

Не программирование чем-то провинилось, а потребности, диктуемые разного рода рейхскомиссарами, не включают в себя что-то умное.

Вот тот же Арес из ёбурга пишет для ЦБ, а ЦБ заказывает его писанину у некой конторы в ёбурге, которая ещё 15 лет назад писала для ЦБ всё те же xml-и, оформляла их при помощи xsd и т.д. и т.п., но и спустя 15 лет они находятся примерно там же - всё те же xml, но теперь лишь с некой модельной надстройкой для детей, дабы возбуждались от её крутости. То есть суть не поменялась совсем. И всё потому, что потребности нет.

Поэтому термин "зрелость" следует применять не к программированию, а к тем, кто формирует запрос на результаты программирования. Пока что эти "кто-то" сами примерно на уровне первых приматов, поэтому им вот и впаривают всякую лажу аресы и ёбургов, ведь попилу лажа не мешает, а иногда даже помогает прикрывать совсем уж мрачные места. Цель ведь не качество софта, а значит там и никакая специализация не нужна, ну кроме попильной, понятно.
9 май 19, 13:09    [21881696]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
mad_nazgul,

Isabelle HOL написана ML. В итоге все логические теории, написанные на ней, сводятся к этому ML коду, который сводится к машинным инструкциям, которые сводятся к электрическим импульсам в процессоре. Но человек, который пишет эти логические теории не обязан всё это знать, он может быть математиком, а не программистом.

Хотя, в Isabelle HOL можно делать вставки ML кода, и здесь я совершенно согласен с идеей о "дырявости абстракций". Ещё там могут быть проблемы с производительностью, для решения которых нужно понимать как всё работает внутри. Но это опционально, я пользовался ML вставками только один раз для теста. И несколько раз переписывал функции, разбивал типы данных на несколько более простых из-за того, что Isabelle HOL неявно формулирует и доказывает кучу теорем и это сильно тормозило.

Но согласиться, что абстракции совсем не нужны я тоже не могу. На том же SQL проще добавить несколько хинтов, чем писать запросы на ЯП. Хотя над SQL ещё куча абстракций - разные ORM, LINQ и т.п. И, вот, где начинаются настоящие проблемы :) Я, например, хлебнул с Hibernate, который выдаёт неадекватные исключения, по которым невозможно понять что не так. Или с XPO, который отправляет много мелких запросов и это очень тормозит при плохом канале.

mad_nazgul
Тогда зачем его генерить, когда можно сразу компилировать?
Еще раз. Если вы пишите программу, то вы пишите программу.
Можно сразу компилировать. Но исходники тоже нужны, чтобы видеть что там нет закладок или чего-то подобного. Плюс не весь код компилируются, те же XSLT.

mad_nazgul
Нужны. Просто вместо одного программиста будут нужны два.
Первый пишет кодогенераторы, второй пишет на птичем языке ФЛК.

Для примера можно плосмотреть на SQL.
Помниться SQL продвигался, как инструмент, для которого программисты не нужны.
Хорошо, пусть будет два. Всё равно это лучше, чем тысяча программистов, тестировщиков, аналитиков, РП у каждого участника взаимодействия. Здесь вариантов всего два:
1) Нормативка на русском и каждый участник реализует её как понимает и своими силами
2) Нормативка на русском + формализованная нормативка, из которой автоматически делается несколько реализаций под разные стеки технологий. Автоматически, потому что на написание и сопровождение этого кода никто ресурсы тратить не будет. А формальная спецификация - это уже не код, она более компактная, более долговечная, понятная для предметников. Под разные стеки, потому что навязывать один стек технологий никто не может.

Варианта, что нормативка сразу реализуется в коде нет.

mad_nazgul
Универсал - это тот кто все делает одинаково плохо.
Постоянно слышу эту фразу. Очевидно, что если он плох во всём, то уже автоматически перестаёт быть универсалом :) Ещё я слышал фразу, что талантливый человек талантлив во всём.

Это всё штампы. Людям удобно загонять себя в рамки. Причём, многим людям мало поставить на себе штампик "программист". Нужно добавить ещё штампов: middle, senior, full-stack и т.п. По-моему нужно заниматься тем, что интересно и не придумывать искусственные ограничения.
9 май 19, 16:48    [21881800]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
alex55555,

вы так эмоционально в каждом сообщении пытаетесь меня задеть, что можно подумать, что вы моя бывшая девушка или что-то в этом роде. Но, нет, она вполне рассудительная и адекватная. Мне страшно представить с чем связано, что в ваших излияниях всё сложнее и сложнее вылавливать что-то конструктивное.
9 май 19, 16:58    [21881804]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
serge79y
Member

Откуда: Москва
Сообщений: 31
Ares_ekb
alex55555,

вы так эмоционально в каждом сообщении пытаетесь меня задеть, что можно подумать, что вы моя бывшая девушка или что-то в этом роде. Но, нет, она вполне рассудительная и адекватная. Мне страшно представить с чем связано, что в ваших излияниях всё сложнее и сложнее вылавливать что-то конструктивное.


Software Engineering это еще и люди. Вы столкнулись с человеческим фактором при попытке обьяснить MDA/MDD. Этот фактор не устраним. Если вы руководите проектом, то можете принудить использовать свой подход, но люди будут уходить.

Алегбраическая система типов и формализм был в ITU-T SDL (Specification and Description Language). В итоге он вначале проиграл UMLю (который был гораздо менее формален), а потом вообще вытеснилось прямым кодингом на C/C++ (нынче еще Go/Rust)

Вы проходите такой же путь, история повторяется. Только в другой области теперь. Мне кажется в области документооборота и учетных систем излишняя формальность вредна. Нормативы и регламенты меняются, законы тоже. Важно чтоб было удобно все менять и иногда править историю :)
9 май 19, 23:42    [21881958]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
serge79y
Member

Откуда: Москва
Сообщений: 31
Ares_ekb
mad_nazgul,

2) Нормативка на русском + формализованная нормативка, из которой автоматически делается несколько реализаций под разные стеки технологий. Автоматически, потому что на написание и сопровождение этого кода никто ресурсы тратить не будет. А формальная спецификация - это уже не код, она более компактная, более долговечная, понятная для предметников. Под разные стеки, потому что навязывать один стек технологий никто не может.



Всегда помните, что такой подход будет работать только тогда, когда никому не потребуется дебажить сегенеренный кода и "чуточку его поправить". На проекте всегда должен быть тот, кто знает, как устроен генератор. Если спец по генератору уходит, то происходит катастрофа ввиду того, что править генеренный код надо правя генератор а специалист ушел.
9 май 19, 23:49    [21881964]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
serge79y,

Посмотрел историю SDL:
1976 - 1-я версия с графической нотацией
1980 - пересмотр языка
1984 - текстовая нотация
1988 - формальная семантика

История UML:
1995 - 1-я предварительная версия
2005 - пересмотренная 2-я версия
2015 - полное текстовое представление (к сожалению не человекочитаемое) для моделей, включая диаграммы
Формальной семантики нет до сих пор. Точнее есть очень много разрозненных работ по формализации отдельных видов диаграмм, но стандарт достаточно неформальный.

Интересное совпадение, что у SDL эти шаги были длиной в 4 года, а у UML - 10 лет. Наверное в 2025 можно ждать полную формализацию UML :)

Я понимаю все эти вещи насчет человеческого фактора. Ровно для этого я и писал статьи на хабр по MDD, чтобы продвигать эту тему. По тому же OCL мне достаточно дать человеку ссылку на статью, чтобы он быстро вник. Если бы я дописал все статьи, которые планировал, то никакой катастрофы с моим уходом с этого проекта не было бы. Её и сейчас не будет, потому что основные вещи описаны.

Насчёт неформальности UML и связанных языков типа OCL. Это проблема и чтобы исправить это я написал формальную спецификацию OCL. Чтобы хотя бы OCL был формальным. На самом деле это делали и до меня ещё в 2014 году. Но прикол в том, что ни я, ни разработчики OCL в этой спецификации нихрена не понимают. Она сильно оторвана от реализации, фактически они сделали альтернативную реализацию OCL на Isabelle HOL.

Моя спецификация OCL уже сильнее оторвана от Isabelle HOL, потому что у меня используется deep embeding (типы данных, синтаксис и т.п. явно определены как алгебраические типы данных) вместо shallow embedding (ни типы, ни синтаксис как таковые не определены, вместо этого используются типы базового языка (Isabelle HOL), а выражения OCL транслируются в выражения Isabelle HOL). Но с другой стороны, она всё ещё слишком оторвана от реализации. А разработчики вообще видят формальную спецификацию OCL так. И теперь я ломаю мозг как скрестить ежа с ужом, чтобы получилось что-то среднее и понятное всем.

Короче история действительно повторяется, люди занимались тем же самым с SDL ещё 30 лет назад. Но я бы не сказал, что в MDD нет вообще никакого прогресса. Огромное количество разных DSL. Инструменты для визуальных языков моделирования: Eclipse Sirius, JetBrains вроде тоже что-то делает, куча рисовалок и т.п.
10 май 19, 05:03    [21881984]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
serge79y
Member

Откуда: Москва
Сообщений: 31
Ares_ekb
serge79y,

Интересное совпадение, что у SDL эти шаги были длиной в 4 года, а у UML - 10 лет. Наверное в 2025 можно ждать полную формализацию UML :)
....
Я понимаю все эти вещи насчет человеческого фактора. Ровно для этого я и писал статьи на хабр по MDD, чтобы продвигать эту тему. По тому же OCL мне достаточно дать человеку ссылку на статью, чтобы он быстро вник. Если бы я дописал все статьи, которые планировал, то никакой катастрофы с моим уходом с этого проекта не было бы. Её и сейчас не будет, потому что основные вещи описаны.
.....
Короче история действительно повторяется, люди занимались тем же самым с SDL ещё 30 лет назад. Но я бы не сказал, что в MDD нет вообще никакого прогресса. Огромное количество разных DSL. Инструменты для визуальных языков моделирования: Eclipse Sirius, JetBrains вроде тоже что-то делает, куча рисовалок и т.п.


За SDL стоял ITU-T, там стандарты более качественные. В SDL был сделана как статическая семантика так и динамическая (полная run-time модель), позволяющая полностью симулировать (выполнять) спецификацию. Это даже было реализовано в наших древних продуктах Telelogic SDL Suite. К сожалению, нашествие молодежи в телеком привело к падению интереса к формальным языкам (TTCN тоже сдулся, а была интеграция с SDL)

Проблемы стандартизации в UML лежат в плоскости бизнеса. Были разные конторы, какие сделали свои тулы на базе UML. В это были вложены средства, посему они хотели видеть свои фичи в стандарте. От весомости конторы зависело включени фич в стандарт.
Стандарт UML разрабатывался не инженерами, а бизнесом в некотором роде. В рез-те получилось то, что получилось. Попутно писались и пишутся разные научные статьи на тему UML, но OMG на это было всегда пофиг. Если ты не Lockheed Martin Corp, Raytheon, IBM и т.д - то твои предложения проигнорят. Грустно, но таков бизнес.

Sirius базируется на GMF. GMF был рожден как база Rational Software Architect-а (RSA), какой вы использовали тоже. Все это крутится на базе GEF 3.xx/Draw2D. К сожалению, на GEF5/JavaFX миграция невозможна (они там все подчистую передалили). Это все уже древние технологии.
Сириус поддерживается Obeo, они живут за счет ряда военных команий (Thales Group) и телекома. Сколько они еще протянут - неясно.
10 май 19, 18:32    [21882201]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
alex55555
Поэтому термин "зрелость" следует применять не к программированию, а к тем, кто формирует запрос на результаты программирования. Пока что эти "кто-то" сами примерно на уровне первых приматов, поэтому им вот и впаривают всякую лажу аресы и ёбургов, ведь попилу лажа не мешает, а иногда даже помогает прикрывать совсем уж мрачные места. Цель ведь не качество софта, а значит там и никакая специализация не нужна, ну кроме попильной, понятно.


Так это одно и то же.
Т.к. теоретическая основа для разделения труда и специализации разрабатывается с начала зарождения программирования как профессии.
И по началу так и пытались делать (см. Мейнфреймы).
Но с удешевлением компьютерных ресурсов оказалось, что так программировать дорого.
Дешевле "фигак-фигак и в продакшен".
13 май 19, 06:59    [21882959]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
Ares_ekb
Можно сразу компилировать. Но исходники тоже нужны, чтобы видеть что там нет закладок или чего-то подобного. Плюс не весь код компилируются, те же XSLT.


Бритва Оккама тут вообще потеряло лезвие.
Зачем нужны "другие" исходники, когда есть первичные исходники?!
Т.е. зачем нужны, грубо говоря, исходники на ассемблере, когда есть код на C?!


Ares_ekb
Хорошо, пусть будет два. Всё равно это лучше, чем тысяча программистов, тестировщиков, аналитиков, РП у каждого участника взаимодействия.


Нет будет не "два программиста", а тысяча для одного ЯП + тысяча для другого ЯП.
Мой опыт говорит только об этом.

Ares_ekb
mad_nazgul
Универсал - это тот кто все делает одинаково плохо.
Постоянно слышу эту фразу. Очевидно, что если он плох во всём, то уже автоматически перестаёт быть универсалом :) Ещё я слышал фразу, что талантливый человек талантлив во всём.


Нет. Талантливый человек талантлив в одном, все остальное он знает постольку-поскольку.
Те "универсалы" которые я встречал, обычно глубоко знали только одну область деятельности.
Остальное знали на уровне в лучшем случае middle.
Иллюзию, того что можно знать все дает google + stackoverflow.
Но увы это не так. Т.к. некоторые специфичные вещи чтобы знать, нужно много лет в этом "вариться".

Тот же тюнинг запросов на Oracle, это отдельная дисциплина знаний, которую за неделю не выучишь.
Т.к. нужно хорошо знать и понимать, как там "унутре" работает.
13 май 19, 07:11    [21882962]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
mad_nazgul
Дешевле "фигак-фигак и в продакшен".

Нет.

Требования к программам такие, что при таких требованиях, можно писать лажу. Никого не расстреляют за упавший на сутки или больше сервер сбербанка или госуслуг, поэтому "фигак-фигак".
13 май 19, 12:22    [21883226]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mayton
Member

Откуда: loopback
Сообщений: 42897
mad_nazgul
Нет. Талантливый человек талантлив в одном, все остальное он знает постольку-поскольку.
Те "универсалы" которые я встречал, обычно глубоко знали только одну область деятельности.
Остальное знали на уровне в лучшем случае middle.
Иллюзию, того что можно знать все дает google + stackoverflow.
Но увы это не так. Т.к. некоторые специфичные вещи чтобы знать, нужно много лет в этом "вариться".

Такие личности как Михайло Ломоносов и Леонардо Да-Винчи были талантливы более чем в одной
области. Но это титаны. Наверное время титанов прошло.
13 май 19, 12:42    [21883251]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
alex55555
mad_nazgul
Дешевле "фигак-фигак и в продакшен".

Нет.

Требования к программам такие, что при таких требованиях, можно писать лажу. Никого не расстреляют за упавший на сутки или больше сервер сбербанка или госуслуг, поэтому "фигак-фигак".


Так я про это и говорю!
Такие требования, потому что так дешевле.
Если же надо надежно, то это дорого.
13 май 19, 14:19    [21883383]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
mayton
Такие личности как Михайло Ломоносов и Леонардо Да-Винчи были талантливы более чем в одной
области. Но это титаны. Наверное время титанов прошло.


Ну насчет них, не все так однозначно.
Как минимум с Ленардо Да-Винчи.
Художником он был гениальным, а вот инженером, врачем и пр. нет.
13 май 19, 14:21    [21883385]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
mad_nazgul
Такие требования, потому что так дешевле.

Первична цель, экономика вторична.
14 май 19, 10:45    [21884128]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
mayton
Наверное время титанов прошло.

Глубина проработки деталей по каждой из областей человеческих знаний увеличилась на порядки, а мозги вряд ли подросли хотя бы на 10%. Поэтому умных во всём теперь быть не может.
14 май 19, 10:46    [21884131]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
alex55555
mad_nazgul
Такие требования, потому что так дешевле.

Первична цель, экономика вторична.


1) Чья цель
2) Обычно цель получить много денег при минимуме затрат ЩАС
14 май 19, 10:53    [21884140]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
mad_nazgul
1) Чья цель

Хозяев жизни.
mad_nazgul
2) Обычно цель получить много денег при минимуме затрат ЩАС

Их цель долговременная - удержать власть. Деньги только сиюминутный инструмент.
15 май 19, 17:33    [21885622]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mad_nazgul
Member

Откуда:
Сообщений: 4918
alex55555
mad_nazgul
1) Чья цель

Хозяев жизни.
mad_nazgul
2) Обычно цель получить много денег при минимуме затрат ЩАС

Их цель долговременная - удержать власть. Деньги только сиюминутный инструмент.


Ну как бы практика говорит немного об обратном.
Обычно цель, кто формирует задачу исполнителю получить прибыль "здесь и сейчас" :-)
16 май 19, 08:14    [21885839]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
alex55555
Member

Откуда:
Сообщений: 2128
mad_nazgul
Ну как бы практика говорит немного об обратном.
Обычно цель, кто формирует задачу исполнителю получить прибыль "здесь и сейчас" :-)

Это практика на уровне отдельных микробов, а на уровне реально больших животин совсем другая практика. Но даже на уровне микробов бывают разные варианты. Так что "обычно" - это просто узкий личный опыт.
16 май 19, 12:36    [21886115]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Bsplesk
Member

Откуда:
Сообщений: 126
Ares_ekb,

Привет.
Что на текущий момент посоветуете для ведения моделей небольшого проекта/фактически StartUP?
Сам склоняюсь к Excel/Confluence.
Основа для моделей/хранилище Excel (возможно свяжу с xsd схемой) --> далее генерация Confluence (таблички); Swagger (Data); Protobuf (.proto); xsd; артефактов. Всякие особенные форматы типа TUTDF ручками по описанию + маппингу.

Excel - base + синхронизация;
Confluence - для обсуждения с заказчиками (бизнес/разработчики) - основное отображение модели и процессов текст/+BPMN;
Swagger (Data); Protobuf (.proto); xsd - артефакты для сервисов (разработчики если им требуется иначе пусть сами создают по описанию confluence);

Задача "простая" - мини. банк (включая работу с картами), интеграций достаточно (порядка 30).
23 окт 19, 15:18    [22000966]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
mayton
Member

Откуда: loopback
Сообщений: 42897
Зачем нужен Excel?
23 окт 19, 16:06    [22001024]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Bsplesk
Member

Откуда:
Сообщений: 126
mayton
Зачем нужен Excel?


Понятен, доступное всем средство!
Конечно он для этого не создан, но встроенный DSL (VBA или .NET) позволяющий делать очень многое, простое отображение сущностей, маппингов в табличном виде, поддержка моделей в том или ином виде ... etc. Отчасти можно извернуться и получить отношения правда в Er виде, что не совсем то.
Картинка с другого сайта. model
Картинка с другого сайта. xml map
Картинка с другого сайта. PowerPivot
23 окт 19, 20:40    [22001235]     Ответить | Цитировать Сообщить модератору
 Re: Просветите в UML. Вопрос.  [new]
Ares_ekb
Member

Откуда: Екатеринбург
Сообщений: 1349
Bsplesk,

сложный вопрос. Лично мне не нравится ни одно из существующих решений. Поэтому я пишу своё, сама рисовалка моделей у меня уже полностью готова (включая всякие ядреные вещи типа поддержки разных систем типов), сейчас доделываю какие-то общие вещи типа интерфейса для работы с деревом проектов, моделей и т.п. Потом надо доделывать серверную часть. Работы ещё на полгода наверное.

Из существующих решений для того же confluence есть плагин draw.io. Ещё интересная штука PlantUML. Можно схему данных описывать просто в Excel, как вы предлагаете. Но я бы даже описывал её в виде простых табличек без всяких XSD и т.п. Затем можно выгружать это в текстовый вид и отдавать на вход PlantUML. Кстати PlantUML интегрируется и с draw.io, и с confluence. Поэтому эти текстовые описания из Excel можно грузить прямо в confluence.

Можно было бы описывать схему данных сразу в формате PlantUML, но если потом нужно будет сгенерить схему данных или ещё что-то, то удобней это делать когда структура сущностей уже разложена в Excel-евской табличке. Парсить текстовое описание сложнее.
24 окт 19, 05:15    [22001336]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: 1 2 3 4 5 6 7 8      [все]
Все форумы / Разработка информационных систем Ответить