Дмитрий ConceptВсе-равно, по факту, в современном мире деньги определяют все.
И если не участвуешь в этой финансовой системе кровообращения, то будешь на задворках.
И 1C Битрикс и Амо СРМ - рулез!!! Алилуя!!! Что будет через 5 лет, кого этот интересует?
Я это проходил. Многие говорили, что победит Виндовз. Я сделал на них ставку. Я проиграл.
Что дальше? Слушать новых Оракулов?
Вообще то умные люди говорили "Microsoft must die!"
И они таки не ошиблись
В этом легко убедиться, посмотрев статистику популярности браузеров и прочитав фразу в стиле "To install the mssql-server Package on
Ubuntu , follow these steps" по адресу docs.
microsoft.com /en-us/sql/linux/sql-server-linux-setup-ubuntu
Вообще, желательно слушать не Оракулов, а аргументы. И тогда риск ошибиться можно снизить, хотя и не до нуля.
Ранее вы привели очень хороший список:
Дмитрий ConceptВот если сделать CASE технологию, которая бы была:
1.Простой в изучении и использовании.
2.Дешевой.
3.Гибкой (настраивалась на выходные языки программирования и среды, Фреймворки, интерфейсы и т.д.)
4.Использовала на входе описание модели информационной системы/ПО в популярных нотациях (UML, ER, XML)
5.Поддерживала автоматическое документирование для всех этапов жизненного цикла ПО.
Но если его проанализировать, получается, что в нем есть внутренние противоречия.
Например "Поддерживала автоматическое документирование для всех этапов жизненного цикла ПО."
Это требование действительно очень важное. Любой, кто хоть раз разбирал код, написанный более нескольких месяцев назад (даже если это твой собственный код), с этим согласится.
Причем об этом говорят уже очень долго.
Какие есть
работающие решения этой задачи? Я знаю только одно - сам код писать в соответствии с некими стандартами (комментарии, имена функций, оформление и т.д.), чтобы он и был документацией. Никаких других работающих вариантов не придумали. Но если мы будем вручную править текст программы, то зачем нам документировать все на уровне нотаций? И как добиться того, чтобы документация на уровне UML совпадала с тем, что в реальности делает программа?
А теперь убираем из списка пункт "3.Гибкой (настраивалась на выходные языки программирования и среды, Фреймворки, интерфейсы и т.д.)"
И сравниваем с BPM системами. Совпадение очень близкое:
Относительно простые в освоении.
Не очень дорогие (Bonita - open source)
На входе используют описание на популярном языке (BPMN)
Автоматически всё документируют (BPMN с комментариями - это и есть неплохая документация)
Разумеется, всё совсем не идеально, но - достаточно хорошо.
А теперь подумаем - а зачем нам нужен этот очень сложный элемент?
Я говорю о преобразовании
"описание модели информационной системы/ПО в популярных нотациях (UML, ER, XML)" --> "текст программы на ЯП высокого уровня".
Вот какую он несет пользу?
Для обучения - да, иногда полезен. Но в практической работе?
Возьмем простой пример - ACCESS. Большая часть пользователей работает с ним в графическом интерфейсе, рисуя стрелочки и расставляя флажки - и успешно создает относительно простые приложения. Меньшая часть пишет код на SQL. И использует графический интерфейс только в отдельных случаях.
Но например разработать сложный (несколько таблиц со сложными связями) и оптимизированный запрос, используя только графический интерфейс - практически невозможно. То есть как бы мы не изгалялись, сделать такой запрос сможет только квалифицированный специалист, и он это будет делать напрямую в 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.
INSERT INTO [Analysis].[Grouped CoGS Value Entry]
([Company ID]
,[Item Ledger Entry No_]
,[Positive]
,[Document Type]
,[Document No_]
,[Document Line No_]
,[ILE Quantity]
,[Invoiced Quantity]
,[From Value Entry No]
,[To Value Entry No]
,[To Check (Minimum)]
,[Equal (To Process)]
,[Cost Amt_(Non-Inv_) Expense])
SELECT
ve.[Company ID]
,ve.[Item Ledger Entry No_]
,ile.Positive
,ve.[Document Type]
,ve.[Document No_]
,ve.[Document Line No_]
,ile.Quantity as [ILE Quantity]
,invoiced_q_line.[Invoiced Quantity]
,coalesce(ve_prev.[Entry No_],0) as [From Value Entry No]
,ve.[Entry No_] as [To Value Entry No]
,0 as [To Check (Minimum)]
,0 as [Equal (To Process)]
,ve.[Cost Amt_(Non-Inv_) Expense]
FROM [Analysis].[Track Calculate - VE] as ve
inner join [Analysis].[Track Calculate - ILE] as ile
on ile.[Company ID] = ve.[Company ID]
and ile.[Entry No_] = ve.[Item Ledger Entry No_]
inner join [Analysis].[Track Calculate - VE] as invoiced_q_line
on invoiced_q_line.[Company ID] = ve.[Company ID]
and invoiced_q_line.[Item Ledger Entry No_] = ve.[Item Ledger Entry No_]
and invoiced_q_line.[Document Type] = ve.[Document Type]
and invoiced_q_line.[Document No_] = ve.[Document No_]
and invoiced_q_line.[Document Line No_] = ve.[Document Line No_]
and invoiced_q_line.[Invoiced Quantity] <> 0
OUTER APPLY
(select top 1
ve_prev.[Entry No_]
from [Analysis].[Track Calculate - VE] as ve_prev
where ve.[Company ID] = ve_prev.[Company ID]
and ve.[Item Ledger Entry No_] = ve_prev.[Item Ledger Entry No_]
and ve.[Document Type] = ve_prev.[Document Type]
and ve.[Document No_] = ve_prev.[Document No_]
and ve.[Document Line No_] = ve_prev.[Document Line No_]
and ve.[Entry No_] > ve_prev.[Entry No_]
and ve_prev.[Item Ledger Entry Type] = 1
and ve_prev.[Cost Amt_(Non-Inv_) Expense] <> 0
order by ve_prev.[Entry No_] desc
) as ve_prev
where ve.[Item Ledger Entry Type] = 1
and ve.[Cost Amt_(Non-Inv_) Expense] <> 0
and NOT EXISTS
(Select * from [Analysis].[Operation Entry (Table)] as exist_op
where ve.[Company ID] = exist_op.[Item Ledger Company ID]
and ve.[Item Ledger Entry No_] = exist_op.[Item Ledger Entry No]
and ve.[Entry No_] = exist_op.[Value Entry No]
and exist_op.[Initial Value Entry No] <> exist_op.[Value Entry No])
;
Попробуйте его описать в популярной нотации
Засеките время, подумайте, - какие нужны знания для создания такого описания? Будет ли описание в популярной нотации понятнее, чем сам текст запроса на SQL?
И подумайте - кто будет (сможет) на практике пользоваться этим функционалом? И будет ли это легче и быстрее (дешевле), чем писать сразу на SQL?
Например, это могло бы быть дешевле, если использовать специалистов с более низкой квалификацией. Но поможет ли использование графической нотации (интерфейса) написать такой запрос пользователю, который не может его написать на SQL?
