機能モデル

システムエンジニアリングやソフトウェアエンジニアリングでは、機能モデルは機能モデリングの観点から作成されます。機能的観点は、ビジネスプロセスモデリングで可能な観点の1つであり、他の観点としては、例えば行動的、組織的、情報的観点などがあります。^{[ 10 ]}

機能モデリングの観点からは、動的なプロセスを記述することに重点が置かれます。このモデリング観点における主要な概念はプロセスであり、これは関数、変換、アクティビティ、アクション、タスクなどです。この観点を採用したモデリング言語のよく知られた例として、データフロー図が挙げられます。

この視点では、プロセスを説明するために4つのシンボルを使用します。それらは以下のとおりです。

• プロセス：入力から出力への変換過程を示します。
• 保管場所：データ収集場所、または何らかの資料保管場所。
• フロー：プロセスにおけるデータまたは物質の移動。
• 外部エンティティ：モデル化されたシステムの外部に存在するが、システムと相互作用する。

これらの記号を用いることで、プロセスをこれらの記号のネットワークとして表現することができます。このように分解されたプロセスは、データフロー図（DFD）と呼ばれます。

動的エンタープライズモデリングでは、制御モデル、機能モデル、プロセスモデル、組織モデルに分割されます。

機能分解とは、機能関係を構成要素に分解し、それらの構成要素から機能合成によって元の機能を再構築するプロセスを広く指します。一般に、この分解プロセスは、構成要素の同一性を理解するため、または全体機能を圧縮表現するために行われます。後者の目的は、構成要素となるプロセスが一定のモジュール性を持つ場合にのみ実現可能です。

機能分解はコンピュータプログラミングにおいて重要な役割を果たしており、その主要な目標の一つは、プロセスを可能な限りモジュール化することです。例えば、図書館管理システムは、在庫管理モジュール、利用者情報モジュール、料金徴収モジュールなどに分割できます。コンピュータプログラミングの黎明期には、これは一部の著名な実践者によって「サブルーチン化の技術」と呼ばれていました。

工学システムの機能分解は、工学システムを分析するための手法です。基本的な考え方は、ブロック図の各ブロックが「and」や「or」といった論理和を用いずに記述できるようにシステムを分割することです。

この演習では、システムの各部分に純粋関数を持たせることを強制します。システムが純粋関数で構成されている場合、それらは再利用または置換が可能です。一般的な副次的効果として、ブロック間のインターフェースが単純かつ汎用的になります。インターフェースが単純になるため、純粋関数を関連する類似の関数に置き換えることが容易になります。

機能ブロック図は、システムの機能と相互関係を記述するブロック図です。機能ブロック図は、次のものを表すことができます。^{[ 11 ]}

• ブロックで表したシステムの機能
• 線で示されたブロックの入力、そして
• 9つの機能間の関係
• 物質や信号のための機能的なシーケンスと経路^{[ 12 ]}

ブロック図では、特定の特性を示すために追加の回路図記号を使用することができます。

具体的な機能ブロック図としては、古典的な機能フローブロック図や、プログラマブルロジックコントローラの設計で使用される機能ブロック図（FBD）などがあります。

機能フローブロック図( FFBD) は、システムの機能フローを段階的に示した、多階層で時間順序付けされたフロー図です。[ ^{14 ]この} 図は 1950 年代に開発され、古典的なシステム工学で広く使用されています。機能フローブロック図は、機能フロー図、機能ブロック図、機能フローとも呼ばれます。^{[ 15 ]}

機能フローブロック図（FFBD）は通常、システムの詳細な手順とサポート手順を定義しますが、システムの開発および製造におけるプロセスを定義するためにも効果的に使用されます。ソフトウェア開発プロセスでもFFBDは広く利用されています。システムコンテキストでは、機能フローの手順には、ハードウェア、ソフトウェア、人員、設備、および／または手順の組み合わせが含まれる場合があります。

