UMLの歴史

UML の開発は 1994 年 10 月に始まり、Rational Software Corporation の Grady Booch と Jim Rumbaugh が Booch と OMT (オブジェクト モデリング テクニック) メソッドを統合するために協力し始めました。 どちらの方法も互いに独立して開発され、ソフトウェア システム開発におけるオブジェクト指向アプローチの最良の方法の 1 つと正しく呼ばれました。 これら 2 つの方法を組み合わせることが決定され、1995 年 10 月に統一方法と呼ばれるベータ版がリリースされました。

1996 年末までに、多くの大企業が UML を中核的なビジネス戦略として検討する準備ができていることが明らかになりました。 DEC、HP、IBM、Microsoft、Oracle、Rational Software などの大手ソフトウェア メーカーを統合した非営利コンソーシアム OMG (Object Modeling Group) が設立されました。1997 年 1 月に UML 1.0 が発行されました。 間もなく、IBM、Objectime、Platinum Technology、Softeam などの企業が OMG に加わりました。 このコラボレーションの結果、UML 1.1 が登場しました。 2003 年にバージョン 1.5 が採用されました。 2004 – バージョン 2.0 を採用

UML構造

UML (Unified Modeling Language の略) は、ソフトウェア開発分野におけるオブジェクト モデリングのためのグラフィカル記述言語です。 UML は一般言語であり、グラフィック表記を使用して UML モデルと呼ばれるシステムの抽象モデルを作成するオープン スタンダードです。 UML は、ほとんどのソフトウェア システムを定義、視覚化、設計、文書化するために作成されました。

UML は、顧客と IS 開発者、および IS 開発者のさまざまなグループの間の対話を組織化するための代表的なモデルの開発を提供します。

まず、UML は Booch、OMT、OOSE の技術を継承しています。

第二に、それらをカバーします。

第三に、UML は言語標準であり、プロセス標準ではないことに注意する必要があります。

UML 言語には、図で使用される一連のグラフィック要素が含まれています。 UML には言語として、これらの要素を組み合わせるためのルールが含まれています。 ダイアグラムは、システムのさまざまなビューを示すために使用されます。 このさまざまな表現のセットはモデルと呼ばれます。 UML モデルは、システムが何を行う必要があるかを記述します。 同時に、それがどのように実装されるかについては何も語られていません。

最も一般的な観点から見ると、UML 言語記述は、次のような 2 つの相互作用する部分で構成されます。

UML 言語のセマンティクス。 これは、UML 言語のオブジェクト モデリング概念の抽象構文とセマンティクスを定義する特定のメタモデルを表します。

UML表記。 これは、UML 言語のセマンティクスを視覚的に表現するためのグラフィカルな表記法です。

UML図

次に、UML グラフィカル表記の概要に移りましょう。 グラフィック表記法は、視覚的表現を言語のセマンティクスにマッピングしたものです。 前述したように、UML は 3 つのモデリング技術の真髄であり、基本的にそれらのグラフィック表記を継承し、ほとんど使用されない表現力の低い要素を破棄し、最新のソフトウェア システム市場のニーズを満たすために新しい要素を追加します。 UML を作成するとき、私たちは言語の単純さと理解しやすさと、その表現力と正確さの間のバランスを維持するように努めました。 開発中のシステムのモデルは、相互接続された一連のサブモデルであり、それぞれのサブモデルは、UML で定義されたグラフィカル表記を使用して記述された一連の図によって記述されます。

UML 1.x を使用して作成されたプロジェクトには、次の図を含めることができます (目的に応じてグループ化されています)。 そういう図もあるよ 八:

ユースケース図

・クラス図

· 動作図

o ステートチャート図

o アクティビティ図

ああ 相互作用図

§ シーケンス図

§ コラボレーション図

· 実装図

o コンポーネント図

o 展開図

3.1. ユースケース図

使用図は、システムのユーザーに表示される IS の機能を説明します。 「各機能」は「ユースケース」または単にユースケースとして表現されます。 ユース ケースは、システムとの典型的なユーザー インタラクションであり、次のようなものです。

ユーザーに表示される機能について説明します。

さまざまな詳細レベルを表現できます。

ユーザーにとって重要な特定の目標を確実に達成します。

ユースケースは、通常アクターと呼ばれるユーザーに関連付けられた楕円形によって図上に示されます。 アクターは、特定のユースケースでシステムを使用します (またはシステムによって使用されます)。 アクターは、このユースケースでは何らかの役割を果たします。 この図にはアクターが 1 人だけ描かれていますが、IS に関連してこの役割を果たしている実際のユーザーは多数いる可能性があります。 すべての先例のリストは実際に情報システムの機能要件を決定し、システム作成のための技術仕様の開発の基礎となります。

ユースケース図では、アクターとユースケース間の接続に加えて、さらに「ユース」と「拡張」という 2 種類のユースケース間の接続を使用することができます (図 3.1.1)。 拡張タイプの接続は、あるユースケースが別のユースケースと似ているが、機能的な負荷が若干大きい場合に使用されます。 システムの通常の動作の変化を説明するために使用する必要があります。 「使用」タイプの接続を使用すると、システム動作の特定の断片を分離し、再記述することなくさまざまなユースケースに含めることができます。

ソフトウェア開発における UML の役割の中核は、言語を使用できるさまざまな方法であり、他のグラフィカル モデリング言語から引き継がれた相違点です。 これらの違いにより、UML をどのように適用すべきかについての長くて難しい議論が生じます。

この困難な状況を解決するために、スティーブ メラーとマーティン ファウラーは独自に定義を考え出しました。 UML を使用する 3 つのモード開発者による: モード スケッチ、モード デザインとモード プログラミング言語。 もちろん、3 つの中で最も重要なのは使用モードです。 スケッチ用の UML。このモードでは、開発者は UML を使用してシステムのさまざまな側面に関する情報を伝達します。 デザイン モードでは、スケッチをフォワード エンジニアリングおよびリバース エンジニアリングに使用できます。 で 直接開発(フォワードエンジニアリング)図はコーディング前に描画されます。 リバースエンジニアリング（リバースエンジニアリング）図は、ソース コードをよりよく理解できるように、ソース コードに基づいて作成されています。

スケッチの本質 、またはスケッチモデリング、 選択性において。 直接開発では、これから作成するプログラムの個々の要素をスケッチし、通常はチームの何人かの開発者とそれについて話し合います。 スケッチを使用すると、これから行うことについてのアイデアやオプションを簡単に共有できるようになります。 取り組むつもりのプログラム全体について話し合うのではなく、最初に同僚に伝えておきたい最も重要な点、またはプログラミングを開始する前に視覚化したいプロジェクトのセクションだけを話し合います。 これらの会議は非常に短い場合があります。数時間のプログラミングをカバーするための 10 分間の会議や、2 週間の反復について話し合うための 1 日の会議などです。

リバース エンジニアリングでは、スケッチを使用してシステムの一部がどのように機能するかを説明します。 すべてのクラスを表示するのではなく、コードに入る前に興味深い、議論する価値のあるクラスだけを表示します。 スケッチは非公式かつ動的であり、迅速かつ共同で行う必要があるため、最適な表示媒体はホワイトボードです。 スケッチは文書化にも役立ちます。完全性ではなく情報を伝えるプロセスが重要な役割を果たします。 スケッチ ツールは軽量の描画ツールであり、多くの場合、開発者は UML の厳密なルールをすべて遵守しているわけではありません。 スケッチの長所は、説明の完全性ではなく、情報伝達の選択性にあります。

