Публикации на тему встроенных систем

[Dale]

Schreiner A.
Object-oriented programming with ANSI C.
1993.

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

Как видно из названия, книга посвящена объектно-ориентированному программированию на языке ANSI C. Тема, прямо скажем, не слишком популярная в компьютерной литературе. При этом ее актуальность для проектирования firmware микроконтроллеров трудно переоценить: качеству программного обеспечения для встроенных систем очень часто уделяется даже меньше внимания, чем при разработке обычных программ (хотя порой бывает нелегко уделить его еще меньше). Применение объектно-ориентированной парадигмы позволило бы поднять качество продукта, но зачастую влечет за собой накладные расходы, выходящие за пределы возможностей микроконтроллеров начального уровня. Написание объектно-ориентированных программ на "чистом" стандартном "С без плюсов" может стать довольно привлекательным компромиссом между качеством и эффективностью кода.

Книга произвела на меня неоднозначное впечатление. С одной стороны, предложенные автором механизмы позволяют писать достаточно выразительные программы: в нашем арсенале появляются три главных кита - инкапсуляция, наследование и полиморфизм; также в некоторых примерах без труда можно узнать знакомые паттерны GoF, хотя автор их и не упоминает явно: Visitor, Observer и некоторые другие. С другой стороны, на мой взгляд, автор несколько смещает акцент в сторону позднего связывания и динамического поведения своей реализации объектной модели. Возможно, это придает модели большую гибкость, но за это придется платить невозможностью отловить некоторые виды ошибок на этапе компиляции. Следовательно, повышается трудоемкость тестирования такого кода. Также мне не понравился механизм работы с исключениями; механизм, описанный в статье "Обработка исключений на языке C", на мой взгляд выглядит куда привлекательнее, хотя и не является объектно-ориентированным.

Безусловно, книга представляет немалый интерес и заслуживает прочтения. Однако отнеситесь к ней критически и не пытайтесь в точности копировать авторский код; возможно, найдется решение получше. Впрочем, с выхода книги в свет прошло без малого два десятилетия, поэтому на судите строго, если какие-то предлагаемые в ней решения покажутся сегодня наивными.

[Dale]

Michael Karlesky, Greg Williams, William Bereza, Matt Fletcher.

Mocking the Embedded World: Test-Driven Development, Continuous Integration, and Design Patterns.

Atomic Object, 941 Wealthy Street SE, Grand Rapids, MI 49506.
URL: http://www.atomicobject.com/files/ESC-413Paper_KarleskyWilliams.pdf

Embedded Systems Conference Silicon Valley (San Jose, California).
ESC 413, April 2007.

Еще одна замечательная статья (доклад на конференции по встроенным системам в Кремниевой долине) от уже известной нам команды из Atomic Object, посвященная цивилизованным методам разработки firmware (хотя, говоря по совести, столь отточенная методология сделала бы честь любой команде разработки ПО любого направления).

Несмотря на небольшой объем (всего 15 страниц), в статье уместилось множество ценнейшего материала. В центре изложения, как обычно, находится разработка ПО через тестирование (TDD) с активным использованием мок-объектов для более полного покрытия кода тестами. Помимо этого, подробно разобран перспективный паттерн Model-Conductor-Hardware, с которым мы уже имели возможность поверхностно познакомиться в моих переводах. Приведены обзоры мощных (и свободно доступных) инструментов для тестирования - Unity, CMock, Systir; на практических примерах показано их применения для различных видов тестирования - модульного, интеграционного, системного. Не обойдена стороной и тема непрерывной интеграции (CI), которая занимает все более заметную роль в процессах производства ПО.

Я вообще питаю слабость к теме качества ПО в целом и firmware в частности. Подобные статьи составляют золотой фонд моей подборки литературы.

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

[Dale]

Dr. Robert Koss, Jeff Langr.

Test Driven Development in C.

C/C++ Users Journal — October 2002.