FFBD法では、関数は論理的な実行順序に従って整理され、図示されます。各関数は、他の関数の実行と完了との論理的な関係に基づいて示されます。関数名がラベル付けされたノードが各関数を表します。左から右への矢印は、関数の実行順序を示します。論理記号は、関数の逐次実行または並列実行を表します。^{[ 16 ]}

階層的入力処理出力（HIPO）は、1970年代に普及したシステム分析設計支援および文書化手法であり、システムのモジュールを階層として表現し、各モジュールを文書化するためのものです^{[ 17 ] 。 [ 18 ]}

これは、自動ランデブーを実証するためのエキスパートシステムの要件開発、設計構築、および実装サポートに使用されました。設計および実装方法のため、検証は体系的に実施されました。^{[ 19 ]}

システムの全体的な設計は、HIPOチャートまたは構造チャートを使用して文書化されます。構造チャートは組織図と見た目が似ていますが、詳細を追加して表示するように変更されています。構造チャートは、さまざまな種類の情報を表示するために使用できますが、最も一般的にはデータ構造またはコード構造を図示するために使用されます。^{[ 18 ]}

N ²チャートは、システム要素間の機能的または物理的なインターフェースを表すマトリックス型の図です。これは、機能的および物理的なインターフェースを体系的に識別、定義、表にまとめ、設計、分析するために使用されます。システムインターフェース、ハードウェアおよび/またはソフトウェアインターフェースに適用されます。^{[ 14 ]}

N ^{2ダイアグラムは、主に}ソフトウェア分野でデータ インターフェースを開発するために広く使用されてきました。しかし、ハードウェア インターフェースの開発にも使用できます。基本的な N ²チャートを図 2 に示します。システム 機能は対角線上に配置され、N × N マトリックスの残りの正方形はインターフェースの入力と出力を表します。 ^{[ 20 ]}

構造化分析設計技法(SADT) は、ソフトウェア アプリケーションのスケッチを作成するための図式表記法である、システムの機能階層として記述するためのソフトウェア エンジニアリング手法です。エンティティとアクティビティを表すためのビルディング ブロックと、ボックスを関連付けるためのさまざまな矢印を提供します。これらのボックスと矢印には、非公式な意味論が関連付けられています。^{[ 21 ]} SADT は、詳細レベルの連続性を使用して、特定のプロセスの機能分析ツールとして使用できます。SADT 手法は、産業情報システムで使用される IT 開発のユーザー ニーズを定義するだけでなく、アクティビティの製造プロセスや手順を説明して提示することもできます。^{[ 22 ]}

SADTは、企業内の機能とその関係を記述することで、あらゆる企業の具体的な機能的視点を提供します。これらの機能は、販売、受注計画、製品設計、部品製造​​、人事管理など、企業の目的を達成します。SADTは、単純な機能関係を描写することができ、異なる機能間のデータと制御フローの関係を反映することができます。IDEF0形式は、 1985年にダグラス・T・ロスによって開発されたSADTに基づいています。^{[ 23 ]}

IDEF0は、製造機能を記述するための機能モデリング手法であり、情報システム、ビジネスプロセス、またはソフトウェアエンジニアリング分析の分析、開発、再設計、および統合のための機能モデリング言語を提供します。 ^{[ 24 ]}これは、ソフトウェアエンジニアリング分野のモデリング言語のIDEFファミリーの一部であり、機能モデリング言語構築SADTに基づいて構築されています。

IDEF0 機能モデリング手法は、組織またはシステムの意思決定、アクション、アクティビティをモデル化するように設計されています。^{[ 25 ]} これは、Douglas T. RossとSofTech, Inc.によって開発された確立されたグラフィック モデリング言語である構造化分析設計技術(SADT)から派生したものです。IDEF0 の元の形式には、グラフィカル モデリング言語 (構文と意味論)の定義と、モデル開発のための包括的な方法論の説明の両方が含まれています。^{[ 1 ]}米空軍は、システムの機能的観点を分析および伝達するための機能モデル手法を開発するために SADT 開発者に委託しました。IDEF0 は、システム分析の整理を支援し、簡素化されたグラフィカル デバイスを通じてアナリストと顧客間の効果的なコミュニケーションを促進するはずです。^{[ 25 ]}

