UMLとは何か？統一モデリング言語について説明

UMLは統一モデリング言語。これは、システムおよびソフトウェア開発者がソフトウェアシステムのアーティファクトを指定、可視化、構築、文書化するのを支援するために開発された、統合された図のセットからなる標準化されたモデリング言語であり、ビジネスモデリングやその他の非ソフトウェアシステムにも使用される。

UMLは、大規模で複雑なシステムのモデリングにおいて成功を収めた最良の工学的実践の集まりを表している。UMLはオブジェクト指向ソフトウェアの開発およびソフトウェア開発プロセスにおいて重要な役割を果たしている。UMLは主にソフトウェアプロジェクトの設計を表現するために図式的な表記を使用している。UMLを使用することで、プロジェクトチームはコミュニケーションを図り、潜在的な設計を検討し、ソフトウェアのアーキテクチャ設計を検証することができる。この記事では、UMLとは何かについて詳しく説明する。

UMLの起源

UMLの目的は、すべてのオブジェクト指向手法で使用可能な標準的な表記を提供し、過去の表記法の最も優れた要素を選定して統合することである。UMLは広範な用途を想定して設計されている。そのため、分散システム、分析、システム設計、展開など、幅広いシステムや活動に対応する構文を提供している。

UMLは、3つの主要なオブジェクト指向モデリング表記の統合から生まれた。

  1. オブジェクトモデリング技法（OMT） [ジェームズ・ルンバウグ 1991年] – 分析およびデータ集約型情報システムに最も適している。
  2. Booch [グレイディ・ブーチ 1994年] – 設計および実装において非常に強力。グレイディ・ブーチはAda言語と深く関与しており、その言語のオブジェクト指向開発に大きな貢献をした。ブーチ法は強力であったが、その表記はあまり人気がなかった（モデルに多くの雲型の図形が含まれており、あまり整然としていなかった）。
  3. OOSE（オブジェクト指向ソフトウェア工学 [イヴァル・ヤコブソン 1992年]） – 「ユースケース」と呼ばれるモデルで特徴づけられる。ユースケースは、システム全体の挙動を理解するための強力な技術であり（オブジェクト指向では伝統的に弱かった分野）。

1994年、OMTの創始者であるジム・ルンバウグがジェネラルエレクトリックを退職し、ラショナルソフトウェアのグレイディ・ブーチに合流したことで、ソフトウェア界は衝撃を受けた。この協働は、両者のアイデアを統合した統一された手法（仮称「統一手法」）を構築することを目的としていた。

1995年までに、OOSEの創始者であるイヴァル・ヤコブソンもラショナルに参加し、彼のアイデア（特に「ユースケース」の概念）が新しい統一手法に取り入れられた。この統一手法は現在、「統一モデリング言語1」と呼ばれている。ルンバウグ、ブーチ、ヤコブソンのチームは愛称で「三銃士」として知られていた。

UMLは当時、他のオブジェクト指向表記にも影響を受けた。

  • メラーとシュラー [1998年]
  • コードとユーダン [1995年]
  • ウィルフス・ブロック [1990年]
  • マーティンとオデル [1992年]

UMLは、当時の他の主要な手法には存在しなかった新しい概念も含んでおり、拡張メカニズムや制約言語などが含まれる。

UMLの歴史

  1. 1996年、オブジェクト管理グループ（OMG）が最初の提案要請（RFP）を発行し、これらの組織が共同でRFPへの対応を行うための触媒となった。
  2. ラショナルは、強力なUML 1.0定義に資源を割り当てることを望む複数の組織と共同でUMLパートナーズ連合を結成した。UML 1.0定義に最も貢献したのは以下の通りである：
    • デジタル・エQUIPMENT・コーポレーション
    • ヒューレット・パッカード
    • I-Logix
    • インテリコープ
    • IBM
    • ICON コンピューティング
    • MCI システムハウス
    • Microsoft
    • Oracle
    • ラシオン ソフトウェア
    • テキサス インスツルメンツ
    • ユニシス
  3. この協働により、明確に定義され、表現力が高く、強力で汎用的なモデル化言語であるUML 1.0が生み出された。これは1997年1月にOMGに初期のRFP応答として提出された。
  4. 1997年1月、IBM、ObjecTime、Platinum Technology、Ptech、Taskon、Reich Technologies、Softeamもそれぞれ別々のRFP応答をOMGに提出した。これらの企業はUMLパートナーズに参加し、自らのアイデアを貢献し、パートナーズが共同で改訂版のUML 1.1を生成した。UML 1.1はUML 1.0の意味の明確性を高め、新規パートナーからの貢献を統合することに焦点を当てた。これはOMGに検討のために提出され、1997年秋に採用された。バージョンは1.1から1.5へと進化し、その後UML 2.0から2.5へと進展した（現在のバージョンはUML 2.5である）。