URL: http://www.drdobbs.com/cpp/test-driven-development-in-cc/184401572

Еще одна статья о том, как совместить то, что долгое время считалось несовместимым: TDD, программирование на C и разработку firmware.

Описаны проблемы, возникающие при попытке разработки программ на C по методологии "разработки, управляемой тестированием", главной из которых для процедурных языков является отсутствие объектно-ориентированных средств в целом и полиморфизма в частности. Указаны способы их решения, например, "статический полиморфизм" на стадии компоновки исполняемого модуля.

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

Как жаль, что подобные статьи не попадались мне пару лет назад... Масса времени не была бы потрачена впустую.

P.S. Первоначальная ссылка утратила актуальность, заменил на действующую.

[Dale]

Adam Dunkels, Oliver Schmidt, Thiemo Voigt

Using Protothreads for Sensor Node Programming

Proceedings of the REALWSN'05 Workshop on Real-World Wireless Sensor Networks, Stockholm, Sweden, June 2005.

URL: http://www.sics.se/~adam/dunkels05using.pdf

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

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

Предлагается реализация протопотоков на основе уже знакомой нам машины Даффа, описанной в статье Саймона Тэтхема. Реализация сделана на ANSI C без использования каких-либо дополнительных средств.

Материал статьи будет полезен разработчикам систем обработки информации на основе микроконтроллеров без встроенной ОС реального времени.

[Dale]

Daniel Graziotin

Introduction to Software Testing. Elements and Concepts.

URL: http://task3.cc/wp-content/uploads/2011/04/Introduction_to_software_testing.pdf

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

Для матерых профи, конечно, этот материал вряд ли станет откровением; но если вы делаете только первые шаги в тестировании, он поможет получить общее представление о предмете и понять, куда двигаться дальше.

[Dale]

Adam Dunkels, Oliver Schmidt, Thiemo Voigt, and Muneeb Ali.

Protothreads: Simplifying Event-Driven Programming of Memory-Constrained Embedded Systems.

Proceedings of the Fourth ACM Conference on Embedded Networked Sensor Systems (SenSys 2006), Boulder, Colorado, USA, November 2006.

URL: http://www.sics.se/~adam/dunkels06protothreads.pdf

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

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

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

Сравнение производится по многим критериям: наглядность исходного кода, объем исходного кода (в строках), размер целевого кода (для различных платформ), время выполнения. Указаны достоинства и недостатки каждого подхода.

Статья очень хорошо дополняет документацию по Protothreads.

[Dale]

Simon Raffeiner.

Functionality and Design of the CMock framework.

URL: http://www.verifysoft.com/Functionality_and_Design_of_the_CMock_Framework.pdf

Основное направление статьи - использование продукта CMock для тестирования ПО встроенных микроконтроллеров. CMock представляет собой генератор мок-объектов, предназначенных для более полного тестирования логики приложения в случае, когда это затруднительно сделать с использованием реальных объектов.

CMock не является самодостаточным продуктом. Его следует применять совместно с фреймворком модульного тестирования (в статье для этой цели использован Unity). Кроме того, широко применяется CException - средство работы с исключениями в среде ANSI C.

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

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

Особое внимание уделено повышению качества ПО за счет уменьшения связанности объектов при использовании паттерна MCH (Model-Conductor-Hardware). В этих условиях применение CMock может оказаться особенно продуктивным.

[Dale]

Caspar Gries.

New Trends in the Optimization of C-Code.

URL: http://www.verifysoft.com/C-Code_Optimization.pdf

Рассмотрены некоторые интересные методы оптимизации программного кода вообще и кода на языке C в частности. Некоторые из этих методов показались мне довольно оригинальными. Особенно любопытны методы оптимизации кода для микроконтроллеров.

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

[Dale]

James Grenning.

Embedded Test Driven Development Cycle.

URL: https://forum.shelek.ru/index.php?action=dlattach;attach=7422

