Oberon space

Да, вот ещё. Статья о счёте 20 даёт некоторый материал для размышлений. В частности, это:

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

В его основу положены следующие принципы:

• предварительное составление калькуляции себестоимости по каждому виду продукции на основании норм всех видов расходов;
• учет изменений норм и определение их влияния на себестоимость продукции;
• учет фактических затрат на производство с подразделением их на расходы по нормам и отклонениям от норм;
• установление и анализ причин отклонений фактических расходов от норм;
• расчет фактической себестоимости выпущенной продукции как суммы нормативной себестоимости, изменений норм и отклонений от норм.

- в общем-то можно понимать как определение (м.б. неполное) сути работы экономистов...

Почему бы и нет... и возвращаемся к тому, как воспитать умение учиться на ошибках... желательно не только собственных...

Цитата: Geniepro от Сентябрь 06, 2012, 01:09:15 pm

В той истории с арианом дисциплина программирования вообще ни при чём. Там скорее недостаток отладки, нехватка дисциплины тестирования...

Согласен - там ЯП не причем. Там ошибки более высокого уровня - тестирования, организации code reuse и вообще проектирования (код работал когда уже был не нужен).

А какое это имеет  сейчас значение?

В смысле - когда уже взорвалось? А что, если подход не сменится, вероятность новых инцидентов это уменьшит?.. ну, считаем, сделали они локальный вывод, что нельзя тупо переносить "объекты со сложным поведением" ((С) "автоматчики") в существенно отличную среду... а действия-то на более высоких уровнях м.б. разными... продумать новую систему как следует... или чего-то столь же тупо "допиливать" от уже наваянного не вполне продуманно... как сделали с Therac-25?..

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

...  давайте перестанем .. об этом - нечего здесь  мусолить...
это всего лишь мое мнение..

Да нет проблем - это было всего лишь обращение внимания на то, что:

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

- чему публичные предположения о поведении собеседников, думаю, не способствуют. Т.е. с моей стороны просто привычка к споспешествованию приличной организации дела. На сём и прекратим.

Ну, чисто программные выводы я просто считал вне своей компетенции... остановился на том, что очевидно с позиций системотехники...

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

И это как раз в тему сказанного:

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

Раз уж мой вывод кого-то интересует - хорошо. Тема ведь стартовала с того, что "вот тут на Коре обозначен поодход, широко практикуемый в ВУЗах страны"... и далее была предложена альтернатива (в основе своей - самообразование через взаимное обучение - топикстартер поправит, если я "отжал" суть неверно).

Так вот. Мне неясно - какие именно особенности того или другого подхода обеспечат формирование специалиста, который не будет пренебрегать свойствами готовых и/или разработанных им компонентов при их включении в систему?
И какие особенности обеспечат, чтобы специалист не игнорировал "принцип двухканальности" построения систем (часто называемый по имени Б.Н. Петрова)?.. А ведь это послужило главной причиной неоднократных убийств по халатности разработчиков (давайте называть вещи своими именами) при помощи Therac-25 (это второй пример из Аджиева)... Точнее, видимая причина - непродуманная логика многозадачного управления рентгеновским излучателем для реализации попременно диагностическоого и лечебного назначений. Однако реальная причина - в том, что контроль суммы параметров, определяющих дозу, был реализован среди других задач в общем контуре управления. Реализация была отработана на предыдущей - 20-й - модели прибора. Но новая модель имела изменения, опять же ставившие блок управления в другие условия (та же ситуация, что с Арианами). А разработчики самонадеянно решили, что это не играет роли...
Тогда как специалисты, адекватные как системотехники, ввели бы для этих жизненно важных параметров отдельный контур контроля (и блокировки) - возможно, не чисто программный, а на "жёсткой" (или микрокодовой) логике. И с продуманной индикацией оператору и логикой восстановления после блокировки... А не занимались бы героическим выявлением дефектов программной логики совмещённого контура... на жизнях пациентов...

В обсуждении я ничего раскрывающего эту тему не увидел - потому и вывод такой... неопределённый...

И ещё. Вот тут:

...
Кроме того, тут явно идет подмена цели - явно хотят чтобы человек писал программу правильно (в соответствии с неким шаблоном) а не научился программировать.
...

- важно то, что упоминается цель. И хотелось бы, чтобы не забывалось - программируют для чего-то. И учатся программировать - чтобы это "что-то" в реализации достигалось - а если не достигается, то хотя бы не влекло опасных последствий.
Вот таких, например, как здесь описаны... Усов, кстати, уже говорил, что программирование здесь только повторяет путь построения материальных систем:

...

Цитата: alexus от Август 11, 2012, 07:17:19 pm

...
Плохие спецификации бывают не только у программного обеспечения. Эта проблема становится серьёзной только потому, что ни заказчики, ни разработчики ПО не придерживаются требований стандартов (международных, государственных или отраслевых). Попробовали бы сдать какой-нибудь примитивный паровой котёл в эксплуатацию без приёмки и проверки котлонадзора... А вот программу, управляющую таким котлом, можно установить безо всяких последующих санкций. Парадокс? Нет просто безалаберность.
...

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

- а, кстати, в примерах от Аджиева можно обнаружить скорее претензии не к программированию, а к отсутствию аналитика как роли... но детали уведут за топик (замечу лишь, что вопросы к структуре системы)...

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

Так я понял это:

... хотелось бы услышать ваше мнение о разработке  В. Лаптева и Ко. -... .

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

А если сравнивать подход в этом редакторе с "диаграммным" - то с каким?.. Рискну предположить, что с техноязыковым всё-таки...
Тогда так - у Лаптева же вообще схем для алгоритмов не предусмотрено. И он (и Прохоренко) высказывались, почему - т.к. обычно должны получаться маленькие процедуры, которые проще представлять (и писать) текстово (м.б. с теми же структурными скобками Прохоренко... ну или моими двумерными )... А схемы нужны в этом случае совершенно других типов - разных зависимостей между процедурами (как по вызовам, так и по "взаимодействию в соовместном протекании", т.е. параллельном).
С этим я согласен. В частности, по опыту визуализации программ "из маленьких процедур" - прежде всего той же "Гетерогенной очереди" Свердлова... Так что ещё раз повторюсь - в этом смысле возможно понимаю, почему Пётр так оценивает "визуализацию исключительно алгоритмов" - какой мне как читателю толк от графит-схем множества мелких процедур без "схем подключения" их?.. и без схем типов, которые бы показывали области видимости и передачу параметров?..
Я уж не говорю, что сложную структуру маршрутов не всегда удаётся уложить "по-драконовски"... вспомним "преобразования графов"... ну и про циклы и их границы м.б. различные мнения...
Кстати, Рэйлвей Каген когда ещё указывал на ЕСКД... и Усов напоминает, что нужно использовать опыт проектирования материальных систем...

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

Кстати, и пример буквально счаз появился - вроде бы "решительный сторонник" техноязыка - но по этому посту видно, что реальная структура предмета описания "рвётся в облака" ЕСКД-подхоода... но ММ пятится назад... а ДРАКОН тянет в воду...