UMLとは何ですか？

UMLとは何ですか？

統合モデル化言語（UML）は、オブジェクト管理グループによって提案された、システム開発のためのオープンスタンダードな図式表記法です。この表記法は、ブーチ、ルンバウ、ヤコブソンの研究に基づいています。UMLは、ドキュメントやソフトウェアの表現および設計を目的としたモデル化言語であり、特にオブジェクト指向設計に有用です。この言語は、ソフトウェア開発ライフサイクル全体にわたり、一般的な初期設計から非常に詳細な設計まで幅広く使用できます。UMLの定義は以下の通りです：

  • 統合モデル化言語（UML）は、ソフトウェアシステムのモデル化および開発のための図式言語です。UML図は、要件分析、設計、実装といったソフトウェア開発のすべての段階を議論する際に開発者が使用する共通の成果物となります。ここでの目的は、システムを構築する前にそのソフトウェアシステムをモデル化することです。
  • 引用：「統合モデル化言語（UML）は、単一のメタモデルを基盤とする図式表記のファミリーであり、特にオブジェクト指向（OO）スタイルで構築されたソフトウェアシステムの記述および設計を支援します。」[マーティン・ファウラー – UML Distilled] p.1。

なぜUMLなのか？

ソフトウェアアーキテクチャが規模と複雑さを増すにつれて、ソフトウェアモデルの必要性も高まります。UMLはソフトウェア業界で主流のモデル化言語です。現在、世界最大のソフトウェアコンソーシアムであるオブジェクト管理グループによって、事実上の標準として採用されています。10人以上の開発者が参加するソフトウェアプロジェクトで、何らかの形でアーキテクチャを指定するためにUMLを使用していないものはほとんど見つかりません。

以下は、ソフトウェア開発プロセスにおけるUMLの使用に関する追加の事実です：

  • ソフトウェアはますます複雑化しています：非常に古いバージョンのWindows XPでも4000万行以上のコードがあります。
  • 単一のプログラマーでは、この量のコードを全体として管理することはできません。
  • コードは、それを書いた開発者以外の開発者には容易に理解できません。
  • 複雑なシステムに対してより簡潔な表現が必要です：モデル化は複雑さに対処する手段です。

モデルとは何か？

  • モデルとは、実物の抽象化であり、詳細を省略したものである。
  • 「システムを記述するすべての要素、およびそれらの相互間の接続をまとめたものが、あなたのモデルを構成する。」（ルスとハミルトン 12）。

ソフトウェアをコードする前に、UMLを使って開発中のシステムのモデルを作成する際、それらは問題を簡略化した形で表現します。問題解決のための構造を提供します。現在の問題に対してどのように進めるかを理解するのに役立ちます。また、複数の解決策を試すことも可能になります。モデルはシステムの実際の開発の前に作成されるため、さまざまな可能性、問題点、選択肢などを理解できます。これにより開発コストの削減が実現します。試行錯誤に時間を費やすことがなくなるため、製品の完成までの時間が短縮されます。また、モデルは問題の複雑さを管理する助けとなり、開発計画やマシン、プログラマー、テスト担当者などのリソースの割り当てを容易に行うことができます。

UMLとは何かではないか？

  • UMLは表記法ではなく、言語である。
  • UMLは誰の所有物でもありません。誰でも使用できるオープンなものです。独自のものではない。
  • UMLはプロセスでも、方法でもない。
  • UMLはオブジェクト指向技術および反復的なソフトウェア開発ライフサイクルの使用を推奨する。
  • UMLは難しいものではない。規模は大きいが、すべてを完全に知る必要はない。また、その中のすべての小さな要素を用いるか理解する必要もない。
  • UMLは時間のかかるものではない。適切に使用すれば、開発コストを削減できる。同時に、理解やコミュニケーションのしやすさ、生産性の向上、品質の向上といった利点がある。
  • UMLは制限されていない。特定の分野に必要な新しい語彙（概念、語や用語）、プロパティ（語に関する追加情報）、意味（言語ルール）を柔軟に受け入れられる。

