Типичные ошибки при написании программ.

[RXL]

Dale, скажи честно, у тебя антипатия к GUI? Не стоит считать GUI чем-то элементарным.

[Dale]

Говорю честно, как на духу.

Нет у меня к GUI ни симпатий, ни антипатий, сугубо потребительское отношение. Равно как и к библиотекам сокетов, к парсерам XML и т.д. Может, я не прав, но любовь или ненависть к подобным вещам в моем представлении вообще является признаком патологии. Нужно - пользуюсь, не нужно - откладываю в сторону.

Те, кто считает GUI сутью и солью программирования, имеют на это полное право. Жаль только, когда действительно интересная тема при этом отправляется на задворки. Но опять же - мое сугубо личное мнение. Отправляясь в чужой монастырь, устав оставляю дома.

[RXL]

Я вот о том же говорю, что стоит вещи называть своими именами: мы помешали вашей беседе, а кнопочки тут не при чем.

[Dale]

Согласен, давайте невинно пострадавшие кнопочки реабилитируем. И попутно проявим хотя бы минимум уважения к автору темы, он заслуживает этого не меньше, чем кнопочки. Если уж перенос подобных тем поближе к пиву и диетам программистских жен неизбежен, то хотя бы избавим ее от обсуждения моих личных пристрастий. Не думаю, что они многим интересны.

[Алексей++]

Парни, хватит ругаться! Автор нормальный чувак, ИМХО, необычные размышления - это правильно. Это же уметь надо Ударения в маразм вроде не отмечено

[Dimka]

Давайте попробуем подобрать пример, на котором в чистом виде видны будут сложности именно размышления над программой, а не борьбы с несовершенством С и ему подобных раритетов.

Давайте. Мне видятся сложными для программирования плохо структурируемые задачи. Например, такие, в которых граф состояний близок к полному, а количество состояний велико (от 7 и выше). При этом события асинхронные, частота их поступлений может превышать скорость реакции.

[Dimka]

Переформулируя до неузнаваемости одну мне известную задачку (кстати, связанную с программированием пользовательского интерфейса):

Задача

Пусть есть переменная A, значение которой меняется в случайные моменты времени с существенными для человека интервалами (например, от 5 секунд до 5 часов). (Как меняется, не важно). Например, отображающая значение какого-то датчика. Программисту доступен сигнал оповещения об измении A.

Пусть есть переменная B, значением которой является вычисление некоторой функции F от A. Программисту доступен сигнал оповещения об изменении B.

Допустим, вычисление F - ресурсоёмкий и заметно длительный для человека процесс (длительностью 1-2 минуты), и решение о его запуске принимает человек. Программисту доступен сигнал о необходимости запуска вычисления F.

Пусть есть ресурсоёмкий и заметно длительный для человека процесс G (длительностью 5-15 минут), который тоже запускается человеком. Программисту доступен сигнал о необходимости запуска G и сигнал об окончании G.

При этом G не может быть запущен в моменты времени, когда значение B не соответствует значению A; F не может быть запущен в моменты времени, пока выполняется G.
Все сигналы асинхронны. Человек может подавать сигналы в любое время и допускать ошибки (т.е. посылать сигналы невовремя).

Нужно разработать индикаторы для человека, отображаемые в переменные C и D, разрешающие ему посылать сигналы на запуск процессов F и G соответственно.

Запрограммировать всё это дело.

[Вад]

При этом G не может быть запущен в моменты времени, когда значение B не соответствует значению A; F не может быть запущен в моменты времени, пока выполняется G.

А что происходит с G, если значение A меняется во время выполнения G? Соответствие A и B имеет значение только при запуске G, но не в процессе?

[Dimka]

Вад, да. Можно считать, что и F и G в самом начале читают текущие значения переменных; F в самом конце записывает новое значение B.

Запуск нескольких экземпляров F и G невозможен.

[Алексей++]

