Жуткое упрощенчество в изложении Паранджарова п.2-4. Так сказать, укрепление вертикали :)
Ну что это за принципы!
>>> Хотя Дейкстра не дает словесной формулировки третьего и четвертого принципов
Слава Аллаху!
А вот ограничение на “сочленение”, “выбор”, “повторение” замечательно.
Я бы даже пошёл дальше - ограничиться одним элементом: два входа - два выхода.
Три дейкстровских получаются как частные случаи коммутации
выходов, входов, входов и выходов соответственно.

Но что-то не вижу ограничения для линий коммутации. Где "нельзя пересекать"?
---
Смотрю я любителей разных моделей на каждый чих много. Эхе-хе. Традиция аддитивности.
Горькие плоды торжества линейных подходов в нашем нелинейном мире.

В русле единой модели идут ГИС программы, где коммуникации, здания и т.п. указываются совместно.
А "проектно-сметная документация" это хоть вещь жутко важная в нашем государстве победившей
бюрократии, но к практической инженерии имеет опосредованное отношение.
Затраты на все утряски стали уже превосходить собственно работы :(
---
Аргумент о том, что графика хороша лишь для пространственно распределённых задач
имеет под собой то основание, что здесь преимущества графики очевидны.
Однако, временные и логические последовательности также удобны для графического представления.
Именно из-за этого UML пал жертвой. Он превратился из универсального языка моделирования
в средство сопровождения проекта и контроля за его исполнением.
Менеджеры его используют, чтобы "пасти котов" за счёт их же непроизводительного труда.
Естественно, что к UML в среде программистов негатив полный.

Меня же интересует применение графики именно для моделирования. И, конечно, не везде и всюду.
Кроме блоков и линий-коннектов надо предусмотреть разъёмы и условия на вход выход,
что почти одно и то же.

Ответ на »сообщение 2818« (Сергей Перовский)
___________________________

Ответ на »сообщение 2794« (Beginner)
___________________________
Мне очень понравилось высказывание академика Н. (приводилась недавно ссылка Р Богатырёвым) о том, что современное состояние дел похоже на Океанию, где освоены лишь небольшие островки. Задачи "в море" каждый за уши притягивает к своему островку, который он умеет решать.
Это нормально?
С точки зрения психологии нормально :(
Так уж устроен наш мозг.
А то, что это неэффективно, и требует преодоления, так это в ветку про научную методологию - проверка области применимости всех используемых методов и средств должна стать абсолютно естественной привычкой.
Дискуссия о интерфейсах растет из той же проблемы: "вот посмотрите, как с помощью этого представления быстро решаются мои задачи - значит будут решаться и ВСЕ остальные". С какой стати все?
Интерфейс аксесса более-менее удачно соответствует тем задачам, для которых аксесс предназначен. Почему из этого следует, что подобный интерфейс будет удобен во всех случаях?


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

Цитируя Паронджарова...
Попытаемся еще раз заглянуть в темные переулки истории и внимательно перечитаем классический труд Дейкстры “Заметки по структурному программированию”. К немалому удивлению, мы обнаружим, что основной тезис о структурных управляющих конструкциях (для обозначения которых названный автор вводит термины “сочленение”, “выбор”, “повторение” [2]) излагается с прямой апелляцией к визуальному языку блок-схем! Непосредственный анализ первоисточника со всей очевидностью подтверждает: дейкстрианская “структурная революция” началась с того, что Дейкстра, использовав блок-схемы как инструмент анализа структуры программ, предложил наряду с другими важными идеями четыре принципа структуризации блок-схем, которые в дальнейшем были преданы забвению или получили иное, по нашему мнению, слишком вольное толкование. Эти принципы таковы.
1. Принцип ограничения топологии блок-схем. Структурная программа должна приводить “к ограничению топологии блок-схем по сравнению с различными блок-схемами, которые могут быть получены, если разрешить проведение стрелок из любого блока в любой другой блок. Отказавшись от большого разнообразия блок-схем и ограничившись ...тремя типами операторов управления, мы следуем тем самым некоей последовательностной дисциплине” [2].
2. Принцип вертикальной ориентации входов и выходов блок-схемы. Имея в виду шесть типовых блок-схем (if-do, if-then-else, case-of, while-do, repеat-until, а также “действие”), Дейкстра пишет: “Общее свойство всех этих блок-схем состоит в том, что у каждой из них один вход сверху и один выход снизу” [2].
3. Принцип единой вертикали. Вход и выход каждой типовой блок-схемы должны лежать на одной вертикали.
4. Принцип нанизывания типовых блок-схем на единую вертикаль. При последовательном соединении типовые блок-схемы следует соединять, не допуская изломов соединительных линий, чтобы выход верхней и вход нижней блок-схемы лежали на одной вертикали.
Хотя Дейкстра не дает словесной формулировки третьего и четвертого принципов, они однозначно вытекают из имеющихся в его работе иллюстраций [2]. Чтобы у читателя не осталось сомнений, мы приводим точные копии подлинных рисунков Дейкстры (рис. 131, средняя и левая графа)1.

Ответ на »сообщение 2811« (Beginner)
___________________________

Ответ на »сообщение 2809« (Beginner)
___________________________
Я чётко понимаю, что специализированные модели (той же принципиальной схемы сигнализации) делать легче, проще, а потому как бы правильнее. Но при этом теряется слишком многое - учёт взаимного влияния, материальность моделируемого объекта, практичность модели.

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

Модель не может быть полностью адекватна объекту моделирования - это всегда упрощение. Хорошая или плохая модель можно сказать только относительно определенных задач.
Если приходится решеть очень разные задачи, то одной моделью обойтись не удается.
Другое дело, что у этих моделей может быть общая часть.

Ответ на »сообщение 2794« (Beginner)
___________________________
Мне очень понравилось высказывание академика Н. (приводилась недавно ссылка Р Богатырёвым) о том, что современное состояние дел похоже на Океанию, где освоены лишь небольшие островки. Задачи "в море" каждый за уши притягивает к своему островку, который он умеет решать.
Это нормально?
С точки зрения психологии нормально :(
Так уж устроен наш мозг.
А то, что это неэффективно, и требует преодоления, так это в ветку про научную методологию - проверка области применимости всех используемых методов и средств должна стать абсолютно естественной привычкой.
Дискуссия о интерфейсах растет из той же проблемы: "вот посмотрите, как с помощью этого представления быстро решаются мои задачи - значит будут решаться и ВСЕ остальные". С какой стати все?
Интерфейс аксесса более-менее удачно соответствует тем задачам, для которых аксесс предназначен. Почему из этого следует, что подобный интерфейс будет удобен во всех случаях?

Ответ на »сообщение 2809« (Beginner)
___________________________

Бывает повторное использование кода, а я о повторном использовании модели. Я думал, что модель объекта едина. Все инженерные коммуникации проводятся в тех же стенах.

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

Почитайте СНиП 11-01-95 "Инструкция о порядке разработки, согласования, утверждения и составе проектной документации на строительство предприятий, зданий и сооружений" -- http://www.vashdom.ru/snip/1101-95/
Можете попробовать отобразить это на то, как в итоге может быть воплощено в промышленном программировании.

Ответ на »сообщение 2806« (Илья Ермаков)
___________________________
>>>Мое сообщение 2778 - о том, что Дейкстра сформулировал принципы структурного программирования именно для блок-схем.

В какой работе?

Ответ на »сообщение 2813« (Beginner)
___________________________

Ответ на »сообщение 2811« (Beginner)
___________________________
учёт взаимного влияния

Было такое - наложили схему теплотрасс на схему трамвайных путей и силовой проводки и выяснили, что блуждающие токи ускоряют коррозию на порядок. Под влиянием путей подразумевали тряску и соответсвенно сторожились её. А надо было делать спецзазамление и электроизоляцию.

Подобные случаи и есть естественное применение графики. Когда показывется нечто физически-пространственное, то тут и говорить не о чем.
А вот когда пытаемся рисовать нечто "эфемерное", как программная система или многомерные топологии на кристалле - вот тут-то и начинается самое интересное :-) Я не говорю, что это невозможно, но подобрать адекватное граф. представление сложнее на порядок. Из 10 предложенных представлений все 9 точно пойдут в корзину... А чтобы туда не пошло 10-е, оно должно быть не от балды придумано, а долго и упорно взращено из практики.

Удивительно, но объёмная схема лучше воспринимается, когда она ещё и крутится.
В случае статики объем лучше передавать градациями серого, а не спектром, хотя цвет более информативен.

Ответ на »сообщение 2811« (Beginner)
___________________________
учёт взаимного влияния

Было такое - наложили схему теплотрасс на схему трамвайных путей и силовой проводки и выяснили, что блуждающие токи ускоряют коррозию на порядок. Под влиянием путей подразумевали тряску и соответсвенно сторожились её. А надо было делать спецзазамление и электроизоляцию.