WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     || 2 | 3 | 4 | 5 |   ...   | 33 |
Статья Д.Н. Воробьева и А.С. Камкина «Генерация тестовых программ для микропроцессоров на основе шаблонов конвейерных конфликтов» посвящена Пр е д и с л о в и е описанию методики автоматизированного построения тестовых программ для В 18-м томе Трудов института системного программирования публикуются 9 верификации управляющей логики микропроцессоров. Методика основана на статей сотрудников Института, посвященных различным аспектам формальной спецификации системы команд и описании шаблонов тестирования программных и аппаратных средств на основе формальных конфликтных ситуаций возможных в работе конвейера тестируемого спецификаций, методам виртуализации и моделирования.

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

построенная на базе компонентных технологий» представлен подход к построению архитектуры инструментария для тестирования на основе В статье М.М. Чупилко «Автоматизация системного тестирования моделей моделей, использующего современные компонентные технологии. Одна из аппаратуры на основе формальных спецификаций» обсуждается проблема основных идей, лежащих в его основе – применение техник неинвазивной системного тестирования взаимосвязанных модулей аппаратуры, когда их композиции, позволяющих с минимальными затратами интегрировать сложность уже не позволяет применять подходы к тестированию на уровне множество независимо разработанных компонентов в сложную систему и модулей. В работе приводится краткий анализ возможностей построения переконфигурировать ее, не изменяя кода компонентов. Также описывается тестовой системы на основе использования формальных спецификаций, а прототипная реализации предложенного подхода на базе свободно доступных также предлагается метод верификации, являющийся расширением библиотек и пример ее использования для построения тестов.

модульного подхода, основанного на технологии UniTESK.

Статья С.Г. Грошева «Технология создания гетерогенных трасс, их анализа и В статье А.С. Камкина «Некоторые вопросы автоматизации построения генерации из них отчётов» содержит описание архитектуры модульной тестовых программ для модулей обработки переходов микропроцессоров» системы трассировки и анализа трасс, поддерживающей трассировку рассматриваются вопросы автоматизированного построения тестовых сложноструктурированной информации, расширение видов трассируемой программ, предназначенных для функциональной верификации модулей информации, изоляцию и выборку нужных данных при анализе полученных обработки переходов микропроцессоров. Формулируются задачи, трасс и облегчающей связывание разнородных данных между собой.

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

разнообразные отчёты.

Статья А.В. Никешина, Н.В. Пакулина и В.З. Шнитмана «Разработка Статья Е.В. Корныхина «Метод зеркальной генерации ограничений для тестового набора для верификации реализаций протокола безопасности IPsec построения тестовых программ по тестовым шаблонам» относится к области v2» посвящена разработке тестового набора для проверки соответствий системного функционального (core-level) тестирования микропроцессоров, реализаций узлов Интернет спецификациям нового протокола безопасности более точно модулей управления памяти. В статье описывается метод IPsec v2. Для построения тестового набора использовалась технология построения тестов (тестовой программы) для нацеленной генерации. Такая автоматического тестирования UniTESK и программный пакет CTesK, генерация предполагает систематичное построение тестов специального вида.

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

MIPS64.

В статье И.Б. Бурдонова и А.С. Косачева «Тестирование конформности на В статье П.М. Довгалюка, М.А. Климушенковой и А.М. Мухиной «Создание основе соответствия состояний» обсуждаются проблемы тестирования модулей поддержки архитектур для среды TrEx с помощью соответствия (конформности) реализации требованиям спецификации. Идея специализированного языка описания процессоров» рассматривается безопасного тестирования, предложенная авторами для конформности, предложенный авторами подход к разработке модулей поддержки архитектур основанной на трассах наблюдений, распространяется на случай (слабой) для среды TrEx на основе языка описания процессорных архитектур.

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



тестирования. Предлагаются общий алгоритм полного тестирования и его 5 модификация для практического применения, опирающаяся на некоторые ограничения на реализацию и спецификацию.

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

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

Сборник завершает статья Д.А. Грушина и А.И. Поспелова «Система моделирования Grid: реализация и возможности применения», в которой описывается разработанная в ИСП РАН система моделирования распределенных вычислительных сред Grid. С помощью этой системы проведен анализ реальной вычислительной среды Sharcnet. На основе анализа были выявлены возможные способы существенного увеличения эффективности работы среды.

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

Источником таких проблем служит обычно чрезвычайно высокая трудоемкость проверки корректности поведения систем при нелинейно Кулямин В. В.

растущем с увеличением числа компонентов количестве возможных kuliamin@ispras.ru сценариев их взаимодействия и сложных, часто неявных связей и зависимостей между ними. В свою очередь, эти трудности имеют следующие Аннотация. В статье представлен подход к построению архитектуры инструментария причины.

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

полный интерфейс модуля, как он понимался в работах Парнаса [3], одного из основоположников модульного подхода к разработке ПО, 1. Введение должен задавать не только его синтаксическую структуру (имена реализуемых операций, типы их параметров и результатов, и Увеличение разнообразия и количества задач, возлагаемых в современном соответствующие структуры данных), но и семантику (правила мире на вычислительные системы, приводит к постоянному росту их использования операций и ожидаемое в ответ поведение модуля). На сложности и усложнению всех видов деятельности, связанных с их практике же обычно ограничиваются только фиксацией синтаксиса, построением и сопровождением. На решение проблем, связанных с этим семантика описывается, да и то, чаще всего не полностью и не вполне ростом сложности, нацелены активно развивающиеся в последние однозначно, только для интерфейсов, входящих в системные десятилетия компонентные технологии [1,2] построения как программных, библиотеки и имеющих достаточно долгую историю использования.

так и аппаратных составляющих вычислительных систем.

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





системы), только за счет помещения готовых компонентов в бинарном виде в В 2002 году годовые потери одной только экономики США от рамки технологической инфраструктуры системы. В результате компоненты многочисленных ошибок в ПО были оценены в 60 миллиардов могут создаваться и поддерживаться совершенно независимыми долларов [4].

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

интегрированной разработки и сопровождения.

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

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

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

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

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

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

такими свойствами пока обладают лишь инструменты модульного тестирования (unit testing) [5], самым известным из которых является Помимо этих свойств, чтобы получить признание на практике, компонентная JUnit [6], модульных инструментов, поддерживающих более сложные технология верификации должна быть расширением одной из существующих виды верификации или тестирование на соответствие требованиям, компонентных технологий разработки и задействовать по большей части ее практически нет.

элементы, уже знакомые и привычные для разработчиков.

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

Pages:     || 2 | 3 | 4 | 5 |   ...   | 33 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.