逆に言語は UML どうやって 手段 デザイン 完成度を目指しました。 直接開発プロセスでは、コーディングを行うプログラマーのために詳細なモデルを構築するのが仕事であるデザイナーによってプロジェクトが開発されるという考え方です。 このようなモデルは、定められた設計上の決定という点で完全である必要があり、プログラマーはあまり考えずにそれらに直接従うことができる必要があります。 モデルの設計者は同じプログラマであっても構いませんが、原則として、設計者はプログラミング チームのモデルを開発する上級プログラマです。 このアプローチの理由は、プロのエンジニアが図面を作成し、それを建設会社に渡すという他の種類のエンジニアリング作業との類似性にあります。

設計はシステムのすべての部分に使用することも、設計者が特定の部分のモデルを描画することもできます。 一般的なアプローチは、設計者がサブシステム インターフェイスとして設計レベルのモデルを開発し、開発者が実装の詳細に取り組むことです。

リバース エンジニアリングにおけるモデルの目的は、プログラムに関する詳細情報を紙の文書として、またはグラフィカル ブラウザを使用した対話型の表示に適した形式で表現することです。 このようなモデルでは、クラスの詳細をすべて、開発者が理解しやすいグラフィカル形式で表示できます。

モデリングには、タスクの要件を満たす詳細を維持する必要があるため、スケッチよりも高度なツールが必要です。 特殊な CASE ツール (コンピューター支援ソフトウェア エンジニアリング) はこのカテゴリに分類されますが、この用語自体はほとんど汚い言葉になっており、ベンダーはこの用語を避けようとしています。 直接開発ツールは、情報を保存する目的で図を描画し、それをリポジトリにコピーすることをサポートします。 リバース エンジニアリング ツールは、ソース コードを読み取り、その解釈をリポジトリに書き込み、図を生成します。 フォワードエンジニアリングとリバースエンジニアリングの両方を可能にするツールは次のように呼ばれます。 両面（往復）。

一部のツールはソース コードをリポジトリとして使用し、図はそれをグラフィカル表現に使用します。 このようなツールはプログラミングとより密接に関連しており、多くの場合、ソース コード編集ツールに直接組み込まれています。

モデルとスケッチの境界線は非常に曖昧ですが、違いは、スケッチは重要な情報を強調して意図的に不完全な状態に保たれているのに対し、モデルは完全性を目指し、多くの場合、プログラミングを単純でやや機械的な動作に減らすことを目的としている点です。 つまり、スケッチを試用要素として定義し、モデルを最終要素として定義できます。

UML を扱う期間が長くなり、プログラミングがより機械的になるにつれて、自動プログラム作成に移行する必要性がより明らかになります。 実際、多くの CASE ツールは何らかの方法でコードを生成し、システムの重要な部分の構築を自動化できます。 最終的には、UML を使用してシステム全体を記述できるようになり、UML モードになります。 プログラミング言語として . このような環境では、開発者は実行可能コードに直接コンパイルされる図を描画し、UML がソース コードになります。 このような UML のアプリケーションには、特に高度なツールが必要であることは明らかです。 (また、UML とソース コードがまったく同じになると、フォワード エンジニアリングおよびリバース エンジニアリングの表記法も無意味になります。)

プログラミング言語としての UML に関する興味深い問題の 1 つは、動作ロジックのモデル化の問題です。 UML 2 では、動作をモデル化する 3 つの方法、インタラクション図、状態図、アクティビティ図を提供します。 彼ら全員にプログラミングの分野で支持者がいます。

UML のもう 1 つの開発者の視点は、概念モデリングでの使用とソフトウェア モデリングでの使用の間のどこかに位置します。 ほとんどの開発者は、UML を使用してソフトウェアをモデル化します。 と ソフトウェアの観点 UML 要素は、ソフトウェア システム要素にほぼ直接マッピングされます。 後で説明するように、マッピングは必ずしも指示に従うことを意味するわけではありませんが、UML を使用する場合、ソフトウェア要素について話します。

と 概念的な視点 UML はドメインの概念の記述を表します。 ここではソフトウェア要素についてはあまり話しておらず、特定の主題分野について議論するための語彙を作成することについて話しています。

視点の選択に厳密なルールはありません。 この問題はさまざまな角度から見ることができるため、応用方法はかなり多くあります。 一部のツールは、ソース コードを自動的に図に変換し、UML をソース コードの代替形式として扱います。 これは主にプログラム的な観点からのものです。 UML 図を使用して「資産プール」という用語のさまざまな意味を会計士のグループとテストして理解する場合は、より厳密な概念ビューを採用する必要があります。

UML がさまざまに使用される結果、UML 図が何を意味するのか、また UML 図が世界の他の部分とどのように関係するのかについて多くの議論が行われています。 これは特に、UML とソース コードの関係に影響します。 開発者の中には、プロジェクトの実装に使用されるプログラミング言語から独立したモデルを作成するために UML を使用する必要があると考えている人もいます。 言語に依存しないモデルは矛盾していると確信している人もいます。

もう 1 つの意見の相違は、UML の性質の問題に関連しています。 ほとんどの UML ユーザー、特にスケッチャーは、図の中に UML の本質を見出していると思います。 ただし、UML の作成者は、図は二次的なものであり、UML メタモデルは主要なものであると考えています。 図はメタモデルを表現したものにすぎません。 この観点は、設計モードおよびプログラミング言語モードで UML を使用する開発者にとっても意味があります。

まとめ： UML を使用する 3 つのモードが特定されました。

1 - スケッチモード。 スケッチは、将来のコード (その後、モデルに基づいてコードを記述する必要があります) または既存のコード (モデルをよりよく理解するため) のいずれかで作成されます。 目的は迅速な情報交換です。 機能 - 選択性。 完全性は重要ではなく、交換のプロセス自体が重要です。

2 - デザインモード。 目標は完全性です。 詳細なモデルが作成され、実装されます (プログラマは実装についてあまり考える必要がなく、作業は単純な機械的な動作に減ります)。 全体をモデル化することも、一部だけをモデル化することもできます。

3 - プログラミング言語モード。 グラフィカルな図はコードにコンパイルされ、UML がソース コードになります。

昨年の回答（デン）

言語 統一モデリング言語 (UML)これは、モデリングと設計方法論のかなり長い、まだ完了していない進化の結果であると考えることができます。

この統合では、次の 3 つの主な目標が追求されました。

· オブジェクト指向技術を使用した、概念から実行可能モジュールまでのシステム モデリング。

· 複雑なシステムにおけるスケーリングの問題を解決する。

· 人間とコンピュータの両方で使用されるモデリング言語の作成。

UML は何に使用されますか?

UML は何よりもまず言語であり、他の言語ツールと同様に、語彙と、その語彙内の単語を組み合わせるためのルールを提供します。 ここでの語彙とルールは、システムの概念的および物理的表現に焦点を当てています。 この言語はモデルの作成方法と読み取り方法を指示しますが、どのような種類のシステム モデルを作成するかについては何のガイダンスも提供しません。これは UML の範囲外であり、ソフトウェア開発プロセスの領域です。

UML は視覚化言語です。 UML でモデルを記述することには、システムに関する情報を転送するプロセスを容易にするという 1 つの単純な目的があります。 各 UML シンボルには厳密に定義されたセマンティクスがあるため、解釈エラーを回避できます。

UML は仕様と正確な定義の言語です。 この意味で、UML モデリングとは、正確で、明確で、完全なモデルを構築することを意味します。

UML はドキュメント言語です。

UML図

UML におけるさまざまな観点からのシステム設計の視覚化は、システムの投影であるダイアグラムを通じて実装されます。 ダイアグラムは要素のセットをグラフィカルに表現したもので、頂点 (エンティティ) とエッジ (関係) を備えた接続されたグラフとして表されます。

チャートの定義は次のとおりです。

