第1章 · 創造的な開発

協力、設計、デバッグ

プログラムは、1 回で書き上がるものではありません。調査し、設計し、大まかに作り、テストし、見直す。これを周を重ねて繰り返し、ユーザーが必要とすることを果たすまで続けます。

図は、一般的な開発の過程の 1 つを実行します。調査と振り返り, designing, prototyping and testing。赤いボールは手元の作業で、どの段階でも、チームを前の段階に戻すことがあります。周を重ねるごとに、プログラム（青）は完成に近づきます。3 周の後はバージョン 3 です。

過程は、計画に沿った段階を踏む秩序だった意図的なものにも、アイデアを試して、うまくいったものを残す探索的なものにもなり得ます。過程は数多くありますが、これらの 4 つの段階は、そのほとんどに共通しています。

この章は AP Computer Science Principles のビッグアイデア 1、創造的な開発で、選択問題の試験の 10–13% を占めます。扱う内容は、協力して取り組むこと（1.1）、プログラムが何をし、どんな入力と出力をもつか（1.2）、プログラムがどのように設計、作成、文書化されるか（1.3）、エラーがどのように見つかり、直されるか（1.4）です。章の最後のページにある、Create パフォーマンスタスクの作業でもあります。

1.1 · コンピューティングによる革新

それを良くする視点

コンピューティングによる革新は、その機能に不可欠な部分としてプログラムを含みます。

それは、自動運転車のような物理的なものにも、画像編集ソフトウェアのような非物理的なコンピューティングソフトウェアにも、電子商取引のような非物理的なコンピューティングの概念にもなり得ます。

革新は協力によって改良されます。効果的な協力は、それを設計した人々の才能と視点の多様さを反映した革新を生み、多様な視点はバイアスを避ける助けになります。メンバー全員が同じ経験を共有しているチームは、その経験に向けて作る傾向があります。

図は、アプリが扱わなければならない場合を挙げる、仮定のチームです。開発者 A 1 人では、12 のうち 5 しか思いつきません。開発者 3 人が合わせると 10 を思いつきます。残りはユーザーに意見を聞くことで得られます。12 のうち 12 です。

だから、ユーザーとの相談やコミュニケーションが重要です。見込みユーザーから集めた情報は、開発者がプログラムの目的をさまざまな視点から理解し、それらを十分に取り込んだプログラムを作る助けになります。

1.1 · 協力して取り組む

ペアプログラミング、オンラインツール、対人スキル

グループは、協力の一般的なモデルを使って革新を開発します。その 1 つがペアプログラミングです。

2 人のプログラマが 1 台のコンピュータを共有します。ドライバー（赤）がコードを入力し、ナビゲーター（青）は書かれた各行を確認し、間違いに気づき、先のことを考えます。図の途中で 2 人は交代します。役割はキーボードについていき、人についていくのではありません。2 人が書いているプログラムは、次のページのものです。

オンラインツールは、同じ部屋にいるかどうかにかかわらず、プログラマがアイデアや文書を共有し、それらにフィードバックを与えられるようにして、協力を支えます。

効果的なチームは、次のものを含む対人スキルを実践しています（これらに限りません）。

• コミュニケーション: 自分が何をしているか、なぜかをはっきり伝え、耳を傾けること。
• 合意形成: チーム全体が支持できる決定に至ること。
• 対立の解消: チームを損なわずに、作業をめぐる意見の相違を解決すること。
• 交渉: 合意に達するために、メンバーそれぞれの望みを調整すること。

1.2 · プログラムとコードセグメント

プログラムは何をするか、どのようにするか

プログラムは、コンピュータが実行したときに特定の課題を行う、プログラム文の集まりです。プログラムは、しばしばソフトウェアと呼ばれます。

total ← 0 REPEAT 3 TIMES { n ← INPUT() total ← total + n } DISPLAY(total / 3)

コードセグメントは、プログラムの一部である、プログラム文の集まりです。ここでは、2 行目から 6 行目までのループです（図の青）。

