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

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