<< 続・システムのデッサン | main | システムのデッサン : レイアウトをちゃんと考える >>

システムのデッサン<実践編> 視点を定める

デッサンの「視点」は、ぶれちゃいけない


まずいデッサンのひとつに、視点がぶれまくったデッサンがある。

たとえば、自動車をデッサンするときに、視点を、

・右ななめ前方45度
・5メートル離れて
・立った時の目の高さ(少し見下ろす高さ)

に定めたとする。

ところが、デッサンをしていくうちに、たとえば

・もっと右よりの視点
・もっと下の視点
・もっと近づいた視点

から見た内容も、いっしょに描いてしまう。

結果として、デッサンがだいぶ狂った絵になる。

視点がぶれたデッサンと、視点がしっかりしたデッサンは、自動車であれば、おそらく素人でも区別がつきそう。

システムのデッサンの場合は、視点がぶれているかどうかの判断は、素人はおろか、システム設計を職業としている私たちでさえ、たぶん、意見が一致しない。
(あまりにひどいものは別でしょうが)

こういう基礎的な設計技法すら、確立していない状況を悲観していてもしょうがないので、これからのどんどん発展可能、と前向きにとらえて、勉強したり、考えたことを、発信していきたいと思っている。

システムデッサンの視点(案)



車とか、物理的な存在であれば、視点は、前後・左右・上下の3つの軸(6方向)のどこかに、具体的に設定できる。

システムの場合、まず、この視点を定める軸がはっきりしない。

視点を定める軸が、共通理解になれば、ある程度、デッサンの基礎を固めることができそうな気がする。

「システム構築のアーキテクチャの原理」とか RUP (だったかな?) 4+1 ビューとかを参考に、私の考える、6つの方向(視点の設定軸)

(1)機能 : システムが果たすべき役割(目的、価値)
(2)情報 : システムが扱う情報
(3)並行性: 並行して行われる業務プロセスと業務プロセス間の通信
(4)開発 : モジュール構成、設計規約、コーディング規約
(5)配置 : ハードやミドルウェア
(6)運用 : 移行、監視、ユーザサポート、障害対策と対応

6つの視点を同時に描けるわけではないので、いくつかの視点ごとに、デッサンすることになる。

もっとも単純なのは、それぞれの設定軸ごとに、6つ描くこと。
でもこれだと、それぞれは、平面的な像になってしまう。

今、模索しているのは、いくつかの定番的な視点設定をすること。

たとえば、

A.機能中心で、情報と並行性が視野に入る角度
B.情報中心で、機能と並行性が視野に入る角度
C.配置中心で、運用と開発が視野に入る角度
D.開発中心で、機能と情報が視野に入る角度

みたいな感じ。(まだ、思いつきレベル)

あとは、距離感。
デッサンで、どの程度、詳細に描くかということ。

ひとつのデッサンは、A4一枚で描ける内容が良いと思っています。

上記の4つの角度で、それぞれA4一枚、都合、4枚を描くところからはじめる。

この記述レベルだと、要点とか、全体の輪郭が大切。
詳細とかは、別の方法で、記述することになる。

要点や輪郭の描き方については、別の記事であらためて書こうと思っています。

----------------------------------
それぞれの角度からのデッサンの仕方
----------------------------------

機能中心で、情報と並行性が視野に入る角度



図柄としては、コンテキスト図ですね。
コンテキスト図については、前に書いた、コンテキストのモデリング を参考にしてください。

機能は、別の言い方をすると、

・システムの果たすべき役割
・システムの目的
・システムの価値

です。

関係者が「価値があること」と認めるものは何か?という設問への答えが、「機能」なんだと思います。

私が最近、やっている人材募集分野のシステムだと、

(求職者が)仕事を探して、応募して、就職できるシステム
(求人企業が)人材を募集して、採用できるシステム

が、システムの基本機能になる。

もちろん、もうちょっと、具体的な価値の議論が必要。

