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

• Автор: Ключев, Аркадий Олегович
• Шифр специальности: 05.13.13
• Научная степень: Кандидатская
• Год защиты: 1999
• Место защиты: Санкт-Петербург
• Количество страниц: 145 с.

ОГЛАВЛЕНИЕ
ВВЕДЕНИЕ
1.ПОСТАНОВКА ЗАДАЧИ
1.1 Классификация и особенности современных МП ИУС ! .2 Методы проектирования РИУС
1.3 Обзор и классификация инструментальных отладочных средств
1.3.1 Обзор стандартных отладочных средств
1.3.2 Обобщенная модель стандартных отладочных средств
1.3.3 Выводы о необходимости вложенной отладки
1.4 Постановка задачи проектирования РИУС Выводы

' ' ? лА О?'.
2. МЕТОДЫ ПРОЕКТИРОВАНИЯ РИУС ПА "'
2.1 Методы проектирования РИУС ПА
2.1.1 Формирование требований
2.1.2 анализ требований
2.1.3 Анализ ситуации
2.2.4 Выбор стратегии
2.2 Целевая модель РИУС ПА
2.2.1 Проектирование системы с частично используемыми аппаратными механизмами
2.2.2 Проектирование параметризуемого шаблона
2.2.3 Проектирование системы с возможнос тью эволюции
2.2.4 Тестовая оценка проекта
2.3 Базовая модель РИУС
2.4 Библиотека объектов РИУС ПА
2.5 Модель проектирования
2.6 Объекты риус па Выводы

*> о

3. АНАЛИЗ ОБЪЕКТОВ РИУС ПА

3.1 Классификация объектов РИУС ПА
3.1.1 Объекты элементной базы
3.1.2 Интерфейсные объекты
3.1.3 Объекты инструментария
3.1.4 Объекты реального времени
3.2 Характеристики объектов РИУС ПА
3.2.1 Функциональное назначение объекта
3.2.3 Внутренние характеристики
3.2.4 Внешние характеристики
3.2.3 Характеристики интерфейса
3.3 Методы получения характеристик
3.4 Критерии корректности характеристик объектов 7О
3.511РИМЕРЫ формирования характеристик для конкретных групп объектов
Выводы
4. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА РИУС ПА
4.1 Проблема отладки РИУС
4.1.1 Отладка сложных и ответственных РИУС
4.1.2 Отладка РИУС в промышленных условиях
4.1.3 Отладка простых РИУС
4.1.4 Некоторые наблюдения и закономерности
4.1.5 Формулирование задачи отладки РИУС
4.2 Обобщенная модель вложенной отладки
4.3 Инструментальная модель
4.3.1 Виды инструментальных моделей
4.3.2 Критерии принадлежности моделей
4.3.3 Критерии избыточности моделей
4.4 Базовые инструменталыше средства РИУС ПА
4.4.1 Вложенная отладка
4.4.2 Средства 1СР
4.4.3 Инструментальный сервер
Выводы 11 о
5. ПРИМЕРЫ ПРАКТИЧЕСКОГО ИСПОЛЬЗОВАНИЯ РЕЗУЛЬТАТОВ ИССЛЕДОВАНИЯ

5.1 Общая архитектура разработанной инструментальной системы
5.2 АРХИТЕКТУРА ИНСТРУМЕНТАЛЬНОЙ СИСТЕМЫ Т51 ИЗ
Карта распределение памяти Т51
5.2.2 Основные механизмы реализованные в Т51
5.3 Архитектура инструментальной системы XI67
5.4 Резидентный инструментарий
5.4.1 Bootstrap и программирование системной (нулевой) страницы FLASH
5.4.2 HEX машина сервисного процессора v 2.01-02 (С167)
5.5 Инструментальный кросс сервер ICS v 1.0 (для LrNUX 2.0)
5.5.1 Перечень команд BBF монитора
5.5.2 Пример файла задания (qnx2m2.tsk)
5.5.3 Пример отчета
Выводы
ЗАКЛЮЧЕНИЕ
ЛИТЕРАТУРА

« простота изменения проекта, т.к. есть последовательность промежуточных описаний
• сокрытие внутренних свойств объектов
• стирание различий меду понятиями АППАРАТУРА и ПРОГРАММА и перевод процесса разделения этих двух понятий на как можно более поздний период проектирования (т.е. уничтожение искусственного разделения на программную и аппаратную часть)
Итак, рассмотрим подробнее этапы ОСТП РИУС.
2.1.1 Формирование требований
Цель данного этапа - установка требований к системе. Гради Буч [11] называет этот шаг концептуализацией. Концептуализация является творческим процессом мысленного моделирования системы. Результатом этого процесса является понимание общего назначения системы. Иногда, для более полного понимания, (и когда это возможно) изготавливают прототип системы. Прототип (см. рис. 9) служит только для понимания, и в дальнейшем, прямого влияния на разработку не оказывает.
2.1.2 Анализ требований
Как известно, целью анализа является описание задачи. На данном этапе мы должны получить прикладную модель проектируемой системы. Такая модель должна удовлетворять трем основньм требованиям:
• Непротиворечивость;
• Прозрачность (т.е. читаемость и понятность);
• Проверяемость [11].
Прикладная модель вырабатывается при содействии представителей заказчика (обычно специалистов в прикладной области) и системного аналитика, со стороны исполнителя (фирмы разработчика системы). Ситуация, когда специалисты со стороны исполнителя что-либо понимают в прикладной области заказчика, очень редка. При анализе, системный аналитик должен понять суть решаемой проблемы с системной точки зрения и составить модель в терминах прикладной задачи. При этом, аналитик может не вникать в тонкости конкретной прикладной области. Прикладная модель должна быть понятна как прикладному специалисту, так и системному аналитику.