UML History

なぜUMLなのか？

多くの企業においてソフトウェアの戦略的価値が高まる中、業界はソフトウェア生産を自動化し、品質を向上させながらコストと市場投入までの時間を削減する技術を求めるようになった。このような技術にはコンポーネント技術、ビジュアルプログラミング、パターン、フレームワークが含まれる。企業はまた、範囲と規模が拡大する中で複雑さを管理する方法を模索している。特に、物理的分散、並行性、レプリケーション、セキュリティ、負荷分散、障害耐性といった繰り返し発生するアーキテクチャ上の問題に対処する必要性を認識している。さらに、世界中のウェブの発展は一部の課題を簡素化した一方で、これらのアーキテクチャ上の問題を悪化させている。ユニファイドモデリング言語（UML）は、こうしたニーズに応えるために設計された。

  1. ユーザーに、意味のあるモデルを開発および交換できる、すぐに使える表現力豊かな視覚的モデリング言語を提供する。
  2. コア概念を拡張するための拡張性と特殊化メカニズムを提供する。
  3. 特定のプログラミング言語や開発プロセスに依存しない。
  4. モデリング言語を理解するための形式的基盤を提供する。
  5. オブジェクト指向ツール市場の成長を促進する。
  6. コラボレーション、フレームワーク、パターン、コンポーネントなどの高レベルな開発概念をサポートする。
  7. ベストプラクティスを統合する。

UML – 概要

UMLの理論に深入りする前に、UMLの主要な概念の一部を簡単に紹介しましょう。

UMLについて最初に注目すべき点は、慣れなければならないさまざまな図（モデル）があるということである。その理由は、システムはさまざまな視点から見ることができるからである。ソフトウェア開発には多くの利害関係者が関与する。

例えば：

  • アナリスト
  • デザイナー
  • コーダー
  • テスト担当者
  • QA
  • 顧客
  • 技術文書作成者

これらのすべての人々はシステムの異なる側面に関心を持ち、それぞれの側面には異なる詳細度が必要です。たとえば、コーダーはシステムの設計を理解し、その設計を低レベルのコードに翻訳できる必要があります。一方、技術文書作成者はシステム全体の動作に注目し、製品の機能を理解する必要があります。UMLは、すべてのステークホルダーが少なくとも1つのUML図から利益を得られるほど表現力のある言語を提供しようとしています。

UML 2 ダイアグラム構造に示されている13の図の概要を以下に示します：

構造図システムおよびその部品の抽象化や実装の異なるレベルにおける静的構造とそれらの関係を示します。構造図には7種類があります：

振る舞い図システム内のオブジェクトの動的振る舞いを示し、これは時間の経過に伴う一連の変化として記述できます。時間振る舞い図には7種類あります：

UML Diagram Types

クラス図とは何ですか？

クラス図は、ほぼすべてのオブジェクト指向手法で使用される中心的なモデリング技術です。この図は、システム内のオブジェクトの種類とそれらの間にあるさまざまな静的関係を記述します。

関係

重要な主な関係は3つあります：

  1. 関連 – タイプのインスタンス間の関係を示します（例：個人が会社で勤務している、会社が複数の事務所を持っている）。
  2. 継承 – オブジェクト指向（OO）で使用されるER図に最も明確な追加要素。オブジェクト指向設計における継承と直接対応している。
  3. 集約 – オブジェクト指向設計におけるオブジェクト構成の一形態。

クラス図の例

Class Diagram

クラス図の詳細については、記事を読むこと。クラス図とは何ですか？

コンポーネント図とは何ですか？

統一モデリング言語（UML）において、コンポーネント図は、コンポーネントがどのように接続されてより大きなコンポーネントやソフトウェアシステムを形成するかを示す。ソフトウェアコンポーネントのアーキテクチャとその依存関係を可視化する。これらのソフトウェアコンポーネントには実行時コンポーネント、実行可能コンポーネント、およびソースコードコンポーネントが含まれる。

