Глава 1 - Кафедра «Технологии программирования

— Участникам разработки общаться нетрадиционным путем в терминах
технологического процесса (например, не «идет» режим экстренного пуска),
а на промежуточном, полностью формализованном языке (своего рода
техническом эсперанто), на котором объясняться можно, например, следующим
образом: «в третьем ГП, в пятой вершине, на четвертой позиции —
изменить значение 0 на 1», что не вызывает разночтений, возникающих из-за
неоднозначности понимания даже для одного естественного языка, а тем более
для нескольких таких языков в случае, когда Участники разработки представляют
разные страны, и не требует привлечения Специалистов, знающих
технологический процесс, для корректного внесения изменений [267];
— снять с Программиста необходимость знания особенностей технологического
процесса, а с Разработчика — тонкостей программирования;
— Программисту функциональных задач ничего не додумывать за
Заказчика, Технолога и Разработчика, а только однозначно и формально
реализовывать систему ГП в виде программы, что позволяет резко снизить
требования к его квалификации, а в конечном счете и вовсе отказаться
от его услуг и автоматизировать процесс программирования или перейти
к автопрограммированию Разработчиком. Последнее возможно, однако,
только в том случае, когда программирование является для Разработчика
«открытым», что не всегда имеет место, в особенности при работе с
инофирмами или их подразделениями, занимающимися разработкой систем
управления, а не только аппаратуры;
— оставлять понятные «следы» после завершения разработки. Это
позволяет проводить модификацию программ новым людям, что при
традиционном подходе чрезвычайно трудоемко («проще построить программу
заново, чем разобраться в чужой программе»). При этом необходимо
отметить, что структурирование и комментарии указанную проблему
решают лишь частично;
— упростить внесение изменений в спецификацию и программу и
повысить их «надежность»;
— сделать алгоритмы управления инвариантными к используемым
языкам программирования, что открывает возможность формирования и
поддержания библиотек алгоритмов, записанных строго формально;
— Заказчику, Технологу и Разработчику контролировать тексты функциональных
программ, а не только результаты их выполнения, как это
имеет место в большинстве случаев в настоящее время;
— устранить не равную «прочность» приемки аппаратуры и программ
Контролером, так как в первом случае им кроме функционирования проверяется
много других характеристик (например, качество печатных плат и их
покрытий, качество пайки, номиналы и обозначения элементов), а во
втором — все внимание уделяется только проверке функционирования и не
исследуются внутренняя организация программ и технология их построения.
Апробация. Подход, в частности, использован:
— при создании совместно с фирмой «Norcontrol» (Норвегия) системы
управления дизель-генератором ДГР-2А 500*500 судна проекта 15760
[267]. Программирование выполнено фирмой на языке ПЛ/М;
— при создании системы управления дизель-генератором того же типа
судна проекта 15640 на базе аппаратуры «Selma-2». Программирование
выполнено НПО «Аврора» на языке функциональных блоков [269];
42