はじめての方のための「早わかりZIPC」

ZIPC Quick Guide

はじめての方のための「早わかりZIPC」

はじめに

ZIPCは、高信頼性が求められる電力制御ソフトウェア開発の中で生まれたCASEツールです。
早期から検証することでソフトウェアの品質を確保するのを支援します。

早期からの検証とは

ソフトウェアはいくつかの段階を経て開発するのが一般的です。この時、作り込めば作り込むほど複雑さは高くなりますが、後工程になるほど検証、修正するのは難しく、コストもかかります。
そこで、各段階で検証できることは検証しておき、早い段階から品質を確保します。

早期からの検証とは

品質確保の4ステップ

ZIPCでは、設計から検証まで4ステップで品質を確保します。

1)モレヌケなく設計

人は組み合わせを網羅的に考えるのは得意ではないので、状態遷移表をかいてモレヌケをなくします。例えば、操作シナリオや状態遷移図から状態遷移表を作成することで、仕様のモレヌケをなくします。ここで見つけたモレヌケには組込み開発で重要な、例外、異常処理などが含まれます。

モレヌケなく設計

2)仕様を動かして確認

日本語で書いた状態遷移表を動かして確認します。動かしてみて気づくこともあるので、この段階で修正します。また、実機ができる前から検証を始められます。

仕様を動かして確認

3)状態遷移表からコードを生成

状態遷移表から自動変換することで、ケアレスミスなくコードを作成します。日本語で書いていた仕様はコンパイラが扱える文字列へ変換する“辞書”を利用して変換します。

4)状態遷移表で実機検証

ZIPCで生成したコードを実機で動かしながら、その様子をほぼリアルタイムに状態遷移表で確認できます。実機試験のときに(設計図である)状態遷移表でカバレッジをとることで品質保証の根拠に利用したり、デバッグ支援に利用します。

状態遷移表からコードを生成

状態遷移表の読み方

状態遷移表の基本要素は4つあります。

  • 状態(State):事象に対して反応を変化させる状況
  • 事象(Event):対象としているシステムへの入力
  • 処理(Action):ある状況における事象に対して行う事柄
  • 遷移(Transition):次の状況

状態遷移表は状態と事象、交差するセルの組み合わせで1つの流れを成しています。

状態遷移表の読み方

なぜ状態遷移表がよいのか?

組込みソフトウェア開発で利用される代表的な設計図としてフローチャートがあります。
フローチャートは着目した流れを追うのに適していますが、網羅的に記述するのには適していません。
状態遷移は、状態と事象における処理が網羅的に見える化されるため、仕様のモレヌケを防ぐのに利用されます。

なぜ状態遷移表がよいのか?

自動生成コードのイメージ

状態遷移表から生成されるコードと実行順序の代表例は以下のようになります。
事象の発生を確認したら、現在の状態に合わせて処理するべき関数を呼び出します。
そして新しい状態に移ります。

自動生成コードのイメージ

ZIPCを利用して得る効果

ZIPCはソフトウェア開発工程を通して次のような効果をあげることができます。

フェーズ 項目 効果
要件定義 表によるモレヌケ防止 要求定義の段階から検証して品質を向上できる
動く仕様書 仕様を動作検証できる
表による最適化分析 最適な機能配置や部品化を分析できる
可視化・可動化による認識の統一 動かして確認することで認識違いがなくなる
表による試験項目 遷移網羅の試験パスが出しやすく、表でカバレッジ測定できる
レビューのしやすさ 視覚的・動的メリットによりレビューしやすい
抽象表記での動作検証 動かすためにコードを書く必要がない
アーキテクチャ
設計
/詳細設定
部分的にデータを混合したシミュレーション 確認したい部分だけコードを記述して動作検証できる
OSを含んだマルチタスクシミュレーション コード化せずにOSを含んだ動作検証が行える
外部連携によるシミュレーション ハードができる前から外観図で検証できる
異常試験環境の構築 実機で出しにくい異常試験が行える
データの流れと構造の分析 シーケンスやタイミングの動作検証ができる
ログの記録 シミュレーションログを記録して後で確認できる
実装 コード生成パターンの選択 実機の性能特性に合わせたコードパターンを選べる
コードの人依存性 コードスタイルが作成者に依存しない
MISRA対応コード 生成コードはMISRA-Cに準拠している
表による実機デバッグ 実機に載せても表で動作検証できる
イベント情報 採用情報
ZIPCセミナーZIPC WATCHERS早わかりZIPCFAQ
CATS