システムのデッサン : レイアウトをちゃんと考える

システムをデッサン(素描)する時の、基本ダイアグラムは、

■振る舞い系
コンテキスト図(概要のユースケースモデル)
アクティビティ図(業務プロセスとプロセス間のやり取り)

■構造系
概念モデル(概要のクラス図、パッケージ図)
配置モデル

などがある。

振る舞い系のレイアウト


振る舞い系は、基本的に、時間の経過とともに、振る舞いが変化することを表現している。

だから、レイアウトの基本は、時間の流れ順。

・上から下へ
・左から右へ

が普通のレイアウト。

ユースケースモデルであれば、アクタの登場順、ユースケースの発生順が基本のレイアウト。

アクティビティ図も同じですね。

システム全体のデッサンよりも詳細な設計用のダイアグラムだけど、ロバストネス図、ステートマシン図、シーケンス図なども、振る舞い系のダイアグラム。

基本のレイアウトは、時間順に、上から下、左から右。

これ、あたりまえのようで、描いているうちにいいかげんになることが結構ある。

特に、システムの全体像をデッサンしているときは、基本要素を発見したり、入れ替えたりしているうちに、レイアウトが時間軸じゃなくなることも多い。

図法として、振る舞いは、時間軸が基本レイアウト、という原則は、みんなで意識しておいたほうが、図を描いたり、レビューする時に、楽になるし、つまらない誤解も減るはず。

構造系のレイアウト


構造系のクラス図やパッケージ図のレイアウトは、私は、ドメイン駆動設計(DDD:Domain-Driven Design) の、Responsibility Layers パターンを基本にしている。

基本は、3段構成。

いちばん下が「リソース」あるいは「ポテンシャル」レイヤ。
「商品」とか「顧客」とか「店舗」とかのクラス(概念)が並ぶ。
ここのレイヤのクラスは、追加や変更は発生するが、それほど、頻繁ではない。

真ん中は、オペレーションレイヤ。
ビジネスのオペレーションのイベントと、それに伴う、状態(ステート)の変化を表現するためのクラス(概念)が並ぶ。

「受注」「出荷」「請求」「入金」などのイベントと、そのイベントが発生した時に、更新しておかなければいけない、注文ステータスとか、入金ステータス。

ここは、頻繁に追加・更新が発生する。

いちばん上が、ポリシーレイヤ。
業務を遂行するための規則や約束事を表現するクラス(概念)群を集める。

「価格ポリシー」、「キャンセルポリシー」、「契約」、「予定」など。

レイヤ構造なので、上のクラスが下のクラスを参照する、のが基本構造になる。

左右のレイアウトについては、問題領域によるけれど、私の場合は、

・左から右へ、時系列に(特にオペレーションレイヤのイベント)

を基本にしている。

配置図など、システム的な構造図についても、依存関係を基本に考えている。
もっと具体的にいうと、サーバーの終了・起動の順番を考えている。

上のほうのサーバーは、下のほうのサーバーを意識せずに、任意に終了・起動できる。

下のほうのサーバーを停止するには、まず、上のサーバーを停止する。

アプリケーションサーバーが上、データベースサーバーが下、ということ。

モデルとコード



こういうレイアウトの原則は、システムの全体像を考えたり、議論するときの便利な道具になる。

対象業務やシステム構成について、どのように理解しているかの、認識の違いを発見しやすくなる。

表面的には、同じ図でも、時間軸やレスポンシビリティによる構造を意識して描くのと描かないのは大違い。

私の経験では、図を描くのを時間のムダという人にかぎって、図の表現方法、図法に無頓着な人が多い。

私は、文章や図を論理的に書くスキル、あるいは「書こうとする」マインドは、よいプログラムコードを書くスキル・マインドと連動していると思っている。

コードがちゃんと書ける人は、文章や図も論理的にかけるはず。
文章や図を論理的に書く人は、コードも論理的にかけるはず。

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

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


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

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

・右ななめ前方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一枚で描く内容の粒度・詳細ささえ、コツがのみこめれば、簡単なはず。

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

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

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

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

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

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

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

