CC BY
36
AndRes!m23=f23(mi, x, y) - критик сужает исходное множество значений в соответствии с требованиями пользователя (здесь обозначения состояний и вычисляющие их функции совпадают с предыдущим примером.
Аналогично можно определить процессы, описывающие поведение критической системы и пользователя. В простейшем случае, когда в системе представлен только описанный выше критик и игнорируются все события, не имеющие к нему непосредственного отношения, эти процессы можно описать следующим образом: CrSystem = detect!m0 ^ CrSystem
User = initialSuggestion?m1^(setUserCapacity!x ^ constrain-ByUserCapacity?m21 ^ User | setBenchRes!y ^ constrainBy-BenchRes?m22 ^ User | setCapacityAndRes!x,y ^ constrain-ByCapacityAndRes?m23 ^ User ).
Тогда поведение всей среды проектирования в целом можно представить как параллельную композицию процессов:
DesignEnvironment = CrSystem || CrMW || User.
В заключение отметим, что критические системы являются мощным средством организации пользовательского интерфейса инструментов проектирования программных систем, обеспечивающим поддержку принятия решений в контексте текущего состояния проекта. Сочетание оперативности обратной связи по всем изменениям в проекте и немодального характера порождаемых кри-
тиками рекомендаций (немодальные диалоговые окна) повышает осведомленность разработчика о состоянии проекта, облегчает доступ к релевантной информации и не ограничивает при этом свободу внесения изменений в проект.
Особенно полезными описанные выше критические системы могут оказаться в проектировании распределенных ИСУП, поскольку такие решения часто требуют учета множества специфических факторов, известных лишь немногим экспертам в данной предметной области, и обработки значительных объемов информации, которая во многом может быть автоматизирована.
Формальное описание критиков позволит использовать соответствующие математические аппараты в процессе построения и реализации критиков и критических систем.
Список литературы
1. Jason E. Robbins. Design Critiquing Systems. http://www.ics.uci.edu/~jrobbins/papers/CritiquingSurvey.pdf
2. Jason E. Robbins. Cognitive Support Features for Software Development Tools, Ph.D. dissertation. http://www.ics.uci.edu/ ~jrobbins/
3. Сайт проекта ArgoUML: http://www.tigris.org/argouml/
4. OMG Unified Modeling Language Specification, Version 1.5. http://www.omg.org/technology/documents/formal/uml.htm
5. Hoare, C. A. R. Communicating Sequential Processes. http://www.usingcsp.com/cspbook.pdf
ВЕРИФИКАЦИОННАЯ ТЕХНОЛОГИЯ БАЗОВЫХ ПРОТОКОЛОВ ДЛЯ РАЗРАБОТКИ И ПРОЕКТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
С.Н. Баранов, П.Д. Дробинцев, А.А. Летичевский, В.П. Котляров
В традиционном подходе качество программного продукта обеспечивается тем, что проверяется соответствие кода спецификации требований и спецификации проекта. Обычно для этого используется матрица отслеживания (traceability matrix), в которой отмечаются все соответствия элементов кода разделам спецификационной документации (рис. 1). Что же в действительности проверяется при таком подходе?
Проверка спецификаций является элементом процесса разработки программного обеспечения (ПО), который дает соответствующую процедуру и порядок ее применения. Однако интерпретация результатов таких проверок - прерогатива разработчика или тестировщика, которые отмечают в матрице отслеживания, что соответствующий пункт спецификации учтен; но то, как именно понят этот пункт, остается невыясненным. Проблему можно решить только через наблюдение за поведением данного приложения в процессе тестирования.
Формализация спецификаций на языках М8С/8БЬ/иМЬ [1-3] позволяет при определенных условиях формально проверить корректность требований и соответствие им кода.
Корректность проверяется путем верификации (то есть доказательства взаимной непротиворечивости требований), соответствие кода специфика-
циям обеспечивается путем прямого порождения (генерации) кода из них.
Визуальное проектирование и моделирование гарантируют соответствие спецификаций и кода за счет генерации кода приложения из спецификаций и кода тестов из требований, то есть код соответствует спецификациям по построению (рис. 2).
Визуальные модели на языках спецификаций М8С/8БЬ/иМЬ для описания продукта используют символические модели приложения и окружения, в которых закодировано множество сценариев поведения за счет применения альтернатив, итераций, множеств символических переменных -параметров.
Визуальные модели очень наглядны, однако кто гарантирует их корректность? Как и насколько полно проверяются поведенческие сценарии символических моделей?
Такая проверка осуществляется на конкретных сценариях (где переменные получают свои значения) или на тестах. Однако неясно, сколько тестов достаточно для исчерпывающей проверки данного приложения и каков их набор.
В существующей практике гарантом успешного решения этой проблемы служит только интуиция опытного тестировщика, которая гарантирует только то, что тестировщик уяснил смысл требований и как-то отразил его в соответствующем тестовом наборе.
Если в тестовом наборе не будет учтена какая-либо комбинация событий при каких-либо совокупностях значений параметров, то не выявленная интуицией проблема, возможно, будет обнаружена на фазе системного тестирования, иначе она неизбежно попадет в список пострелизных дефектов к пользователю.
Именно поэтому в промышленном программировании требуется исчерпывающая проверка функциональных возможностей приложения, а она предполагает экспоненциальный рост числа тестов в тестовом наборе, который быстро исчерпывает допустимые ресурсы и запланированное время проекта.
Эта сложная производственная задача решается путем дополнения тестирования верификацией (рис. 3) - доказательством корректности (качества) продукта. В процессе формализации разработчик и тестировщик создают модели продукта -модель приложения и модель окружения, - используя языки спецификаций М8С/8БЬ/иМЬ.
Рис. 3. Подход с применением верификации
Разработка формальных описаний сложных систем - непростая работа. Она требует точного представления структурных и поведенческих свойств создаваемых моделей на этапе проектирования. В традиционной технологии на этом этапе, как правило, ограничиваются приближенными описаниями свойств создаваемых объектов, в полной мере используя гибкость и "уклончивость" естественного языка. Их уточнение происходит позднее на этапе программирования, в результате фазы формализации и программирования перекрываются.
Необходимость создания формальных моделей на фазе проектирования приводит к строгости и определенности формулировок с самого начала, то есть к сдвигу собственно программирования, правда, на языках достаточно высокого уровня (языках спецификаций), на более раннюю фазу проектирования. К подобному повороту в технологии программирования существующая программистская среда пока еще не очень готова.
Ручная работа над сложными моделями требует особой экспертизы в проблемной области и в детальном понимании структурных и поведенческих характеристик проектируемого объекта.
Предлагается упрощение технологии проектирования, где редукция сложности формализации поведения осуществляется за счет исчерпывающего описания свойств элементарных (на данном уровне описания) активностей, или базовых протоколов (БП).
Каждый БП (рис. 4) соответствует некоторому пункту спецификации и тем самым заменяет формализацию сложных сценариев простой формализацией поведенческих протоколов сценариев элементарных действий, из которых строится слож-
ный сценарий. Из множества БП автоматически генерируются сложные поведенческие сценарии или, наоборот, сложные сценарии декомпозици-руются в простые.
Переход к постепенной формализации по пунктам спецификаций упрощает сложности формализации, связанные с человеческим фактором. Каждый проектировщик работает над формализацией "своего" хорошо знакомого модуля. Автоматическое объединение БП в корректные сценарии позволяет автоматически генерировать сложные поведенческие сценарии и проверять корректность разработанных вручную сценариев.
Модель спецификации, созданная в результате объединения сценариев, может использоваться для генерации кода приложения или кода тестов; при наличии разработанного вручную она может применяться как эталонная модель приложения в процессе автоматического тестирования.
Возможна верификация спецификаций отдельных модулей или свойств продукта по описаниям различных уровней (высокоуровневых по документу высокоуровневого проектирования или детальных, низкоуровневых, по соответствующему документу детального проектирования) в составе целого приложения.
Эта задача известна под названием верификации взаимодействия свойств (feature interaction). В этом случае спецификация на верифицируемый компонент дополняется пред- и постусловиями режимов его использования, явно определяющими структуру и области значений соответствующих параметров.
Наборы БП, накопленные для предметной области, создают архив, который может вновь использоваться в однотипных проектах. Новая технология позволяет анализировать свойства будущего программного продукта уже на раннем этапе проектирования и на уровне разрабатываемых спецификаций.
Метод анализа - это автоматический контроль вза-
имной непротиворечивости и полноты моделей, описывающих поведенческие свойства проектируемого приложения и заданных символическими спецификациями.
Свойства анализируемого проекта выдаются в виде документа -верификационного отчета, который содержит следующую информацию, заданную в виде комментариев к исходным диаграммам спецификаций:
• множество БП;
• описание некорректностей, найденных в результате верификации;
• символические трассы - сценарии, порождающие некорректные ситуации;
• набор символических трасс, достаточный для исчерпывающей проверки функциональности, заданной спецификацией требований.
По верификационным трассам можно автоматически сгенерировать тесты, настроенные на специфическую работу с тестируемым объектом и его окружением.
В результате тестирования получаем тестовый вердикт, заданный в графической форме (рис. 5), в котором зафиксированы все расхождения с требованиями и который позволяет отделить дефекты тестов от дефектов тестируемого приложения.
Описываемый подход (рис. 6) характеризуется следующими преимуществами, выгодно отличающими его от традиционного.
1. Чистка спецификаций: когда разработанный ранее код расширяется для новых приложений, то возрастает риск внесения новых ошибок, поскольку решения принимаются исходя из спе-цификационной документации, а не из наличного кода; поэтому исходные требования и спецификации должны быть корректны и взаимно непротиворечивы с самого начала. Данный подход обеспечивает целостность этих требований.
2. Генерация символических трасс: символическая трасса заменяет собой ряд конкретных трасс с различными константами в качестве значений параметров. Все статические проверки выполняются во время компиляции, и генерируется только код для остаточных динамических прове-
Рис. 5. Описание найденной некорректности
Рис. 6. Подход на основе базовых сценариев
рок (как в случае смешанных вычислений); например, область допустимых значений переменной, все нереализуемые пути от входных значений к выходным также устраняются из рассмотрения.
3. Удаление избыточных символических трасс: трассы разбиваются на классы эквивалентности, и из каждого класса берется только по одному представителю, что приводит к сокращению объема тестирования до 1:100.
4. Оптимальное число тестов с гарантированным 100 % покрытием: конкретные тесты для
прогона порождаются из символических трасс с отфильтровыванием избыточных; оставшиеся тесты по-прежнему гарантируют 100% покрытие исходных требований только этим сокращенным набором тестов.
5. Определение местоположения ошибки в случае неуспеха теста: каждый тест может или пройти, или не пройти. В случае неуспеха пользователь может определить, где скрыта причина: в приложении или в модели окружения. Вердикт с сообщением о неудаче прибавляется к модели окружения и повторно проверяется на взаимную непротиворечивость.
Список литературы
1. ITU-T z.100 (08/2002)// Telecommunication standardization sector of UTI, 202 с. - http://www.itu.int/rec/recommenda-tion.asp?type=items&lang=e&parent=T-REC-Z.100-200208-I
2. Recommendation z.120, 78 с. - http://www.itu.int/rec/re-commendation.asp?type=items&lang=e&parent=T-REC-Z. 120-200404-P.
3. Telelogic TAU 2.3 UML tutorial// Telelogic, 60 с. -https://support.telelogic.com/en/tau/download/product/product.cfm ?vid=97 (the document is included in the product box of TAU 2.3).
4. VRS User manual // Motorola, 82 с. - http://www.stc.corp. mot.com/twiki/bin/view/GSGSE/VrsDocumentation
ИНТЕГРАЦИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ РЕАЛЬНОГО ВРЕМЕНИ И ОПЕРАЦИОННЫХ СИСТЕМ ОБЩЕГО НАЗНАЧЕНИЯ
Я.А. Домарацкий
В последнее время разработчики встроенных систем управления все чаще и чаще сталкиваются с задачами перевода прикладного программного обеспечения (ПО) встроенных систем реального времени с одной программно-аппаратной платформы на другую. Как правило, наследованный код прикладного ПО работает под управлением операционной системы реального времени (ОСРВ). ОСРВ осуществляет диспетчирование задач реального времени, обработку прерываний от внешних устройств, предоставляет набор примитивов для организации межзадачного взаимодействия и другие системные средства. Конкретный набор средств, предоставляемых ОСРВ, определятся архитектурой ОСРВ, областью применения, аппаратной платформой, на которой работает ОСРВ, а также требованиями заказчиков, высказанными на этапе проектирования ОСРВ. В результате различие между коммерческими системами, представленными на рынке ОСРВ, достаточно велико.
Простейшие системы (например 08ЕК [1] или ЯТХС) работают на 8-, 16- и 32-разрядных микроконтроллерах и предоставляют только базовые
средства по диспетчеризации задач и обработки прерываний. Как правило, подобные системы (назовем их базовыми ОСРВ) не поддерживают стандартных интерфейсов разработки прикладного ПО (например Р081Х [2]) и не предоставляют механизмов защиты памяти. Достоинствами базовых ОСРВ является компактность систем, открытость исходного кода систем, прозрачность внутренней архитектуры и обеспечение высокого и гарантированного времени реакции системы на внешние воздействия.
Недостатками подобных систем является их низкая масштабируемость (как правило, отладка системы существенно усложняется, если число одновременно запущенных задач превышает несколько десятков), сложность интеграции компонентов системы в единое целое (отсутствие защиты памяти), сложность повторного использования программных компонентов, изначально разработанных для других проектов (отсутствие поддержки стандартных интерфейсов разработки прикладного ПО), ограниченность средств отладки (как правило, отладка кода прикладного ПО может быть завершена только на целевой аппа-
