Harmony Процесс разработки на основе визуального моделирования для встраиваемых систем и приложений реального времени Дмитрий Рыжов Менеджер по продукту d.ryzhov@swd.ru Что такое процесс? С точки зрения Harmony процесс это: Спецификация серии последовательных деятельностей, выполняемых группой взаимодействующих специалистов, в результате которой создается когерентное множество артефактов, одним из которых является требуемая система Процесс HARMONY 2 Обзор Harmony Гибридный итеративный процесс разработки на основе визуального моделирования, поддерживающий Последовательную разработку систем (Harmony-SE) и Итеративную разработку ПО (Harmony-SWE) Обеспечивает плавный переход от разработки системы к разработке программного обеспечения Процесс основанный на сценариях: Повторное использование тестовых сценариев на протяжении всего процесса разработки Поддержан одним инструментом, как результат единая модель для этапов разработки системы и ПО Процесс HARMONY 3 Временные рамки Harmony От начального анализа до конечной поставки. Обычно от одного до нескольких лет Макрофаза Фокус на ключевых концепц. Фокус на уточнении концепций Фокус на проектировании и реализации Фокус на оптимиз. и развёртывании Добавление функциональности и её проверка в микроцикле. Обычно от 30 мин. до 1 дня Процесс HARMONY Итерация по созданию одного прототипа. Обычно 4-6 недель 4 Макрофаза Harmony Разработка системы (HARMONY-SE) Сбор и анализ требований Функциональное тестирование Разработка ПО (HARMONY-SWE) Системный анализ и проектирование Интеграция подсистем и тестирование Анализ и Проектирование SW Design ПО Интеграция ПО и интегральное тестирование Реализация ПО и элементарное тестирование Процесс HARMONY 5 HARMONY-SE Анализ требований Фиксация требований UC системы Идентификация прецедентов использования системы Прецеденты использования системы Сценарии UC «ЧЯ» Модель анализа системы Интерфейсы системы Функциональный анализ системы Модель системной архитектуры с операциями, привязанными к подсистемам Операции уровня системы Архитектурный дизайн Проектирование архитектуры системы Проектирование архитектуры подсистем Модели физ. подсистем с операциями, привязанным к компонентам АО/ПО Сценарии UC «ЧЯ» Сценарии UC «БЯ» Сценарии UC «БЯ» Расширенные сценарии «БЯ» Разработка АО/ПО Процесс HARMONY 6 Репозит. тестовых данных Репозиторий модели и требований Требования Итеративная разработка ПО Тестовые сценарии Модель Разработка системы (HARMONY-SE) Требования, сценарии и др. артефакты Модель анализа, модели архитектуры системы и подсистем Реализация Приемочное тестирование Система, прошедшая валидацию и верификацию Тестирование Ревизия Дизайн Анализ Разработка ПО (HARMONY-SWE) Процесс HARMONY 7 Обзор HARMONY-SE Анализ требований Фиксирование требований и группировка их в прецеденты использования. Функциональный анализ системы Идентификация и верификация/валидация операций системы (т.е. множества функциональных требований) на основе прецедентов использования. Проектирование архитектуры системы Структурная декомпозиция системы и привязка операций уровня системы к подсистемам (функциональным или физическим). Определение интерфейсов подсистем. Проектирование архитектур подсистем Разделение операций между компонентами подсистем (программными и/или аппаратными). Определение интерфейсов компонентов подсистем. Процесс HARMONY 8 Анализ требований Анализ требований Репозиторий модели и требований Требования UC системы Фиксация требований Идентификация прецедентов использования системы Требования импортируются в модель с целью анализа и моделирования Определяются прецеденты использования системы Устанавливаются трассировочные связи между требованиями и прецедентами использования Процесс HARMONY 9 Пример определения прецедентов Управ ление ав томобилем Нав игация ав томобиля GPS спу тник Водитель Страх ов ание ав томобиля Страх ов ая компания Владелец Регистрация ав томобиля Обс лу живани е ав томобиля Регистрация в сети ГИБДД «Network » Hybrid SUV Обс лу живающий перс онал Hybrid SUV Requirements Сеть Процесс HARMONY 10 Функциональный анализ Цели функционального анализа: Анализ системы как «черного ящика» (ЧЯ) в каждом прецеденте использования (UC) Определение сценариев взаимодействия акторов с системой Определение операций и интерфейсов системы Проверка модели анализа путём исполнения Процесс HARMONY 11 Моделирование прецедента В каждом прецеденте система и акторы моделируются с помощью блоков SysML Процесс HARMONY 12 Определение сценариев и операций В каждом прецеденте для системы определяется множество сценариев взаимодействия с акторами. driver hybridSUV Диаграммы последовательности: - Сценарии «Солнечного дня» - Сценарии «Черного дня» 1.StartVehicle После определения сценариев для системы и акторов определяется множество операций и интерфейсов Процесс HARMONY 13 Спецификация поведения Для каждого прецедента поведение системы и акторов использования специфицируется с помощью диаграмм состояний Это позволяет верифицировать и валидировать модели анализа путём их исполнения Диаграмма состояния для водителя Idle Диаграмма состояния для автомобиля DriveToWork evDriveToWork Off Refines PowerSource Management END1 start Car/ EnablePower(); shut CarOff/ DisablePower(); HeavyAccel evHeavyAccel Operate END2 Idle stopped accelerateCmd Диаграмма состояния для GPS спутника AcceleratingCruising brak eDisengaged Brak ing brak eEngaged tm(1000)/ OPORT(pVehicle)->GEN(evGPSTime(gpsTime,satPosition)); moveSatellite(); accelerateCmd Engaged Idle evDisengage evEngage/ OPORT(pVehicle)->GEN(evSatEngaged); Процесс HARMONY 14 Основные создаваемые артефакты Основные артефакты SysML, создаваемые в ходе разработки системы на основе визуального моделирования Взаимосвязь артефактов функционального анализа Процесс HARMONY 15 Функциональный анализ Анализ требований UC системы Фиксация требований Идентификация прецедентов использования системы Модель анализа системы как «Черного ящика» Операции системы Прецеденты использования системы Сценарии UC «ЧЯ» Функциональный анализ системы Процесс HARMONY 16 Репозит. тестовых данных Репозиторий модели и требований Требования Проектирование архитектуры системы Цель этапа проектирования архитектуры системы: Сделать структурную декомпозицию системы на подсистемы (функциональные или физические) Привязать операции уровня системы к определённым подсистемам Определить результирующие интерфейсы подсистем Получить проверенную модель архитектуры системы На практике декомпозиция системы и привязка операций является итеративным процессом Могут быть проанализированы различные возможные архитектуры системы и стратегии привязки операций Окончательное решение принимается с учётом требований, определённых на этапе анализа требований Процесс HARMONY 17 Пример функциональной архитектуры Определение функциональных подсистем автомобиля «block» Hybrid SUV «block» 1 «block» 1 commsSubsystem navigation Subsystem pCom pIntS S pCom pNav pNav pIntS S 1 1 bodyS ubsystem chassisS ubsyst em pB dyS S pChSS 1 pIntS S interio rSubsystem pNavS S pLitS S pComSS pP wrS S pB rS S 1 pB dyS S brakeSubsystem pLitS S pChSS pP wrS S 1 pLitS S powerSubsystem 1 lightin gSubsystem pB dyS S pChSS pIntS S pB rSS pB rSS Процесс HARMONY 18 Пример физической архитектуры Определение физических подсистем для PowerSubsystem (функциональной подсистемы автомобиля) «block » P owerS ubs ys tem «block » 1 «block » 1 epc :E lec tricalP owerController «block » 1 emg:E lec tricMotorGenerator bp:BatteryP ac k i2:Elec tric Current pE PC: pE MG: i1:Elec tric Current pT rans : pE CU I_E lec Ctrl «block » 1 «block » 1 ac l:Ac c elerator trs m:T rans mis s ion CA N_B us 3 pE MG: I_T rans pE CU «block » 1 ec u:P owerControlUnit I_E CU_B rakeS S pDiff: pE PC I_E lec Ctrl pB rSS pICE: CA N_B us 2 pT rans pP S g1:Torque t2:Torque I_T rans pB rSS s pline 1 I_ICE Cmds pT rans : I_ICE Data I_ICE Data CA N_B us 1 «block » 1 ic e:InternalCombustionE ngine pE CU «block » dif:Differential t1:Torque pChS S pChS S pT rans : 4 «block » fi:FuelInjec tor I_ICE Cmds «block » 1 ft:FuelT ankAs s y P ort:E ngineFuelFitting 1 «block » fp:FuelP ump p: fuelDelivery P ort:FuelT ankFitting fuelSupply:Fuel fuelReturn:Fuel Процесс HARMONY 19 Пример привязки операций к подсистемам Привязка операции Автомобиля к физическим подсистемам Сценарий ЧЯ для прецедента Начать движение водитель:Водитель 1. StartVehicle() автомобиль:HybridSUV ref Сценарий БЯ начала движения Сценарий БЯ для прецедента Начать движение ENV ecu:PowerControlUnit epc:ElectricalPowerController 1. StartVehicle() 2. Enable() 3. Ready() Процесс HARMONY 20 Пример спецификации поведения Спецификация поведения для физической подсистемы PowerControlUnit evE nablePower/ keyOn=true; OP ORT(pT rans)->GEN(evTransP owerOn); Init evGo StandByKeyOff [els e] [keyOn] evDis ableP ower/ keyOn=fals e; DetermineLoB attery() DetermineA cc eleration() [Vehic leState==A CCE L_CRUISE ] [Vehic leState==S TAT IONA RY ] [loB at] [Vehic leState==DECE L] Heavy Ac c elGasE lec () Mild Ac c elElec() Low B at Ac c elGas() None Heavy ChargeCruise() RegenFrictionBrake() Mild RegenBrake() ChargeS tationary() [els e] Процесс HARMONY 21 Проектирование архитектуры подсистем Целью этапа является определения как операции подсистем будут реализовываться: Сделать декомпозицию подсистем на компоненты различных инженерных дисциплин: программные, аппаратные, механические, химические Привязать операций подсистем к компонентам Для реализации операций требующих несколько инженерных дисциплин производится дальнейшая декомпозиция Далее действуем также как на этапе определения архитектуры системы Специфицируем поведение компонентов Верифицируем и валидируем подсистему путём исполнения Процесс HARMONY 22 HARMONY-SE Анализ требований Фиксация требований UC системы Идентификация прецедентов использования системы Прецеденты использования системы Сценарии UC «ЧЯ» Модель анализа системы Интерфейсы системы Функциональный анализ системы Модель системной архитектуры с операциями, привязанными к подсистемам Операции уровня системы Архитектурный дизайн Проектирование архитектуры системы Проектирование архитектуры подсистем Модели физ. подсистем с операциями, привязанным к компонентам АО/ПО Сценарии UC «ЧЯ» Сценарии UC «БЯ» Сценарии UC «БЯ» Расширенные сценарии «БЯ» Разработка АО/ПО Процесс HARMONY 23 Репозит. тестовых данных Репозиторий модели и требований Требования Передача работ разработчикам ПО Модель Rhapsody Полную или отдельные части Исходные файлы (*.h/*.cpp) Интерфейсы Проектную документацию, сгенерированную из модели Для печати В формате HTML Процесс HARMONY 24 Что получает разработчик ПО Модель физических подсистем: Компоненты С портами и интерфейсами С определёнными операциями Спецификации поведения каждого компонента на основе диаграмм состояний Расширенные сценарии взаимодействия белого ящика Для спецификации протоколов взаимодействия по интерфейсам Нефункциональные требования Временные ограничения (например на диаграммах последовательности) Ограничения на качество сервисов Процесс HARMONY 25 Стадия разработки ПО Unit Testing Integration Testing Translation Validation Testing Detailed Design Incremental Review Prototype Definition Mechanistic Design Architectural Design Процесс HARMONY Object Analysis 26 Микроцикл HARMONY Анализ -- идентификация характеристик, которыми должно обладать любое решения для соответствия заданным требованиям; Дизайн -- оптимизация структуры или поведения системы в соответствии с заданными критериями; Реализация -- создание корректно работающего компонента или подсистемы; Тестирование -- получение верифицированной версии системы с хорошо известными возможностями; Ревизия -- идентификация и корректировка задач, связанных с выполнением всего проекта. Процесс HARMONY 27 Спасибо за внимание! http://www.swd.ru/ 196135, г. Санкт-Петербург, пр. Юрия Гагарина 23 тел.: (812) 702-0833 Процесс HARMONY 115553, г. Москва, пр. Андропова 22/30 тел.: (495) 780-8831 28