[Архитектура] Прикладные системы. Общие наблюдения.
А как сюда вписываются системы типа процессинговых центров и биллингов? Я затрудняюсь определить, что такое редактор в подобных системах.
> типа процессинговых центров и биллингов
о таких системах (в которых, преобладает процессы, а не статика) хочу рассказать чуть позже.
Основная мысль - что даже, такие динамические системы, можно эффективно рассматривать, как "статические".
> Я затрудняюсь определить, что такое редактор в подобных системах.
редактор - это добавления новых документов, изменения в старых документах и т.д.
в таких системах - "редактор" - это неявные изменения пользователей, изменения внешнего окружения и т.д.
также, в процессинговых системах - как раз на первое место - выходят модули отслеживания изменений и ИИ.
т.е., например, пользователь скачал еще метр трафика - произошло изменение - далее включается модуль "отслеживания изменений", который пересчитывает общий объем потраченного трафика, его стоимость и т.д.
и далее с помощью модуля ИИ принимает решение - необходимо какое-то активное действие со своей стороны сделать (например, отключить от интернета) или нет.
о таких системах (в которых, преобладает процессы, а не статика) хочу рассказать чуть позже.
Основная мысль - что даже, такие динамические системы, можно эффективно рассматривать, как "статические".
> Я затрудняюсь определить, что такое редактор в подобных системах.
редактор - это добавления новых документов, изменения в старых документах и т.д.
в таких системах - "редактор" - это неявные изменения пользователей, изменения внешнего окружения и т.д.
также, в процессинговых системах - как раз на первое место - выходят модули отслеживания изменений и ИИ.
т.е., например, пользователь скачал еще метр трафика - произошло изменение - далее включается модуль "отслеживания изменений", который пересчитывает общий объем потраченного трафика, его стоимость и т.д.
и далее с помощью модуля ИИ принимает решение - необходимо какое-то активное действие со своей стороны сделать (например, отключить от интернета) или нет.
о таких системах (в которых, преобладает процессы, а не статика) хочу рассказать чуть позже.А зачем? Для чего нужно то, что ты описываешь?
Основная мысль - что даже, такие динамические системы, можно эффективно рассматривать, как "статические".
Я к тому, что само по себе разделение достаточно условно, и не всегда вообще осуществимо. Например, не всегда можно разделить редактор от "вьювера", тем более, что редактор в некотором роде - вьювер. Тяжело отделить и редактор и "вьювер" от хранилища, например, или от ИИ (например, вполне логично, что часть ИИ работает внутри хранилища). Архитектурно эти компоненты часто слишком сложно отделимы... Так что, imho, ты занимаешься чем-то ненужным...
моя основная цель - это уметь разрабатывать в очень сжатые сроки - целые семейства систем.
соответственно этой цели можно добиться - только если системы собирать из готовых кирпичиков.
вот контуры таких кирпичей я и наметил.
> , не всегда можно разделить редактор от "вьювера", тем более, что редактор в некотором роде - вьювер
нельзя отделить на логическом или на физическом уровне?
если можно отделить на логическом уровне, то почему часто считается, что тоже самое нельзя сделать на физическом уровне?
соответственно этой цели можно добиться - только если системы собирать из готовых кирпичиков.
вот контуры таких кирпичей я и наметил.
> , не всегда можно разделить редактор от "вьювера", тем более, что редактор в некотором роде - вьювер
нельзя отделить на логическом или на физическом уровне?
если можно отделить на логическом уровне, то почему часто считается, что тоже самое нельзя сделать на физическом уровне?
Слишком легко сводится один к другому.
Если ты не считаешь за просмотр отработку.
---
...Я работаю антинаучным аферистом...
Если ты не считаешь за просмотр отработку.
---
...Я работаю антинаучным аферистом...
От иерархических систем, в том числе и описательных, уже давно отказались.
Ты переизобретаешь велосипед.
---
...Я работаю антинаучным аферистом...
Ты переизобретаешь велосипед.
---
...Я работаю антинаучным аферистом...
> моя основная цель - это уметь разрабатывать в очень сжатые сроки - целые семейства систем.
Не ты первый такую цель ставишь... Далеко не первый. Между тем думаю, что сама идея - порочна, равно как порочна идея составить универсальную CMS для сайтов, и т.п. Универсальных решений не бывает... Они либо ограничены, либо настолько сложны, что настройка их ничуть не проще, чем программирование "с нуля".
> соответственно этой цели можно добиться - только если системы собирать из готовых кирпичиков.
не всё можно разделить на "кирпичики". Как ты понимаешь, на кирпичики можно разделить только в том случае, если связь с внешним миром этого кирпичика можно ограничить каким-нибудь достаточно простым интерфейсом, когда сложность взаимодействия и управления этим кирпичиком будет не очень большой. К сожалению, это далеко не всегда возможно...
>> , не всегда можно разделить редактор от "вьювера", тем более, что редактор в некотором роде - вьювер
> нельзя отделить на логическом или на физическом уровне?
> если можно отделить на логическом уровне, то почему часто считается, что тоже самое нельзя сделать на физическом уровне?
Потому, что когда-то рациональнее запихнуть часть логики на один уровень, а когда-то - на другой, и универсального метода, или хотя-бы критерия, по которому нужно отделять - нет. В частности, управление хранилищем данных в одних случаях рационально производить на уровне хранилища, составляя извращённые запросы select или используя всякие plsql/pgsql (если хранилище воспринимать как БД а иногда - вынести часть логики на уровень ближе к редактору/вьюверу. В любом случае, если ты и получишь разделение - то слишком общее, недостаточное для того, чтобы существенно ускорять разработку систем.
Не ты первый такую цель ставишь... Далеко не первый. Между тем думаю, что сама идея - порочна, равно как порочна идея составить универсальную CMS для сайтов, и т.п. Универсальных решений не бывает... Они либо ограничены, либо настолько сложны, что настройка их ничуть не проще, чем программирование "с нуля".
> соответственно этой цели можно добиться - только если системы собирать из готовых кирпичиков.
не всё можно разделить на "кирпичики". Как ты понимаешь, на кирпичики можно разделить только в том случае, если связь с внешним миром этого кирпичика можно ограничить каким-нибудь достаточно простым интерфейсом, когда сложность взаимодействия и управления этим кирпичиком будет не очень большой. К сожалению, это далеко не всегда возможно...
>> , не всегда можно разделить редактор от "вьювера", тем более, что редактор в некотором роде - вьювер
> нельзя отделить на логическом или на физическом уровне?
> если можно отделить на логическом уровне, то почему часто считается, что тоже самое нельзя сделать на физическом уровне?
Потому, что когда-то рациональнее запихнуть часть логики на один уровень, а когда-то - на другой, и универсального метода, или хотя-бы критерия, по которому нужно отделять - нет. В частности, управление хранилищем данных в одних случаях рационально производить на уровне хранилища, составляя извращённые запросы select или используя всякие plsql/pgsql (если хранилище воспринимать как БД а иногда - вынести часть логики на уровень ближе к редактору/вьюверу. В любом случае, если ты и получишь разделение - то слишком общее, недостаточное для того, чтобы существенно ускорять разработку систем.
где ты увидел иерархию?
тем более отказались от систем, которые жестко опираются на иерархию, а не от систем, работающих с иерархией.
ps
Если брать даже обычный компьютер - то иерархия никуда не делась, даже файловая система - и то иерархическая.
Берем форум - и опять иерархия.
тем более отказались от систем, которые жестко опираются на иерархию, а не от систем, работающих с иерархией.
ps
Если брать даже обычный компьютер - то иерархия никуда не делась, даже файловая система - и то иерархическая.
Берем форум - и опять иерархия.
Два уровня ты расписал.
Всё зависит от операционной системы.
Не везде есть файловая система. Не везде есть иерархия.
---
...Я работаю антинаучным аферистом...
Всё зависит от операционной системы.
Не везде есть файловая система. Не везде есть иерархия.
---
...Я работаю антинаучным аферистом...
> Они либо ограничены, либо настолько сложны, что настройка их ничуть не проще, чем программирование "с нуля".
> Как ты понимаешь, на кирпичики можно разделить только в том случае, если связь с внешним миром этого кирпичика можно ограничить каким-нибудь достаточно простым интерфейсом, когда сложность взаимодействия и управления этим кирпичиком будет не очень большой. К сожалению, это далеко не всегда возможно...
оба выводы верны, только если считать, что настройка выполняется человеком полностью в ручную.
> В частности, управление хранилищем данных в одних случаях рационально производить на уровне хранилища, составляя извращённые запросы select или используя всякие plsql/pgsql (если хранилище воспринимать как БД а иногда - вынести часть логики на уровень ближе к редактору/вьюверу.
и зачем такое разделение надо принимать во внимание?
тот же .net код, или xquery-запросы - можно выполнять как на уровне хранилища, так и на уровне - бизнес-сервера, так и на уровне клиента.
> Как ты понимаешь, на кирпичики можно разделить только в том случае, если связь с внешним миром этого кирпичика можно ограничить каким-нибудь достаточно простым интерфейсом, когда сложность взаимодействия и управления этим кирпичиком будет не очень большой. К сожалению, это далеко не всегда возможно...
оба выводы верны, только если считать, что настройка выполняется человеком полностью в ручную.
> В частности, управление хранилищем данных в одних случаях рационально производить на уровне хранилища, составляя извращённые запросы select или используя всякие plsql/pgsql (если хранилище воспринимать как БД а иногда - вынести часть логики на уровень ближе к редактору/вьюверу.
и зачем такое разделение надо принимать во внимание?
тот же .net код, или xquery-запросы - можно выполнять как на уровне хранилища, так и на уровне - бизнес-сервера, так и на уровне клиента.
Тяжело отделить и редактор и "вьювер" от хранилища, например, или от ИИ (например, вполне логично, что часть ИИ работает внутри хранилища). Архитектурно эти компоненты часто слишком сложно отделимы...Согласен.
моя основная цель - это уметь разрабатывать в очень сжатые сроки - целые семейства систем.Фразу "собирать из готовых кирпичиков" можно понимать по-разному. Например, если под ней подразумевается, что система, которую мы делаем, будет состоять из частей, и эти части уже были написаны до того, как нашей системы еще в проекте не было, то "собирать из кирпичиков" это значит сильно себя ограничивать.
соответственно этой цели можно добиться - только если системы собирать из готовых кирпичиков.
Гораздо интереснее создать удобную платформу, на которой будут собираться системы. Если под кирпичиками подразумевается платформа, то это другое дело. Но за платформой должна стоять идея. Идея должна быть с одной стороны абстрактной с точки зрения прикладных систем, с другой стороны вполне конкретной с точки зрения реализации.
> Фразу "собирать из готовых кирпичиков" можно понимать по-разному.
в первую очередь, хочеться собирать из готовых кирпичиков - хотя бы логическую(верхние уровни) часть систем.
в первую очередь, хочеться собирать из готовых кирпичиков - хотя бы логическую(верхние уровни) часть систем.
>> Будем дальше переоткрывать метод пошагового уточнения?
> с какой целью его переоткрывать, если ему можно просто следовать?
Выше ты предлагал не следовать старому просто так.
Теперь мы уже скатились на старые рельсы пошагового уточнения.
Будем продолжать, или ты пройдёшь сразу к следующей отметке,
чтобы не вытаскивать тебя к ней мелкими шажками?
> предварительные требования становятся известны завтра (в будущем)
Приходите завтра.
> а подготовиться я к ним хочу сегодня (в текущий момент).
Хоть сколько-нибудь подготовившись.
> при чем своей подготовкой сегодня я управлять могу,
> но я не могу управлять тем, какие требования представит заказчик завтра.
А заказчик тоже отвлечённый? Сферический и вакуумированный?
Или он хоть какие-то требования предъявил?
>> Достаточная определённость свойств разрабатываемых систем до начала разработки.
> у меня нет готового ответа на такой общий вопрос.
Каковы требования, таков и уточняющий вопрос.
---
"Истина всегда конкретна."
> с какой целью его переоткрывать, если ему можно просто следовать?
Выше ты предлагал не следовать старому просто так.
Теперь мы уже скатились на старые рельсы пошагового уточнения.
Будем продолжать, или ты пройдёшь сразу к следующей отметке,
чтобы не вытаскивать тебя к ней мелкими шажками?
> предварительные требования становятся известны завтра (в будущем)
Приходите завтра.
> а подготовиться я к ним хочу сегодня (в текущий момент).
Хоть сколько-нибудь подготовившись.
> при чем своей подготовкой сегодня я управлять могу,
> но я не могу управлять тем, какие требования представит заказчик завтра.
А заказчик тоже отвлечённый? Сферический и вакуумированный?
Или он хоть какие-то требования предъявил?
>> Достаточная определённость свойств разрабатываемых систем до начала разработки.
> у меня нет готового ответа на такой общий вопрос.
Каковы требования, таков и уточняющий вопрос.
---
"Истина всегда конкретна."
> Будем продолжать, или ты пройдёшь сразу к следующей отметке,
можно продолжать - особенно если ты попытаешься сказать - а что ты хочешь услышать.
если бы я знал - что такое следующая отметка и как туда попасть - я там бы уже был.
> Приходите завтра.
я хочу сегодня, т.к. есть вероятность - что завтра будет поздно.
> Хоть сколько-нибудь подготовившись.
как ты поймешь, что я подготовился?
> Или он хоть какие-то требования предъявил?
Всё, вчера, дешево, и чтоб работало.
> Каковы требования, таков и уточняющий вопрос.
пока я не понимаю - куда ты клонишь.
если ты хочешь меня убедить - что моя цель недостижима, то мне это лишь отчасти интересно.
если у тебя есть готовый ответ, и ты из меня пытаешься выдавить детали - так просто сформулируй какие детали тебе нужны.
если тебе нужна конкретика, чтобы обрести почву под ногами - так скажи об этом, и мы вместе подумаем - что именно и зачем необходимо зафиксировать.
можно продолжать - особенно если ты попытаешься сказать - а что ты хочешь услышать.
если бы я знал - что такое следующая отметка и как туда попасть - я там бы уже был.
> Приходите завтра.
я хочу сегодня, т.к. есть вероятность - что завтра будет поздно.
> Хоть сколько-нибудь подготовившись.
как ты поймешь, что я подготовился?
> Или он хоть какие-то требования предъявил?
Всё, вчера, дешево, и чтоб работало.
> Каковы требования, таков и уточняющий вопрос.
пока я не понимаю - куда ты клонишь.
если ты хочешь меня убедить - что моя цель недостижима, то мне это лишь отчасти интересно.
если у тебя есть готовый ответ, и ты из меня пытаешься выдавить детали - так просто сформулируй какие детали тебе нужны.
если тебе нужна конкретика, чтобы обрести почву под ногами - так скажи об этом, и мы вместе подумаем - что именно и зачем необходимо зафиксировать.
> если у тебя есть готовый ответ,
Да, у меня есть ответ.
На абстрактные вопросы у меня всегда есть абстрактные ответы.
> и ты из меня пытаешься выдавить детали -
> так просто сформулируй какие детали тебе нужны.
Уже сформулировал.
> если тебе нужна конкретика, чтобы обрести почву под ногами -
> так скажи об этом, и мы вместе подумаем - что именно
> и зачем необходимо зафиксировать
---
...Я работаю антинаучным аферистом...
Да, у меня есть ответ.
На абстрактные вопросы у меня всегда есть абстрактные ответы.
> и ты из меня пытаешься выдавить детали -
> так просто сформулируй какие детали тебе нужны.
Уже сформулировал.
> если тебе нужна конкретика, чтобы обрести почву под ногами -
> так скажи об этом, и мы вместе подумаем - что именно
> и зачем необходимо зафиксировать
---
...Я работаю антинаучным аферистом...
могу, например, так зафиксировать:
в первую очередь, интересуют:
большие системы автоматизирующие какую-либо деятельность людей.
кол-венные оценки, например, такие:
кол-во видов сущностей: 100 - 1000 - 10^6 и больше
кол-во пользователей - 100 - 10^6 - 10^9 и больше.
приоритеты (от наиболее важных к менее):
скорость разработки (время между появлением требования до его появления в рабочем варианте системы)
гибкость системы (система должна по максимуму позволять добавление доп. функциональности с минимум изменений уже написанного функционала)
масштабируемость системы (должно быть понятным, что необходимо сделать при увеличении/уменьшение кол-венных требований)
скорость работы системы
в первую очередь, интересуют:
большие системы автоматизирующие какую-либо деятельность людей.
кол-венные оценки, например, такие:
кол-во видов сущностей: 100 - 1000 - 10^6 и больше
кол-во пользователей - 100 - 10^6 - 10^9 и больше.
приоритеты (от наиболее важных к менее):
скорость разработки (время между появлением требования до его появления в рабочем варианте системы)
гибкость системы (система должна по максимуму позволять добавление доп. функциональности с минимум изменений уже написанного функционала)
масштабируемость системы (должно быть понятным, что необходимо сделать при увеличении/уменьшение кол-венных требований)
скорость работы системы
Распределённость?
Формализованность?
Учёт времени?
Документооборот? (Есть готовые решения, см. groupware.)
Groupware?
Wiki?
В случае распределённости достаточно разработать протокол прикладного уровня
поверх уже существующего (вернее --- существующих).
Соответственно, объёмы работы кодирования определяются сложностью протокола.
---
...Я работаю антинаучным аферистом...
Формализованность?
Учёт времени?
Документооборот? (Есть готовые решения, см. groupware.)
Groupware?
Wiki?
В случае распределённости достаточно разработать протокол прикладного уровня
поверх уже существующего (вернее --- существующих).
Соответственно, объёмы работы кодирования определяются сложностью протокола.
---
...Я работаю антинаучным аферистом...
Тогда тебе, всё же, нужно не универсальные решения искать, а посмотреть в сторону платформ, и или брать что-то готовое, типа Oracle, либо создавать компонетны платформы под себя (скажем, если ты решаешь более простые задачи, с иной ориентацией с оглядкой на решения, которые уже существуют. На базе той же Oracle 9i/10g сейчас создано очень много бизнес-систем, это очень развитая платформа, с большими возможностями. И разделение по функциональности - тоже уже за тебя придумано... Одним словом, наука себя исчерпала, осталось только ботать и ботать.
> большие системы автоматизирующие какую-либо деятельность людей.
Это один из основных IT рынков, на котором живут большие и страшные монстры вроде Oracle и SAP. Ну и маленькие, но всё равно страшные, типа 1С. Но и здесь нет универсальных решений. Скажем, автоматизация страховой компании - это совсем не тоже самое, что автоматизация торговой фирмы, или рекламной. Везде свои особенности.
> кол-венные оценки, например, такие:
> кол-во видов сущностей: 100 - 1000 - 10^6 и больше
> кол-во пользователей - 100 - 10^6 - 10^9 и больше.
Сущность - вещь неоднозначная. Например, сущность может быть короткоживущей, которую один раз создали, ещё один раз - обработали, а бывают такие, которые живут годами, и ведутся годами. Пользователь - ещё менее однозначная сущность, важнее не сколько штук пользователей, а насколько они в правах отличаются.
Неужели ты беллетристики, которую публикуют на всяких citforum.ru или olap.ru не читал? Не верю. Зайди на olap.ru, там много про КИС и хранилища данных понаписано.
> большие системы автоматизирующие какую-либо деятельность людей.
Это один из основных IT рынков, на котором живут большие и страшные монстры вроде Oracle и SAP. Ну и маленькие, но всё равно страшные, типа 1С. Но и здесь нет универсальных решений. Скажем, автоматизация страховой компании - это совсем не тоже самое, что автоматизация торговой фирмы, или рекламной. Везде свои особенности.
> кол-венные оценки, например, такие:
> кол-во видов сущностей: 100 - 1000 - 10^6 и больше
> кол-во пользователей - 100 - 10^6 - 10^9 и больше.
Сущность - вещь неоднозначная. Например, сущность может быть короткоживущей, которую один раз создали, ещё один раз - обработали, а бывают такие, которые живут годами, и ведутся годами. Пользователь - ещё менее однозначная сущность, важнее не сколько штук пользователей, а насколько они в правах отличаются.
Неужели ты беллетристики, которую публикуют на всяких citforum.ru или olap.ru не читал? Не верю. Зайди на olap.ru, там много про КИС и хранилища данных понаписано.
> Распределённость?
да
> Формализованность?
что ты под этим понимаешь?
> Учёт времени?
не понял, к чему это.
это к разработке, или уже к применению?
> Документооборот?
> Wiki?
и документооборот и wiki работают с неструктурированном информации
соответственно - это не системы автоматизации.
> В случае распределённости достаточно разработать протокол прикладного уровня
поверх уже существующего
как-то ты резко перескакиваешь с уровня на уровень.
мы вроде обсуждали архитектуру, а не проблемы реализации.
Если архитектура монолитная - то никакие "протоколы прикладного уровня" - не помогут.
те же чисто событийные системы тяжело переносятся на распределенную архитектуру, т.к. требуют сверхнадежной и мгновенной передачи сообщений.
да
> Формализованность?
что ты под этим понимаешь?
> Учёт времени?
не понял, к чему это.
это к разработке, или уже к применению?
> Документооборот?
> Wiki?
и документооборот и wiki работают с неструктурированном информации
соответственно - это не системы автоматизации.
> В случае распределённости достаточно разработать протокол прикладного уровня
поверх уже существующего
как-то ты резко перескакиваешь с уровня на уровень.
мы вроде обсуждали архитектуру, а не проблемы реализации.
Если архитектура монолитная - то никакие "протоколы прикладного уровня" - не помогут.
те же чисто событийные системы тяжело переносятся на распределенную архитектуру, т.к. требуют сверхнадежной и мгновенной передачи сообщений.
>> Формализованность?
> что ты под этим понимаешь?
Наличие внешних законодательных норм, вроде бухгалтерских и т. п.
> и документооборот и wiki работают с неструктурированном информации
Первое --- неправда.
> Если архитектура монолитная - то никакие "протоколы прикладного уровня"
> - не помогут.
Ты поставил условие расширяемости, поэтому архитектура явно не монолитная, не так ли?
> те же чисто событийные системы тяжело переносятся на распределенную архитектуру,
> т.к. требуют сверхнадежной и мгновенной передачи сообщений.
Не вижу, из чего проистекают последние требования.
Думаю, первое неправда.
---
...Я работаю антинаучным аферистом...
> что ты под этим понимаешь?
Наличие внешних законодательных норм, вроде бухгалтерских и т. п.
> и документооборот и wiki работают с неструктурированном информации
Первое --- неправда.
> Если архитектура монолитная - то никакие "протоколы прикладного уровня"
> - не помогут.
Ты поставил условие расширяемости, поэтому архитектура явно не монолитная, не так ли?
> те же чисто событийные системы тяжело переносятся на распределенную архитектуру,
> т.к. требуют сверхнадежной и мгновенной передачи сообщений.
Не вижу, из чего проистекают последние требования.
Думаю, первое неправда.
---
...Я работаю антинаучным аферистом...
> Неужели ты беллетристики, которую публикуют на всяких citforum.ru или olap.ru не читал? Не верю. Зайди на olap.ru, там много про КИС и хранилища данных понаписано.
это все клево - только опять же они не дают ответа - как разрабатывать и внедрять большие системы за месяц.
> Сущность - вещь неоднозначная. Например, сущность может быть короткоживущей, которую один раз создали, ещё один раз - обработали, а бывают такие, которые живут годами, и ведутся годами. Пользователь - ещё менее однозначная сущность, важнее не сколько штук пользователей, а насколько они в правах отличаются.
это было оценка видов сущностей.
самих сущностей - еще на порядки и порядки больше.
кол-во пользователей - я просто привел - чтобы показать, насколько большие задачи могут стоять перед такими системами.
> Это один из основных IT рынков, на котором живут большие и страшные монстры вроде Oracle и SAP
ну и пусть себе живут.
раз даже таким монстрам денег хватает, значит нам тем более на этом рынке денег хватит.
это все клево - только опять же они не дают ответа - как разрабатывать и внедрять большие системы за месяц.
> Сущность - вещь неоднозначная. Например, сущность может быть короткоживущей, которую один раз создали, ещё один раз - обработали, а бывают такие, которые живут годами, и ведутся годами. Пользователь - ещё менее однозначная сущность, важнее не сколько штук пользователей, а насколько они в правах отличаются.
это было оценка видов сущностей.
самих сущностей - еще на порядки и порядки больше.
кол-во пользователей - я просто привел - чтобы показать, насколько большие задачи могут стоять перед такими системами.
> Это один из основных IT рынков, на котором живут большие и страшные монстры вроде Oracle и SAP
ну и пусть себе живут.
раз даже таким монстрам денег хватает, значит нам тем более на этом рынке денег хватит.
На базе той же Oracle 9i/10g сейчас создано очень много бизнес-систем, это очень развитая платформа, с большими возможностями.ты про что это? какая платформа? или ты имеешь ввиду какую то конкретную линейку продуктов?
> Наличие внешних законодательных норм, вроде бухгалтерских и т. п.
взаимодействие с ними есть
что-то более - пока сложно сказать.
> Первое --- неправда.
назову тогда их - слабоструктурированные системы.
потому что они работают лишь с очень маленькой толикой той информации, которая действительно содержится в документах.
> Ты поставил условие расширяемости, поэтому архитектура явно не монолитная, не так ли?
этого хочеться, но нет никаких гарантий, что это получится, особенно если учесть, что монолитную архитектуру проще разрабатывать.
> Не вижу, из чего проистекают последние требования.
> Думаю, первое неправда.
под событием понимается, в данном случае, узкий смысл: событие - это то, что формируется при изменении какого-либо значения.
чисто событийная - это система, которое пересчитывает свое состояние на основе таких оповещений о изменениях.
например, если взять вышеприведенный пример о текстовом редакторе - то пересчет размера вертикального скролбара выглядит так:
соответственно, если событие теряется - то мы получаем систему в некорректном состоянии.
взаимодействие с ними есть
что-то более - пока сложно сказать.
> Первое --- неправда.
назову тогда их - слабоструктурированные системы.
потому что они работают лишь с очень маленькой толикой той информации, которая действительно содержится в документах.
> Ты поставил условие расширяемости, поэтому архитектура явно не монолитная, не так ли?
этого хочеться, но нет никаких гарантий, что это получится, особенно если учесть, что монолитную архитектуру проще разрабатывать.
> Не вижу, из чего проистекают последние требования.
> Думаю, первое неправда.
под событием понимается, в данном случае, узкий смысл: событие - это то, что формируется при изменении какого-либо значения.
чисто событийная - это система, которое пересчитывает свое состояние на основе таких оповещений о изменениях.
например, если взять вышеприведенный пример о текстовом редакторе - то пересчет размера вертикального скролбара выглядит так:
int count = 0;
OnDeleteLine
{
--count;
}
OnAddLine
{
++count;
}
OnChangeLine
{
//ничего не делаем
}
соответственно, если событие теряется - то мы получаем систему в некорректном состоянии.
>> Наличие внешних законодательных норм, вроде бухгалтерских и т. п.
> взаимодействие с ними есть
Если они есть, то почти наверняка плясать придётся от них.
> назову тогда их - слабоструктурированные системы.
> потому что они работают лишь с очень маленькой толикой той информации, > которая действительно содержится в документах.
Думаю, это просто современное состояние области.
> этого хочеться, но нет никаких гарантий, что это получится,
> особенно если учесть, что монолитную архитектуру проще разрабатывать.
Я бы не сказал.
Возможно, в твоей парадигме программирования так и есть,
но вообще говоря это неправда.
>> Не вижу, из чего проистекают последние требования.
>> Думаю, первое неправда.
> под событием понимается, в данном случае, узкий смысл:
> событие - это то, что формируется при изменении какого-либо значения.
> чисто событийная - это система, которое пересчитывает свое состояние
> на основе таких оповещений о изменениях.
...
> соответственно, если событие теряется - то мы получаем систему
> в некорректном состоянии.
Ты точно не упустил возможность транзакций или хотя бы простого подтверждения?
Реального времени, конечно, в распределённых системах ты не достигнешь,
но события обрабатывать можно.
Собственно, так оно и происходит.
---
...Я работаю антинаучным аферистом...
> взаимодействие с ними есть
Если они есть, то почти наверняка плясать придётся от них.
> назову тогда их - слабоструктурированные системы.
> потому что они работают лишь с очень маленькой толикой той информации, > которая действительно содержится в документах.
Думаю, это просто современное состояние области.
> этого хочеться, но нет никаких гарантий, что это получится,
> особенно если учесть, что монолитную архитектуру проще разрабатывать.
Я бы не сказал.
Возможно, в твоей парадигме программирования так и есть,
но вообще говоря это неправда.
>> Не вижу, из чего проистекают последние требования.
>> Думаю, первое неправда.
> под событием понимается, в данном случае, узкий смысл:
> событие - это то, что формируется при изменении какого-либо значения.
> чисто событийная - это система, которое пересчитывает свое состояние
> на основе таких оповещений о изменениях.
...
> соответственно, если событие теряется - то мы получаем систему
> в некорректном состоянии.
Ты точно не упустил возможность транзакций или хотя бы простого подтверждения?
Реального времени, конечно, в распределённых системах ты не достигнешь,
но события обрабатывать можно.
Собственно, так оно и происходит.
---
...Я работаю антинаучным аферистом...
> Если они есть, то почти наверняка плясать придётся от них.
принимать во внимание - да, но не больше.
т.к. я часто вижу - что сейчас эти нормы, наоборот, пытаются подтесать под то, что получилось.
> Ты точно не упустил возможность транзакций или хотя бы простого подтверждения?
транзакция + подтверждения - это и есть надежная передача данных
> но события обрабатывать можно.
обрабатывать можно - но чисто событийно-ориентированная архитектура будет плохо работать при распределенном использовании.
ps
в этом мире - можно делать очень многое - только это никак не говорит о том, нужно или не нужно это делать.
принимать во внимание - да, но не больше.
т.к. я часто вижу - что сейчас эти нормы, наоборот, пытаются подтесать под то, что получилось.
> Ты точно не упустил возможность транзакций или хотя бы простого подтверждения?
транзакция + подтверждения - это и есть надежная передача данных
> но события обрабатывать можно.
обрабатывать можно - но чисто событийно-ориентированная архитектура будет плохо работать при распределенном использовании.
ps
в этом мире - можно делать очень многое - только это никак не говорит о том, нужно или не нужно это делать.
моя основная цель - это уметь разрабатывать в очень сжатые сроки - целые семейства систем.
соответственно этой цели можно добиться - только если системы собирать из готовых кирпичиков.
> Как я понимаю, у есть цель зарабатывать не просто много, а очень много. А такая цель может быть достигнута только если успешно делать то, что другие сделать не могутты говоришь не о заказных системах? ты же писал, что
все правильно - и цель, и вывод.
на заказ - это малоприбыльный узкий рынок.
т.к. редкий клиент - готов в одиночку нести все тяготы и риски одинночной разработки.
> ты говоришь не о заказных системах? ты же писал, что
У термина "заказная система" есть два чуть разных толкования:
заказная система - эта система, которая полностью оплачивается одним потребителем (очень малым кол-вом потребителей).
заказная система - это система, которая во время установки или перед поставкой конкретному потребителю - требует значительной настройки под конкретные запросы данного потребителя.
и именно первое толкования я имел ввиду, когда говорил - что ориентация на рынок заказов - тупиковый путь.
У термина "заказная система" есть два чуть разных толкования:
заказная система - эта система, которая полностью оплачивается одним потребителем (очень малым кол-вом потребителей).
заказная система - это система, которая во время установки или перед поставкой конкретному потребителю - требует значительной настройки под конкретные запросы данного потребителя.
и именно первое толкования я имел ввиду, когда говорил - что ориентация на рынок заказов - тупиковый путь.
Это - две степени одного и того же.
Различие - количественное, а не качественное.
Различие - количественное, а не качественное.
т.е. твою систему можно будет поставить в ряд с уже существующими системами 1С, Axapta, Oracle Application, R3 и т.п.?
настройки под конкретные запросы данного потребителя
При выборе неизвестной системы заказчик рискует не меньше, чем при заказе системы с нуля. Как ты представляешь выход твоей системы на рынок?
> т.е. твою систему можно будет поставить в ряд с уже существующими системами 1С, Axapta, Oracle Application, R3 и т.п.?
в идеале - наверное, да
для начала мне достаточно - в разы меньший масштаб, например, на уровне задач решаемых office-ом (access, excel, fox pro).
> При выборе неизвестной системы заказчик рискует не меньше, чем при заказе системы с нуля. Как ты представляешь выход твоей системы на рынок?
созданием на системе - линейки продуктов - которые решают конкретные потребности конкретных групп пользователей.
в идеале - наверное, да
для начала мне достаточно - в разы меньший масштаб, например, на уровне задач решаемых office-ом (access, excel, fox pro).
> При выборе неизвестной системы заказчик рискует не меньше, чем при заказе системы с нуля. Как ты представляешь выход твоей системы на рынок?
созданием на системе - линейки продуктов - которые решают конкретные потребности конкретных групп пользователей.
> Это - две степени одного и того же.
да
> Различие - количественное, а не качественное
нет, различие именно качественное - в одном случае возможно взрывное развитие (прибыль уровня 200-500% в другом - нет.
ps
это вообще две ортогональные друг другу оси - поэтому я, вообще, не понимаю - как можно говорить, что они отличаются количественно.
да
> Различие - количественное, а не качественное
нет, различие именно качественное - в одном случае возможно взрывное развитие (прибыль уровня 200-500% в другом - нет.
ps
это вообще две ортогональные друг другу оси - поэтому я, вообще, не понимаю - как можно говорить, что они отличаются количественно.
т.е. ты хочешь начать с продукта "продвинутый office"? Ты думаешь, Microsoft не пыталась пойти по этому пути?
на уровне задач решаемых office-ом (access, excel, fox pro).
Однако, сейчас видно, что Microsoft идет по пути упрощения и объединения средств разработки, в том числе, С#, SQL Server. (Да, Microsoft это делает не слишком быстро, но поторопить ее не кому, ближайший конкурент Java community слишком раздробленна. Возможно, Microsoft замедляет процесс намерено.)
> т.е. ты хочешь начать с продукта "продвинутый office"?
скорее с продвинутого решения - повседневных задач.
> Ты думаешь, Microsoft не пыталась пойти по этому пути?
как-то пыталась, но это не их направление, соответственно едва ли они это делали хорошо.
> Однако, сейчас видно, что Microsoft идет по пути упрощения и объединения средств разработки, в том числе, С#, SQL Server
и что?
скорее с продвинутого решения - повседневных задач.
> Ты думаешь, Microsoft не пыталась пойти по этому пути?
как-то пыталась, но это не их направление, соответственно едва ли они это делали хорошо.
> Однако, сейчас видно, что Microsoft идет по пути упрощения и объединения средств разработки, в том числе, С#, SQL Server
и что?
как это не их?
как-то пыталась, но это не их направление, соответственно едва ли они это делали хорошо.
Office это их основной продукт, который приносит основную часть денегосновное направление office-а - это работа с документами (с большими массивами малоструктурированной информации и только потом со структурированной информацией.
меня интересует, в первую очередь, хороший инструмент для работы с сильно структурированной информацией
меня интересует, в первую очередь, хороший инструмент для работы с сильно структурированной информацией
> основное направление office-а - это работа с документами
вернее - основное направление - это редактирование документов.
вернее - основное направление - это редактирование документов.
Я всё же не понимаю, чего ты хочешь...
> основное направление office-а - это работа с документами
> вернее - основное направление - это редактирование документов.
Это смотря каких компонент офиса - если просто word или pawer point - то может быть, а если смотреть на excel или access - то уже нет.
Но я о другом - любой сложной инструмент требует настройки, и чем сложнее инструмент, тем более сложной настройки он будет требовать, и тем больше эта настройка будет напоминать программирование, и в конечном итоге, появляется среда под какой-то класс задач, в которой есть какая-то мощная и сложная система программирования. Поэтому в принципе рациональнее, и подобный процесс налицо (про что здесь уже говорили, впрочем) - не создавать сложную систему и язык для её настройки, а создавать просто набор компонент и интерфейсов со средой программирования, с помощью которой уже и создавать быстро, насколько это возможно, конечный продукт.
Что ты предлагаешь не из того, что либо уже предлагают фирмы типа Misrosoft/Oracle/SAP, в крайнем случае 1С, либо над чем они интенсивно работают? В чём новизна твоих идей? Давно уже есть законченные решения для автоматизации каких-то типовых бизнес-отраслей, и эти решения уже давно строят на базе тех же Oracle, /R3, и др.
> основное направление office-а - это работа с документами
> вернее - основное направление - это редактирование документов.
Это смотря каких компонент офиса - если просто word или pawer point - то может быть, а если смотреть на excel или access - то уже нет.
Но я о другом - любой сложной инструмент требует настройки, и чем сложнее инструмент, тем более сложной настройки он будет требовать, и тем больше эта настройка будет напоминать программирование, и в конечном итоге, появляется среда под какой-то класс задач, в которой есть какая-то мощная и сложная система программирования. Поэтому в принципе рациональнее, и подобный процесс налицо (про что здесь уже говорили, впрочем) - не создавать сложную систему и язык для её настройки, а создавать просто набор компонент и интерфейсов со средой программирования, с помощью которой уже и создавать быстро, насколько это возможно, конечный продукт.
Что ты предлагаешь не из того, что либо уже предлагают фирмы типа Misrosoft/Oracle/SAP, в крайнем случае 1С, либо над чем они интенсивно работают? В чём новизна твоих идей? Давно уже есть законченные решения для автоматизации каких-то типовых бизнес-отраслей, и эти решения уже давно строят на базе тех же Oracle, /R3, и др.
> Я всё же не понимаю, чего ты хочешь...
если вкратце - создать инструмент для конструирования информационных систем.
> Но я о другом - любой сложной инструмент требует настройки, и чем сложнее инструмент, тем более сложной настройки он будет требовать,
на мой взгляд - с этой настройкой - может отлично справиться компьютер.
> создавать просто набор компонент и интерфейсов со средой программирования, с помощью которой уже и создавать быстро, насколько это возможно, конечный продукт.
> Давно уже есть законченные решения для автоматизации каких-то типовых бизнес-отраслей, и эти решения уже давно строят на базе тех же Oracle, /R3, и др.
в том-то и дело, что на данный момент - есть куча и куча готовых кирпичиков.
но нет ни одного инструмента, который бы облегчал сам процесс сбора системы из отдельных блоков.
вот такой инструмент я и хочу сделать.
если вкратце - создать инструмент для конструирования информационных систем.
> Но я о другом - любой сложной инструмент требует настройки, и чем сложнее инструмент, тем более сложной настройки он будет требовать,
на мой взгляд - с этой настройкой - может отлично справиться компьютер.
> создавать просто набор компонент и интерфейсов со средой программирования, с помощью которой уже и создавать быстро, насколько это возможно, конечный продукт.
> Давно уже есть законченные решения для автоматизации каких-то типовых бизнес-отраслей, и эти решения уже давно строят на базе тех же Oracle, /R3, и др.
в том-то и дело, что на данный момент - есть куча и куча готовых кирпичиков.
но нет ни одного инструмента, который бы облегчал сам процесс сбора системы из отдельных блоков.
вот такой инструмент я и хочу сделать.
> но нет ни одного инструмента,
Возлюби make.
И grep.
---
"...Потому что Аллах не ведёт людей неверных."
Возлюби make.
И grep.
---
"...Потому что Аллах не ведёт людей неверных."
Не выхватывай словосочетания из контекста.
Не у всех они несут столько смысла, как у тебя.
Не у всех они несут столько смысла, как у тебя.
Если это кирпичи, а не просто камни, то можно было бы давно сделать библиотеку.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
> Если это кирпичи, а не просто камни, то можно было бы давно сделать библиотеку
и какой смысл этого?
библиотека - это лишь набор кирпичей, которые часто используются при решение задач из определенной области, не больше.
и какой смысл этого?
библиотека - это лишь набор кирпичей, которые часто используются при решение задач из определенной области, не больше.
У тебя она уже есть, эта библиотека?
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
> У тебя она уже есть, эта библиотека?
эта - это какая?
вообще, библиотек у меня много и разных.
эта - это какая?
вообще, библиотек у меня много и разных.
Которая "набор кирпичей."
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
>> Я всё же не понимаю, чего ты хочешь...
> если вкратце - создать инструмент для конструирования информационных систем.
Так оно уже есть... Разве набор компонент (модулей, библиотек) плюс текстовый редактор (IDE) не является подобным инструментом?
>> Но я о другом - любой сложной инструмент требует настройки, и чем сложнее инструмент,
>> тем более сложной настройки он будет требовать,
> на мой взгляд - с этой настройкой - может отлично справиться компьютер.
А с компиляцией программы тоже может справиться компьютер. Но это не значит, что компьютер пишет программы, так как ему сначала нужно дать исходный текст. В твоём примере - нужно сначала дать формальное описание того, под чего нужно настроить систему, ведь компьютер сам об этом никогда не узнает. Нужно описать как-то формально все бизнес-процессы, разобраться в требованиях, скорректировать их, предложить изменения в самом бизнесе, чтобы он мог нормально работать с новой КИС, и т.п. Подозреваю, что если разделить затраты на внедрение КИС между:
1) лицензионными отчислениями
2) трудом программистов по доводке системы
3) трудом консультантов, по описанию и корректировке бизнес-процессов, подготовке требований к фирме и программистам
то затраты на программистов - будут самыми маленькими...
Например, ты хочешь внедрить какую-нибудь КИС в какой-то торговой фирме. Тебе ведь для начала нужно понять, какого рода продукт им нужен, что и как нужно автоматизировать и т.п. Сколько времени на это требуется, по твоему? Ты думаешь, это реально за неделю сделать?
> если вкратце - создать инструмент для конструирования информационных систем.
Так оно уже есть... Разве набор компонент (модулей, библиотек) плюс текстовый редактор (IDE) не является подобным инструментом?
>> Но я о другом - любой сложной инструмент требует настройки, и чем сложнее инструмент,
>> тем более сложной настройки он будет требовать,
> на мой взгляд - с этой настройкой - может отлично справиться компьютер.
А с компиляцией программы тоже может справиться компьютер. Но это не значит, что компьютер пишет программы, так как ему сначала нужно дать исходный текст. В твоём примере - нужно сначала дать формальное описание того, под чего нужно настроить систему, ведь компьютер сам об этом никогда не узнает. Нужно описать как-то формально все бизнес-процессы, разобраться в требованиях, скорректировать их, предложить изменения в самом бизнесе, чтобы он мог нормально работать с новой КИС, и т.п. Подозреваю, что если разделить затраты на внедрение КИС между:
1) лицензионными отчислениями
2) трудом программистов по доводке системы
3) трудом консультантов, по описанию и корректировке бизнес-процессов, подготовке требований к фирме и программистам
то затраты на программистов - будут самыми маленькими...
Например, ты хочешь внедрить какую-нибудь КИС в какой-то торговой фирме. Тебе ведь для начала нужно понять, какого рода продукт им нужен, что и как нужно автоматизировать и т.п. Сколько времени на это требуется, по твоему? Ты думаешь, это реально за неделю сделать?
> Разве набор компонент (модулей, библиотек) плюс текстовый редактор (IDE) не является подобным инструментом?
является - но очень неэффективным.
> Подозреваю, что если разделить затраты на внедрение КИС между:
смотря какие затраты.
временные затраты , а также затраты на "глухой телефон" - в большей степени, как раз на этапе программирования/кодирования и отладки - и образуются.
> Ты думаешь, это реально за неделю сделать?
смотря, что уже у нас есть на руках.
Если уже мы, например, имеем десять/сто/тысячу описанных компании, и при этом имеем эффективный инструмент для подключения в эту систему еще одну, то недели может и хватить.
даже пусть это будет месяц - но это все-таки уже не года.
является - но очень неэффективным.
> Подозреваю, что если разделить затраты на внедрение КИС между:
смотря какие затраты.
временные затраты , а также затраты на "глухой телефон" - в большей степени, как раз на этапе программирования/кодирования и отладки - и образуются.
> Ты думаешь, это реально за неделю сделать?
смотря, что уже у нас есть на руках.
Если уже мы, например, имеем десять/сто/тысячу описанных компании, и при этом имеем эффективный инструмент для подключения в эту систему еще одну, то недели может и хватить.
даже пусть это будет месяц - но это все-таки уже не года.
> Сколько времени на это требуется, по твоему? Ты думаешь, это реально за неделю сделать?
для снятия общей схемы процессов - профессионалу может и часа хватить.
но вот на снятие и выстраивания деталей, из-за отсутствия эффективного инструмента - как раз и уходят месяцы, т.к., например, большинство мелких деталей сложно увидеть - пока под рукой нет работающего прототипа (который будет как раз где-нибудь через полгода в лучшем случае)
для снятия общей схемы процессов - профессионалу может и часа хватить.
но вот на снятие и выстраивания деталей, из-за отсутствия эффективного инструмента - как раз и уходят месяцы, т.к., например, большинство мелких деталей сложно увидеть - пока под рукой нет работающего прототипа (который будет как раз где-нибудь через полгода в лучшем случае)
> Так оно уже есть... Разве набор компонент (модулей, библиотек) плюс текстовый редактор (IDE) не является подобным инструментом?
стандартный пример:
ты автоматизировал головной офис, тебе говорят - все клево, нам понравилось, давайте еще автоматизируем наш филиал в республике Зимбабве.
ты отвечаешь - ok-ей, делов-то там, у тебя же уже все написано.
но как только ты начинаешь узнавать мелочи - у тебя начинают волосы вставать дыбом:
1. другой язык (пишут, например, снизу вверх, справа налево)
2. другая валюта (у них какие-нибудь свои рубли, полурубли и копейки, причем полурублей в рубле - 37 штук, а копеек - в полурубле 23)
3. другие правила бизнес округления
4. другие единицы измерения
5. свои нормы ведения документов
и т.д.
внимание, вопрос - как ты с помощью текстового редактора сможешь ответить на вопрос:
какие модули необходимо изменить под эти требования, и на сколько глобальные/сложные будут изменения?
сколько времени тебе понадобиться, чтобы все-таки дать ответ на этот вопрос? как много мест ты пропустишь? будут ли кол-во найденных мест изменения сильно больше, чем 10% от мест, которые действительно требуют изменения?
стандартный пример:
ты автоматизировал головной офис, тебе говорят - все клево, нам понравилось, давайте еще автоматизируем наш филиал в республике Зимбабве.
ты отвечаешь - ok-ей, делов-то там, у тебя же уже все написано.
но как только ты начинаешь узнавать мелочи - у тебя начинают волосы вставать дыбом:
1. другой язык (пишут, например, снизу вверх, справа налево)
2. другая валюта (у них какие-нибудь свои рубли, полурубли и копейки, причем полурублей в рубле - 37 штук, а копеек - в полурубле 23)
3. другие правила бизнес округления
4. другие единицы измерения
5. свои нормы ведения документов
и т.д.
внимание, вопрос - как ты с помощью текстового редактора сможешь ответить на вопрос:
какие модули необходимо изменить под эти требования, и на сколько глобальные/сложные будут изменения?
сколько времени тебе понадобиться, чтобы все-таки дать ответ на этот вопрос? как много мест ты пропустишь? будут ли кол-во найденных мест изменения сильно больше, чем 10% от мест, которые действительно требуют изменения?
>> Так оно уже есть... Разве набор компонент (модулей, библиотек) плюс текстовый редактор (IDE)
>> не является подобным инструментом?
> стандартный пример:
> ты автоматизировал головной офис, тебе говорят - все клево, нам понравилось, давайте еще автоматизируем
> наш филиал в республике Зимбабве.
> ты отвечаешь - ok-ей, делов-то там, у тебя же уже все написано.
Это к чему пример? К тому, что проблем с автоматизацией очень и очень много, и в общем случае задача не решаема, и что универсальных решений не существует? Так я примерно про это и говорю, сейчас ты, получается, пытаешься опровергруть самого себя.
> но как только ты начинаешь узнавать мелочи - у тебя начинают волосы вставать дыбом:
> 1. другой язык (пишут, например, снизу вверх, справа налево)
> 2. другая валюта (у них какие-нибудь свои рубли, полурубли и копейки, причем полурублей в рубле - 37 штук, а копеек - в полурубле 23)
> 3. другие правила бизнес округления
> 4. другие единицы измерения
> 5. свои нормы ведения документов
> и т.д.
Вот-вот. Значит, или все эти параметры должны предусматриваться в качестве параметров настройки программы (то есть ты ещё на момент написания системы должен предусмотреть, что что-то может отличаться, и предусмотреть возможность соответствующих настроек либо у тебя должна быть возможность перепрограммировать какие-либо куски. Предусмотреть возможность всех настроек - нереально, потому как всегда можно столкнуться с ситуацией, когда ты про что-то вообще не представлял, что такое вообще возможно... Поэтому нормальный вариант - иметь какую-то систему, состоящую из универсальных компонент, а логика - уже программируема в том самом текстовом редакторе. И если ты видишь, что логика работы филиала - очень сильно отличается, то по сути, тебе придётся писать новую систему, возможно используя свои старые наработки в той мере, насколько это возможно.
Повторяю - либо тебе необходимо предусмотреть возможность любых настроек, что нереально (а не предусмотришь - и окажется, что система принципиально непригодна для решения задачи из-за какой-то мелочи либо тебе нужно именно программировать систему, отталкиваясь, например, от уже готовых разработанных решений. Как ты видишь настолько универсальное описание системы, чтобы оно всё охватывало, чтобы с ним мог работать компьютер, и чтобы человек смог составить такое описание быстро? В любом случае, или тебе придётся брать какие-либо настройки по умолчанию, и модифицировать их, либо каждый раз с нуля описывать огромное количество параметров системы.
Опиши, как ты видишь со стороны перенастройку системы в описанной тобою ситуации.
>> не является подобным инструментом?
> стандартный пример:
> ты автоматизировал головной офис, тебе говорят - все клево, нам понравилось, давайте еще автоматизируем
> наш филиал в республике Зимбабве.
> ты отвечаешь - ok-ей, делов-то там, у тебя же уже все написано.
Это к чему пример? К тому, что проблем с автоматизацией очень и очень много, и в общем случае задача не решаема, и что универсальных решений не существует? Так я примерно про это и говорю, сейчас ты, получается, пытаешься опровергруть самого себя.
> но как только ты начинаешь узнавать мелочи - у тебя начинают волосы вставать дыбом:
> 1. другой язык (пишут, например, снизу вверх, справа налево)
> 2. другая валюта (у них какие-нибудь свои рубли, полурубли и копейки, причем полурублей в рубле - 37 штук, а копеек - в полурубле 23)
> 3. другие правила бизнес округления
> 4. другие единицы измерения
> 5. свои нормы ведения документов
> и т.д.
Вот-вот. Значит, или все эти параметры должны предусматриваться в качестве параметров настройки программы (то есть ты ещё на момент написания системы должен предусмотреть, что что-то может отличаться, и предусмотреть возможность соответствующих настроек либо у тебя должна быть возможность перепрограммировать какие-либо куски. Предусмотреть возможность всех настроек - нереально, потому как всегда можно столкнуться с ситуацией, когда ты про что-то вообще не представлял, что такое вообще возможно... Поэтому нормальный вариант - иметь какую-то систему, состоящую из универсальных компонент, а логика - уже программируема в том самом текстовом редакторе. И если ты видишь, что логика работы филиала - очень сильно отличается, то по сути, тебе придётся писать новую систему, возможно используя свои старые наработки в той мере, насколько это возможно.
Повторяю - либо тебе необходимо предусмотреть возможность любых настроек, что нереально (а не предусмотришь - и окажется, что система принципиально непригодна для решения задачи из-за какой-то мелочи либо тебе нужно именно программировать систему, отталкиваясь, например, от уже готовых разработанных решений. Как ты видишь настолько универсальное описание системы, чтобы оно всё охватывало, чтобы с ним мог работать компьютер, и чтобы человек смог составить такое описание быстро? В любом случае, или тебе придётся брать какие-либо настройки по умолчанию, и модифицировать их, либо каждый раз с нуля описывать огромное количество параметров системы.
Опиши, как ты видишь со стороны перенастройку системы в описанной тобою ситуации.
> Опиши, как ты видишь со стороны перенастройку системы в описанной тобою ситуации.
если программа представляет собой модель, а не кусок текста в текстовом редакторе, то все достаточно просто, т.к. модель в отличии от куска текста - умеет отвечать на вопросы, в том числе и на те, которые я привел в предыдущем сообщении.
> Это к чему пример?
к тому - что так называемое сегодняшнее программирование - это большую часть времени - толчея воды в ступе.
если программа представляет собой модель, а не кусок текста в текстовом редакторе, то все достаточно просто, т.к. модель в отличии от куска текста - умеет отвечать на вопросы, в том числе и на те, которые я привел в предыдущем сообщении.
> Это к чему пример?
к тому - что так называемое сегодняшнее программирование - это большую часть времени - толчея воды в ступе.
> Вот-вот. Значит,
Программировать надо уметь.
Средства i18n уже придумали, вообще-то.
---
...Я работаю антинаучным аферистом...
Программировать надо уметь.
Средства i18n уже придумали, вообще-то.
---
...Я работаю антинаучным аферистом...
>> Опиши, как ты видишь со стороны перенастройку системы в описанной тобою ситуации.
> если программа представляет собой модель, а не кусок текста в текстовом редакторе, то все достаточно просто,
> т.к. модель в отличии от куска текста - умеет отвечать на вопросы, в том числе и на те, которые я привел в
> предыдущем сообщении.
Модель - слишком абстрактное поняние... Что такое модель, и как её описать? Вспоминая историю - уже создавался "универсальный модельный язык" (или как там его - uml, короче) с кучей диаграмм, чтобы точнее эти модели описывать, вроде даже какие-то решения, чтобы на основе этих диаграмм генерировать всякие обвязки классов и части кода существовали/существуют. Но... Не знаю, насколько полезны они, однако это заведомо не панацея от бед и трудностей, и эйфория по этому поводу уже давно угасла... Та же толчия воды, со своей кучей не меньших проблем.
> если программа представляет собой модель, а не кусок текста в текстовом редакторе, то все достаточно просто,
> т.к. модель в отличии от куска текста - умеет отвечать на вопросы, в том числе и на те, которые я привел в
> предыдущем сообщении.
Модель - слишком абстрактное поняние... Что такое модель, и как её описать? Вспоминая историю - уже создавался "универсальный модельный язык" (или как там его - uml, короче) с кучей диаграмм, чтобы точнее эти модели описывать, вроде даже какие-то решения, чтобы на основе этих диаграмм генерировать всякие обвязки классов и части кода существовали/существуют. Но... Не знаю, насколько полезны они, однако это заведомо не панацея от бед и трудностей, и эйфория по этому поводу уже давно угасла... Та же толчия воды, со своей кучей не меньших проблем.
> Средства i18n уже придумали, вообще-то.
И как i18n мне поможет в том, что в одном проекте все транзакции требуют точность 3 знака после запятой, а в другом проекте - два?
И как i18n мне поможет в том, что в одном проекте все транзакции требуют точность 3 знака после запятой, а в другом проекте - два?
uml - это язык описания (в лучшем случае а не моделирования.
высокоуровневых языков для моделирования - я не встречал.
высокоуровневых языков для моделирования - я не встречал.
А типичные такие средства помогут в случае, когда нужно, как в арабском языке, справа на лево писать? Соответственно формуруя абзацы?
А вообще, речь шла, в первую очередь, про документооборот, а если в правилах одной страны документ нужно предъявить кому-то, перед тем как делать в нём изменения, а в другой - наоборот, после предъявления никому менять нельзя, то здесь уже свои принципиально иные механизмы локализации нужны. Проблема ведь не только и не сколько в языке, а в несколько иной логике...
А вообще, речь шла, в первую очередь, про документооборот, а если в правилах одной страны документ нужно предъявить кому-то, перед тем как делать в нём изменения, а в другой - наоборот, после предъявления никому менять нельзя, то здесь уже свои принципиально иные механизмы локализации нужны. Проблема ведь не только и не сколько в языке, а в несколько иной логике...
Ну так значит с этого стоит начать 
Создать удобный язык для описания бизнес-процессов, а не строить разделение сущностей на редакторы, вьюверы и ИИ. Ведь проблема главная - в отсутствии подобного языка, а не в том, что никто не придумал, на какие составные части нужно разбивать программы (последнее как раз давно придумали и используют)?
Создать удобный язык для описания бизнес-процессов, а не строить разделение сущностей на редакторы, вьюверы и ИИ. Ведь проблема главная - в отсутствии подобного языка, а не в том, что никто не придумал, на какие составные части нужно разбивать программы (последнее как раз давно придумали и используют)?Это решается средствами типизации.
Например.
---
...Я работаю антинаучным аферистом...
Например.
---
...Я работаю антинаучным аферистом...
> Ну так значит с этого стоит начать Создать удобный язык для описания бизнес-процессов, а не строить разделение сущностей на редакторы, вьюверы и ИИ.
так высокоуровневый язык - это и есть вот набор таких сущностей, которые я привел в первом посте.
так высокоуровневый язык - это и есть вот набор таких сущностей, которые я привел в первом посте.
Это не язык. Это, в лучшем случае и с большой натяжкой - классификация компонент. Я не очень представляю, как можно от классификации перейти к языку (описанию) моделей... При том, что, повторюсь, сама классификация более, чем сомнительна. Как формализовать следующий упрощённый бизнес-процесс:
клиент приходит в фирму,
секретать составляет предварительный договор,
далее этот договор корректируется руководством и клиентом,
потом он закрывается (запрещаются изменения
далее идёт исполнение (ведение) договора, состоящее из нескольких шагов.
Банальная схема... Как подобные схемы описывать, чтобы потом быстро лепить из них что-то, особенно если нужно предусматривать возможность изменения подобных схем, когда одни договоры становятся завязанными на другие, ну и т.д.?
клиент приходит в фирму,
секретать составляет предварительный договор,
далее этот договор корректируется руководством и клиентом,
потом он закрывается (запрещаются изменения
далее идёт исполнение (ведение) договора, состоящее из нескольких шагов.
Банальная схема... Как подобные схемы описывать, чтобы потом быстро лепить из них что-то, особенно если нужно предусматривать возможность изменения подобных схем, когда одни договоры становятся завязанными на другие, ну и т.д.?
Для начала - тебе это надо описать (хотя бы в статике тебе надо уметь опять же, чтобы все эти клиенты, секретари и руководство - могли это просматривать и редактировать.
т.е. тебе надо описать - что есть договор, что он состоит из каких-то полей, что договор может находиться в разных состояниях, что в ряде состояний - его можно только просматривать и т.д.
также еще надо описать - что есть пользователи, есть их роли, есть шаги выполнения и т.д.
надо просматривать договора по одному, скопом, по определенной маске и т.д.
надо редактировать - опять же - по одному, группой и т.д.
т.е. тебе надо описать - что есть договор, что он состоит из каких-то полей, что договор может находиться в разных состояниях, что в ряде состояний - его можно только просматривать и т.д.
также еще надо описать - что есть пользователи, есть их роли, есть шаги выполнения и т.д.
надо просматривать договора по одному, скопом, по определенной маске и т.д.
надо редактировать - опять же - по одному, группой и т.д.
Для начала - тебе это надо описать (хотя бы в статике тебе надо уметь опять же, чтобы все эти клиенты, секретари и руководство - могли это просматривать и редактировать.Нет, я всё же не понимаю, о чём мы говорим...
т.е. тебе надо описать - что есть договор, что он состоит из каких-то полей, что договор может находиться в разных состояниях, что в ряде состояний - его можно только просматривать и т.д.
также еще надо описать - что есть пользователи, есть их роли, есть шаги выполнения и т.д.
надо просматривать договора по одному, скопом, по определенной маске и т.д.
надо редактировать - опять же - по одному, группой и т.д.
Да, действительно всё это нужно описывать - я вот о том и говорю, что всегда нужно слишком много описывать, из-за чего не получится создать средство, которое будет быстро и самостоятельно всё конфигурировать...
> Да, действительно всё это нужно описывать - я вот о том и говорю, что всегда нужно слишком много описывать, из-за чего не получится создать средство, которое будет быстро и самостоятельно всё конфигурировать...
Вывод - не понятен.
почему в данном случае - ты считаешь, что после того, как мы описали - что у нас есть договор и т.д. - мы автоматом не получим работающую систему, которая будет позволять просматривать, редактировать договора и т.д.?
Вывод - не понятен.
почему в данном случае - ты считаешь, что после того, как мы описали - что у нас есть договор и т.д. - мы автоматом не получим работающую систему, которая будет позволять просматривать, редактировать договора и т.д.?
почему в данном случае - ты считаешь, что после того, как мы описали - что у нас есть договор и т.д. - мы автоматом не получим работающую систему, которая будет позволять просматривать, редактировать договора и т.д.?А чем будет отличаться "[формально] описали" от "запрограммировали"? В том то и дело, что по сути у тебя - есть уже реализованный объект, с которым можно делать какие-то вещи, однако самое интересное начинается тогда, когда вещи ты с ним захочешь делать нестрандартные.
> А чем будет отличаться "[формально] описали" от "запрограммировали"?
> самое интересное начинается тогда, когда вещи ты с ним захочешь делать нестрандартные
тем, что как раз описание позволяет делать нестандартные вещи, в отличии, от запрограммирования.
одно дело ты описал, что у тебя есть понятие "договор" с полем "название", другое дело - ты это запрограммировал:
В первом случае, ты можешь это описание использовать и для формирования sql/xml - хранилища, можешь для формирования классов, можешь для формирования отображения/редактирования и т.д.
во втором только - для работы с этим договоров из кода
> самое интересное начинается тогда, когда вещи ты с ним захочешь делать нестрандартные
тем, что как раз описание позволяет делать нестандартные вещи, в отличии, от запрограммирования.
одно дело ты описал, что у тебя есть понятие "договор" с полем "название", другое дело - ты это запрограммировал:
public class Dogovor
{
public string Name;
}
В первом случае, ты можешь это описание использовать и для формирования sql/xml - хранилища, можешь для формирования классов, можешь для формирования отображения/редактирования и т.д.
во втором только - для работы с этим договоров из кода
Код на языке программирования является всего лишь
более конкретным выражением твоего описания.
---
"Мы диалектику учили не по Гегелю."
более конкретным выражением твоего описания.
---
"Мы диалектику учили не по Гегелю."
после того, как мы описали - что у нас есть договор и т.д. - мы автоматом не получим работающую систему, которая будет позволять просматривать, редактировать договора и т.д.?А ты насколько хорошо знаешь всякие 1C и подобное? Я вот совсем не знаю но у меня почему-то была уверенность, что там именно так дело и обстоит, нет?
> Код на языке программирования является всего лишь более конкретным выражением твоего описания.
Скорее более низкоуровневым, чем более конкретным.
При конкретизации - общий контекст, обычно, не теряется, при спуске на более нижнии уровни- общий контекст теряется.
Скорее более низкоуровневым, чем более конкретным.
При конкретизации - общий контекст, обычно, не теряется, при спуске на более нижнии уровни- общий контекст теряется.
понятие "договор"
с полем "название"
public class Dogovor
{
public string Name;
}
---
"Мы диалектику учили не по Гегелю."
> А ты насколько хорошо знаешь всякие 1C и подобное?
общее впечатление - есть.
> Я вот совсем не знаю но у меня почему-то была уверенность, что там именно так дело и обстоит, нет?
как-то с этим и в .net-е/с#-обстоит, т.к., например, имея описание в виде класса, пользуясь им как метаописанием - мы можем его хранить в xml-е, в базе, показывать и редактировать одиночный экземпляр (property grid показывать/редактировать множество экземпляров (data grid).
но этим пользоваться не удобно - т.к. для этого нет инструментов облегчающее массовое применение.
общее впечатление - есть.
> Я вот совсем не знаю но у меня почему-то была уверенность, что там именно так дело и обстоит, нет?
как-то с этим и в .net-е/с#-обстоит, т.к., например, имея описание в виде класса, пользуясь им как метаописанием - мы можем его хранить в xml-е, в базе, показывать и редактировать одиночный экземпляр (property grid показывать/редактировать множество экземпляров (data grid).
но этим пользоваться не удобно - т.к. для этого нет инструментов облегчающее массовое применение.
В Axapta-е ты определяешь "табличку", в коде ты можешь обращаться к ней почти как к классу, а также составлять SQL-запросы (встроенный язык поддерживает SQL-синтаксис). В гриде тоже не проблема отобразить, указав табличку, как источник данных.
В первом случае, ты можешь это описание использовать и для формирования sql/xml - хранилища, можешь для формирования классов, можешь для формирования отображения/редактирования и т.д.
P.S. с Axapta-ой не особо знаком, могу ошибаться
как минимум - в описание, мы знали - что поле у нас именно Название, а не просто строка.
описание мы можем уточнить(отнаследовать) например так:
название у договора не одно, а несколько - одно официальное, другое внутренее, третье - международное и т.д.
в качестве названия (если нет уточнения) используется официальное название.
код мы уже так уточнить не сможем.
или описание - можем уточнить так:
название - это строка длины (больше нуля
или название - это строка уникодных символов фиксированной длины,
или название - это строка иероглифических символов произвольной длины
опять же код ты уже так уточнить не сможешь.
описание мы можем уточнить(отнаследовать) например так:
название у договора не одно, а несколько - одно официальное, другое внутренее, третье - международное и т.д.
в качестве названия (если нет уточнения) используется официальное название.
код мы уже так уточнить не сможем.
или описание - можем уточнить так:
название - это строка длины (больше нуля
или название - это строка уникодных символов фиксированной длины,
или название - это строка иероглифических символов произвольной длины
опять же код ты уже так уточнить не сможешь.
>как-то
т.е. этот тред об улучшенной версии инструмента разработки типа VS?
т.е. этот тред об улучшенной версии инструмента разработки типа VS?
> В гриде тоже не проблема отобразить, указав табличку, как источник данных
размеры колонок, порядок колонок, имена в header-е откуда берутся?
задаются в ручную?
мы можем один раз где-нибудь указать, что кол-во колес у машины - обычно 0-9, поэтому размер колонки для показа кол-ва колес можно делать в 1 символ?
если мы уже определили, как отображается наш класс, то можем мы это повторно использовать с какими-то дополнительными изменениями?
и т.д.
размеры колонок, порядок колонок, имена в header-е откуда берутся?
задаются в ручную?
мы можем один раз где-нибудь указать, что кол-во колес у машины - обычно 0-9, поэтому размер колонки для показа кол-ва колес можно делать в 1 символ?
если мы уже определили, как отображается наш класс, то можем мы это повторно использовать с какими-то дополнительными изменениями?
и т.д.
> т.е. этот тред об улучшенной версии инструмента разработки типа VS?
в какой-то степени - да.
в какой-то степени - да.
можно задать при определении "таблички"
размеры колонок, порядок колонок, имена в header-е откуда берутся?
задаются в ручную?
да, см. предыдущий ответ
мы можем один раз где-нибудь указать, что кол-во колес у машины - обычно 0-9, поэтому размер колонки можно делать в 1 символ?
если мы уже определили, как отображается наш класс, то можем мы это повторно использовать с какими-то дополнительными изменениями?по-моему да, но точно не могу сказать
> можно задать при определении "таблички"
а если мне нужно два отображения одной и той же таблички с разным кол-вом колонок?
одна, например, для пользователей, другая админская?
а если мне нужно два отображения одной и той же таблички с разным кол-вом колонок?
одна, например, для пользователей, другая админская?
всегда есть возможность настроить конкретный грид вручную, может еще какие механизмы есть , типа вьюшек,я не спец
> можно задать при определении "таблички"
а если мне нужно два отображения одной и той же таблички с разным кол-вом колонок?
одна, например, для пользователей, другая админская?
более сложный вопрос:
допустим мы хотим одну и ту же табличку показывать разнообразными способами:
в трех разных логических видах (например):
для внешних клиентов,
для сотрудников,
для админов
А также в виде трех различных физических видах:
desktop
web
кпк-десктоп.
какие средства у нас есть для упрощения задания всех этих девяти видов, кроме задания всех видов в ручную?
Что будет с уже созданными 9-ью видами, если мы добавим в табличку еще одну колонку?
нам опять вручную придется все 9 видов перередактировать?
допустим мы хотим одну и ту же табличку показывать разнообразными способами:
в трех разных логических видах (например):
для внешних клиентов,
для сотрудников,
для админов
А также в виде трех различных физических видах:
desktop
web
кпк-десктоп.
какие средства у нас есть для упрощения задания всех этих девяти видов, кроме задания всех видов в ручную?
Что будет с уже созданными 9-ью видами, если мы добавим в табличку еще одну колонку?
нам опять вручную придется все 9 видов перередактировать?
> всегда есть возможность настроить конкретный грид вручную, может еще какие механизмы есть , типа вьюшек,я не спец
т.е. даже нет возможности - половину отображения задавать автоматически, а другую вручную?
ps
все это и означает - что в существующих системах - все это реализовано - как-то, а не в удобном объеме.
т.е. даже нет возможности - половину отображения задавать автоматически, а другую вручную?
ps
все это и означает - что в существующих системах - все это реализовано - как-то, а не в удобном объеме.
>т.е. даже нет возможности - половину отображения задавать автоматически, а другую вручную?
по-умолчанию грид выглядит как указано в определении "таблички", если надо поменять ширину колонки, меняешь ширину одной колонки в гриде. Ты это называешь "половину отображения задавать автоматически"?
по-умолчанию грид выглядит как указано в определении "таблички", если надо поменять ширину колонки, меняешь ширину одной колонки в гриде. Ты это называешь "половину отображения задавать автоматически"?
> мы знали - что поле у нас именно Название, а не просто строка.
"Знали" у тебя что означает: воззрения человека или запись на бумаге?
> название у договора не одно, а несколько
Поэтому код более конкретен: "название --- одна строка знаков предопределённого алфавита."
То, что нельзя уточнить код, это вполне очевидно,
потому что он уже является конкретным выражением.
---
"Мы диалектику учили не по Гегелю."
"Знали" у тебя что означает: воззрения человека или запись на бумаге?
> название у договора не одно, а несколько
Поэтому код более конкретен: "название --- одна строка знаков предопределённого алфавита."
То, что нельзя уточнить код, это вполне очевидно,
потому что он уже является конкретным выражением.
---
"Мы диалектику учили не по Гегелю."
> "Знали" у тебя что означает: воззрения человека или запись на бумаге?
запись в компьютере
> Поэтому код более конкретен: "название --- одна строка знаков предопределённого алфавита."
предопределенного где? на уровне данного компьютерного языка? на уровне документации этой страны?
на уровне возможностей нашей железки?
> То, что нельзя уточнить код, это вполне очевидно, потому что он уже является конкретным выражением
как раз из этого и следует - что с кодом почти невозможно работать, потому что его невозможно уточнять.
Соответственно нужно что-то более высокоуровневое, чем код.
запись в компьютере
> Поэтому код более конкретен: "название --- одна строка знаков предопределённого алфавита."
предопределенного где? на уровне данного компьютерного языка? на уровне документации этой страны?
на уровне возможностей нашей железки?
> То, что нельзя уточнить код, это вполне очевидно, потому что он уже является конкретным выражением
как раз из этого и следует - что с кодом почти невозможно работать, потому что его невозможно уточнять.
Соответственно нужно что-то более высокоуровневое, чем код.
описание мы можем уточнить(отнаследовать) например так:что не можем в коде?
название у договора не одно, а несколько - одно официальное, другое внутренее, третье - международное и т.д.
в качестве названия (если нет уточнения) используется официальное название.
код мы уже так уточнить не сможем.
> что не можем в коде?
уточнять.
в коде - для уточнения, есть только сильно ограниченный метод наследования типов.
уточнять.
в коде - для уточнения, есть только сильно ограниченный метод наследования типов.
>> "Знали" у тебя что означает: воззрения человека или запись на бумаге?
> запись в компьютере
Тогда это не понятия.
>> Поэтому код более конкретен: "название --- одна строка знаков предопределённого алфавита."
> предопределенного где?
Языком программирования.
>> То, что нельзя уточнить код, это вполне очевидно,
>> потому что он уже является конкретным выражением
> как раз из этого и следует - что с кодом почти невозможно
> работать, потому что его невозможно уточнять.
> Соответственно нужно что-то более высокоуровневое, чем код.
Даже высокоруровневый код --- это тот же код.
Просто один язык ты сменяешь другим.
То, что ты хочешь сделать, называется "DSL."
На сях это делается всё-таки очень и очень плохо.
Вне зависимости от приплюснутости.
---
"Я знаю правду! Все прежние правды --- прочь!"
> запись в компьютере
Тогда это не понятия.
>> Поэтому код более конкретен: "название --- одна строка знаков предопределённого алфавита."
> предопределенного где?
Языком программирования.
>> То, что нельзя уточнить код, это вполне очевидно,
>> потому что он уже является конкретным выражением
> как раз из этого и следует - что с кодом почти невозможно
> работать, потому что его невозможно уточнять.
> Соответственно нужно что-то более высокоуровневое, чем код.
Даже высокоруровневый код --- это тот же код.
Просто один язык ты сменяешь другим.
То, что ты хочешь сделать, называется "DSL."
На сях это делается всё-таки очень и очень плохо.
Вне зависимости от приплюснутости.
---
"Я знаю правду! Все прежние правды --- прочь!"
> Даже высокоруровневый код --- это тот же код.
есть описание, а есть - код. не надо их путать и смешивать.
код, в первую очередь, говорит - как надо делать.
описание, в первую очередь, говорит - что надо делать.
есть описание, а есть - код. не надо их путать и смешивать.
код, в первую очередь, говорит - как надо делать.
описание, в первую очередь, говорит - что надо делать.
> код, в первую очередь, говорит - как надо делать.
> описание, в первую очередь, говорит - что надо делать.
Открой для себя декларативное программирование.
---
"Расширь своё сознание!"
> описание, в первую очередь, говорит - что надо делать.
Открой для себя декларативное программирование.
---
"Расширь своё сознание!"
>в коде - для уточнения, есть только сильно ограниченный метод наследования типов.
Согласен.
А если использовать композицию, и если у нас есть вот такая (реализация старой идеи Universal relation ограничения остаются?
Согласен.
А если использовать композицию, и если у нас есть вот такая (реализация старой идеи Universal relation ограничения остаются?
> если использовать композицию, и если у нас есть вот такая фича (реализация старой идеи Universal relation ограничения остаются?
да, остаются
потому что очень многие вещи можно класть на код сильно по разному.
и если ты уже одним способом положил, то другим уже не сможешь.
> если у нас есть вот такая фича (реализация
это фича - слабая, т.к. при ее использовании - мы теряем самое главное - контроль за программой на этапе разработки.
да, остаются
потому что очень многие вещи можно класть на код сильно по разному.
и если ты уже одним способом положил, то другим уже не сможешь.
> если у нас есть вот такая фича (реализация
это фича - слабая, т.к. при ее использовании - мы теряем самое главное - контроль за программой на этапе разработки.
ты о чем?
это фича - слабая, т.к. при ее использовании - мы теряем самое главное - контроль за программой на этапе разработки.
> Открой для себя декларативное программирование.
Для начала хотя бы вспомнил, что такое "декларативное/декларация" по русски.
Декларация - и означает "описание".
Для начала хотя бы вспомнил, что такое "декларативное/декларация" по русски.
Декларация - и означает "описание".
> ты о чем?
о том, что по ссылке был код вида - Root["User.Age"], правильность которого очень тяжело контролировать на этапе разработки.
о том, что по ссылке был код вида - Root["User.Age"], правильность которого очень тяжело контролировать на этапе разработки.
имхо, любое описание, когда оно обрастает деталями, менять сложно
да, остаются
потому что очень многие вещи можно класть на код сильно по разному.
и если ты уже одним способом положил, то другим уже не сможешь.
> имхо, любое описание, когда оно обрастает деталями, менять сложно
очень сильно зависит от архитектуры описания.
очень сильно зависит от архитектуры описания.
о том, что по ссылке был код вида - Root["User.Age"], правильность которого очень тяжело контролировать на этапе разработки.а
, я не о конкретной реализации, я, в общем, о композиции с возможностью не указывать путь между сущностями при обращении к атрибуту одной сущности из другой (мы же тут типа об архитектуре 
)Я в курсе.
А почему ты не вспомнил о декларативном программировании раньше?
---
...Я работаю антинаучным аферистом...
А почему ты не вспомнил о декларативном программировании раньше?
---
...Я работаю антинаучным аферистом...
> А почему ты не вспомнил о декларативном программировании раньше?
потому что - на данный момент - оно представлено очень и очень слабо.
и сейчас - программирование(на уровне компьютера, а не на уровне головы или бумажки) и кодирование - обычно синонимы.
потому что - на данный момент - оно представлено очень и очень слабо.
и сейчас - программирование(на уровне компьютера, а не на уровне головы или бумажки) и кодирование - обычно синонимы.
> по-умолчанию грид выглядит как указано в определении "таблички", если надо поменять ширину колонки, меняешь ширину одной колонки в гриде. Ты это называешь "половину отображения задавать автоматически"?
нет, это чисто ручное задание.
потому что под каждое разрешение экрана придется заново задавать ширины колонок.
нет, это чисто ручное задание.
потому что под каждое разрешение экрана придется заново задавать ширины колонок.
> а , я не о конкретной реализации, я, в общем, о композиции с возможностью не указывать путь между сущностями при обращении к атрибуту одной сущности из другой (мы же тут типа об архитектуре )
конкретизируй чуть свое понимание этого подхода.
у меня пока очень размытый образ по слову "композиция", и пока не получается выдвигать каких-то утверждений.
конкретизируй чуть свое понимание этого подхода.
у меня пока очень размытый образ по слову "композиция", и пока не получается выдвигать каких-то утверждений.
>потому что под каждое разрешение экрана придется заново задавать ширины колонок.
ну, это проблемы компонент в каких единицах указывать ширину
ну
, это проблемы компонент в каких единицах указывать ширину> потому что под каждое разрешение экрана придется заново задавать ширины колонок.
> ну , это проблемы компонент в каких единицах указывать ширину
проблема как раз не в единицах, а в архитектуре описания.
одно дело - ширина задается жестко в пикселях, другое дело - в символах, или в процентах.
намного лучше - если так же можно задать min/max-пределы
почти хорошо - если это можно совмещать с runtime-методами (например, выставление ширины на основе содержимого)
и т.д.
> ну , это проблемы компонент в каких единицах указывать ширину
проблема как раз не в единицах, а в архитектуре описания.
одно дело - ширина задается жестко в пикселях, другое дело - в символах, или в процентах.
намного лучше - если так же можно задать min/max-пределы
почти хорошо - если это можно совмещать с runtime-методами (например, выставление ширины на основе содержимого)
и т.д.
я возьму паузу
в HTML вроде это все можно, в Avalon-е тоже наверное сделают
одно дело - ширина задается жестко в пикселях, другое дело - в символах, или в процентах.
намного лучше - если так же можно задать min/max-пределы
почти хорошо - если это можно совмещать с runtime-методами (например, выставление ширины на основе содержимого)
и т.д.
кстати, почему чисто дизайнерские вещи смешиваются с проблемами реализации бизнес логикой? в этом есть какой-то глубинный смысл?
>> А почему ты не вспомнил о декларативном программировании раньше?
> потому что - на данный момент - оно представлено очень и очень слабо.
А системы, о которых ты говоришь, представлены очень неслабо?
> и сейчас - программирование и кодирование - обычно синонимы.
Мне сейчас безразлично, как "обычно."
Ты сейчас чем занимаешься: программированием или кодированием?
---
...Я работаю антинаучным аферистом...
> потому что - на данный момент - оно представлено очень и очень слабо.
А системы, о которых ты говоришь, представлены очень неслабо?
> и сейчас - программирование и кодирование - обычно синонимы.
Мне сейчас безразлично, как "обычно."
Ты сейчас чем занимаешься: программированием или кодированием?
---
...Я работаю антинаучным аферистом...
> кстати, почему чисто дизайнерские вещи смешиваются с проблемами реализации бизнес логикой? в этом есть какой-то глубинный смысл?
встречный вопрос:
почему это необходимо решать по-отдельности?
встречный вопрос:
почему это необходимо решать по-отдельности?
> Ты сейчас чем занимаешься: программированием или кодированием?
сейчас - это когда и где?
сейчас - это когда и где?
В этом обсуждении.
---
...Я работаю антинаучным аферистом...
---
...Я работаю антинаучным аферистом...
>> кстати, почему чисто дизайнерские вещи смешиваются с проблемами реализации бизнес логикой?
>> в этом есть какой-то глубинный смысл?
> встречный вопрос:
> почему это необходимо решать по-отдельности?
А зачем тогда было писать про разделение на сущности (с чего начался тред если ты сейчас предлагаешь решать всё одновременно? Разделение на сущности ведь нужно как раз для того, чтобы решать задачи по-отдельности, независимо друго от друга. С каждым письмом я тебя всё меньше и меньше понимаю...
Вообще, как раз дизайн и смежные области - это то, что легче чего отделяется, то, что во всех нормальных системах отделяется, и то, что проблем особых и не доставляет. Поставь задачу (требование к терминалам у будет тебе решение. Естественно, чем универсальнее решение - тем сложнее и дороже оно будет... Но по-моему, эти вопросы рассматривать не следует, по крайней мере, если мы обсуждаем автоматизацию разработки КИС. Давай лучше об описании бизнес-процессов поговорим - это было бы интереснее, чем формы обсуждать.
>> в этом есть какой-то глубинный смысл?
> встречный вопрос:
> почему это необходимо решать по-отдельности?
А зачем тогда было писать про разделение на сущности (с чего начался тред если ты сейчас предлагаешь решать всё одновременно? Разделение на сущности ведь нужно как раз для того, чтобы решать задачи по-отдельности, независимо друго от друга. С каждым письмом я тебя всё меньше и меньше понимаю...
Вообще, как раз дизайн и смежные области - это то, что легче чего отделяется, то, что во всех нормальных системах отделяется, и то, что проблем особых и не доставляет. Поставь задачу (требование к терминалам у будет тебе решение. Естественно, чем универсальнее решение - тем сложнее и дороже оно будет... Но по-моему, эти вопросы рассматривать не следует, по крайней мере, если мы обсуждаем автоматизацию разработки КИС. Давай лучше об описании бизнес-процессов поговорим - это было бы интереснее, чем формы обсуждать.
> А зачем тогда было писать про разделение на сущности (с чего начался тред если ты сейчас предлагаешь решать всё одновременно? Разделение на сущности ведь нужно как раз для того, чтобы решать задачи по-отдельности, независимо друго от друга. С каждым письмом я тебя всё меньше и меньше понимаю...
Это два разных инструмента анализа, и ими надо просто уметь пользоваться.
Обобщение(сваливание в кучу) делается для того, чтобы, если получиться, решить большую часть проблем - одним махом, соответственно одна из подзадач при сваливании в кучу - это по максимуму выделить наиболее общие задачи, подходы и т.д.
Конкретизация (разделение) - делается для того, чтобы:
1. чем выше конкретизация, тем проще работать - проще делать категоричные утверждения
2. по-максимуму выделить мелкие детали
3. найти частные решения тех задач, которые не решаются в общем.
По ходу анализа - эти оба инструмента используются циклически:
разделили на кучки,
увидели какие-то детали/частные решения
собрали все вместе,
на основе частных решений - сформировали общее решение
и далее по кругу.
> Но по-моему, эти вопросы рассматривать не следует, по крайней мере, если мы обсуждаем автоматизацию разработки КИС. Давай лучше об описании бизнес-процессов поговорим - это было бы интереснее, чем формы обсуждать.
Еще раз повторяю, что мне нужен конечный результат.
Какой толк от крутой бизнес-логики, если, например, ее состояние - мы не просмотреть, не отредактировать - не сможем?
причем, что самое важное - что проблемы, которые и при формирование форм в автоматизированном виде, и при формирование бизнес-логики - стоят одни и те же.
Что в одном случае - мы имеем плохо формализованную задачу, что в другом.
что в одном случае - нам нужны какие-то инструменты - для описания задачи, борьбы со сложность, что в другом.
Причем опять же - задачи бизнес-логики абстрактны (т.к. сегодня мало понятно, какой "бизнес" будут автоматизировать завтра а вот задача - автоматического формирования GUI - есть и вчера, и сегодня, и завтра.
Причем как раз требования к этой задаче - известны уже сегодня.
Поэтому эта задача - очень хорошо подходит на роль - модельной.
> Давай лучше об описании бизнес-процессов поговорим
давай поговорим.
Какие конкретные проблемы/задачи тебя волнуют?
Это два разных инструмента анализа, и ими надо просто уметь пользоваться.
Обобщение(сваливание в кучу) делается для того, чтобы, если получиться, решить большую часть проблем - одним махом, соответственно одна из подзадач при сваливании в кучу - это по максимуму выделить наиболее общие задачи, подходы и т.д.
Конкретизация (разделение) - делается для того, чтобы:
1. чем выше конкретизация, тем проще работать - проще делать категоричные утверждения
2. по-максимуму выделить мелкие детали
3. найти частные решения тех задач, которые не решаются в общем.
По ходу анализа - эти оба инструмента используются циклически:
разделили на кучки,
увидели какие-то детали/частные решения
собрали все вместе,
на основе частных решений - сформировали общее решение
и далее по кругу.
> Но по-моему, эти вопросы рассматривать не следует, по крайней мере, если мы обсуждаем автоматизацию разработки КИС. Давай лучше об описании бизнес-процессов поговорим - это было бы интереснее, чем формы обсуждать.
Еще раз повторяю, что мне нужен конечный результат.
Какой толк от крутой бизнес-логики, если, например, ее состояние - мы не просмотреть, не отредактировать - не сможем?
причем, что самое важное - что проблемы, которые и при формирование форм в автоматизированном виде, и при формирование бизнес-логики - стоят одни и те же.
Что в одном случае - мы имеем плохо формализованную задачу, что в другом.
что в одном случае - нам нужны какие-то инструменты - для описания задачи, борьбы со сложность, что в другом.
Причем опять же - задачи бизнес-логики абстрактны (т.к. сегодня мало понятно, какой "бизнес" будут автоматизировать завтра а вот задача - автоматического формирования GUI - есть и вчера, и сегодня, и завтра.
Причем как раз требования к этой задаче - известны уже сегодня.
Поэтому эта задача - очень хорошо подходит на роль - модельной.
> Давай лучше об описании бизнес-процессов поговорим
давай поговорим.
Какие конкретные проблемы/задачи тебя волнуют?
> Вообще, как раз дизайн и смежные области - это то, что легче чего отделяется
физическая сторона (например, как вывести грид в консольном режиме) - да.
Логическая (как твои данные будут показываться) - нет, это всецело остается на основном разработчике системы..
физическая сторона (например, как вывести грид в консольном режиме) - да.
Логическая (как твои данные будут показываться) - нет, это всецело остается на основном разработчике системы..
> Еще раз повторяю, что мне нужен конечный результат.
Тогда к чему была вся эта болтовня?
Есть более прямой путь к цели.
---
...Я работаю антинаучным аферистом...
Тогда к чему была вся эта болтовня?
Есть более прямой путь к цели.
---
...Я работаю антинаучным аферистом...
а про что этот тред то, а то прочитал первый пост, не понял, вопрос то какой?
Про то, что хочет чего-то странного.
---
"Не надо читать много книг."
---
"Не надо читать много книг."
> Есть более прямой путь к цели.
таких я не знаю,
по крайней мере - я не знаю таких, чтобы они мне понравились.
таких я не знаю,
по крайней мере - я не знаю таких, чтобы они мне понравились.
Тебе указывали.
Верно второе.
---
Q35: А xxxxx yyyyy ?
A35: Сорри, я не нашел начало треда. О чем вообще речь?
Верно второе.
---
Q35: А xxxxx yyyyy ?
A35: Сорри, я не нашел начало треда. О чем вообще речь?
>> Но по-моему, эти вопросы рассматривать не следует, по крайней мере, если мы обсуждаем автоматизацию разработки КИС.
>> Давай лучше об описании бизнес-процессов поговорим - это было бы интереснее, чем формы обсуждать.
> Еще раз повторяю, что мне нужен конечный результат.
> Какой толк от крутой бизнес-логики, если, например, ее состояние - мы не просмотреть, не отредактировать - не сможем?
> причем, что самое важное - что проблемы, которые и при формирование форм в автоматизированном виде,
> и при формирование бизнес-логики - стоят одни и те же.
Нет, проблемы принципиально разные - потому, что в случае форм формальное описание составить несложно, а вот в случае бизнес-логики совершенно не ясно, как это сделать и как это формализовать. С формами проще - остановись, для начала, на каком-нибудь одном варианте, например на веб-формах - у них всё просто с формальным описанием, они сами форматируются, они сетевые (проблемы тут есть, но это отдельная тема). Вот, через веб-формы, без всяких аплетов и т.п. можно реализовать очень мощную логику, мощные интерфейсы. Так что просмотреть и отредактировать ты сможешь. Но ведь главное - это что ты будешь редактировать, так?
> Причем опять же - задачи бизнес-логики абстрактны (т.к. сегодня мало понятно, какой "бизнес" будут автоматизировать
> завтра а вот задача - автоматического формирования GUI - есть и вчера, и сегодня, и завтра.
> Причем как раз требования к этой задаче - известны уже сегодня.
> Поэтому эта задача - очень хорошо подходит на роль - модельной.
Если хочешь подумать над конкретной задачей по автоматизации формирования GUI - то можно, только конкретной, а не абстрактно-универсальной. Давай про веб-формы поговорим, задача актуальная
>> Давай лучше об описании бизнес-процессов поговорим
> Какие конкретные проблемы/задачи тебя волнуют?
Очень просто - как это дело максимально формализовать в текстовом виде, не в виде сомнительных uml-диаграмм, а именно строгим не литературным текстом. Например задача
1) секретарша получила докумен
2) прочитала его
3) если он ей понравился - передала начальству
4) если нет - выкинула в мусорку
Это может бредовой задачей, но нужно уметь составлять нормальные текстовые описания для такого... Только после этого можно будет думать об автоматизации.
>> Давай лучше об описании бизнес-процессов поговорим - это было бы интереснее, чем формы обсуждать.
> Еще раз повторяю, что мне нужен конечный результат.
> Какой толк от крутой бизнес-логики, если, например, ее состояние - мы не просмотреть, не отредактировать - не сможем?
> причем, что самое важное - что проблемы, которые и при формирование форм в автоматизированном виде,
> и при формирование бизнес-логики - стоят одни и те же.
Нет, проблемы принципиально разные - потому, что в случае форм формальное описание составить несложно, а вот в случае бизнес-логики совершенно не ясно, как это сделать и как это формализовать. С формами проще - остановись, для начала, на каком-нибудь одном варианте, например на веб-формах - у них всё просто с формальным описанием, они сами форматируются, они сетевые (проблемы тут есть, но это отдельная тема). Вот, через веб-формы, без всяких аплетов и т.п. можно реализовать очень мощную логику, мощные интерфейсы. Так что просмотреть и отредактировать ты сможешь. Но ведь главное - это что ты будешь редактировать, так?
> Причем опять же - задачи бизнес-логики абстрактны (т.к. сегодня мало понятно, какой "бизнес" будут автоматизировать
> завтра а вот задача - автоматического формирования GUI - есть и вчера, и сегодня, и завтра.
> Причем как раз требования к этой задаче - известны уже сегодня.
> Поэтому эта задача - очень хорошо подходит на роль - модельной.
Если хочешь подумать над конкретной задачей по автоматизации формирования GUI - то можно, только конкретной, а не абстрактно-универсальной. Давай про веб-формы поговорим, задача актуальная
>> Давай лучше об описании бизнес-процессов поговорим
> Какие конкретные проблемы/задачи тебя волнуют?
Очень просто - как это дело максимально формализовать в текстовом виде, не в виде сомнительных uml-диаграмм, а именно строгим не литературным текстом. Например задача
1) секретарша получила докумен
2) прочитала его
3) если он ей понравился - передала начальству
4) если нет - выкинула в мусорку
Это может бредовой задачей, но нужно уметь составлять нормальные текстовые описания для такого... Только после этого можно будет думать об автоматизации.
> а про что этот тред то, а то прочитал первый пост, не понял, вопрос то какой?
Вспомни понятие "марковский процесс" из матстатистики...
Примени его к обсуждению.
Так ли важен после этого первый пост?
Вспомни понятие "марковский процесс" из матстатистики...
Примени его к обсуждению.
Так ли важен после этого первый пост?
Я ещё помню, марковость отменяется.
---
Q35: А xxxxx yyyyy ?
A35: Сорри, я не нашел начало треда. О чем вообще речь?
---
Q35: А xxxxx yyyyy ?
A35: Сорри, я не нашел начало треда. О чем вообще речь?
> Давай про веб-формы поговорим, задача актуальная
пусть будут веб-формы - неважно.
Ты зря думаешь, что Gui не является частью бизнес-логики.
как только бизнес-логика завязывается на пользователя, то сразу у тебя в бизнес-логику попадает Gui.
Что именно вывести, где, в каком виде (текстовом, графическом: картинка, цвет) - это все и есть, в том числе, задачи бизнес-логики.
> Очень просто - как это дело максимально формализовать в текстовом виде, не в виде сомнительных uml-диаграмм, а именно строгим не литературным текстом.
Описание делается в виде нескольких автоматных схем с комплексными состояниями.
На каждое состояние - описываются правила, по которым мы понимаем, почему мы считаем, что мы находимся именно в этом состоянии.
Состояния у тебя:
1. Документа нет
2. Документ получен секретаршей
3. ДОкумент обработан секретаршей - есть ее вердикт
4. документ у начальника
5. документ в мусорке.
Контрольные проверки на каждое состояние:
1. Документ отсутствует
2. документ есть, владелец - секретарша, вердикта секретарши - нет
3. документ есть, владелец - секретарша, вердикт секретарши -есть
4. документ есть, владелец - начальник, вердикт секретарши есть и положительный
5. документ есть, владелец - мусорка, вердикт секретарши есть и отрицательный.
пусть будут веб-формы - неважно.
Ты зря думаешь, что Gui не является частью бизнес-логики.
как только бизнес-логика завязывается на пользователя, то сразу у тебя в бизнес-логику попадает Gui.
Что именно вывести, где, в каком виде (текстовом, графическом: картинка, цвет) - это все и есть, в том числе, задачи бизнес-логики.
> Очень просто - как это дело максимально формализовать в текстовом виде, не в виде сомнительных uml-диаграмм, а именно строгим не литературным текстом.
Описание делается в виде нескольких автоматных схем с комплексными состояниями.
На каждое состояние - описываются правила, по которым мы понимаем, почему мы считаем, что мы находимся именно в этом состоянии.
Состояния у тебя:
1. Документа нет
2. Документ получен секретаршей
3. ДОкумент обработан секретаршей - есть ее вердикт
4. документ у начальника
5. документ в мусорке.
Контрольные проверки на каждое состояние:
1. Документ отсутствует
2. документ есть, владелец - секретарша, вердикта секретарши - нет
3. документ есть, владелец - секретарша, вердикт секретарши -есть
4. документ есть, владелец - начальник, вердикт секретарши есть и положительный
5. документ есть, владелец - мусорка, вердикт секретарши есть и отрицательный.
Оставить комментарий
Dasar
Основную часть в прикладных системах занимают следующие части:1. Метаописание
2. Вьювер
3. Редактор
4. Хранилище
5. Отслеживание изменений
6. ИИ
Метаописание - описывает "сущностный" граф системы, то с чем мы работаем
1) сущности
2) свойства
3) взаимосвязи
4) ограничения
5) следствия
6) цели/требования(?)
Вьювер - предоставляет просмотр состояния системы
1) просмотр всей системы
2) просмотр множества сущностей
3) просмотр отдельной сущности
4) фильтрация/поиск
5) сортировка
6) сравнение(?)
Редактор - предоставляет редактирование состояния системы
1) изменение отдельных значений
2) групповые операции
3) copy/paste
4) undo/redo
5) соблюдение ограничений, накладываемых метаописанием
6) подсказка ввода/изменений
Хранилище - хранение внутреннего состояния системы
1) Надежность
2) Восстановление после сбоев
3) атомарность по внесению изменений
4) атомарность/независимость хранения состояния отдельных подчастей
5) поддержка версионности
6) поддержка хранения противоречивой информации
7) история изменений
Отслеживание изменений - подсистема, которая на основе метаописания отслеживает текущее состояние и изменения, и пытается применить следствия зафиксированные в метаописании.
Данная подсистема активно взаимодействует с редактором и ИИ.
Пример:
При изменение текста - данная подсистема должна проверить следствия - пересчитать величины скролбаров.
ИИ - подсистема принятия решений в автоматизированном или полуавтоматизированном виде.
1. Выделить возможные решения
2. Сформировать критерии оценки решения
3. Выбрать лучшее решение
4. Активно взаимодействовать с внешними экспертами (пользователями или другими системами).