何人かで作るときの段取り

ソフトウェアを作る作業は、大きく工程という単位に分かれている。名前と順番はだいたいこうだよ。

• 要件定義 … 何ができればいいのかを決める。まだ作り方の話はしない
• 外部設計 … 利用者から見える面を決める（画面や帳票）
• 内部設計 … 中の作りを決める（どんな部品に分けるか）
• プログラミング … 実際にコードを書く
• テスト … 決めたとおりに動くか確かめる
• 運用・保守 … 動かし続けて、直し続ける

試験は「この作業はどの工程のものか」をよく聞いてくる。決めているのは何かで見分けるといいよ。やりたいことなら要件定義、見た目なら外部設計、部品の分け方なら内部設計だ。

設計が2つに分かれているのが、はじめは分かりにくいところだよ。分け目は利用者に見えるかどうかだ。

外部設計は、利用者から見える面を決める。画面のレイアウト、入力の順番、印刷される帳票。見えるものだから、できあがりを利用者（顧客）に見せて承認をもらうのがこの工程だよ。

内部設計は、中の作りを決める。機能をどんな部品（プログラム）に分けるか、データをどう持つか。利用者には見えないので、作る側だけで決めていい。

試験では固い言い方も出てくる。ソフトウェア方式設計は「要件を最上位レベルの構造に置きかえて、部品を洗い出す」工程で、内部設計の入口にあたる。もっと細かく、1行ごとの処理まで決めるのがソフトウェア詳細設計だよ。

いちばん古くからある進め方が ウォーターフォールモデル だよ。名前のとおり滝で、前の工程が終わってから、その成果物を使って次の工程に進む。設計が終わるまでコードは書かない、という進め方だね。

強いのは見通しのよさだ。工程ごとに終わりがはっきりしているので、どこまで進んだかを数えやすいし、大人数で分担しやすい。

弱点は2つある。1つは手戻りが高いこと。上流で決め間違えていると、下流のコードもマニュアルも全部やり直しになる。しかも間違いに気づくのは、たいてい下流に来てからだ。

もう1つは、動くものが最後まで出てこないこと。利用者は完成するまで確かめられないので、「思っていたのと違う」が最後に判明する。

ウォーターフォールの弱点を埋めるために考えられたやり方が、試験によく出てくる。

プロトタイピング は、早い段階で試作品を作って利用者に見せ、感想をもらってから作り込む。「思っていたのと違う」を早めに見つけるための方法だよ。

スパイラルモデル は、要求分析から実装までのひと回りを、部分ごとに何度も繰り返す。優先度の高いところから作り、渦を巻くように少しずつ範囲を広げていく。

2つは目的が近いけれど、聞かれ方が違う。「試作品を見せる」ならプロトタイピング、「開発プロセスを繰り返す」ならスパイラルだよ。

繰り返す考えをもっと押し進めたのが アジャイル開発 だよ。短い期間で動くものを作って見せる、を何度も回す。分厚い仕様書より動くソフトウェア、計画を守ることより変化に合わせることを大事にする。

そのやり方のひとつが スクラム。言葉が多いので、役割と行事に分けて覚えよう。

• スプリント … 1〜4週間の短い区切り。この中で作って見せる
• プロダクトバックログ … やりたいことを優先順に並べた一覧
• デイリースクラム … 毎日決まった時間に短く集まり、進みぐあいと困りごとを共有する
• スプリントレビュー … スプリントの終わりに、できたものを見せる
• レトロスペクティブ … 作ったものではなく進め方そのものを振り返る

人の呼び名も決まっている。プロダクトオーナがバックログの中身と並び順を決め、スクラムマスタが進め方を支え、開発者が作るよ。

アジャイルの中でも、やることを具体的な習慣として並べたのが XP（エクストリームプログラミング） だよ。代表的なものを挙げるね。

• ペアプログラミング … 2人で1つのプログラムを書く。役割を交替しながら互いに確かめるので、話が通じやすくなり品質も上がる
• テスト駆動開発 … テストを先に書いてから、それを通すコードを書く
• リファクタリング … 外から見た動きを変えずに、中身の作りを整える
• コーディング標準 … 書き方をそろえて、誰が書いても読めるようにする
• 継続的インテグレーション … 結合とテストを、待たずに何度も繰り返す

