クラス図について... その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を使うと各行ごとにだれがいつ変更したか表示される。

プレゼントしたい本ということで...

「プレゼントしたい本」ということで、数学ガールという数学の読みものをプレゼントしたい。特に数学が嫌いな人に読ませたい。

理由は、大学の時に、これをよんで目からウロコの思いをして、テンションがバカ上がりしたから、「もう高校の時の数学の授業ってなんやったん!!」って感じ。

数学ガール (数学ガールシリーズ 1)

 数学を探求するロジカルな部分と登場人物の心理描写の淡い感じがいい感じにミックスされていて、数学がわからなくても読めるし、わかる人も楽しめる。

特にすごいのは、学校で習うのとはちがって、公式ができている理由を丁寧に追いかけて、追いかけてから、公式にたどり着くので、ちゃんとわかるということがすごい。

(数学苦手な自分は、物語をなぞって数式をノートに書いたりしたけど....)

自分は、数学Aの中間テスト36点(100点満点中)でしたが、フィボナッチ数列がわかったよ。

あの感動をうまく文章にできませんでしたが、ぜひ読んで新しい世界の扉をあけていただきたい。

まじで、数学がちょっとでもわかると、以前の自分と世界の見方がかわるので。

数学ガール/フェルマーの最終定理 (数学ガールシリーズ 2)

※

恋愛系としても読みだせます。漫画からはいるのもいいかも。

数学ガール 上 (MFコミックス フラッパーシリーズ)