コンテキストのモデリング | システム設計日記
エバンスは、去年３月のプレゼンテーション What I've learned about DDD since the book で、Domain-Driven Design(DDD)の１４章の Bounded Context パターン、Context Map パターン、１５章の Core Domain パターンは、DDD の基本コンセプトとして、３章とか、もっと最初に書くべきだった、というようなことを言っています。 このエバンスの発言は、個人的には「何をいまさら」というのが私の正直な気持ちだった。 だって、開発プロジェクトのスタートでは、「コンテキスト図」を書いて、システムを取り巻く環境や、システムの基本目的を明らかにするのが、あたりまえだから。 コンテキスト図を描き始めたきっかけ もっとも、自分たちのプロジェクトでは、私以外のメンバーは、一年前までは「コンテキスト図」なんて言葉も知らなか
良いユースケースを書くための発想法
システムの要求仕様を決めるのに、ユースケースを使うことがよくあります。 しかし、ユースケースは上手く書けない、何を書けば良いのか分からない、という人も、少なくありません。 たいていのユースケースは、アクターが１人２人いて、アクターが行える操作がいくつか丸で描かれて、それらが線で結ばれているだけの、とてもシンプルなものです。しかし、シンプルすぎて、何の役に立つのか分からない、という人もいます。 役に立つユースケースを書こうとして、細かいことまで書き込みすぎてしまう人も良く見かけます。しかし、それは誤りです。 ユースケースは何のために書くのでしょうか。ここでは、ユースケースの目的をはっきりさせて、良いユースケースを書くための考え方を紹介します。 開発者は、細かいことまでユースケースに書き込みがち Design Wave Magazine 2007年5月号別冊付録「組み込みシステム開発者＆LSI
誤解しがちなモデリングの技：第3回：ステートマシン図（Ｉ） | 豆蔵ソフト工学ラボ
この「保温器」は「温度センサー」から取得した「現在温度」が設定された「上限温度」と「下限温度」の範囲に入るように「ヒーター」のON/OFFを制御するものとします。この「保温器」のステートマシン図(状態遷移図)を考えてみましょう。 図2 はガード条件の使い方を誤ってしまっている典型的な例です。この状態遷移図に従って実装された「保温器」は、おそらく「現在温度」が「上限温度」を超えても「ヒーター」がOFFにならず、どこまでも加熱し続けてしまいます(場合によってはペットの熱帯魚が全滅してしまったり、火災が発生してしまったりします)。 このステートマシン図でまずいのは「加熱中」状態と「非加熱中」状態の間の遷移にかけられているガード条件の部分です。おそらく、このようなステートマシン図を描く人は『これらのガード条件はいつでも常にチェックされていて、その条件が満たされたら遷移が起こる』という間違った解釈を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
アジャイルにおけるソフトウェアアーキテクチャ図とNoUML
