Wikipedia

機能モデル

（アクティビティモデルから転送）

機能モデル（きのうモデル、Function model）はモデル化されるシステムまたはサブ領域内の機能 （アクティビティ、タスク分析（英語版）、プロセス、運用）の構造化された表現である[1]。機能的モデルとも。

Example of a function model of the process of "Maintain Reparable Spares" in IDEF0 notation.

またアクティビティモデルまたはプロセス・モデリングとも呼ばれる機能モデルは、定義されたスコープ内の事業体の機能の図式表現である。機能モデルの目的は、情報ニーズの発見を補助し、機会の識別を助け、そして製品またはサービスコスト決定するための基盤を確立する、機能とプロセスを記述することである[2]。

歴史

編集

機能モデルプロジェクトは20世紀前半に開発されていたマネージメントダイアグラムの他のタイプとして、1950年代に始まった。最初に知られるガントチャート は、それをharmonogramと呼んだKarol Adamieckiによって1896年に開発された。

Adamieckiは、彼のチャートを1931年まで発表しなかったこと、及び彼の作業がいずれの場合もポーランド語あるいはロシア語で発表され、言語が西側世界でポピュラーでなかったことから、そのチャートは今、1910-1915年近辺で彼のチャートを設計し、西側でポピュラーになった、Henry Gantt (1861-1919) の名前を持つ[3][4][5]。最初のプロセス・フローの文書化の構造化手法、フロー・プロセス・チャート (Flow process chart)は、1921年に米国機械工学学会 (ASME) のメンバーに『プロセス・チャート：一つの最適方法発見における最初のステップ』のプレゼントして、Frank Gilbrethによって紹介された[6]。Gilbrethのツールは、産業工学カリキュラムにそれらの方法を素早く見つけました。

最初に良く定義された機能モデルの一つは、1950年代の防衛関連のTRW社によって開発された機能フロー・ブロック・ダイアグラム (FEBD)であった[7]。1960年代にそれは、宇宙システムと飛行ミッションにおけるイベントの時間的シーケンスを可視化するためNASAによって採用された[8]。それは、システム機能の実行の順序を示すためのクラシックなシステム工学でさらに幅広く使われた[9]。

機能モデリングのトピックス

編集

機能的観点

編集

システム工学及びソフトウェア工学における機能モデルは、機能的観点のモデリング (modeling perspective)で創られる。機能的観点は、ビジネスプロセスモデリング で可能な、別の観点が、例えば、振舞い的、組織的、あるいは情報的である、観点の一つである。[10]

機能モデリングの観点は、動的システムを記述することに集中する。このモデリング観点における主な概念はプロセスであり、これは、機能、変換、アクティビティ、行為、タスク、などであり得る。この観点で採用されるモデリング言語の良く知られた例は、データフローダイアグラム (data flow diagram)である。

その観点は、プロセスを記述する、以下の4つのシンボルを使う。

  • プロセス：インプットからアウトプットへの変換を描く。
  • ストア：データの集まり、またはある種の物品。
  • フロー：プロセスにおけるデータまたは物品の移動。
  • 外的エンティティ：モデル化されたシステムの外部であるが、それと作用する。

ここで、これらのシンボルと共にそのプロセスは、これらのシンボルのネットワークとして表され得る。この分割プロセスがDFD：データフロー・ダイアグラムである。

動的エンタープライズモデリング（英語版）における部分は、コントロール・モデル (Control model)、機能モデル、プロセス・モデル (Process model)、及び組織的モデル (Organizational model)で創られる。

機能分割

編集
 
Example of functional decomposition in a systems analysis.

機能分割 (Functional decomposition)[訳語疑問点]は、オリジナル機能が、機能構成 (function composition)[訳語疑問点]によるそれらの部品から再構築され得る方法のような、構成要素部品に機能的 (functional)[訳語疑問点]関係性を解決するプロセスへ広く参照する。一般に、分割のプロセスは、構成要素の識別への洞察を高める目的、あるいは構成要素のプロセスがモジュール性のレベルを所有する時のみ可能なタスクである、グローバル機能の圧縮された表現を得る目的のいずれかを引き受ける。

