設計 | Javaシルバーコース

シーケンス図

Published by javaSilver on 09/02/2017 | Permalink

ユースケース図で「何を作るか」要求仕様を整理し、
クラス図で「何で作るか」属性(データ)と振舞い(機能)を一体化した処理としてどうまとめるか、クラス構造とクラスの関係を整理しました。
次は処理と処理の関係がいつ発生し、いつ終わるか、時系列に沿ったオブジェクト同士の協調処理の順序や関連性をオブジェクト間のメッセージのやり取り(メソッドの起動)で表すシーケンス図を使って整理します。

シーケンス図とは
オブジェクト指向プログラミング以前には、ソフトウェアは目的の処理を実現するため必要なデータをどういう手順で処理するかに着目していました。そこで、繰返し行われる処理は関数やサブルーチンとしてまとめ、それらの関数にデータを渡すこと(関数の呼び出し)で処理を設計しました。
しかし、複雑なデータ構造を扱うようになると、データ自体についても特定の関数周辺で局所的に使われるデータといろいろな箇所で使われる可能性のあるデータを安全に区分けしたい、などの必要性が高まりました。そして、特定のデータ(属性)と関数(メソッド)を一体化してクラスにまとめ、クラス同士のメッセージ交換(インスタンスの生成や操作の起動)により、クラス同士が同調して目的の処理を実現する、オブジェクト指向プログラミングが提案されました。
このメッセージ交換をいつ行うかのタイミングを検討し、明確化するのがシーケンス図です。

シーケンス図の例
ユースケース図でふれた「映画チケットの予約」処理
(イメージをクリックすると拡大イメージが開きます。)

シーケンス図の構成要素
相互作用名

シーケンス図は矩形の枠の左上隅に相互作用名(シーケンス図の名前)を書き込みます。
相互作用名の前にはsd(sequence diagramの略称)を付けます。

ライフライン

シーケンス図で記述する処理に関係するアクターやオブジェクトがライフラインです。アクターはユースケース図に現れたアクターを書きます。オブジェクトはクラス名を矩形で囲い、インスタンスとして存在している期間を垂直に破線で書き示します。また、インスタンスの操作が実行されている期間を活性区間と呼び、ライフライン上の破線の上に縦長の矩形を乗せて示します。
インスタンスの消滅を明示する場合はライフラインの末端に×印を書きます。

メッセージ

同期メッセージ
戻りメッセージ
非同期メッセージ

生成メッセージ
破棄メッセージ

オブジェクト間のやり取り(インスタンスの生成や操作の起動と戻り)を矢印付きの線と、メッセージ名、戻り値、引数で表します。
なお、呼び出し先の操作が終了するまで呼び出し元は次の手順に進まない同期メッセージは黒塗りつぶしの三角形矢印に実線を書きます。呼び出した操作が終了し制御が戻されることを明示したい場合は、矢印に破線で戻りメッセージを書きます。また、この時呼び出した操作の活性区間は終わります。
相手の操作を呼び出し、その操作の完了を待たずに次の手順に進む非同期メッセージは矢印に破線で書きます。
この他、メッセージにはインスタンスの生成を指示する生成メッセージ、消滅を指示する破棄メッセージがあります。
※Javaでは消滅を指示する破棄メッセージを明示する必要はありません。

自己メッセージ

自分自身が持つ操作の起動は、自分自身にメッセージを送る自己メッセージを黒塗りつぶしの三角形矢印をコの字状に書いて示します。

設計に戻る

クラス図

Published by javaSilver on 09/01/2017 | Permalink

クラス図は開発するソフトウェアを構成するクラス及びクラス間の関係を定義します。
クラス図は基本設計段階ではクラス構造の検討に、詳細設計段階では内部仕様の定義に利用します。
それぞれの段階に合わせクラスの表現粒度は適切に選ぶ必要があります。
特に、設計の最終段階ではコーディングに対する作成指示になるので、クラス構造だけでなくクラス名やメンバー名等についても確認する必要があります。

クラス図の書式

