STS分割（変換分析）

概要

構造化設計における 変換分析（Transform Analysis） の手法。DFD（データフロー図）からモジュール構造図（SC: Structure Chart）を導出する際に使う分割技法。

システム全体のデータフローを Source → Transform → Sink の3つに分類することで、主モジュールとその配下のモジュール群を体系的に導出できる。

3つの構成要素

区分	別名	役割	典型的な処理例
Source（ソース）	入力系	物理的入力 → 論理的入力への変換	ファイル読み込み、センサー入力、入力バリデーション、文字コード変換
Transform（トランスフォーム）	中心変換	システムの本質的なビジネスロジック	計算、判定、データ加工
Sink（シンク）	出力系	論理的出力 → 物理的出力への変換	フォーマット変換、画面表示、ファイル書き込み、印刷

ポイント： Transformはデータが最も抽象化（物理的な入出力形式から切り離された状態）されている部分。

中心変換（Central Transform）の識別手順

DFDのデータフローを 入力側から たどる
- 「この処理はまだ入力を論理的に加工しているだけか？」と問いながら進む
- 入力の加工とみなせなくなった手前が Source / Transform の境界
DFDのデータフローを 出力側から たどる
- 「この処理はまだ出力を物理形式に変換しているだけか？」と問いながら戻る
- 出力の加工とみなせなくなった手前が Transform / Sink の境界
両方向から挟み込んで残った部分が 中心変換

識別の判断基準

物理的入力 ──[Source]──▶ 論理的入力 ──[Transform]──▶ 論理的出力 ──[Sink]──▶ 物理的出力

         ←── ここまでSourceとみなせる ──→
                                   ←── ここからSinkとみなせる ──→
                         ↑
                    この部分がTransform

論理的入力：システムが本来扱いたいデータ形式（例：金額、数量）
物理的入力：実際に入力される形式（例：CSV文字列、バイナリデータ）

モジュール構造図への変換手順

主モジュール（Main Control）を配置
- DFDの中心変換に対応する最上位モジュール
Source系モジュールを左に展開
- 「Get 〇〇」という名前をつける慣習がある
- 入力データを取得・変換する処理をモジュールとして列挙
Transform系モジュールを中央に展開
- 「Transform 〇〇」「Process 〇〇」など
- 中心変換の内部処理をモジュールに分解
Sink系モジュールを右に展開
- 「Put 〇〇」という名前をつける慣習がある
- 出力データを加工・出力するモジュールを列挙

モジュール構造図のイメージ

                    ┌──────────────────┐
                    │   Main Control   │
                    └────────┬─────────┘
           ┌─────────────────┼──────────────────┐
           ▼                 ▼                  ▼
  ┌────────────────┐ ┌──────────────┐ ┌────────────────┐
  │ Source Module  │ │  Transform   │ │  Sink Module   │
  │  (Get Data)    │ │   Module     │ │  (Put Result)  │
  └────────┬───────┘ └──────┬───────┘ └───────┬────────┘
       ┌───┴───┐            │              ┌───┴───┐
       ▼       ▼            ▼              ▼       ▼
   Read     Validate    Process        Format   Output

トランザクション分析との比較（重要）

システムアーキテクト試験では 2つの分析手法の使い分け がよく問われる。

	変換分析（STS分割）	トランザクション分析
適用場面	1本のデータが線形に変換されるフロー	入力種別によって処理が分岐するフロー
DFDの形状	入力 → 処理 → 出力の一直線	1つの入力が複数のトランザクションタイプに分岐
モジュール構造	STS 3系統に分割	トランザクションセンターと各トランザクション処理に分割
典型例	バッチ処理、データ変換システム	ATM（振込・引出・照会など）、メニュー選択システム

組み合わせて使う

実際のシステムは混在することが多い。

大きな構造 → 変換分析 でSTS分割
分岐が発生している部分 → トランザクション分析 を局所適用

モジュール設計の品質指標

STS分割後のモジュールを評価する際の観点。

結合度（低いほど良い）

レベル	種類	説明
低（良）	データ結合	引数でスカラー値のみ受け渡し
↑	スタンプ結合	引数でデータ構造を受け渡し
↑	制御結合	フラグや制御コードを渡して相手の動作を制御
↑	外部結合	外部宣言された変数を共有
↑	共通結合	グローバル変数を共有
高（悪）	内容結合	別モジュールの内部を直接参照・変更

凝集度（高いほど良い）

レベル	種類	説明
高（良）	機能的凝集	単一の明確な機能のみ
↑	情報的凝集	同一データ構造に関する複数機能
↑	連絡的凝集	同じデータを順序付きで処理
↑	手順的凝集	順序があるが同一データでない
↑	時間的凝集	同時期に実行されるが無関係な処理
↑	論理的凝集	論理的に似ているだけで無関係
低（悪）	暗合的凝集	全く無関係な処理の寄せ集め

試験でよく問われるポイント

午後I 記述式対策

DFDを読んで「どこが中心変換か」を答えさせる問題
- 識別の根拠を「〜のデータは物理的入力の加工であるため Sourceとみなし、〜から中心変換と判断した」と書けるように
モジュール構造図上で結合度・凝集度を評価する問題

午後II 論述対策

STS分割を論述で使う場面：

設計手法の選択根拠：「データが線形に変換される処理であったため変換分析を適用した」
モジュール分割方針：「Source・Transform・Sinkに分割し、各モジュールの責務を明確にすることで保守性を高めた」
設計上の工夫：「中心変換を独立させることで、入出力形式の変更が他モジュールに影響しない構造とした」

Hikaru's notes