ITパスポート試験 用語辞典
- 別名:
- コーディング
- 分野:
- マネジメント系 » システム開発技術 » システム開発技術
- 出題歴:
- 21年春期問49
- 重要度:
(Wikipedia プログラミング (コンピュータ)より)
プログラミング(programming)とは、プログラムを作成することにより、人間の意図した処理を行うようにコンピュータに指示を与える行為である。
プログラミングの過程
ほとんどのプログラミングは、プログラミング言語を用いてソースコードを記述することで行われる。これをコーディングという。
ある程度複雑なプログラムを作成する場合、一度コーディングを行っただけでは、プログラムが意図したとおりに動作することはまずない。これは、プログラムの入力ミスや、プログラム構造の論理的な誤りになどによるものである。これをバグ(bug)と呼ぶ。そこで、プログラムが意図したとおりに動作するか、検証作業を行う必要がある。これをテストという。テストによりバグが見つかれば、それを修正する必要がある。この修正作業をデバッグ(debug)という。
また、ある程度の期間使われるプログラムでは、使用しているうちに、プログラムの性能や機能に新しい要求が発生したり、プログラムの設定を変更する必要がでてきたり、テストにより発見できなかったバグが見つかることがある。このような事態に対応するため、プログラムを保守していく作業が必要になる。
プログラマーについて
プログラミングをする人をプログラマー(Programmer)という。プログラミングを行うためには、対象領域に関する知識、アルゴリズム、論理学などの様々な専門知識が要求される。
職業としてのプログラマー
プログラマーの仕事
プログラマ
プログラミングを行う者をプログラマと呼ぶ。その仕事には以下のような作業が含まれる。
- 要求分析
- ソフトウェア設計
- プログラム仕様
- ソフトウェアアーキテクチャ
- コーディング
- コンパイル
- ソフトウェアテスト
- ソフトウェアドキュメンテーション
- ソフトウェア保守
この他、プログラムが、作者以外の人によって利用される場合には、プログラムの利用方法や機能について質問を受けることがある。プログラムを、意図したとおり稼働させてゆくためには、これらの問い合わせに対応する必要もある。
一般に、職業としてプログラミングを行う場合、これらの作業が工程として含まれる。大規模なプログラミングでは、これらの作業を分業することも多い。
このような業務は、ソフトウェア工学という学問のソフトウェア開発工程の分野として扱われる。
プログラミング言語
プログラミング言語
プログラミング言語が異なれば、プログラミングのスタイル(プログラミングパラダイム)も異なる。どの言語を使うかの判断には、企業としてのポリシー、その用途への適合性、サードパーティのパッケージが使えるか、個人の好みなど様々な要素がある。理想的には、用途に最も適した言語を選ぶべきである。しかし、その言語を使えるプログラマが十分揃えられないとか、その言語の処理系に問題があるとか、実行時の効率が悪いといった問題から、最適な言語を選べないこともある。
アレン・ダウニー(Allen Downey) は、著書 「計算機科学者のように考える方法」(How To Think Like A Computer Scientist)で次のように書いている。
- 言語が違えば、詳細も違って見えるが、どんな言語にも次のような基本的命令要素がある。
- 入力: キーボード、ファイル、その他の機器からデータを入手する。
- 出力: 画面にデータを表示したり、ファイルその他の機器にデータを送る。
- 演算: 加減算のような基本的算術操作を行う。
- 条件付き実行: 条件をチェックして、一連の処理を行うか否かを判断する。
- 繰り返し: ある処理を繰り返し実行する。通常、毎回何かが変化している。
プログラミングパラダイム
プログラミングパラダイム
今日までに、プログラミングの進歩に貢献したパラダイムとして、次があげられる:
- プログラムの実行制御の仕組みとして、命令から命令へと直接移動する代わりに、論理的な順接・反復構造を用いてロジックの抽象化を目指した構造化プログラミング
- 変数の使用による副作用の発生を排除しようとした関数型プログラミング
- 宣言型プログラミングを可能にした論理プログラミング
- データと手続きの直交化を押し進め、人間の概念構成に近い表現を可能にしたオブジェクト指向プログラミング
- 人間ではなくコンピュータがプログラムを生成する遺伝的プログラミング(遺伝的アルゴリズムの拡張)
プログラミングには、文字による言語を記述する方法ばかりではなく、視覚的な表現や図形的な記号を入力するビジュアルプログラミングという方法もある。
プログラミングの歴史
最古のプログラマブルな機械(プログラムによって動作の変化を制御できる機械)としては、1206年にアル=ジャザリが作った二足歩行ロボットがあると言われている。アル・ジャザリのロボットは、ボートに4体の演奏人形が乗ったもので、宮廷のパーティで池に浮かべて音楽を演奏したと言われている。プログラムはカムにあり、それによって小さなてこを押して、打楽器を演奏する。カムは実際には円筒にペグが突き刺された形であり、このペグの配置でプログラミングし、演奏パターンを変更した。
1801年に開発されたジャカード織機がプログラマブルな機械の起源とされることが多い。この機械は、穴を開けた一連の厚紙(パンチカードの原型)を使った。穴の配列が布を織る際のパターンに対応している。従って、カードを入れ替えることで全く異なる布を織ることができた。1830年ごろには、チャールズ・バベッジがパンチカードを使った解析機関を考案した。
このような先駆者の発明をさらに進化させたのがハーマン・ホレリスであり、1896年にタビュレイティング・マシン・カンパニー(Tabulating Machine Company、後のIBM) を設立した。彼はホレリス式パンチカード、タビュレーティングマシン、キーパンチ機などを発明した。これらの発明が情報処理産業の基礎となったのである。1906年には、タビュレーティングマシンにプラグボードを追加することで、組み替えれば様々な仕事ができるようになった。これがプログラミングへの第一歩である。1940年代には、プラグボードによるプログラマブルな機械が各種登場していた。初期のコンピュータにもプラグボードでプログラムを組むものがあった。
フォン=ノイマン・アーキテクチャの発明により、プログラムをコンピュータのメモリに格納できるようになった。初期のプログラムは特定の機械の命令をそのまま並べて作られ、二進法で記述されることが多かった。初期のコンピュータでは、電気的配線を変更したり、トグルスイッチなどで機械語を直接コンピュータに入力することで、プログラミングが行われた。しかし、機械語の命令は人間にとって扱いにくく、代わりに機械語の命令にニーモニックとよばれる略語を割り当てた、アセンブリ言語が開発され、プログラマは命令をテキスト形式で記述できるようになった。アセンブリ言語は、コンピュータのCPUによって種類が異なるため、アセンブリ言語でかかれたプログラムは、他機種のコンピュータで利用することができなかった。また、単純な処理をアセンブリ言語で記述する場合にも、基本的な処理命令を大量に記述する必要があった。
そこで、特定のコンピュータに依存しない記述方法で、処理の内容をより抽象的に記述するためのプログラミング言語が開発された。そして、プログラミング言語によって記述されたプログラムを、コンパイラを利用して機械語に翻訳することで、実行プログラムを作成することが一般的になった。1954年、最初のプログラミング言語の1つであるFORTRANが開発された。これにより、演算を直接数式のように記述できるようになった(例えば、Y = X*2 + 5*X + 9)。このプログラムの記述(あるいは「ソース」)はコンパイラと呼ばれる特別なプログラムで機械の命令に変換される。他にも様々な言語が開発された(ビジネス用途のCOBOLなど)。プログラムの入力は依然としてパンチカードやさん孔テープで行われていた。1960年代後半、記憶装置や端末の価格が低下してきたことにより、キーボードから直接コンピュータにプログラムを入力できるようになってきた。このため、修正が容易に行えるようテキストエディタが開発された。プログラミング言語の処理方式は、コンパイラ方式とインタプリタ方式に分類される。
コンピュータの能力は時と共に飛躍的な進化を遂げた。このため、より抽象化されたプログラミング言語が開発されるようになっていった。抽象化レベルの高い言語はオーバーヘッドも大きいが、コンピュータ自体の性能の進化が激しいため、多少オーバーヘッドが増えても以前よりも高性能な動作が実現された。このような抽象化レベルの高い言語の利点は、習得が容易であることと、プログラム作成時間が短縮されることである。しかしそれでも、巨大で複雑なプログラムや、高速性が何よりも重視されるプログラムでは、現在でも比較的低レベルな言語を使っている。
20世紀後半を通して、先進国ではプログラマが魅力的な職業の1つとされてきた。しかし、発展途上国の安い労働力をプログラミングに利用する傾向が強まっている。この傾向がどれだけ続くのか、それによってどのような影響があるのかは未知数である。
最近のプログラミング
品質
ソフトウェア開発手法がどうであれ、最終的にはプログラムは基本的な属性を満たさなければならない。プログラミングにおいてそれを気にかけておくことで、デバッグやその後の開発およびユーザーサポートにかかる時間とコストを削減できる。ソフトウェア品質を確保する方法は様々だが、以下の5つの属性が最も重要である。
- 効率性
- リソース使用量(プロセッサ、メモリ、デバイス、ネットワークその他)は可能な限り少ない方がよい。
- 信頼性
- プログラムは正しく動作しなければならない。それは単にソースコードが正しく実装されているというだけでなく、誤差の伝播を少なくするとか、典型的な値の範囲に関するエラー(オーバーフロー、アンダーフロー、ゼロ除算など)を防ぐという観点も含まれる。
- 頑健性
- データ型の間違いなど実行時エラーによるプログラム停止を誘発するような事態に対処できなければならない。これは、特にユーザーとのやり取りの場面や、エラーメッセージの処理などで重要となる。
- 移植性
- 再プログラミングしなくとも、任意のソフトウェア環境やハードウェア環境で動作すべきである。
- 可読性
- 後の保守をコーディングした人が行うとは限らないため、命名規則やコメントなどをわかりやすくしておく。
方法論
ソフトウェア開発の第一段階は要求分析であり、その後モデル化し、実装し、デバッグする。これら作業については様々な方法論がある。要求分析で一般的な方法論としてユースケース分析がある。
モデル化技法としてはオブジェクト指向分析設計(OOAD)とモデル駆動型アーキテクチャ(MDA)がある。統一モデリング言語(UML)は OOAD や MDA での記法として使われている。
データベース設計では、似たような技法として実体関連モデルがある。
実装技法としては様々なプログラミングパラダイムがある(オブジェクト指向プログラミング、手続き型プログラミング、関数型プログラミング、論理プログラミングなど)。
デバッグには統合開発環境(IDE)が使われることが多い(Visual Studio、NetBeans、Eclipseなど)。独立したデバッガ(gdbなど)も使われている。
言語利用状況
どのプログラミング言語が一番使われているかというのは、非常に難しい問題である。言語によっては特定の分野でのみ一般的なものもあるし(例えば、COBOLは企業のデータセンターでよく使われており、FORTRANは科学技術計算に強く、C言語は組み込み市場で強い)、汎用的に様々なアプリケーションを書くのに使われている言語もある。
言語の人気を測定する手段として、求人広告に挙げられている言語を数え上げる方法がある。また、既存のソースコードの行数を言語毎に推計する方法もある(ただし、言語によって同じ機能を実現するのに必要な行数が異なるため、補正が必要)。
デバッグ
バグだらけのプログラムは使いものにならないため、デバッグは重要である。C言語やアセンブリ言語などは、慣れたプログラマであっても、バッファオーバーランや不正なやメモリの初期化忘れ/解放忘れといったバグを作りこみやすい。バッファオーバーランは隣接するメモリ領域を破壊し、全く関係ない箇所でプログラムに異常が発生する原因となる。このため、C言語やC++でのプログラミング向けに Valgrind、Purify、BoundsChecker といったメモリデバッガが開発されてきた。
Java、C#、PHP、Python といった言語にはそのような問題がほとんどないが、性能は低い。ただし、データベースアクセスやファイル入出力が性能を決定付けるような分野では、これらの言語の性能でも何ら問題ない。また、最近ではこれらの言語の処理系でも性能が向上してきている。
プログラミングレス思想
プログラミングは多くのバグが発生する非効率的な手法であるとの思想から、プログラミングを行うことなくプログラムを生成する開発ツールが生み出されている。しかし、型決めして効率性を高めるほど制限事項が多くなり、制限事項を減らし自由度を高めようとするとプログラミング以上に非効率となってしまうため、ごく限定された分野でしか成功していないのが実状である。
大会
- Robocode
- ACM国際大学対抗プログラミングコンテスト
- U-20プログラミングコンテスト
- PALROコンテスト
議論
プログラムを書くことはアートなのか、クラフトなのか、工学なのかという議論がある。よいプログラミングには、それら3つの要素すべてが必要とされ、最終的に効率的で保守しやすいソフトウェアを生み出すことを目的とする(何が効率的で、何が保守しやすいかという判断も様々である)。
出題例
- 個々のプログラムを結合し,ソフトウェアが要求どおり動作するかを検証する。
- ソフトウェアを階層構造に基づいて機能分割する。
- プログラム言語の文法に従って処理手順などを記述し,その処理手順などに誤りがないかを検証する。
- プログラムの処理手順を図式化する。
正解
- 品質特性
- 外部設計
- 内部設計
- コーディング
- コンパイラ
- ホワイトボックステスト
- デバッグ
- コードレビュー
- 単体テスト
- 結合テスト
- システムテスト
- 運用テスト
- ブラックボックステスト
- 回帰テスト
- 受入れテスト
- ソフトウェア導入
- ソフトウェア保守
- ファンクションポイント法
- 類推見積法
- プログラムステップ法
- 標準タスク法
このページのWikipediaよりの記事は、ウィキペディアの「プログラミング (コンピュータ)」(改訂履歴)の記事を複製、再配布したものにあたり、このページ内の該当部分はクリエイティブ・コモンズ 表示 - 継承 3.0 非移植 ライセンスの下 に提供されています。