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

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

для встраиваемых систем и приложений реального времени

Дмитрий РыжовМенеджер по продукту

[email protected]

Процесс HARMONY 2

С точки зрения Harmony процесс это:

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

Что такое процесс?


Обзор Harmony

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

Обеспечивает плавный переход от разработки системы к разработке программного обеспечения

Процесс основанный на сценариях: Повторное использование тестовых сценариев на протяжении всего процесса разработки

Поддержан одним инструментом, как результат единая модель для этапов разработки системы и ПО


Временные рамки Harmony

МакрофазаОт начального анализа до

конечной поставки. Обычно от одного до нескольких лет

Фокус на ключевых концепц.

Фокус на уточнении концепций

Фокус на проектировании и реализации

Фокус на оптимиз. и развёртывании

Итерация по созданию одного прототипа. Обычно 4-6 недель

Добавление функциональности и её проверка в микроцикле. Обычно от 30 мин. до 1 дня


Разработка системы(HARMONY-SE)

Макрофаза Harmony

SW Design

Сбор и анализ требований

Системный анализ и

проектирование

Анализ и Проектирование

ПО

Реализация ПО и элементарное тестирование

Интеграция ПО и интегральное тестирование

Функциональное тестирование

Интеграция подсистем и

тестирование

Разработка ПО(HARMONY-SWE)


HARMONY-SE

Функциональный анализ системы

Анализ требований

Фиксация требований

Идентификация прецедентовиспользования системы

Архитектурный дизайн

Проектирование архитектуры системы

Проектирование архитектуры подсистем

Прецеденты использованиясистемы

Операции уровня системы

Разработка АО/ПО

Реп

озит

орий

мод

ели

и тр

ебов

аний

Требования

UC системы

Модель анализа системыИнтерфейсы системы

Реп

озит

. тес

товы

х д

анны

х

Сценарии UC «ЧЯ»

Модель системной архитектуры соперациями, привязанными к подсистемам

Модели физ. подсистемс операциями, привязаннымк компонентам АО/ПО


Сценарии UC «БЯ»


Расширенные сценарии «БЯ»


Итеративная разработка ПО

Приемочное тестирование

Разработка ПО (HARMONY-SWE)

Разработка системы(HARMONY-SE)

Требования, сценарии и др.

артефактыТестовые сценарии

Система, прошедшая валидацию и верификацию

Модель анализа, модели архитектуры системы и подсистем

Анализ

Ревизия

Дизайн

Реализация Тестирование

Мод

ель


Обзор HARMONY-SE

Анализ требований Фиксирование требований и группировка их в прецеденты

использования. Функциональный анализ системы

Идентификация и верификация/валидация операций системы (т.е. множества функциональных требований) на основе прецедентов использования.

Проектирование архитектуры системы Структурная декомпозиция системы и привязка операций уровня

системы к подсистемам (функциональным или физическим). Определение интерфейсов подсистем.

Проектирование архитектур подсистем Разделение операций между компонентами подсистем

(программными и/или аппаратными). Определение интерфейсов компонентов подсистем.






Реп

озит

орий

мод

ели

и тр

ебов

аний


UC системы

Требования импортируются в модель с целью анализа и моделирования

Определяются прецеденты использования системы

Устанавливаются трассировочные связи между требованиями и прецедентами использования


Пример определения прецедентов

Водитель

Владелец

Обслу живающий персонал

Страхов ая компания

ГИБДД

Управ лениеав томобилем

Страхов аниеав томобиля

Регистрацияав томобиля

Обслу живание ав томобиля

Регистрация в сети

Сеть

«Network»

Нав игацияав томобиля GPS спу тник


Функциональный анализ

Цели функционального анализа: Анализ системы как «черного ящика» (ЧЯ) в каждом

прецеденте использования (UC) Определение сценариев взаимодействия акторов с

системой Определение операций и интерфейсов системы Проверка модели анализа путём исполнения


Моделирование прецедента

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


Определение сценариев и операций

В каждом прецеденте для системы определяется множество сценариев взаимодействия с акторами.

Диаграммы последовательности:- Сценарии «Солнечного дня»- Сценарии «Черного дня»

