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

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

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

Откуда: Екатеринбург
Сообщений: 1300
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

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


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

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

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

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


щито?

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

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


щито?

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


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

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

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


Зачем?!

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

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

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


щито?

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


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

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

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

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

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

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

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

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

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

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

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


щито?

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

Откуда:
Сообщений: 2129
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

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

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

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

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

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


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

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

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

Откуда: Екатеринбург
Сообщений: 1300
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

Откуда:
Сообщений: 2129
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

Откуда: Екатеринбург
Сообщений: 1300
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
Сообщений: 41804
На курсах системного анализа в универе нам рассказывали о Фреймах представления знаний (ФЗ).

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

Откуда:
Сообщений: 2129
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

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

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

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

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

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