機能分割 (Functional decomposition) は、主要な目標が可能な最も大きい広がりのプロセスをモジュール化することである、コンピュータプログラミングにおける卓越した役割を持っています。例えば、ライブラリ管理システムが、在庫モジュール、顧客情報モジュール、及び料金査定モジュールに分解されるかもしれません。初期のコンピュータ・プログラミングの数十年に、それは、若干の卓越した実行者によって呼ばれたとき、これは『サブルーチン化の芸術』として明らかにされました。

工学システムの機能分割は、設計されたシステムを分析するための方法です。基本的な考えは、ブロック・ダイアグラムのそれぞれのブロックがその記述に『and』または『or』条件無しで記述できるような方法で、システムを分割しようとすることである。

この課題は、システムのそれぞれの部分に純粋な機能 (function)を持たせることを強います。システムが純粋な機能で構成されているとき、それらは再利用されるか、あるいは置換えられることができます。普通の副次効果は、ブロック間のインタフェースが単純そして汎用になるということです。インタフェースが通常単純になることから、それは、関連し、類似の機能で純粋な機能で置換えることがより容易です。

機能モデリング手法

編集

機能的アプローチは、複数の図式表現技法とモデリング表記法で拡張された。このセクションでは、年代順に重要な技法の全貌を提供する。

機能フロー・ブロック・ダイアグラム

編集
 
Functional Flow Block Diagram Format.[11]

機能フロー・ブロック・ダイアグラム (FFBD)は、システムの機能的フローの、多段で、時間順で、ステップ毎のフロー・ダイアグラム (Flow diagram)である。[12]そのダイアグラムは、1950年代に開発され、古典的システム工学で幅広く使われた。機能フロー・ブロック・ダイアグラムは、機能フロー・ダイアグラム、機能ブロック・ダイアグラム、あるいは機能フローとしても参照される[13]。

機能フロー・ブロック・ダイアグラム（FFBD）は、システムのためのステップ毎の操作やシーケンスを支援する、通常詳細を定義するが、しかしそれらは、システムの開発や制作におけるプロセスを定義するため効果的に使われる。ソフトウェア開発プロセス (Software development process)もまた、幅広くFFBDを使う。システムの文脈で、機能フローのステップは、ハードウェア、ソフトウェア、人材、設備、及び手順の組合せを含むかもしれない。FFBD手法で機能は、実行の論理的順序で組織化され、描かれる。各機能は、それの他の機能の実行と完了との論理的関係で示される。機能名でラベル付けされたノードは、各機能を描く。左から右への矢印は実行の順序を示す。論理記号は、機能の順次または並列実行を表す。[14]

HIPO と IPO

編集

階層的入力処理出力HIPO (HIPO)は、1970年代に普及した、システムのモジュールを階層的に表現し各モジュールを文書化するための[15]、システム分析設計支援と文書化技法である。[16]

それは、要求を開発し、設計を構築し、そして自動化された待ち合わせを示すためのエキスパート・システムの実装を支援するため使われた。検証は、設計と実装の方法のため体系的に行われた。[17]

システムの全体設計は、HIPOチャート、または構造チャート (Structure chart)を使って文書化される。構造チャートは、組織チャートに現れるそれと類似であるが、付加的詳細を示すため変更された。構造チャートは、情報の幾つかのタイプを表示するため使うことができるが、データ構造 (Data structure)あるいはコードのいずれをも表示するのに最も共通的に使われる。

N2 チャート

編集
 
Figure 2. N2 chart definition.[18]

N2チャート (N2 Chart)は、システム要素間の機能的又は物理的インタフェースを表現する、マトリックス形式でのダイアグラムである。それは、機能的及び物理的インタフェースを体系的に識別し、定義し、表にし、そして分析するため使われる。それはシステム・インターフェースと、ハードウェア及びソフトウェア・インタフェースに適用する。[12]

