システムのデッサン:光源と陰影

初期のドメインモデリングは、システムの全体像のデッサンに不可欠な実践のひとつ。

「どんな情報を扱うシステムか」という「情報の視点」を中心にして、機能と並行性を視野に入れて、システムの全体像を、A4一枚のクラス図にまとめていく。

「概念モデリング」とか、「業務の用語集作成」とほぼ同じ。

業務で扱う情報名や業務上の処理(機能)名を、クラス図として描いていく。

光源はドメイン


UMLツールでクラス図を書くと、それぞれのクラスは、線の太さや色が同じになる。
これだと、かなり平坦なデッサンになり、あまり役に立たない。

ドメイン、つまり、業務の視点、業務から見た重要度や、関心の強さを光源にして、強く光る部分、弱く光る部分、陰影などを描きこめば、モデルが、立体的に、生き生きとしてくる。

ドメインという光源から、陰影や強弱をつけた絵は、関係者の認識合わせに、とても役にたつ。

線の色も太さも同じ四角がならんだクラス図だと、業務の言葉さえ並んでいれば、なんとなく、そんなもんだろうで終わってしまう。

「重要な関心事オブジェクト」「注意すべきオブジェクト」という色分け、描き分けをしてみると、人によって、捉え方が違っているのが一目瞭然になる。

開発者は、プロジェクトの初期では、どのドメインオブジェクト(どの業務の用語)も同じに見えている。
どこから手を付けてもいっしょに見えるし、どのオブジェクトの分析・設計に、時間とエネルギーを使うべきか判断できない。

ドメイン(業務)という光源からあてた光で、めりはりをつけたクラス図を描けば、業務のエキスパートの重要な関心事、業務のややこしい部分を、プロジェクトの初期で、関係者で共有できる。
共有できれば、開発全体の軸や方向感がでてくる。チームが良い成果を達成するための羅針盤になる。

ドメイン駆動設計(DDD)の Highlighted Core パターンですね。

クラス図に光の強弱と陰影をつける


ドメインから光をあてた結果の、光の強弱は、クラスアイコンの背景色、線の太さ、色などで、描く。
あまり、凝らないほうが良い。
背景色だと、白、黄色、グリーンくらいで十分。
線の色や太さはこらないほうが良い。描きわける労力に比べ、情報の伝達効果はいまひとつ。

もちろん、約束事を決めて、同じ色は同じ意味にする。
Enterprise Architect のような UML ツールだと、ステレオタイプを色で視覚化できるので、core とか、subject とか、主題であることを宣言するステレオタイプを定義して、色設定するといいかもしれない。

陰影のつけ方は、アイコンに影をつけるわけではない。
ドメインから光をあてたとき、そのクラス図で影になる部分とは、クラス図の表面ではなく、裏側に何かある、ということ。

「何かある」ということを、明示するために、便利なのが「ノート」。ようするに、注釈ですね。
注釈がついた、クラスには、何かあるぞ、ということになる。
初期の段階では、「ここはなにかあるかも?」という程度のメモでもよい。

関心事の重要性で色分けし、注意すべきクラスには、ノートがついているクラス図で、関係者で、ドメインの概念、構造を、共有できると、あとあと、つまらない、手戻りが激減します。

業務で重要な部分、注意すべき部分を、ソフトウェアの開発者が最初から、きちんと理解して、開発を進めているのだから、大きなブレは起きない道理です。

逆に、ここらへんの認識合わせが、ずれたままだと、ソフトウェアは動くかもしれないが、中身は、かなり、業務モデルとはずれた、ねじれた実装になっている可能性が高い。

ドメイン(業務)の概念モデルと、ソフトウェア実装の構造がねじれていると、変更に弱く、わけのわからない副作用が発生しやすいソフトウェアになる。

業務の構造と概念を丁寧に反映したソフトウエアだと、変更要求も、合理的だし、コードの変更も局所的に、安全にできるようになる。