・どういうふうに仕事が探せると価値があるのか?
・どういう募集ができると価値があるのか?

などですね。

コンテキストモデリングで最初にやるのは、「価値を判断する登場人物たち」、つまり、アクターを描くこと。

あとは、今回開発の対象とするシステムの機能機能(基本ユースケース)をいくつかと、価値(新システムができること)に大きく影響する、外部システムをあらいだす。

この「機能」の目線を中心にして、「情報」と「並行性」も視野に入れてデッサンする。

「情報」は、機能の記述の中に、目的語的に、自然に登場してくる。
それ以上は、この角度からは追わない。(視点がぶれないように)

情報中心の別の視点(後述)で、追いかけるようにする。

並行性については、コンテキスト図で比較的はっきり見える部分と、コンテキスト図では埋もれてしまう部分がある。

・はっきり見える部分

アクター間、外部システム間、外部システムと本システム間が並行動作した時の、同期の必要性。

コンテキスト図では、関連線で、同期(通信)の必要性が示唆される。

・はっきり見えない部分

アクタとして抽象化された役割の実体が複数いて、同時に作業する場合。
この場合、アクタどうしで通信(同期)が重要なのであれば、おそらく、別のアクタとして描き直して、関連線として、明示すべきかもしれない。

たとえば、求人情報の登録や取り下げが、本社の人事部でも、店舗の店長でもできる、というようなケース。 なんらかの同期(通信)が必要。

もっとミクロのレベルでは、本社人事部の担当者同士の同期というような課題もでてくるけど、A4一枚のデッサンで描くべきテーマではない。
(もちろん、設計の過程で、明示すべきテーマ)

情報中心で、機能と並行性が視野に入る角度


概念モデルですね。

私は、概念モデルは、絵柄としては、クラス図よりも、パッケージ図を描くようにしている。

たとえば、顧客クラスと商品クラスではなく、顧客パッケージと商品パッケージ、という感じ。

顧客という概念を分析していくと、その中に、より詳細な情報が登場する。
だから、初期のデッサンでは、情報をいきなりクラスとして表現するより、「情報の入れ物=パッケージ」として、表現して、だんだん、入れ物の中を増やしていく感じで描くスタイルが、実践的だと思っている。

概念モデルは(絵柄はクラス図でも)、クラスモデルでもデータモデルでもなく、概念のモデル。

関心のある情報の「名前」の列挙、という感じですね。
概念モデルが、次のステップでは、クラスモデルとデータモデルに分かれて発展していくことになる。

もちろん、クラスモデルと、データモデル間のマッピングも重要な課題。

よくあるのが、既存のデータベースがある場合。
こういう場合は、テーブル定義を単にリバースエンジニアリングするだけでなく、概念モデルに整理しなおすとよい。

既存の、現実のテーブル定義は、業務の概念(関心事)を適切に表現していることは、きわめて少ないので、概念モデルとデータモデルはまったく別、と考えていたほうがまちがいがない。

情報中心の角度(概念モデル)では、「機能」や「並行性」も、「情報」(概念)として描く。

・機能を実現するのに必要な情報
・並行性を実現するのに必要な情報

こういうことを視野に入れて、関心のある情報は何か?への答えを描いていくのが概念モデル。

配置中心で、運用と開発が視野に入る角度


絵柄としては、もちろん配置図。

配置図は、まずは、「稼働中」の狭い視野で描く。

それから、

・移行の対象になるのは?
・更新の対象になるのは?
・依存関係は?(ノードの停止・起動の順番は?)

という視野を広げて、記述を膨らませる。

基本の目線は、あくまでも、「稼働中」の配置。
ただ、それだけだと、ある一瞬のシステム構成のスナップショットでしかない。

システムの構成は、初期の構築、移行、アプリケーションの更新、ハードやミドルウェアの更新などで、刻々と変化していくもの。

それを、ある一瞬を切り取った静的な視点で描くだけでは不十分。