クラス名
クラスを表す矩形を上下3つの部分に分けた上段に記入します。
属性(フィールド)
クラスが持つ属性を矩形の中段に記入します。フィールド名の前にクラスの可視性(メンバーに対するアクセス可能範囲)を表す記号(後述)を付け、フィールド名の後に：(セミコロン)を書きフィールドの型を記入します。
メソッド
クラスの振舞い、操作を矩形の下段に記入します。メソッド名の前に可視性を表す記号、メソッド名の後に戻り値の型を記入します。

クラスの可視性

アクセス可能範囲	UMLの可視性記号	説明
public	+	すべてのクラスからアクセス可能
protected	#	同じパッケージ内のクラス、もしくはパッケージ外のサブクラスからアクセス可能
パケージプライベート(指定なし)	~	同じパッケージ内のクラスからのみアクセス可能
private	–	同一クラス内からのみアクセス可能

クラス間の関係
関連(association)

クラス間で、一方のフィールドで相手のクラスを参照する(has-a)関係。
参照関係にあるクラス間を実線で結びます。
クラスの可視性はこの実線(依存関係では破線)の参照されるクラス側の端周辺にクラス名を、名前の前に可視性を付けて書いたり、実線の両端には多重度を書き、参照するインスタンスの数を明示することもあります。

多重度の表記

文字記号	説明
n	0以上でm及び*より少ない整数
..	範囲
m	0以上でnより大きい整数
*	0以上でnより大きい任意の整数

nが単体で書かれればクラスのインスタンスがn個参照されることを表し、*が単体で書かれればクラスのインスタンスが任意個参照されることを表します。
また、nが範囲記号を伴ってn..mないしn..*などと書かれれば、クラスのインスタンスがn個からm個まで、ないしn個から任意個まで参照される可能性がある事を表します。

集約(aggregation)

関連と似た関係ですが、クラス同士が全体と部分になっている(owns a)関係。
クラス間を実線で結び、全体側に白抜きのひし形を書きます。
部分側のクラスは、別のクラスからも参照される可能性があります。
ちなみにaggregationの意味は「(独立した部分を集めた)集合」です。

コンポジション(composition)

集約の中でも強い関係、全体クラスのインスタンスと部分クラスのインスタンスが同時に生まれ、同時に消滅する関係。
クラス間を実線で結び、全体側に黒塗りつぶしのひし形を書きます。
部分側のクラスは、他のクラスから参照される事はありません。
ちなみにcompositionの意味は「(すべてが一体になった)合成物」です。

依存(dependency)

一方のクラスが相手のクラスに何らかの影響を与える関係。
影響を受ける(依存する)クラスから、影響を与えるクラスに矢印付きの破線をかきます。
影響を与えるとは、クラスが変更された場合、相手のクラスに影響が及ぶという事であり、依存の形態は、メソッド内で別のクラスのインスタンスを使ったり、メソッドの引数や戻り値に別のクラスのインスタンスを使う、などいろいろ考えられます。

実現(realization)

依存の一種ですが、Javaのインターフェースの実装に相当する関係。
実装クラスからインタフェースに破線の白抜き三角形矢印を引き、ステレオタイプ<< interface >>をインターフェース名の上に記述します。

汎化(generalization)

あるクラスの性質、振る舞いを一般化して新たなクラスを定義した時の両クラスの関係。
一般化して作成したクラスをスーパークラス(親クラス)、一般化するクラスをサブクラス(子クラス)と呼び、一般化の方向(サブクラスからスーパークラス)へ実線の白抜き三角形矢印を引きます。
汎化によって定義したスーパークラスをもとに考えると、スーパークラスと類似の性質や働きを持ちながら一部特殊化した新たなサブクラスを派生させることが出来き、Javaの継承に相当します。
※「一般化する」するとは、ある物から特殊な性質を取り除き、多くに共通する普遍的な性質を抽出、概念化する事です。

設計に戻る

ユースケース図

Published by javaSilver on 08/21/2017 | Permalink

