О методах проектирования программного обеспечения автоматизированных систем управления технологическими процессами
Процесс проектирования ПО автоматизированных систем условно разбивают на следующие этапы:
- Разработка проблемных спецификаций (технического задания) (постановка задачи; определение требований к вводу-выводу; описание ограничений).
- Проектирование макроструктуры ПО автоматизированных систем (выбор и разработка основных функциональных алгоритмов и структур данных).
- Выбор языков программирования и операционной системы.
- Проектирование микроструктуры ПО автоматизированных систем (разработка спецификаций программ).
- Кодирование (запись программ на языке) и получение носителей.
- Тестирование и отладка.
- Корректировка.
- Оформление документации.
- Сопровождение на объекте.
Последовательность этапов весьма условна, поскольку они являются зависимыми. Ведение документации начинается с первого же шага, т.е. этап является распределенным по всему процессу проектирования. Этап корректировки придает всему процессу проектирования итеративный характер, так как шаги корректируются в зависимости от предыдущего состояния.
В процессе разработки ПО систем автоматизации допускают следующие типичные ошибки:
- Недостаточно полно прорабатывают отдельные подсистемы и неточно определяют связи между этими подсистемами. При этом оказываются нарушенными информационные связи между подсистемами.
- Не учитывают характеристики используемой вычислительной техники: объемы оперативных и внешних ЗУ, ограничения на время работы отдельных подсистем программ. В результате система не в состоянии выполнить все возложенные на нее функции.
- Нечетко определяют цели и функции подсистем.
- Занижают оценки времени и стоимости разработок ПО программируемых логических контроллеров (ПЛК).
- Недостаточно автономно определяют подсистемы,
- Некачественно составляют документацию.
На процесс проектирования ПО большое влияние оказывают различные факторы; от выбранного метода проектирования, размера и вида программ используемою языка до квалификации программистов.
Существуют различные методологии проектирования программного обеспечения, среди которых выделяют: нисходящее проектирование, нисходящее кодирование, бригадный метод проектирования, модульное программирование, структурное программирование.
Нисходящее проектирование систем автоматизации (проектирование сверху вниз). Известны различные названия этого подхода к проектированию программ: систематическое программирование, иерархическое проектирование программ, взрывное проектирование. Суть подхода в определении основных обеспечиваемых функций в переходе к определению дополнительных функций, вытекающих из этих основных. Этот процесс расчленения продолжается до тех пор, пока в результате не получаются примитивы или элементарные операции, аппаратно реализуемые на одной из существующих вычислительных машин. Попытки формализовать этапы нисходящего проектирования нашли свое отображение в руководствах по проектированию, используемых в области автоматизированной обработки данных, как средство организации и управления комплексной разработкой проектов соответствующих систем. Примером может служить методология иерархических диаграмм вход — обработка — выход или сокращенно HIPO, созданная фирмой IBM.
Основное внимание при нисходящем проектировании систем управления технологическими процессами следует обращать на тщательное и формализованное описание интерфейса между верхними уровнями программы и модулями нижнего уровня, ограничение размеров модулей и тщательное проектирование структур данных.
Нисходящее кодирование систем автоматизации (процесс написания кодов программы) базируется на представлении о параллельности различных этапов проектирования программы и кодирования отдельных ее частей. В простейшей форме нисходящего кодирования подразумевается, что написание кодов начинается после полного окончания проектирования программ. Существует другая форма нисходящего кодирования, при которой до начала проектирования следующих уровней, должны быть написаны коды этого верхнего уровня. Такой подход обычно обосновывается следующими соображениями:
- Схемы, структурные диаграммы и другие методы представления часто оказываются недостаточными средствами для описания проекта. Во многих случаях программный код оказывается более точным, адекватным и удобным.
- В процессе кодирования могут быть вскрыты те или иные трудности проектирования логики более низких уровней программы. Чем раньше происходит осознание их существования, тем легче их устранить.
- Нисходящее кодирование упрощает нисходящее тестирование. Существуют два основных способа расположения модулей в листинге
программы:
Бригадный метод проектирования автоматизированных систем (метод главного программиста), разработанный специалистами фирмы IBM, заключается в сочетании идей структурного программирования, нисходящего проектирования с идеей использования супер, программистов: один высококвалифицированный программист может выполнить работу группы из пяти, а то и десяти человек. Для осуществления вспомогательных операций (перфорация и т. п.) а также для оказания помощи суперпрограммисту в технических аспектах (тонкости языка программирования, конкретной операционной системы, определенной системы доступа к файлам) привлекаются соответствующие специалисты.
Руководитель проекта при такой организации разработки отвечает за решение финансовых, административных, юридических вопросов, а главный программист— за технические вопросы. Авторы метода прослеживают аналогию с хирургической бригадой, в которой главный программист играет роль, аналогичную роли оперирующего хирурга. Члены бригады при этом скорее ассистируют главному специалисту, чем независимо пишут составные части. Главный программист отвечает за детальную разработку системы, он целиком пишет важнейшие элементы системы, определяет разбиение на подсистемы и способ их объединения.
Существенную роль в бригадном методе играет библиотекарь, отвечающий за точность и сохранность записей, сопровождающих разработку, и контролирующий развитую систему библиотечных процедур, предназначенную для избавления программистов от рутинной работы.
Библиотека состоит из четырех разделов:
- Внутренняя библиотека, содержащая воспринимаемые машиной исходные программы, перемещаемые модули, объектные модули, операторы редактирования связей, тестовые данные.
- Внешняя библиотека, содержащая текущее состояние листингов всех программ, а также листинги последних фиксированных версий программ.
- Набор машинных процедур, включающий всю информацию, необходимую для обновления библиотек, выполнения тестовых пусков, компиляции модулей, редактированию связей и хранению объектной программы.
- Набор формальных процедур, точно определяющих правила внесения изменений в исходные программы, использования машинных процедур, обновления листингов и файлов внешней библиотеки, образования файлов и замены данных в архивах последних версий программ.
Библиотекарь систем управления технологическими процессами может запретить программистам, включая главного программиста проводить действия, не выполнив стандартные библиотечные процедуры.
При вышеописанной организации разработки производительность труда программистов по данным превышала среднюю в четыре-пять раз и достигала в среднем 65 отлаженных команд на программиста в день и 35 команд на каждого члена бригады. В настоящее время можно указать следующую специализацию программистов:
Алгоритмисты систем управления технологическими процессами (методисты, конструкторы) программною проекта в целом обеспечивают принципиальную реализуемость и концептуальную целостность проекта, а не его реализацию. Алгоритмиста может не интересовать, на какой машине реализуется проект, но выбор метода решения, математические характеристики его (точность, сходимость и пр.), методика разбиения системы на части и связь между ними, обеспечивающие заданные тактико-технические требования к проекту, полностью относятся к компетенции алгоритмиста. Результатами работы алгоритмиста являются подробные спецификации системы в целом и отдельных ее частей. В некоторых случаях результатами могут быть отдельные стандартные модули системы и некоторое множество тестов, полученных в процессе проектирования и моделирования проекта.
Системные программисты систем управления технологическими процессами осуществляют собственно реализацию проекта на соответствующей машине с учетом документации, выработанной алгоритмистами.
Отладчики систем управления технологическими процессами отвечают за генерацию контрольных примеров и организацию процесса проверки системы (они должны работать независимо от системных программистов).
Технологи систем управления технологическими процессами отвечают за исправную работу и изготовление инструментального программного обеспечения, а также ведут учебно-консультационную работу с разработчиками по его использованию и правильной эксплуатации.
Контрологи автоматизированных систем обеспечивают однозначное толкование исходных спецификаций, входных данных, языков, а также контроль за графиком разработки и прием результатов работы на всех этапах реализации проекта.
Документологи автоматизированных систем осуществляют контроль за документированием разработки и окончательного программного продукта, а также осуществляют окончательное редактирование и выпуск документации. Документолог совместно с отладчиком отвечает за выпуск проверочного набора тестов всей системы, а также за работоспособность тех примеров, которые вошли в технические описания и инструкции.
Интерологи автоматизированных систем отвечают за проведение опытной эксплуатации и тиражирование системы. На начальных этапах работы алгоритмистов интерологи отвечают за то, чтобы принципы, закладываемые в разрабатываемую систему, не противоречили принципам ее удобной эксплуатации. На последующих этапах разработки интерологи, с одной стороны, дублируют заказчика, оппонируя все принимаемые решения с точки зрения технологичности последующей эксплуатации системы, а с другой —они принимают непосредственное участие в ее разработке, чтобы квалифицированно и независимо от разработчиков провести опытную эксплуатацию системы. Квалификация интерологов должна быть достаточной, чтобы по результатам опытной эксплуатации системы самостоятельно устранить все замеченные недостатки вплоть до полной перекомпоновки системы. Опыт показывает, что наличие самостоятельного звена интерологов между разработчиками и пользователями позволяет сократить этап ввода системы в эксплуатацию, а также упрощает и сокращает процесс учета замечаний пользователя по улучшению системы. Интеролог менее инерционен и консервативен к модернизации системы, чем ее разработчик.
Модульное программирование автоматизированных систем. Модульное ПО систем управления технологическими процессами такое, в котором любую часть логической структуры можно изменить, не вызывая изменений в остальных частях.' Одним из определяющих свойств является размер модуля. Полагают, что модуль должен быть ограничен 50—200 операторами. Другим свойством является независимость по отношению к таким факторам, как логическая структура ПО (алгоритм работы системы), аргументы (параметры) модуля, константы, структура и формат базы данных, модульная структура управления программой. Фиксируя эти факторы, можно установить независимость отдельных модулей. При определении интерфейсов между модулями модуль можно заменить альтернативным (функционально эквивалентным т. е. вырабатывающим те же значения выходных данных при поступлении одинаковых входных данных). На конструкцию модуля обычно налагается следующее ограничение: «один вход — один выход», т. е. модульная программа должна состоять из модулей, которые имеют одну точку входа и одну точку выхода. Модуль не может изменять команды, другого модуля. К достоинствам модульных программ относятся:
- легкость составления и отладки (функциональные компоненты программы пишут и отлаживают порознь);
- легкость сопровождения и модификации;
- возможность распределения модулей между программистами различной квалификации в соответствии с уровнем сложности.
Однако широкому распространению принципа модульности систем управления технологическими процессами препятствуют следующие факторы:
- отсутствие четкого определения понятия модульности, отсюда отсутствие у большинства программистов понимания смысла модульности;
- модульность требует большой дополнительной работы;
- повышение затрат вычислительных ресурсов системы (время центрального процессора и память);
- возникновение проблемы синхронизации.