UMLモデリングセマンティクス
UMLを使用したMDDに関するモデリング手法に関する今日の講義で、講師は、作成する各図のセマンティクスについて（おそらく）テキストで説明することが絶対に必要であると述べました。
私の意見では、UMLによってすでに標準化されているダイアグラム要素のセマンティクスを説明する必要はありません。何らかの理由でステレオタイプ/タグ付きの値で標準UMLを拡張する場合は、完全に適切であることがわかります。
対照的に、標準化は、通常の場合、セマンティクスを毎回説明する必要なしに、人々に図について推論して話させることを意図していると思います。もちろん、唯一の前提条件は、それらがすべて同じUML仕様に依存していることです。
MDDに関するもう1つのポイントは、同じダイアグラムの種類に対して時々異なるセマンティクスを使用すると、コード生成と自動モデル変換が最終的に困難になることです。
- 私はこの概念で正しいですか？
- UMLをより一般的に使用できるようにするために、UMLに固有の解釈のあいまいさがありますか？
私の意見では、UMLによってすでに標準化されているダイアグラム要素のセマンティクスを説明する必要はありません。
はい。UML標準のどこかでセマンティクスが適切に定義されている場合、ダイアグラム要素のセマンティクスを説明する必要はありません。問題は、特にMDDの場合、完全なセマンティクスはこれらの要素のコード生成に依存し、UMLからコードへのマッピングに広く受け入れられている標準がないため、[〜＃〜] uml [〜＃〜]標準は単純にセマンティクス全体を定義しないその要素に対して。実際、 標準の「UMLセマンティクス」段落 でさえ、主にUML構文を扱い、セマンティクスについて非常に非公式な概念しか提供していません。
もちろん、MDDを実行していて、コードジェネレーターを配置している場合は、メタディスクリプションを1回だけ作成して、それぞれに同じ説明を展開する代わりに、どのセマンティクスがあなた/あなたのチーム/プロジェクト/会社に適用されるかを伝えることができます。何度も何度も図。
ここに科学論文があります UMLセマンティクスがほとんど非公式であるという問題を扱っています。 「umlセマンティックルール」をグーグル検索すると、そのトピックを詳細に説明する論文がさらに表示されます。
ステレオタイプは明示的な説明を必要としないはずです（何らかの理由でカスタムステレオタイプを使用している場合は、ステレオタイプが定義されている場所を除きます）。それはステレオタイプを使用することのポイントです。ソフトウェアが単なるステレオタイプの調整であるということはめったにないので、それは通常、物事を説明することを避けることができるという意味ではありません。 IDの発行や計算の実行など、何か面白いことをする部分についての説明も、他の場所での複雑さを大幅に軽減できます。人間が読める言語のテキストは、それを説明する唯一の方法ではないことに注意してください。何をしているのかによっては、数式、オントロジーからのセマンティックアノテーション、または適切な学術論文へのリンクがより適している場合があります。それはすべて異なります。
UMLと適切なコード生成を使用して、実質的にプログラム全体を作成することができます。 mediumサイズのプログラムを記述するために必要なダイアグラムのサイズの複雑さを管理することの難しさは、グラフィックデザインモデルを利用するため、実際にはそれをしたくないでしょう。 UMLのようにかなり実用的ではありません。 UMLはアーキテクチャーに適しています。実際の目的はプログラマーに示され、プログラマーが全体像を理解できるようにすることですが、詳細な作業にはあまり適していません。 （すべてを拡張すると、UMLレベルでのmyプログラムの複雑さを考えると震えます…）
講師のポイントは、コメントがUMLが表すものを何度も教えるべきだということではないと思います。代わりに、私はあなたの質問を次の特別な場合として解釈します：コードにコメントする必要がありますか？はいの場合、どのように？。
通常の論争は、プロダクション（コードまたはUML）が自己文書化されているためコメントが不要かどうか、コメントが実際にプロダクションに何らかの価値を追加するかどうか、コメントがプロダクションと一貫性を保つかどうかについてです。