基礎のスキルを磨く


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

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

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

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

続・システムのデッサン

昨日の記事の続き。

デッサンの仲間(?)に、スケッチ、クロッキー、エスキスなどの技法(?)があるらしい。

ネットで拾い読みしたネタで、無理やり漢字をあてると

クロッキー 速描
スケッチ 粗描
デッサン 素描
エスキス 下絵

という感じらしい。

絵画の分野だと、こういう用語や技法、学習法、評価法などが、しっかりしているんだろうなあ。

ソフトウェアシステムの設計は、こういう基本の技法を語る言葉が、貧弱というか、ほとんどないなあ。

なげいていてもしょうがないので、絵画の分野から、借り物でもう少し、考えてみる。

クロッキー(速描)


数分で、さっと描いた全体像。
イメージ図。
出発点?

スケッチ(粗描)


ある程度、対象を観察したり、考えながら、要点を書きとめたモデル

デッサン(素描)


技法は素朴(モノトーンで、道具や木炭とか鉛筆)だが、
視点をきちんと定め、遠近法や、光源と陰影など、幾何学的(?)な論理性を大切にする描き方。
論理モデルですね。

エスキス(下絵)


最終システムの構図(構造、配置)や彩色などをおおまかに把握するために、描く。
そのまま発展させていくプロトタイプ(原型)とか、スケルトン(骨格)やモックアップ(実物大模型)に近いかなあ。

まずは、第一印象をクロッキー(速描)して、いろいろ観察して、スケッチ(粗描)して、論理的にデッサン(素描)して、最終システムに向けて、エスキス(下絵)を描いてみる、という感じかなあ。

基本は、デッサン力


4つの中では、「デッサン(素描)」が基礎でしょうね、きっと。

視点、遠近法、陰影法などをしっかり描く力がないと、クロッキー、スケッチ、エスキス、どれも、良い仕事ができない。
「デッサンがくるっている」のは、だめでしょう、やっぱり。

要点を強調したり、あえてデフォルメする、というようなことも、基礎のデッサン(素描)力がしっかりしていないと、うまくできないはず。

システムのデッサン力を勉強するには、昨日もかいたけど「システムアーキテクチャ構築の原理」が、役に立ちそう。

デッサン(素描)の視点は、ひとつではなく、6つ。

■機能
■情報
■並行性
■開発
■配置
■運用

まず、それぞれの視点で、きちんとデッサン(素描)できる力をつける。
最低でも、6枚のデッサン(素描)を描くことになる。

もちろん、6つの視点には、関係性が強いものがあるので、その関係性は、きちんと押さえて検証する。

遠近法にあたる部分は、観点。パースペクティブですね。(透視図法)

システムアーキテクチャ構築の原理では、主要な観点として、

◎セキュリティ
◎性能
◎可用性
◎発展性

をあげている。

4点消失法だな。

6つの視点のデッサン(素描)ごとに、この4つの観点を、消失点(集約点)として、各部分の遠近を表現する。

6つの視点×4つの観点のマトリクスを作って、24の升目に濃淡をつけて検証するのも、全体の構図をはっきりさせる手段になる。

ふむ。 システム設計の表現技法や、設計の巧拙の評価手段が、なんとなく見えてきたきがする。

しばらくは、この線をおいかけてみよう。

たいせつなことが忘れていた。

「ドメイン駆動」が、おそらく、光源と陰影法にあたる技法だと思う。

光源をどこにするかで、同じシステムでも、ずいぶんと見え方や印象がかわるはず。

ドメインからの光をあてながら、システムに陰影をつけていくのが、よい設計スタイル。

ドメインを光源にしたとき、くっきり浮き上がる部分、影になる部分、その濃淡やコントラストを、関係者で共有することが、価値のあるシステムづくりには、とっても役に立つはず。

システムのデッサン(素描)力

とりあえず描いてみる


年末に、ちょっとした設計を済ませたかったが、いろいろ立て込んで、どうにも時間が足りなくなった。

