第10章 表記法
この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている:translation-feedback@oreilly.com
C4モデルのすべての図の種類を見てきたので、いよいよ表記法について議論する時が来た。第2章で触れたように、多くの人にとっては意外なことだが、C4モデルは表記法に依存せず、特定の表記法を必要としない。つまり、好きな図形、色、線のスタイル、アイコンなどを自由に使用できる。 UMLやArchiMateなどの既存の表記法を使用することも可能だが、その話題については後ほど詳しく述べる。
とはいえ、すべての表記法が同等というわけではない。そこで本章では、表記法について詳しく検討し、図の表記を「良い」ものから「素晴らしい」ものへと高めるための指針を示す。
優れた表記法とは何か?
まず、先程述べたことを改めて強調しておきたい。見落とされがちだが、C4モデルは表記法に依存しない。最初の例示図で使用した表記法は、青と灰色の図形で構成されていた。残念ながら、多くの人々やツール開発者がこの慣習を採用した結果、それらの青と灰色の図形がC4モデルの標準表記法であるという誤解が生じている。そうではない。好きな色や図形を自由に使用してほしい。
では、良い表記法とはどのようなものだろうか。出発点として、以下の特徴を提案したい。
-
表記法は、図の読み取りを容易にし、より幅広い読者のアクセシビリティを高める。
-
要素や関係性を区別するために使用される表記法(図形、色、線のスタイル、アイコンなど)は、図の凡例で説明される。
-
表記法は、同一セット内の図間で一貫性がある。例えば、同じソフトウェアシステムを記述するシステムコンテキスト図とコンテナ図では、両方の図に現れる要素や関係に対して同じ表記法が用いられる。
図を作成する際、私の目的は、その図が「自ずと語られる」ようにすることだ。読者は、あまり多くの質問をすることなく、目にする内容の大部分を解釈できるべきである。図は本質的に、口頭での説明や文章による解説がなくても、単独で成立し、理解できるものでなければならない。
ソフトウェアアーキテクチャ図は、単独の成果物として作成されるものではないことは承知している。むしろ、通常は補足的な文書化に組み込まれたり、プレゼンテーションで使用されたりするものだ。説明文付きの文書化やプレゼンテーションから図だけが抽出され、必要なコンテキストが欠落した結果、読者が図が何を伝えようとしているのか混乱してしまう状況を、私は数多く目にしてきた。この章の表記ガイドラインが、そのような状況下でも図が理解される可能性を高めることを願っている。
頭字語、略語、コードネーム
理解不能な頭字語、略語、コード名は、それ以外では完璧な図を台無しにしてしまう。可能な限りこれらを避けることを推奨するが、簡潔さのために使用せざるを得ない場合は、文書化された用語集、あるいはさらに良い方法として図の凡例にそれらを記載することを提案する。 ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access