「uml」の記事 - Crieit

実践UML記述法：シーケンス図で継承元（親クラス）のメッセージ（メソッド）を利用する際の書き方について

2021-11-26T19:37:42+09:00

TL; DR

クラス名::メソッド名 なんてどうでしょう？

本題：シーケンス図で継承元（親クラス）のメッセージを利用する

シーケンス図のメッセージは、ライフラインがクラス図のクラスと紐付いている場合、クラスの操作を使うことが一般的かと思います。

2つだけのクラスを持つクラス図とシーケンス図

@startuml
title クラス図の例

skinparam classAttributeIconSize 0

class 利用者 {
}

class クラス {
  + 操作()
}

クラス "1 - used" <-- "1" 利用者
@enduml

@startuml
title シーケンス図の例

participant ": 利用者" as 利用者
participant "used : クラス" as クラス

利用者 -> クラス: 操作()
@enduml

しかし、継承元クラス（親クラス）のメッセージを利用する際、クラスとしては持っていない（かのように見える）メソッドを呼出すように書く必要があります。

継承が1つ存在するクラス図とシーケンス図

@startuml
title 継承が1つ存在するクラス図の例

skinparam classAttributeIconSize 0

class 利用者 {
}

class 親クラス {
  + 操作()
}

class クラス {
}

親クラス <|-- クラス
クラス "1 - used" <-- "1" 利用者
@enduml

@startuml
title 継承が1つ存在するシーケンス図の例

participant ": 利用者" as 利用者
participant "used : クラス" as クラス

利用者 -> クラス: 操作()
note right: 表記上の違いが無い
@enduml

上記はわかりやすい例ですが、下記のように継承とメッセージが複数存在すると、どのクラスのどのメソッドが使われているのか把握しづらくなります。
特に、子クラスのメソッドで親クラスのメソッドを呼出すような形は、どれがどのクラスで実装されているのか把握しづらいです。

継承が複数存在して視認性が悪いクラス図とシーケンス図

@startuml
title 継承が複数存在して視認性が悪いクラス図の例

skinparam classAttributeIconSize 0

class 利用者 {
}

class 高祖父母クラス {
  + create()
}

class 曽祖父母クラス {
  + read()
}

class 祖父母クラス {
  + update()
}

class 親クラス {
  + delete()
}

class クラス {
  + 操作()
}

高祖父母クラス <|-- 曽祖父母クラス
曽祖父母クラス <|-- 祖父母クラス
祖父母クラス <|-- 親クラス
親クラス <|-- クラス
クラス "1 - used" <-- "1" 利用者
@enduml

@startuml
title 継承が複数存在して視認性が悪いシーケンス図の例

participant ": 利用者" as 利用者
participant "used : クラス" as クラス

利用者 -> クラス: 操作()
note right: それぞれのメッセージが\nどのクラスのものか\n把握が難しい
クラス -> クラス: read()
クラス -> クラス: delete()
クラス -> クラス: create()
クラス -> クラス: update()
@enduml

また、上記のような状態において、UML2系で記法の定義はされていません。

現状で最新のUML2.5.1では、メッセージの記法は以下のように定義されています。
request-message-label という部分が今回のターゲットとなるメッセージラベルです。
中身を確認すると、メソッド名に該当する message-name、引数に該当する input-argument-list の2つしか存在しません。
クラス図の属性や操作には prop-modifier という名で詳細を記述できるため以下様にもできるのですが、シーケンス図のメッセージには上記の様な補足も書けないことになっています。

 ::=  |  | ‘*’

 ::=  [‘(‘[] ’)’]
 ::=  [‘,’*]
 ::= [ ‘=’]  | ‘-’

;  の定義は省略する

About the Unified Modeling Language Specification Version 2.5.1

解決策

ここで、 message-name の定義を考えてみます。
定義は以下の通りです。

The message-name appearing in a request-message-label is the name property of the Message.
If the Message has a signature, this will be the name of the Operation or Signal referenced by the signature.
Otherwise the name is unconstrained.

request-message-labelに表示されるmessage-nameは、そのMessageのnameプロパティです。
Messageにシグネチャがある場合は、そのシグネチャで参照されるOperationやSignalの名前になります。
それ以外の場合、名前は制約を受けません。

