UML入門

公開日：2020.08.20　最終更新日:2020.08.20

UMLとは

UMLとはUnifiedModelingLanguageの略で、オブジェクト指向分析、設計においてシステムをモデル化する際の記法を規定した言語です。何のためにUMLで図を書くのか、レベルによって三つあります。

レベル1: プログラムを書く前に，図で自分の考えを整理する．
レベル2: チーム開発において，図でコミュニケーションする．
レベル3: ユーザや顧客と仕様を検討する．

それぞれのレベルにおける使い方について簡単に説明します。

レベル１

プログラミングを始めてしばらくすると、動くプログラムを下記ことがシステム開発であると勘違いする人がいます。完全に間違いとは言いませんが、仮に一人で書いていたとしても、プログラムの規模が3000行を超えたあたりで壁に当たるはずです。行き当たりばったりでコーディングしていると、見通しが立たずつぎはぎだらけのプログラムになってしまいます。

これをなくすために、自分の考えを整理することが必要になります。動くプログラムを作ることに集中しすぎてしまい、視野が小さくなってしまいがちなときに、プログラムをUMLで図解することが効果的です。プログラムの構造や動きを図で捉えることができるため、見通し良く全体像を使い見ながらコーディングすることが可能です。

レベル２

プログラムの規模が30000行を超えると一人で開発するのが困難になり、チームでの開発になり、分担を決めたり、システム全体の構造を決めたりする必要があります。職業としてシステム開発する、いわゆるプロの現場ではこれが通常の姿でしょう。

その際に設計を検討するための図としてUMLを使うことができ、設計の討議の際などに、ホワイトボードなどを使って絵を描く際にもUMLが役立ちます。全員がUMLの語彙を持っていることで簡潔かつビジュアル的に設計の方針を示すことができます。あるいは、UMLno図をきれいに効率よく描くことができる市販のCASEツールがいくつかあるので、これらを使っても良いはずです。

レベル３

とても大切なことですが、システム開発とは「プログラムを正しく書く」ことではなく「正しいプログラムを書く」ことです。プログラムが正しいかどうかを決めるのはそのシステムのユーザユアそのシステムに対価を支払う人、すなわち顧客です。なので、システム開発では開発者がユーザや顧客と対話として、どういったシステムを作るのかを合意する必要があり、この場面でもUMLが活躍します。ユーザや顧客は一般的にシステムを利用する機能に興味があり、プログラムの内部構造には興味がありません。UMLでは、システムがどう言う機能を持つのかをも表現することができ、それをもとに話し合い、システムの使用を詳細に決定することができます。

以上のようにUMLを理解することで様々なレベルにおいて、コミュニケーションが円滑に進み、多くの人がUMLを理解することで、いっそうシステム開発の見通しが良くなるでしょう！

UMLはビジュアルなモデリング言語

UMLは、オブジェクト指向分析・設計においてモデリングを行う言語です。言語とは、意図を表現し、伝達し、記録するものであると広義に捉えると、日本語や英語が自然言語であり、JavaやC++がプログラミング言語である、と言うのと同じ意味で、UMLは『モデリング言語』と言うことができます。さらに、JavaやC++がデキスト言語であるのに対して、UMLはビジュアル言語と言うことができます。

UMLは、扱おうとしている問題を明らかにしたり（分析）、その解決方法を組み立てる（設計）際に、問題を図としてモデリングする過程を助けます。描かれたモデルを複数人で共有してコミュニケーションしたり、自分一人でも考えをまとめ、アイデアを展開する作業を助けます。これらの側面から、UMLの意図を表現し、伝え記録する役割、すなわち「言語」としての役割が明らかになると思います、

UMLに規定されている図を、ダイアグラムと呼びます。その種類を以下に示します。

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

分析、設計プロセスとUML

UMLでは記法（ノーテーション）とその意味（セマンティクス）が定義されていますが、その図をどの開発フェーズでどのように使用するか？と言う開発プロセスには意図的に触れられていません。大まかな使用法の例を紹介します。

分析フェーズ

ここではユースケース図を中心に要求を分析・定義します。ここのユースケースに対して具体的な処理の手順をかき、そこから問題領域の概念の抽出が行われます。それらをクラス図を使いモデリングしたものを「概念モデル」とし、アクティビティ図、状態図、シーケンス図、コラボレーション図なども補助的に使用されます。この概念モデルではシステムをユーザや顧客の言葉でモデリングすることが重要で、UMLはそのコミュニケーションを助ける言語と言う役割です。

設計フェーズ

要求されているモデルをもとに、決定されたアーキテクチャの中に論理的な設計モデルを構築します。この作業には、クラス図を中心に、アクティビティ図状態図、シーケンス図、コラボレーション図等が使用されます。扱う問題領域によって必要な図は異なりますが、このように作成された設計モデルが、設計フェーズの成果物となります。ここでUMLが設計者間のコミュニケーションのための言語です。

一方、システムの論理的な側面とは別に「アーキテクチャ」を決めておく音が重要となります。アーキテクチャは使用するハードウェアや分散環境、データベース、通信、GUI、言語やライブラリなどの開発基盤、さらには過去の資産や組織体制などの環境的政治的要因で決定されます。全く新規の開発では、アーキテクチャの決定は設計フェーズで行われることが多いですが、現実的には分析と並行して行われることもありますし、すでに決定されたアーキテクチャに従って設計を進めることも多くあります。

UMLでは、物理的なソフトウェアやハードウェアの構成はそれぞれコンポーネント図や配置図で記述することができます。

実装フェーズ

設計モデルを元に実際のコーディング(プログラミング)が行われ，コードが生成されます．ここでは UML 図を見ながら，Java/C++/C# と言ったプログラミング言語を用いてプログラミングすることになります．しかし，設計モデルを CASE ツール等を使って書いている場合，そのモデルからコードのスケルトン (雛型)を生成することができることが多いようです．

繰り返し型プロセス

分析フェーズ、設計フェーズ、実装フェーズという順序でプロセスを紹介しましたが、実際の開発ではこのようなウォーターフォール型ではなかなかうまくいかないことが多いようで、問題が発生しても、逆戻りしにくく、手遅れになるリスクが付き纏います。ウォーターフォール型に対して、イテラティブ（反復型）という分析から実装までのフェーズを繰り返して行う手法が主流です。素早く反復を行うことで早期にリスクを軽減しようという考え方です。例としてRUP（RationalUnifiedProcess）などが有名です。