初期の概念モデリング(ドメインモデリング)で、ドメイン(業務)を光源に、クラス図に色分けとノートで注釈したものを意識して作成し、共有することが、役に立つソフトウェアを作る、基本テクニックの一つ。

重要度と分析・設計の難易度


業務の光で、クラス図を照らして、強弱・陰影をつけた場合、重要なクラスは、技術者から見たら、単純で、退屈なクラスに見えることが多い。

うまくいっているビジネスほど、ほんとうに重要なことは、精査され、磨き上げられているので、初期のモデルをみる限りは、その中核オブジェクトは、単純に見えることがある。

で、単純に作ると、大失敗。

重要なドメインオブジェクト、業務の関心事であるオブジェクトの分析・設計には、細心の注意が必要。

そのオブジェクトが表現している、業務の関心事は、実際の業務の中で、さまざまなルールや手順が、なかば無意識に適用されている。また、重要な関心事であるだけに、たまにしか起きないような例外的な状況の時は、どうするかとかのノウハウが、業務のエキスパートの頭の中に、しっかり入っている。

ところが、これらのルール、手順、例外対処ノウハウなどは、業務のエキスパートが、事前に、明示的に語ることはまずない。 彼らにとっては、ある意味、前提知識みたいな話だし、あまり意識せずに、それをやっているからこそ、エキスパートなわけで、いちいちそんなことを意識して考えていたのでは仕事にならない。

業務に役に立つ道具を作るためには、そいういうエキスパートの知識をなんとか引っ張り出して、コードに実装しなくちゃいけない。
そのためのテクニックが、ドメインモデリング。概念クラス図。

業務で重要な関心事クラスは、実装は単純なクラスかもしれません。
でも、その背景にある、ビジネスルール、業務知識を、適切にキャッチするのは、かなり難易度が高い。

初期の概念モデリングで、ドメインの中核オブジェクト、業務の重要な関心事オブジェクトを特定できたら、そこが出発点。

楽勝に見えても、細心の注意を払って、分析・設計を進めること。
エキスパートとのやり取りで、ちょっとでも違和感を感じたら、がんばって掘り下げること。

ハイライトされた重要オブジェクトのまわりには、大切な業務知識が山のように埋まっている。
それを、丁寧に掘り出すことで、業務の役に立つソフトウェアを作ることができる。

重要な業務知識のありかの嗅ぎ付け方、掘り出し方が、よいソフトウェアづくりに、必須のスキル。

クラス図に色やノートを使って、強弱・陰影をつけて、業務のエキスパートや、開発者どうしで、認識合わせを丁寧にやれば、重要な業務知識のありかは、容易に見つけることができる。

ただし、そのまわりに埋まっている業務知識の掘り出しは、そう、簡単ではない。

ここに、いろいろ埋まっているんだ、という革新を持って、分析・設計を進めれば、ある日、突然、価値のある業務知識を見つけることができる。 ドメイン駆動設計(DDD)の、ブレークスルーパターンですね。

Evans も書いているように、いつ、どんなブレークスルーが起きるかは、予測不能。地道に、基本的な分析・設計を繰り返すのみ。

でも、あちこちを、手当り次第にほっていたのでは、いかにも効率が悪い。

システム全体のデッサンで、初期の概念モデルに、業務の光をあてて、強弱・陰影をつけることで、どこを掘ればよさそうかのあたりが、つけば、ソフトウェアの価値をもっとも高めることができるポイントに、時間とエネルギーを投入できる。

それが、良いシステムのデッサンのコツであり、やるべきこと。
ブレークスルーが起きるタイミングは予測できないが、ブレークスルーが起きる場所は、分析モデリングの初期からある程度、確信をもって、予想できる。 業務の重要な関心事を表現する、中核クラス。そこに、ブレークスルーのネタはころがっている。

calendar
  12345
6789101112
13141516171819
20212223242526
2728     
<< February 2011 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM