オブジェクトの広場は株式会社オージス総研グループのエンジニアによる技術発表サイトです

技術講座

システムエンジニアリングで
SysML を使いこなす

第2章 実践編-電光掲示板を設計する(1)

※本稿は、技術評論社刊『組込みプレス Vol.18』に掲載された特集記事「特集2 システムエンジニアリングで SysML を使いこなす」の転載です。 技術評論社の了承を得て転載しています。 本稿については、一切の転載をお断りします。

株式会社オージス総研
ソリューション開発本部 組み込みソリューション部
青木 淳
2010年7月8日

第2章 実践編-電光掲示板を設計する

2.1. プロセスと対象システム

実践編では、システムエンジニアリングプロセスを実施しながら、その中で SysML を利用する形式で SysML のダイアグラムを解説していきます。 文中で <<SysML>> と表記されている部分が SysML 仕様の解説をしている部分になります。

本編を始める前に、本記事のエンジニアリングプロセスと分析対象となるシステムについて説明します。

2.1.1. 本記事のエンジニアリングプロセス

本記事のシステム検討に適用するシステムエンジニアリングプロセスは、JIS X0170 規定のプロセスに対応させると、利害関係者要求定義プロセスを省略した要求分析プロセスと方式設計プロセスとなります。 しかし、SysML のダイアグラム説明に主眼を置いている関係上、各工程の中身は JIS X0170 に規定されているアクティビティを実施している訳ではなく、簡単にした独自のアクティビティです。

図 1 本記事のシステムエンジニアリングプロセスアクティビティ
図 1 本記事のシステムエンジニアリングプロセスアクティビティ

図 1 に本記事のシステムエンジニアリングアクティビティを示します。 また、SysML の使い方は本記事のシステムエンジニアリングプロセスでの使用例であり、SysML でエンジニアリングプロセスを規定しているわけではありません。 1.3 で SysML には標準の「ビュー」が定義されていないことを説明しました。 本記事のプロセスでは、「ビュー」を図 2 のように定義します。

物理ビューでは CPU/メモリ/ボタン/スイッチなど、システムの物理的構成要素を記述します。

論理ビューでは通信や表示など、システムの機能を論理的構成要素として記述し、要求を実現するための振る舞いの記述も含まれます。 パフォーマンスビューでは要求の性能面の評価を記述します。 要求は論理構成に割り当てられ、論理構成は物理構成に割り当てられます。

図 2 本記事のプロセスのビュー構成
図 2 本記事のプロセスのビュー構成

このビュー構成にはコストや消費電力が組み込まれていないので、すべてを表している訳ではありません。 しかし、ハードやソフトの切り分けを主目的とするシステムエンジニアリングでは参考になると思います。

<<SysML>>

ビュー構成には SysML のパッケージ図を利用しています。 パッケージ図はモデル要素をグループ化して関連性を表現するのに用い、UML からの変更点はありません。 ただし、1.3 で説明したように、パッケージにステレオタイプ <<view>> が設定されている場合はビューという解釈します。

図中でフォルダアイコンのような形をしている図形がパッケージで、この中にパッケージ名に関連するさまざまなモデル要素が入っていることを表します。

2.1.2. 対象システム

本記事では簡単な事例として電光掲示板システムを取り上げます。 32×16 ドットの Matrix LED を使ったシステムで、以前 Matrix LED の制御をすべてソフトウェアで行っていたシステムに対し、システムの一部をハードウェア (CPLD) に置き換える検討を、SysML を用いて行うという設定です。

初期ハードウェア制約として存在している利用部品を表 1 に示します。

表 1 利用部品
表 1 利用部品

この部品を可能な限り利用することを考えます。 なお、この部品は実際に弊社で社内教育用に用意しているハードウェアであり、本記事の実践のために実際に CPLD で表示の確認まで行っております。

CPLD は内部回路を書き換えることが可能な電子デバイスの 1 つで、比較的回路規模が小さいものを指します。 回路規模が大きくなると FPGA と呼ばれますが、名称に明確な規定がある訳ではありません。

CPLD は逐次処理には適しませんが、同時処理であれば電気レベルの遅延時間で処理が終わるといった特徴があります。 内部回路を書き換えるという点で CPU のソフトウェアプログラミングと同様のイメージを与えますが、「命令を逐次実行」する CPU とは異なり、プログラミングの結果が生成されるのは「回路」なのです。

