10. システム/アプリ開発

10.1. システム開発の流れ

システムは企画→要件定義→開発→運用→保守というフェーズでシステムの一生は表せられ、ソフトウェアライフサイクルと呼ばれる。

10.1.1. 要件定義

この工程は作成するシステムにどんな機能が求められているか明らかにする。 要件を取りまとめた結果について要件定義書という形で文書に残する。

10.1.2. 機能要件と非機能要件

機能要件

業務要件を実現するために必要な機能に関する要件。

非機能要件

システムが満たすべき品質要件、技術要件、運用/操作要件など。

10.1.3. システム設計

要件定義の内容を具体的なシステムの仕様に落とし込む作業のこと。 システム設計は主に3つの段階に分かれる。

外部設計

「利用者から見た」設計を行う。ユーザインターフェスなどの利用者が直接手を触れる部分の設計を行う。

内部設計

「開発者から見た」設計を行いう。外部設計を実現するための実装方法やデータ設計などを行う。

プログラム設計

プログラムをどう作るかという視点で設計を行う。プログラムの構造化設計やモジュール同士のインターフェス仕様がこれにあたる。

10.2. システム開発手法

10.2.1. ウォータフォールモデル

10.2.2. プロトタイピングモデル

10.2.3. スパイラルモデル

10.2.4. RAD(Rapid Application Development)

RADは迅速なアプリケーション開発という意味であり、エンドユーザと開発者による少数構成のチームを組み、開発支援ツールを活用するなどして、とにかく短期間で開発することを重要視した開発手法のこと。

RADツールとして有名なのはVIsual Basicのビジュアル開発環境などが該当する。 RADではプロトタイプを作成しそれを評価するサイクルを繰り返すことで完成度を高める。このフェーズが無限に繰り返されないように開発の期限を設けます。これはタイムボックスと呼ばれる。

10.2.5. アジャイル開発とXP(extreme Programming)

アジャイル開発はスパイラルモデルの派生型であり、より短い反復単位を用いて迅速に開発を行う手法である。この開発手法では1つの反復で1つの機能を開発し、反復を終えた時点で機能追加されたソフトウェアをリリースする。

アジャイル開発の一種であるXPは少人数の開発に適用しやすいとされ、既存の開発手法が仕様を固めて行う方式であったのに対し、XPは変更を許容する柔軟性を実現する。

XPでは5つの価値と19のプラクティスが定義されており、そのうち開発プラクティスとして定められているのは以下6つである。

プラクティス	説明
テスト駆動開発	実装前にテストを定め、テストをパスするように実装を行う。テストは自動テストであることが望まれる
ペアプログラミング	2人1組でプログラミングを行う。1人がコードを書きもう1人がコードの検証役になり、互いの役割を入れ替えながら作業を進める
リファクタリング	完成したプログラムでも内部のコードを随時改造する。冗長コードを改めるに留める。
ソースコードの共有所有	コードの制作者に断りなく、チーム内の誰もが修正を行うことができる。チーム全員がコードの責任を負う
継続的インテグレーション	単体テストを終えたプログラムはすぐに結合し結合テストを行う
YAGNI	今必要とされるシンプル機能だけの実装に留める

10.3. 業務のモデル化

モデル化は現状のプロセスを抽象化し視覚的に表すことであり、システムが実現すべき機能の洗い出しのために行われる。

代表的なものにDEFとER図、状態遷移図がある。

10.3.1. DED(Data Flow Diagram)

DEFはデータの流れを図として表したもの。

DFDの例

10.3.2. ER図(Entity-Relationship)

ER図は実体と関係という概念を用いてデータ構造を図に表したものである。

10.3.3. 状態遷移図

状態遷移図は状態の移り変わりを矢印で表した図のこと。

10.4. 外部設計

10.4.1. CUIとGUI

CUIは文字を打ち込むことでコンピュータに命令を伝えて処理させる方式。マウスなどは一切用いない。

GUIは画面にアイコンやボタンを表示してそれをマウスなどのデバイスで操作し命令を伝えるグラフィカルな操作方式であり、現在の主流である。

10.4.2. GUIで用いられる部品

部品	説明
メニューバ	アプリケーションの基本領域であり、ここに各コンポーネントが配置される
ウィンドウ	アプリケーションを操作するための項目が並んだメニュー
プルダウンメニュ	クリックすると垂れ下がり表示されるメニュー
テキストボックス	文字入力用の短形領域である
チェックボックス	選択肢を複数選択したり特定の項目をON/OFFさせる用途に用いられる
ラジオボタン	複数ある選択肢から1つだけを選ばせるのに用いる

10.5. 詳細設計

各プログラムをモジュール単位に分解・階層化させることはプログラムの構造化設計と言う。

