Logo Море(!) аналитической информации!
IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware
Обучение от Mail.Ru Group.
Онлайн-университет
для программистов с
гарантией трудоустройства.
Набор открыт!
2010 г.

Как получить бездефектную систему?

Сергей Кузнецов

Обзор сентябрьского 2009 г. номера журнала Computer (IEEE Computer Society, V. 42, No 9, Сентябрь 2009).

Авторская редакция.
Также обзор опубликован в журнале "Открытые системы"

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

Первая из них называется «Бездефектные системы: да, мы можем добиться этого!» («Faultless Systems: Yes We Can!») и написана Жаном-Реймондом Эбриэлем (Jean-Raymond Abrial, Swiss Federal Institute of Technology, Zurich, Switzerland ).

Статья умышленно названа провокационным образом. Все знают, что бездефектные системы невозможны, иначе их давно бы производили. И что такое «дефект»?

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

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

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

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

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

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


Рис. 1. Три взаимодействующие дискретные системы переходов

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

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

Авторами следующей статьи являются Сью Блэк, Пол Бока, Джонатан Боуен, Джейсон Горман и Майк Хинчи ( Sue Black, University of Westminster, Paul P. Boca, Hornbill Systems, Ltd, Jonathan P. Bowen, Museophile Ltd, Jason Gorman, Codemanship Ltd, Mike Hinchey, University of Limerick, Ireland). Статья называется «Формальные и быстрые методы: выживут наиболее пригодные?» («Formal Versus Agile: Survival of the Fittest?»).

Инженерия программного обеспечения как отдельная дисциплина прошла в своем развитии несколько фаз. Барри Боем (Barry Boehm) в своем недавнем обзоре отмечает:

  • переход от инженерии аппаратного оборудования в 1950-е гг. к кустарному программированию в 1960-е гг.;
  • введение формализованности и каскадного процесса (waterfall process) разработки программного обеспечения в 1970-е гг.;
  • появление приемов повышения производительности и масштабируемости труда программистов в 1980-е гг.;
  • введение параллельных процессов (concurrent process) разработки в 1990-е гг.;
  • и возникновение быстрых (agile) процессов в 2000-е гг.
Каждая следующая фаза оказывалась развитием предыдущей фазы или реакцией на ее недостатки.

По утверждению авторов, появление формальных методов следует связывать с работами Чарльза Бэббиджа (Charles Babbage) и Ады Лавлейс (Ada Lovelace) над разностными и аналитическими машинами. Понятие корректности присутствовало уже на этой доэлектронной фазе – Бэббидж писал о «верификации формул, размещенных на технологических картах». Алан Тьюринг (Alan Turing) одним из первых воспользовался формальными методами в своей статье о корректности программ. Однако в терминологию инженерии программного обеспечения формальные методы вошли только в 1970-е гг.

