Проектирование ресурс-менеджеров QNX Neutrino

Процесс разработки
критических приложений
HARMONY
Что такое процесс?
С точки зрения Harmony процесс это:
–
Спецификация серии последовательных деятельностей,
выполняемых группой взаимодействующих специалистов,
в результате которой создается когерентное
множество артефактов, одним из которых является
требуемая система
Harmony – результат развития и совершенствования процесса
ROPES (Rapid Object-Oriented Process for Embedded Systems).
Используется преимущественно а аэрокосмической и оборонной
промышленности США
Процесс HARMONY
2
Как выполняется разработка критичного ПО
Хорошо известен V-цикл проектирования и
разработки критичного ПО:
ТЗ
Анализ требований
Спецификация
требований
ЭП
Приемочное
тестирование
ПСИ
Системный анализ
и проектирование
Спецификация
архитектуры
Интегрирование
системы и ее
тестирование
ПИ
Проектирование
ПО
Детальная
спецификация
Интегрирование
модулей ПО и их
тестирование
ТП
Реализация ПО и
тестирование
компонентов
Процесс HARMONY
3
Макроцикл HARMONY
System Engineering
(HARMONY-SE)
Приемочное тестирование
Анализ требований
Спецификация
требований
Приемочное
тестирование
ТЗ
ПСИ
Системный анализ
и проектирование
Спецификация
архитектуры
ЭП
Интегрирование
системы и ее
тестирование
Проектирование
ПО
Детальная
спецификация
ТП
Интегрирование
модулей ПО и их
тестирование
Реализация ПО и
тестирование
компонентов
Процесс HARMONY
ПИ
Software Engineering
(HARMONY-SWE)
4
Обзор HARMONY-SE
Анализ требований
Фиксация требований
UC системы
Идентификация вариантов
использования системы
Варианты использования
системы
Сценарии UC «ЧЯ»
Модель системы как «Черный ящик»
Операционные контракты
Функциональный анализ системы
Модель системной архитектуры с
операц. контрактами
Операционные контракты
(наборы функциональных требований)
Архитектурный дизайн
Сценарии UC «БЯ»
Проектирование архитектуры системы
Сценарии UC «ЧЯ»
Проектирование архитектуры подсистем
Модели физич. подсистем
с операц. контрактами АО/ПО
Репозит. тестовых данных
Репозитарий модели и требований
Требования
Разработка АО/ПО
Процесс HARMONY
5
Обзор HARMONY-SE
Анализ требований
– Фиксирование требований и группировка их в варианты
использования.
Функциональный анализ системы
– Идентификация и верификация/валидация операций
системы (т.е. множества функциональных требований) на
основе вариантов использования.
Проектирование архитектуры системы
– Опциональная декомпозиция операций системы и привязка
их к (функциональным или физическим) подсистемам.
Определение интерфейсов подсистем.
Проектирование архитектур подсистем
– Разделение операций между компонентами системы
(программными и/или аппаратными). Определение
интерфейсов компонентов подсистемы.
Процесс HARMONY
6
HARMONY-SE: Анализ требований
Анализ требований
Репозитарий модели и требований
Требования
UC системы
Фиксация требований
Идентификация вариантов
использования системы
Требования фиксируются для их последующей трассировки
Возможно хранение требований в Word/Exel/RequisitePRO/DOORS
(для трассировки требований используется Rhapsody Gateway)
Варианты использования идентифицируют на основе
Процесс HARMONY
7
HARMONY-SE: Анализ требований
Фиксация требований
ADMS – Aircraft Defense Management System
Процесс HARMONY
8
HARMONY-SE: Анализ требований
Фиксация требований
Процесс HARMONY
9
HARMONY-SE: Анализ требований
Идентификация вариантов использования
Каждый вариант использования показывает один из аспектов
функционирования системы, рассматриваемой как «черный ящик»
Процесс HARMONY
10
HARMONY-SE: Анализ требований
Детализация вариантов использования
С любым визуальным объектом с помощью механизма anchor может быть
сопоставлено требование.
Процесс HARMONY
11
Обзор HARMONY-SE
Анализ требований
– Фиксирование требований и группировка их в варианты
использования.
Функциональный анализ системы
– Идентификация и верификация/валидация операций
системы (т.е. множества функциональных требований) на
основе вариантов использования.
Проектирование архитектуры системы
– Опциональная декомпозиция операций системы и привязка
их к (функциональным или физическим) подсистемам.
Определение интерфейсов подсистем.
Проектирование архитектур подсистем
– Разделение операций между компонентами системы
(программными и/или аппаратными). Определение
интерфейсов компонентов подсистемы.
Процесс HARMONY
12
HARMONY-SE: Функциональный анализ
Анализ требований
Фиксация требований
UC системы
Идентификация вариантов
использования системы
Модель системы как «Черный ящик»
Операционные контракты
Варианты использования
системы
Сценарии UC «ЧЯ»
Функциональный анализ системы
При функциональном анализе выполняются:
- Анализ «черного ящика» («ЧЯ», BB) для каждого варианта
использования (UC)
- Анализ целостности вариантов использования
Процесс HARMONY
Репозит. тестовых данных
Репозитарий модели и требований
Требования
13
HARMONY-SE: Функциональный анализ
Для артефактов функционального анализа
целесообразно создавать пакет с подпакетами
анализа каждого варианта использования
Процесс HARMONY
14
HARMONY-SE: Функциональный анализ
Функциональный анализ – это преобразование
функциональных требований в
операционные контракты
ОК (OpCon) задаются в виде сообщений (запросов
сервиса).
На диаграмме последовательности OpCon могут
включать:
– Пред- и пост- условия (могут задаваться состояниями)
– Кросс-ссылки на другие диаграммы последовательности
– Ограничения
Процесс HARMONY
15
HARMONY-SE: Функциональный анализ
OpCon изменения состояния/режима
OpCon деятельности
Процесс HARMONY
16
HARMONY-SE: Функциональный анализ
Структура системы, необходимая для выполнения
каждого UC, описывается с помощью диаграммы
определения блоков
Почему в SysML используют блоки?
- Не нужно определять классы;
- Позволяют анимировать модель.
- Блоки взаимодействуют через
порты – именованные точки
соединения
Процесс HARMONY
17
HARMONY-SE: Функциональный анализ
Сценарий каждого варианта использования
обычно описывают набором диаграмм
последовательностей
Диаграммы
последовательности:
- Сценарии «Солнечного дня»
- Сценарии «Черного дня»
Процесс HARMONY
18
HARMONY-SE: Функциональный анализ
Анализ целостности вариантов использования
1) Блоки, представляющие систему в каждом
варианте использования, помещают на одну
диаграмму
2) На эту диаграмму перетаскивают
блоки, моделирующие актеров, и
связывают соответствующие порты
Процесс HARMONY
19
HARMONY-SE: Функциональный анализ
Поведение каждого блока удобно описывать в
виде конечного автомата
Это позволяет верифицировать модель с помощью симуляции (анимации)
Процесс HARMONY
20
HARMONY-SE: Функциональный анализ
Валидация и верификация модели
на основе симуляции (анимации)
Сохранение модели
Запуск симуляции
Процесс HARMONY
21
HARMONY-SE: Функциональный анализ
Валидация и верификация модели
на основе симуляции (анимации)
Предыдущее
состояние
Последний
сработавший
переход
Текущее
состояние
Процесс HARMONY
22
HARMONY-SE: Функциональный анализ
Основные артефакты SysML, создаваемые в
ходе модельно-управляемого системного
инжиниринга
Взаимосвязь артефактов функционального анализа
Процесс HARMONY
23
Обзор HARMONY-SE
Анализ требований
– Фиксирование требований и группировка их в варианты
использования.
Функциональный анализ системы
– Идентификация и верификация/валидация операций
системы (т.е. множества функциональных требований) на
основе вариантов использования.
Проектирование архитектуры системы
– Опциональная декомпозиция операций системы и привязка
их к (функциональным или физическим) подсистемам.
Определение интерфейсов подсистем.
Проектирование архитектур подсистем
– Разделение операций между компонентами системы
(программными и/или аппаратными). Определение
интерфейсов компонентов подсистемы.
Процесс HARMONY
24
HARMONY-SE
Анализ требований
Фиксация требований
UC системы
Идентификация вариантов
использования системы
Варианты использования
системы
Сценарии UC «ЧЯ»
Модель системы как «Черный ящик»
Операционные контракты
Функциональный анализ системы
Модель системной архитектуры с
операц. контрактами
Операционные контракты
(наборы функциональных требований)
Архитектурный дизайн
Сценарии UC «БЯ»
Проектирование архитектуры системы
Сценарии UC «ЧЯ»
Проектирование архитектуры подсистем
Модели физич. подсистем
с операц. контрактами АО/ПО
Репозит. тестовых данных
Репозитарий модели и требований
Требования
Разработка АО/ПО
Процесс HARMONY
25
Организация SE-модели
Область требований
Область системной архитектуры
Область спецификации физической
архитектуры (Подсистем)
Процесс HARMONY
26
Harmony
Цикл инкрементной разработки («Микро-цикл»)
Требования,
сценарии и др.
артефакты
Системный инжиниринг
(HARMONY-SE)
Модель
Тестовые
сценарии
Модель требований и
логической структуры
Реализация
Приемочное
тестирование
Система, прошедшая
внутреннюю валидацию и
верификацию
Тестирование
Ревизия
Дизайн
Анализ
Программный инжиниринг
(HARMONY-SWE)
Процесс HARMONY
27
Микроцикл HARMONY
Анализ -- идентификация характеристик, которыми
должно обладать любое решения для соответствия
заданным требованиям;
Дизайн -- оптимизация структуры или поведения
системы в соответствии с заданными критериями;
Реализация -- создание корректно работающего
компонента или подсистемы;
Тестирование -- получение верифицированной версии
системы с хорошо известными возможностями;
Ревизия (Party!) -- идентификация и корректировка
задач, связанных с выполнением всего проекта.
Процесс HARMONY
28
Микроцикл HARMONY: Анализ
Анализ:
•
•
определение прототипа – выбор требований,
подлежащих реализации на витке
объектный анализ – идентификация необходимых
объектов и классов
Стратегии выявления объектов:
–
–
–
–
–
–
–
Идентификация существительных
Предоставляемые сервисы
Транзакции
Физические устройства
Ключевые концепции
Устойчивые данные
Элементы управления
Процесс HARMONY
29
Микроцикл HARMONY
Анализ -- идентификация характеристик, которыми
должно обладать любое решения для соответствия
заданным требованиям;
Дизайн -- оптимизация структуры или поведения
системы в соответствии с заданными критериями;
Реализация -- создание корректно работающего
компонента или подсистемы;
Тестирование -- получение верифицированной версии
системы с хорошо известными возможностями;
Ревизия (Party!) -- идентификация и корректировка
задач, связанных с выполнением всего проекта.
Процесс HARMONY
30
Микроцикл HARMONY: Дизайн
В ходе стадии «Дизайн» к прототипу
применяют шаблоны проектирования
Шаблоны проектирования надежности:
-
Однородная избыточность
Неоднородная избыточность
Санитарная проверка
Монитор-актуатор
Наблюдатель
Администратор (функциональной) безопасности
Дизайн или Проектирование – применение к прототипу шаблонов
проектирования, необходимых для привидения его в соответствие
заданным критериям
Процесс HARMONY
31
Микроцикл HARMONY: Дизайн
Дизайн:
Архитектура подсистем и компонентов – из каких
исполняемых модулей состоит система или подсистема;
Архитектура развертывания – элементы, относящиеся к
различным инженерным областям: программной, аппаратной,
механической, химической, тестовой и т.д.;
Архитектура распределения – размещение объектов в
изолированных адресных пространствах, способ нахождения
друг друга, порядок их совместной работы;
Архитектура надежности – как выявляются, изолируются и
устраняются сбои в процессе функционирования системы;
Архитектура ресурсов и параллельности –потоки, их
диспетчеризацию и их синхронизацию при использовании
разделяемых ресурсов;
Архитектура безопасности –элементы системы, необходимые
для обеспечения информационной безопасности.
Процесс HARMONY
32
Микроцикл HARMONY
Анализ -- идентификация характеристик, которыми
должно обладать любое решения для соответствия
заданным требованиям;
Дизайн -- оптимизация структуры или поведения
системы в соответствии с заданными критериями;
Реализация -- создание корректно работающего
компонента или подсистемы;
Тестирование -- получение верифицированной версии
системы с хорошо известными возможностями;
Ревизия (Party!) -- идентификация и корректировка
задач, связанных с выполнением всего проекта.
Процесс HARMONY
33
Микроцикл HARMONY: Реализация
Реализация:
•
•
Трансляция модели в коды
Тестирование программных модулей (функциональное,
качества сервиса, покрытия кода, стресс-тестирование, нагрузочное
•
)
Ревизия соответствия программных модулей
модели
Результатом фазы реализации являются высококачественные
компоненты и подсистемы создаваемой системы.
Процесс HARMONY
34
Микроцикл HARMONY
Анализ -- идентификация характеристик, которыми
должно обладать любое решения для соответствия
заданным требованиям;
Дизайн -- оптимизация структуры или поведения
системы в соответствии с заданными критериями;
Реализация -- создание корректно работающего
компонента или подсистемы;
Тестирование -- получение верифицированной версии
системы с хорошо известными возможностями;
Ревизия (Party!) -- идентификация и корректировка
задач, связанных с выполнением всего проекта.
Процесс HARMONY
35
Микроцикл HARMONY: Тестирование
Тестирование –
валидация качества уже высококачественного
продукта
1) Базовые тест-векторы (диаграммы
последовательностей) уже созданы на этапе
формализации требований к системе.
2) Фаза «Тестирование» актуальна при внесении
заказчиком изменений в требования в ходе проекта
Выявление дефекта требует повтора микроцикла для его устранения и
повторного тестирования
Процесс HARMONY
36
Микроцикл HARMONY
Анализ -- идентификация характеристик, которыми
должно обладать любое решения для соответствия
заданным требованиям;
Дизайн -- оптимизация структуры или поведения
системы в соответствии с заданными критериями;
Реализация -- создание корректно работающего
компонента или подсистемы;
Тестирование -- получение верифицированной версии
системы с хорошо известными возможностями;
Ревизия (Party!) -- идентификация и корректировка
задач, связанных с выполнением всего проекта.
Процесс HARMONY
37
Микроцикл HARMONY: Ревизия
Ревизия:
- Ревизия выполнения графика проекта. При необходимости
может выполняться реорганизация проекта, передача части
работ в аутсорсинг, перегруппировка ресурсов проекта;
- Ревизия архитектуры. Архитектура оценивается на различных
фазах проекта, тем не менее ревизия необходима – просчеты в
архитектуре системы дорого стоят.
- Ревизия процесса. Проводится оценка самого процесса
разработки и его рабочих процедур – при необходимости
процесс корректируется.
- Ревизия рисков. Проверяется, как контролируются риски,
предусмотренные в плане управления рисками, а так же какие
новые риски появились.
Процесс HARMONY
38
HARMONY
Процесс –
это спецификация серии последовательных деятельностей,
выполняемых группой взаимодействующих специалистов,
в результате которой создается когерентное множество артефактов,
одним из которых является требуемая система
Выходные данные Harmony:
верифицированная система высокого качества
Процесс HARMONY
39
Спасибо за внимание!
196135, г. Санкт-Петербург,
пр. Юрия Гагарина 23
тел.: (812) 702-0833
факс: (812) 373-0497
web: http://www.swd.ru/
Процесс HARMONY
40