После определения сценариев для системы и акторов определяется множество операций и интерфейсов

driver

1.StartVehicle

hybridSUV


Спецификация поведения

Для каждого прецедента поведение системы и акторов использования специфицируется с помощью диаграмм состояний

Это позволяет верифицировать и валидировать модели анализа путём их исполнения

Off

Operate

Idle

Brak ing

stopped

AcceleratingCruising

accelerateCmd

brakeEngaged

brakeDisengaged

accelerateCmd

startCar/EnablePower();

shutCarOff/DisablePower();

IdleDriveToWork

END1

evDriveToWork

END1

evHeavyAccel

HeavyAccel

END2END2

Idle

evEngage/OPORT(pVehicle)->GEN(evSatEngaged);

Engaged

evDisengage

tm(1000)/OPORT(pVehicle)->GEN(evGPSTime(gpsTime,satPosition));moveSatellite();

Диаграмма состояния для водителя

Диаграмма состояния для GPS спутника

Диаграмма состояния для автомобиля


Основные создаваемые артефакты

Основные артефакты SysML, создаваемые в ходе разработки системы на основе визуального моделирования

Взаимосвязь артефактов функционального анализа


Функциональный анализ






Реп

озит

орий

мод

ели

и тр

ебов

аний


UC системы

Модель анализа системы как «Черного ящика»Операции системы

Реп

озит

. тес

товы

х д

анны

х




Цель этапа проектирования архитектуры системы: Сделать структурную декомпозицию системы на

подсистемы (функциональные или физические) Привязать операции уровня системы к определённым

подсистемам Определить результирующие интерфейсы подсистем Получить проверенную модель архитектуры системы

На практике декомпозиция системы и привязка операций является итеративным процессом

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

Окончательное решение принимается с учётом требований, определённых на этапе анализа требований


Пример функциональной архитектуры

Hybrid SUV«block»

bodySubsystem1

pIntSS

pLitSS

pChSS

chassisSubsystem1

pBdySS

pBrSS

pPwrSS

brakeSubsystem1

pLitSS

pChSS

pPwrSS

interio rSubsystem1

pNavSS

pBdySS

pLitSS

pComSS

lightin gSubsystem1

pBrSS

pBdySS

pIntSS

powerSubsystem1

pChSS pBrSS

commsSubsystem1 «block»

pCom

pIntSS

navigationSubsystem1 «block»

pNavpIntSS

pNavpCom

pIntSS

pLitSS

pChSSpBdySS

pBrSS

pPwrSS

pLitSS

pChSS

pPwrSS

pNavSS

pBdySS

pLitSS

pComSS

pBrSS

pBdySS

pIntSSpChSS pBrSS

pCom

pIntSSpNav

pIntSS

pNavpCom

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


Пример физической архитектуры

PowerSubsystem«block»

bp:BatteryPack1 «block»

ac l:Accelerator1 «block»

ecu:PowerControlUnit1 «block»

I_ECU_BrakeSS

pBrSS

I_T rans

pT rans

I_ElecCtrl

pEPC

I_ICECmds I_ICEData

pPS

epc:Elec tricalPowerController1 «block»

pEMG:

I_ElecCtrl

pECU

CAN_Bus3

emg:Elec tricMotorGenerator1 «block»

pT rans :

pEPC:i1:Elec tricCurrent

i2:Elec tricCurrent

trsm:T ransmiss ion1 «block»

pDiff:

pEMG:

pICE:

I_T ranspECU

CAN_Bus2

ft:FuelT ankAssy1 «block»

fp:FuelPump1 «block» p: Port:FuelT ankFitting

dif:Differential1 «block»

pChSS

pT rans :

spline

t2:Torque

t1:Torqueice:InternalCombustionEngine1 «block»

fi :FuelInjec tor4 «block»

pT rans :

g1:Torque

Port:EngineFuelFitting

fuelDelivery

fuelSupply:Fuel fuelReturn:Fuel

I_ICEData

I_ICECmds

pECUCAN_Bus1

pChSS

pBrSS

pBrSS

I_ECU_BrakeSS