самое первое, что нужно сделать, это то, что

 - F при запуске запрещает запуск G
 - по окончанию вычисления B=F(A), F должна проверить, поменялось ли значение A (в сравнении с A в начале вычислений). Если  не поменялось, разрешаем запускать G


Ещё можно автоматизировать: запуск G производить из F по флагу, установленному программистом. Когда работает F , могут установить флаг, F в конце проверит, менялась ли A и запустит G.

Если надо запустить только G, то запускается F, смотрит, менялась ли A, если менялась - вычисляет, если не менялась, берёт предыдущий результат и выполняет G

[Вад]

А какова основная функция человека в этом процессе? Он является лишь частью системы, отвечая за решения о запуске F и G? Я так понимаю, он обслуживает процесс G и отвечает за то, чтобы данные для G были готовы (запускает процесс F)?

[Dimka]

Я выше сказал, что сигналы асинхронны, но процессы F и G работают в одном потоке исполнения.

Вад, да, задача человека - выбрать момент времени для запуска того или иного процесса (не в смысле ОС, а в смысле "вычислительный процесс").

Ещё можно автоматизировать

Нельзя, так как процессы имеют существенную длительность, и такая стратегия невыгодна. Фактически ты предлагаешь объединить их в один процесс длительностью в худшем случае 17 минут. Бывают случаи, когда F завершился и можно запускать G, но выгоднее подождать очередного значения A, ещё раз запустить F и только потом G. A изменяется с разными частотами: бывают серии быстрых изменений A, потом большая пауза.

И вообще твоё предложение - это не решение поставленной задачи, а её додумывание. Додумывать и "автоматизировать" ничего не надо. Нужно запрограммировать.

- F при запуске запрещает запуск G
 - по окончанию вычисления B=F(A), F должна проверить, поменялось ли значение A (в сравнении с A в начале вычислений). Если  не поменялось, разрешаем запускать G

Эта идея и ежу понятна. Тема же "о чём думает программист". В данном случае это не просто разработка алгоритма, а ещё и выбор новых переменных, может каких-то структур данных, решения о их взаимосвязях, организация управления вообще - в этом и весь интерес.

[ezus]

Как много всего за 2 дня.  И тема, неожиданно для меня, повернулась в мою сторону.

Ударения в маразм вроде не отмечено (у автора)

Ну спасибо, а то я уже начал сомневаться в своем интеллекте.

Кроме того, я приводил пример НЕ того как ПИСАТЬ, а пример того как ДУМАТЬ.

А это не одно и то же? Часто мы думаем на языке; формы языка определяют формы мысли.

Я добавлю сюда еще одну очень актуальную цитату из этого же поста.

Программировать - значит понимать (К. Нюгард)

Даже не знаю как и что ответить. Но попробую начать с байки, реальной.
Я дома; звонок от сотрудника соседнего отдела: "Мне сказали использовать ваш класс, как мне это сделать?". Использование класса требует некоторого понимания того, что он делает. Я пытаюсь что-то объяснить, но натыкаюсь на полное непонимание - стенка. В растерянности полу-шутя я задаю вопрос: "Вы сначала думаете или пишите?". На что получаю абсолютно серьезный несколько недоуменный ответ: "Конечно, сначала пишу, а потом думаю и разбираюсь, если что не так." Я был в шоке, но потом специально обратил внимание на то, что большенство программистов вокруг меня именно так и работают. Вот тут я действительно засомневался в своем интеллекте. Хотя мой вопрос был вполне легитимен: я мог объснить как работает класс, или без объяснение сказать ЧТО надо делать, или просто продиктовать код.
Второй пример: как-то в обеденное время за общим столом я абсолютно без задних мыслей при обсуждении какой-то худ.книжки, как что-то очевидное, сказал что в основе любой программы лежит некоторая идея, во всяком случае у меня так. На что все семь человек-программистов, сидевших в это время за столом, посмотрели на меня как на больного - какие еще идеи? Программа - это программа, и для ее написания идей не нужно.
Вот тут я почувствовал наступление на меня старческого маразма.
Если ты трезв, но все говорят тебе, что ты пьян - пойди и проспись.
Может быть все о чем я размышляю это чушь?
К счастью через какое-то время я это ощущение победил, просто запретив себе разговоривать на эти темы. Так что этот мой выход на форум редкое исключение в моем поведении.