ここでいう「シグネチャで参照されるOperationやSignal」は、多くはライフラインに紐付くクラスの操作（つまりメソッド）です。

操作を記述する際、クラス名の記載の有無についてまで明記はありません。
しかし、UMLの仕様書にも多く書かれている記述として クラス名::操作名 という書き方が使える様です。
であれば、メッセージ名としても同様の記述を使えば良いのではないでしょうか？

継承が複数存在するが視認性をある程度補えるシーケンス図

@startuml
title 継承が複数存在するが視認性をある程度補えるシーケンス図の例

participant ": 利用者" as 利用者
participant "used : クラス" as クラス

利用者 -> クラス: 操作()
クラス -> クラス: 曽祖父母クラス::read()
クラス -> クラス: 親クラス::delete()
クラス -> クラス: 高祖父母クラス::create()
クラス -> クラス: 祖父母クラス::update()
@enduml

結論

クラス図におけるクラスの属性や操作の補足的記法をベースに考えることが多いため、シーケンス図でも同様の書き方ができないかを調べた挙句、シンプルな記法を思いつきました。
遠回りした気もしますが、お蔭でさまざまな定義などの再学習もできたため、結果的には良かったと思います。
仕様書、万歳！

実践UML記述法：ユースケース図におけるユースケース間の関係の書き方を疑似コードから逆変換して考える

2020-10-04T23:28:17+09:00

本記事は、 Qrunch からの移転記事です。

移転元: 実践UML記述法：ユースケース図におけるユースケース間の関係の書き方を疑似コードから逆変換して考える - 雑木林

TL; DR

ユースケース図の include および extends は、それぞれメソッドおよび if 文が真の場合のメソッドに変換できます。
また、拡張点は if 文の真偽値判定に変換できます。

本題：ユースケース図におけるユースケース間の関係の書き方を疑似コードから逆変換して考える

UMLのダイアグラムの1つに、ユースケース図というものがあります。
ユースケース図とは、ステークホルダーとシステムの関係を、簡易的に図として表現するものです。

以下のような図を、人生で1度は見たことがあるはずです。

@startuml
title 冷蔵庫利用者のユースケース図

left to right direction

actor "利用者" as user

rectangle 冷蔵庫 {
  usecase set_item as "食品を入れる
  ---
  extension points
  食品にラッピングが付いている"
  (食品を取る) as get_item
  (ドアを開ける) as open_door
  (ラッピングを外す) as remove_wrapping
  set_item ..> open_door : <>
  get_item ..> open_door : <>
  set_item <.. remove_wrapping : <>
}

user --> set_item
user --> get_item
@enduml

問題点

ここで、よく混乱するのが include および extend の意味、および、矢印の向きです。

include は、あるユースケースは別のユースケースを包含している、という意味を表します。

ユースケースBの中には、ユースケースAが含まれていることを示します。
「has a」関係、つまり、「ユースケースB has a ユースケースA」の関係が成り立ちます。

extend は、あるユースケースが別のユールケースを拡張する、という意味を表します。

ユースケースAに対して、機能を追加するようなユースケースBの関係を示します。

ユースケース図(Use Case Diagram) - UML入門 - IT専科

この包含と拡張、という単語の違いは、個人的には非常に理解が難しかったです。
それにより、以下の疑問が顕在化します。

どのように include と extend を使い分けるのか
なぜ extend の矢印の向きは include と逆なのか

しかし、下記ページにより、長年の疑問が解けたので、解説しようと思います。

ユースケース図のincludeとextend:アーキテクト360

解決策

エンジニアは、図で理解するより、ソースコードで理解する方が簡単ですよね。
ということで、上記ユースケース図の例を、疑似コードに置換えてみます。

冷蔵庫利用者のユースケース疑似コード

# TODO: 例として挙げたユースケース図からは、ユースケースの実行順序までは読取れない

def ドアを開ける:
    # ドアを開ける際の処理記述

def ラッピングを外す:
    # ラッピングを外す際の処理記述

def 食品を入れる:
    if 食品にラッピングが付いている:
        ラッピングを外す()
    ドアを開ける()
    # 食品を入れる際の処理記述

