統一モデリング言語UML

UML(Unified Modeling Language)とは、オブジェクト指向分析・設計のためのモデリング言語として、従来から使われていた数種類の記述法を統合したものです。UMLを用いて分析・設計を行う事で、すっきりとした道筋で考えを進める事が可能になります。

目次

UML誕生の歴史

オブジェクト指向の設計方法論は、1980年代後半から1994年ぐらいにかけて多くの提唱者が現れ、まさに百家争鳴というべき状態でした。代表的なものだけでも次のような方法論がありました。

  • 「オブジェクト指向システム分析」を出版したシュレアー氏とメラー氏の手法
  • Adaの設計で有名なブーチ氏の手法
  • General Electric社でランボー氏が開発したOMT(Object Modeling Technique)
  • ユースケースを使い要求分析が得意なヤコブソン氏のOOSE(Object-Oriented Software Engineering)
  • Hewlett-Packard社がそれぞれの手法のよいところを取り入れた第二世代の方法論と呼ばれているFusion
  • コード氏とヨードン氏によるOOA(Analysis)/OOD(Design)手法

しかし1994年に、Rational Software社において、ブーチ氏とランボー氏により統一方法論の作成が開始されました。すでにランボー氏は自身の方法論であるOMTを用いてNo.1の地位を築いていましたが、ブーチ氏とともに統一への道を歩み始めたのです。1995年には、ヤコブソン氏が彼らに合流し、1996年7月、ついにUMLバージョン0.9がリリースされます。さらに1997年1月には、UMLパートナーがUML1.0を作成しました。UMLパートナーとは、DEC、HP、I-Logix、Intellicorp、IBM、Icon Computing、MCI Systemhouse、Microsoft、Oracle、Rational Software、TI、Unisysの各社です。このとき、UMLには次の4つのゴールが設定されました。

  • オブジェクト指向の概念を使ってシステム(ソフトウェアとは限らない)をモデル化すること。
  • 上流工程の開発成果物や実行可能な成果物との明示的な結び付きを確立すること。
  • 複雑かつミッションクリティカルなシステムでは避けられない、システム規模の問題に対応すること。
  • 人間とコンピュータの両方に利用可能なモデリング言語を開発すること。

(参考文献 「UMLサマリ」日本ラショナルソフトウェア株式会社 より)

UMLの特徴

UMLは、要求分析からシステム分析、設計、テストまで、広範囲のシステム開発フェーズをカバーしています。使用している図(ダイヤグラム)は、おもにランボー氏のOMT、ブーチ法、ヤコブソン氏のOOSEの各手法から持ち込まれました。ターゲットは情報システム、組み込みリアルタイムシステム、分散システム、ビジネスシステムと幅広く考えられています。UMLでは、以下のような図が定義されています。

  • ユースケース図
  • クラス図
  • パッケージ
  • コラボレーション図
  • 状態図
  • インターフェイス
  • シーケンス図

アプリケーション設計とモデリング

アプリケーションの設計とは何でしょうか?ひとことで言ってしまうと、プログラム処理と扱うデータの構造を考えることと言えます。

図1 アプリケーション設計とはプログラム処理とデータ構造を考えること

アプリケーションには、処理ロジックとデータの取り扱いという2つの側面があります。今までのアプリケーション設計では、データ中心設計(DOA)に代表されるように、処理よりもデータ構造が重要視されてきました。そこでは、処理はデータから切り離されてプログラムそのものとなり、変更された場合には容易に作り直せることが多いため、使い捨てになりがちです。

ここで、スケジュール管理のプログラムを例に考えてみます。このプログラムは単純なもので、自分のスケジュールを入力して、それを検索して表示する事ができます。スケジュールは「2000年1月1日に会社に出勤してY2Kバグに対応する」というように表示されます。この他にも、スケジュールの追加、削除の機能を持っています。これは図2のように「処理」と「データ」に分けて整理する事ができます。このようにアプリケーションの設計では、「処理」と「データ」について考えていくことになります。

図2 スケジュール管理プログラムでの処理とデータ

アプリケーション設計法の歴史

ここで、アプリケーションの設計法の歴史を簡単に振り返ってみます。1980年代に、システムエンジニアとして習得することが必須だったのは、SA/SD(Structured Analysis / Structured Design)と呼ばれていた構造化手法でした。この手法では、DFD(データフローダイヤグラム)という処理を表記する図と、ER図(エンティティ-リレーションシップダイヤグラム)というデータの構造を表記する図を用いました。DFDはデマルコ(Tom DeMarco)氏にらによって考案されました。またジェームス・マーチン(James Martin)氏は経営的な視点から情報システムを構築するIE(Information Engineering)を広めていきました。

現在、DFDはプログラムというよりは、経営に必要なビジネスプロセスを整理する、システム設計よりも上流の工程に利用されています。また、ER図はリレーショナルデータベースの設計に広く使用されています。こうした伝統的な手法に対して、最近では、処理とデータを一緒に扱うオブジェクト指向による手法が主流になりつつあります。プログラム言語では、COBOLからJavaやWeb系言語へとシフトしています。ただし、オブジェクト指向で設計する場合にも、リレーショナルデータベースがデータベースの主流である限りは、ER図について最低限のことは理解しておく必要があります。

設計のステップ

