Перед современной IT индустрией стоит непростая задача. Увеличивается количество программных комплексов, призванных решать различные бизнес-задачи, а также увеличивается их сложность. В связи с этим остро встает вопрос о контроле бизнес-требований, предъявляемых к продукту.
Для решения этой задачи в данной статье осуществляется обзор различных методов контроля качества программного обеспечения и предлагается новый подход. Подход объединяет преимущества контрактного программирования для контроля корректности мощь темпоральных логик для описания бизнес-требований.
В данном статье рассмотрены:
– Актуальность проблемы. Необходимость контроля корректности ПО.
– Подходы к автоматизированному контролю корректности ПО.
– Плюсы и минусы каждого подхода.
Далее проведен анализ всех предлагаемых подходов.
На основании проведенного анализа и изложенных результатов сформулированы основные проблемы, мешающие массовому использованию рассмотренных подходов в промышленных масштабах, поставлены задачи и цели данной работы.
При разработке информационных систем очень важно контролировать качество программного обеспечения. Понятие качества программного обеспечения сформулировано стандарте ISO 9126 [1]. На сегодняшний день, действует редакция, принятая в 2001 году. По этому стандарту качество можно рассматривать как совокупность различных аспектов. Совокупность этих аспектов представлена на рисунке 1.
Одним из самых важных аспектов качества, представленных на диаграмме, является функциональность. Функциональность определяет способность ПО решать поставленные задачи. При этом очевидно, что важнейшей характеристикой функциональности является корректность — соответствие создаваемого ПО заданной спецификации. Если ПО не соответствует своей спецификации, то таким продуктом нельзя пользоваться, даже если он надежен, производителен и удобен в использовании.
Контроль корректности ПО может осуществляться двумя способами — вручную и автоматизировано. При ручном контроле корректности огромную роль при получении результата играет человеческий фактор. Чтобы избежать ошибок, возникающих в процессе ручного контроля корректности, используют полную или частичную автоматизацию процесса.
Поэтому важнейшей задачей в IT индустрии является обеспечение автоматизированного контроля корректности ПО.
Рис. 1.
Все подходы к контролю корректности программного обеспечения можно разделить на две большие группы:
- контроль качества программного обеспечения на этапе создания;
- контроль качества программного обеспечения на этапе выполнения.
Подходы из первой группы позволяют проводить анализ корректности работы программного обеспечения еще до его запуска и использования. Такие подходы делятся на три большие группы:
– статический анализ;
– тестирование;
– верификация.
Подходы из второй группы проявляют себя уже после компиляции продукта и старта его использования. Их основной задачей является завершение или приостановка работы программы в случае обнаружения какой-либо критической ошибки. Считается, что гораздо лучше прекратить (или приостановить) выполнение программы, нежели продолжать некорректное выполнение. Также динамический контроль позволяет быстрее находить и устранять ошибки, которые не были выявлены на более ранних этапах.
Критическими ошибками в таких случаях могут служить:
– Нулевое значение знаменателя при выполнении операции целочисленного деления.
– Ошибка при попытке коммуникации с недоступным внешним устройством.
– Исчерпание доступной памяти или переполнение стека.
– Появление сигнала аварийного отключения электропитания системы.
– Нарушение бизнес-требований, заложенных при создании программы. Например, выдача чека с отрицательной суммой заказа. В рамках представленной работы данный пункт является наиболее интересным и будет исследован более подробно.
Такие подходы можно также разделить на три группы, в порядке появления и развития подходов:
– коды ошибок;
– исключения;
– контракты.
Далее перечисленные выше подходы рассмотрены более подробно, а также произведено их сравнение.
Статический анализ используется для поиска часто встречающихся дефектов по некоторым шаблонам. Такой анализ хорошо автоматизируется. Однако он способен обнаружить лишь малое число из всех возможных ошибок.
Большинство техник статической проверки корректности программ, доказавших свою эффективность, рано или поздно становятся частью средств разработки, компиляторов, а иногда преобразуются в семантические правила языков программирования.
Тестирование является динамическим методом проверки программ. Для его проведения необходима работающая система, какой-то ее компонент, либо прототип.
Тестирование позволяет обнаруживать в системе ошибки, проявляющиеся во время работы. Однако, для проведения тестирование необходимо подготовить набор тестов, а иногда разработать саму тестовую систему. И, если тестовую систему еще можно повторно использовать при разработке очередного программного продукта, то набор тестов разработчикам приходится писать каждый раз заново, учитывая особенности и требования конкретной системы. На практике существует множество различных средств, позволяющих частично автоматизировать тестирование. Например, достаточно часто используется вероятностное тестирование, позволяющее быстро проверить корректность работы системы, при подаче ей на вход каких-либо случайных данных.
Существенным недостатком тестирования является то, что оно, как правило, помогает выявить значительное число ошибок, но гарантировать, что система будет работать, корректно не может.
Верификация является статическим методом проверки программы. Верификация относится к формальным методам и применяется только к тем свойствам системы, которые можно выразить с помощью формальной математической модели.
Проблему при данном подходе представляет собой необходимость построения математической модели, а также формальное описание требований, которым эта математическая модель, а, следовательно, и проектируемая система, должны удовлетворять.
Достоинством данного метода может служить тот факт, что верификация гарантирует корректность работы системы по всем проверяемым свойствам, если они успешно прошли проверку на модели.
На рисунке 2 сведены воедино ключевые характеристики всех трех подходов. Каждый подход имеет свои достоинства и недостатки. Однако если рассматривать все эти подходы с точки зрения улучшения корректности ПО, наиболее интересным является подход на основе верификации.
Только верификация позволяет гарантировать корректность работы программы. Именно поэтому верификация программ представляет наибольший интерес на сегодняшний день.
Рис. 2.
Код ошибки — это номер (или сочетания буквы и номера), который соответствует конкретной проблеме в работе программы. Коды ошибок используются для идентификации неправильной работы аппаратного и программного обеспечения, неверного ввода данных пользователем без обработки, возникающей при этом исключительной ситуации в коде программы.
Хотя иногда коды ошибок используются в сочетании с обработкой исключений. Также коды ошибок часто используются вместе с кодами возврата.
Во время выполнения программы могут возникать ситуации, когда состояние данных, устройств ввода-вывода или компьютерной системы в целом делает дальнейшие вычисления в соответствии с базовым алгоритмом невозможными или бессмысленными. В этом случае системе генерирует исключение, уведомляя пользователей о возникновении такой ситуации.
В отсутствие собственного механизма обработки исключений для прикладных программ наиболее общей реакцией на любую исключительную ситуацию является немедленное прекращение выполнения с выдачей пользователю сообщения о характере исключения. Можно сказать, что в подобных случаях единственным и универсальным обработчиком исключений становится операционная система.
Возможно игнорирование исключительной ситуации и продолжение работы, но такая тактика опасна, так как приводит к ошибочным результатам работы программ или возникновению ошибок впоследствии. Например, проигнорировав ошибку чтения из файла блока данных, программа получит в своё распоряжение не те данные, которые она должна была считать, а какие-то другие. Результаты их использования предугадать невозможно.
Обработка исключительных ситуаций самой программой заключается в том, что при возникновении исключительной ситуации управление передаётся некоторому заранее определённому обработчику — блоку кода, процедуре, функции, которые выполняют необходимые действия.
Исключения позволяют повысить безопасность и качество ПО, предотвращая выполнение программы в случае возникновения каких-либо ошибок. В смысле контроля качества, исключения гораздо надежнее кодов ошибок, так как неверный код ошибки гораздо легче пропустить или намеренно игнорировать.
Основная идея контрактного программирования — это модель взаимодействия элементов программной системы, основывающаяся на идее взаимных обязательств и преимуществ. Контракт некоторого метода или функции может включать в себя:
- конкретные обязательства, которые любой клиентский модуль должен выполнить перед вызовом метода — предусловия;
- конкретные свойства, которые должны присутствовать после выполнения метода — постусловия, которые входят в обязательства поставщика;
- обязательства по выполнению конкретных свойств — инвариантов, которые должны выполняться при получении поставщиком сообщения, а также при выходе из метода.
В объектно-ориентированном программировании контракт метода обычно включает следующую информацию:
– возможные типы входных данных и их значение;
– типы возвращаемых данных и их значение;
– условия возникновения исключений, их типы и значения.
При использовании контрактов сам код не обязан проверять их выполнение. Обычно при нарушении контракта выбрасывается исключение, сообщающее о возникшем несоответствии.
Таким образом, контракты представляю собой модель контроля логических ошибок, или, другими словами, модель проверки бизнес-правил.
Рис. 3.
На рисунке 3 сведены воедино ключевые характеристики всех трех подходов. Каждый подход имеет свои достоинства и недостатки. Однако если рассматривать все эти подходы с точки зрения улучшения корректности ПО, наиболее интересным является подход на основе контрактов.
Только контрактное программирование позволяет описывать и контролировать выполнение различных бизнес-требований не затрачивая при этом значительных усилий.
Все перечисленные подходы можно показать на диаграмме времени жизни программного продукта (рисунок 4).
Рис. 4.
Основной целью данной статьи является теоретическое обоснование и разработка инструмента, который бы позволял встраивать в программный продукт требования, записанные в формальном виде и на этапе выполнения проверять их выполнение.
Более конкретно, можно сформулировать следующие подцели данной статьи:
- Теоретическое обоснование — более подробный обзор контрактного программирования и формализма темпоральных логик. Описание предлагаемого комбинированного подхода.
- Создание спецификация инструмента на основе теоретических выводов.
- Практическое сравнение подходов к динамическому контролю качества на примере разработки одного и того же блока кода.
- Проектирование архитектуры инструмента.
- Создание инструмента.
Решение обозначенной выше проблемы, позволит увеличить качество программного обеспечения и автоматизировать проверку различных бизнес-требований на этапе выполнения программ, написанных на языках семейства.NET.
Также очень важно проводить теоретические исследования в данной области, чтобы на осовании полученных знаний, спроектировать мощный и пригодный к использованию в различных условиях инструмент.
Литература:
1. Введение в программные системы и их разработку Национальный Открытый Университет «ИНТУИТ». 2016 год, 650 страниц
2. Приемы объектно-ориентированного проектирования. Паттерны проектирования. Автор: Э.Гамма, Р.Хелм, Р.Джонсон, Дж. Влиссиде Издательство: Питер Год: 2010, язык: Русский ISBN: 978–5–496–00389–6 Страниц: 366 Источник: http://forcoder.ru/developing/
3. Release it! Проектирование и дизайн ПО для тех, кому не все равно Автор: Майкл Нейгард Издательство: СПб.: Питер Год: 2016 Язык: Русский Страниц: 320 Источник: http://forcoder.ru/developing/
4. Принципы работы с требованиями к программному обеспечению. Унифицированный подход Автор: Дин Леффингуэлл, Дон Уидриг Издательство: Вильямс Год: 2002 ISBN: 5–8459–0275–4, 0–2016–1593–2 Источник: http://progbook.ru/proektirovanie-i-razrabotka-po/