しょうがないので、「一枚5分くらいでいいから、画面のラフスケッチ、ユースケースモデル、概念モデルの三つを、ざっと描いてみて」と頼んだら、要点がはっきりとわかる、かなり良いモデルがでてきた。
(さすがに、1モデル5分ではなく、10分とか20分はかけたようだけど)

描いた本人は、粗が目立って、あまり、納得していない様子。

私からみると、彼の設計意図、こだわりポイント、切り捨てたポイントが明確で、とてもよい設計ドキュメントになっていると思った。

最近は、モデリングツール( Enterprise Architect ) を使ったモデリングが多かったけど、こういう手書きのラフスケッチの良さを、再発見。

この再発見をブログで書こうと思って、ネットで関連ワードを漁っていたら、見つけたのが「デッサン (素描)」という言葉。

ソフトウェア設計でも、「デッサン(素描)」は、基本スキルだし、とても、役に立つ技法。もっと、デッサンをやるべきだし、デッサン力を身につけることが大切。

油絵で、絵の具を使うのが、コーディングだとしたら、その前に、木炭とか、やわらかめの鉛筆で、デッサン(素描)したり、下絵を描くのが、基本。(だと思う。絵の専門家じゃないので確かじゃないけど)

デッサン(素描)で視覚的な特徴をつかむ


デッサン(素描)は、モノトーンで、輪郭線の強弱や、濃淡による陰影で、表現する技法。

細部の精密表現には向かないけど、全体の構図とか、視覚的な特徴とかを、表現するには、きわめて有効な技法というわけだ。

ソフトェアで、細部を精密に表現するには、コードを書くのが一番。APIの使い方などは、サンプルコードが、もっとも、わかりやすい表現手段だと思う。

ただ、ソフトウェアの全体の構造とか、特徴とかを、関係者で、共有するには、コードは適切な手段ではない。

1枚の視覚的な表現、つまり、デッサン(素描)が、もっとも役に立つ。

デッサン(素描)は、試作方法


ルネサンス時代には、絵画や彫刻、建築の試作方法として大いに用いられるようになったのだそうだ。( from wikipedia )

ソフトウェア開発、システム構築は、「建築」との類似性が高いと思う。

デッサン(素描)が便利な試作方法である、という点も、まさにその通り。

描かないのが、腕の見せ所


デッサン(素描)のツボは、細部を「描きこまない」ことでしょう。

ごちゃごちゃ描きこみすぎると、全体が真っ黒になって、線の強弱や、濃淡による陰影の表現が、わかりにくくなってくる。

強弱や陰影をはっきりさせるには、何も描いてない部分とのコントラスト(対比)がポイントになるはず。

ソフトウェアシステムのデッサン(素描)の勘所も、まさにそこにある。

いろいろ描きこみすぎると、全体の輪郭や、特徴が、どんどん、あいまいになってくる。

全体の輪郭と、システムの特徴を、うまく表現するには、いかに、詳細を描かないか、ということが重要になる。

A4一枚(たぶん裏紙)に、輪郭と特徴を、描きだすデッサン力が、ソフトウェアの設計の、必須の基礎スキルだと思う。

デッサン(素描)のアンチパターン


どういうデッサン(素描)が、よい設計かを、書くのは難しい。
こういう場合は、「アンチパターン」(ありがちなまずいパターン)を挙げることで、よいデッサンを表現してみる。

全体が真っ黒


描き込みすぎ。
強調すべき線や陰影が、全体の中に埋没しちゃって、全体の輪郭や特徴がわからなくなっちゃている。
設計ドキュメントで、よくみかけるアンチパターン。詳細な記述が役に立つシーンもあるが、全体の輪郭や特徴(要点)をつかむには、描き込みすぎては、ダメ。

一般化


誤った抽象化。(単純化)
たとえば、○を三つほど描いて、線でつないで、おしまいにするパターン。
MVC の図とかですね。
「デザインパターン」とか「アナリシスパターン」とかもそうですね。

論理的に正しいし、細部を切りすて、全体の構図、特徴をみごとに表現している。

ただし、こういうのは、一般モデルとして、意味があっても、個別のシステムの設計には、そのままでは、役に立たない。