システム設計は、「要求仕様」「システム分析」「システム設計」という3つの段階に分類できます。「要求仕様」とは、どのようなシステムにするかという仕様を決める事です。「システム分析」では、システム内の機能を決めます。これを論理設計と呼ぶ場合もあります。ここでは、アプリケーションが利用するシステムを考慮しないで、あくまでも論理的な設計をするのです。これに対して、「システム設計」は実装を考慮した設計と言えます。実装とはWebによるシステムにするとかJava言語を使用するといった事です。システム設計は物理設計とも呼ばれ、Oracleだったらこういうテーブルを1つ追加する、などといった事を決定していきます。

ここで、設計の段階と設計図(ダイヤグラム)の関係を考えてみます。全ての段階で利用する技術がオブジェクト指向であれば、ここでのテーマであるUML(Unified Modeling Language)を素直に採用すれば良いのですが、必ずしもそうとは限りません。例えば、データの管理にOracleなどのリレーショナルデータベースを採用した場合は、この設計にはER図を使った方がフィットします。プログラム言語としてJavaを採用した場合は、構造化手法ではなくオブジェクト指向による設計手法を採用することになります。このように、エンジニアとしては状況に応じた使い分けをマスターする必要があります。UMLなどのオブジェクト指向の手法と、DFDやER図の関係を正しく理解しておきましょう。

構造化手法とオブジェクト指向

オブジェクト指向の設計手法について説明する前に、まず構造化手法について見ていきます。DFDは図3のように処理とデータの流れを表すものです。ここでは、「スケジュールを検索する」というのが処理で、そのプロセスの入力が「日付」、出力が「スケジュール」になります。DFDでは、プロセス(処理)を楕円で囲み、データの流れを矢印で、データの保管場所を上下の線でそれぞれ表します。DFDを用いると、処理を階層化することができます。より細かい処理は図4のように、下位の図(1の下位に1.1、1.2・・・があるというように数字で階層関係を示す)で表現するようにします。

図3 DFDの表記例

図4は「スケジュールを検索する」という処理をDFDによって表しています。初めにスケジュールを検索したい日付を入力します。そのデータを次の「スケジュールを読み込む」プロセスを利用して、「スケジュール」からデータを読み込みます。そして、そのデータを「カレンダー」と合わせて表示します。

図4 DFDによるスケジュール検索の表現

次にER図を見てみましょう。図5のER図では、スケジュール管理のデータ構造を表しています。ここでは、複数の利用者で使用できるように、「利用者」というエンティティを作成しています。エンティティとは、データの保管場所のことです。RDBのテーブルに相当します。そして、そこに保存される内容を属性と呼びます。この例では、「スケジュール」「利用者」「カレンダー」がデータで、そのうちカレンダーの属性が、「日付」「休日」「行事」になります。

図5 ER図の表記例

なぜオブジェクト指向設計手法を採用すべきなのか

このようなER図では、システムが非常に分かりやすく表現されています。それでは、なぜ、これを使い続けるわけにはいかないのでしょうか。その大きな理由は、実装環境がJava、C++、CORBAやEJBなどの分散オブジェクトへパラダイムシフトを起こしているからです。プログラム言語や開発環境が変わってしまうと、設計技術も古いものだけでは対応できません。構造化手法の普及時も、やはり構造化プログラミングの隆盛というものがありました。これは、プログラミングの方法として、スパゲッティなものではなく、goto文などを極力使用せずに構造化されたレコードを書こうという発想でした。そして、この考え方が設計レベルに持ち上がってきました。ここでも構造化というパラダイムシフトが起ったわけです。開発環境が進化してくると、おのずと設計手法も変わらざるを得ません。JavaやWeb技術でシステム構築しようとした途端に、オブジェクト指向設計が要求されてきます。そして、オブジェクト指向でモデリングを行っておけば、設計段階からプログラム開発段階へシームレスに設計情報をつなぐことができます。例えば、DFDはプログラム設計では利用できませんが、オブジェクト指向のクラス図は利用できます。CASEツールを利用すれば、クラス図からコードを生成する事もできます。

また、構造化手法では、システムの変更要求に柔軟に対応できません。データ構造はER図によって一元管理されているから良いのですが、処理の方はプログラムに組み込まれてしまっているので、処理ロジックがあちらこちらに散らばってしまいます。オブジェクト指向では、データと処理が一体化しているので、データ構造を変更したとしても、それに対応できる処理もすぐに変更できます。また、クライアント/サーバシステムの構成がアプリケーションサーバを導入して3階層になったときも、構造化手法によってデータと処理を分けて設計していては、それらを実装したサーバーを的確に分割する事はできません。

このように説明してしまうとオブジェクト指向設計がなんだか凄く難しくて高級な感じがしてきますが、決してそんなことはありません。オブジェクト指向設計では、構造化手法よりも容易にモデリングが行えます。例えば、受発注システムを考えた時に、データモデリングでは、いきなり「注文」というエンティティを持ってきたりします。これは、モデリングの経験がある人ならすぐに思いつきますが、そうでない人にとっては難しいことです。それに比べてオブジェクト指向設計では、具体的なケースであるシナリオを考えてから、手順を追って説明に必要な要素を洗い出していきます。こちらの方が、初心者には容易に入っていけるはずです。