www.uml.org からの画像この
記事は、UMLと現時点でのそのアプリケーションの特性に特化しています。歴史的な情報はほとんどなく、主なポイントだけです：
- UMLは、オブジェクト指向モデリング言語の作成に取り組んだ結果、90年代に生まれました。
- 仕様1.0は1997年にリリースされました。
- 仕様2.0は2005年にリリースされました。
- 現在まで、UML 2.5では、SysMLやSoaMLなど、いくつかのプロファイルが進化しています。
UMLが現在および現在どのように適用されているかを見て、それについて考えると、次の結論を導き出すことができます。UMLのバージョンは2.5になりましたが、言語の使用の原則は最初のバージョンから変更されていません。
その結果、アナリストは、20年以上前に制定されたソフトウェアシステムを説明するという概念を使用します。コンセプト自体は優れていますが、アプリケーションの場所とコンテキストに関連付ける必要があります。
このUMLアプリケーションの分析を続行し、それを現在の時間の要件とも関連付けると、結論は次のようになります。
- UMLを使用するすべての方法は、ユースケース駆動開発を「回避」します。
- UMLモデルは整合性に欠けています。構造と動作、ビジネスレベル、アプリケーションレベルの側面を個別に説明するという選択されたアプローチは、モデル全体の認識を複雑にします。
- UMLはオブジェクト指向言語であるため、他の概念を表現することは困難です。
ユースケース駆動型開発アプローチについては何も言いませんが、その具体化の1つはRational Unified Processです。次に、最後の2つのポイントについてお話します。
プレゼンテーションの側面
UMLは多くの図で構成されています。それぞれが独自のルールに従い、独自の理解で要素と矢印を使用します。また、外部からは統一された言語のように見えませんが、さまざまな表現のセットとして表示されます。これは、さまざまな視点から主題領域を見る機会としてしばしば提示されます。同じ成功を収めたスイスナイフは、基本的にブレード、スクリュードライバー、栓抜き、スプーン、フォーク、およびこれらすべてを1つのハンドルで構成されたセットである統合ツールと呼ぶことができます。
アナリストがすべての図を1つのモデルに収めようとすると、どうなりますか？彼はハイブリッドチャートとリンクテーブルの作成を開始します。結果は単一のモデルではなく、ダイアグラムとテーブルが追加された一連のダイアグラムです。
プレゼンテーションレベル
ビジネスアナリストが、UMLダイアグラムを使用してサブジェクトエリアを記述したとします。そして今、システムアナリストまたは同じアナリストは、ソフトウェアシステムのモデルを形成する必要があります。アナリストがUMLに集中している場合、彼は以前に作成されたものに対応するビューを作成し始めますが、すでにシステムのフレームワーク内にあります。これは、同様の図の形式で再度表示されます。
また、分析者は、サブジェクトエリアの説明とシステムのモデルを比較したい場合はどうしますか？
彼は、ハイブリッドダイアグラムの作成、テーブルのリンク、トレースを再度開始します。
その結果、再び多くのチャートとテーブルができました。
UMLは古い言語であり、膨大な数の本と古い例が存在することにまだ注意が必要です。これは主に、自動化されていないビジネスから自動化されたビジネスへの移行のケースを説明しています。そしてアナリストはこれらの例から学びます。しかし今日、情報技術は至る所に浸透しています。企業ごとのITから離れたアプローチは受け入れられません。
サービス指向のアプローチ
UMLはオブジェクト指向言語であるため、他の概念を表現することは困難です。たとえば、サービス指向。UML標準プロファイルには「サービス」の概念はありませんが、サービス指向アーキテクチャモデリング言語として宣伝されているSoaMLプロファイルがあります。
サービス指向アプローチについて簡単に説明し、SoaMLがそのモデリングに適さない理由をさらに理解します。TOGAFの定義の解釈に基づく。
サービス指向のアプローチを簡単に形式化するには、2つの抽象化が必要です。
- プロセスは、サービス間の/サービス間の制御フローです。プロセスは、特定の結果を一緒に達成する一連のアクションであるとも言わなければなりません。
- サービス -サブジェクトまたは他のサービスからの要求に応答して特定の機能を提供する動作の要素。サービスは機能を提供またはサポートし、明示的に定義されたインターフェースを持ち、明示的に制御されます。
これがSoaMLでどのようにモデル化されているかを見てみましょう。同時に、UMLのオブジェクト指向モデリングとSoaMLのサービス指向モデリングの違いを比較します。
男と店
目的：店舗で商品を購入するモデルを説明します。
オブジェクト指向のアプローチは、誰にとっても明確でシンプルだと思います。時間を無駄にしないために、ビジネスレベルは考慮しません。私は誰でも頭の中で、アドバイス図のユースケースとその詳細をアクティビティ図またはシーケンス図の形で想像できると思います。
人はユーザーとしてではなく、対話の当事者の1人として行動します。では、仕様に厳密に従って、
SoaMLを使用してこの問題を解決しましょう。 この図では、相互作用する人々のコミュニティを定義しています。これはストアとパーソンです。 私たちは、ストアが「売り手」として機能し、個人が「購入者」として機能する、それらの間のビジネスプロセス「商品の販売」を決定します。
ビジネスプロセスに基づいて、次のビジネスサービスを識別できるようになりました。SoaMLでは、ServiceContract分類子がこれに使用されます。
このサービスのフレームワーク内では、売り手はプロバイダーとして働き、買い手はコンシューマーとして働きます。
サプライヤーとしての売り手は、1つの「売り」操作を提供します。ビジネス分析が終わり、システムレベルに移行します。
製品を販売するためのビジネスプロセスの更新バージョンをシステムレベルでモデル化する必要があります。このため、私はシーケンス図を選択しましたが、他の任意の動作図を使用できます。
更新されたビジネスプロセスから、1つの操作「販売」を選び出し、それを「販売方法を知っている人」という基本的なインターフェースに配置します。
次に、サービスの実装に使用されるサービスインターフェイスについて説明する必要があります。
次のサービスインターフェースを取得します。
- 「販売可能」というインターフェースから継承された「販売意欲」。
- 「購入する必要があります」。これは、「販売できる」インターフェースに依存します。
これで、ターゲットサービスモデルを複合構造図として表すことができます。
UMLでのオブジェクト指向モデリングとSoaMLでのサービス指向モデリングの結果を比較してみましょう。
視覚的には、全体の違いは、コンポーネントの境界にあるこれらの小さな正方形にあります。赤でマークしました。それだけが違いますか？
オブジェクト指向のモデリングとサービス指向のモデリングには本当に違いがあります。それは、SoaMLがすべてをオブジェクトに削減したということだけです。しかし、その詳細については後で説明します。
次に、より複雑なケースでのSoaMLの検討を終了し、おおよそ次のスキームを取得します。
私の意見では、SoaMLの何が問題になっていますか。
第一に：繰り返しになりますが、言語の整合性と、ビジネスのレベルとアプリケーションのレベルの間の接続の問題については、すべてが相互に関連していることがいかに難しいかがわかりました。
2番目：サービスは構造オブジェクトとして記述されますが、これは良くありません。ロシア語のスピーチでは、「プロバイダーがサービスを表す」というフレーズが一般的です。これは、SoaMLで実装されるコンポーネント指向のアプローチです。しかし、サービス指向のパラダイムの場合、「サプライヤーがサービスを提供する」と言った方が正しいでしょう。 「サービス」をロシア語に異なる方法で翻訳すると、「サプライヤがサービスを提供する」ということで、すべてがすぐに適切なものになります。この観点から見ると、「サービス」は「オブジェクト」ではなく「動作」です。
第三に：サービス指向アーキテクチャーに関するスライドでは、プロセスとサービスという2つの抽象化について説明しました。オブジェクト指向アプローチのレンズを通してそれらを表示して説明することは、穏やかに言えば、ストレスの多い作業です。
パラダイム
UMLに戻る。UMLは、そのパラダイムを通じて他のパラダイムを記述しようとします。
そして、すべてがコンポーネント指向のパラダイムでうまくいった場合、それはオブジェクト指向のものの論理的な継続として提示できます。サービス指向のものはうまくいきませんでした。
この場合、1つのパラダイムを別の不幸なアイデアで表現します。
「Person and Store」問題の例を使用して、SoaMLでこのような概念を使用する方法を示しました。
以下に示すように、パラダイムとの関連性が高くなります。
サービス指向モデリングがオブジェクト指向とどのように異なるかを示します。
人と犬
目的：相互作用モデルを説明する-人は犬と一緒に歩きます。
技術学部の学生はおそらくこの問題をためらうことなく解決するでしょう。関連する専門分野の学校や大学では、オブジェクト指向プログラミングが必須です。オブジェクト指向のアプローチを以下に示します。
サービス指向モデルはどのように見えますか？学生がそのような質問に答えるかどうかはわかりません。
これは私が受け取りたいものです。（自分のために少し考えてから、見てください）
, . - . () () «».
, . - . () () «».
オブジェクト指向プログラミングの歴史を思い出すことができます。登場当初、エズガーダイクストラやニクラウスワースなど、非常に権威ある人々でさえ懐疑的でした。そして今日に至るまで、一部の人々はOOPは注目に値しないと考えています。
まあ、このモデルも笑顔を引き起こす可能性があります。実際のところ、サービス指向のパラダイムでは、プログラミングと設計の初期レベルでは十分なサポートがありません。プログラマーの場合、サポートはJava Enterprise EditionやSpringなどのフレームワークによってのみ提供されます。プログラマは、オブジェクト指向アプローチ用にすでにフォーマットされたヘッドでそれらに到達すると思います。
アナリストは、サービス指向のアーキテクチャとデザインの理解を、それが何であるかを異なる方法で理解しているインターネット上の記事に基づいており、詳細や技術的な詳細に深く掘り下げていない記事は、一般的にあいまいです。その結果、アナリストは、システムとユーザーの間で一般的に受け入れられているユースケースに戻ります。また、システムのアーキテクチャとそのコンポーネントの構成は、アーキテクトによってすでに固定されているか、選択したプラットフォームによって決定されることもよくあります。そしてアナリストは再び、システムとユーザーの間のユースケースを簡単に説明します。
オブジェクト指向のアプローチと、人が犬を「歩く」サービスにレンダリングする、この一見馬鹿げたアプローチを比較してください。面白くなくても、人間が「ウォーク」メソッドを実装するオブジェクト指向のアプローチは、面白そうに見えるでしょう。犬が出される入口!!! 次に、サービス指向のパラダイムを理解しました。
これらのパラダイムは完全に互換性があることに注意してください。人はまだ彼の通常の行動をすることができます：眠り、踊り、犬は吠えます。
もう1つのポイント：この例では、新しい概念「サービス」を導入しました。ただし、その使用規則はまだ明確に定義していませんが、SoaMLとは異なります。このような拡張機能はメタモデリングに関連しているため、ここで注意する必要があります。これに夢中にならないでください。作成されたモデルが矛盾して不明瞭になる場合があります。
結論の代わりに
- UML . , . .
- . , . .
- UML . , . , UML, .