UML概観

UML

UMLを学ぶモチベーション

私の職種をざっくりとくくるとソフトウェアエンジニアになるのですが，出来ることと言えばライブラリを使い回しつつPythonで画像処理が出来るくらいのものです。
これではソフトウェアエンジニアとして胸を張れないので，ここではその基礎であるUMLについて学んでいきたいと思います。まずは， http://objectclub.jp/technicaldoc/uml/umlintro1 を参考にさせて頂き，UMLの全体像を理解していきたいと思います。

UMLとは何か？

Unified Modeling Languageの略で，オブジェクト指向分析，設計においてシステムをグラフィカルにモデル化する際の記法を規定した言語です。"規定"されたという部分が重要ポイントでしょうか。
実際にソフトを書いていると，自分以外の人が書いたコードが読みにくい！と思うことってありますよね。(逆も然り)それを少しでも減らすためには何か統一されたルールに沿った記法である必要があります。それがUMLです。

なぜUMLを使うか？

参考記事の中でも個人的に響くポイントです。 記事中ではシステムが大きくなるにつれて，コードの量が増えるにつれてUMLの必要性が高まることを示唆しています。 それは規模が大きくなるほどコミュニケーションの必要性が高まり，その時に共通言語，かつビジュアル的に記述されている設計書があるとそのハードルが下がる，というメリットがあるからでしょう。
弊社ではUMLでの設計プロセスに疑問を呈する方もいるのですが，まだプロダクトがその規模感に到達していないために出てくる声なのかもしれません。遅かれ早かれ直面する課題なんだろうな。

UMLダイアグラムの種類

UMLにはシステム開発の分析，設計フェイズで必要となる各種ダイアグラムが用意されています。

ダイアグラム 役割 開発フェイズ
ユースケース図 システムの境界，使用機能を定義 分析
アクティビティ図 システムの動作の流れを表現 分析，設計
状態遷移図 オブジェクトの取りうる状態，遷移を表現 分析，設計
クラス図 概念や静的なクラス間相互関係を表現 分析，設計
パッケージ図 各モデル要素の階層的グルーピング 分析，設計
相互作用図
シーケンス図 オブジェクト間のメッセージ交換の時系列表現 分析，設計
コラボレーション図 オブジェクトの集団の協調動作の表現 分析，設計
オブジェクト図 実行時のオブジェクト状態のスナップショット 分析，設計
コンポーネント図 システムを構成する実行可能モジュールや
ソースコードの物理的構造を表現 		設計
配置図 システムを構成するマシンや装置の繋がりを表現 設計

各フェーズでやること

分析フェーズ

ユースケース図を中心に要求分析，要求定義を行います．その過程で見えてきた問題領域の概念を抽出し，クラス図を使ってモデリングをします．補助的に(特にフローチャートを作るような目的で)アクティビティ図，状態遷移図，シーケンス図，コラボレーション図が使用されます．ここで出てくるUMLは，ユーザーや顧客とのコミュニケーションツールとしての位置付けが大きいため，モデリングする際の言葉もユーザーに馴染みの良い言葉を用いるようにします．

設計フェーズ

このフェーズでのUMLは設計者間のコミュニケーションのために用いられます．そのため，扱われるUMLもより開発寄りのものが増えてきます．よく使われるものとして，クラス図，アクティビティ図，状態遷移図，シーケンス図，コラボレーション図があるようです．実装の設計や処理フローに関連したUMLたちですよね．これらのUMLが設計モデルとなり，このフェーズでのアウトプットとなります．
また，システムの論理的な側面とは別にアーキテクチャを決めておくことも必要です．ここでのアーキテクチャはシステム全体の構造を意味し，ハードウェア，データベースなどなど周辺要因から決定されるようです．これは開発も佳境まで進んだ段階でリソースが足りない！といったことがないように，事前に制約は決めておきましょうということですね．また，既に実績のあるアーキテクチャを持っている場合は，それをベースに考えるということもあるでしょう．(その方が楽ですもんね)

実装フェーズ

設計モデルを元に，実際のコーディングを行います．設計フェーズが理想的に進んでいれば，このフェーズでの仕事は要求を実装に落とし込む"作業"になるはずです．

まとめ

UMLの目的，種類，フェーズ毎の作業内容について概観しました．今回の内容はあくまで概観ですので，これでUMLを使ったモデリングができるようになった！とはもちろんいきません．具体的なUMLの作成は次回以降のブログで書きたいと思います．
UMLをベースとしたシステム開発は業務の円滑化に貢献してくれそうだと感じました．１人でシステム開発をするなら良いですが(そんなケースはほぼ皆無でしょう)，複数人で開発する場合は設計書があった方がそれぞれの役割を明確化でき作業がし易いですよね．
これまでの自分の仕事を振り返ると，いきなり実装フェーズに飛んでしまうことが多かったなぁ…そういう仕事の仕方だとコミュニケーションも発生し辛い，I/Fが合わないなどのトラブル発生にも繋がってしまうように感じます．
今後はソフトウェアエンジニアとして恥ずかしくない仕事の仕方もできるようにしていかねば．