シンプルで保守性に優れたプログラムを作るための構造化設計のためのモジュール分割法には「データの流れに注目した技法」と「データの構造に注目した技法」がある。

10.5.1. モジュール分けの利点と留意点

モジュール分けのメリットとして以下のような点があげらる。

• 作業の分担が可能
• 再利用が簡単
• 修正が一部で済む

モジュール分けした後の作業は3つの制御構造を用いてプログラミングする構造化プログラミングへと移る。

10.5.2. モジュール分割技法

「データの流れ」に着目した技法は以下の3種類。

STS分割法

入力処理、変換処理、出力処理という3つのモジュール構造に分割する手法

トランザクション分割法

プログラムを一連の処理(トランザクション)単位に分割する方法

共通機能分割法

プログラム中の共通機能をモジュール分割する方法

10.5.3. モジュール独立性を測る尺度

モジュールの独立性を測る尺度として用いられるのはモジュール強度とモジュール結合度である。

モジュール強度

モジュール結合度

10.6. プログラミング

10.6.1. プログラム言語

プログラム言語には低水準言語と高水準言語の2種類がある。

低水準言語

コンピュータが理解しやすいプログラム言語のこと。 機械語やアセンブラがある。

高水準言語

人間が理解しやすいプログラム言語のこと。 COBOL、C、C++、Javaなどがある。

10.6.2. 言語プロセッサ

言語プロセッサは人間が記述したプログラム(ソースプログラム)を機械語のプログラムに変換するプログラムのこと。

翻訳の仕方によって、アセンブラ、コンパイラ、インタプリタの3種類に分けられる。

アセンブラ

アセンブラ言語で書かれたソースプログラムを機械語に翻訳するもの。

コンパイラ

ソースコードの内容を最初に全て機械語に翻訳するもの。 作成途中で確認のため動かすと言った手法は用いれない。

インタプリタ

ソースコードに書かれた命令を１つずつ機械語に翻訳しながら実行する。逐次翻訳するため動作を確認しながら作っていくことが容易に行える。

10.6.3. コンパイラ方式でのプログラムの実行手順

コンパイラ方式のプログラムの場合、その過程でコンパイラ以外にリンカとローダが使われる。

コンパイラの仕事

リンカの仕事

リンク(連係編集)はプログラムは自分で分割したモジュールやライブラリとしてあらかじめ提供されている関数や共通モジュールなどすべてつなぎ合わせる作業のこと。リンクを行うプログラムはリンカと呼ばれる。

あらかじめリンクさせておく手法は静的リンキングと呼ばれる。またこの時点ではリンクさせず、プログラムの実行時にロードしてリンクする手法は動的リンキングと呼ばれる。

種類	説明
静的リンク	プログラムを実行する前にリンカによって必要な目的プログラムやライブラリモジュールをリンクする方法
動的リンク	プログラム実行中に別のプログラムモジュールの機能が必要になった時にあらかじめ必要なプログラムやライブラリをリンクする方法

ローダの仕事

ロードはロードモジュールを主記憶装置に読み込ませる作業のこと。これを担当するプログラムがローダである。

10.6.4. リバースエンジニアリング

リバースエンジニアリングは既存のソフトウェアの動作を解析することで、プログラムの仕様やソースコードを導き出す手法。

目的は既にあるソフトウェアを再利用することで、新規開発を手助けすることである。 これによって得られた仕様をもとに新しいソフトウェアを開発する手法はフォワードエンジニアリングと言う。

フォワードエンジニアリングはオブジェクトコードを逆コンパイルしてソースコードを取り出したりする。 これを元となるソフトウェア権利者の許諾なく行うと知的財産権の侵害にあたるため注意が必要である。

10.7. オブジェクト指向プログラミング

処理の対象をオブジェクトという概念でとらえ、オブジェクトの集まりとしてシステムの設計開発を行うことはオブジェクト指向プログラミングと呼ばれる。

詳細に説明するとオブジェクトはデータ(属性)とそれに対するメソッド(手続き)を一つにまとめた概念である。

オブジェクト指向でプログラムを設計するとモジュールの独立性が高く保守しやすいプログラムの作成が可能。

10.7.1. カプセル化

オブジェクト指向プログラミングではカプセル化できることが大きな特徴。 カプセル化することでオブジェクト内部の構造は外部から知ることができなくなる。つまり、情報隠蔽ができることがカプセル化の利点である。

カプセル化を用いるとオブジェクトの実装方法に修正を加えてもその影響を最小限にとどめることができる。

10.7.2. クラスとインスタンス

オブジェクトはデータとメソッドを定義したものでした。この「オブジェクトがもつ性質」を定義したものはクラスと呼ばれる。