UMLの目的

  • 視覚的なモデル化言語であり、視覚的なプログラミング言語ではない。ただし、一部のモデル化ツールにはコード生成機能があり、一部はコードからモデルを逆引きできる。
  • ソフトウェア開発プロセスを支援できる図を作成することを目的としているが、UML自体はソフトウェア開発プロセスや開発手法ではない。したがって、UMLはプロセスに依存しない。
  • ソフトウェアのブループリントを作成するための標準言語。
  • コミュニケーションツールです。
  • 要件、アーキテクチャ、テスト、プロジェクト計画など文書化するための言語です。
  • ソフトウェアシステムを対象としていますが、他のシステムもモデル化できます。
  • オブジェクト指向開発プロセスを支援することを目的としています。
  • システムの静的構造と動的動作の両方を捉えることができます。
  • UML図はステークホルダーが要件を理解し、議論し、合意するのを助けます。
  • UML図は複雑なプロセスを理解しやすいレベルに抽象化するのを助けます。
  • UML図は問題解決を促進する助けになります。

モデル化言語は何を提供するのか？

  • モデル要素：概念と意味
  • 表記法：モデル要素の視覚的表現
  • ガイドライン：表記法における要素の使用に関するヒントと提案

概要歴史

1980年代後半、モデル化を始めた頃、さまざまな異なるアプローチがありました。それぞれのアプローチには独自の表記法がありました。問題は、異なる人が異なる表記法を使っていた場合、どこかの段階で誰かが翻訳作業を行う必要があったことです。多くの場合、ある記号が一つの表記法ではある意味を表していたのに対し、別の表記法ではまったく異なる意味を表していました。1991年、人々がそれぞれ書籍を発表し始めました。グレイディ・ブーチは初版を発表し、イヴァル・ヤコブソンも彼の書籍を発表し、ジム・ルンバウグはOMTアプローチを発表しました。各書籍にはそれぞれ長所と短所がありました。OMTは分析において非常に強みを持っていた一方で、設計では弱さがありました。ブーチのアプローチは設計において強みがあり、分析では弱さがありました。また、イヴァル・ヤコブソンのObjectoryはユーザーエクスペリエンスに非常に優れており、当時ブーチやOMTはそれらを十分に考慮していませんでした。1994年にブーチとヤコブソンが両者のアプローチを統合し、1995年にルンバウグが参加しました。1997年にOMGからUML 1.1が発表され、他の人々（例：ヨーデン）からの意見も反映されています。UML v2.xが現在の最新バージョンです。

リリース日

  • 1995年 – UML 0.8
  • 1996年 – UML 0.9 – Three Amigos
  • 1997年 – OMGが引き継ぐ。
  • 1997年 – OMG UML 1.1
  • 1998年 – OMG UML 1.2
  • 1999年 – OMG UML 1.3
  • 2001年 – OMG UML 1.4
  • 2003年 – OMG UML 1.5
  • 2003年 – OMG UML 2.0 – 取り入れられた
  • 2005年 – OMG UML 2.0 – 最終版
  • 2006年 – OMG UML 2.1
  • UML2.1.2（11/04/07）－2008年5月27日現在のバージョン

「三つのアメゴ」によるメソッド統合の動機

  • 個々のメソッドが互いに独立して進化する事実
  • オブジェクト指向設計市場の安定性をもたらすための意味と表記法の統合
  • 統合が以前の個々のメソッドを改善すると予想された

UMLパートナーズ

  • ラシオン・ソフトウェア・コーポレーション
  • IBM
  • ヒューレット・パッカード
  • I-Logix
  • ICON Computing
  • Intellicorp
  • MCI Systemhouse
  • Microsoft
  • ObjecTime
  • Oracle
  • Platinum Technology
  • Taskon
  • テキサス・インスツルメンツ／スティングラ・ソフトウェア
  • Unisys

統合前の異なるメソッドにおけるUML表記の入力

UMLは、ブーチ、OMT、Objectoryの表記法の統合だけでなく、他の多数のメソドロジストたちの優れたアイデアを統合したものであり、下図に示す通りである。これらのオブジェクト指向メソッドで用いられる表記法を統合することで、統一モデリング言語（UML）は、広範なユーザー経験に基づいたオブジェクト指向分析・設計分野における事実上の標準の基盤を提供する。

表記法の役割

表記法はあらゆるモデルにおいて重要な役割を果たす。「それはプロセスを統合する接着剤である。」表記法には3つの役割がある：

  • コードそのものからは明らかでない、または推論できない意思決定を伝えるための言語として機能する。
  • すべての重要な戦略的・戦術的決定を捉えられるほど十分に豊かな意味を提供する。
  • 人間が推論できるほど具体的で、ツールが操作できる形を提供する。

統一モデリング言語（UML）は、分析から設計へと発展する非常に堅牢な表記法を提供する。表記法の一部（たとえば、クラス、関連、集約、継承）は分析段階で導入される。他の要素（たとえば、包含の実装指標やプロパティ）は設計段階で導入される。

