Журнал РАДИОЛОЦМАН, ноябрь 2012
George Novacek, Канада
Circuit Cellar
Статья представляет собой серьезный взгляд на процесс разработки программного обеспечения и программирования. Рассматриваются такие вопросы, как генераторы кода, программы-симуляторы и тестирование.
Большинство инженерных дисциплин зародилось как искусство. Одаренные люди совершенствовали какой-либо навык, зачастую без достаточного понимания заложенных в нем базовых принципов, и успешно применяли его на практике. Хорошим примером является производство стали. Ранее лишь немногие высокооплачиваемые мастера знали секрет выплавки этого материала. Но позже, в середине 19 века, изобретение бессемеровского процесса перевело производство стали в область науки. Потребность в высококвалифицированных ремесленниках исчезла, а цена на сталь резко упала.
Разработка программного обеспечения пошла тем же путем. Первоначально представляя собой область, в которой разбирались лишь несколько гуру, сегодня разработка ПО стала научно обоснованной деятельностью, которой, как хотели бы видеть, в конечном счете, руководители, смогут заниматься обученные обезьяны.
Создатели ПО, в целом, делятся на две категории. Первую представляют разработчики, являющиеся, по сути, творцами, которые находят решения, изобретают новые алгоритмы и, в общем, развивают отрасль. Вторая категория представлена программистами, которые лишь реализуют идеи инженеров, предоставленные им в виде псевдокода, блок-схем или каким-либо другим способом. Они проделывают большую работу по преобразованию этих идей в код. Но это не означает, что инженер и программист не могут быть одним и тем же лицом. В небольших компаниях зачастую так и происходит.
Хотя пока не приходится ожидать, что в ближайшем будущем наука сможет полностью автоматизировать процессы разработки, требующие творческого подхода, (впрочем, уже были попытки) в области разработки ПО она все же достигла значительных результатов, возложив на себя такие монотонные и рутинные задачи, как генерация исходного кода, управление версиями, обнаружение ошибок и тестирование.
Программы автоматической генерации кода
Автоматические генераторы кода, хотя и не такие сложные, как сегодня, появились довольно давно. В середине девяностых я приобрел пакет разработки на основе принципов нечеткой логики. Я так и не воспользовался им, потому что клиенты вздрагивали при слове «нечеткий» и настаивали на применении нашего проверенного временем метода планируемого усиления. Недавно я нашел этот пакет у себя в ящике и решил попробовать его. Я был удивлен тем, что сгенерированный им код был поразительно похож на тот, который мы писали для планируемого усиления, но с одним значительным отличием. С помощью графического интерфейса пакета процесс разработки шел гораздо быстрее.
Со дня своего зарождения автоматические генераторы кода прошли долгий путь. Хорошим примером знакомого мне современного автоматического генератора кода является SCADE (среда разработки приложений для решения критически важных задач приложений безопасности) Suite, разработанный компанией Esterel Technologies. В отличие от большинства других подобных программ, SCADE Suite был официально признан инструментом для разработки приложений, предъявляющих повышенные требования к безопасности до уровня A, включительно, в соответствии со стандартом DO-178B. SCADE применяют в компаниях, в которых разрабатываются приложения для таких отраслей промышленности, как автомобильная, железнодорожная, аэрокосмическая, телекоммуникационная, медицинская, и военная. К таким компаниям отнесятся Dassault, Audi, Boeing, Lockheed, Siemens и Airbus.
Чтобы понять, как работает SCADE, рассмотрим процесс разработки системы управления шасси самолета. Инженеры, проектирующие такую систему, в документе, носящем название System Requirements (требования к системе), указывают, что необходимо для управления ими. После декомпозиции этих требований, когда для встраиваемого контроллера определены требования к ПО и аппаратной части, инженер-программист получает документ Software Requirements (требования к ПО). Рассмотрим две конкретные функции, описанные в этом документе: регулирование угла колеса передней опоры с использованием принципа обратной связи и последовательность выпуска и убирания шасси.
Из документа System Requirements системный инженер берет основные коэффициенты усиления и ограничения для системы управления колесом передней опоры и включает их в документ Software Requirements. Инженер-программист разрабатывает блок-схему программы, которая затем моделируется и отлаживается, при этом значения коэффициентов изменяются при помощи программы-симулятора Simulink компании MathWorks до тех пор, пока работоспособность системы с обратной связью не будет удовлетворять требованиям технического задания. Полученная блок-схема представлена на Рисунке 1. Графическое представление системы управления с обратной связью, показанной на Рисунке 1, становится частью документа Software Design Description (описание процесса разработки ПО).
 |