Теперь по делу.
Знать , Уметь и Понимать.
Я знаю о существовании конкретного программистского приема
Я умею этим приемом пользоваться
Я понимаю какова причина появления этого приема, когда и почему надо\можно использовать этот прием, каковы его плюсы и минусы.

Мне кажется есть разница между:
Я использую данные прием, потому что он первый пришел мне в голову и
Я использую его, потому что осмысленно выбрал его и понимаю все последствия этого выбора. 

[Dimka]

Хотя мой вопрос был вполне легитимен: я мог объснить как работает класс, или без объяснение сказать ЧТО надо делать, или просто продиктовать код.

Насколько я понимаю, программист - понятие собирательное.

В былые времена, говорят, были кодировщики (целью которых было записать подготовленный алгоритм в кодах соответствующей машины и изготовить перфоленту), были собственно программисты (целью которых на основании поставленной задачи и известных методов её решения было оптимизировать математический метод под особенности конкретной машины), были алгоритмисты-аналитики (целью которых было по поставленной задаче разработать метод её решения), были постановщики задач.

Сейчас есть кодировщики (их задача писать код в соответствии с проектом), разработчики (их задача разрабатывать проект в соответствии с архитектурой и кодировать особо ответственные места), тестировщики (их задача проверять соответствие кода проекту, проекта архитектуре, архитектуры требованиям), архитекторы (их задача по имеющимся требованиям и ограничениям разработать архитектуру и выбрать платформу, инструментальные средства и технологии, при необходимости, разработать их, проектировать особо ответственные места), аналитики (их задача собрать и организовать требования и ограничения к системе, разработать информационную модель предметной/проблемной области).

В данном случае описано общение за обедом между толпой кодеров и кем-то повыше в профессиональной иерархии Естественной, что каждый уровень подразумевает свой круг понятий, представлений и идеалов. Странно лишь обвинять кодеров в том, что они кодеры. Если организации нужны были не кодеры, а разработчики, нужно было либо нанять других людей, либо озаботиться повышением квалификации имеющихся. В последнем случае кодер становится "растущим кодером", его круг понятий, представлений и идеалов меняется, поэтому он больше слушает, чем озвучивает свои взгляды. Поскольку информация структурируется по иерархии сверху вниз, общение тоже идёт таким образом, что архитектор общается с разработчиком на языке разработчика, разработчик общается с кодером на языке кодера; это возможно, так как профессиональный рост шёл снизу вверх, и в душе и разработчика и даже архитектора живёт маленький кодер Правда, внутренний кодер архитектора гораздо более дисциплинирован и подконтролен, нежели внешний

Самое интересное, что у нас в стране обычно у кодера можно повысить квалификацию, так как большая их часть вуз закончила и пыльный скелет знания у них где-то в шкафу есть. Если же кодер - техник из ПТУ, то, как правило, это его потолок, который курсами не поправишь. Говорят, таких много в разных Индиях.

Мне кажется есть разница между:
Я использую данные прием, потому что он первый пришел мне в голову и
Я использую его, потому что осмысленно выбрал его и понимаю все последствия этого выбора.

Есть.

А насчёт задачки?

[Dale]

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

А Вы уверены, что это былы действительно программисты? Старая шутка гласит: чтобы носить очки, недостаточно быть просто умным; нужно еще и иметь плохое зрение. Точно так же, чтобы быть программистом, недостаточно питать отвращение к физическому труду, нужно еще и иметь определенную профессиональную подготовку. И если полвека назад с теорией было туговато и программистами становились самоучки-энтузиасты, то сегодня в этом недостатка нет. И литературы навалом, только успевай читать, и даже образовательные стандарты есть, где четко прописано, что обязан знать и уметь программист.