UMLの利点

UMLは多様な分野に適用可能であるアプリケーション分野（例：銀行、金融、インターネット、航空宇宙、医療など）主要なオブジェクトおよびコンポーネントと併用可能ソフトウェア開発手法およびさまざまな実装プラットフォーム。

  • 何が得られるかを正確に把握できます
  • 開発コストを低く抑えることができます
  • ソフトウェアは期待通りに動作します。予期せぬ事態が少なくなります
  • 不十分なコードが提供される前に適切な決定がなされます。全体的なコストが削減されます
  • メモリおよびプロセッサ効率の高いシステムを開発できます
  • システムの保守コストが低くなります。再学習の必要が少なくなります
  • 新しい開発者と協力しやすくなります。
  • プログラマや外部請負業者とのコミュニケーションがより効率的になります。

UML 4 + 1 ビュー

UMLは開発中のシステムの以下の4つのビューで構成される（図3参照）[Eriksson & Penker, 1998; Kruchten, 2000]：

  • ユースケースビュー：外部のアクターが認識するシステムの機能を示す。ユースケース図および時折アクティビティ図で記述される。
  • 論理ビュー：この機能がシステム内部でどのように設計されているか、システムの静的構造および動的動作の観点から示す。クラス図およびオブジェクト図（静的モデル）および状態遷移図、シーケンス図、協調図、アクティビティ図（動的モデル）で記述される
  • コンポーネントビュー：ソフトウェアコンポーネントの構成を示す。コンポーネント図で記述される。
  • デプロイメントビュー：コンピュータやデバイス内の実行時処理ノードの物理的構成（デプロイメント）およびそれら上に存在するコンポーネント、プロセス、オブジェクトを示す。デプロイメント図で記述される。
  • プロセスビュー：実行時のシステムの並行的な側面（タスク、スレッド、プロセス、相互作用など）を示し、これらのスレッド間の通信および同期に関する問題に対処する。動的図（状態遷移図、シーケンス図、協調図、アクティビティ図）および実装図（コンポーネント図およびデプロイメント図）で記述される。

4+1 architectural view model

各システムは以下のもので構成される静的および動的モデル。静的モデルはクラス図およびオブジェクト図に描かれる。しかし、システムの動作に関する情報はほとんど明らかにされない。システムの動作は、シナリオ（すなわちユースケース図）、シーケンス図、状態遷移図、アクティビティ図を用いて図式化される。これらがシステムの動的モデルを構成する。システムの動作は、システムに属するすべてのオブジェクトの総合的な動作である。

上記の5つのビューを図3の反復的ライフサイクル段階にマッピングしたい場合、次のように述べることができる。

  • オブジェクト指向分析（OOA）は、ユーザーの視点からユーザーの要件のモデルを構築するもので、Use caseビューに対応する。
  • オブジェクト指向設計（OOD）は、分析に詳細および設計意思決定（開発者の視点から）を追加し、論理ビューに対応する。
  • 最後に、実装またはオブジェクト指向プログラミング（OOP）は、プロセス、デプロイメントおよびコンポーネントビューに対応する。

UML 2 ダイアグラム

UMLには、さまざまな視点からモデルを記述するために使用できる複数の種類の図がある。図は大きく2つのカテゴリーに分けられ、さらにサブカテゴリーに分類される。

  • 構造図 – 構造図システムの静的側面を表す。これらの静的側面は、図の主な構造を形成し、したがって安定した部分を表す。これらの静的側面は、クラス、インターフェース、オブジェクト、コンポーネント、ノードによって表される。
  • 振る舞い図 – 任意のシステムには静的および動的という2つの側面がある。したがって、モデルが両方の側面を完全にカバーしている場合、完全と見なされる。
    振る舞い図は基本的にシステムの動的側面を捉える。動的側面は、システムの変化・移動する部分としてさらに説明できる。

UML Diagram Types

構造図