システムのどの部分を CPU に処理させ、どの部分をハードウェアデバイスに処理させるかはシステム設計時のトレードオフのひとつなので、本記事の適用システムとして採用しました。

2.2. 要求分析

要求分析工程のゴールを「システム境界を明確にし、システム外部とのインターフェースを明確にする」と設定します。 したがって、システムの内部構造は一切検討しません。

要求分析はサービスレベルとシステムレベルに分けて行います。 サービスレベルでは、ステークホルダ (利害関係者) の目的を基にシステムを分析し、システム境界を明確にします。 システムレベルではステークホルダの目的をシステムが実現する手段を基に分析し、システム仕様を詳細化していきます。

2.2.1. サービスレベル要求分析

ここでは図 3 の流れに沿って検討を進めます。

図 3 サービスレベル要求分析
図 3 サービスレベル要求分析
(1) ユースケース分析

図 4 にサービスレベルのユースケース図を示します。

図 4 サービスレベルユースケース
図 4 サービスレベルユースケース

本記事の目的は組込み機器開発者がシステムエンジニアリングを経験することであり、商品開発ではありません。 したがって、以降のシステムエンジニアリングにおける判断は通常の商品開発とは異なる選択をすることがあることをご了承下さい。

このユースケースの時点では漠然とした目的のみが決定され、詳細は未検討のままです。

<<SysML>>

ユースケース図は、システムの外部から求められる機能的な要求を表現する図で、UML からの変更点はありません。

楕円がユースケースで、システム外部から識別できる機能単位で記述します。 よく内部処理の単位でユースケースが書かれている例を見ますが、これは間違いです。 外部から識別できる機能に着目します。

人型をしている図形はアクターと呼ばれ、システムのステークホルダ (利害関係者) を表します。 本記事の図ではステークホルダは 1 種類しかありませんが、通常システムにはさまざまなステークホルダが存在しています。 システムに関与するステークホルダーは、それぞれシステムに対して異なる要求を持っているので、要求を検討する上でステークホルダーに抜け漏れがないように注意しましょう。

(2) 非機能的要求検討

ユースケースはシステムの機能的側面を表しているに過ぎないので、要求図を用いて性能や設計制約などの機能に付随する要求を明確にします。

図 5 にサービスレベルの要求図を示します。

図 5 サービスレベル要求図
図 5 サービスレベル要求図

サービスレベルのユースケースは SysML の「割り当て」によって同名の要求に割り当てられていますが、この割り当ては本記事のプロセス特有のルールです。 これにより要求分析対象のユースケースが特定できるようになります。

要求は機能要求 (<<functionalRequirement>>)、設計制約 (<<designConstraint>>) から検討され、「CPLD を使用する」「既存の電光掲示板システムを流用する」という 2 つの派生要求 (<<deriveReqt>>) を定義しています。 「CPLD ならハードウェア回路の変更が容易」であるとしています。

最終的に「電光掲示板を CPLD 駆動に変更する」と元の要求を洗練 (<<refine>>) しています。

<<SysML>>

要求図は UML には存在しない SysML 独自のダイアグラムで、非機能的要求を含めた要求を記述するために用いられます。

要求は複数の要求の集合として表すことができ、ネストを用いて表現します。 要求にはさまざまな種類があり、ユーザが独自にステレオタイプ <<requirement>> を拡張しても良いことになっています。 SysML1.1 の仕様書では、付録に規定外拡張として以下の拡張ステレオタイプが記されています (表 2)。

これら要求の拡張をシステムエンジニアリングプロセスで独自に規定し、要求分析時に検討しなければならない要求の側面として位置づけることにより、要求分析時の検討不足低減に繋がることが期待されます。

表 2 要求の拡張
表 2 要求の拡張

要求間の関連はステレオタイプ <<deriveReqt>><<refine>> を含め、表 3 のように種類が規定されています。

表 3 要求間の関連ステレオタイプ一覧
表 3 要求間の関連ステレオタイプ一覧

すでに 1.3 で述べましたが、「割り当て」の概念も SysML で新しく取り入れられました。 基本的には要素間の抽象的マッピングといった汎用的な意味で、実装への変換が可能な (モデリングツールが自動生成できるような) 具体的関係を示すためではありません。