コンポーネント図の例

Component Diagram

コンポーネント図の詳細については、記事を読むこと。コンポーネント図とは何ですか？

配置図とは何ですか？

配置図は、オブジェクト指向ソフトウェアシステムの物理的側面をモデル化するのに役立つ。構造図であり、ソフトウェアアーティファクトが配置先に配置（配布）される形でシステムのアーキテクチャを示す。アーティファクトは開発プロセスによって生成される物理世界の具体的な要素を表す。静的ビューで実行時構成をモデル化し、アプリケーション内のアーティファクトの配置を可視化する。ほとんどの場合、ハードウェア構成とそれら上に存在するソフトウェアコンポーネントのモデル化を含む。

配置図の例

Deployment Diagram

配置図の詳細については、記事を読むこと。配置図とは何ですか？

オブジェクト図とは何ですか？

オブジェクト図は、オブジェクトやデータ値を含むインスタンスのグラフである。静的オブジェクト図はクラス図のインスタンスであり、ある時点におけるシステムの詳細な状態のスナップショットを示す。違いは、クラス図がクラスとその関係から構成される抽象モデルを表すのに対し、オブジェクト図は特定の時点におけるインスタンスを表すという点で、本質的に具体的である。オブジェクト図の使用は限定的であり、主にデータ構造の例を示すために用いられる。

クラス図とオブジェクト図の比較 – 例

一部の人々は、UMLクラス図とUMLオブジェクト図の違いを理解しにくいと感じるかもしれない。なぜなら、両方とも属性とそれらの間のリンクを持つ名前付き「長方形ブロック」を含んでおり、その結果、2つのUML図が似た外観を持つからである。また、UMLツールではクラス図とオブジェクト図の記号が同じ図エディタ（クラス図）に配置されるため、両者が同じものだと誤解する人もいる。

しかし実際には、クラス図とオブジェクト図はコードベースの2つの異なる側面を表している。この記事では、これらの2つのUML図について、それぞれが何であるか、どのように異なるか、そしていつ使うべきかについてのアイデアを提供する。

クラス図とオブジェクト図の関係

プログラミングを行う際には「クラス」を作成する。たとえば、オンラインバンキングシステムでは、「User（ユーザー）」、「Account（口座）」、「Transaction（取引）」などといったクラスを作成することができる。教室管理システムでは、「Teacher（教員）」、「Student（生徒）」、「Assignment（課題）」などといったクラスを作成することができる。各クラスには、そのクラスの特徴や振る舞いを表す属性と操作がある。クラス図は、これらのクラス、その属性、操作、およびそれらの相互関係を可視化できるUML図である。

UMLオブジェクト図は、クラスのオブジェクトインスタンス（UMLクラス図に描かれた）が特定の状態で「どのように見えるか」を示す。言い換えれば、UMLオブジェクト図は、UMLクラス図内のクラスが特定の状態でどのように使用されるかのインスタンスと見なすことができる。

これらの定義が気に入らない場合、以下のUML図の例を見てください。数秒でその違いが理解できると信じています。

クラス図の例

以下のクラス図の例は、2つのクラス「User（ユーザー）」と「Attachment（添付ファイル）」を表している。ユーザーは複数の添付ファイルをアップロードできるため、2つのクラスは、添付ファイル側に多重度0…*の関連で結ばれている。

Class Diagram

オブジェクト図の例

以下のオブジェクト図の例は、ピーター（つまりユーザー）が2つの添付ファイルをアップロードしようとする際、UserクラスとAttachmentクラスのオブジェクトインスタンスが「どのように見えるか」を示している。したがって、アップロードされる2つの添付ファイルに対して、それぞれ2つのインスタンス仕様がある。

Object Diagram

オブジェクト図の詳細については、記事を読むこと。オブジェクト図とは何ですか？

パッケージ図とは何ですか？

パッケージ図は、パッケージとパッケージ間の依存関係を示すUMLの構造図です。パッケージ図を使用すると、システムのさまざまな視点を示すことができます。たとえば、マルチレイヤー（別名マルチティア）アプリケーションとしてのモデル、マルチレイヤー・アプリケーション・モデルなどです。

パッケージ図の例

Package Diagram

パッケージ図の詳細については、記事を読んでくださいパッケージ図とは何ですか？

コンポジット構造図とは何ですか？