def 食品を取る:
    ドアを開ける()
    # 食品を取る際の処理記述

各ユースケースは、各メソッドと対応します。

include の関係先ユースケース（例における「ドアを開ける」ユースケース）は、関係元ユースケース（例における「食品を入れる」ユースケースおよび「食品を取る」ユースケース）の共通部品として、関数内で呼出すメソッドとして対応します。

extend の関係元ユースケース（例における「ラッピングを外す」ユースケース）は、関係先ユースケース（例における「食品を入れる」ユースケース）を一部拡張するため、拡張点「食品にラッピングが付いている」場合にのみ呼出すメソッドとして対応します。

ここで注意ですが、例として挙げたユースケース図からは、ユースケースの実行順序までは読取れないことに気をつけてください。
例えば、「食品を入れる」ユースケースで実行する、「ドアを開ける」ユースケース／「ラッピングを外す」ユースケース／「食品を入れる」ユースケースの3つ（3番目は、ユースケース自身のユースケースを指す）は、本来は前後関係がありますが、ユースケース図からは読取れません。
「ドアを開ける」前に「食品を入れる」ことはできませんし、「ラッピングを外す」前に「食品を入れる」ことは、本来はできないので、疑似コードでは順序を指定してます（ドアを開けた後にラッピングを外すことはできますが、電気代が掛かるので、先にラッピングを外しています）。

表でまとめると、下記の通りです。

ユースケース図	疑似ソースコード
ユースケース	メソッド
`include`	関係元ユースケースの内部で実行するユースケース
`extend`	関係先ユースケースの内部で、拡張点が真の場合に実行するユースケース
拡張点	`extend` の関係元ユースケースを実行する場合は真を表す真偽値

こう見ると、最初の疑問点がはっきりすると思います。

どのように `include` と `extend` を使い分けるのか

include の関係先ユースケースは、複数のユースケースから呼出されることを想定し、共通部品化すると良いです。

extend の関係元ユースケースは、まず関係先ユースケースを共通部品化し、ある分岐点（拡張点）でのみ実行するユースケースとして外出しすると良いです。

なぜ `extend` の矢印の向きは `include` と逆なのか

ここは、私の個人的な見解を述べます。

extend が include と逆向きなのは、 extend の関係元ユースケースが拡張点を求めていることが理由と考えます。
すなわち、 extend の関係元ユースケースは、関係先ユースケースにおける拡張点に「依存」していると言えるのではないか、と考えます。

疑似コードを見ればわかりますが、 extend の関係先ユースケースに拡張点が存在しないユースケース図は、どのような場合に関係元ユースケースが実行されるのか、判断できかねます。
つまり、 extend の関係元ユースケースと、関係先ユースケースの拡張点は、セットであると考えるのが自然です。
さらに言えば、 extend の関係元ユースケースは、関係先ユースケースの拡張点なしには関係を結ぶことは難しく、拡張点に依存して存在を維持している関係である、と言うこともできます。

結論

ユースケース図の関係は、疑似コードから逆変換して考えてみると、理解しやすい気がします。
UMLは高度に抽象的であるため、具象的な疑似コードに置換えることで、把握しやすいのかもしれません。

これを元に、ユースケース図がもっと流行ることを期待します。

実践UML記述法：スクリプト言語（Python, Perl, PHPなどなど）における可視性をUMLで記述する1考察

2020-10-04T23:17:50+09:00

本記事は、 Qrunch からの移転記事です。

移転元: 実践UML記述法：スクリプト言語（Python, Perl, PHPなどなど）における可視性をUMLで記述する1考察 - 雑木林

TL; DR

スクリプト言語における可視性をUMLで記述する場合、リバースエンジニアリングによる結果論的可視性を書くといいかもしれない

本題：スクリプト言語における可視性をUMLで記述する

UMLには可視性という概念があります。

Javaにおけるアクセス修飾子とほぼ同等のもの、と考えておけば間違いではありません。
public、private、protected、およびpackageです。

スクリプト言語（ここではPython、Perl、PHPといったいわゆるP言語を対象としておきます）には、絶対的な可視性はありません。
例えばPythonであれば、変数の前にアンダースコアを付けることで「疑似的に」プライベート変数を設定できますが、実際に外部から参照できないわけではありません。

