Методы построения и верификации моделей системного программного обеспечения информационно-управляющих систем

• Автор: Окулевич, Владимир Викентьевич
• Шифр специальности: 05.13.12
• Научная степень: Кандидатская
• Год защиты: 2004
• Место защиты: Санкт-Петербург
• Количество страниц: 158 с. : ил.

Оглавление
Оглавление
Введение

Глава 1. Анализ методов повышения качества и надежности СПО ИУС.

1.1. Специфика СПО ИУС

1.2. Методы повышения качества и надежности ПО ИУС.

1.2.1. Использование образцов.

1.2.2. Тестирование.

1.2.3. Повторное использование компонент

1.2.4. Использование средств автоматической генерации кода

1.2.5. Использование средств сквозного цикла разработки.

1.2.6. Использование систем контроля требований.
1.2.7. Построение и верификация моделей.
1.3. Построение и верификация моделей СПО ИУС
1.3.1. Модель СПО.
1.3.2. Моделирование СПО
1.3.3. Верификация моделей СПО
1.3.4. Современные средства построения и верификации моделей ПО
1.4. Постановка задачи.
Глава 2. Методы построения и верификации моделей СПО ИУС.
2.1. Основные понятия. Классификация объектов СПО ИУС
2.2. Выбор базового метода построения и верификации моделей
2.3. Анализ базового метода построения и верификации моделей ПО
2.4. Метод построения и верификации моделей СПО ИУС
2.4.1. Входные данные метода
2.4.2. Выходные данные метода.
2.4.3. Определение и классификация требований.
2.4.4. Общая последовательность этапов метода.
2.4.5. Специфика этапов метода в зависимости от типа модели СПО
2.4.5.1. Особенности при исследовании архитектуры СПО
2.4.5.2. Особенности при исследовании КВМ СПО
2.5. Особенности метода построения и верификации моделей СПО ИУС
2.5.1. Выбор форматов для этапа построения моделей
2.5.2. Выбор форматов отчетов верификации.
2.5.3. Дополнительные операции темпоральной логики
2.5.4. Образцы требований с различными областями видимости
2.5.5. Интеграция с МБОеу.
2.5.6. Интеграция с системой контроля версий
2.5.7. Классификация элементов моделей
2.5.8. Выбор формата описания элементов моделей.
2.5.9. Таблица описания библиотеки элементов
2.6. Библиотека элементов моделей.
Выводы.
Глава 3. Исследование характеристик методов построения и верификации
моделей СПО ИУС
3.1. Исследование базового и расширенного методов
3.2. Исследование расширенного метода и метода на основе БМУ.
Выводы.
Глава 4. Исследование и разработка моделей СПО ИУС.
4.1. Исследование архитектуры СПО модель драйвера Vi ЫТ
4.2. Исследование критически важного механизма арбитража активности
резервированных модулей
Выводы.
Заключение.
Список литературы


Известны следующие определения. Архитектура программного обеспечения - это ряд значительных решений об организации программной системы, выборе структурных элементов и их интерфейсов, с помощью которых собирается система, а также их поведение во взаимодействии с этими элементами, объединение этих структурных и поведенческих элементов в большие системы и архитектурный стиль этой организации - этих элементов и их интерфейсов, их взаимодействия и их объединения» []. Архитектура программного обеспечения - это абстрактная спецификация системы, состоящая в основном из функциональных компонент, описанных в терминах их поведения и интерфейсов, а также межсоединений компонент» []. Программная архитектура системы определяет высокоуровневую структуру, определяющую ее общую (в ориг. Хорошо определенная архитектура позволяет инженеру составлять мнение о свойствах системы на высоком уровне абстракции. Типичные свойства, с которыми необходимо считаться, включают протоколы взаимодействия, пропускную способность и задержки, положение центральных хранилищ данных и предполагаемых направлений эволюции (системы)» []. Программная архитектура была предложена как многообещающий подход для того, чтобы заполнить разрыв между требованиями и реализацией в проектировании сложных систем. Программная архитектура описывает общую организацию системы в терминах ее компонент и их взаимодействия» []. Программная архитектура программы или вычислительной системы -это структура или структуры системы, которые включают программные компоненты, внешне видимые свойства этих компонент и отношения между ними. Под внешне видимыми свойствами, мы подразумеваем те, о которых могут делать предположения другие компоненты, такие как предоставляемые сервисы, характеристики производительности, обработка отказов, использование разделяемых ресурсов и т. В этом определении указывается, что программная архитектура должна абстрагироваться от некоторой информации о системе (иначе нет причин определять архитектуру, мы бы просто говорили обо всей системе), а также предусматривать достаточно информации для того, чтобы быть основой анализа, принятия решений и, следовательно, сокращения рисков. Рассмотрим некоторые последствия из этого определения подробнее. Во-первых, архитектура определяет компоненты. Архитектура содержит информацию о том, как компоненты взаимодействуют друг с другом. Это означает, что архитектура специально пропускает содержательную информацию о компонентах, которая не относится к их взаимодействию. Во-вторых, определение делает ясным, что системы могут состоять больше чем из одной структуры, и что ни одна структура не претендует на то, чтоб неопровержимо быть архитектурой. Определение намеренно не указывает, что такое архитектурные компоненты и отношения. Является ли программный компонент объектом? Процессом? Библиотекой? Базой данных? Коммерческим продуктом? Им может быть все перечисленное и больше. В-третьих, определение подразумевает, что каждая программная система имеет архитектуру, поскольку каждая система может быть представлена в виде компонент и отношений между ними. Это то поведение, которое позволяет компонентам взаимодействовать друг с другом, являющееся ясной частью архитектуры. Следовательно, большинство рисунков из «квадратов и стрелочек», которые проходят как архитектуры, фактически не являются архитектурой вовсе. Это просто рисунки из «квадратов и стрелочек» » []. Программная архитектура - это множество концепций и проектных решений о структуре и текстуре программного обеспечения, которые должны быть сделаны до начала параллельной инженерной разработки для того, чтобы обеспечить эффективное удовлетворение архитектурно значимых явных функциональных и качественных требований и неявных требованиях семейства продукции, проблемы и области решений» []. Кроме того, в контексте широко распространенной объектно-ориентированной технологии разработки программного обеспечения, понятие «абстрактный» применяется к тем объектам, экземпляр которых не может быть создан в действительности (см.