ダイコン
http://d.hatena.ne.jp/akon/20040727#p1 http://d.hatena.ne.jp/makotan/20040727#p10 http://d.hatena.ne.jp/isami100/20040727#p1 http://d.hatena.ne.jp/marrow/20040727#1090917475 とさまざまな意見がありますが、コントロールの抽出は、 akonさんとい…
従来のオブジェクト指向では、データと振る舞いを1つに してクラスにまとめます。 これがオブジェクト指向の最も重要なポイントとされてきた わけですが、業務アプリケーションに限っていうと 話が変わってきます。 例えば、手数料というデータがあったとし…
くーすのスペルはkusuにしたいと思います。 http://seasarproject.g.hatena.ne.jp/kakutani/20040722#p1
の戯言">CRCと古くて寝かしていたものを使うからクースーかと思っていたんだけどね。 ロバストネス分析・CRCといった良いものだけど、 あまり使われずに埋もれていたものを掘り起こしたということで、 クース(古酒)は、ぴったりかも。スペルに悩むが。 反対…
固有名詞なら普通っぽいですけど Radishでどうっすか。 DItanic, DIHardって手も(笑)。
ダイコン指向だと確かにどういう意味って聞かれたときに答えづらい。 id:dotさんのいうように〜駆動開発はわかりやすくて みんなの頭の中にパターンが刷り込まれていそうです。 再考してみました。 ダイコンを使いこなす上で最も重要なポイントは インターフ…
id:akonさんに名前付けてくれと厳しい要求を突きつけられた。 沖縄の方言を適当に持ってくればよいものではないし、 アルファベットの組み合わせだとちょっとしらける感じ。 覚えやすく・親しみがあり、まわりがうなずけるものでないとだめだろう。 私自身の…
id:marrowさんの日記でダイコン時代の設計手法を トライアルでやってます。 http://d.hatena.ne.jp/marrow/20040721
CRCはClass-Responsibility-Collaboratorの略です。 Responsibilityはクラスの責務、 Collaboratorは協調して動くクラスを表します。 これが、ダイコン時代のコンポーネントの設計にはぴったりなんですよ。 Responsibilityがinterfaceのメソッド、Collaborat…
いらない。 終了ーーーーーーーーーーーーーーーーー。(^^; アスペクト指向って、複数のクラスに共通で適用できるような 処理をモジュールとして分離して扱いましょうというものだと 思っているので、設計時には意識しない方が良いのでは ないでしょうか。 A…
以前は、静的なアスペクト定義と動的なアスペクト定義という ことで比較していたのですが、正確にいうと AOPフレームワークは コンパイル時にクラスに対してアスペクトを適用する 実行時にクラスに対してアスペクトを適用する 実行時にインスタンス(コンポー…
外部設計で業務フローをロバストネス分析して、 画面設計書とエンティティ定義書に落としていく開発手法を 実践投入。 しかも、オフショアですよ、あなた。 内部設計はオフショア。 やれ、要求モデル、概念モデル、仕様モデル、実装モデルだの いろんなモデ…
ダイコン時代のORM(O/R Mapping)はテーブル中心でもなければ、 オブジェクト中心でもなく、結果セット中心でなければならない。 結果セット中心とはどういうことだろうか。 業務にとっては、テーブルやオブジェクトがどのように設計されて いるのかは、ある…
これは本当にアスペクトで実装すべきなのでしょうか? データアクセスはcross-cutting concernなのでしょうか? 間違ってる! といいきるだけの根拠は全然ないのですが,直感としては違うんじゃないかという気がしてしょうがないです. S2Daoがcrosscutting …
アフォなコードを書く人はそれをアフォなコードだと思っていない事が多いハズなんです。で、それはアフォなコードだよって教えてあげても猛烈な反発が ダイコン時代では、インターフェースと実装が分離され、 設計の段階でインターフェースがきっちり決まっ…
オブジェクト指向やモデリングの本でこのような文章をみたことがないだろうか。 クラスを抽出するためには、ユースケースから名詞、動詞を まず抽出します。名詞はクラス・属性の候補になり、 動詞は操作や関連の候補になります。書いてあることは間違ってな…
ほぼ、クラス図不要論とおなじなのですが、自分の意見を書いておきます。 ドメインをデータと振る舞いの点から考えてみたいと思います。 データはどのように永続化するのかが最も重要です。 RDBMSを使う限りはRDBMSに適したようにモデリングしたほうがいい。…
これは、UI仕様書(Validationつき)とエンティティ仕様書とを明示的に関連づけてしまい(一枚にできないか)、バウンダリからサービスを経由しないで(デザイン的にはスルーして)S2Daoをたたくことで実現できる(Excelでうんぬんを突き詰めたい)。 これまで…
バウンダリに関しては、UI層のフレームワークに合わせた 内部設計書を作成します。 とりあえず、必要だと思われるのは、UI層のコントローラ (例えばStrutsのAction)のコンポーネント定義です。 UI層のコントローラは、ロジック層のクラス(interface)に依存し…
外部設計のインプットデータは、業務フローです。 業務フローごとに外部設計を行います。 ユーザにレビューしてもらえるのは、外部設計まで。 気合を入れます(笑)。 業務フローの中で、既にバウンダリが洗い出されているはずなので、 それらをもとにロバスト…
ダイコンの守備範囲は、外部設計以降なのですが、外部設計をするために 最低これだけは必要になるだろうと思うものを書いておきます。 逆にいうとこれらが決まらずに外部設計にはいっても、 結局待ち状態に入り、プロジェクトは迷走をし始めるでしょう。 デ…
http://www.javagen.com/petstore/ を例に考えてみます。 私は正直言うと http://examples.macromedia.com/petmarket/store.htmlのほうしか しらないので細かいところは若干異なるかも。 最初は、「カテゴリを表示する」です。 5つの動物がカテゴリです。 最…
FDDはFeature Driven Developmentの略でシステムがユーザに提供する価値を Feature(ユーザ機能)に分解してユーザ機能ごとに開発していきます。 ユーザ機能とはで表現されるものです。 なんじゃいそりゃー。VO(動詞 + 目的語)。「〜を〜する」で表現される も…
http://d.hatena.ne.jp/akon/20040620#p3やそのコメント http://d.hatena.ne.jp/higayasuo/20040620#1087744106 http://d.hatena.ne.jp/habuakihiro/20040621#1087747725 とやり取りしていたのですが、お互いいってることが微妙にずれる。 ユースケース、FDD…
ユースケースの管理単位は、画面系なら関連のある複数の画面の組み合わせ、 帳票系なら1帳票、バッチ系ならジョブネット。 ユースケース単位に、ロバストネス分析を行って全体構造を把握します。 ロバストネス分析を行うときにもっと重要なのがコントロール…
従来のオブジェクト指向では、クラス・継承・多態性などを学んでも、 結局、実プロジェクトにどうやって活かしたらよいのか、 よくわからないというのが実情だったのではないでしょうか。 デザインパターンなども実際のコードに生かせるのは、 業務システム…
ここでいう作業待ちとは、前工程が決まらないために 後工程の人が遊んでしまう状態のことです。 作業待ちが起こると工数的なダメージがあるばかりではなく、 開発者のモチベーションも下げてしまいます。 仕様と実装を明確に分離し、仕様を先につめるように…
ユースケースが正しいことを検証する、あるいは さらに詳細な設計をする前の準備として、 ロバストネス分析は役に立つと思います。 ロバストネス分析とはユースケースの登場人物を バウンダリ、コントロール、エンティティに分類して その関連を分析するもの…
UI層のコントローラは、コントローラのコントローラ (StrutsのActionServletなど)とユースケース固有のコントローラ (StrutsのActionなど)があると思います。 ここで取り上げるのは、ユースケース固有のコントローラです。 コントローラの役割は以下のような…
UI層は、自動テストは行わない。目視でのテスト。 これまでの経験だとUI層のテストを自動化しようと すると、労力の割にはえるものが少ない。 テストのために必要なサービス層の実装は、MockInterceptorで 組み込みましょう。 サービス層は、もちろん自動テ…