リファクタリングは間違えやすいので気をつけて。外部仕様は変えないのが約束だよ。動きを変えたらそれは機能追加や修正で、リファクタリングとは呼ばない。

大きなプログラムは、モジュールという部品に分けて作る。君が関数やクラスに切り出してきたのと同じ話だよ。

分け方の良し悪しを言うための物差しが2つある。ここは向きを取りちがえやすいので、理由つきで覚えよう。

凝集度（モジュール強度）は、1つのモジュールの中がどれだけ1つの目的にまとまっているか。強いほうがよい。中身が1つの目的だけなら、直す理由も1つなので、直す場所が1か所で済むからだよ。なんでも詰め込んだモジュールは、関係ない用事で何度も開くことになる。

結合度は、モジュール同士がどれだけ深く絡んでいるか。弱いほうがよい。絡みが浅ければ、片方を直すときにもう片方を読まなくて済むからね。

覚え方は「中はぎゅっと、外とはゆるく」。この2つがそろっている状態を、モジュールの独立性が高いというよ。

結合度は「弱い・強い」だけでなく、段階に名前が付いている。弱い（よい）ほうから並べるよ。

• データ結合 … 必要なデータ項目だけを引数（パラメタ）で渡す。いちばん弱くて、いちばんよい
• スタンプ結合 … データのかたまりを丸ごと渡す。使わない項目まで見えてしまう
• 制御結合 … 相手の処理を切り替えるための引数を渡す。渡された側の動きが呼ぶ側に左右される
• 外部結合・共通結合 … 共通の（グローバルな）領域を通してやり取りする。誰が書きかえたか追えなくなる
• 内容結合 … 相手の内部を直接のぞいたり書きかえたりする。いちばん強くて、いちばん悪い

受け渡しが引数だけで済んでいるかどうかが分かれ目だよ。引数だけならデータ結合、共通の置き場を経由し始めると一気に強くなる。

ここからは君が書いた class の話だよ。試験の言葉に置きかえるだけなんだ。

class Dog { ... } は設計図で、これが クラス。new Dog() で作った実物が インスタンス（オブジェクト）だよ。クラスは1つでも、インスタンスはいくつでも作れる。逆に、1つのインスタンスが複数のクラスから作られることはない。

「クラス」と「インスタンス」の関係は、種類と実例の関係でもある。「公園」がクラスなら「代々木公園」がインスタンス、という具合だね。

そのクラスの中で、データ（属性）と処理（振る舞い＝メソッド）を1つにまとめて、中の詳細を外から触らせないようにすることを カプセル化 というよ。ありがたいのは、中の作りを変えても外の使い手が影響を受けにくいこと。これを情報隠蔽ともいう。

extends で書いてきたのが 継承 だよ。もとになるクラス（スーパクラス／基底クラス）の属性や機能を、サブクラス（派生クラス）が受け継ぐ。サブクラスは「〜の一種」になっているのが目印だ。「トラック」は「自動車」の一種だからサブクラスだけれど、「タイヤ」や「エンジン」は部品なので継承ではないよ。

そして 多相性（ポリモーフィズム）。同じ呼び出しをしても、相手のクラスによって違う動きになることだよ。speak() と書いておけば、犬なら犬の鳴き方、猫なら猫の鳴き方になる、というあれだね。

これを実現する道具が オーバーライド。サブクラスで同じ名前のメソッドを作り直すことだよ。似た名前のオーバーロードは、同じ名前で引数の型や数が違うものを並べることで、別のものだから混ぜないようにね。

設計を人に渡すとき、書き方が人によって違うと読めない。そこで図の描き方をそろえたのが UML だよ。代表的な図を、構造を表すものとふるまいを表すものに分けて覚えよう。

構造を表す図。

• クラス図 … クラスと、クラス同士の関連。継承（汎化）もここに描く
• オブジェクト図 … クラスではなくインスタンス同士の関係

ふるまいを表す図。

• シーケンス図 … オブジェクト間のやり取りを時系列に並べる
• ユースケース図 … 利用者とシステムのやり取りを外側から描く
• アクティビティ図 … ある振る舞いから次の振る舞いへの流れ
• 状態遷移図 … 何をきっかけに状態が変わるか

ちなみに、できあがったプログラムから設計の情報を取り出して図にすることを リバースエンジニアリング というよ。逆向きだから「リバース」だね。