Papyrusを使ってみる

職業紹介会社から紹介されたちょっと条件の良い求人。

ただ、入社試験でUMLの読み書きが出るとあったので、PapyrusというUMLエディターをインストールしてみました。

UMLはシステムの構造や振る舞いを図で表現するもので、現在の版では13種類の図が定義されています。

とはいえソフトウエア開発で通常使うのは4種類か5種類くらいなのでそれだけ覚えれば良いのではと甘く考えています。

さて、ソフトウエア開発では昔から図で仕様や設計を表現しようという活動がありました。

古くはフローチャートや状態遷移図、HIPOチャートなどがありますが、状態遷移図は使われることがあってもそれ以外の図はあまり使われているのをみたことがありません。

一つは図を描くのに手間がかかることが原因ではないかと思います。

仕様や設計を検討している段階では当然図を描いては消しのプロセスが繰り返し発生するのでとてもやってられない、場合によっては図を描き直すのが面倒になって検討をやめてしまうといったことが起きます。

また、作成した設計や仕様を記録として残すために図示する場合であっても、図形要素の配置が適当でないと図が混乱してしまうため、結局描き直しが発生する場合があります。

専用のソフトウエア等を使用すると要素間の連結を維持したまま図形要素を移動できるなど図形の描き直しを容易にすることはできますが、大体にしてホームポジションから手を動かしたくない人にはマウスを操作するだけでも苦痛だったりします。

それ以上に問題なのが図形は面積が必要なことです。

図形要素には要素名などの項目や説明などの文言などが含まれるため、書かれた内容が読めるようにある程度の大きさが必要になります。

このためちょっと複雑な図になるとA4やA3の用紙に入りきらなくなり、全体像が把握しにくいということになります。

また、画面上で図を編集する際にはさらに悲惨で30型くらいの大型高精細モニターでもなければ全体像が把握できないことになります。

図の複雑化を避けるため階層化した図を使用するわけですが、それはそれで全体像の把握が難しくなるという問題もあります。

もちろん階層化は設計において有効であることは間違いありませんが、階層化のための階層化になるのはちょっと問題ではないかと思うところもあります。

そして一番の問題はどこまで詳細化するかその見極めが難しい点にあります。

抽象度が高いとコーディングの技量に品質が左右されることになりますし、逆に詳細しすぎるとコーディングとの二度手間になってしまう点があります。

で、結局は設計でデザインパターンを指定するなど図だけでは完結しないことになります。

また、図を描いただけでコーディングが完了する実行可能なUMLといったものもあります。

同期入社の元同僚が実行可能なUMLの伝導者になっていたので、ちょっと話を聞いたのですが下準備が大変そうであまり興味を持てずそのままにしています。そいつはだいぶ前に転職して最近は何をやっているのかわからないけど、まだ実行可能なUMLの伝導をやっているのかなあ。

と、そんなところでPapyrusに戻りますが、クラス図をちょっと描いてみたところ、デフォルト設定があまり好みじゃなかったこともあって、なんだか使いにくいという印象しか残りませんでした。

それ以前にUMLがよくわかっていないというか、15年ほど前に入門コースを受けたまま一度も実務で使ったことがないので、UMLの勉強から始めないといけないし、たとえ入社試験に合格しても実務で困るだろうなというのがほんとのところです。