実際の書き方としては、稼働中を目線にした配置図に、構成が変化するという目線で、気になることを、ノートで追記していくようにしている。

もちろん、A4一枚のデッサンなので、描くべき内容は、要点と、輪郭だけにすることがポイント。

開発中心で、機能と情報が視野に入る角度


開発者の視点なので、開発者は、自分の関心事を、並べ立てれればよい?

まあ、そのはずなんだけど、実際には、開発者に、開発者の視点で、A4一枚でシステムをデッサンしてもらうと、稚拙な絵がでてくることが多い。

簡単にいうと、

・視野が極端に狭い
・視野が極端に偏っている

絵がでてくる。

もっとも、ある程度の開発者であれば、システムがわかっていないわけじゃなくて、絵にするテクニックが未熟なだけ。

テクニックさえ覚えれば、開発者にとって、この角度からシステムをデッサンすることは、そんなに難しいことではない。

基本テクニックは、とても簡単。

コンポーネント図とパッケージ図を描くこと。
クラス図とか、個別のクラス名がでてくるレベルの絵を書いちゃいけない。

ここは、テクニックというより、発想の違いかもしれない。

狭い視野だと、自分が開発しているのは、クラスであり、ここの定義ファイル。
つまり、エディタで開いて編集しているものが、自分の開発対象。

オープンソースのフレームワークを使う場合も、狭い視野だと、使用する個別のクラスやAPIが関心事。

そうではなくて、 jar 単位とか、パッケージ単位で、ものごとを考えるようにする。

そういう発想さえ持てれば、システムの全体像を、コンポーネント図とパッケージ図で描くことはそう、むずかしいことではない。

A4一枚で描く内容の粒度・詳細ささえ、コツがのみこめれば、簡単なはず。

おっと、忘れてはいけない重要なポイントがある。

開発者の目線を中心にするけど、かならず、「機能(目的、価値)」と「(関心のある)情報」という視野まで広げること。

そうしないと、ほんとうに技術的な関心事だけがならんだ、ふくらみのない絵しかでてこない。

車の例でいうと、真下から、ボディの裏だけを、平面的な描いたような絵になる。
(技術オタクであれば、これでも、とっても興味深い絵なんだろうけど)

機能目線からのデッサンの中心課題、情報目線からのデッサンの中心課題。

それらが、開発者目線のデッサンの、一部として登場しなきゃいけない。

もちろん、中心目線は、開発者の関心事、技術テーマ。
ただし、その周辺には、きちんと、機能と情報についての用語を使うこと。

基礎のスキルを磨く


いちばん、いいのは、これが良いデッサンです、というのを、まず、お手本にすることだと思う。

思うが、「これが良いデッサンです」というのが、あれば苦労しない。

人様に、威張って、お見せできるものではないけど、このブログでは、できるだけ、実際のデッサンを発信していけたらいいなと思っている。

お互いのデッサンを見せ合うことで、得るものもあるだろうから。

コメント
コメントする









この記事のトラックバックURL
トラックバック
calendar
   1234
567891011
12131415161718
19202122232425
2627282930  
<< November 2017 >>
システム設計日記を検索
プロフィール
リンク
システム開発日記(実装編)
有限会社 システム設計
twitter @masuda220
selected entries
recent comment
  • 番号より名前。 ニーモニックコードより名前。 【パターン】
    師子乃 (03/10)
  • Smart UI が優れている?
    masuda220 (03/10)
  • Smart UI が優れている?
    kagehiens (03/09)
  • オブジェクト指向プログラミングの教え方?
    masuda220 (12/05)
  • オブジェクト指向プログラミングの教え方?
    ZACKY (12/04)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    kompiro (08/14)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    JHashimoto (06/13)
  • 「オブジェクトの設計力」 スキルアップ講座やります
    masuda220 (02/28)
recent trackback
categories
archives
others
mobile
qrcode
powered
無料ブログ作成サービス JUGEM