言い換えると、オブジェクトの設計図がクラスであり、データやメソッドを持っている。 この設計図に対して具体的な属性値を与えメモリ上に実体化させたものはインスタンスと呼ばれる。

10.7.3. クラスの階層構造

クラスの基本的な考え方はオブジェクトを抽象化し定義すること。 クラスの階層化というのはクラスに上位、下位の階層を持たせることができるというもの。

下位クラスは上位クラスのデータやメソッドの構造を受け継ぐことができます。 上位クラスはスーパクラス(基底クラス) 、下位クラスはサブクラス(派生クラス) と呼ばれます。 サブクラスがスーパクラスの特性を引き継ぐことは継承(インヘリタンス) と呼ばれる。

汎化と特化

汎化は下位クラスが持つ共通性質を抽出し上位クラスとして定義することをさす。 特化は抽象的な上位クラスをより具体的なクラスとして定義すること。 それぞれの関係は下記図のようになる。

集約と分解

下位クラスは上位クラスの特性を分化して定義したもの。上位クラスは下位クラスを集約して定義したものという関係。

多態性(ポリモーフィズム)

多態性は同じメッセージを複数のオブジェクトに送ると、それぞれが独立した固有の処理を行うというもののこと。

10.7.4. UML(Unified Modeling Language)

UMLはオブジェクト指向分析・設計において用いられる統一モデリング言語である。

またこれは複数人で設計モデルを共有してコミュニケーションをとるための手段。 UMLでは13種類の図が規定されている。これらはダイヤグラムと呼ばれる。

UMLのダイヤグラム

UMLの図は構造図と振る舞い図に分類できる。

10.7.5. クラス図

クラスの定義や関連付けを示す図である。 クラス内の属性と操作を記述し、クラス同士を線でつないで互いの関係を表する。

10.7.6. ユースケース図

利用者視点でシステムが要求に対してどう振る舞うかを示す図である。

10.7.7. アクティビティ図

業務や処理のフローを表す図である。

10.7.8. シーケンス図

オブジェクト間のやり取りをし系列に沿って表す図である。 オブジェクト同士の相互作用を表すもので、オブジェクト下の点線で生成から消滅までを表しそこで行われるメッセージのやり取りを矢印で表す。

10.8. テスト

10.8.1. 単体テスト

単体テストでは各モジュールごとにテストを個なって誤りがないかを検証する。 この手法ではブラックボックステストやホワイトボックステストという手法を用いて検証を行う。

10.8.2. 結合テスト

結合テストでは複数のモジュールを繋ぎ合わせて検証を行い、モジュール間のインターフェスが正常に機能しているかを確認する。

結合テストではテストする順番によりボトムアップテスト、トップダウンテストがある。

ボトムアップテスト

下位のモジュールから上位のモジュールへ順にテストする方法。 上位にはドライバと呼ばれるダミーモジュールを用意する。

トップダウンテスト

上位のモジュールから下位のモジュールへ順にテストする方法。 下位にはスタブと呼ばれるダミーモジュールを用意する。

その他のテスト

トップダウンテストとボトムアップテストを組み合わせて行う折衷テストやすべてのモジュールを一気につなげるビッグバンテストがある。

10.8.3. ブラックボックステストとホワイトボックステスト

ブラックボックステスト

モジュールの内部構造は意識せず入力に対して適切な出力が仕様通りに得られるかを確認する。

ホワイトボックステスト

モジュール内部構造が正しく作られているかを検証する。入出力は構造をテストするためだけに過ぎない。

10.8.4. テストデータの決めごと

ブラックボックステストを行う際に入力値をしっかり定義づけることが大切となる。その入力テストデータを作成する基準として用いらるのは同値分割と限界値分析である。

同値分割

データ範囲を種類ごとのグループに分け、それぞれから代表的な値を抜き出してテストデータとして用いる。

限界値分析

限界値分析では上記グループの境目部分を重点的にチェックする。境界前後の値をテストデータに用い、境界値分析と言う。

10.8.5. リグレッションテスト

リグレッションテスト(退行テスト)はプログラムを修正した時にその修正内容が正常に動作していた部分まで悪影響を与えていないかを確認するテスト。

10.9. レビュー手法

10.0.1. レビューの種類

デザインレビュー

デザインレビューは要件定義/外部設計/内部設計で行われるレビューで、使用の不備や誤りを早い段階で見つけるために行われるもの。

コードレビュー

コードレビューはプログラミングの段階で行われるものでプログラムのミスを発見するために行われるもの。

10.1.2. レビューの手法

ウォークスルー

ウォークスルーはレビューの対象物の作成者が主催者となり他の関係者に説明する手法のこと。

インスペクション

インスペクションはモデレータと呼ばれる第3者が議長になり行うレビューのこと。