Separation of concernsについて

Separation of concerns という言葉があります。 Wikipediaでは次のようになっています。

  1. Separation of concerns

複雑な系を分割し扱いやすくするための手法かもしれません。 しかし Concerns の種類はどの程度が良いのでしょうか? RM-ODP (5)、RUP (4+1=5)、UMLのダイアグラム(14種類)、Federal Enterprise Architecture の Perspectives の数(5)、と5という数字が多い(マジックナンバー?)のですが、下は静的と動的(または構造と振る舞い)の2から上はUMLの14あたりまで行くのかもしれません。

先日このような話をネタにしてちょっと発表をしてきました。 Separation of concerns で対象物を幾つかの Concerns に対応する記述に分割したとします。 これらは独立しているようですが、所詮は同じものを別の角度から見ただけのものですから、相関があります。 例えば、建造物を作る際の設計図ですが、正面図/平面図/側面図と3方向から見た図を書きます。 建造物の屋根のてっぺんを想像すると、正面図では一番上、側面図でも一番上、平面図だと上から見たところなので図面の表面にあたる部分、というようにつながり(相関)があり、これを認識しないと建てられないのではないかと思います。 ITシステムの場合でも、記述物の間の相関を何らかの形で表現して全体としての整合性を示す必要があります。 この時に、例えばビジネスに関する関心事に基づいて仕様(モデル)を書こうとすると、実は世の中に何種類もの標準があり、ビジネスモデルには何種類ものモデリング言語が含まれる可能性があることが分かります。 ビジネスプロセスのBPMNもその一つですし、SoaMLもそうかもしれませんし、Business Motivation Modelも入ると思います。 発表の結論は次のようにしました。

  1. 一つのConcernに対応した仕様の中に複数のモデリング言語を使うことは避けられない。その仕様の中での整合性を確保するのは仕様記述者の責任として、その仕様の一部として多くの内部相関記述は含めないようにする(使用するモデリング言語の数が増えると対応出来なくなるため)
  2. 相関記述にはUMLを使う。非UML言語の場合、最適なUMLとの対応付けを模索するか、無理な場合にはコメント(Annotation)で関連付けする。

これは前に進めるための中途半端な結論ではありますが、結論より問題意識を共有したかったということです。

今度発表の機会があれば何かデモ出来るものにしたいと思っています。 やはり分かり易いものでないと、聞く側も話す側も疲れますから。

Separation of concernsについて

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中