N2ダイアグラムは、データ・インタフェースを開発するため、主にソフトウェア領域で、広範囲に使われた。しかしながらそれはハードウェア・インタフェースを開発するためにも使える。基本的な N2 チャートは、図２に示されます。システム機能は対角線上に置かれる；Ｎ ｘ Ｎマトリックスでの正方形の残りは、インタフェースのインプットとアウトプットを表す。[18]

構造化分析及び設計技術（SADT）

編集
 
SADT basis element.

構造化分析及び設計技術 (SADT)は、ソフトウェア・アプリケーションのスケッチを構築するダイアグラム的表記で、機能の階層としてシステムを記述するための、ソフトウェア・エンジニアリング手法 (Software engineering methodology)である。それは、エンティティとアクティビティを表すビルディング・ブロックとボックス間を関係づける矢印を提供する。これらのボックスと矢印は、関連する非公式な意味論を持つ。[19] SADTは、連続する詳細さのレベルを使い、与えられたプロセスの機能分析ツールとして使われる。SADT手法は、産業情報システムで使われるIT開発のユーザー・ニーズを定義することを可能にするが、しかしまた、アクティビティの製造プロセスや手順を説明し表現することも可能にする。[20]

SADTは、一つの会社の機能とそれらの関係性を記述することによって、あらゆる事業体の特手化された機能的ビューを提供する。これらの機能は、販売、受注計画、製品設計、部品製造、及び人材資源管理のような、会社の目的を満たす。SADTは、シンプルな機能的関係描くことができ、そして異なった機能間でのデータとコントロールの流れの関係性 を反映できる。IDEF0形式論は、ダグラス・テイラー・ロスによって1985年に開発されたSADTに基づいている。[21]

IDEF0

編集
 
IDEF0ダイアグラムの例

IDEF0は、情報システムと事業プロセスの分析、開発、リエンジニアリング、及び統合、あるいはソフトウェア工学分析のための機能的モデリング言語を提供する、製造機能を記述する一つの機能モデリング手法論である。[22]それは、ソフトウェア工学分野でのモデリング言語であるIDEFファミリー手法の一員であり、機能モデリング言語SADTで構築される。

IDEF0機能モデリング手法は、組織またはシステムの意思決定、行動、及びアクティビティをモデル化するため設計された。[23]それは、ダグラス・テイラー・ロスとSofTech社によって開発された、確立された図式モデリング言語構造化分析及び設計技術 (SADT)から派生した。そのオリジナル形式では、IDEF0は、図式モデリング言語の定義（構文と意味論）とモデル開発の包括的方法論の解説の両方を含んでいた。[1]米空軍は、システムの機能的観点を分析し、コミュニケートする機能モデリング手法の開発をSADT開発者に委任した。IDEF0は、シンプル化されたグラフィック手段を通して、システム分析の組織化の支援と分析者と顧客間の効果的コミュニケーションを促進するべきである。[23]

ビジネス・プロセス・モデリング表記法（BPMN)

編集
 
Business Process Modeling Notation Example.

事業プロセス・モデリング表記法 (BPMN)は、ワークフローにおける事業プロセスを規定するための一つの図式表現法である。BPMNは、Business Process Management Initiative(BPMI),で開発され、2005年の組織合併により、現在はObject Management Groupによって取り扱われている。BPMNの現在バージョンは1.1であるが、BPMN2.0に向けての大きな改訂のプロセスが進行している。[24][25]

BPMN仕様は、事業プロセス・ダイアグラム（BPD）で事業プロセスを規定するための図式表記法を提供している。[26] BPMNの目的は、複雑なプロセスの意味論まで可能とする事業ユーザー目線での表記を提供することにより、技技術ユーザーと事業ユーザー両者のための事業プロセス管理を支援することである。BPMN仕様はまた、表記の図形と言語（特にBPEL4WS）による実行構築の基礎との間のマッピングも提供する。[27]