コンポジット構造図は、UML 2.0に追加された新しいアーティファクトの一つです。コンポジット構造図はクラス図に似ており、主にシステムを微視的な視点からモデル化するために使用されるコンポーネント図の一種ですが、全体のクラスではなく、単一の部品の内部構造を示します。これは静的構造図であり、クラスの内部構造およびその構造が可能にする協調動作を示します。

この図には、部品同士が相互にやり取りするためのポート、クラスのインスタンスが外部世界とやり取りするためのポート、および部品やポート間の接続子を含めることができます。コンポジット構造は、実行時に目的を達成するために協調する相互接続された要素の集合です。各要素は協調動作において明確な役割を持っています。

コンポジット構造図の例

Composite Structure Diagram

コンポジット構造図の詳細については、記事を読んでくださいコンポジット構造図とは何ですか？

プロファイル図とは何ですか？

プロファイル図を使用すると、ドメインおよびプラットフォーム固有のスタereotypeを作成し、それらの関係を定義できます。スタereotypeは、スタereotypeの形状を描画することで作成でき、リソース中心のインターフェースを通じて構成や一般化によって関連付けることができます。また、スタereotypeのタグ付き値を定義および可視化することもできます。

プロファイル図の例

Profile Diagram

プロファイル図の詳細については、記事を読んでくださいUMLにおけるプロファイル図とは何ですか？

ユースケース図とは何ですか？

ユースケースモデルは、ユースケースの観点からシステムの機能要件を記述します。これは、システムの意図された機能（ユースケース）とその環境（アクター）のモデルです。ユースケースを使用すると、システムが実行すべきことと、システムがその要件をどのように満たすかを関連付けることができます。

ユースケースモデルを、レストランにあるメニューのように考えてください。メニューを見ることで、利用可能な料理、個々の料理、およびその価格を把握できます。また、そのレストランが提供する料理のジャンル（イタリアン、メキシコ料理、中華料理など）もわかります。メニューを見て、そのレストランでどのような食事体験が待っているか全体的に把握できます。実際、メニューはレストランの振る舞いを「模倣」しているのです。

強力な計画ツールであるため、ユースケースモデルは開発サイクルのすべての段階で、すべてのチームメンバーが使用しています。

ユースケース図の例

Use Case Diagram

ユースケース図の詳細については、記事を読んでくださいユースケース図とは何ですか？

アクティビティ図とは何ですか？

アクティビティ図は、選択、反復、並行性をサポートする段階的な活動やアクションのワークフローを図式化したものです。対象システムの制御フローを記述し、複雑なビジネスルールや操作の検証、ユースケースやビジネスプロセスの記述に用いられます。統一モデリング言語（UML）では、アクティビティ図は計算プロセスおよび組織プロセス（すなわちワークフロー）をモデル化することを目的としています。

アクティビティ図の例

Activity Diagram

アクティビティ図の詳細については、記事を読んでくださいアクティビティ図とは何ですか？

ステートマシン図とは何ですか？

状態図は、デイビッド・ハーレルのステートチャート概念に基づいて、UMLでシステムの動作を記述するために使用される図の一種です。状態図は、許可された状態と遷移、およびそれらの遷移に影響を与えるイベントを示します。これにより、オブジェクトのライフサイクル全体を可視化でき、状態ベースのシステムの理解を深めるのに役立ちます。

ステートマシン図の例

State Machine Diagram

ステートマシン図の詳細については、記事を読んでくださいステートマシン図とは何ですか？

シーケンス図とは何ですか？

シーケンス図は、時間の順序に従ってオブジェクトの協調動作をモデル化します。特定のユースケースシナリオにおけるオブジェクト同士の相互作用を示します。高度な視覚的モデリング機能により、数回のクリックで複雑なシーケンス図を作成できます。さらに、一部のモデリングツール（たとえばVisual Paradigm）は、ユースケース記述で定義したイベントの流れからシーケンス図を生成できます。

シーケンス図の例

Sequence Diagram

シーケンス図の詳細については、記事を読んでくださいシーケンス図とは何ですか？

コミュニケーション図とは何ですか？

シーケンス図と同様に、コミュニケーション図もユースケースの動的動作をモデル化するために使用されます。シーケンス図と比較して、コミュニケーション図は時間の順序よりもオブジェクト間の協調動作を強調しています。意味的に同等であるため、一部のモデリングツール（たとえばVisual Paradigm）では、一方から他方を生成できます。

コミュニケーション図の例

Communication Diagram