[ezus]

Попытаюсь на примере предложенной задачи показать о чем я ДУМАЮ.
Понятно, что это будет слишком развернуто и насыщено "философией", но в данном случае цель - не решение задачи, а разбор примера.

Сначала пытаюсь понять о чем речь.
Первый этап - этап черного ящика.
Этот этап опирается на более развернутое определение понятия система.
Обычно на вопрос " Что такое система?" получаешь ответ типа "Система - это совокупность взаимосвязанных объектов", что в общем-то правильно, но является только половиной определения. Система - это не только что-то состоящее из чего-то, но и как целое , она является частью чего-то более общего - частью среды, с которой она взаимодействует, или - подсистемой некой мета-системы.
На этом этапе меня не интересует внутреннее устройство системы. Здесь я только анализирую среды. Их можно представить как ромашка - в центре программа, а липестки - это различные среды. Например: человеко-машинная, информационая, операционная, временная, организационная, административная и др. В нашем случае интересны: человеко-машинная и временная среды.
Временная среда рассматривает развитие процессов во времени и их взаимодействия и взаимозависимости.
Человеко-машинная среда определяет интерактивную информацию(входную и выходную), точки принятия решений человеком и возможные воздействия человека на программу.

Прошу прощение - продолжение следует. Надеюсь.

[ezus]

To Dimka & Dale:
Я Вам завидую:
Вам повезло работать в серьезных организациях с серьезными людьми - мне повезло меньше.

А насчёт задачки?

Попробую продолжить.

Ч-М среда.
Человек асинхронно получает 2 сигнала:
С - необходим расчет F
D - необходим расчет G

Человек может выполнить 2 команды:
К1 - выполнить расчет F
К2 - выполнить расчет G.

Точки принятия решений:
1. Нет сигналов - нет команд
2. Есть сигнал С - можно выдать К1
3. Есть сигнал D - можно выдать К2

Ошибки и реакция:
1. Если выдана команда при отсутствии сигнала, то команда игнорируется.

Анализ:
1. Не достаточно информации для принятие решений - нет данных, которые помогли бы принять решение нужно или нет выполнять соответствующую команду (не критично)
2. Нет полноты множества команд - если приходят оба сигнала и С и D , то нет команды К3 для последовательного расчета F и G (не критично)
3. Не определен момент погашения сигналов С и D ( не критично, если сигналы типа сообщений, и критично для сигналов типа транспорант или лампочка)
4. Отсутствует обратная связь по ошибкам человека. (не критично)

Возможно еще что-нибуть, но в принципе чМ интерфейс понятен.

[ezus]

Возможно еще что-нибуть, но в принципе чМ интерфейс понятен.

Понятен, но не совсем. Моя попытка перейти к временной среде породила дополнительные вопросы к черному ящику.

Продолжение анализа на этапе черного ящика.
4. Команды К1 и К2 являются:

• указанием\приказом о начале расчета

или

• разрешением на выполнение расчета в ближайше возможное время

или

• разрешением на выполнение расчета в подходящее время

  Критично с т.зр. выбора алгоритмов работы.

[Dimka]

Ч-М среда.
Человек асинхронно получает 2 сигнала:
С - необходим расчет F
D - необходим расчет G

Поправка. Не необходим, а возможен. У человека нет задачи по загоранию лампочки рефлекторно нажимать кнопку. Человек может нажать кнопку, когда посчитает это нужным, от системы требуется лишь обозначить периоды времени, когда кнопку нажимать нельзя/можно.

1. Не достаточно информации для принятие решений - нет данных, которые помогли бы принять решение нужно или нет выполнять соответствующую команду (не критично)

Это касается человека-оператора, но не касается программной системы. Зачем пытаться расширять границы системы?