構造図システムの静的側面を表す。これらの静的側面は、図の主な構造を形成し、したがって安定した部分を表す。
これらの静的側面は、クラス、インターフェース、オブジェクト、コンポーネント、ノードによって表される。4つの構造図は次の通りである。
  • クラス図 – システムのクラスおよびインターフェースの静的構造とそれらの関係または関連（継承、集約、関連を含む）およびクラスの操作と属性を示す図。表示モードは：関連、継承、依存。これはUMLで非常に一般的な図である。
  • オブジェクト図 – システムの特定の時間または状況（スナップショット）における静的構造を示す図で、システム内の関係を示す。
  • コンポーネント図 – システム内のコンポーネントの構成および依存関係を記述する図。
  • 複合構造図 – 通信リンクを介して協働する相互接続されたインスタンスの実行時インスタンスを調査する図。
  • パッケージ図 – システムが論理的なグループに分割される方法およびこれらのグループ間の依存関係が存在する可能性を示す図。
  • デプロイメント図 – 分配可能な物理単位（配布可能なソフトウェアコンポーネント、アプリケーション、サーバー、アプリケーション、ハードウェアなど）が分散システムアーキテクチャを構成する方法を記述する図。

振る舞い図

  • ユースケース図 – ユースケース（ソフトウェア機能／サービス）とアクター（ユーザー：人間またはシステムの両方）の役割を示す図。この図はユーザーの視点から作成されている。
  • アクティビティ図 – システムの動的性質を、活動から活動への制御の流れをモデル化することで示す図。システム（例：オブジェクト／クラス）が内部イベントにどのように対応するかを図示する。（注：外部イベントは状態図で記述される。）ビジネスプロセスモデリングにおいて、この図はユースケースやビジネスルールの論理をモデル化するために使用できる。
  • 状態図 （別名：状態チャート図、状態機械図） – システム（例：オブジェクト／クラス）が外部イベントにどのように対応するかを示す図。（注：内部イベントはアクティビティ図で記述される。）

相互作用タイプ図 – モデルの組織的部品間の相互作用。

  • シーケンス図 – オブジェクト間の相互作用およびメッセージの流れ、およびメッセージの相対的な時系列順序を示す図。
  • コミュニケーション図（別名 UML1のコラボレーション図） – システムが共同してタスクを実行する方法およびシステム間で存在しなければならない関連を示す図。コラボレーション図は、シーケンス図をもとに、それをクラス図との相互作用として記述することによって得られる。要するに、この図はオブジェクト間のメッセージの流れおよびクラス間の基本的な関連（関係）を示す。
  • タイミング図 – ある期間にわたって1つ以上のオブジェクトの振る舞いを調査する図。
  • 相互作用概要図 – 相互作用図（シーケンス図、コミュニケーション図、タイミング図、相互作用概要図）間の相互作用およびフロー制御を示す図。

UMLプロファイル

UMLプロファイルは正確には図ではないが、UMLへの拡張およびサブセットを記述するためのプロファイルである。サブセットはオブジェクト制約言語（OCL）を使って記述される。拡張は、任意のモデル要素に装飾できるタグとして定義されるスタereotypeによって作成される。たとえば、クラスに「永続的」というタグを付けることで、システムの実行時間の寿命を超えてインスタンスが保存されるクラスを識別できる。形式的には――これはイデオロギー的に誤りであるが――これらのメカニズムを使って記述されたかどうかに関わらず、UMLへの拡張およびサブセットの任意の集合をプロファイルと呼ぶことができる。正式には、UML 2では、ルールを記述するOCLおよびスタereotype定義がパッケージに収集されている。

ソフトウェア開発における関連図

OOADメソドロジーの違いとUML標準の進化の間で、図の名前やその機能は時間とともに変化する可能性がある。以下は、UML1やUML2に含まれるかどうかは不明だが、OOADメソドロジーで使用できる図や作業成果物の例である。

  • システムコンテキスト図
  • エンティティ関係図（クラス図に類似）：概念的、論理的、物理的ERD
  • ロバストネス分析

結論

UMLの起源と定義を検討することで、それが何であるか、そして私たちに何を提供できるかについて簡潔な理解を得た。また、次回の開発プロジェクトでUMLを活用することで得られる利点を検討し、UML 2に用意されているアーキテクチャ的視点、モデル、図の種類についても概略的に検討した。UMLはプロセスではないが、ソフトウェア集約型システムの開発に用いるオープンな標準的な視覚的モデリング表記法である。成功したプロジェクトに必要な要素は、表記法、プロセス、ツールという3つの側面を備える必要がある。

 

 

表記法のみ – あなたは表記法（例：UML）を学ぶことができるが、それをどう使うかが分からなければ（プロセス）、おそらく失敗するでしょう。

プロセスのみ – あなたは素晴らしいものを手に入れる可能性がありますプロセス、しかしプロセスを伝えることができなければ（表記法おそらく失敗するでしょう。そして最後に