典型的な例は機能のブロックへのマッピングやブロック操作のソフトウェアへのマッピングなどです。

本記事のプロセスではユースケースから要求へマッピングしています。 しかし、構造的には要求の一部である機能要求 (<<functionalRequirement>>) を、機能を記述するユースケースへマッピングするほうが自然でしょう。 本記事のマッピングの意図は、先にユースケース分析を実行して機能的要求を検討したあとで、ユースケースに関連した非機能的要求を検討することにあります。 筆者のコンサルタントとしての経験上、開発者は要求分析時に要求の機能的側面のみに注力しすぎる傾向があるようです。 そこで、組込みシステムでは 8 割を占めるとも言われる非機能的側面を検討することを促すためにこのようにしました。

要求図では関連のノートにもステレオタイプが規定されています。 図中の <<rationate>> と、それ以外にも <<problem>> があります。

<<rationate>> ではその要求が必要な根拠を記述します。 図ではノート中に根拠を示していますが、科学的な実験結果などが参照されることも多いです。

<<problem>> は要求に関連した問題を記述します。 過去不具合があったとか、技術的課題があるなどが典型的な例です。

(3) コンテキスト図作成

開発対象が具体的になったので、コンテキスト図を作成し開発対象に対するイメージを明確にします (図 6)。

本記事で作るシステムはスクロール可能な電光掲示板ですが、表示する文字列を入力する装置はステレオタイプ <<external>> をつけて開発対象外であるとしています。 なお、電光掲示板のグラフィックは仮のイメージであり、本記事で開発するもののイメージをそのまま表しているわけではありません。

図 6 コンテキスト図
図 6 コンテキスト図
<<SysML>>

コンテキスト図は SysML に規定されている図ではありません。 SysML1.1 の仕様書付録 B に内部ブロック図をコンテキスト図として応用する例が示されていますので、それに倣いました。

2.2.2. システムレベル要求分析

ここでは図 7 の流れに沿って検討を進めます。

図 7 システムレベル要求分析
図 7 システムレベル要求分析
(1) ユースケース分析

図 8 にシステムレベルのユースケース図を示します。

図 8 システムレベルユースケース
図 8 システムレベルユースケース

図 6 コンテキスト図の内容をユースケース図で記述しました。 「スクロールする」機能は文字列が表示領域より長かった場合のみなので <<extend>> としています。 文字列は一度設定すると変更されない限り同じ文字列を表示し続けるため、「表示する文字列を設定する」ユースケースは「文字列を表示する」ユースケースから独立したユースケースとしました。

(2) 非機能的要求検討
A) 判明している要求の確認

サービスレベル要求分析およびシステムレベルユースケースから判明している要求を、要求図にまとめて図 9 に示します。

図 9 システムレベル要求 (初期)
図 9 システムレベル要求 (初期)

システムレベルユースケース図から機能的要求 3 件、サービスレベル要求分析から制約条件が 1 件判明しています。

"RefineBy 物理構成" と書かれているノートは関連のノート形式記述で、この図に表れていない「物理構成」で詳細に説明されていることを意味します。

 
B) 利用予定ハードウェアの調査

図 10 に、サービスレベルの要求分析で検討したハードウェア構成をブロック定義図に示します。

図 10 物理構成のブロック定義図
図 10 物理構成のブロック定義図

電子掲示板で利用予定のハードウェアは CPLD ユニットと CPU 基板で、CPU 基板には CPU ユニットの他に LED が 2 つ、ディップスイッチが 1 つ、Matrix LED ユニットが 1 つ含まれています。

CPLD ユニットのクロック周波数と I/O 規格には設計の余地がありますが、3.3V 駆動のため、I/O 規格は 3.3V 駆動のものに限られます。 回路規模が 240LE とかなり小規模 (全部メモリにすると 30 バイト分にもならない) なので、CPLD に可能なことはかなり限られてきます。 外部との I/F には未定義の I/O 端子を利用できます。

CPU 基板では、外部との I/F に RS-232C/Ethernet および未定義の I/O ポートを利用できます。 CPU 基板から多重度 2 で接続されている LED は、CPU 基板のパーツとして led_g、led_r の 2 つの LED として表現されていることがわかります。