· クラス図- 多くのクラス、インターフェース、コラボレーション、およびそれらの間の関係を示す構造図。

· オブジェクト図- 多くのオブジェクトとオブジェクト間の関係を示す構造図。 これはクラス図の特殊なケースと考えることができます。 モデリング ツールは、フィーチャー ダイアグラムの別の形式をサポートする必要はありません。 これらはオブジェクトを表すため、クラスを持たないが、クラスに属するオブジェクトがあるクラス図は、オブジェクト図とみなすことができます。

· ユースケース図- 多くの先例と主体、およびそれらの間の関係を示す行動図。

· 相互作用図:

ああ シーケンス図- 相互作用を示し、イベントの時系列を強調表示する動作図。

ああ 連携図- 相互作用を示し、メッセージを送受信するオブジェクトの構造的構成を強調する動作図。

· ステートチャート図- マシンを示し、イベントを受信する順序に関してオブジェクトの動作を強調表示する動作図。

· アクティビティ図- マシンを示し、あるアクティビティから別のアクティビティへの制御フローの遷移を強調表示する動作図。

· コンポーネント図- 特定のコンポーネントのセットの構成とコンポーネント間の依存関係を示す図 - 統計的なタイプのシステムを指します。

· システムトポロジ図（展開図）- ノードとノード間の関係を示す構造図。

前年の回答 (マディナ)

オプション1

UML におけるオブジェクトベースの設計手法 (UML 図)

統一モデリング言語 (UML) は、オブジェクト指向のアプローチに基づいて、さまざまな種類のシステム (ソフトウェア、ハードウェア、ソフトウェアとハ​​ードウェアの混合、人間の活動を明示的に含むものなど) を指定、視覚化、構築、および文書化するための言語です。

とりわけ、UML 言語はリレーショナル データベースの設計に使用されます。 このために、言語のごく一部 (クラス図) が使用されますが、完全ではありません。 リレーショナル データベースの設計という観点から見ると、モデルの機能は ER 図の機能とそれほど変わりません。

クラス図 UML 用語では、データベース設計に明示的に関係しないクラス (およびその他のエンティティ) のセットと、これらのクラス間の関係を示す図を「ダイアグラム」と呼びます。 制約は、自然言語で非公式に指定することも、OCL (オブジェクト制約言語) で定式化することもできます。

クラスは次のように呼ばれます共通の属性、操作、関係、セマンティクスを持つオブジェクトのコレクションの名前付き記述。 グラフィカルに、クラスは長方形として表されます。 クラスを識別するための名前（文字列）。

クラス属性は、そのプロパティのインスタンスが取ることができる値のセットを記述するクラスの名前付きプロパティです。 クラスは任意の数の属性を持つことができます (特に、属性を持たないこともできます)。

クラスの操作は、このクラスの任意のオブジェクトから要求できる名前付きサービスです。 操作は、オブジェクトに対して何ができるかを抽象化したものです。 クラスには任意の数の操作を含めることができます (特に、操作を含めないこともできます)。 クラスの一連の操作は、このクラスのすべてのオブジェクトに共通です。

クラス図には、依存関係、一般化、および関連性という 3 つの異なるカテゴリの関係が含まれる場合があります。

依存症あるクラスの仕様の変更が、最初のクラスを使用する別のクラスの動作に影響を与える可能性がある場合、アプリケーション結合と呼ばれます。 2 番目のクラスのインターフェイスが変更されると、最初のクラスのオブジェクトの動作に影響します。 依存関係は、依存関係が存在するクラスを指す矢印が付いた点線として表示されます。

接続の一般化と呼ばれる共通エンティティ間の接続と呼ばれます スーパークラス、または親、およびこのエンティティのより特殊なバージョンと呼ばれる サブクラス、または子孫。 一般化は接続と呼ばれることもあります 「は」これは、子孫クラスが祖先クラスの特殊なケースであることを意味します。 子孫クラスは祖先クラスのすべての属性と操作を継承しますが、追加の属性と操作をその中で定義できます。

ジェネリック関係が使用されるほとんどの場合、単一継承 (各サブクラスにはスーパークラスが 1 つだけある) で十分です。 ただし、UML では、1 つのサブクラスが複数のスーパークラスに基づいて定義されている場合、多重継承も許可されます。

この図では、クラスは 学生そして 研究者同じスーパークラスから派生した 男大学から。 クラスへ 学生クラスのそれらのオブジェクトを参照します 男大学から、学生とクラスに対応します 研究者- クラスオブジェクト 男大学から、研究者に対応します。 多くの学生は在学中にすでに研究プロジェクトに参加し始めていることが多いため、このような 2 つのクラス オブジェクトが存在する可能性があります。 学生そして 研究者、クラスの 1 つのオブジェクトに対応します 男大学から。 したがって、クラスのオブジェクトの中には、 学生研究者の場合もあれば、学生の場合もあります。 次にクラスを定義します 学生研究者スーパークラスからの多重継承を通じて 学生そして 研究者。 クラスオブジェクト 学生研究者クラスのすべてのプロパティと操作が含まれています 学生そして 研究者これらのクラスのオブジェクトが使用できる場所であればどこでも使用できます。 したがって、包含多態性は引き続き機能します。 しかし、これには多くの問題が伴います。 たとえば、サブクラスを作成するとき 学生そして 研究者どちらも属性を定義できます コンピュータのIPアドレス。 クラスオブジェクトの場合 学生この属性の値は、ターミナル クラスのコンピュータの IP アドレス、およびクラスのオブジェクトの IP アドレスになります。 研究者- 研究室のコンピュータの IP アドレス。 また、クラスオブジェクトの場合、 学生研究者同じ名前の両方の属性が重要である場合があります (研究生は、端末クラスのコンピューターの IP アドレスと研究室のコンピューターの IP アドレスの両方を持っている場合があります)。 実際には、次のいずれかの解決策が使用されます。

• サブクラスの形成を禁止する 学生研究者いずれかのスーパークラスで属性の名前が変更されるまで コンピュータのIPアドレス;
• このプロパティはスーパークラスの 1 つだけから継承します。そのため、たとえば、属性値は次のようになります。 コンピュータのIPアドレスクラスオブジェクトの場合 学生研究者常に研究室のコンピュータの IP アドレスになります。
• サブクラスで両方のプロパティを継承しますが、意味を明確にするために両方の属性の名前が自動的に変更されます。 たとえば、それらに名前を付けます 生徒のコンピュータの IP アドレスそして 研究者のコンピュータの IP アドレス.

これらのソリューションにはそれぞれ欠点があるため、UML を使用してリレーショナル データベースを設計する場合、一般にクラス継承を使用する際には十分に注意し、多重継承を避けるように努める必要があります。

協会これは構造的関係と呼ばれ、あるクラスのオブジェクトが別のクラスまたは同じクラスのオブジェクトと何らかの形で関連していることを示します。 アソシエーションの両端が同じクラスに属することが許可されます。 関連付けには 2 つのクラスが含まれる場合があり、その場合はバイナリと呼ばれます。 一度に n 個のクラスを接続する関連付けを作成することができます (これらは n 項関連付けと呼ばれます) 1) グラフィックでは、関連付けは、クラスをそれ自体または他のクラスに接続する線として表されます。

関連の概念には、名前、役割、多重性、集約という 4 つの重要な追加概念があります。 関連付けには、関係の性質を特徴付ける名前を付けることができます。 関連付けに名前を付けるもう 1 つの方法は、関連付けに参加する各クラスの役割を示すことです。 クラスの役割は、ER モデルにおける接続の終端の名前と同様に、指定されたクラスに近い関連線の下に配置された名前によって指定されます。

