クラス図について... その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以外のポインタ、パラメータクラスは初期化していること、などが該当する。

[責務]

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

■事後条件

[内容]

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

[責務]

呼び出された側が守る

■不変条件

[内容]

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

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

[責務]

呼び出られた側が守る

※

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

クラス図について

UMLといえば、これって感じだと思う。

クラス図って？

システム(対象)の静的な関係を示すことに用いる。

示すのは、

・クラス名称

   - プロパティ(属性もしくはクラスの関連)

   - 操作

   - クラス同士の関連とその制約

　 (汎化とかコンポジット、多重度、多重の場合は順序指定ありか？など...)

■プロパティ

クラスの属性を指す言葉、属性はクラスの外に出して関連でもかけるから、

属性もしくはクラスの関連って書いてます。

上の図が属性版、下の図が関連版です。どっちで書くかの判断基準ですは、静的構造として重要でない場合は、属性にまとめると書きたいことが伝わりやすいかと思います。

 ■操作

クラスが実行するアクションのこと。

(getter,setterメソッドは書かなくてもわかるから、書かなくてもいい)

クラスに書くときは、状態更新する(modifierもしくはcommand)と更新しない(query)に分けるとわかりやすい。

■関係

汎化についてはリスコフの置換原則を守ること。

依存関係の向きと依存がつくクラス同士の関係が適切か意識する。

UMLモデリングのエッセンス―標準オブジェクトモデリング言語入門 (Object oriented selection)

開発プロセスについて、ちょっと纏め

UMTP Lv2をうけようと思うので、プロセスをちょっとまとめ

■ウォーターフォール型プロセス

プロジェクトをアクティビティ(要求分析、設計、コーディング、テスト)に分けて管理する。

[特徴]

・滝のように流れが決まっていても、流れを上流にさかのぼることがある。

・設計終わった。と思っても試験から設計に戻ることもある

・本番稼働に近いコードが、最後にテストになるので、問題が最後に見つかる可能性

　が、どうしても高く見える。

■反復型プロセス

プロジェクトを機能で分割して、機能ごとに分けて管理(リリース)する。

[特徴]

・一回の反復で機能が完全にできあがらないこともある。こんな時は、最後のほうの

　反復にバグフィックスの反復が入ったりする。

・本番稼働に近いコード(近い品質)が早期にテスト、組み合わせに回せるので、

　問題の早期発見ができる。

■組み合わせプロセス

ウォーターフォール型プロセス、反復型プロセスを組み合わせる。例えば、分析と設計は、組み合わせプロセスで、以降は反復型プロセス。

SVN Blame

コードをSVNやGitで管理していると、このコードをいつだれが変更したか

しべたいことがある。

そんなときは、Blameを使うと各行ごとにだれがいつ変更したか表示される。