コミュニケーション図の詳細については、記事を読んでくださいコミュニケーション図とは何ですか？

相互作用概要図とは何ですか？

相互作用概要図は、相互作用の制御フローの概要に焦点を当てます。ノードが相互作用または相互作用の発生である活動図の一種です。相互作用概要図では、メッセージやライフラインが非表示になっている相互作用を記述します。実際の図にリンクでき、相互作用概要図内の図間で高いナビゲーション性を実現できます。

相互作用概要図の例

Interaction Overview Diagram

相互作用概要図の詳細については、記事を読んでください相互作用概要図とは何ですか？

タイミング図とは何ですか？

タイミング図は、特定の時間期間におけるオブジェクトの動作を示します。タイミング図はシーケンス図の特殊な形です。タイミング図とシーケンス図の違いは、軸が逆になっている点にあります。つまり、時間は左から右に増加し、ライフラインは垂直に配置された別々の区画に表示されます。

タイミング図の例

Timing Diagram

タイミング図の詳細については、記事を読んでくださいタイミング図とは何ですか？

UMLを学ぶ。UMLを描く。

Visual Paradigm Community Editionを入手 – UMLをより速く、より効果的に学べる無料のUMLツールです。Visual Paradigm Community EditionはすべてのUML図タイプをサポートしています。その受賞歴のあるUMLモデラーは直感的で使いやすく、直感的に操作できます。

無料ダウンロード

