はじめに
以前、スペックアウトにUMLを利用することを検討しました。その中で、クラス図*1が利用できそうと考えました。そこで、クラス図を用いたスペックアウトを実施したのでまとめます。
以下に今回の内容を表にまとめます。
対象 | 正常系の1処理 |
---|---|
作成者 | 新人 |
利用ツール | PlantUML |
効果 | ソースコードの可視化、新人の知識向上 |
何を描いたか
正常系の1処理に利用するクラス及びメソッドを抽出しました。また、抽出したクラス間の関係や派生クラスであれば親クラスを描きました。
誰が描いたか
新人さんに描いてもらいました。そのため、対象モジュールに対する知識は無い状態です。作成中に、都度対象モジュールに対する知識のある人*2が指導したり、相談を受けたりはしていました。また、新人さんはコーディング経験はあるが、他者が書いた大規模なソースコードを読む経験はありませんでした。また、UMLに関する知識もありませんでした。
どのように描いたか
クラス図をはじめUML形式で記述する場合、フリーハンドやVisioのような作図ツールでも描けますが、たくさんのUML作成ツールがあります。新人さんは、PlantUML*3を利用して作成してくれました。オブジェクトを自分で配置する作図ツールではなく、テキストで書くUML作成ツールを選んだところにセンス感じます(描く手段の指示はしていなかったです)。テキストで書くUML作成ツールの場合、自分で配置を考える必要がないこと、図を起こした後でも修正が容易であることのメリットがあると考えます。
スペックアウトで何を得たか
ソースコードの可視化
スペックアウトをしたため、1処理に限りますがソースコードをクラス図にて可視化をすることができました。クラス図にすることで、クラスの構造やクラス間の関係、役割を図で表現することができます。構造や関係を図にすることで、システムの理解が進むこととその図を用いてシステムに関する議論がしやすくなるというメリット*4があります。今回であれば、新人さんへシステム概要をレクチャーする手段にもなりました。
ソースコード自体を参照すればクラス図から得られる情報は獲得できるため、クラス図はそれほど重要なものではない、工数割いてまで作成するものではないと考える方もいます。しかし、人が頭の中でイメージしやすいのは文字列であるソースコードではなく、構造化された図です。また、他者と議論する場合は1つの図を共有した方が、議論しやすいです。そのため、なるべくはクラス図を作るべきだと考えます。
新人の知識向上
今回は新人さんにモジュール理解を目的にクラス図を作成してもらいました。クラス図を作成することで、狙い通りモジュールの理解を深めてもらうことができました。ソースコード上でも判る情報でも、新規メンバが見たら一目では判りにくいものというものも多いです。例えば、下記のクラス図の例からInputとOutputのタスクは同じタスククラスから派生しており、両方とも同じメソッド構造をしていることが一目でわかります。この見た人が一目でわかるようになる、という効果が私は絶大だと考えます。
おわりに
クラス図を用いたスペックアウトの実施例をまとめました。新人さん向けへのモジュール理解の手段として良かったのではないかと思います。また、いままで資料として無かったクラス図が一部ではあるものの作成されたというのも大きな効果だと考えています。今後はこのクラス図をもとにシーケンス図も作成できたらと思います。ちなみに、クラス図とシーケンス図はどちらを先にというよりも一緒のタイミングで作成していくくらいで良いらしいです。
*1:クラス図とは、UMLで定義された図および作図法の一つで、システムを構成するクラスと、クラス間の相互の関係を表現する図。システム全体の静的な構造を明らかにするために作成される。 クラス図とは - IT用語辞典 e-Words
*2:私
*4:これがそもそものUMLの狙いと私は理解しています。