PR

境界を図で表現

 システムの境界を表現する方法としては、構造化手法のコンテキスト図があり、現在でもよく使われている。また、ユースケース図のアクターに他のシステムを配置することでも、システムの境界を表現できる。

 システムズモデリング言語である「SysML(Systems Modeling Language)」では、システムの構造を表現する図として「パッケージ図」「ブロック定義図」「内部ブロック図」がある。パッケージ図は、システムの構成要素を束ねてグループ化する際に用いる。ブロック定義図は、システムの構成要素を意味のあるまとまりのブロックとして定義し、ブロックとブロックの間の関係を表現できる。内部ブロック図は、ブロックを構成する構成要素間のつながりを表現する。

 車両盗難防止システムは、ボディー、エンジン制御、メーターといった既に存在する構成要素と関連してシステムが成り立つ。この関係をブロック定義図で表現すると図3のようになる。車両盗難防止システムブロックと、関連する既存構成要素のブロックとして表現できる。

図3 車両盗難防止システムの境界
図3 車両盗難防止システムの境界
[画像のクリックで拡大表示]

 自動車向け機能安全規格「ISO 26262」のPart3では、アイテムの定義として、システムの対象と周辺システムとの境界を明確に定義することが求められる。これは、機能安全の対象となるシステムの位置付けと他のアイテムとの関係を明らかにすることで、開発対象を定めることを意味する。ブロック定義図を利用し、システムの対象と周辺システムの関係を表現することで、アイテムの境界を定義できる。

 システムの境界を特定したら、次は、抽象機能をアーキテクチャー要素として定義する。「車両盗難防止システム」を例に、解説していく。

機能をアーキテクチャー要素として定義する

 システムの構成要素(アーキテクチャー要素=ブロック定義図のブロック)は、システムの機能から論理的に導出される。システムは、ユーザーや保守サービス担当者などの利害関係者に機能を提供するものであり、この機能を実現するのがシステムの構成要素になるからである。図4に、システムの機能(abstruct function)をアーキテクチャー要素として定義する流れを示す。まず、利害関係者に提供する機能を単純な機能に分解する。次に、分解した機能を責務・役割の観点で統合する。

図4 機能をアーキテクチャー要素として定義する流れ
図4 機能をアーキテクチャー要素として定義する流れ
[画像のクリックで拡大表示]

機能を分解する

 車両盗難防止システムの要求に対して機能を分解してみたのが、図5である。分解の前に、商品企画などからの要求として提示されるさまざまな機能に対し、機能要求として整理しておく。機能要求をユースケース・シナリオやUSDM(Universal Specification Describing Manner)3)で定義しておけば、分解はスムーズにできる。要求記述の動詞に着目すると、単純な機能に分解しやすい。

図5 車両盗難防止システムの機能分解
図5 車両盗難防止システムの機能分解
[画像のクリックで拡大表示]

 図5のように、機能を分解して階層的に機能の構造を表すことから、この図を「機能階層構造図」と呼ぶ。これは、VE(Value Engineering)において機能定義で行う機能系統図と同じ意味合いである。

 機能の分解は、システムの境界である入出力が見えるまで、もしくはシステムとして判断する機能が単機能になるまで行う。KAOS(Knowledge Acquisition in autOmated Specification)では、要求の実現に責任を持つエージェントが1つになるまで分解する4)。このように単一の機能になるまで分解することで、曖昧な構成要素がなくなり、結果として構成要素の漏れがなくなる。