UML を使用したモデルの構造と動作、および 2 つの関係についていくつか質問がありました。
- 構造と動作の関係の仕様または理解に関して、UML の制限を見つけましたか?
- UML を使用して、構造と動作の関係を最適化する方法について、実用的なアイデアをお持ちではないかと思っていました。
- この関係をよりよく理解したり、より簡単に表現したりするのに役立つ UML ツールを知っていますか?
ありがとう
UML を使用したモデルの構造と動作、および 2 つの関係についていくつか質問がありました。
ありがとう
はい:
シーケンス図は、トランザクションにいくつかのコンポーネントがどのように関係するかを示す、高レベルで読みやすいものです。しかし、詳細なレベルでは良くありません (判読できません)。トランザクションが何十ものメソッドを含む方法を示しています (メソッド A がメソッド B を呼び出し、メソッド D と E からデータを取得し、次にメソッド F を呼び出すなど)。
クラス図を見ると、いくつかのサブクラスを持つベース クラスが表示される場合があります。これは、クラスの動作についてほとんど何も伝えません (共通の動作、または少なくとも共通の API と、各サブクラスに固有の個別の動作がある可能性があることのみを示します)。
それは大きな問題です。簡単な答えは、「オブジェクトにテキスト ノートを添付します。図は、説明テキストなしでは十分ではありません」です。
いいえ、そうではありません。UML ツールを使用すると、UML 図を作成 (および図からコードを生成) できますが、それをどのように使用するかはユーザー次第です。Real-Time Object-Oriented Modeling (1994)というタイトルの書籍で説明されている、実行可能なモデル、つまりモデル自体が動作する優れた製品がありましたが、そのような UML ツールを私は知りません。私が知っている最も近いものは、モデルとコードの間を「往復」できることです (つまり、モデルからコードを生成し、コードからモデルを生成します)。
melculetz に対する UML の有用性に関しては、状況が変わったと思います。
Visual Studio 2010 では、複合クラスを生成する関連関係を定義できます。多重度とクラス修飾子を指定できます。モデルからクラスを生成することもできます。
現在、ステート マシン オブジェクトのメソッドを視覚的に定義するために、システムのフェーズを視覚的にモデル化しようとしています。それが、構造と行動を統合しようとする私の試みです。ブログをチェックして、私がどのように上達しているかを確認してください。Class Analyzer は、クラス オブジェクトの動作を視覚的に表現します。制限が解除されました。
その答えは、開発方法を MDA に向けることだと思います。より多くのクラスを生成できますが、見返りは管理のしやすさと再利用 (努力をテンプレート化する場所) の点にあります。
私はまだ自分のモデルに取り組んでいますが、VS2010 は開発プロセスを管理するための優れたツールであると確信しています。UI モデリングについてはまだ調査していませんが、噂は聞いています。すべてが間違っているかもしれませんが、Lightswitch を使用することで、UI もモデル化できると思います。
宿題の問題のようですね。Wikiは UML のすべてを教えてくれます。
UML の制限は、あらゆる形式の通信と同じです。言葉がシンプルになればなるほど、伝えられることが少なくなり、コミュニケーションがより明確になります。四角や丸などの形は構造を表し、線は関係性を表し、矢印は動きや流れを表します。方向、太さ、色、数、さまざまな形状など、他のプロパティの意味を定義することで、これを強化できます。オーディオやビデオ、モーション、ツールチップなどのマルチメディア レイヤーを組み込むこともできますが、UML についてはもう話していません。
私のお気に入りの UML ツールは、ホワイトボードとドライ イレース マーカーです。
UML では、メソッドのシグネチャを指定し、メソッドをクラスにグループ化できますが、実装として使用するコードについては何も述べていません。それが「振る舞い」の意味であるなら、UMLはクラスレベルでそれをまったく扱っていないと思います。
UI レベルではさらに悪化します。UML に対する私の印象は、UI を指定するにはひどく不十分だということです。
すべてを UML に埋め込むのに必要な労力は、アプリケーションをコーディングするのと同じかそれ以上の労力が必要だと思います。UML ツールの追加の負担は貧弱な IDE であり、単体テストでできる方法で UML の正確性を証明できないことです。
UMLは売り過ぎです、IMO。これは、開発者間の非公式なコミュニケーションに便利な表記法であり、それ以上のものではないと考えています。これは、エンジニアリング図面に相当するオブジェクト指向のものではありませんでした。