Небольшая, но содержательная статья посвящена проблемам использования разработки, управляемой тестированием (TDD), при проектировании встроенных систем.

Автор рассматривает различные подходы к тестированию ПО для встроенных систем: тестирование на компьютере разработки (обычно IBM PC), на эмуляторах и на целевой системе. Проанализированы достоинства и недостатки каждого подхода, даются рекомендации по их совместному использованию с целью преодолеть недостатки и проявить достоинства каждого из них.

Для чтения статьи требуется предварительное знакомство с предметом, поэтому рекомендую ее подготовленным читателям. Тем, кто впервые сталкивается с данной темой, советую предварительно ознакомиться с другими статьями из этого обзора.

[Dale]

Tim Mackinnon, Steve Freeman, Philip Craig.

Endo-Testing: Unit Testing with Mock Objects.

URL: http://connextra.com/aboutUs/mockobjects.pdf

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

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

Хорошим выходом из этой ситуации является применение мок-объектов (МО). Применение МО позволяет произвести полное тестирование компонента, не пожертвовав при этом инкапсуляцией. Кроме того, применение МО стимулирует к программированию с использованием интерфейсов, что в конечном итоге уменьшает связанность компонентов и тем самым улучшает качество кода.

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

[Dale]

James Grenning.

Extreme Programming and Embedded Software Development.

URL: http://www.objectmentor.com/resources/articles/EmbeddedXp.pdf

Разработка встроенного ПО имеет свои особенности по сравнению с обычным ПО. Разработка обычно ведется на компьютере с иной архитектурой, чем целевое оборудование. Привычный человеко-машинный интерфейс отсутствует. Возможны проблемы с организацией распараллеливания потоков. Сам встроенный компьютер может быть спрятан от пользователя. Ресурсы обычно ограничены, особенно объем памяти и производительность. Это увеличивает сложность разработки.

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

Использование экстремального программирования (XP) позволяет начать работу одновременно со стартом проекта, задолго до готовности оборудования. При этом максимум внимания уделяется написанию хорошо протестированного кода.

XP подразумевает инкрементную разработку ПО, когда на каждом шаге реализуется одна простая функция наиболее простыми средствами, которая затем интегрируется в продукт. В основе процесса лежат "пользовательские истории", которые реализуются до тех пор, пока в итоге не получится продукт, пригодный к поставке.

Пока оборудование не готово, группа разработчиков ПО начинает исследования. Исследуется объем предстоящих работ, задаются границы проекта, определяется направление и составляется план первого релиза. Пишутся все возможные "пользовательские истории", оцениваются усилия по реализации каждой из них. Каждая история должна быть реализуема одним человеком максимум за 2 недели. Если история слишком велика, она разбивается на набор историй меньшего объема. Потребитель принимает непосредственное участие в написании историй.

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

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

Отдельно рассмотрена ситуация, когда требования к системе меняются, и способы адаптации проекта к меняющимся требованиям (собственно говоря, это и есть "конек" XP).

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

[Dale]

Micah Dowty.

Test Driven Development of Embedded Systems Using Existing Software Test Infrastructure.

University of Colorado at Boulder.

URL: http://svn.navi.cx/misc/trunk/docs/papers/embedded-test-driven-development.pdf

Традиционный процесс разработки ПО включает фазы спецификации, проектирования, реализации и тестирования. Рабочая версия продукта появляется в самом конце процесса, при этом зачастую не остается достаточно времени на исправление дефеков, обнаруженных при позднем тестировании.

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

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

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

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

Особый интерес вызывает использование для системного и приемочного тестирования специальной программно-аппаратной среды, интегрированной с системой модульного тестирования на языке Python - pyunit. Это позволило разработчикам писать скрипты для приемочных тестов на языке высокого уровня.

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

[Dale]

Robert Martin.

Beware of C hackers.

URL: http://www.objectmentor.com/resources/articles/bewareCHackers.html