CPU ユニットのクロック周波数は 20MHz で、利用可能な ROM、RAM サイズが明記されています。 5.0V 駆動の TTL となっているので、4.6V 以上の電圧をかけられない CPLD ユニットはそのまま接続できないことがわかります。

Matrix LED ユニットは 32×16 ドット表示可能で、クロック周波数は 0.3MHz 未満でなくてはなりません。

<<補足>>

ソフト担当者はあまり考慮することはありませんが、デジタル論理の 0/1 は物理的には電圧です。

たとえば 5.0V 駆動の場合、電圧が 0.0V なら 0、5.0V なら 1 となるのはよいとして、2.5V だった場合どちらになるのかという問題が発生します。

これを決定する規格のことを I/O 規格といい、駆動電圧が同じでも I/O 規格が一致していないとハードウェアはまともに動きません。 ちなみに TTL では入力が 0.8V 以下なら 0、2.0V 以上なら 1、それ以外は不定です。

<<SysML>>

ブロック定義図は UML におけるクラス図を拡張した図で、SysML の中で中核をなす図です。 すでに 1.3 で述べていますが、クラスの概念を拡張したものがブロックで、さまざまなプロパティ (ユーザー定義も可能) を設定できます。 代表的なプロパティは表 4 の通りです。

表 4 ブロックのおもなプロパティ
表 4 ブロックのおもなプロパティ

なお、プロパティは振る舞いに関する記述に対してではなく、構造に関する記述に対して用います。 振る舞いは、操作で表現します。

ブロック定義図はブロックの構造を表現するとともに、ブロックの内容を定義するのに用いる図です。 UML のクラス図に比べると使用可能な関連が大幅に制限され、基本は黒菱形のコンポジションと実線矢印で表される参照関連の 2 種類となります。 白菱形の共存や汎化も利用可能となっています。 図では要求分析のための資料という位置づけのため汎化を用いていませんが、たとえば、本記事の例ではクロック周波数を持つものは同期型ブロックとするなど、ブロックに共通する概念を抽象ブロックとすることが可能です。

コンポジションで関連づけられるブロック構造は、黒菱形がついているブロックに黒菱形がついていないブロックが含まれる包含関係を表しています。 たとえば機能を構造展開する場面で利用できますが、ブロック内部の区画に現れる場合はブロックのインスタンスであるパーツの形で表現されます。 図 10 ではブロック「CPU 基板」にブロック「LED」が多重度 2 で関連づけられていますが、ブロック「CPU 基板」の parts 区画に表現されているブロック「LED」要素は led_g、led_r という 2 つのパーツに具体化しています。

このように、ブロック定義図では関連による階層構造の表現は UML でいうところのクラスレベルの表現となり、ブロック内部の区画に現れるプロパティは UML でいうところの属性表現のイメージになります。

ブロックのプロパティはパーツ以外にも 表 4 のようにさまざまなものがありますが、ブロック-パーツの関係と同様にクラス-インスタンスの関係となります。 たとえば集約による階層構造に Interface を記述した場合の区画は標準ポートに、Flow Specification や値型を記述した場合はフローポートに、制約ブロックを記述した場合は制約に対応します。 図 10 ではブロックの階層構造のみ表現しています。

ブロック定義図の使い方として、階層構造に注力するのであれば図 10 の上図のように区画にインスタンスを記述せずに関連のみで表現し、1 ブロック内部の構造は内部ブロック図 (後述) で表現するという方法が取られます。 ブロックの内容を定義する場合は、図 10 の下図のようにブロックが並んだ記述となります。 ブロック定義図は UML のクラス図とは異なり、階層構造以外のブロック間の関係は、内部ブロック図として 1 ブロック内部のプロパティ同士の結合関係を記述することになります。

 

次に CPU 基板の内部ブロック図を図 11 に示します。

図 11 CPU 基板の内部ブロック図
図 11 CPU 基板の内部ブロック図

CPU ユニットを中心に LED/ディップスイッチ/Matrix LED が配置され、それぞれ入出力ポートが接続されています。 網掛け表現は本記事の独自拡張で、SysML の規約ではありません。 この部分は取り外しが可能なことを表しています。 CPU ユニットと Matrix LED ユニットはコネクタ経由で接続されているので脱着可能です。 RS-232C、Ethernet、未定義の I/O ポートは CPU ユニットのポートをそのまま CPU 基板上に引き出しています。

