ソフトウェア工学の基礎

第4章 モデル

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

全てのモデルは間違っているが、有用なものもある。

ジョージ・E・P・ボックス（英国統計学者、帰属）

ここまでで、ソフトウェアエンジニアとしての仕事において、特に他の開発者とのコミュニケーションが中心的な焦点であることは明らかだろう。コンピュータは構文的に正しいコードだけを気にするが、人間同士のコミュニケーションにはそれ以上のものが必要だ。コードは他者が理解できるよう、十分に文書化され整理されているべきだ（コードの書き方については章3を参照）。しかし時にはそれ以上のものが必要になる。プロジェクト全体を通じて、技術的な意図を表現するためにソフトウェアモデルやボックスと線の図を使用することになる。

優れたコードと同様に、優れたソフトウェアモデルは明確で、関係者が容易に理解できるものである。モデルが不明確であれば、それを利用する者は技術的な意図を理解できない。モデルのコンシューマは決して少なくない：ユーザ、テスター、他の開発者、セキュリティ担当者、予算決定者、プロジェクトマネージャー、アーキテクト。そして自分自身だ。時には、図の唯一のコンシューマが自分だけの場合もある。とはいえ、適当に図を描いて皆に理解してもらえるとは思えない。開発者には完璧な図でも、エンジニアリング担当副社長には通用しないかもしれない。その逆も然りだ。課題は、どの図をいつ作成すべきかを見極めることだ 。

ソフトウェアモデルとは何か？なぜ行うのか？

ソフトウェアは比較的新しい産業であり、成熟した分野から概念や手法を借用してきた。¹ また、モデリング手法にも様々な「潮流」があった。統一モデリング言語（UML） からC4モデルまでだ。建設業界は新プロジェクトに着手する前に設計図一式を作成する。ソフトウェアプロジェクトも同じことをすべきではないか？おそらくそうだ。

ソフトウェアモデリングとは、ソフトウェアシステムの構造、振る舞い、機能を理解・分析・伝達しやすくするため、その抽象的な表現を作成するプロセスである。これらのモデルは、開発者、設計者、関係者をシステムの設計・開発プロセスに導く。優れたソフトウェアモデルは実世界の問題領域を反映し、開発プロセス全体を通じて洞察を提供する。

しかし、ソフトウェアを書くことと家を建てることの本質的な違いを理解することが重要である。物理世界の再構築は困難で費用がかかる。建設業者が、例えば生産現場で耐荷重壁の実用性をテストする余裕などないのだ。設計図は、設計者が家が地域の建築基準を満たし、水道・電気・冷暖房の配管が適切であることを保証する手段だ。建設開始前に設計図は「何を建てるか」を伝え、所有者が期待通りに進むことに同意させる。建設完了後には設計図が仕様通りに建てられたかを確認する材料となる。もし様々な業者が即興で作業したら、現場は混乱するだろう。

しかしソフトウェアはリファクタリングできる。²コードは数時間で数百ドルのコストで変更できる。物理世界の「リファクタリング」コストは桁違いに高い。もし些細な変更のたびに数時間と数百ドルの追加コストがかかるなら、住宅の建て方は変わっていただろう。設計図は建築プロセスにおいてそれほど不可欠ではなかったはずだ。ソフトウェアはより柔軟なため、図解はプロジェクト成功にそれほど重要ではないかもしれない。

図はコンパイルされない。図は、プロジェクトの完成に貢献する実行可能なコードにはならない。実際、開発者にとって、コードは究極の設計成果物である、と強く主張することもできる。影響力のある ...