|
| Рисунок 1. | Блок-схема системы с обратной связью. |
Поведение посадочных шасси самолета определяется конечным автоматом. Как и в случае системы управления с обратной связью, инженер проектирует диаграмму состояний для конечного автомата, которая затем обрабатывается в симуляторе до тех пор, пока не будут получены удовлетворительные результаты. Это также представляется графически, и тоже становится частью документа Software Design Description.
Документ Software Design Description передается программисту, который должен написать исходный код. Когда дело доходит до таких модулей, как система управления с обратной связью или автомат, описывающий поведение шасси, процесс разработки протекает с использованием графического интерфейса пакета SCADE. SCADE, в свою очередь, генерирует исходный код, который затем добавляется в прошивку встраиваемой системы, как правило, в виде вызываемой функции. Во время интеграции аппаратной/программной части некоторые параметры могут нуждаться в корректировке, поскольку в первую очередь они зависят от точности математической модели.
Программы управления конфигурациями
Управление версиями является очень важным моментом в любом процессе разработки. Нет ничего хуже, когда команда программистов работает над разными версиями документов или исходных кодов. Были времена, когда один из моих поставщиков постоянно обновлял ассемблер, не утруждая себя изменением номера версии или, хотя бы, включением информации о модификации файлов. Поскольку каждое изменение версии ассемблера/компилятора влечет за собой повторную проверку критического программного обеспечения, отслеживание версии ассемблера было настоящим кошмаром. Я также был свидетелем того, как один производитель аэрокосмического оборудования из-за своей небрежности потерял управление конфигурациями. Последствия были ужасными. Агентство по выдаче сертификатов вынудило производителя отказаться от результатов работы, проводившейся в течение нескольких месяцев, и вернуться к последней проверенной конфигурации.
Подобных происшествий можно избежать, если разработчик использует программу управления конфигурациями. Среди наиболее известных программ такого рода можно назвать Rational DOORS компании IBM, предназначенную для динамических объектно-ориентированных систем. DOORS представляет собой базу данных, которая отслеживает открытие нескольких документов или файлов с исходным кодом и внесение в них изменений несколькими пользователями и обновляет номер версии в соответствии с изменениями.
Тестирование, верификация и валидация
Другой трудоемкой и рутинной задачей, возложенной на плечи программистов, является процесс тестирования, верификации и валидации. Рассмотрим каждую составляющую этого процесса.
Тестирование – это общий термин, означающий совокупность процедур тестирования модулей, интеграции модулей, интеграции аппаратной и программной части и т.д., в результате которых разработчики убеждаются в том, что код работает, как задумано.
Верификация представляет собой, в значительной степени, бюрократическую задачу. Она дает гарантию, что все требования технического задания были выполнены и могут быть прослежены от документации до исходного кода, при этом каждой строке исходного кода соответствует определенный пункт технического задания. В ходе верификации устанавливаются правила использования стека, оговариваются типы данных, синхронизация при наихудших случаях, предотвращение конфликтов прерываний и т.д. Верификация может быть выполнена на главном компьютере (например, ПК) или на целевой системе. Использование компьютера зачастую представляет собой более удобный вариант. Верификация может одновременно выполняться несколькими программистами без дополнительных затрат на целевые системы.
Процесс верификации также в значительной степени был автоматизирован. Polyspace компании MathWorks представляет собой одну из нескольких программ, позволяющих сложить с плеч программистов такие рутинные задачи.
Наконец, валидация производится на целевой системе, чтобы убедиться в том, что вся система работает как необходимо. Это момент, когда «резина касается дороги», и когда могут быть обнаружены высокоуровневые ошибки технического условия. Как правило, системы, состоящие из механических и электрических частей, не ведут себя в точности так, как модели в симуляторе. Это происходит, главным образом, потому, что в математических моделях невозможно учесть все параметры, особенно те, которые присущи механическим частям. В хорошо спроектированных системах в основном ограничиваются варьированием коэффициентов усиления и границ изменения регулируемых величин. Для встраиваемого ПО хорошей идеей является создание защищенной паролем таблицы, в которой должны храниться все значения, нуждающиеся в возможной корректировке, и к которой можно получить доступ и впоследствии вносить изменения через интерфейс ПК, например USB.
Сегодня разработчикам ПО доступно огромное количество инструментов. В этой статье я упомянул лишь некоторые из них. Я также хочу развеять опасения программистов по поводу потери своих рабочих мест, которые заняли бы обученные обезьяны. Этого пока еще не предвидится. В тоже время, наука продолжит облегчать нашу жизнь, и в наших продуктах будет намного меньше ошибок, допущенных человеком.
