今日のつぶやき - goldenportのブログ

モデリングしているとusecaseが要だなぁとつくづく感じる。(domain modelが基本という前提の上で) #

UX方面ではpersonaやpaper prototyping、agile方面ではuser storyや(FDDの)featureもあるけど、要求とシステムをつなぐというポジションではuse caseの塩梅がよい。 #

use caseは(いわゆる)system usecaseも重要だけど、business usecaseとsystem usecase(場合によってはcomponent usecase)の階層構造の利用価値が高い。 #

business usecase→system usecaseのラインで、業務フローとシステム機能の結合を補強する。 #

usecaseのモデル上の位置付けは、collaborationを抽象化したもの(逆にusecaseを具象化するとcollaborationになる)なので、message passingが基本となるクラウド・アプリケーションとは本質的に相性がよいはず。 #

クラウド・アプリケーションの要求モデルもuse caseを基本に考えたい。PIM→PSMへの落し込みではusecase/collaborationをservice/service busアーキテクチャにどのように落としこむかといったあたり。 #

use caseをモデルリソースのハブとして使用する考え方はクラウド時代でも有効。use caseごとのエンティティのアクセス・パターンを明確にすることで、DKVS上での物理データ設計に必要な情報を整理できる。 #

要求モデルと設計モデルのルートをuse caseに統一すると決めれば、UX方面のモデル、Agile方面のモデルをuse caseのハブに接続して統合するというアプローチも考えられる。各種の要求モデルは適材適所で使用して、use caseで本線に集約する。 #

現在のuse caseの運用はUI方面が厚くて、クラウド時代に重要なモデルとなると予想される状態機械方面が弱い。UI方面はUX方面の技術に置き換わることになると思われることもあり、use caseの運用は状態機械方向にシフトした方がよいだろう。 #

UX→system usecase、business usecase(with　business flow)→system usecaseという2つの流れを基本線に、必要に応じてagaile方面の技術と併用するというようなプロセス・アーキテクチャが面白そう。 #

RT @nsharp_2ch: NoSQL Databasesの分類は4つが一般的？column-oriented、document-oriented、key-value、その他。 #

RT @tsurezure_bot: 全てが予想不可能だと諦めてしまえば、もっともらしく、間違いもない。bit.ly/3Ru49u #

Azureの場合、データ処理はWCF Entity Framework, SQL Server Modelingを使ってSQL Azureをターゲットにするのが本線。となるとER図が軸になるなぁ。 #

AppEngineをやる人はそもそもUMLとか使わないだろうし。となると、クラウドのデータ設計は引き続きER図が軸と考えるべきなのか。振舞いはOOで記述することになるとすると、ハイブリッドな方法が必要かも。 #

スキーマもデータ側に所属する場合、アプリケーション側に所属する場合、データとアプリケーションのダブルディスパッチの場合、とかありそう。 #

Automatically shipped by LoudTwitter