ダイコン

ダイコン時代の設計手法 - クラス抽出

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分析

CRCはClass-Responsibility-Collaboratorの略です。 Responsibilityはクラスの責務、 Collaboratorは協調して動くクラスを表します。 これが、ダイコン時代のコンポーネントの設計にはぴったりなんですよ。 Responsibilityがinterfaceのメソッド、Collaborat…

ダイコン時代のアスペクト指向設計

いらない。 終了ーーーーーーーーーーーーーーーーー。(^^; アスペクト指向って、複数のクラスに共通で適用できるような 処理をモジュールとして分離して扱いましょうというものだと 思っているので、設計時には意識しない方が良いのでは ないでしょうか。 A…

ダイコン時代のAOP - AOPフレームワーク

以前は、静的なアスペクト定義と動的なアスペクト定義という ことで比較していたのですが、正確にいうと AOPフレームワークは コンパイル時にクラスに対してアスペクトを適用する 実行時にクラスに対してアスペクトを適用する 実行時にインスタンス(コンポー…

ダイコン時代の外部設計 - 業務フローをロバストネス分析

外部設計で業務フローをロバストネス分析して、 画面設計書とエンティティ定義書に落としていく開発手法を 実践投入。 しかも、オフショアですよ、あなた。 内部設計はオフショア。 やれ、要求モデル、概念モデル、仕様モデル、実装モデルだの いろんなモデ…

ダイコン時代のORM - 結果セット中心

ダイコン時代のORM(O/R Mapping)はテーブル中心でもなければ、 オブジェクト中心でもなく、結果セット中心でなければならない。 結果セット中心とはどういうことだろうか。 業務にとっては、テーブルやオブジェクトがどのように設計されて いるのかは、ある…

ダイコン時代のAOP

これは本当にアスペクトで実装すべきなのでしょうか? データアクセスはcross-cutting concernなのでしょうか? 間違ってる! といいきるだけの根拠は全然ないのですが,直感としては違うんじゃないかという気がしてしょうがないです. S2Daoがcrosscutting …

アフォなコード

アフォなコードを書く人はそれをアフォなコードだと思っていない事が多いハズなんです。で、それはアフォなコードだよって教えてあげても猛烈な反発が ダイコン時代では、インターフェースと実装が分離され、 設計の段階でインターフェースがきっちり決まっ…

ダイコン時代の設計手法 - 奇妙なクラス抽出法

オブジェクト指向やモデリングの本でこのような文章をみたことがないだろうか。 クラスを抽出するためには、ユースケースから名詞、動詞を まず抽出します。名詞はクラス・属性の候補になり、 動詞は操作や関連の候補になります。書いてあることは間違ってな…

ダイコン時代の設計手法 - クラス図なんて要らない

ほぼ、クラス図不要論とおなじなのですが、自分の意見を書いておきます。 ドメインをデータと振る舞いの点から考えてみたいと思います。 データはどのように永続化するのかが最も重要です。 RDBMSを使う限りはRDBMSに適したようにモデリングしたほうがいい。…

ダイコン時代の設計手法 - Logicがない場合

これは、UI仕様書(Validationつき)とエンティティ仕様書とを明示的に関連づけてしまい(一枚にできないか)、バウンダリからサービスを経由しないで(デザイン的にはスルーして)S2Daoをたたくことで実現できる(Excelでうんぬんを突き詰めたい)。 これまで…

ダイコン時代の設計手法 - 内部設計

バウンダリに関しては、UI層のフレームワークに合わせた 内部設計書を作成します。 とりあえず、必要だと思われるのは、UI層のコントローラ (例えばStrutsのAction)のコンポーネント定義です。 UI層のコントローラは、ロジック層のクラス(interface)に依存し…

ダイコン時代の設計手法 - 外部設計

外部設計のインプットデータは、業務フローです。 業務フローごとに外部設計を行います。 ユーザにレビューしてもらえるのは、外部設計まで。 気合を入れます(笑)。 業務フローの中で、既にバウンダリが洗い出されているはずなので、 それらをもとにロバスト…

ダイコン時代の設計手法 - 外部設計に必要なもの

ダイコンの守備範囲は、外部設計以降なのですが、外部設計をするために 最低これだけは必要になるだろうと思うものを書いておきます。 逆にいうとこれらが決まらずに外部設計にはいっても、 結局待ち状態に入り、プロジェクトは迷走をし始めるでしょう。 デ…

ダイコン時代の設計手法 - PetStore(1)

http://www.javagen.com/petstore/ を例に考えてみます。 私は正直言うと http://examples.macromedia.com/petmarket/store.htmlのほうしか しらないので細かいところは若干異なるかも。 最初は、「カテゴリを表示する」です。 5つの動物がカテゴリです。 最…

ダイコン時代の設計手法 - FDD

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層のコントローラ

UI層のコントローラは、コントローラのコントローラ (StrutsのActionServletなど)とユースケース固有のコントローラ (StrutsのActionなど)があると思います。 ここで取り上げるのは、ユースケース固有のコントローラです。 コントローラの役割は以下のような…

ダイコン時代のテスト技法 - 単体テスト

UI層は、自動テストは行わない。目視でのテスト。 これまでの経験だとUI層のテストを自動化しようと すると、労力の割にはえるものが少ない。 テストのために必要なサービス層の実装は、MockInterceptorで 組み込みましょう。 サービス層は、もちろん自動テ…