Olen onnellinen.

■ クラス図
もはや説明不要。試験では最も出題数が多い。

■ 属性・操作の記述



この辺りは覚えるだけ。

■ 関連
実線で繋ぐ。"＜"矢印をつけるとメッセージを送信できることを表す（誘導可能性）



上図においてクラス3からクラス4へメッセージが送信できる。
"く"がある場合はできる、"×"がある場合はできない、何もない場合はわからない


■ 集約
ひし形付き実線で繋ぐ。

・ 塗りつぶし→コンポジション
・ 白抜き→共有集約



コンポジションと共有集約の違い
図のクラス5が消滅したときにクラス6は同時に消滅するけどクラス7は消滅しない。
コンポジション（composition）は合成、集約はアグリゲーション（aggregation）ともいう。


■ 汎化
白抜き三角矢印で繋ぐ。



ユースケース図のアクター間、ユースケース間と同様です。


■ 依存関係
破線の"く"矢印で繋ぐ

abstraction 抽象化
・ derive 派生
・ refine 洗練
・ trace トレース

use
・ call 呼び出す
・ instantiate インスタンス化する
・ responsibility 責任

realize 実現化

substitute 代替する

permit アクセス許可する

また、realizeには別の記法もあります。





■ エレメント
すべてのスーパークラス。Javaでの"java.lang.Object"。

■ 式（expression）
評価した結果が値またはその集合である表現。OCLで記述できる。（※ OCLだけではない）

■ UML のプリミティブ型
・ Integer
・ Boolean
・ String
・ UnlimitedNatural

■ シーケンス図とは
インタラクション図（相互作用図）の一種。
実業務でもそれなりに使われる。でもなんちゃってシーケンス図のことが多い。


■ イベントの発生順序
問題にしやすいということもあって、抑えておきたいのがイベントの発生順序。

以下のシーケンス図をみてください。



4つのイベント「A()の送信」「A()の受信」「B()の送信」「B()の受信」を順番に並べてみてください。

解答1

1.A()の送信

2.A()の受信

3.B()の送信

4.B()の受信


これはよいですよね。明らかです。
ですが他にも解答があります。

解答2

1.B()の送信

2.A()の送信

3.A()の受信

4.B()の受信


ポイントは『送信→受信の順に流れる』『生存線上では上から下に流れる』というルールです。

つまり、図からは以下のルールが読み取れます。

ルール1：A()の送信→A()の受信の順

ルール2：B()の送信→B()の受信の順

ルール3：A()の受信→B()の受信の順


このルールのみ満たしていればよいことになります。A()とB()でどちらが先に送信されるかは不定です。
もちろん、このルールは『非同期メッセージ』のときのみのルールなことも注意です。

■ アクティビティ図とは
一連の処理の流れを表す。エンドユーザと開発者の意思統一のために有効な設計書となり得ます。

■ 構成要素

ノード

・アクション

・オブジェクトノード

・コントロールノード

角が丸い四角形で表すのがアクション、
四角形がオブジェクトノード、
その他の開始ノードなどをコントロールノードと呼びます。


エッジ

・コントロールフロー

・オブジェクトフロー

アクション同士と実線＜矢印で接続しているのが『コントロールフロー』、
値が渡っているものが『オブジェクトフロー』


アクティビティ図はこれらの構成要素を説明できれば十分です。

■ 全体
OCUPはUMLの仕様やセマンティクスを問う試験になっています。
その点はモデリング技能を問うUMTPと異なることを意識しておく必要があります。

OCUPの中で最も基本的となるのがファンダメンタルであり、クラス図、アクティビティ図、ユースケース図、シーケンス図が対象となります。


■ ユースケース図
ユースケース図はシステムの外側からみた振る舞いを表します。
『振る舞い』つまり、システムが提供するサービスを『ユースケース』、
利用者などのシステムの外側から関わるものを『アクター』と言います。

ユースケース、アクターともに3つの表記法があり、試験ではすべてを抑えておく必要があります。

■ 関連と関係

関連

アクターとユースケースを実線で結ぶ。



関係

1. 汎化関係
アクター間、またはユースケース間の関係です。白抜き実線矢印で表します。



2. 包含関係、拡張関係
ユースケース間の関係です。破線矢印にinclude, extendのステレオタイプをつけます。


破線矢印には「包含」、「拡張」の両方の意味があるため、実際にどちらかはコンテキストから判断しなければなりません。試験ではともかく、実業務ではステレオタイプを明示したほうがよいです。

ファンダメンタル(Fundamental)とは「基本」「基礎の」といった意味です。
ベーシックとかより格好良いですね。音の響きとかだけですけど。

例によってとりあえず試験範囲をざっと流し読み。


■ ユースケース図
・ アクター
   システムに外部からかかわるもの。スティックマンアイコンを用いることが多いが任意のアイコンを使用できる。

※ スティックマンアイコン


人型だと直感的にわかりにくいのかも。

ユースケースはシステムの振る舞いを表す。アクターに対してのサービスの観点で記述する。
また、ユースケース図だけでなく、ユースケース記述もつけて説明する。


■ アクティビティ図
コントロールフロー、データフローを表現する。
↓こんなやつ


要件定義段階で作ることが多く、お客様が見ることも想定されるので、
見やすく、読みやすく記述したいです。(個人的希望)

・ ガード
   分岐条件みたいな。複雑な場合デシジョン入力(<>キーワードをつけたノート)に記述できる。

・ ピン
   オブジェクトノードの表現。

・ 複数の開始ノード
   複数開始ノードが存在する場合はすべて同時に開始される。
   開始ノードは黒丸(●)で表す。


■ インタラクション図とシーケンス図
イベントのトレースを表す。
↓こんなやつ