|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
mad_nazgulserge79yТочнее так, 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...бррр ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 09:14 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
mad_nazgul, можно писать сразу на ЯП. Например, вот, правило ФЛК: если реквизит «Цель представления предварительной информации (casdo:PreliminaryInformationUsageCode)» содержит 1 из значений: «11», «12», «13», реквизит «Цель представления предварительной информации (casdo:PreliminaryInformationUsageCode)» не содержит значение «01», реквизит «Регистрационный номер предварительной информации (cacdo:PreliminaryInformationIdDetails)» не заполнен, то реквизит «Регистрационный номер транспортного средства (csdo:TransportMeansRegId)» должен быть заполнен Вот, оно на DSL: Код: sql 1. 2. 3. 4. 5.
Вот, оно на Java: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22.
Вот, на XSLT: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. 123. 124. 125. 126. 127. 128. 129.
В реализации так много кода, потому что нужно различать ситуации: успех, ошибка, не выполнено предусловие в правиле и поэтому нечего проверять, нет подходящих элементов в документе и поэтому нечего проверять. Также нужно в результатах выводить путь к провалидированным элементам. Понятно, что конкретно под это правило можно написать более оптимальный и компактный код. Но в этом смысла столько же сколько в том, чтобы отказаться от языков высокого уровня и писать всё на ассемблере. Или отказаться от SQL. DSL нужны чтобы скрыть технические детали реализации. Выражения на DSL можно анализировать и добавлять в реализацию кучу логики, которой в исходном выражении нет. В этом примере видно, что в коде появляются условия и циклы, которых в исходном выражении даже близко нет. Ровно также когда вы пишите код на SQL или LINQ вы не пишите условия, циклы и т.п. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 09:33 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
serge79yКстати. по стандарту, диаграмм в нем тоже нет (и в этом одна из причин проблем "стандарта").Это проблема, нам приходилось выгружать модель в XMI, а диаграммы в SVG для загрузки в хранилище. Но в UML 2.5 диаграммы уже добавили, осталось дождаться когда это реализуют хотя бы в нескольких основных редакторах. Ещё в стандарте были разные мелкие неоднозначности. Например, разработчики Eclipse OCL считали, что у типов данных в UML не может быть операций, а только у классов. А мы понимали стандарт так, что у типов они тоже могут быть. В целом, UML плох для 1) концептуального моделирования, для этого лучше подходят модели с "открытым миром" - RDF, OWL и т.п. 2) для проектирования структур документов, потому что они древовидные (а если каждый узел дерева - это отдельный класс, то запаришься переходить от класса к классу в UML модели). Ещё профили и стереотипы конечно позволяют не изобретать новый язык моделирования. Но если стереотипов достаточно много, то проще сделать специализированный язык моделирования, чем использовать UML. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 09:55 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
Java-код в примере выше неправильный :) Я как-раз переделываю генератор под другую модель, съелись имена XML элементов. В этом и плюс кодогенераторов, нашел ошибку, исправил генератор, перегенерил всё: Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30.
... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 10:20 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
Ares_ekbserge79yКстати. по стандарту, диаграмм в нем тоже нет (и в этом одна из причин проблем "стандарта").Это проблема, нам приходилось выгружать модель в XMI, а диаграммы в SVG для загрузки в хранилище. Но в UML 2.5 диаграммы уже добавили, осталось дождаться когда это реализуют хотя бы в нескольких основных редакторах. Ещё профили и стереотипы конечно позволяют не изобретать новый язык моделирования. Но если стереотипов достаточно много, то проще сделать специализированный язык моделирования, чем использовать UML. Все GMF-based редакторы базируются на GMF Notation model. Переделывать под стандарт навряд ли будут. RSA точно не будут. Он ведь продан HCL, пишется теперь одними индусами, причем из изначальной команды, кто хоть как-то был причастенкс истокам продукта осталось два индуса и они совершенно не хотят заниматься RSA. Да и в скиллов нема у них для такой работы.... Переход на новую notation model это большой геммор. Существующие продукты навряд ли будут передывать. Профайлы - это еще одна беда UML. Как раз в контексте контроля версий. Если у нас есть две версии, их общий предок и каждая версия и предок имеют профайлы разных версий, то сравнивать и мержить такое проблематично. Плюс в UML2 SDK в Eclipse есть дефект с миграцией модели на профайл новой версии. Миграция может менять xmi:id на рэндомные для stereotype application-ов в ресурсе. Мне пришлось свой метод писать для апгрейда версий профайла из-за этого.... ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 10:37 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
Ares_ekbDSL нужны чтобы скрыть технические детали реализации. Выражения на DSL можно анализировать и добавлять в реализацию кучу логики, которой в исходном выражении нет. В этом примере видно, что в коде появляются условия и циклы, которых в исходном выражении даже близко нет. Ровно также когда вы пишите код на SQL или LINQ вы не пишите условия, циклы и т.п. Ну дык DSL можно писать и на Java для Java. Хотя больше эту тему форсят JetBrains в Kotlin. Насчет "манагеров", то пусть рисуют, только с этими картинками к программистам не надо лезть. Все равно программировать не умеют. :-) ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 11:08 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
mad_nazgul, а вы думаете на чём у меня этот DSL реализован? На Java все парсеры/сериализаторы и реализованы + преобразования моделей на QVTo. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 11:14 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
mad_nazgulНасчет "манагеров", то пусть рисуют, только с этими картинками к программистам не надо лезть. Все равно программировать не умеют. :-) А программисты тут для написания ФЛК нафиг и не нужны. Их пишут аналитики, а программист нужен только чтобы написать кодогенератор один раз и всё. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 11:18 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
Ares_ekbmad_nazgulНасчет "манагеров", то пусть рисуют, только с этими картинками к программистам не надо лезть. Все равно программировать не умеют. :-) А программисты тут для написания ФЛК нафиг и не нужны. Их пишут аналитики, а программист нужен только чтобы написать кодогенератор один раз и всё. Абстракции дырявы. Есть правда одна "универсальная" система для написания ФЛК - regexp. Но как то, для среднестатистического менеджера - "СЛОЖНА". Да и для среднестатистического программиста то же не просто. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 14:15 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
mad_nazgul, и какой выход? Уволить маркетологов/менеджеров и дать программистам спокойно писать ФЛК в коде? Спасибо, но, нет, я слишком ленивый, чтобы писать их руками. Пусть их пишут аналитики, а я буду просто генерить нужный код. Мне проще и интересней написать генератор, чем заниматься тупой рутиной. Для regexp достаточно XSD, там вообще писать ничего не надо. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 15:17 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
Ares_ekbmayton, классический пример - это 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? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 15:26 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
Ares_ekbmad_nazgul, и какой выход? Уволить маркетологов/менеджеров и дать программистам спокойно писать ФЛК в коде? Спасибо, но, нет, я слишком ленивый, чтобы писать их руками. Пусть их пишут аналитики, а я буду просто генерить нужный код. Мне проще и интересней написать генератор, чем заниматься тупой рутиной. Так не надо даже писать. Есть regexp-же :-) Ares_ekbДля regexp достаточно XSD, там вообще писать ничего не надо. Чта?! Какое отношение XSD имеет к регулярным выражения?! ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 15:34 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
mad_nazgul, слишком наркоманский тролинг. Регулярки можно зашить в XSD и никакие дополнительные ФЛК писать не надо: Код: xml 1. 2. 3. 4. 5.
Очевидно, что регулярками не покрыть все ФЛК, пример был выше. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 16:45 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
Гуглил ФЛК.... Футбольный любительский клаб? Финансы Лизинг Кредитование? ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 16:48 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
форматно-логический контроль ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 17:06 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
mayton, Groovy как таковым я никогда не пользовался, если не считать Gradle. Интересная штука. Но это всё в основном надстройки над языками программирования - EDSL или синтаксический сахар. Сейчас из "улучшенных Java" гораздо популярнее Scala или Kotlin. У Groovy мне кажется очень ограниченное применение. Я лично больше занимаюсь вещами, которые с другого конца относительно языков программирования - прикладные (бизнесовые) модели процессов, данных. Возможно я вообще сильно оторвался от мира программирования. Например, у нас были лютые споры с разработчиками на некоторых проектах. Они считали полным бредом использовать OCL для написания правил ФЛК. Что это вообще за язык, нет ни одной вакансии где требовалось бы его знание. И кажется они как-раз предлагали запилить DSL на Groovy или использовать JavaScript или что-то подобное - я не помню уже точно, но приближенное именно к языкам программирования, а не языкам моделирования или спецификации. Или они считали полным бредом писать на QVTo транслятор с одного языка на другой, когда это можно сделать на Java (правда они так и не сделали). А с другой стороны есть предметники, для которых что OCL, что JavaScript, что Groovy - это всё какая-то жесть, в которой они ничего не понимают и им это не нужно. Нормативный документ с JavaScript кодом ни один предметник никогда не подпишет. А нам нужно найти какой-то баланс, чтобы эти модели и DSL для предметников не были слишком техническими, привязанными к какому-то конкретному стеку технологий, но чтобы с другой стороны были более формальными, чем русский язык, к которому они привыкли. ... |
|||
:
Нравится:
Не нравится:
|
|||
06.05.2019, 21:00 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
Ares_ekbmayton, Groovy как таковым я никогда не пользовался, если не считать Gradle. Интересная штука. Но это всё в основном надстройки над языками программирования - EDSL или синтаксический сахар. Сейчас из "улучшенных Java" гораздо популярнее Scala или Kotlin. У Groovy мне кажется очень ограниченное применение. Я лично больше занимаюсь вещами, которые с другого конца относительно языков программирования - прикладные (бизнесовые) модели процессов, данных. Возможно я вообще сильно оторвался от мира программирования. Например, у нас были лютые споры с разработчиками на некоторых проектах. Они считали полным бредом использовать OCL для написания правил ФЛК. Что это вообще за язык, нет ни одной вакансии где требовалось бы его знание. И кажется они как-раз предлагали запилить DSL на Groovy или использовать JavaScript или что-то подобное - я не помню уже точно, но приближенное именно к языкам программирования, а не языкам моделирования или спецификации. Или они считали полным бредом писать на QVTo транслятор с одного языка на другой, когда это можно сделать на Java (правда они так и не сделали). А с другой стороны есть предметники, для которых что OCL, что JavaScript, что Groovy - это всё какая-то жесть, в которой они ничего не понимают и им это не нужно. Нормативный документ с JavaScript кодом ни один предметник никогда не подпишет. А нам нужно найти какой-то баланс, чтобы эти модели и DSL для предметников не были слишком техническими, привязанными к какому-то конкретному стеку технологий, но чтобы с другой стороны были более формальными, чем русский язык, к которому они привыкли. Можно использовать синтаксис существующего ЯП, но наделить все другой семантикой. Тогда просто используем весь арсенал парсеров и трансформаторов АСТа для данного ЯП, но со своим целями. Для этих целей лучше подходят языки типа Java, где грамматика может иметь несколько точек входа - compilation unit, expression, method/statement. Это позволит парсить куски текста без полного контекста. ... |
|||
:
Нравится:
Не нравится:
|
|||
07.05.2019, 23:39 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
Ares_ekbmad_nazgul, слишком наркоманский тролинг. Регулярки можно зашить в XSD и никакие дополнительные ФЛК писать не надо: Код: xml 1. 2. 3. 4. 5.
Очевидно, что регулярками не покрыть все ФЛК, пример был выше. Прошу прощения я спрашивал, не какое отношение регулярные выражения имеют к XSD (регулярные выражения можно использовать почти во всех ЯП и не только). А какое отношение XSD имеет к регулярным выражениям. Для чего в регулярных выражениях нужно XSD?! ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 08:07 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
Ares_ekbЯ лично больше занимаюсь вещами, которые с другого конца относительно языков программирования - прикладные (бизнесовые) модели процессов, данных. Возможно я вообще сильно оторвался от мира программирования. Например, у нас были лютые споры с разработчиками на некоторых проектах. Они считали полным бредом использовать OCL для написания правил ФЛК. Что это вообще за язык, нет ни одной вакансии где требовалось бы его знание. Так правильно спорили. "Манагеры" на своем птичьем языке что-то накалякают, а им потом это дерьмо разгребать. Любая DSL (не важно на чем) это все таки ЯП, а не язык предметной области. Соответственно для работы с ним нужно быть программистом. Тот кто знает предметную область редко когда бывает хорошим программистом. Поэтому зачем его мучить изучением программирования, когда можно мучить программистом предметной областью. Причем программисту не надо знать глубоко предметную область, достаточно знать основные термины и определения. Что гораздо проще, чем не программисту (предметнику) глубоко изучать программирование. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 08:14 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
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, либо можно написать нужный кодогенератор под свой стек технологий и под свои требования. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 10:17 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
Ares_ekb, Кто мешает использовать ФЯП, например Scala или Haskel?! Хотя, судя по BigData математикам проще писать на Python, чем на ФЯП. Вывод 1 - Если что-то нельзя описать на ЯП, то для этого нельзя написать исполняемую программу. ;-) Вывод 2 - Конечно, предметники лучше знают, свой язык если он есть. Он нужен для общения между собой. А вот со внешним миром все таки нужно что-то "попроще". Программисты же не объясняются с "бизнесом" кодом ЯП, а все таки используют естественный язык. Насчет написания кода. Так вся сложность/легкость программирования, что прототип (декорация) не отличим от готового продукта. Т.е. "программа работает" и "программа работает и в нее легко вносить изменения" это две большие разницы. На этом уже "обожглись" в нулевых с "индусами". Когда была идея, что умные аналитики нарисуют красивые диаграммы, а дешевые-программисты на аутсорсе по ним все накодят. Оказалось, что это работает очень плохо. Что гораздо дешевле нанять дорогих-программистов, чем дешевых-программистов. Вот такой парадокс :-) Сейчас вообще дошли до того что нужны программисты-мастера Т.е. как бы, что аналитики, ПМ, тестировщики и пр. не нужны, должны быть только программисты-мастера. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 12:24 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
Ares_ekbВывод 1: не всё можно или удобно описывать на языках программирования. Есть формальные языки (языки спецификации), которые очень далеки от ЯП. Ёперный театр, ты же модельками балуешься, и не понимаешь таких простейших вещей, как формализация знаний. Однобокий из тебя ботаник... Ares_ekbВывод 2: предметники могут на порядок лучше знать свои формальные языки, чем программисты. Эти языки могут быть на столько сложными, что программист вообще хрен поймёт там что-либо. Это те же модели. И ты даже пишешь, что на Изабель их курил. Но не в коня корм... Повторюсь - мир шире твоих представлений, а ты этого не замечаешь. Узколобо мыслишь, потому что. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 12:40 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
mad_nazgulСейчас вообще дошли до того что нужны программисты-мастера Ну это же самореклама "группы товарищей". Не стоит так экзальтированно её воспринимать. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 12:42 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
Ares_ekbmad_nazgul, не всё сводится к программированию. Например, если вы полистаете эту штуку , то найдете там очень много вещей из функциональных языков программирования: алгебраические типы данных, pattern-matching, функции высшего порядка и т.п. Когда я только начинал писать на Isabelle HOL я воспринимал её исключительно как ФЯП и формулировал всё через функции. Потом я надсадился доказывать для этих функций теоремы и открыл для себя индуктивные предикаты (или отношения), которые являются сугубо логической конструкцией. Опционально для них можно сгенерить исполняемый код, но далеко не всегда. Для индуктивных предикатов на порядок проще доказывать теоремы, также в отличие от функций они могут быть недетерминированными ("возвращать" несколько значений), могут быть частично определенными, могут "вычисляться" в разных направлениях (например, для заданного результата вычисляем исходные аргументы). Хорошая линка. Почитаем. ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 13:38 |
|
Просветите в UML. Вопрос.
|
|||
---|---|---|---|
#18+
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Т.е. как бы, что аналитики, ПМ, тестировщики и пр. не нужны, должны быть только программисты-мастера.Я лично всю жизнь так и работаю: занимаюсь всем сразу. Разумеется ничего хорошего в этом нет ... |
|||
:
Нравится:
Не нравится:
|
|||
08.05.2019, 14:07 |
|
|
start [/forum/topic.php?fid=33&msg=39811133&tid=1547146]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
43ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
61ms |
get tp. blocked users: |
1ms |
others: | 313ms |
total: | 465ms |
0 / 0 |