プログラム設計ツール

ソフトウェアが工学になった年

• 1968年10月、世界を代表する50人のプログラマがドイツ・ガルミッシュに集まり、大規模プログラムの失敗（遅延、予算超過、信頼性不足）の理由を議論した。彼らは欠けていたものを指し示す用語として ソフトウェアエンジニアリング を造語した。
• 不満は単純だった。建設家は建てる前に図面を描く。エンジニアは切断する前に計算を行う。プログラマは誰にも何を描かせていない状態でコードを入力していたのだ。
• その十年間で生まれた図面こそが、デザイン工程で使用するものとなる：構造化図（プログラムがどのように部分に分解されているかを示す）と状態遷移図（動作を示す）。
• この授業では、それらをどう読むか、どう作成するか、そして構造化図から擬似コードへどう変換するかを学ぶ。

デザインが決定すること

• 分析はプログラムが 何を（what） すべきかを定めた。デザインは どのように（how） を決定する: データ構造、アルゴリズム、モジュール、およびインターフェースである。
• デザイン工程で生み出される図面は、プログラマがコードにできるものである: 1つのアルゴリズムのロジック用 フローチャート、テキストによる同内容の 擬似コード、モジュール用の構造化図、動作用の状態遷移図。
• 各ツールは異なる質問に答え、試験ではどれが適切かを問う。

コード化される前に描かれたあるアルゴリズムのロジック

構造図

• 構造図は、プログラムがモジュール、サブROUTINES（サブルーチン）、およびそれら間で渡されるパラメータに分解された階層的な分解を示す。このトップダウン設計は、大きな問題をより小さな部分問題に分割し、それぞれが1つのモジュールとなる。
• 各モジュールは長方形で表される。上の呼び出し元と、下の呼び出されるモジュールを結ぶ線がある。同じレベルのモジュールは左から右へ呼ばれる。
• 線の横にある小さな矢印がデータを運ぶ: モジュール内へ 下 に渡されるパラメータ、呼び出し元へ 上 に返される結果。菱形は選択を、曲線矢印ループを表す。

Hierarchy on the lines, data on the arrows

例題: 図からシグネチャーを読む

                 CalculatePay
             /        |          \
    GetEmployee   CalculateBonus   CalculateTax
    returns:      takes: sales     takes: gross
    employeeID    returns: bonus   returns: tax

例題: 構造化図を作成する

構造化図から擬似コードへ

• 最上位モジュールがメインプログラムとなり、その下の長方形は矢印から読み取ったヘッダーを持つプロシージャまたは関数となる。メインプログラムは左から右の順序でそれらを呼ぶ。

PROCEDURE ProcessStudent()
    DECLARE Marks : ARRAY[1:10] OF INTEGER
    DECLARE Average : REAL
    Marks ← ReadMarks()
    Average ← CalculateAverage(Marks)
    CALL OutputGrade(Average)
ENDPROCEDURE

• 戻り値がある場合、それはFUNCTION … RETURNSであり、何も戻さないモジュールはPROCEDUREである。パラメータリストはちょうど下向きの矢印に相当する。

状態遷移図

• 状態遷移図 はシステムの 動作 を文書化する: あり得る 状態 と、それをある状態から別の状態へ移動させる イベント 。
• 各状態は円または角丸ボックス、各遷移は原因となるイベントでラベル付けされた矢印（ sometimes 伴うアクション）である。始点状態を示すマーカーがある。
• イベントを待って反応するシステムに適している: 自動販売機、信号機、ドアロック、ユーザーインターフェース。

Every state, every event, every arrow

演習例：ドアロック図を読む

ツールの選択

• プログラムがモジュールに分割され、その間で何がやり取りされるかを示す: 構造図。
• イベントに対するシステムの時間的な挙動、特にモードを持つ機械やインターフェースの動作を示す: 状態遷移図。
• 1つのアルゴリズムの段階的なロジックを示す: フローチャートまたは擬似コード。どれを選ぶべきか、および理由を述べよ。

見落としやすいポイント

理解できましたか