SysMLを活用した要求定義から論理・物理アーキテクチャ構築まで

システム要件の定義

図2は、「車両盗難防止システム」の要求をSysMLの要求図で記述したものです。車両のステークホルダーである所有者からの「盗難を防止してほしい」という要求を、さらに細分化された４つの要求「不正解錠の防止」、「施錠忘れ防止」、「エンジン不正始動防止」、「異常通知」によって実現することを示しています。

この４つの要求はすべてシステムに対する「機能要求」です。一方、これら機能の実現をどのように達成すればよいかは「非機能要求」として明確にします。非機能要求を抽出するには、ISO/IEC25010「システム及びソフトウェア品質モデル」などの網羅的なフレームを参照すると効率的です。また、関連する法規や環境規制など、システムが必ず守らなければならないものはシステム制約として整理します。

論理構成要素の定義

図3は、「車両盗難防止システム」の要求に基づき、システム構成をSysMLのブロック定義図を使って表現したものです。この図からは、このシステムが、ボデー、エンジン制御、メーターといった既に存在する構成要素と関連して成り立っていることが分かります。

図4は、「車両盗難防止システム」の内部の構成要素を表したものです。今回は「キー照合」「自動施錠／解錠」「イモビライザー」などといった機能と、それをユーザに伝える「警告」とそれの詳細である「振動検知」「衝撃検知」、別の通知手段である「ユーザ通知」が構成要素となります。

論理アーキテクチャの作成

システムの構成要素が決まったら、続いて構成要素間の関係を定義します。図5は、構成要素間の関係をSysMLのブロック図で表現しています。定義した構成要素それぞれをブロックとして置き、ブロック間のインタフェースを決めています。

この図からは、「キー照合」の結果を受けて「自動施錠/解錠」、「イモビライザー」が作動し、最終的に表示と音でユーザに通知するという流れが読み取れます。このように、構成要素とそれらの関係を定義することで論理アーキテクチャを作成します。

物理アーキテクチャの作成

前ページの図5で示した論理アーキテクチャに対して、非機能要求や制約に配慮した実際の「モノ」としての構成を物理アーキテクチャと呼びます。物理アーキテクチャの構築には、まずは下表のように、「車両盗難防止システム」の非機能要求を実現するために必要なアーキテクチャ制約を導出し、先に定義した論理アーキテクチャに対しこれを満たすような変更を施していくことになります。

表のアーキテクチャ制約に対し、さまざまなトレードオフ分析を行い、全体最適な視点で決定した物理アーキテクチャが図6です。ここでは、ハードウェアとソフトウェアの区別、および、それらがどのように配置されるかを見て取ることができます。今回は、性能面およびビジネス面での制約から、盗難防止とボデーECUの2つのCPUに各構成要素となるブロックが分割配置されたことが分かります。

さらに図7のように、各要素間のつながりや、やり取りされる情報などを表現できる内部ブロック図を活用することで、設計したアーキテクチャの妥当性をモデルを使って早い段階で検証することができます。このような手順を踏むことで、多様で大規模なシステムに対しても、トップダウンかつ全体最適なアーキテクチャを事前に検討することが可能になります。

システムアーキテクトを目指して

システムアーキテクチャは一度構築すればそれで終わりではなく、システムのライフサイクル全般に渡って維持していかなければなりません。また、複数のシステムに対して同じようにシステムアーキテクチャを定義していくことで、機能の統合や相互接続などの全体最適を実現するための検討が進むようになります。

システム開発を行う企業においては、システムアーキテクチャ設計を継続していくシステムアーキテクトの存在が不可欠です。また、システムアーキテクトにとっては、全体最適なシステムを設計することで企業の事業戦略を大きく推進する役割を果たせます。システムアーキテクトを目指し、真に役立つシステムアーキテクチャ設計を実現させましょう。

コンサルタントが教える成功の秘訣

エグゼクティブコンサルタント 斎藤 賢一

複数の機能が同時に動作する複雑なシステムは、システム内部の構造も複雑になりがちです。特に、既存の複数システムを組み合わせた統合システムは、システム構造に一貫性が無く、動作不安定、使い勝手の悪いUI、重複した機能、資源効率の悪さなどの品質低下を引き起こします。

システムアーキテクチャを設計する際は、機能をベースに技術や制約などに依存しない「論理的なアーキテクチャ」から、技術制約や品質要件などを考慮した「物理アーキテクチャ」へと変換していきます。この時、システムアーキテクチャ設計のインプットとなる機能要件、非機能要件をどれだけモレなく厳密に定義できるかがポイントになります。

また、要件を満たす構造は何通りも考えられるので、アーキテクチャの導出根拠が重要になります。アーキテクチャ導出根拠が残っていると、要件が変わったときに適切な対応を取ることができ、新しい要件が追加された場合に効率よく検討できます。

エクスモーションでは、要求から最良・最善のシステムアーキテクチャが設計できるよう、開発現場のアーキテクトを支援しています。

シニアコンサルタント　庄司順和

どのようなシステムにもシステムアーキテクチャは必ず存在します。しかしそれは適切に設計されたものではなく、ソフトウェアとハードウェアを個別に設計した結果を現場の担当者がすり合わせているというケースが少なくないようです。そのように定義されたシステムアーキテクチャでは、継続した拡張や、複数バリエーションへの展開などに困難がつきまといます。

システムアーキテクチャは、それがシステムを作る目的にかなっているか、企業の事業戦略に合致しているかを説明できる構造になっていなければなりません。これは機能個別の設計をしているときには抜け落ちてしまいがちな視点です。常に全体最適の意識を持ちながら、後々まで役に立つシステムアーキテクチャを作り上げましょう。

システムアーキテクチャに関する記事を見る

他のソリューションを見る

最新コラム