ツールサポートなし – あなたの作業の成果物を効果的に文書化できない場合（ツールおそらく多くの時間を無駄にし、最終的に失敗するでしょう。

 

自動化UMLツール

Visual Paradigmは自動化ツールであり、以下の機能によりソフトウェアプロジェクトでの成功を保証します：

  1. 表記法の暗記を最小限に抑えるための簡単な構文編集
  2. 人気のある最も簡単なアジャイルスクラムソフトウェア開発プロセスおよびツールセットをサポート
  3. プロジェクトや製品レポート、アーティファクトをリアルタイムでスムーズ化する自動化

UMLリソース

  1. 14種類のUML図タイプの包括的ガイド – Cybermedian
    • このガイドは、Visual Paradigm Community Editionでサポートされている14種類のUML図タイプについて概要を紹介します。UML図がソフトウェア集約型システムの可視化にどのように役立つかを説明し、各図タイプが提供する機能を記述しています。また、Visual Paradigmがさまざまなモデリングニーズに対応する多様なUML図をサポートしている点も強調しています。.
  2. 最高のUML無料ツール（オンラインおよびデスクトップ用フリーソフト）を使ってUMLモデリングを学ぶ – Cybermedian
    • この記事では、UMLモデリングにVisual Paradigmを使用する利点について説明し、最新のUML 2.x標準への対応と多様な図タイプのサポートを強調しています。また、人気のある開発プラットフォームとの統合機能や、学術界および産業界での広範な導入についても言及しています。.
  3. 例による学習：UML状態機械図 – Cybermedian
    • このリソースはUML状態機械図に焦点を当て、これらの図を作成するための理想的なツールとしてVisual Paradigmを推奨しています。状態機械図が動的システム動作をどのようにモデル化できるかを詳しく解説し、Visual Paradigmが開発ツールやプラットフォームとの統合機能を強調しています。.
  4. UML図：包括的なガイド – Cybermedian
    • この包括的なガイドでは、ソフトウェア開発におけるUML図の重要性と、Visual Paradigmがさまざまな種類のUML図をサポートする方法を説明しています。構造図、振る舞い図、インタラクション図をカバーし、Visual Paradigmを用いて効果的なUMLモデルを作成する方法についての洞察を提供しています.
  5. 無料オンラインUMLツール – Cybermedian
    • この記事では、Visual Paradigm Online（VP Online）Express Editionを紹介しています。これは、UML図を作成するための無料オンライン描画ツールです。使いやすさ、制限のなさ、さまざまなウェブブラウザとの互換性を強調しており、個人的および非営利目的のUML図作成にアクセスしやすい選択肢となっています.
  6. UMLタイミング図の理解：包括的なガイド – Cybermedian
    • このガイドでは、UMLタイミング図とそのリアルタイムシステムにおける重要性を説明しています。Visual Paradigmを用いてこれらの図を作成する方法について説明し、システム内のタイミングおよび期間制約の視覚的表現に焦点を当てています.
  7. UML 2.5図の包括的なガイド – Cybermedian
    • このガイドでは、UML 2.5図の概要を提供し、包括的なモデル作成におけるVisual Paradigmの優れた選択肢としての特徴を強調しています。ツールの多様性、使いやすいインターフェース、強力なコード生成機能について説明しており、さまざまな業界の専門家に適しています.
  8. UMLクラス図の包括的なガイド – Cybermedian
    • このガイドは、UMLクラス図とVisual Paradigmによるその作成支援に焦点を当てています。ツールの学術界での広範な導入、システムおよびデータベース設計・分析における利用について説明しています。また、UMLモデル作成の迅速な開始に役立つ例やテンプレートの利用可能性についても言及しています.
  9. Visual Paradigmを用いたUMLパッケージ図のチュートリアル – Cybermedian
    • このチュートリアルでは、Visual Paradigmを用いてUMLパッケージ図を作成する手順を紹介しています。大規模なシステムを整理する上でパッケージ図の重要性を説明し、Visual Paradigmを用いた作成手順を段階的にガイドしています.
  10. アジャイルソフトウェア開発におけるビジュアルモデリングの包括的なガイド – Cybermedian
    • このガイドでは、UMLツールがアジャイルソフトウェア開発における役割について説明し、Visual Paradigmを人気のある選択肢として強調しています。Visual Paradigmが使いやすいインターフェースと、検証、コード生成、リバースエンジニアリングなどの機能を提供し、モデリングプロセスを向上させることを説明しています.

 

 

 

コメントを残す