「統一モデリング言語」のことなんだけど、言語といいつつ実はすべて図。
オブジェクト指向の要求抽出、設計に使われる図（ダイヤログ）は、ブーチ、ランボー、ヤコブソンでそれぞれ違っていた（この３人をスリーアミーゴスといいますが、踊る大捜査線とも鈴木亜美さんとも、全然関係ないです）。
で、そこで、この３人によって、オブジェクト指向分析、開発のためのダイアログが統一（統合）された。それがUML
唐突だけど、情報処理っていうのは、畢竟（ひっきょう）
・入力情報（データ）をもとに
・情報を処理（プロセッシング）して
・出力情報（データ）を得る
っていう行為。
なので、設計するには、データの構造とプロセスのふるまいがわかればいい。
オブジェクト指向においては、
データの構造などは、構造図（のグループに属する図）で表現する
プロセスのふるまいは、ふるまい図（のグループに属する図）で表現する
構造図にはクラス図などがあり、振る舞い図には、アクティビティ図、シーケンス図などが属する。
ただ、いろいろあるけど、図はすべての情報を表現できない。
全部表現できなくて、不便ではないの？というと、不便ではない。
っていうのは、オブジェクト指向にかかわる人は要求分析者、設計者（システムエンジニア）、プログラマ等様々な人がいるから、その人にあった情報があればいい。
→なので、学会なんかで、UMLに●●の要素を加えたものを提案するとか言って論文を出すと、いや情報足すのに何の有用性があるの？っていう感じでリジェクトされる可能性大なので注意！
じゃあ、設計の時にどのような図を使うかっていうことなんだけど、
・分析段階でまず、ユースケース図を使って、システムを大雑把に
把握するとともに、関連アクターをチェック
。ユースケースがどのような業務プロセスかを詳細化していくために
アクティビティ図を作成
・各アクティビティに関連するデータを考えて、クラス図作成
・アクティビティ達成のために各クラスがどのようなふるまいをすれば
いいかを分析するため、シーケンス図を作成
っていう流れになるかな。詳しくは、こんな本に書いてある
ただ、上の流れは、事務系のシステムの話で、制御系の場合には、ステートチャート図などのほうが使われる。
なお、開発の図というと、ほかにDFDやER図が有名だが、これらはUMLに入らない。これらはオブジェクト指向ではなく、構造化設計手法で使われる。
これ以上詳しい話は、ネットでググってもらうとして、今回のお話はここまで。
アクセス
トータル
ランキング