UML用語集と用語

  • 抽象クラス – インスタンス化されないクラス。このクラスのインスタンスは存在しない。
  • アクター – システムに関与するイベントを開始するオブジェクトまたは人物。
  • アクティビティ：アクティビティ図におけるステップまたはアクション。システムまたはアクターが実行する操作を表す。
  • アクティビティ図：プロセス内のステップや意思決定、並行処理（たとえばアルゴリズムやビジネスプロセスなど）を示す拡張されたフローチャート。
  • 集約 – 他のクラスの一部である。図では、包含するクラスの隣に空のダイヤモンドで示される。
  • アーティファクト – 設計プロセスの段階の出力を記述する文書。記述は図形的、文章的、またはその組み合わせである可能性がある。
  • 関連 – モデル内の2つの要素間の接続。これはコード内のメンバ変数を表すこともでき、人員記録とその記録が表す人物との関係、2つの職種クラス間の関係、またはその類似関係を表すことができる。デフォルトでは、関連の両方の要素は互いを認識しており、同等である。関連はナビゲーション可能な関連であることもあり、これはソース側がターゲット側を認識しているが、逆は成り立たないことを意味する。
  • 関連クラス：2つの他のクラス間の関連を表し、それに情報を追加するクラス。
  • 属性 – オブジェクトの特徴であり、他のオブジェクトを参照するか、オブジェクトの状態に関する情報を保持するために使用できる。
  • 基本クラス：サブクラスが一般化関係を通じて継承する属性と操作を定義するクラス。
  • 分岐：アクティビティ図における意思決定ポイント。複数の遷移が分岐から発生し、それぞれにガード条件がある。制御が分岐に到達すると、正確に1つのガード条件が真でなければならず、制御は対応する遷移に従う。
  • クラス：類似したオブジェクトのカテゴリであり、すべて同じ属性と操作で記述され、すべて代入可能である。
  • クラス図 – システム内のクラスとそれらの間の関係を示す。
  • 分類子：属性と操作を持つUML要素。具体的には、アクター、クラス、インターフェース。
  • 協働：通信図における2つのオブジェクト間の関係であり、オブジェクト間でメッセージが往復可能であることを示す。
  • 通信図 – 操作がどのように達成されるかを示し、オブジェクトの役割に重点を置いた図。
  • コンポーネント: システム内のデプロイ可能なコード単位。
  • コンポーネント図: さまざまなコンポーネントとインターフェース間の関係を示す図。
  • コンセプト – ドメインモデルに含めるべき名詞または抽象的概念。
  • 構築段階 – Rational統一プロセスの第3段階で、構築されたシステム内で複数の機能的イテレーションが作成される。ここが作業の大部分が行われる段階である。
  • 依存関係: ある分類子が別の分類子の属性や操作を知っていることを示す関係だが、その第二の分類子のインスタンスとは直接接続されていない。
  • デプロイメント図: さまざまなプロセッサ間の関係を示す図。
  • ドメイン – システムが関与する議論の範囲の一部。
  • 詳細化段階 – Rational統一プロセスの第2段階で、構築段階におけるイテレーションを含む追加のプロジェクト計画が可能になる。
  • 要素: モデルに表示される任意の項目。
  • カプセル化 – オブジェクト内のデータはプライベートである。
  • 一般化 – あるクラスが別のクラス（スーパークラス）のサブクラスであることを示す。ハローの矢印はスーパークラスを指す。
  • イベント: 状態図において、システムが行動を起こすか状態を変更する原因となる信号、イベント、または入力を表す。
  • 最終状態: 状態図またはアクティビティ図において、図が完了する点を表す。
  • フォーク: アクティビティ図における、複数の並行した制御スレッドが開始する点。
  • 一般化: サブクラスがベースクラスの属性や操作を継承し、さらに追加する継承関係。
  • GoF – ガング・オブ・フォーのデザインパターン。
  • 高い結合度 – クラスが複雑になりすぎず、関係のない機能を実行しないことを保証するGRASP評価パターン。
  • 低い結合度 – 1つのクラスが別のクラスに依存するか、接続されている程度を測るGRASP評価パターン。
  • インセプションフェーズ – Rational Unified Processの最初のフェーズで、初期の概念化とプロジェクトの開始を扱う。
  • 継承 – サブクラスは親（スーパークラス）の属性や特徴を継承する。これらの属性はサブクラスでオーバーライドできる。
  • 初期状態：状態図またはアクティビティ図において、図の開始点を表す。
  • インスタンス – オブジェクトはクラスのインスタンスである。クラスはオブジェクトを作成するためのテンプレートのようなものである。クラスのインスタンスは任意の数作成できる。
  • インターフェース：属性と操作を定義し、振る舞いの契約を形成する分類子。提供者クラスやコンポーネントはインターフェースを実現する（すなわち、その属性と操作を実装する）ことを選択できる。クライアントクラスやコンポーネントはインターフェースに依存できるため、実際の提供者クラスの詳細を知らずに提供者を使用できる。
  • イテレーション – プロジェクトに小さな機能を追加するミニプロジェクトの一部。分析、設計、コーディングの開発サイクルを含む。
  • ジョイン：アクティビティ図における、複数の並行した制御スレッドが同期して再結合する点。
  • メンバー：分類子内の属性または操作。
  • マージ：アクティビティ図における、異なる制御パスが合流する点。
  • メッセージ – 1つのオブジェクトから別のオブジェクトへのリクエストで、受信オブジェクトに何らかの処理を実行するよう依頼するもの。これは、受信オブジェクト内のメソッド呼び出しにほぼ等しい。
  • メソッド – オブジェクト内の関数または手続き。
  • モデル – 中心となるUMLアーティファクト。さまざまな要素が階層構造に配置され、要素間の関係を持つ。
  • 複数性 – 領域モデルにおける外部概念ボックスの隣に表示され、オブジェクト同士の数量的関係を示す。
  • ナビゲーション：関係のどちらの端がもう一方の端を認識しているかを示す。関係は双方向ナビゲーション（両端が互いを認識）または単方向ナビゲーション（一方の端がもう一方を認識するが、逆は成立しない）を持つことができる。
  • 表記法 – 分析および設計手法を作成するためのルールを伴う図式化された文書。
  • 注記：図をより詳しく説明するために図に追加されたテキストコメント。
  • オブジェクト – 活動図において、活動から情報を受信するか、活動に情報を提供するオブジェクト。協調図またはシーケンス図において、図で記述されたシナリオに参加するオブジェクト。一般的には、特定の分類子（アクター、クラス、インターフェース）のインスタンスまたは例。
  • パッケージ – 論理的にまとまりのあるUML要素のグループ。
  • パッケージ図：すべての要素がパッケージおよび依存関係であるクラス図。
  • パターン – オブジェクト間の相互作用における責任割り当ての問題に対する解決策。よく発生し、よく知られた問題に対する名前付きの解決策。
  • パラメータ：操作のパラメータ。
  • 多態性 – 同じメッセージ、異なるメソッド。パターンとしても使用される。
  • プライベート：属性または操作に適用される可視性レベルで、含まれる分類子内のコードのみがメンバーにアクセスできることを示す。
  • プロセッサ：配置図において、コードをデプロイできるコンピュータまたはその他のプログラマブルデバイスを表す。
  • プロテクト：属性または操作に適用される可視性レベルで、含まれる分類子またはそのサブクラス内のコードのみがメンバーにアクセスできることを示す。
  • パブリック：属性または操作に適用される可視性レベルで、任意のコードがメンバーにアクセスできることを示す。
  • 読み取り方向の矢印 – 領域モデルにおける関係の方向を示す。
  • 実現: コンポーネントまたはクラスが特定のインターフェースを提供することを示す。
  • 役割 – 領域モデルで使用され、エンティティが果たす役割に関するオプションの説明である。
  • シーケンス図: オブジェクトの時間的な存在と、そのオブジェクト間で時間とともに送信されるメッセージを示す図で、ある振る舞いを実行する。状態図 – オブジェクトのすべての可能な状態を示す図。
  • 状態: 状態図において、これはシステムまたはサブシステムの状態や条件を表す。ある時点での動作内容とそのデータ値を示す。
  • 状態図: システムまたはサブシステムの状態、状態間の遷移、および遷移を引き起こすイベントを示す図。
  • 静的: 属性に適用される修飾子で、その属性のコピーが分類子のすべてのインスタンス間で共有されることを示す。操作に適用される修飾子で、その操作が独立しており、特定の分類子のインスタンスに対して作用しないことを示す。
  • ステレオタイプ: モデル要素に適用される修飾子で、通常UMLでは表現できないものを示す。本質的に、ステレオタイプにより独自の「UML方言」を定義できる。
  • サブクラス: 上位クラスによって定義された属性および操作を一般化関係を通じて継承するクラス。
  • スイムレーン: アクティビティ図内の要素で、特定のアクティビティを担当するシステムまたはドメインの部分を示す。スイムレーン内のすべてのアクティビティは、スイムレーンによって表されるオブジェクト、コンポーネント、またはアクターの責任である。
  • タイムボクシング – 各イテレーションには、特定の目標を持つ固定された時間制限がある。
  • 遷移: アクティビティ図において、これは1つのアクティビティ、分岐、マージ、フォーク、ジョインから別のものへの制御の流れを表す。状態図においては、1つの状態から別の状態への変化を表す。
  • 遷移フェーズ – Rational統一プロセスの最終フェーズで、ユーザーが新しいシステムの使い方を学び、システムがユーザーに提供される。
  • UML – 統一モデリング言語は、テキストおよび図的文書を通じてオブジェクト間のより緊密な関係を可能にすることで、ソフトウェアプロジェクトの分析と設計を向上させる。
  • ユースケース: ユースケース図において、これはアクターからのあるリクエストに応じてシステムが実行するアクションを表す。
  • ユースケース図: アクターとユースケースの間の関係を示す図。
  • 可視性: 属性または操作の修飾子で、どのコードがメンバにアクセスできるかを示す。可視性のレベルには、パブリック、プロテクト、プライベートがある。
  • ワークフロー – 特定の結果を生み出す活動のセット。