開発すべきソフトウェアは、ある文脈の中で、特定の関係者にとって、(特殊な)価値があること。
そういう価値のあるソフトウェアの全体の輪郭はなんで、どこが要点かを表現するには、一般モデルではなく、もっと特殊なモデルを描かなくちゃいけない。

デザインパターンは、一般モデルとして、興味深いし、設計の参考になることは、まちがいない。

ただし、一般モデルは、個々のシステム固有の特徴を、捨象することで、成り立っている。

個々のソフトウェア設計で重要なのは、そのシステム固有の特徴であり、固有のこだわりポイントこそが大切。

似顔絵でも同じですね。

ある特定の人物の、特徴を描く出そうとする似顔絵と、一般的な「人の顔」を表現した絵とは、目的がまったく違う。

ソフトウェア開発で大切なのは、そのシステム固有の特徴(要点)を、生き生きと描き出すための、デッサン力なんです。

もちろん、一般モデルの勉強はとても大切。
一般モデルを参考にしながら、自分たちは、特殊モデルを創る、というのが、設計なんだと思う。

幼児の絵


稚拙。
コードしか書いたことがない技術者に、設計してもらうと、多いのが、このアンチパターン。

遠近感や大小の対比、位置関係が、かなり崩れている。

幼児の絵は、実は、ほんとうにそう見えているらしい。見たままを素直に描いているらしい。
子供たちには、絵は自由にのびのびと描かせるべきで、遠近感や大小関係を大人の目線・価値観で、いろいろ言うべきではない。

ただし、仕事としてソフトウェア開発をやるには、そうはいかない。
システムの設計(デッサン)が、幼児の絵では、困るわけです。

きちんとした遠近感、大小表現、位置表現ができる基礎の技量があって、はじめて、特徴を強調することができるようになる。

デッサンの基本


絵画の分野であれば、デッサンの基本とか、練習方法とかが、ある程度の確立しているのかもしれない。

ソフトウェアシステムの設計で、私がデッサン(素描)を学ぶのに、おすすすめしたいものを、ざっとあげてみる。

【道具】モデリングツール
フリーハンドでよいデッサンができるようになるには、ある程度の技量が必要。

入門編としては、モデリングツールを使って、UML 風のダイアグラムを描くのが良いと思う。

おすすめ(私たちが使って、よいと思っているもの)は、Enterprise Architect(EA)

ツールの機能もそうだけど、ヘルプとか、入門編のマニュアルとかに、UML の基礎知識を勉強するのに、よい情報がたくさん提供されている。

関係の表現には、アソシエーション(関連)、継承、依存、実現など、いろいろな種類がある。それらを意味や使い分け、そのサンプルなど、EAのヘルプやドキュメントは、情報の宝庫です。

【勉強のネタ】
システムのデッサン(素描)にも、いろいろな流派があると思いますが、私たちが、愛用しているものを紹介しておきます。

リレーションシップ駆動要件分析(RDRA)

RDRA は、要件定義という、システム全体がまだはっきりしない段階で、どうやって、システム全体像を関係者で創っていくかという、実践的な手法です。

ソフトウェアシステム設計のデッサン(素描)の技法として、一押しです。

ICONIX(ユースケース駆動開発実践ガイド)

ICONIX は、RDRA で定義した要件を、ユースケースモデルやクラスモデルから初めて、実際のコードにするまでの、アジャイルで、実践的な手法です。

デッサン力という観点でいうと、「描き込みすぎない」ことを学ぶには、とても参考になる考え方です。

予備設計の段階で描くべきこと、そうでないこと。
詳細設計の段階で描くべきこと、そうでないこと。

こういうメリハリのつけ方のヒントが満載の開発手法です。

システムアーキテクチャ構築の原理

「システムアーキテクチャ構築の原理」は、システム全体の構図を狂わせないために、システム全体像の描き方のポイントを教えてくれます。

6つのビューポイント(視点)と、4つの主要なパースペクティブ(観点)を使って、システムの全体の構造を、体系的かつ要点を押さえた描き方を勉強するには、最適な書籍だと思います。

----
というわけで(?)、今年は、システムのデッサン力をアップするぞ!

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