<<SysML>>

内部ブロック図は UML における複合構造図を拡張した図で、ブロック定義図がブロックの仕様を記述するのに対し、内部ブロック図はブロック内部でのプロパティ間の接続関係を記述する図と言えます。 ブロック定義図で使用可能な関連が大幅に制限されているのも、ブロック定義図ではブロック間の階層構造およびブロックの定義を目的とし、接続関係は内部ブロックで記述する意図があります。 同じ部品であっても使用場所によってさまざまな接続が考えられるので、妥当な考え方だと思います。

内部ブロック図で利用されるブロックのプロパティは、おもに (SysML1.1 の仕様書では制限はないですが) パーツとパーツ上の標準/フローポート、ポート間の接続とポートを流れるアイテムフロー (図 11 では不使用) です。

標準ポートは UML のポートと同じ仕様で、SysML では新たにフローポートという概念が加わったため、混同を避けるために名称が変更されました。

フローポートは SysML で追加された概念で、標準ポートが Interface で定義されるサービス授受 (Interface には利用側と提供側がある) に用いられるのに対し、フローポートは情報や資源の流れを表現するのに用いられます。 たとえば加工のための原料がフローポートを通してインプットされ、加工後の製品がアウトプットされるなどです。

標準ポートは四角に矢印はありませんが、フローポートには入力か出力かを規定する属性が存在し、図中の矢印の向きが方向を表しています。 両方向の矢印がついているフローポートは入出力両用です。

 
C) 要求の詳細化

利用予定のハードウェアからくる制約も考慮して要求を詳細化します。 図 12 に検討結果の要求図を記します。

図 12 システムレベル要求
図 12 システムレベル要求

利用可能なハードウェア構成から、同時可能な文字数は 8×16 ドットフォントで 4 文字分であること、スクロール速度はディップスイッチで 16 段階に設定することを要求に追加しました。

文字列入力には RS-232C または Ethernet を利用することを候補として挙げていますが、詳細は未定にしています。 他に表示可能な文字の詳細とスクロール速度の詳細も未定です。

また、<<problem>> として、CPU 版ではスクロール時に画面がちらついたとあり、それを受けて今回はちらつかないことが性能要求として上がっています。 そこから性能要求が検討されていますが、設定可能なスクロール速度と関連することがわかります。

テストケースとして、スクロール速度の計測は 1 ドットスクロールごとに赤・緑の LED を交互点滅させ、その間隔を計測することにしています。

本記事では理解しやすくするために未定である要求は網掛けとしていますが、SysML1.1 の規定にはない独自の表現です。

次に利用するハードウェアの制約もまとめておきます (図 13)。

図 13 利用ハードウェアの制約
図 13 利用ハードウェアの制約

これまでの要求を表形式でまとめました。 表にすると、要求図では見えなかった抜け漏れが発見されることがあります。 新たに発見された要求は、要求図にも反映させておくことが望ましいです (表 5)。

表 5 電光掲示板基本仕様
表 5 電光掲示板基本仕様

太枠の部分はこれまでの分析で触れられていなかった項目です。 単純な仕様ですが、単色の Matrix LED であることを明記していませんでした。 表示色数は、確保しなくてはならない VRAM 容量の計算に必要な情報のため追加しました。

現時点では仕様に未定の項目がいくつか残っています。 実際の開発でも初めの要求分析で仕様がすべて固まることはまずあり得ないといってよいと思います。

重要なことは、決まっていないことが明確になっていることと、いつまでに決定しなければ全体計画に影響を与えるかを把握し、リスクを管理することにあります。

現時点で未定である項目は基本的に要求元 (筆者) の関心が薄い項目です。 機能を満たす範囲であれば何でもよいと思っており、内部構造を検討する過程でコストのかからない方法で実現できる仕様に決定する予定です。

なお、内部構造の設計を進めるに当たって、初期に未定であったり暫定であったりする項目は (たとえ仕様が確定しても) 変更があり得るものとして設計検討すべきです。

最後に設計時に考慮すべき制約事項をまとめます (表 6)。

表 6 設計時に考慮すべき制約事項一覧
表 6 設計時に考慮すべき制約事項一覧

第2章 実践編(2)へ続く・・・