人気のUML書籍

UMLを学ぶために読めるベストセラーUML書籍の一部を以下に紹介します：

  1. UML Distilled: 標準オブジェクトモデリング言語の簡潔なガイド
  2. UML 2と統一プロセス: 実践的なオブジェクト指向分析と設計
  3. UML 2.0を学ぶ
  4. UMLによるWebアプリケーションの構築
  5. 統一モデリング言語リファレンスマニュアル
  6. UML™ 2.0スタイルの要素
  7. JavaプログラマーのためのUML
  8. Schaum’s Outline of UML
  9. 統一モデリング言語ユーザーガイド
  10. UML 2資格ガイド: 基礎および中級試験
  11. UMLにおけるオブジェクト指向設計の基礎
  12. UMLによるユースケース駆動型オブジェクトモデリング: 注釈付きECサイト例
  13. UMLによる柔軟なオブジェクト指向システムの設計
  14. UMLによるユースケース駆動型オブジェクトモデリング
  15. UML 2.0を用いたシステム分析と設計: オブジェクト指向アプローチ
  16. UML 2.0の要点
  17. 応用を伴うオブジェクト指向分析と設計
  18. UMLを解説
  19. デザインパターン: 再利用可能なオブジェクト指向ソフトウェアの要素
  20. オブジェクトの入門書: UML 2.0を用いたアジャイルモデル駆動開発

関連リンク

  1. 視覚的モデリング用プロフェッショナルなUML設計ツール


Visual Paradigm Online

コメントを残す