問題点

スクリプト言語で開発する場合、UMLにおける可視性の情報は無意味です。
それどころか、余計な情報として「ノイズ」と言われても仕方ありません。

UMLには可視性を書かなくても構文的に問題ないため、可視性の情報無しでも大丈夫です。
しかし、それでは次のような問題が起こりえます。

UserクラスがInformationクラスと関連しているクラス図

@startuml
class User {
    printText()
}

class Information {
    text
    message
}

User --> "1\ninfo" Information
@enduml

さて、上記のクラス図から「UserクラスはInformationクラスのtext変数を参照しているが、message変数は参照していない」という情報を読み取れるでしょうか。

UserクラスがInformationクラスを持っているPythonコード

class User:
    info = Information()
    # クラス図におけるprintText()メソッドと対応
    def print_text(self):
        print ("{}".format(info.text))

class Information:
    text = "This is printed"
    message = "Oh no!"

お分かりの通り、クラス図からでは理解できません。
しかし、クラス図から変数の利用状況が理解できなければ、結局コードを読まなければならず、UMLの浸透には貢献できません。

余談ですが、クラス図ではprintTextとキャメルケースにしているところ、Pythonコードではprint_textとスネークケースにしています。
これは、UMLがキャメルケース、Pythonがスネークケースを推奨しているためです。

解決策

発想を逆転します。
設計時に可視性を決めるのではなく、コード上で利用しているか否かを判断し、それをUMLに反映してはどうでしょうか？

UserクラスがInformationクラスと関連しておりmessage変数は利用していないクラス図

@startuml
class User {
    - printText()
}

class Information {
    + text
    - message
}

User --> "1\n- info" Information
@enduml

上記のクラス図から、「少なくとも」Informationクラスのmessage変数を外部クラスは参照していないことがわかります。
また、他の変数（info）やメソッド（printText()）についても、外部からの参照はないことがわかります。

上記のクラス図を見ただけで、Informationクラスはtext変数にのみ注意すればよく、message変数はInformationクラス内部を見れば把握できることがわかります。

結論

どうでしょう。
あくまで視点を変えただけですから、「言われなくてもその通りじゃん」と言われればごもっともです。
UMLを設計ツールとして可視性を考えるのではなく、UMLをあくまで可視化ツールとして利用するという考え方であれば、UMLを利用しやすくなるのではないでしょうか。

実践UML記述法：UMLのクラス図における関係の考察

2020-10-04T23:14:35+09:00

本記事は、 Qrunch からの移転記事です。

移転元: UMLのクラス図における関係の考察 - 雑木林

はじめに

UMLのクラス図には、ノードのようなもの（クラスやインタフェースなど）とエッジのようなもの（関連や依存など）を記述できます。

さて、クラスやインタフェースをプログラミング言語に落とし込むには、あまり苦も無く変換できると思います。
私もクラス図とPerlの変換について、記事を書いたりしていました。

クラス図とPerlの対応付け: https://qiita.com/Morichan/items/cfa83fee6d451847ef85

しかし、エッジのようなもの（以降、関係と呼びます）は、汎化関係以外を書くのは難しいのが現状です。
C++への変換において、「Recovering UML class models from C++: A detailed explanation」では、関係をC++に対応付けするためには意味解析 (semancit analysis) をする必要がある、と書かれています。

ここでいう意味解析という意味ですが、恐らくは構文解析だけでは瞬時に変換できず、構文解析結果を元にメモ化テーブルなどを作り、作成したメモ化テーブルから総合的に判断する必要がある、という意味だと私は捉えました。
例えば、1つのクラス内に同じ名前のメンバ変数（Javaであればフィールドと呼びます）が複数存在する場合、コンパイルエラーとなりますよね。
本来であれば避けるべきですが、構文解析だけでは判断できません。
判断するためには、構文解析によってフィールドのリストをメモ化テーブルに入れておき、同じメンバ変数をメモ化テーブルから確認しなければなりません。
他にも連想配列を使うとか、いろいろ方法はあると思いますが、どちらにせよ構文解析「だけ」では無理だということです。
これを「意味解析をする必要がある」という意味で使っていると考えます。