По сравнению с формальными методами, методология быстрой разработки (agile methods) сравнительно нова. В 2001 г. в Agile Manifesto (http://agilemanifesto.org) были выдвинуты четыре основных принципа этого подхода: реагировать на изменения важнее, чем следовать плану; люди и их взаимодействие важнее процессов и средств; работающее программное обеспечение важнее исчерпывающей документации; сотрудничество с заказчиком важнее обсуждения условий контракта.

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

Сравнительно недавно возникло направление исследований по интеграции формальных и быстрых методов. На прошедшем в 2003 г. Первом Южноевропейском симпозиуме по формальным методам обсуждались новые формальные методы, интеграция формальных и быстрых методов и проблемы оценки «быстроты» формальных методов.

Последняя статья тематической подборки представлена Бертраном Мейером, Арно Фивой, Илинкой Чупа, Андреасом Лейтнером, Йи Веем и Эммануэлем Стапфом (Bertrand Meyer, Arno Fiva, Ilinca Ciupa, Andreas Leitner, Yi Wei, ETH Zurich (Swiss Federal Institute of Technology), Zurich, Switzerland, Emmanuel Stapf, Eiffel Software) и называется «Программы, которые сами себя тестируют» («Programs That Test Themselves»).

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

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

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

AutoTest – это набор инструментальных средств, которые автоматизируют процесс тестирования на основе использования программ, содержащих приспособления для своей собственной верификации. Эти приспособления имеют форму контрактов – спецификаций классов и их методов. Три основных компонента AutoTest затрагивают взаимосвязанные аспекты тестирования:

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

Эти механизмы, исходно разработанные в ETH Zurich для исследовательских целей, теперь интегрированы в среду EiffelStudio. Доступен как их вариант с открытыми кодами, так и коммерческий продукт. Продолжаются исследования теории и методов.

Первую из трех статей, не входящих в тематическую подборку, – «Динамическая конфиденциальность при общественных видеонаблюдениях» («Dynamic Privacy in Public Surveillance») – написали Саймон Монкрайф, Света Венкатеш и Джеф Вест (Simon Moncrieff, Svetha Venkatesh, Geoff A.W. West, Curtin University of Technology).

В последние годы среди исследователей происходило много обсуждений относительно конфиденциальности и ее влияния на повсеместную компьютеризацию. Хотя никто не спорит с тем, что поддержка конфиденциальности в системах «вездесущного компьютинга» (ubiquitous computing) необходима, эта область все еще находится в зачаточном состоянии. В нескольких разрабатываемых системах этого рода защита конфиденциальности реализуется, но сравнительно редко речь идет о системах, в которых, по-видимому, впервые были использованы идеи вездесущного компьютинга, – в системах наблюдения. Наиболее известна система Privacy Protected Video Surveillance (Privacy Cam), разработанная Эндрю Сениором (Andrew Senior) и его коллегами.

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


Рис. 2. Более всего телевизионные системы с закрытой передачей распространены в Великобритании

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

Авторами статьи «Применение принципов Парнаса на новом уровне: разработка декларативного языка» («Taking Parnas’s Principles to the Next Level: Declarative Language Design») являются Дэниэль Кук и Дж. Нельсон Раштон (Daniel E. Cooke, J. Nelson Rushton, Texas Tech University).

В течение последних 17 лет авторы экспериментировали с декларативными подходами к организации вычислений над нескалярными значениями. Эти исследования завершились теоретическими результатами, приведшими к разработке языка SequenceL. Этот язык полон по Тьюрингу и компактен (12 грамматических правил по сравнению c более чем 120 в языке Java), а семантика языка основывается на двух вычислительных законах CSP-NT: «потребляй-упрощай-производи» (consume-simplify-produce) и «нормализуй-преобразуй» (normalize-transpose). За это время было разработано около десятка интерпретаторов и четыре кодогенератора для компиляции SequenceL в C и C++. SequenceL-код всех примеров, приводимых в этой статье, был пропущен и проверен на интерпретаторе SequenceL.

Один из последних кодогенераторов использовался для приложений дистанционного наведения, навигации и управления в симуляторе NASA шатла и пилотируемого космического аппарата Orion. Генератор код SequenceL обеспечивает производительность рабочих программ, сравнимую с производительностью тех же приложений, написанных инженерами NASA вручную. В лучших случаях откомпилированные SequenceL-программы выполняются быстрее своих двойников на C; в худших – проигрывают им в производительности в 2,1 раза. В настоящее время один из интерпретаторов перерабатывается с целью генерации многопотокового кода для многоядерных процессоров.

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

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

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

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

Последняя большая статья номера называется «Обеспечение безопасности в небесах: мы верим в требования» («Securing the Skies: In Requirements We Trust»). Ее авторами являются Башар Нузейбех, Чарльз Хейли и Крейг Фостер (Bashar Nuseibeh, Charles B. Haley, Open University, Milton Keynes, UK, Craig Foster, NATS).

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

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

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

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

Новости мира IT:

Архив новостей

Последние комментарии:

Релиз ядра Linux 4.14  (6)
Пятница 17.11, 16:12
Apple запустила Pay Cash (2)
Четверг 09.11, 21:15
Loading

IT-консалтинг Software Engineering Программирование СУБД Безопасность Internet Сети Операционные системы Hardware

Информация для рекламодателей PR-акции, размещение рекламы — adv@citforum.ru,
тел. +7 985 1945361
Пресс-релизы — pr@citforum.ru
Обратная связь
Информация для авторов
Rambler's Top100 TopList liveinternet.ru: показано число просмотров за 24 часа, посетителей за 24 часа и за сегодня This Web server launched on February 24, 1997
Copyright © 1997-2000 CIT, © 2001-2015 CIT Forum
Внимание! Любой из материалов, опубликованных на этом сервере, не может быть воспроизведен в какой бы то ни было форме и какими бы то ни было средствами без письменного разрешения владельцев авторских прав. Подробнее...