SOA
吉野さんの所にいってきた。ここでもトヨタだ。黒船も使うみたいだ。技術的にはGFlowの出番だが、壮大すぎなので一時退却(成毛さんチームがやってくれるらしい)。しんちゃんパパを召喚してもらうことにした。 くーすは業務アプリケーションを対象としていた…
BCEのそれぞれの数から工数を見積もることができるが、それぞれの組織においてデータを収集して補正数を算出する必要がある。
くーすは業務アプリケーションを開発するためのサービス指向の軽量開発プロセスである。DIコンテナで実装しない開発にも利用できるが、DIコンテナで実装すると効率的に開発できる。ただし、開発の数%しか占めない業務ロジックに焦点を当てている。しかも複雑…
BCE分析の出所が見つかりません。そんな言葉ないのかな。id:akon さんが鍵を握っているのか。 OOSEでは「分析モデルを作成する」としか書いてないですね。「ロバストネス分析」というのは、ICONIXという方法論で使われている方法らしい。 召喚された。確かに…
業務フローから抽出したサービス数（コントロールクラス数）とかなり明朗なお見積もりが提示できる。業務フローを検収してしもらうと見積もれるということである。もちろん、画面数、帳票数など従来からあるものもベースに積み上げる必要がある。もっとも開…
コントロールとは、システムが提供するサービスのことである。古来、クラスの抽出には苦労している。そして、以下のような方法が考えられている。興味深いのは、CRC法以外はすべてPeter Coadによるものである。 CRC法 by Ward Cunningham CRCカードを使って…
業務フローとは業務(ロジック)の実行順序、業務ロジックとはデータのアクセス順序、をそれぞれのルール化したものである。 業務ロジックには、以下のものがある。 ・あるキーに基づいて、データ項目を単純に入力、照会、更新、削除 ・ひとつ以上のデータ項目…
うーん、すっきりしない。なんでフルスクラッチ前提で議論が進むんだろう。どう考えてもというか経験的にエンハンスの方が多い。つまり、既存のデータベースが使われて、既存のエンティティ仕様書を元に、「テーブルを追加しょうか、フィールド(カラム)を追…
比嘉さんのコメントで少し理解。ロバストネス分析は、ステートレスなサービスを抽出するために採用したのだから、サービスが業務フローでステートレスに抽出できているならば、ロバストネス分析は簡略化できるかも。
Webサービス(SOAPを利用したXMLによるアプリケーション連携)のサービスとSOAのサービスが同義と勘違いされやすいが、両者の粒度はまったく違う。SOAはWebサービスのためのアーキテクチャでもなけれ、Webサービスを使うことが前提でもない。サービス指向とい…
業務分析は業務コンサルに任せるのが一番。倉庫のロケーションとかメニューのレイアウトとかプロだなぁと感心してしまう。業務コンサルに頼むほどでもない、業務は十分把握しているというユーザの場合、落とし穴だけの要件と戦うことになる。だから、商売に…
UMLはEDOCも含めて要件定義には向いていない。なぜならばユーザ化の可読性が低いからである。IDEF0が可読性が高いかという一概にはいえないが一日の長があるのは確かである(ダイコンSOAではユーザが読めるものとした)。とくに要件定義段階でオブジェクトのに…
なぜロバストネス図になったかといういきさつ、プロセスを記録しておく。業務フローはIDEF0があれば十分だが望めない。要はユーザが読んでくれて検収印をくれることなので、なんでなければならんいと主張するものではないというところから議論は始まった。UM…
ついにSOAにAOA/Dが導入されてしまった。 http://d.hatena.ne.jp/higayasuo/20040623 一日かかって悩んでいたことを一時間もかからず、解決してしまった。「レギュレーションが違うからしかたないね」と自分を納得させる。
これまでで重量SOAについて理解していただけたと思う。重量といえども従来に比べればかなり軽量ではある。これはあくまでも多くの人がWebアプリケーションを開発することを意識したので重量になってしまった。しかし、S2の真髄は軽量である。当然、軽量な開…
S2もそうですが、敷居を下げたいので何を読みなさいというのは避けたいと思っています。でも深く知ることはよいことなので背景になっている技術の参考文献をあげます。でも散在しているものの要点は日記から得られるようにしたい。 ロバストネス http://d.ha…
ユースケースを状態とサービスに分離します。 サービスはステートレスです。 は、さりげなかったんだけど、これは難しいジャン。 FDD的に「ステートレスなサービス」とユースケースを切り出した方が楽ではないか。そして、サービスの責務をしっかりユースケ…
単にクラス図は不要であるといってしまうと、LyeeやT型と同一視されてしまうので、見解を述べておく（LyeeやT型の開発に携わったことがないので間違った認識かもしれないことをあらかじめ断っておく）。いろいろなところで講演したり、著述しているので、く…
いまさら、＠ITの記事について四の五の言っても詮無きことですが、＠IT情報マネジメント用語事典をみていると情報源が明らかでない（@ITは日記？）。したがって、記者の意見なのか伝聞なのか情報の信憑性が確かめられず、この情報がひとり歩きすることを危惧…
開発プロセスと管理プロセスを区別しなければならない。そして、管理のために成果物を要求してはならない。つまり、開発成果物から管理プロセスは管理すべきである。このため、SOAでは、管理プロセスについては言及しない。 さらに、SOAにおいて、開発プロセ…
つまり、業務フローと業務ロジックにかかわる部分だけに慎重に考えている。 極言するとアクションサーブレット(struts-config.xml)が業務フローで、アクションクラス（から先）が業務ロジックと考えれば、コントロール層でなくてルールエンジンの問題として…
自信ないのでコメントよろぴく。要素技術をMVCにマッピングした実行環境です。id:satoshisさんのご質問に答えると、Web環境で「使う」ときの基本構成のつもりです。 V C M Logic Persistence JSP+Velocity S2 Spring S2Dao Hibernate EJB(CMP) Servlet EJB(S…
・ロバストネス分析でBCEに分解 B:画面、帳票 C:業務フロー E:データと処理 ・(MDAのPIMとPSMにマッピング) ・BCEをJ2EEのMVCにマッピング V: C: M:(業務ロジックとデータアクセス)
パターン化されたサービスは、画一化したサービスになってしまい、顧客満足度が低い。したがって、SOAにおいてパターン化は悪である。パターン化とは作り手の論理であって使い手の論理ではない。むしろ、ERPベンダが用いている手法であるが、ユーザから要件…
ルール駆動によるユースケースの記述 周知のごとく、ユースケースの記述レベルはまちまちである。自然言語で記述しているのだから、レベルを定めることには無理がある。とくにユースケースの粒度を定義しょうというプロジェクトを見受けることがあるが、これ…
日本ではe-japanでEAが積極的に採り上げられているため、GAのきらいがある。このため、一般企業には使えないと勘違いしている人が出てきたのには困ったもんだ。そして、GAこそルールだと思う。サービスではない。役所にサービスはない、規則だけだといったほ…
DIコンテナはステートレスに作成しなければならない。つまり、サービスをステートレスになるまで、分解する必要がある。これがSOAの要である。では、どうやって分解するか。これはルール駆動で分解する。つまり、サービスがひとつの完結したルールになるまで…
ビジネスアプリケーションを対象にしている。 SOA・・・サービス指向分析。名前を変える必要があるが、要件を分析し定義するというだけでなく。ビジネスプロセスを分析し、改善案を提案し、業務フローを定義する（いわゆるBPM）。ビジネスプロセスの分析結果…
