О методах проектирования программного обеспечения автоматизированных систем управления технологическими процессами

Процесс проектирования ПО автоматизированных систем условно разбивают на следующие этапы:

1. Разработка проблемных спецификаций (технического задания) (поста­новка задачи; определение требований к вводу-выводу; описание ограни­чений).
2. Проектирование макроструктуры ПО автоматизированных систем (выбор и разработка основных функциональных алгоритмов и структур данных).
3. Выбор языков программирования и операционной системы.
4. Проектирование микроструктуры ПО автоматизированных систем (разработка спецификаций программ).
5. Кодирование (запись программ на языке) и получение носителей.
6. Тестирование и отладка.
7. Корректировка.
8. Оформление документации.
9. Сопровождение на объекте.

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

В процессе разработки ПО систем автоматизации допускают следующие типичные ошибки:

1. Недостаточно полно прорабатывают отдельные подсистемы и неточно определяют связи между этими подсистемами. При этом оказываются нару­шенными информационные связи между подсистемами.
2. Не учитывают характеристики используемой вычислительной техни­ки: объемы оперативных и внешних ЗУ, ограничения на время работы от­дельных подсистем программ. В результате система не в состоянии выполнить все возложенные на нее функции.
3. Нечетко определяют цели и функции подсистем.
4. Занижают оценки времени и стоимости разработок ПО программируемых логических контроллеров (ПЛК).
5. Недостаточно автономно определяют подсистемы,
6. Некачественно составляют документацию.

На процесс проектирования ПО большое влияние оказывают различные факторы; от выбранного метода проектирования, размера и вида программ используемою языка до квалифи­кации программистов.

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

Нисходящее проектирование систем автоматизации (проектирование сверху вниз). Известны различные названия этого подхода к проектированию программ: систематическое программирование, иерархическое проектирование программ, взрывное проектиро­вание. Суть подхода в определении основных обеспечиваемых функций в переходе к определе­нию дополнительных функций, вытекающих из этих основных. Этот процесс расчленения продол­жается до тех пор, пока в результате не получа­ются примитивы или элементарные операции, аппаратно реализуемые на одной из существую­щих вычислительных машин. Попытки формали­зовать этапы нисходящего проектирования нашли свое отображение в руководствах по проектиро­ванию, используемых в области автоматизированной обработки данных, как средство организации и управления комплексной разработкой проектов соответствующих систем. Примером может слу­жить методология иерархических диаграмм вход — обработка — выход или сокращенно HIPO, созданная фирмой IBM.

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

Нисходящее кодирование систем автоматизации (процесс написания кодов программы) бази­руется на представлении о параллельности различных этапов проектирования программы и кодирования отдельных ее частей. В простейшей форме нисходя­щего кодирования подразумевается, что написание кодов начинается после полного окончания проектирования программ. Существует другая форма нис­ходящего кодирования, при которой до начала проектирования следующих уровней, должны быть написаны коды этого верхнего уровня. Такой подход обычно обосновывается следующими соображениями:

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

программы:

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

Руководитель проекта при такой организации разработки отвечает за решение финансовых, административных, юридических вопросов, а главный программист— за технические вопросы. Авторы метода прослеживают аналогию с хирургической бригадой, в которой главный программист играет роль, аналогичную роли оперирую­щего хирурга. Члены бригады при этом скорее ассистируют главному специалисту, чем незави­симо пишут составные части. Главный програм­мист отвечает за детальную разработку системы, он целиком пишет важнейшие элементы системы, определяет разбиение на подсистемы и способ их объединения.

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

Библиотека состоит из четырех разделов:

1. Внутренняя библиотека, содержащая вос­принимаемые машиной исходные программы, пе­ремещаемые модули, объектные модули, опера­торы редактирования связей, тестовые данные.
2. Внешняя библиотека, содержащая текущее состояние листингов всех программ, а также листинги последних фиксированных версий программ.
3. Набор машинных процедур, включающий всю информацию, необходимую для обновления библиотек, выполнения те­стовых пусков, компиляции модулей, редактированию связей и хранению объектной программы.
4. Набор формальных процедур, точно определяющих правила внесения изменений в исходные программы, использования машинных процедур, обновления листингов и файлов внешней библиотеки, образования файлов и замены данных в архивах последних версий программ.

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

При вышеописанной организации разработки производительность труда программистов по данным превышала среднюю в четыре-пять раз и достигала в среднем 65 отлаженных команд на программиста в день и 35 команд на каждого члена бригады. В настоящее время можно указать следующую специализацию програм­мистов:

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

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

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

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

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

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

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

Модульное программирование автоматизированных систем. Модульное ПО систем управления технологическими процессами такое, в котором любую часть логической структуры можно изменить, не вызывая изменений в ос­тальных частях.' Одним из определяющих свойств является размер модуля. Полагают, что модуль должен быть ограничен 50—200 операторами. Другим свойством является независимость по отношению к таким факторам, как ло­гическая структура ПО (алгоритм работы системы), аргументы (параметры) модуля, константы, структура и формат базы данных, модульная структура управления программой. Фиксируя эти факторы, можно установить независимость отдельных модулей. При определении интерфейсов между модулями модуль можно заменить альтернативным (функционально эквивалентным т. е. вырабатывающим те же значения выходных данных при поступлении одинаковых входных данных). На конструкцию модуля обычно налагается следующее ограничение: «один вход — один выход», т. е. модульная программа должна состоять из модулей, которые имеют одну точку входа и одну точку выхода. Модуль не может изменять команды, другого модуля. К достоинствам модульных программ относятся:

• легкость составления и отладки (функциональные компоненты программы пишут и отлаживают порознь);
• легкость сопровождения и модификации;
• возможность распределения модулей между программистами различной квалификации в соответствии с уровнем сложности.

Однако широкому распространению принципа модульности систем управления технологическими процессами препятствуют следующие факторы:

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