最終的な実装言語がC#で、設計を検討する場合、設計資料の作成にUMLを使うと表現が少々難しい事あります。Javaのコンテキストには無いC#固有の文を扱う時にどうやって書けばいいのかわからない構文がいくつかあるので表現方法をどうするか考えてみました。
プロパティ構文
setter/getter両方ともアクセス修飾子が同じ場合は簡単です。実際のコードで
public string Str { get; set; }
こんな風に表現したいなら以下のように<
setter/getterでアクセスレベルが異なる場合、どうしようも無いのでオレオレ制約を記載します。意図するコードが
public string Str { get; private set; }
の時は、
上記のようにします。間違ってもJava風にsetter/getterを記述すると、作業者が自分じゃない限り100%そのまま実装されてしまいます。
プロパティ構文を期待しているのにこんな風にUMLを書いておくと以下のコードになって成果物に反映されます。よく見ないでもc#の標準のコーディング規約でないメソッド名だしワケワカメになったりします。
private string Str; public void setStr(string str) { this. Str = str; } public string getStr() { return this.Str; }
デリゲート
c#はデリゲートがインターフェースのメンバーでもなんでもなく、普通に型として使えるので他人に資料ベースで指示を出すときに少し困ります。関数ポインタにも全く同じことが言えると思います。
// デリゲートの宣言 delegate void SystemEvent(object sender, EventArgs e); // 実際の利用個所 public void Hoge(SystemEvent callback) { (中略) }
重要なのは結局、「型」なので、デリゲート宣言自体をクラスで扱うのがいいと思います。
普通に宣言すると、只のクラスになってしまうのでステレオタイプでこれはデリゲートですよーと識別してもらいます。
イベント
イベントとかもUMLで記述方法が不明です。間違ってもJava風にインターフェースを継承したオブザーバーみたいな形式で記述するのだけは間違いです。なぜなら最終的な実装がUMLの通りに実装される可能性が高いので、c#固有の文でそれっぽく書く必要があります。これも、イベントもデリゲートと同じくステレオタイプで指示します。
public event SystemEvent Elapsed;
まとめ
普通に開発するときに実装に近いUMLなんて書くほうが無駄だと思いますが、自動コード生成だとかプロセスで決まっているときには少し困るで書いてみました。