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

公開日:2019-05-01
最終更新:2019-05-01

TL; DR

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

実践UML記述法とは

UMLが使われない理由の1つに、書き方がわからないという問題が挙げられます。
バージョン2.0以降、わけのわからない機能がどんどん増えて、複雑化してしまったのは事実です。

でも、UMLというのは可読性の向上にすごく役立つものだと考えています。
どのクラスがどのクラスと関係しているのか、どのライブラリを消したらどこに影響が出るのかをぱっと見で理解できるのは、図ならではだと思います。

しかし使われない。

そこで、実践的なUMLの書き方講座みたいなことを勝手にしてみようと思います。
ここに書いているのはあくまで1例ですので、参考程度にしておくと吉かもしれません。

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

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

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

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

問題点

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

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

PlantUML文
@startuml  
class User {  
    printText()  
}  

class Information {  
    text  
    message  
}  

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

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

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に反映してはどうでしょうか?

PlantUML文
@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を利用しやすくなるのではないでしょうか。

記事が少しでもいいなと思ったらクラップを送ってみよう!
41
+1
いろいろ落ちている

よく一緒に読まれている記事

0件のコメント

ブログ開設 or ログイン してコメントを送ってみよう
目次をみる

技術ブログをはじめよう

Qrunch(クランチ)は、ITエンジニアリングに携わる全ての人のための技術ブログプラットフォームです。

技術ブログを開設する

Qrunchでアウトプットをはじめよう

Qrunch(クランチ)は、ITエンジニアリングに携わる全ての人のための技術ブログプラットフォームです。

Markdownで書ける

ログ機能でアウトプットを加速

デザインのカスタマイズが可能

技術ブログ開設

ここから先はアカウント(ブログ)開設が必要です

英数字4文字以上
.qrunch.io
英数字6文字以上
ログインする