問題タブ [mda]

簡略化されたクラス図のメタモデルはどこにありますか? ATL ATLAS Transformation Language プロジェクト用です。エンティティ クラス図を SQL データベースに変換する必要があります。ありがとうございました 。

別の Ecore モデルで EMF-Ecore モデル コンポーネントを再利用する方法はありますか?

MDA についていくつか質問したいことがあります。

まず、ある言語でコードを記述し、そのコードを別の言語で生成できるツールが存在することを知っています。異なるプラットフォーム用のコード。これらの変換は MDA と見なされますか、それとも別のものですか?

MDA を使用するとコードの一部が自動的に生成されることを除いて、プログラマーの生産性を向上させる他の理由はありますか?

従来の開発と比較して、MDA に切り替える価値はありますか (すぐに)、それは実際に可能ですか?

PIMの作成にはEAを使用しています。Javaコードを直接生成すると、必要な場所で正しいデータ型が得られます-関連付けプロパティに修飾子を設定するマップは、マップになることを理解しています。そして、それは期待どおりに機能します。ただし、MDA 変換と生成コードを実行すると、プロパティは List に変換されます (これは悪いことです) バグ セッターとゲッター メソッドは、次の例のように Map を使用し続けます。

Java のデフォルトの変換パッケージを使用しています。コネクタの Java 変換に次の行を追加しようとしましたが、ソース セクションです

しかし、それは役に立たないようです

奇妙に聞こえるかもしれませんが、PSM から PIM へ、または同様の概念で MDA の逆プロセスを作成する必要があります。XML メッセージの作成を担当する C# パッケージがあります。すべての開発が C# で行われ、コンポーネントが再利用されたため、正常に動作することがわかるまで。しかし、現在、さまざまなプラットフォームでの開発を開始しており、最初に特定のコントラクト (XSD スキーマ) を指定したいと考えています。そこで、現在のパッケージをリバース エンジニアリングして、xsd を生成しようとしました。しかし、解決する必要があるいくつかの問題が発生しました。

• C# コレクション クラスのリレーションへの変換
• 内部クラスをパッケージに移動
• C# プロパティを属性に変換する
• C#辞書をどのようにモデル化すればよいかよくわかりません

そのプロセスが理想からかけ離れており、反対方向に進むべきであることは承知していますが、少なくとも現時点ではほとんど反対することはできません.

ヒントをいただければ幸いです。ありがとう

何らかの形で変換テンプレート (CDT) 内の文字列を照合して解析することは可能ですか?

私は文字列を持っています：辞書と私は必要になります：1）文字列が辞書キーワードで始まることを検出します2）2番目のパラメータを抽出します-> Shift

変換中に内部クラスを通常のクラスに変換する可能性はありますか?

クラスは、ラッパー クラスと同じパッケージ内にある必要があります。

どうも

文献でこの段落を見つけましたが、意味がわかりませんでした

設計の実践は、開発ライフ サイクルに沿って作業を強力に分割する従来のコード ベースのエンジニアリングから、設計フロー内のすべての人がモデルについて発言できるモデル駆動型のエンジニアリング アプローチに移行しています。

どんな助けでも大歓迎です

EMF Ecore を使用して作成されたメタモデル内で独自のデータ型を定義するにはどうすればよいでしょうか?

目標は、多くの属性を含むクラスを持つことです。各属性には 1 つのデータ型があります。

私が今直面している問題は、プロパティ ビュー (Eclipse EMF) で [メタモデルに準拠するモデルで] 属性データ型を設定したいときに、空のリストが表示されることです。

EAttribute を追加するときと同様のものが必要です。異なる Etype (EString、EBoolean など) から選択できます。

助けていただければ幸いです。

ありがとうございました。

私は、趣味とベスト プラクティスの演習として、Python と C# の両方で同じドメイン モデル (ISO 191xx 規格と OGC 抽象モデルに触発された単純な GPS/GIS ライブラリ) を実装しています。

最初に、「まあ、ISO/OGC は完成した UML をくれたので、C# と Python の各クラスに同じ署名を持たせるつもりだ」と考えました。

Python のメソッド シグネチャを当てにできないため、「strict/static vs ダック タイピング」の問題にすぐに行き詰まりました。例えば：

• コンストラクターのオーバーロードは、C# では非常に一般的で自然ですが、Python では*args **kwargsand 条件に頼る必要があります。
• プロパティは C# で推奨されていますが、Python で見たほとんどのソース コードはフィールドを直接設定する傾向がありますが、@propertyorの使用property()は非常に簡単です。
• （等々）。

実際、ある言語と他の言語の間には (明らかに) 明白で非常によく文書化された「考え方の違い」があり、それらの違いを尊重しながら、同時に「同じ」アプリケーション、つまり同等のアプリケーションに行き着きたいと思います。ドメイン モデル、アーキテクチャ、および機能。

だから私の質問は基本的に次のとおりです。

Python と C# で同じ抽象モデル ("UML のような") を実装する場合、どのように進めればよいでしょうか。具体的には、どの構造を不変にする必要があり、どれを異なるものにする必要がありますか?