Harmony Процесс разработки на основе визуального моделирования

1. HarmonyПроцесс разработки на основевизуального моделирования для встраиваемых систем и приложений реального времени Дмитрий РыжовМенеджер по продуктуd.ryzhov@swd.ru

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

3. Обзор Harmony • Гибридный итеративный процесс разработки на основе визуального моделирования, поддерживающий • Последовательную разработку систем (Harmony-SE) и • Итеративную разработку ПО (Harmony-SWE) • Обеспечивает плавный переход от разработки системы к разработке программного обеспечения • Процесс основанный на сценариях: Повторное использование тестовых сценариев на протяжении всего процесса разработки • Поддержан одним инструментом, как результат единая модель для этапов разработки системы и ПО Процесс HARMONY

4. Временные рамки Harmony От начального анализа до конечной поставки. Обычно от одного до нескольких лет Макрофаза Фокус на ключевых концепц. Фокус на уточнении концепций Фокус на проектировании и реализации Фокус на оптимиз. и развёртывании Добавление функциональности и её проверка в микроцикле. Обычно от 30 мин. до 1 дня Итерация по созданию одного прототипа. Обычно 4-6 недель Процесс HARMONY

5. Функциональное тестирование Сбор и анализ требований Макрофаза Harmony Разработка системы (HARMONY-SE) Разработка ПО (HARMONY-SWE) Системный анализ и проектирование Интеграция подсистем и тестирование Анализ и Проектирование ПО Интеграция ПО и интегральное тестирование SW Design Реализация ПО и элементарное тестирование Процесс HARMONY

6. HARMONY-SE Анализ требований Требования Фиксация требований UC системы Идентификация прецедентов использования системы Прецеденты использования системы Модель анализа системы Интерфейсы системы Сценарии UC «ЧЯ» Функциональный анализ системы Репозиторий модели и требований Операции уровня системы Модель системной архитектуры с операциями, привязанными к подсистемам Сценарии UC «ЧЯ» Репозит. тестовых данных Архитектурный дизайн Сценарии UC «БЯ» Проектирование архитектуры системы Сценарии UC «БЯ» Проектирование архитектуры подсистем Расширенные сценарии «БЯ» Модели физ. подсистем с операциями, привязанным к компонентам АО/ПО Разработка АО/ПО Процесс HARMONY

7. Итеративная разработка ПО Требования, сценарии и др. артефакты Тестовые сценарии Модель Приемочное тестирование Разработка системы (HARMONY-SE) Модель анализа, модели архитектуры системы и подсистем Система, прошедшая валидацию и верификацию Тестирование Реализация Ревизия Дизайн Анализ Разработка ПО (HARMONY-SWE) Процесс HARMONY

8. Обзор HARMONY-SE • Анализ требований • Фиксирование требований и группировка их в прецеденты использования. • Функциональный анализ системы • Идентификация и верификация/валидация операций системы (т.е. множества функциональных требований) на основе прецедентов использования. • Проектирование архитектуры системы • Структурная декомпозиция системы и привязка операций уровня системы к подсистемам (функциональным или физическим). Определение интерфейсов подсистем. • Проектирование архитектур подсистем • Разделение операций между компонентами подсистем (программными и/или аппаратными). Определение интерфейсов компонентов подсистем. Процесс HARMONY

9. Анализ требований Анализ требований Требования Фиксация требований UC системы Идентификация прецедентов использования системы • Требования импортируются в модель с целью анализа и моделирования • Определяются прецеденты использования системы • Устанавливаются трассировочные связи между требованиями и прецедентами использования Репозиторий модели и требований Процесс HARMONY

10. Пример определения прецедентов Процесс HARMONY

11. Функциональный анализ Цели функционального анализа: • Анализ системы как «черного ящика» (ЧЯ) в каждом прецеденте использования (UC) • Определение сценариев взаимодействия акторов с системой • Определение операций и интерфейсов системы • Проверка модели анализа путём исполнения Процесс HARMONY

12. Моделирование прецедента • В каждом прецеденте система и акторы моделируются с помощью блоков SysML Процесс HARMONY

13. Определение сценариев и операций • В каждом прецеденте для системы определяется множество сценариев взаимодействия с акторами. • Диаграммы последовательности: • Сценарии «Солнечного дня» • Сценарии «Черного дня» • После определения сценариев для системы и акторов определяется множество операций и интерфейсов Процесс HARMONY

14. Спецификация поведения • Для каждого прецедента поведение системы и акторов использования специфицируется с помощью диаграмм состояний • Это позволяет верифицировать и валидироватьмодели анализа путём их исполнения Диаграмма состояния для водителя Диаграмма состояния для автомобиля Диаграмма состояния для GPS спутника Процесс HARMONY