2. Нет полноты множества команд - если приходят оба сигнала и С и D , то нет команды К3 для последовательного расчета F и G (не критично)

Вот тут мне бы хотелось пояснения. Какими путями возникла такая мысль? (Кстати, весьма похожая на идею Алексей1153++). Как говорится, один раз - случайность, два раза - совпадение. Если третий человек выскажет ту же мысль, я начну беспокоиться

3. Не определен момент погашения сигналов С и D ( не критично, если сигналы типа сообщений, и критично для сигналов типа транспорант или лампочка)

Формально - да. Но это решаемо и, собственно, составляет часть требуемого решения.

4. Отсутствует обратная связь по ошибкам человека. (не критично)

Этим можно не усложнять.

Продолжение анализа на этапе черного ящика.
4. Команды К1 и К2 являются:
указанием\приказом о начале расчета
или

разрешением на выполнение расчета в ближайше возможное время
или

разрешением на выполнение расчета в подходящее время
  Критично с т.зр. выбора алгоритмов работы.

Отчасти это даёт ответ на мои сомнения в пункте 2 Это приказ о немедленном начале расчёта.

[ezus]

Это касается человека-оператора, но не касается программной системы. Зачем пытаться расширять границы системы?

Пометка о некритичности и говорит о том, что я не собираюсь расширять систему. НО...

• Программа живет пока она изменяется
• Аппетит заказчика приходит во время его еды
• Развитие системы предусмотренное на этапе анализа задачи намного дешевле непредусмотренных изменений на этапе эксплуатации
• и т.д и т.п.

Поэтому, если я вижу недостатки(на мой взгляд) в системе, я их отмечаю, пытаюсь убедиться в их необходимости, и если я в себе уверен, то, даже не смотря на отказ заказчика, я стараюсь предусмотреть не дорогие ветки с отложенной реализацией.

Вот тут мне бы хотелось пояснения. Какими путями возникла такая мысль?

Это мысль скорее всего приходит ассоциативно: чаще всего человек реагирует на ситуацию, а не как обезьяна на сигнал. Сигнала у нас действительно 2, а возможных ситуаций три, следовательно и команд интуитивно должно быть 3.
Правда, если бы я начал анализ с времянной среды, то там сигналы бы рассматривались вне человеческого контекста, там было бы важно взаимодействие сигналов во времени, и вместо возникшего вопроса, скорее всего встал бы вопрос Как запретить ситуацию с двумя сигналами одновременно.

Мне кажется, это как раз иллюстрирует необходимость анализа задачи с разных точек зрения и не ограничиваться только анализом данными и алгоритмов.

3. Не определен момент погашения сигналов С и D ( не критично, если сигналы типа сообщений, и критично для сигналов типа транспорант или лампочка)

Формально - да. Но это решаемо и, собственно, составляет часть требуемого решения.

. Вот тут я не совсем согласен. Предложенная постановка не содержит критериев выбора. Возможны оба варианта, а критерий лежит в самой предметной области, а не в области программистской реализации.

Это приказ о немедленном начале расчёта.

Отсюда вытикает или запрет на одновременности C и D, или наличие К3.

[Алексей++]

Dimka, моя мысль состояла в том, чтобы избавиться от одной из вещей, которые требуется синхронизировать, а именно: G возможно начать только после выполнения F, да ещё если A одинаково в начале и в конце расчёта F. Поэтому эти две задачи нужно объединить в одну функцию. Эта функция позволяет выпольнить 2 различных сценария (в зависимости от заданной человеком задачи)

1) Задача: выполнить F. Действия функции:
    1 Выполнить F. (или взять результат из кеша)
    2 Завершение

2) Задача: выполнить G. Действия функции:
    1 Выполнить F. (или взять результат из кеша)
    2 Если поменялась A - завершение
    3 Выполнить G.


кстати, если A поменялась во время расчёта F, а затем вернулось в изначальное состояние - это тоже за изменение надо считать ?

