システムをデッサン(素描)する時の、基本ダイアグラムは、
■振る舞い系
コンテキスト図(概要のユースケースモデル)
アクティビティ図(業務プロセスとプロセス間のやり取り)
■構造系
概念モデル(概要のクラス図、パッケージ図)
配置モデル
などがある。
振る舞い系は、基本的に、時間の経過とともに、振る舞いが変化することを表現している。
だから、レイアウトの基本は、時間の流れ順。
・上から下へ
・左から右へ
が普通のレイアウト。
ユースケースモデルであれば、アクタの登場順、ユースケースの発生順が基本のレイアウト。
アクティビティ図も同じですね。
システム全体のデッサンよりも詳細な設計用のダイアグラムだけど、ロバストネス図、ステートマシン図、シーケンス図なども、振る舞い系のダイアグラム。
基本のレイアウトは、時間順に、上から下、左から右。
これ、あたりまえのようで、描いているうちにいいかげんになることが結構ある。
特に、システムの全体像をデッサンしているときは、基本要素を発見したり、入れ替えたりしているうちに、レイアウトが時間軸じゃなくなることも多い。
図法として、振る舞いは、時間軸が基本レイアウト、という原則は、みんなで意識しておいたほうが、図を描いたり、レビューする時に、楽になるし、つまらない誤解も減るはず。
構造系のクラス図やパッケージ図のレイアウトは、私は、ドメイン駆動設計(DDD:Domain-Driven Design) の、Responsibility Layers パターンを基本にしている。
基本は、3段構成。
いちばん下が「リソース」あるいは「ポテンシャル」レイヤ。
「商品」とか「顧客」とか「店舗」とかのクラス(概念)が並ぶ。
ここのレイヤのクラスは、追加や変更は発生するが、それほど、頻繁ではない。
真ん中は、オペレーションレイヤ。
ビジネスのオペレーションのイベントと、それに伴う、状態(ステート)の変化を表現するためのクラス(概念)が並ぶ。
「受注」「出荷」「請求」「入金」などのイベントと、そのイベントが発生した時に、更新しておかなければいけない、注文ステータスとか、入金ステータス。
ここは、頻繁に追加・更新が発生する。
いちばん上が、ポリシーレイヤ。
業務を遂行するための規則や約束事を表現するクラス(概念)群を集める。
「価格ポリシー」、「キャンセルポリシー」、「契約」、「予定」など。
レイヤ構造なので、上のクラスが下のクラスを参照する、のが基本構造になる。
左右のレイアウトについては、問題領域によるけれど、私の場合は、
・左から右へ、時系列に(特にオペレーションレイヤのイベント)
を基本にしている。
配置図など、システム的な構造図についても、依存関係を基本に考えている。
もっと具体的にいうと、サーバーの終了・起動の順番を考えている。
上のほうのサーバーは、下のほうのサーバーを意識せずに、任意に終了・起動できる。
下のほうのサーバーを停止するには、まず、上のサーバーを停止する。
アプリケーションサーバーが上、データベースサーバーが下、ということ。
こういうレイアウトの原則は、システムの全体像を考えたり、議論するときの便利な道具になる。
対象業務やシステム構成について、どのように理解しているかの、認識の違いを発見しやすくなる。
表面的には、同じ図でも、時間軸やレスポンシビリティによる構造を意識して描くのと描かないのは大違い。
私の経験では、図を描くのを時間のムダという人にかぎって、図の表現方法、図法に無頓着な人が多い。
私は、文章や図を論理的に書くスキル、あるいは「書こうとする」マインドは、よいプログラムコードを書くスキル・マインドと連動していると思っている。
コードがちゃんと書ける人は、文章や図も論理的にかけるはず。
文章や図を論理的に書く人は、コードも論理的にかけるはず。
■振る舞い系
コンテキスト図(概要のユースケースモデル)
アクティビティ図(業務プロセスとプロセス間のやり取り)
■構造系
概念モデル(概要のクラス図、パッケージ図)
配置モデル
などがある。
振る舞い系のレイアウト
振る舞い系は、基本的に、時間の経過とともに、振る舞いが変化することを表現している。
だから、レイアウトの基本は、時間の流れ順。
・上から下へ
・左から右へ
が普通のレイアウト。
ユースケースモデルであれば、アクタの登場順、ユースケースの発生順が基本のレイアウト。
アクティビティ図も同じですね。
システム全体のデッサンよりも詳細な設計用のダイアグラムだけど、ロバストネス図、ステートマシン図、シーケンス図なども、振る舞い系のダイアグラム。
基本のレイアウトは、時間順に、上から下、左から右。
これ、あたりまえのようで、描いているうちにいいかげんになることが結構ある。
特に、システムの全体像をデッサンしているときは、基本要素を発見したり、入れ替えたりしているうちに、レイアウトが時間軸じゃなくなることも多い。
図法として、振る舞いは、時間軸が基本レイアウト、という原則は、みんなで意識しておいたほうが、図を描いたり、レビューする時に、楽になるし、つまらない誤解も減るはず。
構造系のレイアウト
構造系のクラス図やパッケージ図のレイアウトは、私は、ドメイン駆動設計(DDD:Domain-Driven Design) の、Responsibility Layers パターンを基本にしている。
基本は、3段構成。
いちばん下が「リソース」あるいは「ポテンシャル」レイヤ。
「商品」とか「顧客」とか「店舗」とかのクラス(概念)が並ぶ。
ここのレイヤのクラスは、追加や変更は発生するが、それほど、頻繁ではない。
真ん中は、オペレーションレイヤ。
ビジネスのオペレーションのイベントと、それに伴う、状態(ステート)の変化を表現するためのクラス(概念)が並ぶ。
「受注」「出荷」「請求」「入金」などのイベントと、そのイベントが発生した時に、更新しておかなければいけない、注文ステータスとか、入金ステータス。
ここは、頻繁に追加・更新が発生する。
いちばん上が、ポリシーレイヤ。
業務を遂行するための規則や約束事を表現するクラス(概念)群を集める。
「価格ポリシー」、「キャンセルポリシー」、「契約」、「予定」など。
レイヤ構造なので、上のクラスが下のクラスを参照する、のが基本構造になる。
左右のレイアウトについては、問題領域によるけれど、私の場合は、
・左から右へ、時系列に(特にオペレーションレイヤのイベント)
を基本にしている。
配置図など、システム的な構造図についても、依存関係を基本に考えている。
もっと具体的にいうと、サーバーの終了・起動の順番を考えている。
上のほうのサーバーは、下のほうのサーバーを意識せずに、任意に終了・起動できる。
下のほうのサーバーを停止するには、まず、上のサーバーを停止する。
アプリケーションサーバーが上、データベースサーバーが下、ということ。
モデルとコード
こういうレイアウトの原則は、システムの全体像を考えたり、議論するときの便利な道具になる。
対象業務やシステム構成について、どのように理解しているかの、認識の違いを発見しやすくなる。
表面的には、同じ図でも、時間軸やレスポンシビリティによる構造を意識して描くのと描かないのは大違い。
私の経験では、図を描くのを時間のムダという人にかぎって、図の表現方法、図法に無頓着な人が多い。
私は、文章や図を論理的に書くスキル、あるいは「書こうとする」マインドは、よいプログラムコードを書くスキル・マインドと連動していると思っている。
コードがちゃんと書ける人は、文章や図も論理的にかけるはず。
文章や図を論理的に書く人は、コードも論理的にかけるはず。