公理的設計は、製品、情報システム、ビジネスプロセス、またはソフトウェアエンジニアリングソリューションの分析、開発、再設計、および統合のためのソリューション合成フレームワークとして使用される、トップダウンの階層的な機能分解プロセスです。^{[ 26 ]}その構造は、潜在的な機能ソリューションモデルのアーキテクチャの堅牢性を最適化するために、機能間の結合を数学的に分析するのに適しています。

ビジネス機能モデル（BFM）は、組織の使命を遂行するために日常的に実行される業務の一般的な説明またはカテゴリです。これらは「一般的なビジネス機能の識別のための概念構造を提供する」ものです。^{[ 27 ]}これは、ビジネス領域機能のコンテキストで重要なビジネスプロセスを示すことができます。ビジネス機能モデルのプロセスは、バリューチェーンモデルのプロセスと整合していなければなりません。プロセスは、最終製品を生産したりサービスを提供したりするために実行される、関連するビジネス活動のグループです。継続的に実行されるビジネス機能とは異なり、プロセスは、特定の開始点と、望ましい出力の提供によって示される終了点があるという特徴があります。右の図は、ビジネスプロセス、ビジネス機能、およびビジネス領域のビジネス参照モデルの関係を示しています。^{[ 28 ]}

ビジネスプロセスモデリング表記法（BPMN）は、ワークフローにおけるビジネスプロセスを指定するためのグラフィカルな表現です。BPMNはビジネスプロセス管理イニシアチブ（BPMI）によって開発され、2005年に両組織が合併して以来、現在はオブジェクト管理グループによって維持されています。BPMNの現在のバージョンは2.0です。^{[ 29 ]}

ビジネスプロセスモデル表記法（BPMN）仕様は、ビジネスプロセス図（BPD）でビジネスプロセスを指定するためのグラフィカル表記法を提供します。 ^{[ 30 ]} BPMNの目的は、ビジネスユーザーにとって直感的でありながら複雑なプロセス意味を表現できる表記法を提供することで、技術ユーザーとビジネスユーザーの両方のビジネスプロセス管理をサポートすることです。BPMN仕様はまた、表記法のグラフィックと実行言語の基盤となる構成要素、特にBPEL4WSとの間のマッピングも提供します。^{[ 31 ]}

ビジネス参照モデルとは、企業、サービス組織、または政府機関の中核事業の機能面および組織面に焦点を当てた参照モデルです。エンタープライズエンジニアリングにおいては、ビジネス参照モデルはエンタープライズアーキテクチャフレームワークまたはアーキテクチャフレームワークの一部であり、エンタープライズアーキテクチャに関連する構造とビューをどのように構成するかを定義します。

一般的に、参照モデルとは、何かの基本的な目標や概念を具体化したモデルであり、様々な目的において参照として利用できるものです。ビジネス参照モデルは、組織の業務運営を、それを実行する組織構造とは独立して記述する手段です。他のタイプのビジネス参照モデルは、業務プロセス、業務機能、および事業領域のビジネス参照モデル間の関係を示すこともできます。これらの参照モデルは階層的に構築でき、サービスコンポーネント、テクノロジー、データ、およびパフォーマンスの分析の基盤となります。

オペレーター機能モデル（OFM）は、人間工学エンジニアが使用する従来のタスク分析手法の代替案として提案されています。オペレーター機能モデルは、オペレーターが複雑なシステムをより単純な部分に分解し、制御アクションとシステム構成を調整して、許容可能なシステム全体のパフォーマンスを達成する方法を数学的に表現しようとします。このモデルは、複雑なシステムにおける知識表現、情報フロー、意思決定の基本的な問題を表現します。ミラー（1985）は、ネットワーク構造は、オペレーターのシステムの内部モデルと、オペレーター制御機能を構成する意思決定問題を解決するためにモデルがどのように使用されるかを指定する制御構造の可能な表現として考えることができると示唆しています。^{[ 32 ]}