少し間が空いたが、ここからは、次の記事までの時間がかかる領域に入る。
これまでのところで、Webアプリケーションやスマホアプリケーションなど、クライアントとサーバーに分離しつつ、全体で統合された動きを期待する場合の、UIを司るクライアントサイドでの設計内容記述を、一般的なクラス図から拡張子、バインディングやイベント監視といった特有の機能や、あるいは役割よりも手順を記述したり、UIの要素を分離するなどの詳細化をおこなうことで、1つのダイアグラムにより多くの情報を含めることを意図した記述方法を検討してきた。
引き続いてこれまでに記述してきたようなダイアグラム上で、フレームワークの機能と実装すべき機能の分離を明確に記述することを目標に記述方法を検討する。ある特定の機能について、当然ながら、まずは次のような分類ができる。
- A: フレームワークに頼らず全て実装する
- B: フレームワークに一部頼って実装する
- C: 全機能をフレームワークに頼る
Bについては、当然ながら、割合や実装手段としてファンクションコールなのか、コールバックなのかなど様々なパターンが考えられる。Cについては、例えば、設定や指定されたメソッドの組み込みにより、本来の処理の流れの中には明示的に記述されない物も含めることにする。したがって、「何も書かない」わけではなく、何かを書くものの、その機能が必要とされる段階では何も記述しない、あるいはそれに等しいような機能を指すことにする。
まずは、これらABCを次のような記法で記述することにする。
フレームワーク機能については、ステレオタイプの<<framework>>を付与することにする。Bについては、コールバックの場合はフレームワーク機能への矢印は逆になる。また、Bについては、Proc1′ + feature1 = Proc1になり、Cについてはfeature1とProc1での結果が同一であることが期待される。
こうしたルールのもと、フレームワークの機能を１つのモジュール的に示して、設計の上でどのようにフレームワークの機能を利用するのかを明示的に示す方針のもと、いくつかサンプルとしての設計を進めてみることにする。