このページをはてなブックマークに追加このページを含むはてなブックマーク このページをlivedoor クリップに追加このページを含むlivedoor クリップ

  • 追加された行はこの色です。
  • 削除された行はこの色です。
*目次 [#ze97db05]

#contents


*モデリング [#v91db458]

-モデリングとは業務やデータを分析すること。
-要求や構造を可視化する手段。
--入れ物(箱)を作ることや絵を描くことではない。
---RDBMSを箱としか見ないと、すべてのデータをRDBMSから抜き出した後にプログラム側でデータを検索する必要があるため非効率になってしまう。また、RDBの問い合わせの柔軟性・容易さも失われる。
-洗い出したユーザ要求をモデル化することによって、全体像を把握して矛盾を見つけ出したり実現の可能性を確認したりすることができる。
-[[ステークホルダー]]間で共通言語としてモデルを使う。
--ステークホルダーによってモデリングニーズは異なる。
-理解を試みようとしている対象を整理・分類し、特徴を明確化した結果、理解を試みようとしている対象の理解が容易になってくる。
-我々は現実世界の物に対して必ず概念を抱いている。自分自身が持つ概念を通じて、現実世界を認識・理解しているのである。
--これを逆に言うと、人々は知らず知らずのうちに概念によって現実世界を把握しているといえる。
-[[オブジェクト指向開発]]も[[データベース設計]]のデータモデリングも、その中心的な作業と作業の成果物はそれぞれ[[クラス図]]と[[ER図]]である(当然、これ以外にも重要な作業や成果物はある)。
--構築しようとするシステムをクラスやエンティティを用いて表現し、設計作業が進むにつれて、効果的な設計・実装情報をクラス図やER図に書き加えていくこともできる。
-概念、分類、抽象化の理解度に応じてモデリングの各種技法を効果的に使用できるか、できないかに大きな差が出やすいといわれている。
--ここでいう差とは開発対象(ドメイン)から適切なクラスやエンティティのタイプを抽出し、実世界の関係を適切に表現できる能力を指す。
--特に[[上流工程]]でのモデリングに大きな差が出やすいといえる。
---上流工程では[[概念モデリング]]という作業を行う。この概念モデリングの成果物が概念モデルである。
-オブジェクト指向のクラスやデータモデリングのエンティティタイプを用いることで、我々が物事を取り扱うことや説明することを単純化できる。
-分類についての価値を理解しておくことは、「汎化-特化」「多重分類」「動的分類」などの価値を十分に理解して効果的に活用できることにつながる。
-データ中心開発やオブジェクト指向開発であっても、効果的な開発プロセスや効果的な技法を利用しないと限界がある。
-[[C++]]や[[Java]]を用いて開発するシステムを[[UML]]でモデリングするときは明示的に主キーを付与する必要はない。
--1つのクラスから複数のインスタンス(ただし属性値は同じ)を生成したとしても、それらは区別が付く。なぜならばプログラミング言語が[[メモリ]]上にクラスのインスタンスであるオブジェクトを格納する。コンピュータ上でプログラムを動作させるには、その場所を示すためのメモリのアドレスを使う。C++やJavaの場合、各オブジェクトにメモリのアドレスを自動的に付与するため、属性の中に主キーを用意しなくてよいのである。
-作成するモデルは、利用するプロセス(手法・方法論)によって異なる。
-DBシステムやソフトウェアの開発は建築のアーキテクチャ構築と似ている。建築の設計は、ソフトウェア開発の「分析→アーキテクチャ設計→設計」に対応する。
--建築家のアレクサンダーによってパターンという概念が提案された。
-[[クラス図]]によるモデリングは、モデリングの目的や対象を明確に持たない限り、そのモデルが正しいかどうかがわからない。
--目的が異なると、クラス名や属性が異なる。
--よって、モデリングを行う際には、目的を明確に持つように心がける。


*モデリングの目的 [#c5e82ba4]

 これからシステム開発などを行おうとするドメイン(対象領域)を、モデルの持つ多くのメリットを利用し、理解することである。

 次の観点に注目する。

+業務分析
--現実世界の様子をそのまま捉える。ただしオブジェクト指向と現実世界にはギャップがある。
+要求定義
--コンピュータの性質を考慮して、肩代わりをさせる仕事の範囲を決める。
+設計
--ハードウェアの能力、OSやミドルウェアの特性、プログラミング言語の表現能力などを考慮してソフトウェアの構造を決める。

*分析モデルと設計モデルの違い [#p5c2c581]

-分析レベルのモデル
--開発対象の本質を明確にする。
--通常このまま実装することはせず、設計フェーズで修正が必要。
-設計レベルのモデル
--開発環境に最適化する。
--ER図は必ずしも開発環境を素直にモデル化しているとは限らない。

*各ステークホルダーと必要とされるモデリングニーズ [#a90ce823]

|ステークホルダー|モデリングニーズ|h
|経営層|業務領域全体を把握でき、戦略や目標に対する達成度が評価できる。|
|業務担当者|業務手順を明確にでき、シミュレーションにより実現性を確保できる。|
|開発者|システムの仕様が把握でき生産性が高く、規模の見積もりもできる。|
|運用者|保守や障害対応がしやすく、外部委託できるよう標準化できる。|
|監査者|監査の効率がよく、漏れのないように様々なビューで検証できる。|

*モデリングの難しさ [#o8ab8e18]

-目的や用途によって強調したい部分が異なる。
--つまり、抽象化とは目的とする本質を明らかにすることになる。
-モデリング作業における抽象化では、モデラーの主観や技量が出やすい。
--モデリングを行った人の意思が非常に強く反映される。
--モデラーは自分の持つ概念というフィルターを通じて現実世界の物事や実態を理解して抽象化を行うため、できあがるモデルには人によって異なる。

*モデリングの手続き [#r2430741]

**アプローチ [#bc2f0b64]

-「合意」された語彙→「L-真」の構成→「F-真」の文
--情報の中で使われている語彙を[[観察述語]]として考えて、何らかの(無矛盾な)文法を適用して「文(構成)」を作る(「L-真」を構成する)。次に、「文(構成)」とと現実的な事態を「T-文」で検証する(「F-真」を確認する)。

*モデルの詳細化 [#s7539f45]

**モデルの詳細化の目的 [#d748b613]

-モデルの詳細化の目的は、モデリングの対象となる問題領域について理解を深めることにある。
--そのことが結果的にモデルを実装コードに近づけることになる場合もあるが、そうでないこともある。
--モデルを実装コードに近づけるとは、モデルから実装コードが一意に生成できるかどうかということである。
-クラスの属性の型や操作の引数や戻り値を明確にするようなモデルの詳細化は、モデルを実装コードに近づけるための詳細化である。
-例えば、関連の線だけのものと、関連の線に集約を付けたものを実装コードに落とす際に明確な違いはない。
--このようにモデルの意味付けを詳細化することは、分析・設計時にモデルの対象となる問題を深く理解させることに繋がる。

例:業務分析時には、業務の本質的な概念構造を理解するために、要求分析時には要求の理解を促進するために、ソフトウェア設計時には設計アーキテクチャの理解を深めるためには、モデルの意味付けを詳細化するわけである。 ◇

例:[[C++]]などのメモリ管理を行う必要がある[[プログラミング言語]]では、オブジェクトのライフサイクルを管理するオーナーを集約から想定することもできる。これは実装コードを示唆する効果がある。

しかし、そのような観点だけで集約を使っていると、理解のためのモデルの本質が失われてしまう。 ◇

*参考文献 [#e73895c6]

-『ITアーキテクト×コンサルタント』
-『モデルとプロセスをめぐる冒険』
-『オブジェクト指向でなぜつくるのか』
-『44のアンチパターンに学ぶDBシステム』
-『SEのためのモデルへのいざない』
-『これだけでわかる!初歩のUMLモデリング』