Rarestyleへようこそ
C#,デザインパターン,UML,オブジェクト指向,Webサービス,iPAQ(モバイル) アクセス数: 
コミュニティマーカー OCPとデザインパターン
コミュニティマーカー サンプルコードについて
コミュニティマーカー デザインパターン ひとくちメモ
コミュニティマーカー FactoryMethodパターン
コミュニティマーカー AbstractFactoryパターン
コミュニティマーカー Builderパターン
コミュニティマーカー Prototypeパターン
コミュニティマーカー Adapterパターン
コミュニティマーカー Bridgeパターン
コミュニティマーカー Compositeパターン
コミュニティマーカー Decoratorパターン
コミュニティマーカー Facadeパターン
コミュニティマーカー Flyweightパターン
コミュニティマーカー Proxyパターン
コミュニティマーカー TemplateMethodパターン
コミュニティマーカー Chain of Responsibilityパターン
コミュニティマーカー Commandパターン
コミュニティマーカー Iteratorパターン
コミュニティマーカー Mediatorパターン
コミュニティマーカー Mementoパターン
コミュニティマーカー Observerパターン
コミュニティマーカー Stateパターン
コミュニティマーカー Strategyパターン
コミュニティマーカー Visitorパターン
コミュニティマーカー 速習!デザインパターン第一回
コミュニティマーカー 速習!デザインパターン第二回
コミュニティマーカー 速習!デザインパターン第三回
コミュニティマーカー UMLとは
コミュニティマーカー UML入門
コミュニティマーカー オブジェクト指向
コミュニティマーカー クラス図
コミュニティマーカー アクティビティ図
コミュニティマーカー インタラクション図
コミュニティマーカー ユースケース図
コミュニティマーカー J2EE覚書
コミュニティマーカー モバイル情報
クラス図 UML表現・オペレーション・構成要素・関連・依存

UML クラス図

クラス図とは

UMLでは、システムの構造をクラス図で表現します。
クラス図は、UMLの中心的ダイアグラムであり、オブジェクトを元に作成することができます。

クラスの表現

クラス

  • クラスはオブジェクトの構造特性と振る舞いを規定します。
  • クラスは、分類子のひとつで、属性(プロパティ)と操作(メソッド,オペレーション)を持ちます。
  • クラスの属性は、プロパティのインスタンスです。

クラス図

クラスの表現の仕方(Visio使用例)
クラス図表現1 クラス図表現2 クラス図表現3
  • クラス名は大文字で中央に記述します。(Person)
  • 基本的にクラス名の最初の文字は大文字にします。(文字セットが大文字をサポートしている場合)
  • 抽象クラスの場合、クラス名はイタリック体で記述します。
  • 属性とオペレーションは左詰
  • 属性とオペレーションの最初の文字は小文字にします。
  • 属性とオペレーションは省略して記述できます。
  • 属性とオペレーションの先頭に可視性を記述できます。
  • 可視性は、グループ化して表示することも可能です。
  • オペレーションはパラメータを与えて呼び出すことが可能です。

オペレーション

オペレーションは、名前と型(戻り値の型)を持つ振る舞い特性です。
オペレーションの書式: 可視性 名前(パラメータ):プロパティ

パラメータ

振る舞い特性の呼び出し時に渡される引数です。
パラメータが複数あるときには、カンマ区切りで記述します。

プロパティ

  • 条件
    • 事前条件
      • オペレーションが呼び出されるときに真ではなくてはならない条件です。
        偽であれば、オペレーションは呼び出されません。。
    • 事後条件
      • オペレーションの終了時に必ず真でなければならない条件です。
    • ボディー条件:
      • オペレーションの返り値。事後条件と異なり、再定義により変更することが可能です。
        事後条件は、再定義により付け加えることのみ可能です。

UMLの構成要素

エレメント

エレメントとは、UMLモデルの構成要素で、すべてのメタクラスに共通のスーパークラスです。
UMLモデルの構成するすべての要素は、このエレメントを継承しており、エレメントは最上位のクラスということになります。

  • 名前付きエレメント
    • 名前をつけることが可能なエレメントをいいます。

ネームスペース