ユースケース、分かりそうで分かりにくい言葉です。useもcaseも聞いた事があるため、勝手な解釈で分かった気になりがちですが、そうすると間違った先入観で勉強することになるのでプログラミング上の意味をなかなかとらえることが出来ません。
プログラミングではこういう用語によく出会います。そういう時は英語の意味を確認し、用語の正しいイメージを持って勉強すると効果的です。

ユースケースは一般的には「使用事例」、製品説明などで使われる場合は「適用領域」などの意味です。つまり、ユースケース図は作ろうとしているシステムがどのように利用できるのか、システムが提供するサービスや機能はどのような領域に適用できるるのかを検討し、明示するために利用します。
ユースケース図はシステム開発の工程の中では要件定義の段階で、システムが満たすべき要件を表現し、関係者間の合意形成に使われます。

ユースケース
ユースケース図を描く前に、ユースケース自体は何かをもう少し考えてみましょう。
例えば、一般的なイベントのチケット販売システムを考えてみましょう。
まず、チケット販売システムはチケットを購入しようとしている顧客、公演主催者が利用するでしょう。そして劇場側も劇場の運営などのために、何らかのシステム(劇場運営システム)を通してチケット販売システムからの情報を入手するでしょう。
そして、チケット販売システムは、

–

チケットの予約をする

–

チケットの予約を変更する

–

チケットの予約を取り消す

–

チケットの予約状況を確認する

–

チケットの予約状況を取得する

などの機能、振舞いを持つことが期待されるでしょう。

これら、対象システムは何か、システムを使う人又は物は何か、システムが提供する機能は何かを文章で書こうとすると百人百様になってしまい、関係者が内容を理解するにも時間がかかります。
そこで、これらの事を図式化の決まりに従って簡潔にまとめたのがユースケース図です。ユースケース図を使えば、一目で「システムの利用者(アクター)」が何で、「システムで出来る事(枠の内側)」、「システムで出来ない事(枠の外)」がはっきり分かり、合意形成の議論もしやすいでしょう。

ユースケース図の構成要素

対象

ユースケース図で表現したいシステムを四角形で表し、対象の名前を上部に記述します。

アクター

システムの外でシステムと相互作用するユーザーや外部システムを丸と棒で描いた人型で表します。

ユースケース

システムが外部に対して提供するひとまとまりの機能を簡潔な一文で書き、楕円で囲みます。

関係

アクターと相互作用するユースケース、及び関係のあるユースケース相互を実線で結びます。

以上の構成要素をまとめると、ユースケース図は完成します。

ユースケース図作成上の注意

–

ユースケースはアクターから見た機能が重要なので、外からは見えない内部的な機能、実装技術、性能は記述しません。

–

ユースケースの表現は簡潔な一文が望ましいので、(顧客が）「チケットを予約する」のように、明確な目的語と動詞で表現します。

–

ユースケースの抽出粒度が個々に異なると全体が簡潔にまとまらなくなるので、アクターがある一つの目的を達成するために中断せずに行う機能を単位とすると良いでしょう。必要があれば、目的の粒度に応じてユースケース図を全体と詳細に分けるのも必要です。

–

ユースケース図で表現できるのは、どのような機能が、どのようなアクターと関連するかであって、期待する操作手順や前提条件などは表現できませんし、表現すべきではありません。それらが必要な場合はユースケース図ではなく補助資料としてユースケース記述書(UMLでの書式規定はありません。)などを用意して記述します。

ユースケースの相互関係
同じ粒度で列記したユースケース同士に共通する部分があったり、一部を独立させた方が全体のユースケースが簡潔になる場合、ユースケース間には次の関係があるといい、それらを以下のように記述します。

extend(拡張)
あるユースケースの機能を別のユースケースが拡張する関係。
機能を拡張するユースケースから基になるユースケースに向かって点線の矢印を引き、ステレオタイプ<< extend >>と線上に記述。実線で結びます。

include(包含)
あるユースケースが別のユースケースを内部に含む関係。
包含するユースケースから包含されるユースケースに向かって点線の矢印を引き、ステレオタイプ<< include >>と線上に記述。

設計に戻る