一般に、関連付けには、それ自体の名前とクラスの役割の名前の両方を付けることができます。 これは、クラスが異なる関連付けで同じ役割を果たすことができるため、一般にクラスの役割名のペアでは関連付けが識別されないためです。 2 つのクラス間に関連付けが 1 つだけ定義されている単純な場合は、追加の名前をまったく関連付けないことも可能です。

多重度アソシエーションのロールは、特定のロールを持つクラスのオブジェクトがいくつアソシエーションの各インスタンスに参加できる、または参加する必要があるかを示す特性です。

関連ロールの多重度を指定する最も一般的な方法は、特定の数値または範囲を指定することです。 「1」は、特定の役割を持つ各クラス オブジェクトがこの関連付けのインスタンスに参加する必要があり、特定の役割を持つ 1 つのクラス オブジェクトだけが関連付けの各インスタンスに参加できることを示します。 範囲「0..1」を指定すると、特定の役割を持つクラスのすべてのオブジェクトが特定の関連付けのインスタンスに参加する必要はなく、関連付けの各インスタンスに参加できるオブジェクトは 1 つだけであることを示します。 同様に、範囲「1..*」を指定すると、指定された役割を持つクラスのすべてのオブジェクトがこの関連付けのインスタンスに参加する必要があり、少なくとも 1 つのオブジェクトが関連付けの各インスタンスに参加する必要があることを示します (上限は指定されていません) ）。 多重度を決定するより複雑な場合には、範囲リストを使用できます。

2 つのクラス間の通常の関連付けは、等しいエンティティ間の関係を特徴づけます。つまり、両方のクラスは同じ概念的レベルにあります。 しかし、場合によっては、クラス図は、2 つのクラス間の関連が部分全体の特別な形式を持つという事実を反映する必要があります。 この場合、クラス「全体」はクラス「部分」よりも上位の概念レベルを有する。 この種の協会はと呼ばれます 集計.

コンピュータは各端末クラスに設置する必要があります。 したがってクラス コンピュータークラスの「一部」です ターミナルクラス。 クラスの役割 コンピューター原則として端末クラスはコンピュータなしでも存在できるため、これはオプションです。 また、コンピュータを搭載していない端末クラスはその機能を実行しませんが、クラスオブジェクトは ターミナルクラスそして コンピューター独立して存在します。

「部分」と「全体」の結びつきが強すぎて、「全体」の破壊がその「部分」すべての破壊につながる場合がある。 このプロパティとの集計関連付けは次のように呼ばれます。 複合、または単なる作曲。

どの学部も 1 つの大学の一部であり、大学の清算はその大学内のすべての既存の学部の清算につながりますが、大学の存続中に個々の学部が清算され創設されることもあります。

クラス図では、設計されたデータベースでサポートする必要がある整合性制約を指定できます。 UML では、自然言語と OCL (オブジェクト制約言語) の 2 つの方法で制約を定義できます。

データベース整合性制約を定義するという観点からは、クラス不変式を定義する手段の方が重要です。

下 不変 OCL のクラスは、特定のクラスのすべてのオブジェクトが満たさなければならない条件として理解されます。 より正確には、クラス不変式は論理式であり、その評価では、特定のクラスのオブジェクトが作成されるときに真が得られ、このオブジェクトの存在全体を通じて真の値が維持されなければなりません。 不変式を定義するときは、クラスの名前と、指定したクラスの不変式を定義する式を指定する必要があります。 構文的には次のようになります。

以下は、OCL で制約を指定するための不変条件の例です。

1. 30 歳以上の従業員は 5 人以上の部門で働かなければならないという制限を OCL で表現します。

2. 各部門にはマネージャーが必要であり、対応する会社よりも先に部門を設立してはいけないという制限を定義します。

3. 4 番目の不変条件により、従業員の最大数が 1000 人に制限されます。

オプション 2

1. RUPモデル。 RUP モデルの基本図。

Rational Unified Process (RUP) は、スパイラル ソフトウェア開発手法の 1 つです。 この方法論は Rational Software によってサポートされており、製品は年に約 2 回更新されます。 統一モデリング言語 (UML) は、一般知識ベースのモデリング言語として使用されます。

RUP での反復的なソフトウェア開発では、プロジェクトをいくつかの小さなプロジェクトに分割し、それらを順次実行します。各開発反復は、反復の最後に達成する必要がある一連の目標によって明確に定義されます。 最後の反復では、一連の反復目標が製品顧客によって指定された一連の目標と正確に一致する必要がある、つまり、すべての要件が満たされる必要があると想定しています。 RUP は、反復的なソフトウェア開発に対する構造化されたアプローチを提供し、プロセスを時間の経過とともに 4 つのマイルストーン (開始、精緻化、構築、移行) に分割します。 RUP は、プロジェクトの開発を成功させるために次の 6 つの実践を推奨しています。

反復的な開発。

要件管理。

モジュール式アーキテクチャの使用。

ビジュアルモデリング。

品質チェック;

変更を追跡します。

UML でのシステム モデルのグラフィック表現は次のように呼ばれます。 図。 UML 言語に関しては、次の型が定義されています。

· ユースケースまたはユースケース図(ユースケース図)

· クラス図(クラス図)

· 行動チャート(動作図)

· 状態図(ステートチャート図)

· アクティビティ図(アクティビティ図)

· 相互作用図(相互作用図)

· シーケンス図(シーケンス図)

· 協力図(連携図)

· 実装図(実装図)

· コンポーネント図(部品図)

· 展開図（展開図）

これらの各図は、システム モデルの異なるビューを指定します。 同時に、ユースケース図はシステムの概念モデルを表し、他のすべての図を構築するための開始点となります。 クラス図は、システムの構造設計の静的側面を反映する論理モデルであり、同じく論理モデルの一種である動作図は、システムの機能の動的側面を反映します。 実装図は、システムのコンポーネントを表し、その物理モデルを参照するのに役立ちます。

上に挙げた図のうち、2 つ以上の亜種を指定するものもあります。 次の図は独立した表現として使用されます。 ユースケース, クラス, 州, 活動, シーケンス, 協力, コンポーネントそして 導入.

UML 図の場合、含まれる情報の点で重要なビジュアル シンボルには次の 3 種類があります。

· コミュニケーション、平面上の異なる線で表されます。

· 文章、個々の幾何学的形状の境界内に含まれる。

· グラフィックシンボル、図の視覚要素の近くに描かれています。

· 各図は、モデル化された主題領域の一部を完全に表現したものでなければなりません。

· 図上に示されるモデル エンティティは、同じ概念レベルである必要があります。

· エンティティに関するすべての情報は、図上に明確に表示される必要があります。

· 図には矛盾する情報が含まれていてはなりません。

· 図にテキスト情報を詰め込みすぎないでください。

· 各図は、そのすべての要素を正しく解釈するために独立していなければなりません。

· 特定のシステムを記述するために必要な図の種類の数は厳密には固定されておらず、開発者によって決定されます。

システム モデルには、定義されている要素のみを含める必要があります。

22.IC設計[J]

トニーの用意された答え

Denis Kovalevich の回答が更新されました

実装段階

導入がうまくいかない主な原因の1つは、経営コンサルティング段階でのISプロジェクトの開発が不十分であることです。 その結果、情報システムが企業管理システム全体に十分に統合されていないことが判明しました。

・特に重要な段階に十分な時間とエネルギーを費やす必要がある場合、主要なスタッフからのサポートが不足している。

· 段階的で賢明なアプローチではなく、野心的すぎる計画。

· 同様のビジネスで同様のシステムを使用した実際の経験を持つ専門家から十分なアドバイスを得ることができなかった。

運用段階

o 日常使用。