中軸設計（Axiomatic design）

編集

中軸設計 (Axiomatic designは、分析、開発、リエンジニアリング、及び、製品、情報システム、事業プロセス、またはソフトウェア工学ソリューションの統合、等のソリューション合成のフレームワークとして使われる、トップダウンな階層機能的分割プロセスである。[28]その構造は、潜在する機能的ソリューション・モデルの仕組的頑強さを最適化するための機能間のカップリング分析に、数学的に適している。

機能モデルのその他のタイプ

編集

システムとソフトウェア工学分野で、多くの特定機能及び機能的モデルが定義されてきた。ここでは2～3の一般的タイプだけが説明される。

事業機能モデル（BFM）

編集

事業機能モデル（BFM）は、組織のミッションを実行するため日常的に実施されるオペレーションの一般的記述あるいは分類である。それは、事業領域機能の文脈での重要な事業プロセス (business process)を示すことができる。事業機能モデルにおけるプロセスは、価値連鎖（バリューチェーン）モデルにおけるプロセスから構成されねばならない。プロセスは、最終製品制作あるいはサービス提供のため実行される関連事業アクティビティのグループである。継続ベースで実行される事業機能と違って、プロセスは、それらが望まれたアウトプットを提供することでマークされる、特定化された開始と終了ポイントを持つという事実によって特徴づけられる。右側の図は、事業プロセス、事業機能、及び事業領域の事業参照モデル間の関係性を描いている。[29]

事業参照モデル（BRM）

編集
 
This FEA Business reference model depicts the relationship between the business processes, business functions, and the business area’s business reference model.

事業参照モデル (Business reference model)は、事業体 (Enterprise)、サービス組織 (service organization)、あるいは政府機関 (Government agency)の中核事業 (Core business)の機能的及び組織的側面に着目した、一つの参照モデルである。エンタープライズアーキテクチャ(EA)における事業参照モデルは、EAと関連した構造とビュー (views)をどのように組織化するか定義する、エンタープライズアーキテクチャフレームワーク (Enterprise Architecture Framework)あるいはアーキテクチャフレームワークの一部である。

一般的な参照モデル (reference model)は、それらを実行する組織的構造 (organizational structure)とは独立に、基本的目標または何かのアイデアを具現化する何かのモデルであり、様々な目的のため参照するのに探すことができる。事業参照モデルは、組織の事業運営 (business operations)を記述する手段である。

事業参照モデルの他のタイプは、事業プロセス (Business process)、事業機能、及び事業領域 の参照モデルの間の関係性をも描く。これらの参照モデルは、階層的に構成され、サービス・コンポーネント、技術、データ、及び性能の分析のための基盤を提供する。

オペレータ機能モデル（OFM）

編集

オペレータ機能モデル（Operator Function Model）は、人的要因 (Human factors)技術者によって使われる伝統的なタスク分析 (task analysis)技法に代わる提案である。オペレータ機能モデルは、どのようにオペレータが、許容可能な全体システムの性能を達成するため、複雑システムを単純な部分に分割し、コントロール行為とシステム構成を協調させるかを数学的フォームで表そうとする試みである。そのモデルは、複雑システムの知識表現、情報フロー、及び意思決定における基本の課題を表現する。Miller (1985)は、どのようのそのモデルがオペレータ・コントロール機能から成る意思決定問題を解決するため使われるかを特定するシステム＋コントロール構造に関して、ネットワーク構造がオペレータの内的モデル (Internal model)を表現可能であると考えられることを提案した。[30]

関連項目

編集
 
ウィキメディア・コモンズには、機能モデルに関連するカテゴリがあります。

参照

編集

  この記事にはパブリックドメインである、アメリカ合衆国連邦政府が作成した次の文書本文を含む。アメリカ国立標準技術研究所.

  1. ^ a b FIPS Publication 183 released of IDEFØ December 1993 by the Computer Systems Laboratory of the National Institute of Standards and Technology (NIST).
  2. ^ Reader's Guide to IDEF0 Function Models. Accessed 27 Nov 2008.
  3. ^ H.L. Gantt, Work, Wages and Profit, published by The Engineering Magazine, New York, 1910; republished as Work, Wages and Profits, Easton, Pennsylvania, Hive Publishing Company, 1974, ISBN 0879600489.
  4. ^ Gerard Blokdijk, Project Management 100 Success Secrets, Lulu.com, 2007, ISBN 0980459907, Google Print, p.76
  5. ^ Peter W. G. Morris, The Management of Projects, Thomas Telford, 1994, ISBN 0727725939, Google Print, p.18
  6. ^ Ben B. Graham (2002). Detail Process Charting. p.2.
  7. ^ Tim Weilkiens (2008). Systems Engineering with SysML/UML: Modeling, Analysis, Design. Page 287.
  8. ^ Harold Chestnut (1967). Systems Engineering Methods. Page 254.
  9. ^ Thomas Dufresne & James Martin (2003). "Process Modeling for E-Business". INFS 770 Methods for Information Systems Engineering: Knowledge Management and E-Business. Spring 2003
  10. ^ Process perspectives. In: Metamodeling and method engineering, Minna Koskinen, 2000.
  11. ^ Systems Engineering Fundamentals. Defense Acquisition University Press, 2001
  12. ^ a b The first version of this article is completely based on the NAS SYSTEM ENGINEERING MANUAL SECTION 4.4 VERSION 3.1 06/06/06.
  13. ^ Task Analysis Tools Used Throughout Development. FAA 2008. Retrieved 25 Sept 2008.
  14. ^ FAA (2006). NAS SYSTEM ENGINEERING MANUAL SECTION 4.4 VERSION 3.1 06/06/06.
  15. ^ Sandia National Laboratories (1992). Sandia Software Guidelines Volume 5 Tools, Techniques,and Methodologies SANDIA REPORTS 85–2348qUC–32
  16. ^ IBM Corporation (1974).HIPO—A Design Aid and Documentation Technique, Publication Number GC20-1851, IBM Corporation, White Plains, NY, 1974.
  17. ^ Mary Ann Goodwin and Charles C. Robertson (1986). EXPERT SYSTEM VERIFICATION CONCERNS IN AN OPERATIONS ENVIRONMENT. NASA paper N88-17234.
  18. ^ a b NASA (1995). "Techniques of Functional Analysis". In: NASA Systems Engineering Handbook June 1995. p.142.
  19. ^ John Mylopoulos (2004). Conceptual Modelling III. Structured Analysis and Design Technique (SADT). Retrieved 21 Sep 2008.
  20. ^ SADT at Free-logisitcs.com. Retrieved 21 Sep 2008.
  21. ^ Gavriel Salvendy (2001). Handbook of Industrial Engineering: Technology and Operations Management.. p.508.
  22. ^ Systems Engineering Fundamentals. Defense Acquisition University Press, 2001.
  23. ^ a b Varun Grover, William J. Kettinger (2000). Process Think: Winning Perspectives for Business Change in the Information Age. p.168.
  24. ^ “BPMN Information”. 2008年11月2日閲覧。
  25. ^ “BPMN FAQ”. 2008年11月2日閲覧。
  26. ^ Richard C. Simpson (2004). An XML Representation for Crew Procedures. Final Report NASA Faculty Fellowship Program - 2004. Johnson Space Center.
  27. ^ S.A. White, "Business Process Modeling Notation (BPMN)," In: Business Process Management Initiative (BPMI) 3 May 2004.
  28. ^ Suh (2001). Axiomatic Design: Advances and Applications, Oxford University Press, 2001, ISBN 0-19-513466-4
  29. ^ Analyze the Business and Define the Target Business Environment. Accessed 27 Nov 2008.
  30. ^ Operator Function Model (OFM). Accessed 27 Nov 2008.
「https://ja.wiki.x.io/w/index.php?title=機能モデル&oldid=94643929」から取得