プログラムは、何をするかで大まかに説明できます。「ユーザーが入力した 3 つの数の平均を表示する」のように。あるいは、何をし、その文がどのようにそれを行うかで詳しく説明できます。「total を 0 にする。3 回、数を読み込んで n に入れ、total に加える。そのあと total / 3 を表示する」のように。

プログラムは、さまざまな入力や状況に対して動作する必要があります。図は、これを 2 回実行します。

その振る舞いは、実行中にどのように機能するかで、多くの場合、ユーザーがどう対話するかで説明されます。ユーザーが 3 つの数を入力すると、1 つの数が表示されます。

どの革新にも目的があります。問題を解決すること、あるいは創造的な表現で関心を追求することです。目的を理解している開発者は、プログラムをより良く開発できます。

1.2 · 入力と出力

データが入り、データが出る、さまざまな形で

プログラムの入力は、プログラムが処理するためにコンピュータに送られるデータです。プログラムの出力は、プログラムからデバイスに送られるあらゆるデータです。

どちらもさまざまな形をとります。触覚（タッチ、振動）、音声（話された言葉、音）、視覚（カメラの画像、画面）、テキストです。図は、それぞれの形の入力を 1 つずつ順にプログラムに送り込み、それぞれの形の出力を 1 つずつ外に送り出します。

入力はユーザーや他のプログラムから来ます。右下のテキスト出力は別のプログラムに送られ、そのプログラムにとっては入力です。

入力は、たいていプログラムの出力に影響します。そして出力は、たいていプログラムの入力または以前の状態、つまり保存された値にもとづきます。このプログラムは、受け取った入力の count（青）を保持しているので、画面への同じタッチでも、2 回目には異なる出力になり得ます。

前のページの平均を求めるプログラムでは、INPUT() の 3 回の呼び出しが入力で、DISPLAY が出力を画面に送りました。

1.2 · 出来事

起動されたときに実行される文

イベントは動作と結びつけられ、プログラムに入力データを与えます。

イベントは、キーが押されたとき、マウスがクリックされたとき、プログラムが開始されたとき、あるいは実行の流れに影響するその他の定義された動作が起きたときに生成されます。

イベント駆動プログラミングでは、プログラム文は、順次の制御の流れではなく、起動されたときに実行されます。上から 1 行ずつ実行されるものはありません。各イベントがそれを処理する手続きを実行し、プログラムは次のイベントを待ちます。

PROCEDURE onStart() { count ← 0 DISPLAY(count) } PROCEDURE onClick() { count ← count + 1 DISPLAY(count) } PROCEDURE onKeyPress() { count ← count - 1 DISPLAY(count) }

試験の参考資料にはイベントの構文がないので、ここでは各ハンドラーを手続きとし、仮定の環境が、そのイベントが起きたときにそれを呼び出すものとします。図では、プログラムが開始され、ボタンが 3 回クリックされ、キーが押され、ボタンがもう 1 回クリックされます。表示される値は 0, 1, 2, 3, 2, 3 です。

count はプログラム全体に属するので、各クリックの出力は、それ以前のイベントに左右されます。

1.3 · 開発の過程

反復的と漸進的

開発の過程は、秩序だった意図的なものにも、探索的な性質のものにもなり得ます。過程は数多くあり、ほとんどが調査と振り返り、設計、試作、テストの段階を使います。

反復的な過程は、過程全体を通して、フィードバック、テスト、振り返りにもとづく改良と修正を必要とします。そのために前の段階に戻ることがあります。下の行では、プログラム全体が最初の反復から、大まかな形で存在します。フィードバック（赤）が入るたびに戻され、どの部分も完成に近づいていきます。

漸進的な過程は、問題をより小さな部分に分け、各部分が動作することを確かめてから全体に加えます。上の行では、部分が 1 つずつ作られてテストされ、テストに通ったときにだけ全体に加わります。

この 2 つは対立するものではありません。ほとんどのチームは両方を行います。部分ごとに作り、フィードバックが届くたびに、各部分と全体を見直します。

1.3 · 調査と設計

要件、仕様、ストーリーボード、モジュール

プログラムの設計は、その要件を決めるための調査から始まります。