[ezus]

Алексей1153++ ++
Т.к. асинхронность трудно воспринимаема нашим сознанием, то везде, где только возможно, я ищу возможность избежать асинхронности.
Поэтому в любом случае я выполнял бы F и G в одном потоке\процессе с алгоритмом типа:

Если К1, то выполнить F
иначе
если К2, то выполнить G

При наличии К3 - просто убрать "иначе"

[Алексей++]

ezus, ты забыл учесть, что возможность выполнения G зависит от смены A (и, соответственно, обязательного пересчёта F)

[ezus]

ezus, ты забыл учесть, что возможность выполнения G зависит от смены A (и, соответственно, обязательного пересчёта F)

Пардон, не понял, что я забыл? G  не зависит напрямую от A. И для выполнения G не требуется смена А и расчет F. Он мог быть выполнен ранее и только потом, через какое-то время запускается только G. Возможно для полноты и ясности в "если" необходимо добавить провекрки состояний, но привел не строгий алгоритм, а только его структуру.

[Алексей++]

При этом G не может быть запущен в моменты времени, когда значение B не соответствует значению A; F не может быть запущен в моменты времени, пока выполняется G.

[Dimka]

Вот читаю и думаю, как по-разному думают программисты об одном и том же


Лично я в первую очередь думал о состояниях и переходах между ними.

Первый вопрос: что на что влияет?

Отсюда видно, что начальным независимым элементом системы является A (в него стрелки зависимостей только входят), конечным зависимым элементом является G (из него стрелки только выходят). Элементы F и B являются по зависимостям транзитными.

Теперь учтём, что A и B - это переменные со значениями, а F и G - вычислительные процессы. Зависимость процесса от переменной интерпретируем как-то, что данная переменная является входной для процесса. Зависимость переменной от процесса интерпретируем как-то, что данная переменная является выходной для процесса. Как выше оговаривалось, в данной задаче считается, что процесс в начале читает значения входных переменных и в конце записывает значения выходных, в остальное время значения переменных "свободны".

Поскольку G имеет входными A и B, но B транзитивно через F зависит от A, и оговорено, что должно наблюдаться соответствие A и B как B=F(A). Это равенство существенно для запуска G (является одним из предусловий), поэтому обозначим его соблюдение как логический флаг Z1. Для запуска G также существенно (другое его предусловие), чтобы процесс F не выполнялся (в соответствии с оговоренными ограничениями). Наличие/отсутствие выполнения F обозначим логическим флагом Z2.

По смыслу процесса F нужно невыполнение равенства B=F(A), т.к. F это равенство восстанавливает. Это предусловие для запуска F выражается через уже введённый флаг Z1, но взятый с отрицанием. Второе предусловие запуска F - отсутствие выполнения процесса G, обозначим его логическим флагом Z3.

Эти три флага дают 8 возможных состояний:

Код:

# Z1 Z2 Z3 E
1 0  0  0  +
2 0  0  1  *
3 0  1  0  &
4 0  1  1  -
5 1  0  0  +
6 1  0  1  *
7 1  1  0  &
8 1  1  1  -

Некоторые из состояний заведомо невозможны - они обозначены "-" в столбце E (ошибка). По условию задачи невозможно одновременное исполнение процессов F и G - состояния 4 и 8 исключаются. Состояния выполняющихся процессов являются безразличными с точки зрения флага Z1, поэтому могут быть объединены: это пары состояний 2 и 6 (обозначены "*"), 3 и 7 (обозначены "&"). После этого анализа у нас остаётся следующая таблица состояний:

Код:

# Z1 Z2 Z3 C D
1 0  0  0  1 0
2 1  0  0  0 1
3 X  1  0  0 0
4 X  0  1  0 0

