MBSEメモ
○ 課題の定義 －顧客の運用・操作上の要求分析
最初のステップでは、システムに対する要求ではなく、その先にある顧客の要求とゴール、期待される目標や動作を分析します。この分析により、実運用とシステム構築・検証・評価・性能の条件について、十分な定義を得ることができます。
このフェーズの成果物は、主に「運用上のアーキテクチャ」で構成されます。「運用上のアーキテクチャ」は、アクタやユーザ観点の要求、それらの運用上の能力や動作(運用上の利用シナリオ、安全性、セキュリティ、ライフサイクルといった運用上の制約を含む)を説明するものです。
方法論
Arcadiaはモデルに基づいた、システム、ハードウェア、ソフトウェアのアーキテクチャを検討するエンジニアの方法論です。Arcadiaは、2005年から2010年の間、Thales(仏)の全業務を対象として、現場の担当者が繰り返し検討した上でまとめられました。
Arcadiaはビューポイント駆動のアプローチ(ISO/IEC 42010で説明されている)をとり、要求と解決策を明確に区別します。
2016/10/11更新
ここでは方法論のひとつ、Arcadiaを取り上げます。
Arcadiaは内容が公開されており、Arcadiaに対応したツールCapellaがフリーで利用できます。
Capellaのホームページから引用します。
具体的に、どのような手順で進めるのか見ていきましょう。
これは、最初の図のA1~A3をまとめる作業に対応します。
このフェーズでは、「システムのユーザは何を望んでいるか？」を明らかにします。
○ システム要求をまとめる －システム要求分析
2番目のステップは、システム自体に注目します。その振る舞いと品質で、運用上の要求をどのように満たすのか定義します。次のステップで検討する要素は、ここで作られます。対応する機能、相互の情報の交換、非機能の制約(安全性、セキュリティなど)、システムに割当てられる性能、システムと操作者の関わり方、などです。
このステップのゴールは、顧客要求(コスト、スケジュール、スキルなど)の実現性をチェックすることです。必要であれば、それらの要求について交渉します。最初に検討したシステムのモデルにより、機能面の要求の分析が完了します。このシステムのモデルは、アーキテクチャに対する要求を調べ、コストと、そのモデルに矛盾がないことを評価したものです。
このフェーズの成果物の主なものは、システムの機能的な要求(機能について、機能的なつながり、シナリオ)、ユーザや他のシステムとの互換性や関わり(機能について、関わり方、非機能の制約)、そしてシステムへの要求です。
ここまでのフェーズが、以降に続く設計を明確にするものであり、顧客により確認され、承認されるものです。
これは、最初の図のF1~F5をまとめる作業に対応します。
このフェーズでは、「システムはユーザのために何を実現するか？」を明らかにします。
最初のステップと合わせて、NEED UNDERSTANDINGとしています。以降が、SOLUTION ARCHITECUTUAL DESIGNとなっています。
○ システム・アーキテクチャ検討 －論理アーキテクチャ(概念レベル)
3番目のステップでは、システムを粗く分割します。この分割は、この後に行う開発のプロセスでの分割とは異なるかもしれません。機能、インターフェイス、データフロー、振る舞いなどを明確にした機能、非機能の分析から始め、システムを分割し、それを論理的な要素に割り当てます。この論理的な要素はのちに開発、外部への発注、統合、再利用、製品と形状の定義の基本となるものです。他の判断基準は、それらの境界を定義するときに考慮されます。
粗い分割が、最初の図のC1~C3です。
このプロセスでは、アーキテクチャ上の優先事項とビューポイントと関連する設計ルールなどを考慮します。のちに続くフェーズで詳細化する部品に対して、主な非機能の制約(安全性、セキュリティ、性能、システム構築・検証・評価、コストなど)も考慮し、一緒に検討して良い落としどころを探します。この手法は「ビューポイント駆動」と呼ばれます。複数のビューポイントによって、システムのアーキテクチャに影響を与える制約をまとめる手法です。
このフェーズの成果物は、「論理アーキテクチャ」です。「論理アーキテクチャ」は部品、明確なインターフェイスの定義、シナリオ、モデルと状態、部品の設計を考慮する全てのビューポイントと、その方法を含みます。
「論理アーキテクチャ」が要求を満たすことを確認する中で、結果として要求と運用上のシナリオに関連が追加されます。
いろいろなビューポイント、つまりいろいろな観点から検討し、その結果、機能をアーキテクチャに割当てています。
このフェーズでは、「期待を満足するために、システムはどのように働くか？」を明らかにします。
○ システム・アーキテクチャの開発 －物理アーキテクチャ
4番目のステップでは再び「論理アーキテクチャ」の検討を行います。但し、それが最終的なアーキテクチャであるという点が異なります。この検討が終わると、モデルは開発の準備ができた(“下流の”エンジニアから見て)と見なされます。従って、最適化の考え方、アーキテクチャ・パターンや最新のサービスや部品なども導入します。そして、実装など技術的な制約や選択した方法に合わせて、論理アーキテクチャをまとめていきます。
このフェーズの成果物は、物理アーキテクチャです。物理アーキテクチャは、製造する部品、部品の設計で考慮される全てのビューポイントや方法をまとめたものです。要求や運用上のシナリオとの関連付けも追加します。
これは、最初の図の、C11、C12、C4を含む構成が対応します。
このフェーズと次のフェーズでは、「どのようにシステムを開発するか？」を明らかにします。
○ 各部品の要求をまとめる －開発と、システム構築・検証・評価・性能への制約
最後のステップでは、完全に分割された構造(EPBS)を扱います。これまでの作業で得られたことを使い、部品の要求をまとめ、システム構築・検証・評価・性能を保証します。
システム構成に関連付けられた全ての仮説と制約は、ここでまとめ、チェックします。
このフェーズの成果物は、主に部品開発への制約です。それぞれの要素が開発されることで期待される特性をまとめたものです。
これは、最初の図の一番下、黄色い図が対応します。図ではプロセッサやバスが書かれています。
そして、以降の開発へと続いていくことになります。
以上がArcadiaの流れの概要です。Capellaはステップ間のデータの変換や、それぞれのステップで、どのような図を書けば良いのかガイドしてくれます。