ユースケース駆動開発実践ガイドを読んでわかったこと - paz3のおもいつき
ユースケース駆動開発実践ガイド を読んでいます。現在、ロバストネス分析のところまで読み進めました。この本で目からウロコが落ちる体験をしています。以下、気付いた点です。 ユースケースってすごい いままでユースケース記述というのは「アクターと丸をつないだものに、他の資料（機能仕様書など）から見つけ出した説明をつけたもの」で「あまり役に立たないもの」と考えていたのですが、違いました。ICONIXプロセスでは次のことをすることで、ユースケースを設計の基本となる極めて重要な資料に仕立て上げています。 先に用語リスト（ドメインモデル）を作成し、そこに含まれる用語を使うことで曖昧さを排除する。 宣言的（例：ユーザーは検索できる）ではなく叙述的（例：ユーザーは検索ボタンをクリックする）に書く。 「事前条件」「アクター」「スコープ」「レベル」「成功時保障」などの項目を省略し、その分、モデリングに集中する。
ユースケース駆動開発実践ガイドを読んでわかったこと、その2 - paz3のおもいつき
ユースケース駆動開発実践ガイド を読んで気付いたことのメモです（そんなの当たり前だよ！」というようなこともあるかもしれませんが、ご容赦ください）。前回（d:id:paz3:20090613）の続きです。 シーケンス図のメッセージとロバストネス図のコントローラは1対1対応しなくてもよい 最初、ロバストネス図のすべてのコントローラをシーケンス図のメッセージに置き換えようとしました。たとえば「数量が足りていれば○○する」というような判断をするコントローラも、とあるオブジェクトの自分宛のメッセージとして記述しました。その結果、メッセージ（メソッド）の数が膨れ上がり、わけがわからなくなってしまいました。 書籍を読み直してみたところ、次のように書いてありました。 コントローラと操作の間に1対1の対応を取る必要はありません シーケンス図上にフローチャートを描こうとしてはいけません そこで、シーケンス図か
ASP.NET MVC 4でjQueryを使って動的に部分ビューを更新させる - 酢ろぐ！
今日は7月7日、七夕ですね。Twitterのタイムラインを見ていたら七夕ということもあってか短冊を作って遊んでる方が沢山いました。 だるさんがWebMatrixを使って短冊ヘルパーを作っていたので、僕も負けじとASP.NET MVCを使ってかなり雑な短冊メーカーを作りました。 短冊メーカー (Microsoft Azureが自由に使えなくなったので閉鎖しました) ツイート機能は入れないといけないと思い実装しましたが、Ajaxで動的に内容を差し替えるツイートボタンの実装は難易度が高かったです。 ┏┷┓ ┃ ┃ ┃雑┃ ┃な┃ ┃短┃ ┃冊┃ ┃メ┃ ┃｜┃ ┃カ┃ ┃｜┃ ┃更┃ ┃新┃ ┃し┃ ┃た┃ ┃よ┃ ┃ ┃ ??━┛??URL 2014-07-07 18:43:39 via Twitter for Websites なんで雑かというと、横書き用の「、」「。」や半角アルファベットな
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://software.fujitsu.com/jp/technical/interstage/apserver/guide/pdf/Finalizer-GC.pdf
