スパゲッティをラザニアにとらえるシステム思考②

スパゲティに見えた先人の食べ残しをラザニアととらえる思考法

の第二弾！

---

第二弾は、前回の続き。
自分の担当のソフトウェア全体を
アプリ・ライブラリ・隠ぺいの３層に横に切り出し、
機能毎に縦に切り出したのちの捉え方を説明します。

主に、私が業務で取り組んでいる、

ソフトウェアの把握方法を２つ紹介します。

コールグラフという考え方

---

本来、ソフトウェアを開発するうえで、

UML（Unified Modeling Language）で書かれた

詳細設計があることが望ましいですが、

それがない場合はコードを読み込む必要があります。

そんな時、コールグラフという考えが役に立ちます。

FunctionAは、FunctionB,Cを呼び出して実装され、

FunctionBは、D、E。FunctionCはD、E、Fを呼び出して

実装されている。という実装のコール（呼び出し）を

グラフ化します。

前回からに引き続き、

FunctionAがアプリ層、

B,Cがライブラリ層、

D,E,Fが隠ぺい層であれば、

コールグラフから機能が

正しく実装できているかが図で確認できます。

この例も、まぁまぁ複雑な例なのですが、

FunctionD,E,FからBやAを呼び出す図になった場合、

複雑（スパゲッティ）になっていると言えます。

ちなみに、コールグラフを作るのに、

有償ですが、Understandというツールがかなり強力です。

障害から把握する方法

---

私の実体験だと、
ソフトウェアを引き継いだ時点で、
既に市場で利用されていて障害（不具合）が
出てメンテナンスを求められることがあります。

ソフトウェアを縦横で切り出して、
コールグラフを書き出せると、
障害の状況からどこに不具合があるかを
発見することが容易になります。

たとえば、
ユーザーの入力に対して、
ある処理を行って、結果を表示する。
というソフトウェアの場合に、
処理内容で不具合があった場合は、
障害が発生しうる処理（Fucntion）を特定できます。
特定したあと、修正の影響がどの機能に及ぶかも把握できます。

一次受けのソフト開発などでは、

クライアントから過去別の受託会社が実装したコードと

最新でない仕様書を用いて開発請負するケースがあります。

そのような場合は上記の把握方法は、有用です。

二次受け以降に説明する場合でも中間資料を作る際に

必要な作業となります。