調査では、プログラムの制約と、それを使う人々の関心や興味を明らかにします。それは surveys, ユーザーテスト, interviews and 直接の観察 によって行えます。

プログラムの要件は、プログラムがどう機能するかを説明するもので、提供しなければならないユーザーとの対話の説明を含むことがあります。プログラムの仕様は、その要件を定めます。図書館の自習室を予約する仮定のアプリの場合は、次のとおりです。(1) ユーザーが日付を選ぶ。; (2) ユーザーはその日に空いている部屋を見る。; (3) ユーザーは 1 つを予約し、コードを受け取る。。

設計の段階では、仕様をどう達成するかを概説します。次のものを含むことがあります。

• brainstorming
• 計画とストーリーボードの作成
• モジュールと機能的な構成要素への整理
• ユーザーインターフェースのレイアウト図
• テストの戦略

図は、そのうちの 2 つを描きます。インターフェースのストーリーボードは、手順ごとに画面が 1 つあり、ユーザーのタップで画面から画面へ進みます。そして要件ごとに 1 つのモジュールに整理されたプログラムです。

1.3 · ドキュメント

他の人のコードの出典を明記する

プログラムのドキュメントは、コードセグメント、イベント、手続き、プログラムの機能と、それがどう開発されたかについての書かれた説明です。

コメントは、人が読むためにプログラムに書き込まれるドキュメントの一種で、プログラムの動き方には影響しません。コメントに対応していないプログラミング環境もあり、試験の参考資料にもコメントはないので、図では、各手続きのドキュメントをそのそばに置いています。

PROCEDURE average(numList) { total ← 0 FOR EACH num IN numList { total ← total + num } RETURN(total / LENGTH(numList)) } PROCEDURE isEven(n) {  RETURN(n MOD 2 = 0) }

average([6, 9, 3, 10]) は 7 を返します。ドキュメントは開発の全期間を通して書かれます。average のカードは、そのコードとともに育ちます。ドキュメントは、1 人でもチームでも、正しいプログラムを開発し保守する助けになります。次の読み手（あとで見る書き手自身であることも多い）が、各部分が何のためかをわかるからです。

共同で、あるいは別の出所から開発されたコードセグメントは、出典を明記することが重要です。出典の明記はプログラムのドキュメントの中に置いてよく、出所または元の作者の名前を含めるべきです。図では、isEven（青）は別の出所から来ており、そのカードがそれを示しています。

1.4 · 構文エラー、実行時エラー、論理エラー

それぞれがいつ現れるか

3 つのプログラムがあり、どれも [90, 75, 82] のすべての得点を表示するはずですが、それぞれ誤りが 1 つあります。

構文エラーは、プログラミング言語の規則に従っていないプログラムの誤りです。1 つ目のプログラムでは、5 行目に閉じかっこがありません。プログラムはまったく実行されません。どの行も実行されず、何も表示されません。

実行時エラーは、プログラムの実行中に起こる誤りです。実行時エラーはプログラミング言語ごとに定義されます。2 つ目のプログラムは、表示する前に i に 1 を足すので 75 and 82 を表示し、次に scores[4] を要求します。リファレンスシートでは、1 より小さい、またはリストの長さより大きいインデックスはエラーとなり、プログラムは終了します。

論理エラーは、アルゴリズムやプログラムが正しくない動作や予期しない動作をする原因となる誤りです。3 つ目のプログラムは、繰り返しが 1 回足りません。止めるものは何もなく、最後まで実行されますが、3 個の得点のうち 2 個しか表示されません。出力を期待される出力と比べて初めて、誤りに気づきます。

scores ← [90, 75, 82] i ← 1 REPEAT LENGTH(scores) - 1 TIMES { DISPLAY(scores[i]) i ← i + 1 }

修正すると、3 行目は REPEAT LENGTH(scores) TIMES になります。

1.4 · オーバーフローエラー

範囲外の数

オーバーフローエラーは、コンピュータが、定義された値の範囲外の数を扱おうとしたときに起こります。

多くのプログラミング言語は、整数を決まったビット数で保存するので、値の範囲が限られます。整数を 4 ビットで保存する仮定の言語を考えます。保持できる最大の数は 1111 で、これは 15 です。