さて、上記の論文において「意味解析をする必要がある」という意味が、私が捉えた意味だとするならば、構文解析を元に関係を変換できるのではないか、と考えることができます。
以降は、私が考えたサイキョーの変換ですので、深く考えずに読んでいただければと思います。

関係の種類と対応

関係には、以下の6つがあります。

実現
汎化
コンポジション
集約
関連
依存

上部の関係が最も強く、下がるにつれて関係が弱くなります。

余談ですが、「関係」と言えば上記6つの関係を総称したものとして取り、「関連」と言えば関係の中の1種類のものとして取ります。
よく勘違いしやすいので気を付けましょう。

以降、各関係をどう捉えるか、Javaを例にして考えてみます。

実現

いわゆるインタフェースを実装しているクラスの関係です。
クラス図では、下図のように記述します。

Javaにおいてはinterfaceとimplementの関係を書けばよいです。

interface ふわふわしたもの {
    // ...
}

class 実装したもの implements ふわふわしたもの {
    // ...
}

簡単ですね。

汎化

いわゆる継承クラスの関係です。
クラス図では、下図のように記述します。

クラス図では、抽象クラスとクラスの汎化関係、およびクラスとクラスの汎化関係の間に差異はありません。

Javaにおいてはextendsの関係を書けばよいです。

abstract class 抽象的なもの {
    // ...
}

class 具象的なもの extends 抽象的なもの {
    // ...
}

class より具象的なもの extends 具象的なもの {
    // ...
}

こちらも簡単ですね。

つまり、実現と汎化については、構文解析レベルで判断可能です。
ですから、これ以降について考えてみると面白いですよ。
以降は答えがありませんので、各自考えてみてください。

コンポジション

is-part-of関係と呼ばれる関係です。
クラス図では、下図のように記述します。

ここで、関連端名として「部位A」という文字と、その左端に可視性の「-」 (private) が登場しました。
Javaで記述する際に利用するので、併せて覚えてください。

よく勘違いされる方がいますが、黒塗り菱形は持っている側に付きます。
持たれる側に付くわけではありません、少しややこしいですよね。
また、持たれる側の矢印はオプションです、あってもなくてもあまり意味はありません。

さて、Javaでどう書くかというと、私は「そのクラスだけがインスタンスを持っている」と捉えます。

class 部分的なもの {
    // ...
}

class 全体的なもの {
    private 部分的なもの 部位A = new 部分的なもの();
}

new演算子以降については、あっても無くても問題ありません。
あるいは、コンストラクタ内に記述するというのも手でしょう。

class 部分的なもの {
    // ...
}

class 全体的なもの {
    private 部分的なもの 部位A;

    全体的なもの() {
        部位A = new 部分的なもの();
    }
}

さて、これだけだと「ふーん、そんなものか」だと思われると思いますが、次の集約を見れば違いがはっきりすると思います。

集約

own-a関係と呼ばれる関係です。
クラス図では、下図のように記述します。

さて、コンポジションとの違いは、黒塗り菱形を白抜き菱形に変更しただけです。
この違いですが、is-part-of関係（つまり「全体的なもの」は「部分的なもの」の一部である関係）とown-a関係（つまり「持っているもの」は「持たれているもの」を所有している）という言葉の違いである、と考えました。

すなわち、Javaでどう書くかというと、私は「そのクラス以外にもインスタンスを（参照として）保持している」と捉えます。

class 持たれているもの {
    // ...
}

class 持っているもの {
    private 持たれているもの 所持品X;

    持っているもの() {
        所持品X = new 持たれているもの();
    }
}

違い無しじゃないか！
と思われたあなた、正解です。
上記のクラス図では違いはありません。
しかし、下図でははっきり違いが見えると思います。

class 持たれているもの {
    // ...
}

class 持っているもの {
    private 持たれているもの 所持品X;

    持っているもの(持たれているもの 所持品) {
        所持品X = 所持品;
    }
}

class もう1つの持っているもの {
    private 持たれているもの 所持品Y;

    もう1つの持っているもの(持たれているもの 所持品) {
        所持品X = 所持品;
    }
}