Поскольку язык C сегодня однозначно ассоциируется для меня с разработкой firmware, счел уместным добавить эту статью в свой обзор.

Как вы относитесь к холиварам? Лично я - неоднозначно, в зависимости от того, кто именно холиварит. Поскольку в подавляющем большинстве случаев в холиварах коротают время люди пустые и недалекие, холивары получаются столь же унылые и бестолковые. Но иногда (как в данном случае) в холиваре сходятся яркие и неординарные личности, и тогда получается шоу, достойное Соловьева с его "Поединком".

Данная заметка представляет собой ответ многоуважаемого дядюшки Роба Мартина на фрагмент из книги не менее уважаемого Бертрана Мейера "Object Success". Фрагмент недвусмысленное имеет заглавие: "PRUDENT HIRING PRINCIPLE: Beware of C hackers". В нем Мейер настоятельно не рекомендует принимать на работу над серьезными проектами в больших командах людей, поднаторевших в низкоуровневом пограммировании на языке C со всеми его уловками и выкрутасами. Эта позиция не голословна, автор приводит вполне убедительные доводы в обоснование своей точки зрения.

В свою очередь Мартин не менее убедительно утверждает, что плохие программы можно с приблизительно равным успехом писать на любом языке, а соблюдение определенных принципов позволяет писать на C весьма качественные продукты. Кроме того, его заботит, что стереотип может въесться в мозг менеджерам, осуществляющим набор персонала, и тогда упоминание "сишного прошлого" в резюме может стать препятствием в карьере разработчика.

В отличие от Полиграфа Полиграфовича, не согласного ни с Энгельсом, ни с Каутским, я в данном случае согласен одновременно с обоими спорщиками, несмотря на то, что они утверждают совершенно противоположные вещи. Редкий случай.

Здесь находится небольшое обсуждение этой заметки.

[Dale]

James W. Grenning.

Why are you Still Using C?

URL: http://www.objectmentor.com/resources/articles/WhyAreYouStillUsingC.pdf

Опрос, проведенный Embedded.com, показал, что 68% респондентов используют для разработки встроенного ПО язык С. По какой причине они предпочитают C, а не C++? Частично это объясняется доступностью инструментальных средств. Но помимо этого многие разработчики даже не подозревают, какие возможности открывает перед ними объектно-ориентированный подход.

Когда Бьярн Страуструп разрабатывал C++, он планировал, что C++ останется столь же низкоуровневым языком программирования, что и C. Основополагающим принципом был: "вы не должны платить за то, чем не пользуетесь". Это означает, что если вы откомпилируете ваш код, написанный на C, компилятором C++, у вас не должно быть никаких дополнительных накладных расходов, кроме стоимости нового компилятора. Если же используются какие-то средства C++, нужно четко сознавать, во что это обойдется.Главное при оценке накладных расходов - руководствоваться фактами, а не слухами и домыслами.

Мир полон слухов о медленных программах на C++, требующих массу памяти и тратящих ее на многочисленные "утечки". Но плохие программы делают не компиляторы, а программисты. В C++ есть масса полезных вещей: инкапсуляция, наследование, полиморфизм, обработка исключений, шаблоны, стандартная библиотека... Все они имеют свою определенную цену.

Инкапсуляция возможна и на "чистом C без плюсов", но мало кто ее реально использует, поскольку сам язык не слишком поощряет это. Для C++ инкапсуляция - это средство самого языка. Использование инкапсуляции позволяет строить цельные объекты по принципу единой ответственности Мартина (хотя и не гарантирует его соблюдение автоматически). Плата за инкапсуляцию (небольшая) - скрытый параметр функций-членов класса, указывающий на экземпляр (кроме функций in-line). Эта цена в большинстве случаев вполне окупается существенным улучшением архитектуры программы.

Объектно-ориентированное проектирование позволяет разделить приложение на слабо связанные объекты с четко определенными интерфейсами. При правильном использовании этой методики получаются лучше структурированные и более понятные программы, чем в случае структурного подхода. Хорошо спроектированные объекты следуют принципу Мейера: они открыты для расширений и закрыты для модификации.