廃棄

前年の回答 (マディナ)

実装。

2.1. 技術プロジェクト (TP) の作成。

請負業者のコンサルタントと顧客の IT 専門家が TP を構成します。

顧客は TP を承認します。

作業範囲、期間、費用が指定されています。

TP マテリアルは、作業を計画および文書化するときに使用されます。

TP構成：

保存されたデータの構造。

アルゴリズム。

使用されるシステム リソース、その構造と接続。

ユーザーインターフェース。

2.2. 仕事の計画。

承認された規制に従って

請負業者のプロジェクトマネージャーと顧客は作業プログラム（WP）を作成します。

顧客と請負業者が RP を承認します。

作業チームのメンバー向けに個別の計画が作成されます。

RP構成：

作業リスト: 構成、テスト、受け入れ (作業リストには技術仕様と技術仕様が含まれる場合があります)。

ターンアラウンドタイム;

RPの各項目を担当します。

2.3. 基本的な参考書を埋めていく。

ステージの特徴：

1 ～ 18 か月かかる場合があります。

情報入力の一元化が必要。

システムが動作するために必要な条件です。

実装方法:

データ変換。

ユーザー (オペレーター) による手動データ入力。

2.4. セットアップ、テスト、受け入れ。

ステージの特徴：

最も労働集約的で責任あるもの。

事前の準備（規制、技術仕様、技術仕様、RP）に大きく依存します。

演奏者側と顧客側の両方に厳しい規律が必要です。

顧客からの追加のタスクの出現を伴う。

競合状況を克服するには、顧客と請負業者の側に柔軟性が必要です。

2.5. 試運転。

ステージの特徴：

実行者からの迅速かつ信頼性の高い応答が必要です。

顧客に多大な労力が必要となる場合があります (二重作業)。

かなりの期間（1〜3か月）があります。

これには、コメント (提案) の最終リストの作成、構成、テスト、承認に関する最終作業の計画と実行が伴います。

2.6. ドキュメンテーション。

ユーザー向けの説明書の作成。

システム内の部門間の相互作用に関する規制を作成する。

技術文書の完成。

その他の（事前に合意された）文書の作成。

2.7. プロジェクトの完了。

契約関係の法的終了。

最終的な財務上の決済。

さらなる協力に関する決定を下す：技術サポートおよび保証後のサポートに関する契約を締結し、新しいプロジェクトを実施する。

IPリサイクル– DELETE ボタンで実行します。

昨年の回答（デン）

実装段階

開発と実装のフェーズは通常、常に完全に完了します。 それは、テクノロジーの発展の遅れ、スタッフやユーザーの能力不足、優れたコンサルタントの不足によって妨げられることはありません。

この段階で問題が発生した場合は、次の 3 つの主な理由が考えられます。

特に重要な段階に十分な時間とエネルギーを費やさなければならない場合、主要なスタッフからのサポートが不足している。

段階的で賢明なアプローチではなく、過度に野心的な計画。

同様のビジネスで同様のシステムを使用した実際の経験を持つ専門家から十分なアドバイスを得ることができなかった。

運用段階

・情報システムの稼働

o 技術機器の試運転の試運転。

o ソフトウェアを試験的に運用する。

o 職員の訓練と認定。

o コンポーネントとシステム全体の試運転を実施する。

o 試運転と作業受領証明書の署名。

・情報システム運用

o 日常使用。

o ソフトウェア、ハードウェア、およびプロジェクト全体のサポート。

サポート（保守）段階

テクニカル サポート サービスは、企業情報システムの運用において非常に重要な役割を果たします。 情報システムの運用段階における適格な技術サービスの存在は、情報システムに割り当てられたタスクを解決するための必要条件であり、保守要員によるミスは、情報システム自体のコストに匹敵する明らかなまたは隠れた経済的損失につながる可能性があります。

情報システムの保守を組織化するための準備としての主な準備作業は次のとおりです。

· システムの最も重要なコンポーネントを特定し、それらのダウンタイムの重要性を判断する (これにより、情報システムの最も重要なコンポーネントを特定し、メンテナンスのためのリソースの割り当てを最適化できます)。

· 保守タスクの識別と、サービス部門によって解決される内部タスクと、専門サービス組織によって解決される外部タスクへの分割 (これにより、実行される機能の範囲と責任の分割が明確に定義されます)。

· 記載されたタスクおよび能力分担の枠組み内でメンテナンスを組織するために必要な利用可能な内部および外部リソースの分析 (分析の主な基準: 機器の保証の有無、修理資金の状況、従業員の資格)。

· 保守組織計画の作成。実行するアクションの段階、実行のタイミング、段階のコスト、および実行者の責任を決定する必要があります。

情報システムの高品質な技術保守を提供するには、日常の管理タスクを解決するだけでなく、障害が発生した場合にシステムを迅速に復元できる高度な資格を持つ専門家の関与が必要です。

廃棄

清算される製品に関連するすべての情報が情報情報システムから除外されることを伴う、そのコンポーネントの二次原材料への変換（環境要件に準拠した）を伴う製品の清算。

このトピックについては、http://www.piter.com/attachment.php?barcode=978546900641&at=exc&n=0 および http://www.rus-lib.ru/book/38/men/21 で詳しく説明されています。 /2.3 .html

23.IC設計[J]

関連情報。

以下のような定義です。

言語- 以下の役割を果たす標識システム:

• 人間のコミュニケーションと精神活動の手段。
• 人の自己認識を表現する方法。
• 情報を保存および送信する手段。

言語には、一連の記号 (語彙) と、その使用と解釈のための規則 (文法) が含まれます。

このかなり包括的な定義に、言語には自然なものと人工的なもの、形式的なものと非形式的なものがあることを付け加えなければなりません。 UML は形式的かつ人工的な言語ですが、後で説明するように、このラベルは UML に完全には適合しません。 これは作成者がいるという点で人為的なものですが、これについては今後何度か触れます (同時に、UML の開発は継続的に行われており、自然言語と同等の地位にあります)。 これを形式的と呼ぶことができるのは、その使用に関する規則があるためです (ただし、後で説明するように、UML 記述には明らかに非形式的な要素も含まれています)。 もう 1 つのニュアンス: UML はグラフィカル言語であるため、状況が少し混乱します。

プログラミング言語の記述例ですでに見たように、形式的な人工言語を記述する場合、原則として、そのような要素は次のように記述されます。

1. 構文つまり、言語構造を構築するための規則を決定します。
2. セマンティクス、つまり、どの言語構造が意味論的な意味を獲得するかに応じたルールの定義です。
3. 語用論つまり、必要な目標を達成するために言語構造を使用するためのルールを決定します。

また、同時期（80年代初頭）には「オブジェクト指向の時代」が始まりました。 すべては、60 年代に使用されていた Simula-67 言語の概念の一部を適用した、プログラミング言語の SmallTalk ファミリの出現から始まりました。 オブジェクト指向アプローチの出現は、主に問題の複雑さの増大によるものでした。 オブジェクト指向のアプローチプログラムの作成と運用の原則そのものに非常に根本的な変更を加えましたが、同時に、大幅な増加を許可しました。 パフォーマンスプログラマーの仕事を見直し、問題とその解決方法を別の視点から見て、プログラムをよりコンパクトにして簡単に拡張できるようにします。 その結果、もともとプログラミングへの伝統的なアプローチを指向していた言語は、多数のオブジェクト指向の拡張を受けました。 最初の 1 つは 80 年代半ば、Apple の Object Pascal プロジェクトでした。 その上、 オブジェクト指向アプローチはまったく新しいソフトウェア テクノロジの強力な波を生み出し、その頂点は Microsoft などの一般に認知されたプラットフォームでした。 NET Framework と Sun Java。