Из которой несложно определить значения искомых индикаторов C и D. Кроме того, можно определить логику смены состояний, а сами состояния разделить на 2 класса: вычислительных (соответствующих работе процессов) и управляющих (соответствующих периодам принятия решений). Получается, что каждый индикатор активен в соответствующем ему управляющем состоянии.

Только после этого анализа, по-моему, можно переходить к алгоритмам, точнее привязке сигналов и основной программы к состояниям и переходам между ними.

[Вад]

Любопытно Я размышление над этой задачей начал с человека.

Сначала я уяснил для себя, какую роль играет пользователь. Насколько я понял, пользователь здесь выступает в качестве эксперта, принимающего решения на основе поступающих данных и своего опыта. Соответственно, человек вырабатывает стратегию поведения, оценивая исходные данные и обучаясь методом проб и ошибок как можно лучше предугадывать возможные изменения в системе. И задача программы - способствовать ему в этом.

А потому программа должна решать две задачи:
1. Доставить пользователю максимум необходимой информации, чтобы улучшить его экспертные знания (лучше понимать систему и работать над ошибками),
2. Предоставить интерфейс принятия решений, предоставляющий пользователю требование о принятии решения в таком виде, который не допускает некорректного представления об актуальном состоянии системы. То есть, пользователь не должен быть введён в заблуждение, и не имеет возможности принять решение, не допускаемое логикой работы системы (например, дважды запустить G, или запустить F при A=B).

Соответственно, я сразу стал думать о том, что человек получает не два, а большее количество сигналов. И задача - как можно нагляднее представить пользователю происходящее в системе, при этом исключив недопустимые переходы между состояниями. И тут мало просто показать, что "нужно выполнить F" или "можно выполнять G" - так утрачивается информация о динамике системы. И вот как раз способ отобразить эту динамику наиболее эффективно и показался мне основной задачей данной системы. Основная проблема для меня: как помочь пользователю?

Что касается самих состояний и переходов, то тут у меня сразу возникла финальная картинка Для этого не потребовалось выводить полный список состояний - достаточно было сосредоточиться на согласовании двух вычислительных процессов в системе.

[Dimka]

Соответственно, я сразу стал думать о том, что человек получает не два, а большее количество сигналов. И задача - как можно нагляднее представить пользователю происходящее в системе, при этом исключив недопустимые переходы между состояниями. И тут мало просто показать, что "нужно выполнить F" или "можно выполнять G" - так утрачивается информация о динамике системы. И вот как раз способ отобразить эту динамику наиболее эффективно и показался мне основной задачей данной системы. Основная проблема для меня: как помочь пользователю?

Ну вот и третий

Тут отчасти моя вина, так как исходную задачу я зашифровал за буковками. И там ещё много всяких побочных ответвлений (например, значение B используется не только для G, но и в других местах, и поэтому человек решает не только "привести B в соответствие с A", но и "можно ли затереть текущее значение B новым").

Как говорил С. Королёв: "Луна - твёрдая!" - сим предлагаю дискуссию об удобствах юзера закрыть и считать, что индикаторы C и D - лучшее по эргономическим и прочим соображениям решение. А вот о будущих расширениях/изменениях системы думать можно, если нужно .

Сосредоточимся на программировании

Что касается самих состояний и переходов, то тут у меня сразу возникла финальная картинка  Для этого не потребовалось выводить полный список состояний - достаточно было сосредоточиться на согласовании двух вычислительных процессов в системе.

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

[ezus]

Спасибо за модель состояний.
Почему то я забыл ее включить в свою коллекцию.
Хотя понятно почему, в то время я в основном сталкивался с задачами АСУ, в которых динамика состояний встречается редко.

[Dimka]

динамика состояний

По-моему состояния и есть выражение динамики. Вне контекста динамики состояний не существует. Состояния потому выделяются, отделяются друг от друга, что для аналитика переход между ними считается значимым, если переходы между двумя состояниями не имеют значения, такие состояния объединяются в одно. Именно поэтому у меня получилось 4 состояния, не больше и не меньше.