ITSSのITAで昨年宿題とした、EAについて考慮する作業をしているのですが
#エンタープライズはソリューションをコンポジットしたものという結論になりそうですが
RUPの4+1ビューで考えた場合、従来のユースケースの上位概念(もしかするとシステムユースケースビューの上位かも)として、ビジネスユースケースビューを定義し
#EUPでは、エンタープライズビジネスとしている
ビジネスアーキテクチャを登場させて、このレイヤをEAにしてはどうかとみたいなことを考察するに当たって、ビジネスユースケースについて検索していたら、
ガイドライン8 : エンティティクラスの属性についてコード設計しない
エンティティクラスの属性の値をコード化するような「コード設計」は、この分析ではまだ行ってはいけません。コード設計とは、たとえば性別の「男」を 0 に、「女」を 1 に割り当てるような作業です。それはソフトウェアアーキテクチャと設計で決定することで、論理的なシステムを検討する上では必要のないことです。古いホストのシステムでは、ユーザが利用する端末にラジオボタンもリストボックスも表示する能力がないので、意味を選択させるのではなく、上記のようなコードを入力させていることがあります。このようなシステムを再構築するケースで、早期にコード設計をしようとしてしまう傾向があります。ですが、そのようなアプローチで再構築したシステムというのは、GUI になっても依然としてユーザにコードの入力を強いるようなユーザビリティが低いシステムで、カプセル化が適切に行われていない設計をしてしまいがちです。
という記事が検索で引っかかったのですが、私の少ない経験上、コードを入力することは、ユーザビリティを良くするケースのほうが多い。
ユーザは部品コードとか仕分けコードを記憶していて、GUI部品で選択するより早い。新コード体系を導入するにしても、慣れてくるとコードで入力したいと要求される。これまでの連載に関心をもって読みましたが、このことで興ざめしました。さらにいえば、この例は再構築としているが、多くの企業では、コード設計は他のシステムで行われていて、いやでもコードを意識しなければならないはず。
『「コード設計」は、この分析ではまだ行ってはいけません。』
ってどんな開発だろう。
前編を読み返してみると、表記法はビジネスユースケースですが、コンテキストは従来のユースケースでした。書かれた方に他意はないですが、残念です。
ほかにもつっこみどろ満載なんですが、ここだけはあんまりだなと思いつつも、古い記事にいまさら、コメントをつけるまでもないと思い、ここに書いてみました。