モデリングを行う手法としては、分類や分割、階層化といった方法があります。これも人間が世界を認識するための基本手法です。

分類 
分類とは、事物や現象を、何らかの基準に従って区分することによって体系づけることです。
例えばある企業の人事システムでは、従業員を職位に従って、一般社員、係長、課長、部長、社長に分類することがあります。分割 
分割とは、複雑なものをより簡単な構成要素に分けることです。
システムを複数のサブシステムに分けたり、業務を複数の機能に分けたりします。階層化 
階層化とは、システムを互いに独立している複数の階層に分けて分析、設計及び実装のことです。

モデリングするには、モデリング言語を使用します。 
モデリング言語は、ルールの一貫したセットで定義された構造によって情報、知識あるいはシステムを表現するため使われるあらゆる人工言語のことです。

モデリング言語は図式またはテキスト形式であり得ます。

図式モデリング言語　
図式モデリング言語は、概念を表す名前を持つシンボルと、そのシンボルを結合しその関係を表現するライン、及び制約を表現する様々な図式表記を持つダイアグラム技術を使います。テキスト形式モデリング言語　
テキスト形式モデリング言語は通常、コンピュータが解釈可能な表現にするパラメータによって達成される標準化されたキーワードを使います。

モデリングとは、業務の流れやシステムの構成、といった、論理世界にしか存在しないものを可視化するための技法です。

モデリングは、記号を使ってモデルを作成することによって、問題点の洗い出しや理解の深まり、人間同士間の認識共有を図ります。  なお、業務やシステムを視点に分けてモデリングすることによって、複雑なものを単純化にして人間に理解しやすくすることができます。

人間同士の認識共有

ソフトウェアシステム開発に関わる人間は主に、ソフトウェアシステムを利用する「ユーザ」とソフトウェアを開発する「エンジニア」に大別することができますので、人間同士間の認識共有も、ユーザとエンジニア間の認識共有とエンジニア同士間の共有に分けることができます。

ユーザとエンジニア間の認識共有
ソフトウェア開発では、ビジネスによる要件とシステムによる実装の間には大きな溝があります。エンジニアが直接自分が欲しいと思うソフトウェアを書く場合は、そのようなことはないかもしれません。
しかし、ソフトウェアのことを知らないユーザからの依頼によってソフトウェアの開発を行う場合には、当然この溝は非常に大きなものになります。 
この溝を埋めるために用いる技術が「モデル」です。モデルを仲介して要件と実装の間の溝を埋めます。エンジニア同士間の認識共有
ごく小さいソフトウェアは一人で作り上げることもあるかもしれませんが、殆どの場合はチーム合同の作業になります、なかでは何百人、何千人のエンジニアが同時に開発を行うプロジェクトも少なくありません。 
そこで分析や設計、実装、テストなどの作業を別々の人に担当してもらうのは殆どですので、モデルを通じて、エンジニア同士間の認識共有を図ります。 複雑なものを単純化

業務やシステムは複雑で，そのまま理解することは通常、人間にとっては難しいものです。  着目する視点を分けてモデリングすることによって、業務やシステムを単純化し，理解しやすくします。ただし，業務やシステム自体が単純になったわけではなく，単に着目する部分を絞っているだけです。

用途

DFDとは、本来業務が持ってい る目的を達成するために要する 処理機能（大きな業務を構成す る要素業務に相当。）と情報の流 れを表すものです。

処理の手順ではなく、情報を注目対象としています。
DFDで表現する主な要素：

「情報」がどこからきて どのような処理が行われ その結果がどこに渡されるのか あるいはどこに蓄積されるのか構成要素

DFDは、「ファンクション（処理を行う機能）」、「ターミネータ（情報の発信元、受 信元）」、「情報の流れ」、「ファイル（情報の一時的な蓄積場所）」という4つの 記号により表現されます。

作成方法

DFDを作成する際の基本的なルール

全てのファンクションも、少なくとも1つ以上の「入力となる情報の流れ」と「出 力となる情報の流れ」を持つこと情報の流れは少なくとも1つのファンクションに結合していること全てのファンクションは、入力情報を新しい情報として出力すること全てのターミネータは少なくとも1つの情報の流れと結合していること全てのファイルは少なくとも1つの情報の流れと結合していること
作成事例