しかし、最も重要なことは、OOP の出現には、モデリングのための便利なツール、つまり複雑なソフトウェア システムを記述するための統一された表記法が必要だったということです。 そこで、3 人の主要な専門家、最も人気のあるメソッドの 3 人の著者である「スリー アミーゴ」が、それぞれの開発を統合することにしました。 1991 年、「スリー アミーゴ」のそれぞれが、OOAP メソッドの概要を説明した本を書くことから始めました。 それぞれの方法論は、

UML は、OO システムを記述、視覚化、設計、文書化するための統一グラフィカル モデリング言語です。 UML は、OO アプローチに基づいてソフトウェアをモデリングするプロセスをサポートし、概念とプログラムの概念の関係を整理し、複雑なシステムのスケーリングの問題を反映するように設計されています。 UML モデルは、ビジネス分析からシステム メンテナンスに至るまで、ソフトウェア ライフ サイクルのすべての段階で使用されます。 さまざまな組織が、問題領域や使用するテクノロジに応じて、適切と思われる UML を使用する場合があります。

UML の簡単な歴史

90 年代半ばまでに、さまざまな著者が数十の OO モデリング手法を提案しており、それぞれが独自のグラフィック表記を使用していました。 同時に、これらの方法にはいずれも長所がありましたが、「あらゆる側面から」、つまり必要なすべての投影を示す、PS の十分に完全なモデルを構築することはできませんでした (記事 1 を参照)。 さらに、OO モデリング標準が存在しないため、開発者が最適な方法を選択することが困難になり、ソフトウェア開発への OO アプローチの広範な採用が妨げられました。

オブジェクト テクノロジとデータベースの分野における標準の採用を担当する組織であるオブジェクト管理グループ (OMG) の要請により、統一と標準化という緊急の問題は、最も人気のある 3 つの OO メソッドの作成者によって解決されました。 Butch、D. Rambo、A. Jacobson は協力してバージョン UML 1.1 を作成し、1997 年に OMG によって標準として承認されました。

UMLは言語です

どの言語も語彙と、単語を組み合わせて意味のある構造を作成するためのルールで構成されます。 これは、特に UML などのプログラミング言語の構造です。 その特徴は、言語辞書がグラフィック要素で構成されていることです。 各グラフィック シンボルには特定のセマンティクスが関連付けられているため、ある開発者が作成したモデルは、別の開発者や、UML を解釈するソフトウェア ツールでも明確に理解できます。 ここから特に、UML で表現されたソフトウェア モデルは、OO プログラミング言語 (Java、C++、VisualBasic など) に自動的に変換できることがわかります。つまり、UML をサポートする優れたビジュアル モデリング ツールがあれば、モデルを構築すると、このモデルに対応するサンプル プログラム コードも受け取ります。

UML はメソッドではなく言語であることを強調しておく必要があります。 どの要素からモデルを作成するか、どのように読み取るかについては説明されていますが、どのモデルをどのような場合に開発する必要があるかについては何も述べられていません。 UML に基づいてメソッドを作成するには、ソフトウェア開発プロセスの記述を補足する必要があります。 このようなプロセスの例としては、Rational Unified Process があります。これについては、後続の記事で説明します。

UML辞書

モデルはエンティティとエンティティ間の関係の形式で表され、図に示されます。

エンティティは、モデルの主要な要素である抽象化です。 エンティティには、構造 (クラス、インターフェイス、コンポーネント、ユース ケース、コラボレーション、ノード)、動作 (インタラクション、状態)、グループ化 (パッケージ)、および注釈 (コメント) の 4 つのタイプがあります。 エンティティの各タイプには、独自のグラフィック表現があります。 エンティティについては、図を検討するときに詳しく説明します。

関係エンティティ間のさまざまなつながりを示します。 UML は次の関係タイプを定義します。

• 依存症は、2 つのエンティティのうちの 1 つ (独立したもの) の変更が、もう 1 つの (依存したもの) のセマンティクスに影響を与える可能性がある場合の、2 つのエンティティ間のそのような接続を示しています。 依存関係は、依存エンティティから独立エンティティに向かう点線の矢印で表されます。
• 協会あるエンティティのオブジェクトが別のエンティティのオブジェクトに関連していることを示す構造的関係です。 グラフィックでは、関連付けは、関連付けられたエンティティを接続する線として表示されます。 アソシエーションはオブジェクト間を移動するのに役立ちます。 たとえば、クラス「Order」と「Product」の間の関連付けを使用して、一方では特定の注文で指定されたすべての製品を検索したり、他方ではこの製品を含むすべての注文を検索したりすることができます。 対応するプログラムがそのようなナビゲーションを提供するメカニズムを実装する必要があることは明らかです。 一方向のみのナビゲーションが必要な場合は、関連付けの最後に矢印で示されます。 関連の特殊なケースは集約、つまり「全体」-「部分」という形式の関係です。 グラフィカルに、エッセンス全体の近くの端にあるダイヤモンドで強調表示されます。
• 一般化親エンティティと子エンティティの間の関係です。 基本的に、この関係はクラスとオブジェクトの継承のプロパティを反映します。 一般化は、親エンティティに向かう三角形で終わる線として示されています。 子は親の構造 (属性) と動作 (メソッド) を継承しますが、同時に新しい構造要素と新しいメソッドを持つことができます。 UML では、エンティティが複数の親エンティティに関連付けられる多重継承が可能です。
• 実装– 動作の仕様を定義するエンティティ (インターフェイス) と、この動作の実装を定義するエンティティ (クラス、コンポーネント) との間の関係。 この関係はコンポーネントをモデル化するときによく使用され、後続の記事で詳しく説明します。

図。 UML では次の図が提供されます。

• システムの動作を説明する図:
• 状態図
• アクティビティ図、
• オブジェクト図、
• シーケンス図、
• コラボレーション図。
• システムの物理的な実装を説明する図:
• コンポーネント図。
• 展開図。

モデル コントロール ビュー。 パッケージ。

モデルが人間によく理解されるためには、モデルを階層的に編成し、階層の各レベルに少数のエンティティを残す必要があることはすでに述べました。 UML には、モデルの階層表現を編成する手段であるパッケージが含まれています。 どのモデルも、クラス、ユースケース、その他のエンティティや図を含む一連のパッケージで構成されます。 パッケージには他のパッケージを含めることができ、階層を作成できます。 UML では個別のパッケージ図は提供されませんが、他の図に表示される場合があります。 パッケージは、しおりが付いた長方形として描かれています。

UML が提供するもの。

• パッケージを識別することによる複雑なシステムの階層的記述。
• ユースケースの装置を使用してシステムの機能要件を形式化する。
• アクティビティ図とシナリオを作成してシステム要件を詳細に説明します。
• データクラスを特定し、クラス図の形式で概念的なデータモデルを構築します。
• ユーザーインターフェイスを記述するクラスを特定し、画面ナビゲーションスキームを作成します。
• システム機能を実行する際のオブジェクトの相互作用のプロセスの説明。
• アクティビティ図と状態図の形式でのオブジェクトの動作の説明。
• ソフトウェアコンポーネントとインターフェースを介したそれらの相互作用の説明。
• システムの物理アーキテクチャの説明。

そして最後は…

UML にはさまざまな魅力がありますが、ビジュアル モデリング ツールなしでは実際のソフトウェア モデリングで使用するのは困難です。 このようなツールを使用すると、表示画面上に図をすばやく表示し、文書化し、さまざまな OO プログラミング言語でプログラム コード テンプレートを生成し、データベース スキーマを作成できます。 そのほとんどには、プログラム コードの再エンジニアリングの可能性が含まれています。これは、プログラムのソース コードを自動的に分析することによって、ソフトウェア モデルの特定の予測を復元することです。これは、モデルとコード間のコンプライアンスを確保するため、また、以前のシステムの機能を継承するシステムを設計する場合に非常に重要です。