図は 12 から数え上げます。1 ステップごとに、変わるビットが反転します。15 で 1 を加えるには 5 ビット目が必要になります（16 は 10000 です）が、記憶には 4 ビットしかありません。これがオーバーフローです。次に何が起こるかは言語によります。エラーで止まるものもあれば、収まるビットだけを残して誤った値（ここでは 0）で続けるものもあります。

実際の言語はもっと多くのビットを使うので、限界ははるかに大きくなりますが、それでも限界です。試験の参考資料の言語は違います。そこでは、整数の大きさはコンピュータのメモリだけで制限されます。

1.4 · テスト

定義された入力、期待される出力

テストでは、あらかじめ決めた入力を使って、アルゴリズムやプログラムが期待どおりの結果を出すことを確かめます。プログラマはその結果をもとにプログラムを修正します。

架空の映画館の要件：13歳未満、または65歳以上のチケットは$8で、それ以外の人は$12です。どの入力を試し、それぞれ何を期待すればよいかは、この要件からわかります。

PROCEDURE price(age) {  IF(age < 13 OR age ≥ 64) { RETURN(8) } RETURN(12) }

よいテスト入力は、期待される結果の違いを示し、入力データの両端（最小値と最大値）かそのすぐ外側にあります。間違いはそこに集まりやすいからです。ここでは、一方の境界の両側の12と13、もう一方の境界の両側の64と65、そして最小の年齢0です。

64でのテストは失敗します。コードは age ≥ 64 となっていますが、要件が意味するのは age ≥ 65 で、論理エラーです。40のような典型的な年齢でテストしても、これは見つかりません。

1.4 · エラーを見つけて直す

トレース、可視化、デバッグ、表示

エラーを見つけて直す効果的な方法は、テストケース、手作業のトレース、可視化、デバッガ、出力文の追加です。

findMax はリストの最大の数を返すはずです。[-3, -7, -2] でテストすると、−2ではなく0を返します。理由を調べるため、プログラマはループの中に DISPLAY(max)（青）を追加します。これが出力文の追加です。

PROCEDURE findMax(numList) {  max ← 0 FOR EACH num IN numList { IF(num > max) { max ← num }  DISPLAY(max) } RETURN(max) }

要素ごとに1行ずつ、手作業でトレースします。

max は変わりません。0より大きい要素がないからです。デバッガは、プログラムを一時停止して変数を表示することで、同じことを示します（図のセルは、プログラムの状態の可視化です）。エラーは3行目にあります。max は0から始まっていて、すべてが負の数のリストのどの要素よりも大きいのです。

修正は max ← numList[1] です。リストの要素から始めます。もう一度実行すると、追加した出力は−3, −3, −2を示し、−2を返します。そのあと、追加した DISPLAY を取り除きます。

1.1–1.4 · Create パフォーマンスタスク

自分のプログラムと、それに関する質問

Create パフォーマンスタスクは、この章で学んだことを実際に使う課題です。1.1〜1.4の開発プロセス、ドキュメント、テストを用いて、自分で選んだプログラムを作ります。

AP Digital Portfolio に3つのものを提出します。プログラムのコード、実行中の動画、そして個人プロジェクト参考資料（PPR）です。そのために、授業時間が少なくとも9時間与えられます。プログラムには、リストや手続きなど、決められた要素を入れなければなりません。

試験当日には記述式の解答があります。60分間で、自分のPPRにあるコードについての2問に答えます。解答中、PPRを見ることができます。

• 記述式 1: プログラムの設計、機能、目的
• 記述式 2(a): アルゴリズムの開発
• 記述式 2(b): エラーとテスト
• 記述式 2(c): データの抽象化と手続きの抽象化

タスクと記述式の解答を合わせてAPスコアの30%になります。選択問題の試験（120分で70問）が残りの70%です。

そのため、この章の問いは、自分のプログラムについてのものとして再び出てきます。目的と機能は何か、入力と出力は何か、何をどの入力でテストしたか、どんなエラーを見つけて直したか、といった問いです。