コンピュータ技術者のための無料情報倉庫です

ソフトウェア設計者向け情報

3.UML基礎知識
・・・UML（ユーエムエル）: Unified Modeling Language・・・

　2001年、17人の高名なソフトウェア開発技術者達によって「アジャイル宣言」が出されました。 宣言に合わせて発表されたUMLは、「Unified Modeling Language」の略で、「統一モデリング言語」と訳されます。 ソフトウェア工学でシステムをモデル化するため、10種類以上のダイアグラム（各種の図）の標準化を規定しています。 当初、1994年から1996年にかけて、Rational Software社のCready Booch（ブーチ）、James Rumbaugh（ランボウ）、Ivar Jacobson（ヤコブソン）の3人（スリーアミーゴスと呼ばれています）によって提起されました。 1996年に結成された国際コンソーシアム「UML Partners」において仕様の作成が開始され、1997年には、標準化団体OMG（Object Management Group）に引き継がれました。 現在は、通常「第2版」（2.4.1版が2013年にリリース済み）が使用されています。

3-1.UMLの目的

　UMLでは、それまで使用していたフローチャート（UMLでは「アクティビティ」と呼称がかわります）やクラス図などのツールをダイアグラムと呼びます。 規定する各種ダイアグラムは、以下の3つの用途で使用することを目的としています。

【UMLの目的】

1.言語や機器に依存しない「ソフトウェアのモデリング」用統一規格を提供する。
　UML以前のコンピュータ業界では、「メーカーの規定（機器依存）」や「ソフトウェア規定（言語依存）」は当然でした。 ハードウェアメーカーやソフトウェアッベンダー単位にモデリング言語が作成されてきたのです。 機器や言語を変更しても、共通に使用可能なドキュメント（設計書など）は技術者の夢と希望であったのです。

2.ビジネスプロセスやシステム工学、および、組織体の構造表現用統一規格を提供する。
　システム工学は、当時発達を開始した新しい分野です。 現在では、当たり前に実施されている構造表現は2000年以前は論文ごとに表記方法が異なるのが当然でした。 著者は、構造理論に造詣の深いヤコブソン氏の恣意が実現されたものと考えております。（尊敬に値しますよね）

3.オブジェクト指向設計の普及のための「モデリング言語」を提供する。
　モデリング言語の登場こそが、最大のイベントと考えられます。 UMLの発表以降、ハードウェアやソフトウェアの専門知識を度外視して、コンピュータ技術者は意思の疎通が可能になったのです。

　当初の第1版では、各ダイアグラムの目的やダイヤグラム間の関連性が脆弱でした。 しかし、第2版において大幅に補完され、実際に使用され始めました。 さらに、現在も改良を続けています。
UMLが不完全なまま公開されたのは、アジャイル宣言の発表にあわせて、統一されたモデリング言語を提供するためといわれています。 今日でも、フローチャートは依然として使用されておりますが、UMLは必要不可欠なツールとしての地位を獲得していると思います。 UML以前のコンピュータ業界では、大手のメーカーや開発ベンダーごとに「独自」の記述規格を用いていました。 シシテムの設計者は、開発業者が使用する規格に合わせてダイアグラムを記述する必要があったのです。 著者もマルチベンダー環境下で設計者になりましたので、数社分のドキュメントの内容を統一することが最大の仕事でした。 特に、フローチャートは、実際のプログラム製造にかかわる業者向けに何種類も記述しなければならない状況だったのです。 なんとかして共通化したいというのが、世界中の技術者の希望であったと思います。

3-2.UML誕生の背景

　1990年代後半から、イテレーション（設計からテストまでの一連の手順）のインクリメンタル（回数を2回以上に増加する）な反復型開発（iterative and incremental development ： IIDと略します。）が提唱されました。 また、各理論の技術者間の潤滑なコミュニケーションに対応するため、世界共通の表現基準が要求されてきました。 具体的には、オブジェクト指向開発普及のために、2001年にAgile Allianceから出されたアジャイル宣言（後述）を達成するための「ツール」として、UMLが規格化され、進化を続けています。 また、2002年より、米国の公的機関では、特に大型ソフトウェア開発において調達にはIIDが推奨され、数年後には、義務化となっています。
1980年代に推奨されていた、失敗率（使用されない、もしくは、手直しの必要性がある）の高い、ウォーターフォール型での大型開発は世界的に減少しています。

著者注1：補足
　ウォーターフォール型の開発手法はもともと、数〜数十人月程度のIID小規模開発手法として考案されたものです。
現在、国際的に、IIDはシステム開発における当然の開発手法となっております。
このIIDを記述する共通言語としてUMLが誕生ししたのです。 共通のモデル表現言語として、開発技術者にとってはUMLの知識は「常識」の範疇となってきているのです。
著者の主観ですが、クラス図の記述においては、UMLの記述ルールがかなり一般的になってきたようです。 UMLのルール策定には、統一すべき対象の種類が多く、大変な作業量が必要だったようです。 成果として、ランボウ氏の推奨し採用されたクラス図の四角形での表記は、「書きやすい」のが最大の利点でしょうか。 当時、業界のリーダであったブーチ氏は雲形を使用していましたが、使用の普及を目指したUMLの選定作業には敬意を表する価値があると思います。

著者注2：【問題点】
　UMLは、システム開発者から問題点をよく指摘されております。 (1).業務系と組込系のダイアグラムの区別が曖昧である。 (2).オブジェクト指向言語以外の開発では、技術者間のコミュニケーションが難しい。（インピーダンス不整合とも呼ばれます。）
などが、問題点（今後の課題）としてよく取り上げられます。
　インピーダンス不整合に関する、著者の主観です。
UMLのなかでも、フローチャートの代替となるアクティビティの普及が遅れているように感じています。 フローチャート発祥のIBMのホームページでは、アクティビティに統一されている模様ですが、 現実のソフトウェア開発現場では、IBM型フローチャートの利用率はかなり高いと感じられます。 アクティビティほどの汎用性が現場で要請されていないのか、高齢者が慣れているIBM方式が使用されているだけなのか、 今後の推移が注目されるところです。

3-3.UMLの構成

　UMLは、システムモデル・プログラム構造とビジネスモデル構造表現を統一的に標記することも目的としています。
また、用途に応じて、二つのグループに分類されることがあります。
(1).構造図
プログラム製造やデータベース構築のために視覚的に「もの（データ）」と「こと（作業や通信）」について表現する。
(2).振る舞い図
「もの（データ）」と「こと（作業や通信）」の間で取り交わされる「メッセージの流れ」や「作業の順序」について表現する。

UMLの各ダイアグラムに関するご紹介は、断章として別項に掲載いたします。 また、設計業務でよく使用するダイヤグラムについては、用途を限定する形で掲載の予定です。 また、UMLはシステム設計に限らず多くの分野で使用可能ですので、是非、ご参照ください。

【断章に掲載のダイアグラム】
UML2.1のダイヤグラム（一部、2.4版の記述ルールになっています。）
1. 構造図
　・クラス図：予定-設計者向けの解説を別途掲載
　・コンポーネント図
　・コンポジット図
　・配置図
　・オブジェクト図
　・パッケージ図

2. 振る舞い図
　・アクティビティ図：予定-設計者向けの解説を別途掲載
　・コミュニケーション図
　・相互作用概観図
　・シーケンス図
　・状態マシン図
　・タイミング図
　・ユースケース図：予定-設計者向けの解説を別途掲載

UMLの概要については、本題からは外れますが、断章としてご紹介します。

UML基礎知識-以上

お問い合わせについて

▲ページトップに戻る