UMLについて 2017/02/12

勘違いや間違いがあったので、備忘録...

・UMLに独自の図を追加して使うことはできない。

 UMLの仕様はOMG(Object Management Group：オブジェクト指向技術の標準化を行なう団体)が決めているので、この仕様にない図を使ったものはUMLとは認められない。

拡張をする場合は、UMLの仕様にあるメタ属性や制約、ステレオタイプで行う。この拡張のセットをUMLプロファイルという。

・UMLの図の種類

構造図：クラス図、オブジェクト図、パッケージ図、コンポーネント図、コンポジット構造図、配置図

振る舞い図：ユースケース図、アクティビティ図、相互作用図、ステートマシン図

なお、相互作用図は、更にシーケンス図、コミュニーケーション図、タイミング図、相互作用概略図が存在する。

以下Wikipediaにある図

・UnifiedProcess

以下のフェーズからできている

(1)方向づけ：対象システムが実現可能であるか判断する

(2)推敲：アーキテクチャを策定

(3)作成：製品レベルのシステムを作り上げる

(4)移行：利用環境に適応しているかの確認を行う

パッケージ図 その２

パッケージを描くときは、パッケージ間の依存関係を意識する。具体的には、単一方向に依存が付くような場合が望ましい。

例外はあって、Mapperパターンのデータマッパーなどは、データを管理する層とロジックの層の橋渡しをするため両方から依存が付く。

橋渡しでは、ロジック層で扱うデータをデータ保存するのに適した形に変換したりするので、両方から依存が付くのが自然で正しい。

パッケージ図

■パッケージ図

クラスをグルーピングする構成要素です。グルーピングの基準では、以下に注意する。

・閉鎖性共通の原則(Common Closure Principle)

1つのパッケージ内のクラスは、同じような理由で変更されるべきという原則 

・全再利用の原則(Common Reuse Principle)

再利用するときはパッケージ丸ごと再利用する 

クラス図について... その3

■分類と汎化

よく汎化のことを、ia-a関係というが注意しないといけないことがある。

それは以下のいずれもia-a関係であるということ。

・分類:ポチはボーダーコリーです。(ポチ is ボーダーコリー)

・汎化:ボーダーコリーは血統です。(ボーダーコリー is 血統)

サブタイプ化(汎化)をする際には、２つの上が混在したりしないように注意が必要となる。

■多重分類

一つのクラスに複数のサブセットタイプがつくこと。

この概念をそのまま実装することは難しい(やり方がない?)ため、概念レベルの設計で利用されることもあるけど、個人的にはわざわざ一般的でない書き方をしなくても...と思う

 上の図では、Carクラスは、グレード(HighとLow)と駆動方式(4WD、FD、FR)の2つのサブクラスのセットに属している。

■関連クラス

関連クラスは関連に付くクラスであり、これにより関連に属性、操作を追加できる。

関連クラスのインスタンスは、関連両端のオブジェクトに対して１つしか存在できないという制約が付く。

このため、1つしか存在しない場合は関連クラス、1つ以上存在する場合は普通のクラスとしてモデル化する。

クラス図について... その2

UML モデリングのエッセンス 第3版 (Object Oriented SELECTION)

5章読んでいて、使っている表現と使っていない表現があったので、復習を兼ねてまとめ。

■クラスに追加するとわかりやすくなる(具体的な書き方は上の書籍参照)

・キーワード：このクラスはインターフェースクラスだよといったことを明示する

・リスポンシビリティ：クラスの責務を明示する

・staticな操作、属性  ：CやC++のstaticみたいなやつは明示しようという話

　ほんとにクラスの要素ある必要あるの？とか検証に使えそう

・派生プロパティ       ：他のプロパティに依存する(計算できたりする)プロパティ

■クラス関連の書き方

・集約：よくいうのはhas-a関係で所有権のある場合に使う。といっても、has-a関係

　でも関連で書かれていることはよくあります。

    あまり深く考えずに、関連より強い関係のときに使うぐらいでいいと思う。

　書いた人がいれば聞くのが一番だと思うが、かなりの確率で、特に意味はない

　という答えになると思います。

・コンポジション：コンポジションクラス(所有する側)が消えるとき、所有されて

　いるクラスも消えてしまうような、とても強い関係の場合に使う。

 ■クラス図自体の書き方

・インターフェース：すべての操作が抽象操作で、直接インスタンス化できない。

・抽象クラス：1つ以上の抽象操作(実装がない操作)をもつクラス。

　直接インスタンス化できない。

2つの差異は、インターフェースはクラスの機能(振る舞い)を示すもので、抽象クラスはクラスの意味を示すもの。(間違ってたらごめんなさい)

インターフェースクラスは特に重要で、クライアントクラスがインターフェースに依存するようにして、実装に依存しないようにすることで、実装の変更がクライアントに及ばないようにする。(詳しくは依存関係逆転の法則をみてください)

シーケンス図

システムの動的構造(振る舞い)をモデル化に使用する。特にクラスやオブジェクトなどの何らかのモノの間のコラボレーションを記述する。

アルゴリズムやループを書くのが目的じゃなくて、コラボレーションを記述するのに便利なダイアグラム。なので、練習以外の目的でアルゴリズムとかをシーケンス図でかかないようにする。

(アルゴリズムとかは、疑似コード、いっそコードで示せばいいと思う)

あと、設計時は同期と非同期は意識して書くことが大事です。例えば、非同期メッセージの要求と応答に隙間ができるので、割り込みが入る場所目に見えてわかる。

契約による設計(Design By Contract)

クラスやメソッドの事前条件、事後条件、不変条件を明確に表明する設計手法を、契約による設計(Design By Contract)という。

■事前条件

[内容]

実行前に満たすべき条件。例えば、引数には0以上の整数、NULL以外のポインタ、パラメータクラスは初期化していること、などが該当する。

[責務]

チェックするのは、呼び出し側が行う

■事後条件

[内容]

結果についての決まり。例えば、検索条件に合う住所や施設名称を返す、複素数の演算結果を返す、など操作に実行後に保証することが該当する

[責務]

呼び出された側が守る

■不変条件

[内容]

クラス事態に関する表明。これがでてくるのは継承が入ってきたとき。

サブクラスはスーパークラスと同じように扱えることが望まれる(リスコフの置換原則)から、サブクラスには、スーパークラスの事前条件、事後条件が不変還俗としてついてしまう。

[責務]

呼び出られた側が守る

※

メモしていて思ったんですが、継承関係に負の可変性がついた場合は不変条件はダメになる?