統一モデリング言語 (UML) は、情報システム (IS) の「ブループリント」を作成するための標準ツールです。 UML を使用すると、これらのシステムの要素を視覚化、指定、設計、文書化できます。

UML は、エンタープライズ規模の情報システムから分散 Web アプリケーション、さらには組み込みリアルタイム システムまで、あらゆるシステムのモデル化に適しています。 これは非常に表現力豊かな言語であり、システムの開発とその後の展開に関連するあらゆる観点からシステムを表示できます。 表現の可能性が豊富であるにもかかわらず、この言語は理解しやすく、使いやすいです。 UML の学習を始めるのに最適な場所は、その概念モデルです。このモデルには、基本的な構成要素、それらのブロックをどのように組み合わせるかを定義するルール、および言語の一般的なメカニズムのいくつかという 3 つの基本要素が含まれています。

UML は、IS 開発プロセスのコンポーネントの 1 つです。 UML はモデル化される現実から独立していますが、モデリング プロセスがユース ケースの考慮に基づいており、反復的かつ増分的であり、システム自体が明確に定義されたアーキテクチャを持つ場合に最適に使用されます。

UML は、ソフトウェア システムの要素を視覚化し、指定し、構築し、文書化するための言語です。 言語は、辞書と、言語に含まれる単語を組み合わせて意味のある構造を作成できるルールで構成されます。 モデリング言語では、語彙とルールはシステムの概念的および物理的表現に焦点を当てます。 UML のようなモデリング言語は、IC の「設計図」を作成するための標準ツールです。

複雑な IS を作成する場合、将来のシステムのモデリングが実行されますが、多くの場合、これは文書を作成せずに非公式に行われます。 ただし、このアプローチには問題が伴います。 まず、概念モデルに関する意見交換は、議論の参加者全員が同じ言語を話す場合にのみ可能です。 第 2 に、テキストベースのプログラミング言語の境界を越えるモデルがなければ、情報システムの特定の側面について洞察を得るのは不可能です。 第三に、コードの作成者が意図したモデルを明示的に実装しなかった場合、転職した場合、この情報は永久に失われます。 せいぜい、実装に基づいて部分的にのみ再作成できます。

UML を使用すると、3 番目の問題が解決されます。明示的なモデルによりコミュニケーションが容易になります。

システム機能には、テキストでモデル化するのが最適なものもあれば、グラフィックでモデル化するのが最適なものもあります。 実際、あらゆる興味深いシステムには、プログラミング言語だけでは表現できない構造が存在します。 UML はグラフィカル言語であり、これを使用すると、特定された問題の 2 番目を解決できます。

UML は単なるグラフィック シンボルのセットではありません。 それぞれの背後には、明確に定義されたセマンティクスがあります。 これは、ある開発者が作成したモデルを、別の開発者、さらにはツール プログラムによっても明確に解釈できることを意味します。 これにより、上に挙げた最初の問題が解決されます。

この文脈では 仕様正確で、明確で、完全なモデルを構築することを意味します。 UML を使用すると、情報システムの開発および展開中に行う必要がある重要な分析、設計、および実装に関する決定をすべて指定できます。

UML はビジュアル デザイン言語であり、これを使用して作成されたモデルは、さまざまな IS プログラミング言語に直接変換できます。

IS を開発する場合、次のような要素が必要になります。

• システム要求;
• アーキテクチャの説明。
• プロジェクト;
• ソース;
• プロジェクト計画。
• テスト;
• プロトタイプ。
• バージョンなど

採用された開発方法論に応じて、一部の作業は他の作業よりも正式に実行されます。 言及されている項目は、単にプロジェクトに提供されるコンポーネントではありません。 これらは、管理や結果の評価に必要であり、また、システムの開発中および展開後のチーム メンバー間のコミュニケーション手段としても必要です。

UML は、システム アーキテクチャとそのすべての詳細を文書化するという問題を解決し、システム要件の策定とテストの定義のための言語を提供し、最終的にはプロジェクトの計画とバージョン管理の段階で作業をモデリングするためのツールを提供します。

UML が使用される場所

UML 言語は主に情報システムの開発を目的としています。 その使用は、次の分野で特に効果的です。

• エンタープライズ規模の情報システム。
• 銀行および金融サービス。
• 電気通信。
• 輸送;
• 防衛産業、航空、宇宙飛行。
• 小売り;
• 医療用電子機器。
• 科学;
• 分散型 Web システム。

UML の範囲はソフトウェア モデリングに限定されません。 その表現力により、たとえば、法的システムにおける文書の流れ、病院における患者サービス システムの構造と機能をモデル化し、ハードウェアを設計することが可能になります。

UML 概念モデル

UML を理解するには、その概念モデルを理解する必要があります。この概念モデルには、言語の基本的な構成要素、それらを組み合わせるルール、および言語全体に共通するいくつかのメカニズムという 3 つのコンポーネントが含まれています。 これらの要素をマスターすると、UML モデルを読んで自分で作成できるようになります。もちろん、最初はそれほど複雑ではありません。 この言語の経験を積むにつれて、より高度な機能の使い方を学ぶことができます。

UML ビルディング ブロック

UML 語彙には、次の 3 種類の構成要素が含まれています。

• エッセンス;
• 関係;
• 図。

エンティティは、モデルの主要な要素である抽象化です。 関係はさまざまなエンティティを結び付けます。 図は、対象となるエンティティのコレクションをグループ化します。

UML には 4 つのタイプのエンティティがあります。

• 構造的;
• 行動的な;
• グループ化。
• 注釈的な。

エンティティは、言語の基本的なオブジェクト指向ブロックです。 彼らの助けを借りて、正しいモデルを作成できます。 構造エンティティには 7 つのタイプがあります。

• クラス
• インターフェース
• 協力
• 使用事例
• アクティブクラス
• 成分
• ノード

これら 7 つの基本要素 (クラス、インターフェイス、コラボレーション、ユース ケース、アクティブ クラス、コンポーネント、ノード) は、UML モデルに含めることができる基本的な構造エンティティです。 これらのエンティティには、アクター、シグナル、ユーティリティ (クラスの種類)、プロセスとスレッド (アクティブなクラスの種類)、アプリケーション、ドキュメント、ファイル、ライブラリ、ページ、テーブル (コンポーネントの種類) など、さまざまな種類があります。

動作的なものは、UML モデルの動的コンポーネントです。 これらは言語の動詞であり、時間と空間におけるモデルの動作を記述します。 動作エンティティには主に 2 つのタイプしかありません。

• 交流
• ステートマシン

これら 2 つのインタラクション要素とオートマトンは、UML モデルに含まれる主要な動作エンティティです。 意味的には、多くの場合、主にクラス、コラボレーション、オブジェクトなどのさまざまな構造要素に関連付けられます。

グループ化エンティティは、UML モデルを構成する部分です。 これらはモデルを分解できるブロックです。 主要なグループ化エンティティは 1 つだけです。 ビニール袋.

パッケージは、UML モデルを編成するために使用できる基本的なグループ化エンティティであり、フレームワーク、モデル、サブシステムなどのパッケージのバリエーションもあります。

注釈エンティティ— UML モデルの説明部分。 これらは、モデルの要素に関する追加の説明、明確化、またはコメントを提供するコメントです。 注釈要素の基本的なタイプは 1 つだけです: 注。 注記は、要素または要素のグループに付けられたコメントまたは制限を表す単なる記号です。 グラフィック的には、メモはテキストまたはグラフィックのコメントを含む湾曲したエッジを持つ長方形として表されます。

