第5章処理の流れを復元し、変更影響を追えるようにする

要素の一覧だけでは、変更の影響を追えない

クラスやモジュールの役割を把握しても、どの順番で呼ばれ、条件によってどこへ分岐するかは別に確認しなければならない。文章だけで順序・分岐・呼出し関係を説明すると、読み手が頭の中で全体を組み立てる負担が残る。

そこで、確認した処理フローや要素間・システム間の関係、運用手順をUMLで可視化した。図で理解できることに加え、変更のたびに手作業で描き直さずに更新できることも必要だったため、テキストから生成・更新できる処理構造の図を使った。

すべての処理を一枚へ詰めると、関係を示しても読み取れない。理解に必要なユースケース単位で分け、代表的なメインフローに分岐・例外処理・呼出し関係を加えた。

起動方法ごとの前処理、共通のコア処理、出力処理も分離した。同じ処理と開始条件による差分を区別することで、何が共通で、どこが変わるかを確認できる。

開始条件の違いと、共通する処理を分ける

＋の付いた項目を選ぶと、詳しい説明が下に表示されます。

気になる項目を選ぶと、その役割や判断理由を確認できます。

利用する機能や起動方法ごとに、処理が始まる条件を確認しました。一つの巨大な図へまとめず、利用場面ごとに流れを分ける起点にしました。

起動方法によって異なる前処理を、共通処理から切り分けました。同じ処理に入る前の違いを残し、開始条件によって動作が変わる箇所を追えるようにしました。

共通して呼ばれる処理の順序と、渡される値・返される値をコードから調べました。個々のクラスの説明を、実際に動く順序へつなぐためです。

条件によって変わる呼出し先や例外処理を確認しました。コードから復元した流れを人が確認し、通常の順序だけでは見えない変更影響も調べられる形にしました。

前処理・共通処理から出力までを分け、どの変更がどの結果へ影響するかを追えるようにしました。その場限りの説明ではなく、後の仕様変更に合わせて更新する情報として残しました。

コードから復元した構造へ、実行順序と分岐を加えたことで、局所的な説明を処理全体の流れへ接続できた。処理構造の図は見た目のためではなく、その流れを確認し、後の変更に合わせて修正するための表現だった。

ただし、人が読む図と、質問に必要な根拠を検索する資料では使い方が異なる。次章では、確認した仕様をそれぞれの利用方法に合う形へ分ける。