業務・システム最適化計画策定指針（ガイドライン）からの「人事給与業務でのＤ Ｆ Ｄ」 の作成事例

外部リンクデータフロー図（Data Flow Diagram / DFD）とはDFD(データフローダイヤグラム)の書き方（2）外部要素からデータフローへDFD(データフローダイヤグラム)の書き方（3）データフローとプロセスの命名についてDFD(データフローダイヤグラム)の書き方（4）データディクショナリーとミニ仕様書DFD(データフローダイヤグラム)の書き方（5）デシジョン・テーブル

モデルは、図や表等でものごとを単純化して表現したものであり、以下のように様々な視点から分類することができます。

言語・表記法対象領域・局面静的か動的か論理か物理か

本トピックでは、各視点からのモデルの分類をそれぞれ説明します。

言語・表記法による分類

モデリング技法は、その仕様や成果物を言語・表記法としてまとめて公開されます。  以下によく使用されているモデリング言語・表記法を取り上げます。

No.言語説明SubNo.表記法説明1UMLUnified Modeling Language 統一モデリング言語---2BPMNBusiness Process Modeling Notation ビジネスプロセスモデリング表記法---3ERDEntity-Relationship Diagram 実体関連図1IDEF1X-2IE表記-4DFDData Flow Diagram データフロー図1Yourdon&Coad記法-2Gane&Sarson記法シンボルは4つのみ5FlowChart流れ図-JIS. X. 0128. -1988-

モデリング技法は、基本的に形式化されたシステム言語を使用してモデルを記述しますが、UMLのユースケースのように自然言語で記述されるモデルもあります。

対象による分類

モデリング対象によって、モデルを以下のように分類することができます。

No.対象UML2.0BPMNERDDFD流れ図1ビジネスアクティビティ図
ユースケース図
コミュニケーション図
クラス図
オブジェクト図○○○○2組織クラス図
配置図×○××3データクラス図
オブジェクト図
パッケージ図×○××4システムコンポーネント図
パッケージ図
クラス図
オブジェクト図
配置図
アクティビティ図
シーケンス図
コミュニケーション図×○○○5プログラムクラス図
コンポジット構造図
オブジェクト図
パッケージ図
アクティビティ図
ステートマシン図
シーケンス図
コミュニケーション図×○○○ 領域・局面による分類

モデルの種類としては、「問題領域(problem domain)」モデルと「解決領域(solution domain)」モデルの二つに大別することができます。

問題領域モデル　
「何(what)」をするのかをモデル化したものです。解決領域モデル 
その「何」をどう実現するのかをモデルしたものです

問題領域モデルと解決領域モデルは、目的に応じてさらに細分化されます。

領域モデル問題領域ドメイン分析モデル要求分析モデル解決領域システム分析モデル設計モデル実装モデルドメイン分析モデル 
現実世界をモデリングしたモデルです。要求分析モデル 
やりたいことをモデリングしたモデルです。システム分析モデル 
プログラミング言語や実行環境といった実現方法に依存しない、ITシステムとして本質的なレベルでの解決方法をモデリングしたモデルです。設計モデル 
プログラミング言語や実行環境を前提に具体的な実現方法をモデリングしたモデルです。実装モデル 
プログラミング言語などによる実装を指します。 静的か動的かによる分類

モデルを静的モデルと動的モデルに分類することができます。

静的モデル 
静的な構造に関するモデルです。動的モデル 
動的挙動に関するモデルです。No.区分UML2.0BPMNERDDFD流れ図1静的モデルクラス図
コンポジット構造図
コンポーネント図 配置図
オブジェクト図
パッケージ図×○××2動的モデルアクティビティ図
ユースケース図
ステートマシン図
相互作用概要図
シーケンス図
コミュニケーション図
タイミング図○×○○ 論理か物理かによる分類

モデルを論理モデルと物理モデルに分類することができます。

論理モデル 
概念上のモデルやプログラム内に存在するオブジェクトに対するモデルです。物理モデル 
ファイルやノードなど具体的に扱うことができるリソースに対するモデルです。No.区分UML2.0BPMNERDDFD流れ図1論理モデルクラス図
コンポジット構造図
コンポーネント図
オブジェクト図
パッケージ図
その他振る舞いを表現する図○○○○2物理モデルコンポーネント図
配置図
その他振る舞いを表現する図○○○○