ネームスペースとは、名前付きエレメントの集合を含むエレメントのことです。 ネームスペース自身も名前付きエレメントということになります。 クラスは、典型的なネームスペースであり、ネームスペース内では、すべてのメンバーは名前により識別することが可能です。

限定子

クラスの識別
ネームスペースをAとし、Aに含まれる名前付きエレメントクラスBの識別は

A::B と表現し識別することができます。ネームスペースの名前を"::"でつなぎます。

このとき、エレメントを限定させ、識別させる表記を限定子と呼びます。
(上記の場合の限定子はA::

パッケージ

ネームスペースの一例です。ネームスペースを継承しているメタクラスですが、意味的には、エレメントをグループ化したものです。

エレメントとパッケージの関係は
  • エレメントが複数のパッケージに含まれることはありません。
  • パッケージの移動に伴い、エレメントも移動します。
  • パッケージが消滅すれば、そこに含まれるエレメントも消滅します。
パッケージ内部へのアクセス

パッケージ内では、限定子なしでエレメントを参照できます。またパッケージ内の公開された エレメントは限定子をつけることでパッケージ外からも参照することができます。(public)

分類子

  • 分類子とは、インスタンスを生成できる要素です。
  • クラス、関連、インターフェースは、分類子です。

抽象分類子

  • インスタンス化の情報を完全に提供できない分類子(抽象クラス)
  • 名前は、イタリック体で表す。

可視性

ネームスペースに含まれるエレメントへのアクセスを設定するためのものです。javaなどの言語では、可視性は、クラスの属性(プロパティ) 、メソッド(オペレーション)などを外部に公開する、あるいはパッケージ内のクラスをパッケージ外部に対して 公開するかどうかなどを設定するために用いられます。

アクセス権を制御する4つの可視性
  • public(+)
    • すべてのクラスからアクセス可能
  • private(-)
    • 自分のクラスからのみアクセス可能
  • protected(#)
    • 継承されるクラスからのみアクセス可能
  • package(~)
    • 自分のクラスとパッケージ内部でのみアクセス可能で、パッケージ外のクラスからのアクセスはできません。

継承

継承については、あるクラスの特性を引き継ぎ、新たなクラスを作ると説明していますが、汎化はこれを実現する方法です。

汎化(generalization)と特殊化(specialization)

サブクラスからスーパークラスを導くことを汎化、または抽象化、スーバークラスからサブクラスを導くことを 特殊化と呼びます。

継承関係の表現は、白抜きの三角形と実践で結びます。

継承が行われた場合、サブクラスは、スーパークラスの属性(プロパティ)と操作(メソッド)の仕様を引き継ぎます。

下記の例では、スーパークラスを料理人、サブクラスを、カレー屋さんとラーメン屋さんとします。この場合、 オーダーを取る操作と調理する操作が引き継がれることになります。


オーダーをとるという行為は、カレー屋さんとラーメン屋さんでさほど変わりはありませんが、調理する操作を 考えた場合、2者では少し異なってきます。一般的にこのような場合、カレー屋さんは調理するメソッドをカレーを つくるようにし、ラーメン屋さんでは、ラーメンを作るというように調理する操作を再定義する必要がでます。 (オーバーライド参照)

関連

関連(association)とは

クラス間のつながりに代表されるように、モデル同士の接続など意味的なつながりを関連と呼びます。
また、クラスのインスタンスであるオブジェクトとの間でのつながりは「リンク」と呼ばれます。 クラス間のつながりが「関連」がに対応するように、オブジェクト間では「リンク」が対応します。

関連端(association end)

たとえば、教師と生徒に師弟関係があるとして、つながりをかんがえてみると、先生一人に対して生徒が複数、 接続の部分すなわち関連端は、インスタンスの集合(コレクションのようなもの)といえます。


二項関連

関連には名前をオプションとしてつけることが可能です。また方向を黒い三角形で示すことができます。(下記参照)

関係クラス

関連クラスとは、関連に関する情報をクラスであらわします。また関連に含まれる情報を保持する解釈もできます。
AクラスとBクラスに関連があり、AとBのインスタンスが決まると、関連クラスのインスタンスが一意に決定できると説明されています。 この関連クラスのインスタンスが存在する場合、A,Bのインスタンスも存在していると考えられます。

多重度(multiplicity)

あるひとつのクラスAを基準に他のクラスBを関連させた場合に、ひとつのクラスA(オブジェクトAとする)にもう一方のクラスの インスタンス(オブジェクトB)が対応する数を多重度と呼びます。


インスタンスの集合と多重度

多重度はコレクションと関係しています。インスタンスの集合について、下記の指示子(タグ)で機能を表現できます。
  • {unique}
    • ユニークである
  • {ordered}
    • 順序付けが出来る(存在する)
  • {unordered}
    • 順序付け出来ない(存在しない)unorderedについては、省略が可能である。
  • {stored}
  • 整列する

誘導可能性(isNavigable)

誘導可能性(isNavigable)は、2つの対応関係から一方が決定した場合、もう一方が導けるかということをあらわします。
関連を結びつけた分類子間の参照の方向を指定します。誘導可能性として指定された方向のみにメッセージを送ることができます。

多重度と関連端と誘導可能性

誘導可能性のある関連は、{unique},{ordered}であることから、クラス内に実装することと(属性として保持すること)、 つながりとして関連があるクラスとしてとらえることに意味的な違いがなくなっています。


結果、関連端で表現されるものと、プロパティ(属性)は同じ意味になります。

集約と合成

クラス間に包含関係が存在する場合、全体と部分という表現が 生まれてきます。これを集約と呼び、特に結びつきが強いものを合成とよびます。

集約について

商品とお買上リストのように、商品が消滅しても お買い上げリストがなくなるようなことはありません。 商品オブジェクトとお買い上げリストオブジェクトの 結びつきが少ないのが特徴です。

集約の表現法は、白抜きのひし形と実線を結んであらわします。

合成について

お買上伝票とお買上リストの関連 お買上伝票が無くなれば、お買い上げリストもなくなることを 意味します。オブジェクトの生成単位で考えると、お買い上げ伝票 オブジェクトのインスタンスの消滅は、お買い上げリストの消滅 と同じタイミングであるといえます。

合成の表現法は、黒で塗りつぶしたひし形と実線を結んであらわします。

下記に、合成と集約についてまとめて表現してみます。

N項関連

3つ以上のクラスの関連を表現する場合は、N項関連として表記できます。下記に示しておりますが、白抜きのひし形から、実線で関連している クラスを結びます。

N項関連は、白抜きの大きなひし形と実線を結んであらわします。
  • N項関連について
    • ロール名や多重度が指定できます。
    • 限定子や集約は付けません。

依存関係(dependency)

オブジェクト間に何らかの関係があるが、そのひもづきが強くない場合、 依存関係として、わかりやすく表現できます。
依存関係は、依存する側(クライアント)と依存される側(サプライア)があり、クライアント(依存する側)が何らかの機能を実装 (実現)する場合にサプライア(依存される)を必要とする関係になります。サプライア側の仕様変更はクライアント側に影響を与えます。

依存関係は、破線の矢印を結んであらわします。
  • 依存関係
    • 依存関係には名前をつけることもできます。(任意)
    • 多重度はありません。
    • 依存する側クライアントから依存される側(サプライア)に向けて、破線の 矢印を向けて表記します。
    • 説明には、ノート、ステレオタイプを使用します。

依存関係の種類

  • <<use>> (使用)
    • <<call>> (呼び出し)
    • <<responsibility>> (責任)
    • <<instantiate>> (インスタンスを作る)
  • <<abstraction>> (抽象化)
    • <<derive>> (派生)
    • <<refine>> (洗練)
    • <<trace>> (トレース)
  • <<realize>> (実現)
  • <<substitute>> (代替)
  • <<permit>> (アクセスの許可)

オブジェクトとリンク

クラスのインスタンスはオブジェクト、関係のインスタンスはリンクです。

表現の仕方は、長方形で囲み、下線(アンダーライン)を引きます。
  • 表現書式:
    • インスタンス名:分類子

UML構成要素のまとめ

構成要素イメージを整理してまとめてみます。


コミュニティマーカーUMLインデックスへ

rarestyle
Copyright 2006 Rarestyle このページへのリンクは確認不要です。
Programming by Xenon Project Team     免責事項について