無料配布
括弧図
UML (統一モデリング言語) は、ソフトウェア システムの成果物を記述、視覚化、構築、文書化するために使用される汎用ビジュアル モデリング言語標準です。
言語のことになると、多くの友人が SQL、Java、C#、PHP などの言語を思い浮かべ、怖がって遠ざけてしまうかもしれません。
さまざまなプログラミング言語
ただし、UML はプログラミング言語ではなく、ビジュアル モデリング言語です。なぜ言語と呼ばれるかというと、UMLはコミュニケーションのための語彙やルールを提供し、その語彙やルールの枠内で垣根なく同じソフトウェアでコミュニケーションを行うことができ、さまざまなユーザが同じことを同じ理解できるようにするためです。
1960 年代後半以降、コンピュータ技術の継続的な普及に伴い、ソフトウェアに対する人々の需要は日に日に増大し、ソフトウェアの規模も拡大し、ソフトウェアの複雑さも増大してきました。科学的な理論的指針が欠如しているため、ソフトウェア開発コストは常に上昇しており、品質を保証できないソフトウェアはさらに悪化しています。ソフトウェアのメンテナンスは非常に面倒な作業になります。人々はこれをはっきりとソフトウェア危機と呼んでいます。
何をするか？その場合、ソフトウェア開発作業はプロジェクトとして実行する必要があります。そこで、ソフトウェアエンジニアリングという概念も登場しました。ソフトウェアエンジニアリングは、ソフトウェア生産の客観的法則を研究し、ソフトウェア生産活動を導くためのソフトウェア生産に関連する概念、原理、方法、技術、およびツールを確立することを目的としています。もちろん結果は満足のいくものでした。
ソフトウェアエンジニアリングに関する人々の研究が継続的に深まるにつれて、オブジェクト指向プログラミングが人々の視野に入ってきました。 1980年代から1990年代初頭にかけて、オブジェクト指向の分析・設計手法が数多く生まれ、オブジェクト指向の手法を紹介する書籍も数多く出版されました。これは、百の学派が争っているような感じがします。各著者は実践者のグループを率いており、その手法には多くの類似点がありますが、微妙な違いもあります。
これは、同じ分野の専門家に同じことについて話すときに混乱をもたらし、異なるオブジェクト指向の表現方法を思いつく可能性があり、同じことの理解とコミュニケーションを著しく妨げます。
このとき、ある方から、統一して同じ基準にしようという提案がありました。誰も彼の呼びかけを聞いていないようで、彼を無視しました。 OMG (Object Management Group) という組織もあり、同様にオブジェクト指向の標準化を試みましたが、すべての方法論者から公開の抗議書を 1 通受け取っただけでした。
Martin Fowler は、著書『UML Essentials: A Concise Guide to the Standard Object Modeling Language』の中でこの状況について語る際、次のようなジョークを飛ばしています。
A: 方法論者とテロリストの違いは何ですか?
B: テロリストは交渉できる。
オブジェクト指向の表現方法には大きな隔たりがある
1995 年の OOPSLA (オブジェクト指向プログラミング システム、言語、およびアプリケーション) 年次会議で、Grady Booch と Jim Rumbaugh は、統合されたアプローチである統一メソッド ドキュメント 0.8 (統一メソッド) を初めて公に説明しました。
さまざまな関係者間の一連のコンテストの後、1997 年 1 月に、すべての組織が他の組織と協力してメソッド標準の提案を提出し、これが初めて統一モデリングと呼ばれる UML ドキュメントのバージョン 1.0 をリリースしました。言語。
競争プロセスの後、OMG はバージョン 1.1 を公式の OMG 標準として採用しました。一連の修正を経て、UML1.4 と UML1.5 は比較的成熟したものになりました。たとえば、Rational Rose 2003 はそのような標準に基づいて開発されました。
多くの人が UML について話すとき、主に作成者の功績は Grady Booch、Ivar Jacobson、Jim Rumbaugh であると考え、彼らを「スリー アミーゴ」と呼びます。
もちろん、初期段階では反対を表明し、彼らが一定の貢献をしたと信じていた人もいたが、後期にはOMG委員会のメンバーが多くの貢献をし、3人の中で貢献したのはジム・ランボーだけだった。後期では。
手法と表現の側面
過去に登場したメソッドと表現に関して、UML はオブジェクト指向メソッドで一般に受け入れられている多くの概念を組み込んでおり、各概念について明確な定義、表現、および関連用語を提供しています。 UML を使用すると、さまざまな既存の方法で確立されたモデルを元の方法よりも適切に記述することができます。
ソフトウェアサイクル
ソフトウェア開発ライフサイクルの観点から見ると、UML にはシームレスな開発要件があります。開発プロセスのさまざまな段階で同じ概念と表現のセットを使用でき、同じモデル内で概念と表現を変換することなくそれらを混合できます。このシームレス性は、反復的で増分的なソフトウェア開発にとって非常に重要です。
応用分野としては
アプリケーション分野に関しては、UML は、大規模、複雑、リアルタイム、分散型、集中型のデータまたはコンピューティング、組み込みシステムなどを含むさまざまな分野のモデリングに適しています。
プログラミング言語と開発プラットフォーム
実装プログラミング言語と開発プラットフォームに関しては、UML はさまざまな異なるプログラミング実装言語と開発プラットフォームを実行するシステムに適用できます。
開発プロセス
開発プロセスに関して言えば、UML はモデリング言語であり、開発プロセスの詳細を記述するツールではありません。汎用プログラミング言語と同様に、さまざまなスタイルのプログラミングが可能です。
内部の概念的な側面
内部概念に関して、UML はさまざまな概念間の内部接続を明らかにし、表現することに特別な注意を払っています。既知および未知の状況に適用される複数の方法でモデリングの概念を把握しようとするプロセスにより、概念とその適用可能性についての理解が深まります。これは、さまざまな規格を統一するという本来の目的ではありませんが、さまざまな規格を統一したことによる最も重要な成果の 1 つです。
UML の構成は、次の図を使用して説明できます。
UML の基本的な構成要素とグラフィックの分類
現在、UML の最新バージョンは UML バージョン 2.5 まで発展しており、図の数は 9 から 13 に増加しています。 UML 自体の複雑さはソフトウェア モデリング自体を超えるのではないかと考える人もいます。
以上がUML の基本的な紹介です。ソフトウェア エンジニアリングにおいて不可欠なモデリング言語として、UML の開発の歴史は、ソフトウェア設計概念の進歩を目撃するだけでなく、チームのコミュニケーションの促進、システム設計の最適化、開発プロセスの加速における UML の役割も強調しています。 . 重要な役割。この記事の基本的な紹介を通じて、UML の歴史的背景を深く理解できるだけでなく、要件分析、システム設計、文書化における UML の広範な応用を習得できると思います。
関連記事:
無料オンライン協力マインドマップとフローチャート 