UML では、次の 4 種類の関係が定義されています。

• 中毒;
• 協会;
• 一般化。
• 実装。

これらの関係は、UML の基本的な接続構成要素であり、有効なモデルを作成するために使用されます。
ここで説明した 4 つの要素は、UML モデルに含めることができる主なタイプの関係ですが、リファインメント、トレース、包含、拡張 (依存関係用) などのバリエーションもあります。

UML の図は一連の要素をグラフィカルに表現したもので、ほとんどの場合、頂点 (エンティティ) とエッジ (関係) を備えた接続されたグラフとして表されます。 図は、さまざまな視点からシステムを視覚化するために描かれます。 この図は、ある意味、システムの投影の 1 つです。 原則として、最も些細な場合を除いて、図はシステムを構成する要素を凝縮した図を提供します。 同じ要素がすべての図に存在することも、少数の図にのみ存在することも (最も一般的なオプション)、どの図にも存在しないこともあります (非常にまれです)。 理論上、図にはエンティティと関係を任意に組み合わせて含めることができます。 ただし、実際には、情報システムのアーキテクチャを構成する 5 つの最も一般的なタイプに対応する、比較的少数の標準的な組み合わせが使用されます。 したがって、UML には 9 種類の図があります。

• クラス図。
• オブジェクト図。
• ユースケース図。
• シーケンス図。
• 協力図。
• 状態図。
• アクティビティ図。
• コンポーネント図。
• 展開図。

以下は、UML で使用される図の一部のリストです。 ツールを使用すると他の図を生成できますが、リストされている 9 つは実際に最も頻繁に使用される図です。

UML 言語ルール

UML ビルディング ブロックは、相互に任意に組み合わせることができません。 他の言語と同様、UML は、適切にフォーマットされたモデルがどのようなものであるべきかを定義する一連のルールによって特徴付けられます。つまり、意味的に自己一貫性があり、関連付けられているすべてのモデルと調和しています。

UML 言語には、以下を正確かつ明確に定義できるセマンティック ルールがあります。

• 名前、エンティティ、関係、図に与えることができます。
• 範囲(名前が何らかの意味を持つ文脈);
• 可視性(名前が表示され、他の要素で使用できる場合);
• 誠実さ(要素が相互に正しくかつ一貫して関係する方法);
• パフォーマンス(これは、何らかの動的モデルを実行またはシミュレートすることを意味します)。

情報システムの開発中に作成されたモデルは時間の経過とともに進化し、異なるプロジェクト参加者によって異なる時点で異なる見方がされる可能性があります。 このため、適切に設計されたモデルだけでなく、次のようなモデルも作成されます。

• 隠れた要素が含まれています (認識を簡素化するために、多くの要素は示されていません)。
• 不完全（個々の要素が欠落している）。
• 一貫性がありません (モデルの整合性は保証されません)。

システムの詳細がすべて完全に明らかになるまで、開発プロセス中にあまり適切に設計されていないモデルが出現することは避けられません。 UML ルールは、モデルの作業中に重要な分析、設計、実装の問題に対処することを奨励しますが、必須ではありません。その結果、時間の経過とともに適切に定式化されたモデルが得られます。

一般的な UML メカニズム

特定の規則に従うと、構築がより簡単かつ効率的になります。 特定の建築パターンに従うことで、ビクトリア朝やフランス風の建物を設計できます。 同じ原則が UML にも当てはまります。 この言語の操作は、以下にリストされている一般的なメカニズムを一貫して使用することによって非常に容易になります。

• 仕様 (仕様);
• 追加（装飾品）。
• 共通の部門。
• 拡張性メカニズム。

建築

情報システムを可視化し、仕様化し、構築し、文書化するには、さまざまな視点から検討する必要があります。 エンド ユーザー、アナリスト、開発者、システム インテグレーター、テスター、テクニカル ライター、プロジェクト マネージャーなど、プロジェクトに関わる人は皆、それぞれの関心を持っており、構築されるシステムについては、そのライフサイクルのさまざまな時点でそれぞれ異なる見方をします。 システム アーキテクチャはおそらく最も重要な要素であり、考えられるすべての観点を管理するために使用され、ライフ サイクル全体を通じてシステムの反復的かつ漸進的な開発が促進されます。

アーキテクチャは、以下に関する一連の重要な決定です。

• ソフトウェアシステムの構成。
• システムを構成する構造要素とそのインターフェースの選択。
• 他の要素と連携して指定されるこれらの要素の動作。
• これらの構造要素と動作要素をより大きなサブシステムに構成します。
• システムの組織全体を導き、決定するアーキテクチャ スタイル。静的要素と動的要素、そのインターフェイス、連携、およびそれらの組み合わせ方法。

ソフトウェア システムのアーキテクチャには、すべての構造的および動作的側面だけでなく、使用、機能、パフォーマンス、柔軟性、再利用性、完全性、経済的および技術的制限とトレードオフ、および美的問題も含まれます。

先例の視点から見るとユース ケース ビューでは、エンド ユーザー、アナリスト、テスターが観察したシステムの動作を説明するユース ケースをカバーします。 このタイプは、ソフトウェア システムの実際の構成を指定するのではなく、システム アーキテクチャの形成が依存する原動力を指定します。 UML では、このタイプの静的な側面はユース ケース図によって伝えられ、動的な側面はインタラクション、状態、アクション図によって伝えられます。

デザインビュー(デザイン ビュー) は、問題とその解決策の語彙を形成するクラス、インターフェイス、コラボレーションをカバーします。 このビューは主にシステムの機能要件、つまりシステムがエンド ユーザーに提供する必要があるサービスをサポートします。 UML を使用すると、このタイプの静的な側面はクラス図とオブジェクト図によって伝えられ、動的な側面はインタラクション図、状態図、およびアクション図によって伝えることができます。

プロセスビュー(プロセス ビュー) では、システム内の同時実行および同期メカニズムを形成するスレッドとプロセスを取り上げます。 このビューでは、主にシステムのパフォーマンス、スケーラビリティ、およびスループットについて説明します。 UML では、その静的側面と動的側面は、デザイン ビューと同じ図によって視覚化されますが、関連するスレッドとプロセスを表すアクティブ クラスに特別な注意が払われます。

実装ビュー実装ビューでは、最終的なソフトウェア製品の構築とリリースに使用されるコンポーネントとファイルがカバーされます。 このビューは主に、さまざまな方法で組み合わせることができる (ある程度) 独立したコンポーネントとファイルで構成されるシステム バージョンの構成を管理することを目的としています。 UML では、このタイプの静的な側面はコンポーネント図を使用して伝達され、動的側面はインタラクション、状態、アクション図を使用して伝達されます。

展開ビュー展開ビューには、それが実行されるシステムのハードウェア トポロジを形成するノードが含まれます。 これは主に、物理システムを構成する部品の配布、供給、設置に関係します。 その静的な側面は展開図によって説明され、動的な側面はインタラクション、状態、およびアクションの図によって説明されます。

リストされた各タイプは完全に独立していると見なすことができるため、システムの開発に携わる人々は、アーキテクチャの自分たちに直接関係する側面のみの研究に集中できます。 しかし、これらの種は互いに影響し合っていることを忘れてはなりません。 たとえば、展開ビューのノードには、実装ビューで説明されたコンポーネントが含まれており、これらのコンポーネントは、設計ビューとプロセス ビューのクラス、インターフェイス、コラボレーション、およびアクティブ クラスの物理的な実施形態を表します。 UML を使用すると、リストされた 5 つのビューのそれぞれとその相互作用を表示できます。