「クラス図」の記事 - Crieit

実践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に未来があることを願います。