pT rans

I_T rans

pEPC

I_ElecCtrl

I_ICECmds

pPS

I_ICEData

pEMG:

pECU

I_ElecCtrl

pT rans :

pEPC:

pDiff:

pEMG:

pICE:

I_T ranspECU

p: Port:FuelT ankFitting

pChSS

pT rans :

pT rans :

Port:EngineFuelFitting

I_ICECmds

pECU

I_ICEDatapChSS

pBrSS

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


Пример привязки операций к подсистемам

водитель:Водитель

1. StartVehicle()

автомобиль:HybridSUV ref Сценарий БЯ начала

движения

ENV ecu:PowerControlUnit

1. StartVehicle()

2. Enable()

epc:ElectricalPowerController

3. Ready()

Сценарий ЧЯ для прецедента Начать движение

Сценарий БЯ для прецедента Начать движение

Привязка операции Автомобиля к физическим подсистемам


Пример спецификации поведения

DetermineAcceleration() DetermineLoBattery()

AccelGasElec() RegenBrake() ChargeStationary()

[loBat]

[Vehic leState==STAT IONARY]

[else]

RegenFrictionBrake()

Heavy Mild

[Vehic leState==DECEL]

AccelElec() AccelGas() ChargeCruise()

Heavy None

[Vehic leState==ACCEL_CRUISE]

Low BatMild

Init

StandByKeyOff

evEnablePower/keyOn=true;OPORT(pT rans)->GEN(evTransPowerOn);

[else]

evGo

[keyOn]

evDisablePower/keyOn=false;

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



Целью этапа является определения как операции подсистем будут реализовываться:

Сделать декомпозицию подсистем на компоненты различных инженерных дисциплин: программные, аппаратные, механические, химические

Привязать операций подсистем к компонентам Для реализации операций требующих несколько инженерных

дисциплин производится дальнейшая декомпозиция

Далее действуем также как на этапе определения архитектуры системы

Специфицируем поведение компонентов Верифицируем и валидируем подсистему путём исполнения


HARMONY-SE





Архитектурный дизайн




Операции уровня системы

Разработка АО/ПО

Реп

озит

орий

мод

ели

и тр

ебов

аний


UC системы

Модель анализа системыИнтерфейсы системы

Реп

озит

. тес

товы

х д

анны

х


Модель системной архитектуры соперациями, привязанными к подсистемам

Модели физ. подсистемс операциями, привязаннымк компонентам АО/ПО




Расширенные сценарии «БЯ»


Передача работ разработчикам ПО

Модель Rhapsody Полную или отдельные части

Проектную документацию, сгенерированную из модели Для печати В формате HTML

Исходные файлы (*.h/*.cpp) Интерфейсы

Опционально – может быть

легко сг

енерированы на основе модели


Что получает разработчик ПО

Модель физических подсистем: Компоненты С портами и интерфейсами С определёнными операциями Спецификации поведения

каждого компонента на основе диаграмм состояний

Расширенные сценарии взаимодействия белого ящика Для спецификации протоколов

взаимодействия по интерфейсам Нефункциональные требования

Временные ограничения (например на диаграммах последовательности)

Ограничения на качество сервисов


Стадия разработки ПО

MechanisticDesign

DetailedDesign

Translation

UnitTesting

Integration Testing

ArchitecturalDesign

Object Analysis

PrototypeDefinition

Validation Testing

Incremental Review

Iterative Prototypes


Микроцикл HARMONY

Анализ -- идентификация характеристик, которыми должно обладать любое решения для соответствия заданным требованиям;

Дизайн -- оптимизация структуры или поведения системы в соответствии с заданными критериями;

Реализация -- создание корректно работающего компонента или подсистемы;

Тестирование -- получение верифицированной версии системы с хорошо известными возможностями;

Ревизия -- идентификация и корректировка задач, связанных с выполнением всего проекта.


196135, г. Санкт-Петербург, пр. Юрия Гагарина 23тел.: (812) 702-0833

Спасибо за внимание!

115553, г. Москва, пр. Андропова 22/30тел.: (495) 780-8831

http://www.swd.ru/

Documents

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