15. Основные создаваемые артефакты • Основные артефакты SysML, создаваемые в ходе разработки системы на основе визуального моделирования Взаимосвязь артефактов функционального анализа Процесс HARMONY

16. Функциональный анализ Анализ требований Требования Фиксация требований UC системы Идентификация прецедентов использования системы Прецеденты использования системы Модель анализа системы как «Черного ящика» Операции системы Сценарии UC «ЧЯ» Функциональный анализ системы Репозиторий модели и требований Репозит. тестовых данных Процесс HARMONY

17. Проектирование архитектуры системы Цель этапа проектирования архитектуры системы: • Сделать структурную декомпозицию системы на подсистемы (функциональные или физические) • Привязать операции уровня системы к определённым подсистемам • Определить результирующие интерфейсы подсистем • Получить проверенную модель архитектуры системы На практике декомпозиция системы и привязка операций является итеративным процессом • Могут быть проанализированы различные возможные архитектуры системы и стратегии привязки операций • Окончательное решение принимается с учётом требований, определённых на этапе анализа требований Процесс HARMONY

18. Определение функциональных подсистем автомобиля Пример функциональной архитектуры Процесс HARMONY

19. Определение физических подсистем для PowerSubsystem (функциональной подсистемы автомобиля) Пример физической архитектуры Процесс HARMONY

20. Пример привязки операций к подсистемам Сценарий ЧЯ для прецедента Начать движение • Привязка операции Автомобиля к физическим подсистемам Сценарий БЯ для прецедента Начать движение Процесс HARMONY

21. Пример спецификации поведения Спецификация поведения для физической подсистемы PowerControlUnit Процесс HARMONY

22. Проектирование архитектуры подсистем Целью этапа является определения как операции подсистем будут реализовываться: • Сделать декомпозицию подсистем на компоненты различных инженерных дисциплин: программные, аппаратные, механические, химические • Привязать операций подсистем к компонентам • Для реализации операций требующих несколько инженерных дисциплин производится дальнейшая декомпозиция Далее действуем также как на этапе определения архитектуры системы • Специфицируем поведение компонентов • Верифицируем и валидируем подсистему путём исполнения Процесс HARMONY

23. HARMONY-SE Анализ требований Требования Фиксация требований UC системы Идентификация прецедентов использования системы Прецеденты использования системы Модель анализа системы Интерфейсы системы Сценарии UC «ЧЯ» Функциональный анализ системы Репозиторий модели и требований Операции уровня системы Модель системной архитектуры с операциями, привязанными к подсистемам Сценарии UC «ЧЯ» Репозит. тестовых данных Архитектурный дизайн Сценарии UC «БЯ» Проектирование архитектуры системы Сценарии UC «БЯ» Проектирование архитектуры подсистем Расширенные сценарии «БЯ» Модели физ. подсистем с операциями, привязанным к компонентам АО/ПО Разработка АО/ПО Процесс HARMONY

24. Модель Rhapsody Полную или отдельные части Проектную документацию, сгенерированную из модели Для печати В формате HTML Исходные файлы (*.h/*.cpp) Интерфейсы Передача работ разработчикам ПО Опционально – может быть легко сгенерированы на основе модели Процесс HARMONY

25. Что получает разработчик ПО • Модель физических подсистем: • Компоненты • С портами и интерфейсами • С определёнными операциями • Спецификации поведения каждого компонента на основе диаграмм состояний • Расширенные сценарии взаимодействиябелого ящика • Для спецификации протоколов взаимодействия по интерфейсам • Нефункциональные требования • Временные ограничения(например на диаграммах последовательности) • Ограничения на качество сервисов Наша Работа сделана! Процесс HARMONY

26. Implementation Testing Unit Testing Integration Testing Validation Testing Translation Iterative Prototypes Detailed Design Incremental Review Prototype Definition Mechanistic Design Design Object Analysis Architectural Design Analysis Стадия разработки ПО Процесс HARMONY

27. Микроцикл HARMONY • Анализ -- идентификация характеристик, которыми должно обладать любое решения для соответствия заданным требованиям; • Дизайн -- оптимизация структуры или поведения системы в соответствии с заданными критериями; • Реализация -- создание корректно работающего компонента или подсистемы; • Тестирование -- получение верифицированной версии системы с хорошо известными возможностями; • Ревизия -- идентификация и корректировка задач, связанных с выполнением всего проекта. Процесс HARMONY

28. Спасибо за внимание! http://www.swd.ru/ 196135, г. Санкт-Петербург, пр. Юрия Гагарина 23 тел.: (812) 702-0833 115553, г. Москва, пр. Андропова 22/30 тел.: (495) 780-8831 Процесс HARMONY