Полиморфизм позволяет уменьшить "жесткость" статической логики программы за счет определения поведения программы на этапе выполнения. Достигается это косвенным вызовом виртуальных функция через соответствующую таблицу. За это приходится платить как небольшим увеличением времени работы (за счет косвенного вызова), так и дополнительной памятью (для хранения таблицы виртуальных методов). Эта цена может оказаться не такой уж высокой с учетом существенного упрощения логики приложений.

Подчас репутация C++ страдает из-за того, что он услужливо выполняет за вас некоторые весьма дорогостоящие операции (например. передачу громоздких объектов по значению). Есть способы надежно защититься от этой непрошенной помощи, например, объявив закрытый конструктор копирования для таких классов. Аналогично можно защититься от возврата объекта по значению.

Резюме автора: программисты используют C++ для встроенных разработок намного реже, чем следовало бы, причем это связано не с объективными недостатками языка и/или компилятора, а скорее с незнанием и склонностью верить ничем не подтвержденным слухам.

Любопытная точка зрения, появилось искушение попробовать лично...

[Dale]

Tony Gray.

Design for Debugability.

URL: http://www.eetimes.com/design/embedded/4024475/Design-for-Debugability

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

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

[Dale]

Jack Ganssle.

How to Become an Embedded Geek.

URL: http://www.ganssle.com/startinges.htm

Перед теми, кто хотел бы выбрать путь разработчика встроенных систем, встает нелегкий вопрос: с чего начать? Оказывается, этот вопрос не менее актуален и в Соединенных Штатах, где образование, казалось бы, должно по определению быть более гибким по сравнению с нашим, изрядно бюрократизированным.

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

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

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

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

[Dale]

Michael Barr.

How to enforce coding standards automatically.

URL: http://www.eetimes.com/discussion/barr-code/4218283/How-to-enforce-coding-standards-automatically?Ecosystem=embedded

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

Единственный способ заставить команду следовать выбранным стандартам кодирования - максимально автоматизировать процесс контроля. В идеале в репозиторий должен попадать лишь код, прошедший все автоматические проверки. Не стоит также допускать  до обзора код, не прошедший автоматические проверки. В этом случае участники обзора не отвлекаются на второстепенные детали и фокусируются на: 1) что должен делать модуль, 2) делает ли он это безопасно и правильно и 3) понятны ли код и комментарии к нему всем членам команды.

