BNF для ЯОП является инструментом. Это - разные концепты. В общем-то, не думаю, что нужно продолжать спор, давайте останемся при своих мнениях.
Это хорошо, при освоении бюджетов, но...
Не хотел писать, но чувствую, что есть недопонимание... О каком бюджете вы писали? На всякий случай - этот проект мы делаем вне работы, хотя порой пользуемся им и на работе: например, студенты берут темы на курсовые и дипломные работы, иногда у них получается внести заметный вклад в проект.
И, конечно, этот проект помогает держать форму, чтобы быть более-менее на современном уровне. Например, сейчас мы делаем инфраструктуру для реализации микросервисов на платформе SIMODO. Следующей весной попробуем целиком перевести лабы по микросервисам с golang на наш язык (как альтернативный). Сейчас работает синхронный вариант взаимодействия (REST API, OAS). К весне подключим оркестрацию и мониторинг.
А ещё, может быть, напишем специализированный язык для бекэнда. Как вам оркестратор распределённых транзакций в виде группы специальных операторов? О, нет! Сечас кто-то кинется в ChatGPT писать запрос и ответит, что такое уже есть и даже код приведёт! :-)
Ладно. В общем. Если что-то выйдет, напишу по этому поводу статью здесь. Надеюсь, будет интересно.
Это настолько простая штука что даже лень обьяснять (с)
Думаю, многим было бы интересно почитать ваш опыт реализации, а главное, передачи на сопровождение сложной задачи, реализованной с использованием графической нотации. Мне точно интересно! Буду ждать! :-)
Плюсы: отечественная наука (хоть и с опозданием в +50 лет), но дозревает до ЯОП.
Прямо уж +50? За что вы так не любите отечественную науку? :-)
Идеи и определение ЯОП были впервые сформулированы в 1994 году. Ну никак не 50 лет.
И это только идеи ЯОП. Вы считаете, что с тех пор ничего не изменяется в науке в этом направлении?
Минусы: Вы не сформулировали на языке математики, чего хотите достичь, значит, понимаете задачу интуитивно.
Отчасти вы правы. Но в интуитивном понимании задачи нет ничего плохого. В той же математике интуитивисткое направление вполне себе существует. См. например, Морис Клайн "Математика . Утрата определённости".
Задача, закреплённая строгим языком математики, кристаллизуется, а хотелось бы её как бы немного размять. В том числе и по этой причине была написана статья на данной платформе - в попытке поиска возможных путей дальнейшего движения.
Формулирую задачу...
Спасибо :-). В целом всё так, но это взляд только с одной из сторон. Такая формулировка несколько "кондовая", что ли. Хотелось бы оценить насколько она абстрактна, не слишком ли сужает возможные варианты управления сложностью в широком смысле. Для этого как раз и требуется интуиция. Лично я всё ещё в поиске.
Что касается плюсов и минусов нашей разработки языков, то они меняются. Мы находимся в поиске наиболее удобных для наших задач языков. И отталкиваемся именно от конкретных задач, в перую очередь. Это вносит некоторый хаос, но должно привести к хорошему результату, я надеюсь.
На мой взгляд, у графических нотаций есть одна серьёзная проблема - сложность рефакторинга. Если нужно что-то поменять, то разобраться в спагетти из связей между блоками бывает довольно сложно. Хотя, может быть, всё зависит от самодисциплины и первоначальной структурированности. А ещё от привычки. Мне кажется, мы часто попадаем в ловушку обучения на простых задачах, для которых графические нотации идеальны. Но при усложнении задачи появляются проблемы -- см. предел Дойча.
Есть ли какой-ибо язык для формализации алгоритмов бизнес-процессов (EPC, WF2M, BPMN) или подобие "Пример прототипирования блок-диаграмм для АСМ SIMODO?
Никто не против графических нотаций. Однако те из них, которые вы привели, чаще всего используются для общения между людьми. А если нужно их формализовать для алгоритмизации, то всё равно придётся использовать какой-то язык - хоть Питон, хоть С.
А можно конвертировать на предметно-ориентированный язык, если он существует. Об этом речь. Для этих нотаций я не знаю такого языка.
Главная слабость текстовых языков - зависимость от имён: их трудно придумывать, запоминать и не перепутать
Есть разные подходы, применение которых не вызывает подобных проблем, или, по крайней мере, сильно их упрощает. Например, тот же DDD. Если вы описываете модель на языке предметной области, то имена - это понятия этой предметной области (как правило). И в чём тогда проблема?
Если у вас все задачи решаются в MATLAB, то не вижу проблем. Вам не о чем беспокоится.
По поводу ChatGPT... А вы всегда и во всём с ним советуетесь? :-)
Можно сформулировать так: если приложение достаточно сложное, разделимо на модули или подсистемы, требует участия хотя бы нескольких команд, а также мы не имеем точной и окончательной постановки, то крайне желательно предусмотреть устойчивость его кода к изменениям (иногда это называют адаптивностью). Для этого можно использовать различные приёмы и методики. При большом объёме уже написанного кода, при попытке что-то поменять в функциональности или добавить новую, изменения придётся проводить через все слои архитектуры, которая для больших приложений важна.
Если упор делается на предметную область и связь с остальными слоями архитектуры автоматизирована, вплоть до генерации, то затраты на изменения можно существенно сократить. Об этом в статье. И эта мысль хорошо перекликается с цитатой из книжки Сергея ТарасоваДефрагментация мозга. Софтостроение изнутри, которая приведена в сообщении от OlegZH ниже.
Если приложение простое и делается одним-двумя разработчиками, то можно и "схлопнуть" - они и так "дожмут" разработку. Пару ночей не поспят, но доделают, если что.
Возможно, я не вполне понял, что вы имели в виду под термином "современная разработка". Если так, то поясните, пожалуйста.
Думаю, ваш изначальный тезис ложный. Основа ИС не информация, а обработка информации. Сама по себе информация важна, но без обработки никому не нужна. Даже на статическом сайте информация для отображения у пользователя должна быть обработана. Хотя бы переобразована из HTML на сервере в DOM на клиенте (в браузере), а ещё передана. Или вы эту обработку не считаете? Тогда где граница между "чистой" информацией и её обработкой?
Информацию и данные можно рассматривать лишь как способ сохранять состояние объектов бизнес-логики (предметной области). Однако каким именно образом я буду это делать определяется из конкретной ситуации. Например, если надёжность инфраструктуры будет достаточно высока, можно хранить состояние в памяти компьютера (если её заведомо хватит, конечно), не используя ни СУБД, ни какие-либо другие хранилища.
Длина итераций важна чтобы усилить обратную связь и вовлечённость заказчика в проект. См. Agile и соответствующие методологии разработки ПО, например.
Можно заметить, что на протяжении эволюции ИТ длинна итераций сокращалась. Если каскадную модели можно назвать одной длинной итерацией, которая чаще всего занимала весь период разработки и внедрения проекта, то такие методологии как RUP или MSF, которые пришли на смену, сократили эти итерации, за весь проект их могло быть несколько, и заказчик мог влиять на ход проекта существенно сильнее.
Гибкая разработка и соответствующие методологии ещё сильнее сокращают длительность итераций за счёт отказа от некоторых документов, например ТЗ, спецификаций и др...
Многие идеи ждали соего воплощения долго, до тех пор, пока не созревали условия. Взять хотя бы парадигму функционального программирования и лямбда-исчисления...
У меня нет уверенности на 100%, что получится, но есть план двигаться в этом направлении. "Дорогу осилит идущий" (с) Кто-то.
К сожалению, в "академической среде" не хватает дискуссионной площадки, где можно было обсудить эту тему. Или я её не нашёл пока.
Аналогия со строительством устарела уже как минимум на 20 лет, когда Мартином Фаулером был обозначен термин "рефакторинг". Расскажите, пожалуйста, как происходит рефакторинг в строительстве? А в разработке ПО это ежедневная практика для большинстрва проектов. Аналогия со строительством была очень хороша на заре развития ИТ, когда доминировала каскадная модель жизненного цикла разработки ПО.
Что касается СУБД. Дело в том, что вы в своём посте ставите БД на первое место, по сути объявляете её главенство. В современной разработке это уже не совсем так. В DDD, например, речь идёт о хранилище - некоторой прослойке, уменьшающей зависимость от конкретной СУБД и улучшающей возможности тестирования приложений. Ещё пример: брокер сообщений для микросервисов Apache Kafka, который, не являясь СУБД, может выполнять роль хранилища для некоторых задач.
В своей статье я хотел подчеркнуть первостепенное значение бизнес-логики, всё остальное - вторично, в том числе и БД. Именно этот тезис на мой взгляд должен позволить существенно продвинуться в автоматизации разработки. Если получится, то может случиться примерно такая же революция в ИТ, которая была при переходе в написании программ с машинных кодов и ассемблера на универсальные языки программирования.
Однако при гибкой разработке (Agile) аналитиков может не быть совсем. За счёт коротких итераций. См. почти любую методологию на базе манифеста Agile, например Scrum, где аналитик опционален. Техника, рекомендуемая в DDD тоже предлагает решение на этот счёт: общий язык, на котором общается команда должен быть языком предметной области, это значит, что просто переводчик с этого языка для разработчиков не нужен. Если, конечно нет других задач для аналитика.
Тут речь идёт о способе описании предметной области в таком виде, чтобы разработка и сопровождение ПО было максимально независимо от баз данных в том числе (от пользовательского интерфейса, конечно тоже). В этом случае можно было бы менять СУБД с минимальными изменениями в бизнес логике, а в идеале без изменений.
BNF для ЯОП является инструментом. Это - разные концепты. В общем-то, не думаю, что нужно продолжать спор, давайте останемся при своих мнениях.
Не хотел писать, но чувствую, что есть недопонимание... О каком бюджете вы писали? На всякий случай - этот проект мы делаем вне работы, хотя порой пользуемся им и на работе: например, студенты берут темы на курсовые и дипломные работы, иногда у них получается внести заметный вклад в проект.
И, конечно, этот проект помогает держать форму, чтобы быть более-менее на современном уровне. Например, сейчас мы делаем инфраструктуру для реализации микросервисов на платформе SIMODO. Следующей весной попробуем целиком перевести лабы по микросервисам с golang на наш язык (как альтернативный). Сейчас работает синхронный вариант взаимодействия (REST API, OAS). К весне подключим оркестрацию и мониторинг.
А ещё, может быть, напишем специализированный язык для бекэнда. Как вам оркестратор распределённых транзакций в виде группы специальных операторов? О, нет! Сечас кто-то кинется в ChatGPT писать запрос и ответит, что такое уже есть и даже код приведёт! :-)
Ладно. В общем. Если что-то выйдет, напишу по этому поводу статью здесь. Надеюсь, будет интересно.
Думаю, многим было бы интересно почитать ваш опыт реализации, а главное, передачи на сопровождение сложной задачи, реализованной с использованием графической нотации. Мне точно интересно! Буду ждать! :-)
Прямо уж +50? За что вы так не любите отечественную науку? :-)
Идеи и определение ЯОП были впервые сформулированы в 1994 году. Ну никак не 50 лет.
И это только идеи ЯОП. Вы считаете, что с тех пор ничего не изменяется в науке в этом направлении?
Отчасти вы правы. Но в интуитивном понимании задачи нет ничего плохого. В той же математике интуитивисткое направление вполне себе существует. См. например, Морис Клайн "Математика . Утрата определённости".
Задача, закреплённая строгим языком математики, кристаллизуется, а хотелось бы её как бы немного размять. В том числе и по этой причине была написана статья на данной платформе - в попытке поиска возможных путей дальнейшего движения.
Спасибо :-). В целом всё так, но это взляд только с одной из сторон. Такая формулировка несколько "кондовая", что ли. Хотелось бы оценить насколько она абстрактна, не слишком ли сужает возможные варианты управления сложностью в широком смысле. Для этого как раз и требуется интуиция. Лично я всё ещё в поиске.
Что касается плюсов и минусов нашей разработки языков, то они меняются. Мы находимся в поиске наиболее удобных для наших задач языков. И отталкиваемся именно от конкретных задач, в перую очередь. Это вносит некоторый хаос, но должно привести к хорошему результату, я надеюсь.
Спасибо. Посмотрю.
Спасибо! Буду иметь в виду.
На мой взгляд, у графических нотаций есть одна серьёзная проблема - сложность рефакторинга. Если нужно что-то поменять, то разобраться в спагетти из связей между блоками бывает довольно сложно. Хотя, может быть, всё зависит от самодисциплины и первоначальной структурированности. А ещё от привычки. Мне кажется, мы часто попадаем в ловушку обучения на простых задачах, для которых графические нотации идеальны. Но при усложнении задачи появляются проблемы -- см. предел Дойча.
Никто не против графических нотаций. Однако те из них, которые вы привели, чаще всего используются для общения между людьми. А если нужно их формализовать для алгоритмизации, то всё равно придётся использовать какой-то язык - хоть Питон, хоть С.
А можно конвертировать на предметно-ориентированный язык, если он существует. Об этом речь. Для этих нотаций я не знаю такого языка.
Есть разные подходы, применение которых не вызывает подобных проблем, или, по крайней мере, сильно их упрощает. Например, тот же DDD. Если вы описываете модель на языке предметной области, то имена - это понятия этой предметной области (как правило). И в чём тогда проблема?
Если у вас все задачи решаются в MATLAB, то не вижу проблем. Вам не о чем беспокоится.
По поводу ChatGPT... А вы всегда и во всём с ним советуетесь? :-)
Согласен. Спасибо за комментарий и вам и всем участникам. Было полезно.
Осталось только действительно сделать что-то по-настоящему стоящее :-).
Можно сформулировать так: если приложение достаточно сложное, разделимо на модули или подсистемы, требует участия хотя бы нескольких команд, а также мы не имеем точной и окончательной постановки, то крайне желательно предусмотреть устойчивость его кода к изменениям (иногда это называют адаптивностью). Для этого можно использовать различные приёмы и методики. При большом объёме уже написанного кода, при попытке что-то поменять в функциональности или добавить новую, изменения придётся проводить через все слои архитектуры, которая для больших приложений важна.
Если упор делается на предметную область и связь с остальными слоями архитектуры автоматизирована, вплоть до генерации, то затраты на изменения можно существенно сократить. Об этом в статье. И эта мысль хорошо перекликается с цитатой из книжки Сергея Тарасова Дефрагментация мозга. Софтостроение изнутри, которая приведена в сообщении от OlegZH ниже.
Если приложение простое и делается одним-двумя разработчиками, то можно и "схлопнуть" - они и так "дожмут" разработку. Пару ночей не поспят, но доделают, если что.
Возможно, я не вполне понял, что вы имели в виду под термином "современная разработка". Если так, то поясните, пожалуйста.
Определения одного понятия бывают разные. Некоторые мне нравятся больше, некоторые меньше :-).
Думаю, ваш изначальный тезис ложный. Основа ИС не информация, а обработка информации. Сама по себе информация важна, но без обработки никому не нужна. Даже на статическом сайте информация для отображения у пользователя должна быть обработана. Хотя бы переобразована из HTML на сервере в DOM на клиенте (в браузере), а ещё передана. Или вы эту обработку не считаете? Тогда где граница между "чистой" информацией и её обработкой?
Информацию и данные можно рассматривать лишь как способ сохранять состояние объектов бизнес-логики (предметной области). Однако каким именно образом я буду это делать определяется из конкретной ситуации. Например, если надёжность инфраструктуры будет достаточно высока, можно хранить состояние в памяти компьютера (если её заведомо хватит, конечно), не используя ни СУБД, ни какие-либо другие хранилища.
Длина итераций важна чтобы усилить обратную связь и вовлечённость заказчика в проект. См. Agile и соответствующие методологии разработки ПО, например.
Можно заметить, что на протяжении эволюции ИТ длинна итераций сокращалась. Если каскадную модели можно назвать одной длинной итерацией, которая чаще всего занимала весь период разработки и внедрения проекта, то такие методологии как RUP или MSF, которые пришли на смену, сократили эти итерации, за весь проект их могло быть несколько, и заказчик мог влиять на ход проекта существенно сильнее.
Гибкая разработка и соответствующие методологии ещё сильнее сокращают длительность итераций за счёт отказа от некоторых документов, например ТЗ, спецификаций и др...
Длина итераций имеет значение... :-).
Салют!
Многие идеи ждали соего воплощения долго, до тех пор, пока не созревали условия. Взять хотя бы парадигму функционального программирования и лямбда-исчисления...
У меня нет уверенности на 100%, что получится, но есть план двигаться в этом направлении. "Дорогу осилит идущий" (с) Кто-то.
К сожалению, в "академической среде" не хватает дискуссионной площадки, где можно было обсудить эту тему. Или я её не нашёл пока.
Аналогия со строительством в настоящее время совершенно неуместна, см. мой комментарий выше.
Аналогия со строительством устарела уже как минимум на 20 лет, когда Мартином Фаулером был обозначен термин "рефакторинг". Расскажите, пожалуйста, как происходит рефакторинг в строительстве? А в разработке ПО это ежедневная практика для большинстрва проектов. Аналогия со строительством была очень хороша на заре развития ИТ, когда доминировала каскадная модель жизненного цикла разработки ПО.
Что касается СУБД. Дело в том, что вы в своём посте ставите БД на первое место, по сути объявляете её главенство. В современной разработке это уже не совсем так. В DDD, например, речь идёт о хранилище - некоторой прослойке, уменьшающей зависимость от конкретной СУБД и улучшающей возможности тестирования приложений. Ещё пример: брокер сообщений для микросервисов Apache Kafka, который, не являясь СУБД, может выполнять роль хранилища для некоторых задач.
В своей статье я хотел подчеркнуть первостепенное значение бизнес-логики, всё остальное - вторично, в том числе и БД. Именно этот тезис на мой взгляд должен позволить существенно продвинуться в автоматизации разработки. Если получится, то может случиться примерно такая же революция в ИТ, которая была при переходе в написании программ с машинных кодов и ассемблера на универсальные языки программирования.
Прекрасный отрывок. Отложил себе эту книгу :-).
Таких аккумуляций много. Тот же DDD. Паттерны проектирования, MVC... Микросервисная архитектура, DevOps... Это только то, что сразу приходит на ум.
Однако при гибкой разработке (Agile) аналитиков может не быть совсем. За счёт коротких итераций. См. почти любую методологию на базе манифеста Agile, например Scrum, где аналитик опционален. Техника, рекомендуемая в DDD тоже предлагает решение на этот счёт: общий язык, на котором общается команда должен быть языком предметной области, это значит, что просто переводчик с этого языка для разработчиков не нужен. Если, конечно нет других задач для аналитика.
Тут речь идёт о способе описании предметной области в таком виде, чтобы разработка и сопровождение ПО было максимально независимо от баз данных в том числе (от пользовательского интерфейса, конечно тоже). В этом случае можно было бы менять СУБД с минимальными изменениями в бизнес логике, а в идеале без изменений.