class 管理しているもの {
    private 持っているもの 管理対象X;
    private もう1つの持っているもの 管理対象Y;
    private 持たれているもの 所持品Z = new 持たれているもの();

    管理しているもの() {
        管理対象X = new 持っているもの(所持品Z);
        管理対象Y = new もう1つの持っているもの(所持品Z);
    }
}

「管理しているもの」クラスのコンストラクタによって、「持っているもの」クラスのコンストラクタと「もう1つの持っているもの」クラスのコンストラクタに、所持品Zインスタンスを代入しています。
Javaではインスタンスは基本的に参照渡しのため、「持っているもの」クラスの所持品Xと「もう1つの持っているもの」クラスの所持品Yと「管理しているもの」クラスの所持品Zは全て同じインスタンスを参照していることになります。

これが、私の考える集約です。

依存

とても範囲の広い関係です。
クラス図では、下図のように記述します。

依存と聞くと、上記までの5つの関係全ても依存に書換えられる気がします。
しかし、UML2.5.1の仕様では、依存 (Dependency) は直接関係 (DirectedRelationship) と汎化関係であり、関連 (Association) と汎化 (Extension) とは異なるものとして定義されています。
実現 (InterfaceRealization) は依存と汎化関係であるため、実現については依存に書換えようと思えばできる関係と言えるでしょう。
ちなみに、集約 (Aggregation) とコンポジション (Composition) は、属性 (Property) の種類を表す列挙子 (AggregationKind) として設定できるみたいで、こちらも全く異なります。

UML2.5.1の仕様では確かに書換えられないようですが、実際問題として「依存」という名前だけではよくわかりません。
ではUML2.5.1の仕様を読めば解決するのかというと、そうでもなさそうです。

A Dependency is a Relationship that signifies that a single model Element or a set of model Elements requires other model Elements for their specification or implementation.

意訳: 依存は、とあるクラス（ここでは要素ではなくクラスと読んで差し支えない）の仕様や実装のために、別のクラスを必要としていることを意味する。

つまり、実装に必要であればいいようです。

ということで、Javaでどう書くかというと、私は「依存先のクラスをどこかしらで利用しており、上記5つの関係以外の場合全てを表す」と捉えます。

class 依存されているもの {
    // ...
}

class 依存しているもの {
    // ...

    void hoge(依存されているもの 引数S) {
        // ...
    }
}

例えば上記のように、メソッドの引数の型について、現状クラス図では定義することが難しいです。
ですが、依存を書くことで、どこか関係性があるのだろうことは理解できます。

他にも、キャストのためだけに呼ばれているとか、調べればいろいろ利用法が出てきそうです。
どちらにせよ、クラス図からJavaに変換する際には利用できそうにありません。
Javaからクラス図に変換する際に利用する関係だと思います。

煩雑になりすぎてしまう問題は、容易に想像できます。
しかし、UMLはいわゆるダイアグラムですから、読みづらければ非表示にすればよいだけです。
全てを表示する必要はなく、ダイアグラムの利用目的のために表示内容を変えるのは手だと思います。

おわりに

私がUMLを研究していて、いつか挑戦してみたいことを書いてみました。
もう修士課程は終盤直前ですが、もしこの話に興味があれば、勝手に使ってかまいません。
もちろん、このサイトから引用したなんて野暮なことは書かず、自分で定義し、その理由付けも自分で行ってくださいね。
その論文ができたら、ご一報くださると嬉しいです。

UMLに未来があることを願います。

「uml」の記事 - Crieit

実践UML記述法：シーケンス図で継承元（親クラス）のメッセージ（メソッド）を利用する際の書き方について

実践UML記述法：ユースケース図におけるユースケース間の関係の書き方を疑似コードから逆変換して考える

どのように include と extend を使い分けるのか

なぜ extend の矢印の向きは include と逆なのか

実践UML記述法：スクリプト言語（Python, Perl, PHPなどなど）における可視性をUMLで記述する1考察

実践UML記述法：UMLのクラス図における関係の考察

どのように `include` と `extend` を使い分けるのか

なぜ `extend` の矢印の向きは `include` と逆なのか