Если позволяет бюджет проекта, самый простой и эффективный способ - применить навороченные коммерческие инструменты статического анализа кода (например, LDRA Technology's static analysis engine). Они позволяют автоматически проверять соблюдение до 80% правил стандарта. Для малобюджетных проектов есть инструменты подешевле (PC-Lint, RSM). Помимо нарушений стандарта, статические анализаторы способны также находить множество ошибок в программах, не противоречащих синтаксису языка и потому не выдающие ошибок/предупреждений при компиляции.

Резюме статьи: чтобы стандарт реально приносил пользу, его нужно строго соблюдать. Чтобы стандарт строго соблюдался, нужны автоматизированные инструменты для поддержки и контроля его соблюдения.

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

[Dale]

Boydens J., Cordemans P., Steegmans E.

Test-Driven Development of Embedded Software.

URL: https://lirias.kuleuven.be/bitstream/123456789/264989/1/TestDrivenDevelopmentofEmbeddedSoftware.pdf

Попытки применения TDD к разработке встроенных систем сталкиваются с рядом трудностей, среди которых наиболее существенными являются жеская привязка к оборудованию и неготовность аппаратных средств к моменту начала разработки ПО. Задержки с разработкой оборудования вынуждают откладывать тестирование на поздние сроки проекта. При этом тестирование производится нерегулярно и часто заменяется отладкой, а порой и вовсе игнорируется.

Процесс разработки, управляемый тестированием, позволяет повысить качество продукта. "Традиционная" разработка встроенного ПО ориентирована на "водопадную" модель. По методологии TDD встроенное ПО разрабатывается сначала на основе виртуальных драйверов. Уменьшить зависимость ПО от оборудования можно посредством программирования через интерфейсы. Тогда для тестирования бизнес-логики можно заменить настоящие драйверы оборудования подставными (виртуальными). За счет использования интерфейсов добавляется уровень косвенности, позволяющий впоследствии, когда ПО станет стабильным, заменить виртуальные драйверы реальными. После этого можно провести тестирование самой встроенной системы.

При использовании TDD акцент с реализации ПО смещается на интерфейс и наблюдаемое поведение модуля. Поскольку тесты строятся на основе интерпретации спецификаций, недоразумения выявляются на ранних стадиях проекта. Чем раньше обнаружена ошибка, тем дешевле обходится ее исправление.

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

Паттерн Model-Conductor-Hardware позволяет изолировать оборудование и бизнес-логику друг от друга. С целью тестирования создаются мок-версии компонентов. Паттерн непосредственно реализуется на целевой системе. Весь процесс полностью поддается автоматизации; мок-объекты генерируются автоматически специальным скриптом на основании интерфейса модуля.

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

   

[Dale]

Mark VanderVoord (contributed by Matt Wilbur).

When Bad Code Runs Green.

URL: http://throwtheswitch.org/white-papers/when-bad-code-runs-green.html

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

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

P.S. Откровенно говоря, у меня возникло впечатление, что в данном конкретном случае ошибка могла быть обнаружена достаточно строгим статическим анализатором текста (например, Splint) даже без всякого тестирования; впрочем, проверить сейчас недосуг. Однако это нисколько не умаляет ценности урока в общем.

[Dale]

Tim Ottinger, Jeff Langr

How Virtuous Is Your Code?
URL: http://pragprog.com/magazines/2011-08/how-virtuous-is-your-code

Статья опубликована в журнале PragPub, в номере за август 2011. В ней продолжается вечная тема о том, какой код следует считать хорошим, а какой, мягко говоря, не очень. Казалось бы, после МакКоннелла, Мартина и других корифеев сказать на эту тему больше нечего. Тем не менее статью прочитал с большим удовольствием.

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

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

[Dale]

Paul D. Smith.

How Not to Use VPATH.

URL: http://make.paulandlesley.org/vpath.html

Небольшая статья о некоторых тонкостях использования переменной VPATH при работе с GNU make. Продемонстрированы ловушки, в которые легко может попасть новичок и выбраться из которых не так легко, учитывая невразумительную диагностику make.

Рекомендую всем, кто не относит себя к экспертам по GNU make.

[Dale]

Philippe Kruchten.

Architectural Blueprints — The “4+1” View Model of Software Architecture.

Paper published in IEEE Software 12 (6). November 1995, pp. 42-50

URL: http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf

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

Сегодня, 16 лет спустя, эти нотации могут показаться даже наивными. Например, для статической диаграммы классов применена нотация Буча. Однако читатель может получить хорошее представление о том, что же такое архитектура есть на самом деле, поскольку чаще всего этот термин используется крайне расплывчато и спекулятивно.

Кроме того, материал определенно представляет исторический интерес. Гораздо проще понять нынешнее состояние дел, зная, каким путем к нему пришли в свое время.

Рекомендую прочитать хотя бы для общего развития.

[Dale]

Jack Ganssle.

The Embedded Muse 19, March 20, 1998

http://www.ganssle.com/tem/tem19.htm

Выпуск журнала "The Embedded Muse" посвящен вечно актуальной теме дисциплины разработки firmware. Поразил полный резонанс мыслей с автором. Приведу несколько цитат:

Недавно я проводил семинар группе из примерно тридцати разработчиков встроенных систем. Несколько человек из аудитории затеяли оживленную дискуссию о концепциях дисциплины процесса разработки встроенного ПО. Я был весьма удивлен, обнаружив, что небольшая группа поддерживала идею анархического создания firmware. Проектирование? Обзоры? Какое там. Похакерствуй, погляди, что получилось, а затем вноси массу изменений в ходе отладки и интеграции.

В целом сообщество разработчиков firmware гораздо беспечнее относится к программному обеспечению, чем программисты бизнес-приложений. После почти полувековой истории программирования создатели настольных приложений на собственных шишках научились разумным способам создания кода. Не скажу, что они полностью в этом преуспели, но похоже, что формальные приемы настоящей ИНЖЕНЕРИИ программного обеспечения гораздо сильнее превалируют здесь, чем в мире встроенных систем.

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

Дисциплина - вот ключевое слово для эффективной разработки firmware. Научитесь противостоять искушению выбирать столь манящий легкий путь, особенно под давлением сроков.

Удивительно, что статья написана больше десяти лет назад, а противостояние между двумя столь разными подходами продолжается. До сих пор не редкость "творческий подход" к типовым задачам (он же - безграмотность и незнание типовых решений), полное безразличие к качеству, тяга к анархии и прочие прелести "социального программирования", которые просачиваются и в гораздо более ответственный мир firmware.

[Dale]

Jack Ganssle.

A Dirty Word.

URL: http://www.ganssle.com/tem/tem66.htm

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

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

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

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

Статья опубликована в 66-м выпуске онлайн-журнала для разработчиков встроенных систем "The Embedded Muse".

[Dale]

Yichen Xie, Dawson Engler.

Using Redundancies to Find Errors.

URL: http://www.stanford.edu/~engler/p401-xie.pdf

В статье изложены результаты весьма любопытного исследования, проведенного в лаборатории компьютерных систем Стендфорского университета (Калифорния).

Предметом исследования явились исходные тексты ОС Linux в объеме порядка 1.600.000 строк. Авторы искали в них избыточные фрагменты кода (присвоение значения переменной самой себе, присвоение значений неиспользуемым переменным, "мертвый" код, условные операторы, условия которых заведомо никогда не выполняются, и т.п.).

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

Не буду пересказывать всю статью и тем самым лишать читателей удовольствия ознакомиться с оригиналом по вышеприведенной ссылке. Поделюсь лишь двумя выводами от ее прочтения:

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

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

[Dale]

Jack Ganssle.

My love-hate relationship with C.

URL: http://eetimes.com/discussion/embedded-pulse/4024881/My-love-hate-relationship-with-C

Статья представляет взгляд признанного эксперта в области программирования встроенных систем на актуальные проблемы этой отрасли, вызванные в основном применением языков C и C++ для написания встроенного кода. Джек указывает главные слабости этих языков, провоцирующие ошибки в программах, и предлагает ряд решений: как минимум - работа с более безопасным подмножеством языка (например, с использованием известных ограничений MISRA), как максимум - переход на надежные языки программирования (Ada, Cyclone).

Рекомендую почитать не только саму статью, но и ее обсуждение, где также отметились некоторые корифеи. Не скажу, что материал очень уж оригинален и выводы неожиданны, но все же пустой тратой времени это чтение никак не будет.

[Dale]

Jack Ganssle.

Code Guardians.

URL: http://www.ganssle.com/tem/tem113.htm

Небольшое, но весьма, на мой взгляд, интересное и поучительное эссе было опубликовано в 113-м выпуске журнала "The Embedded Muse", который Jack Ganssle выпускает для разработчиков встроенных систем с июня 1997 года по сей день.

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

Рекомендую прочитать и принять к сведению всем, для кого показатели качества стоят не на последнем месте.

[Dale]

Jack Ganssle.

Productivity Vs Process.

URL: http://www.ganssle.com/tem/tem115.htm

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

Приведенные данные свидетельствуют о четкой корреляции между ростом уровня исполнителя (в соответствии с CMM) и снижением затрат на производство продукта. Напрашивается вывод, что при разумном использовании процессов отдача от них существенно превосходит накладные расходы. Дело за малым - научиться этому самому разумному использованию.

В заключение автор выражает скорбь по поводу патологической приверженности разработчиков firmware к "социальным"© методикам программирования, которые чаще всего заключаются в отсутствии методик (так называемый "творческий процесс"©). Крепись, Джек, встроенные системы - наиболее консервативная область компьютерных наук.

[Dale]

Doug Putnam.

Exploring the Outer Limits: How much software can be developed in a year?

URL: http://www.qsm.com/Develop_12%20months.pdf

Пожалуй, мало найдется программистов, которых не раздражал бы, казалось, вполне естественный и невинный вопрос заказчика: "Когда будет готова программа?". Вопрос этот весьма непрост. С одной стороны, зачастую довольно объемные проекты начинаются с нуля (или почти с нуля), поэтому трудно что-то прогнозировать заранее. С другой стороны, именно заказчик платит деньги и считает вправе знать, когда будет результат. Неспроста организации, способные сначала качественно спланировать работы по проекту, а затем строго выдержать собственный график, имеют довольно высокие показатели зрелости по шкале CMM. Производительность труда программиста (как в розницу, одиночек, так и оптом, собранных в коллективы) остается одним из самых загадочных вопросов в управлении процессом производства программных продуктов.

В классических работах Боэма, Брукса и т.п. приводится довольно обширная статистика на этот счет; впрочем, эти труды давно поросли тодстым слоем мха: большинство из рассмотренных в них проектах были реализованы на ламповых машинах и ныне забытых языках. Не помешали бы более свежие данные, более подходящие к сегодняшним реалиям.

Doug Putnam, вице-президент компании Quantitative Software Management, Inc., которая специализируется на разработке инструментальных средств для управления процессом разработки ПО, проанализировал имеющиеся в его распоряжении метрики по 6,322 проектам, успешно реализованным в 2000-2001 годах. Переписывать здесь эти данные не буду, поскольку оригинал статьи доступен по приведенной ссылке. Интересующиеся могут ознакомиться с публикацией самостоятельно, она не слишком велика и при этом весьма информативна.

Рекомендую всем инженерам, которым надоело отвечать на вопрос заказчика о сроках готовности продукта малоубедительным "Как только, так сразу", либо называть дату с потолка, а по ее истечении мямлить: "Понимаете, тут такое дело...".

[Dale]

Philip E. Ross.

The Exterminators. A small British firm shows that software bugs aren't inevitable.

URL: http://spectrum.ieee.org/computing/software/the-exterminators/0

Редкая статья, в которой речь идет о качестве программного обеспечения, не констатирует удручающее состояние данной проблемы. Не стала исключением и данная.

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

К счастью, есть организации, которые относятся к проблеме максимально серьезно. Одна из них упоминается в статье (бывшая Praxis High Integrity Systems, нынче Altran Praxis). Эта фирма производит ПО для наиболее ответственных приложений и демонстрирует высочайшее качество продуктов (4 ошибки на 100.000 строк кода, три из которых оказались тривиальными и были исправлены практически мгновенно,а четвертая потребовала 2 дня на исправление; те, кто знаком со статистикой в отрасли, которая дает средние значения от 2 до 10 ошибок на 1000 строк,  не могут не признать, что результат просто фантастический).

Конечно, качество не достается даром. Цена продуктов Praxis приблизительно в полтора раза выше, чем у конкурентов. Впрочем, на мой взгляд, когда речь идет о качестве, торг здесь неуместен. Перефразируя афоризм, выбранный мной в качестве подписи: "Если вы считаете, что качественный софт - это слишком дорого, попробуйте поработать с некачественным". Те, кто не согласен, приглашаются на исправительные работы по снятию крейсера с мели; возможно, в ходе работ они изменят мнение.

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

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