開発プロセス・ソフトウェア設計（システム開発技術）
学習のポイント
システム開発を行う上での「システムのライフサイクル」、「開発プロセスの各工程の役割」を理解し、3種類の開発モデルの理解、システムのアプローチの方法として「プロセス中心アプローチ」「データ中心アプローチ」「オブジェクト指向アプローチ」を押さえ、システム開発の手順を理解しましょう。
| 1. システムのライフサイクルと共通フレーム2013 | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
● システムのライフサイクル ・システムは、ユーザーの要望より新システムの「企画・計画」が行われ、これを基にして「開発」を行い、新たに誕生します。 ・開発されたシステムは、ユーザーによって「運用」され、その後、外部環境の変化に伴い新たな要望を実現するために「保守」を行います。 ・「運用」「保守」を繰り返し、いつかは、「保守」で対応できなくなった場合は、新たなシステムを完成し、その後、旧システムは「破棄」されます。
● 共通フレーム2013とは？
・開発・取引に関する標準的な枠組みを提供したもの。 | ||||||||||||||||||||||||||||||||||||||||||||||||||
| 2. 開発プロセス | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
● システムの開発プロセス 下記が、実際の開発プロセスです。各工程の作業について確認していきましょう。
| ||||||||||||||||||||||||||||||||||||||||||||||||||
| 2-1. システム要件定義 | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
システム全体「ハードウェア」「ソフトウェア」が実現すべき要件を定義する。実際は、現状システムの問題点を把握し、システム利用者からヒヤリングなどを行い、必要とする「機能」「性能」「システム構成要素」を定義します。 ● 要件定義の内容
1. 機能的要求仕様…システムに必要とされる機能 ● 要件定義実現のための3つのアプローチ
1. プロセス中心アプローチ…システムの機能面に対するアプローチ |
||||||||||||||||||||||||||||||||||||||||||||||||||
| 2-2. システム方式設計 | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
システム要件定義で決定した内容を満たすために、どのようなソフトウェア・ハードウェアとするかを「最上位レベル」で明確にする。具体的には、システムを「ソフトウェア品目」として、分割します。 ※ソフトウェア品目…OS・DBMS・各種サブシステムなどのソフトウェアの構成管理の対象となる単位のこと。 ※ソフトウェアの構成管理とは…ソースコードや文書などの成果物の変更履歴を管理し、製品のバージョンやリビジョンに個々の成果物のどのバージョンが対応しているかを識別して、任意のバージョンの製品を再現可能とすること。 |
||||||||||||||||||||||||||||||||||||||||||||||||||
| 2-3. ソフトウェア要件設計 | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
システムの外部（ユーザーや他のシステム）に対して、どのようなインターフェースを実装すべきかを設計します。
1. システム分割…システムをサブシステムへ分割する。 ●コード設計 コード設計の際は以下の機能が求められます。 「識別機能」データを一意に識別できる機能。 「分類機能」データをグループに分類できる機能。桁ごとに意味を持たせることで実現。 「配列機能」データの並び順をできる機能。 「チェック機能」コードが正しく入力されたかチェックできる機能。「チェックディジット」を持たせる。以下の種類があります。
●チェックディジット ・JANコード、ITFコードなどで使用されている「モジュラス10/ウェイト3」の方式は以下の通りです。 例：「351386327796」のチェックデジットを求める。
1. 奇数位置のキャラクタを合計して3倍。(5+3+6+2+7+6)×3=87 ●入力ミスのチェック方法 「目視チェック」 人間がデータを見てエラーの有無を確認する。 「ニューメリックチェック」 入力データが数字であるかどうかチェック方法。 「フォーマットチェック」 入力データに形式(フォーマット)がある場合はその通りに入力したかチェックする方法。 「論理チェック」 入力データが論理的にみて適切であるかどうかチェックする方法。 「リミットチェック」 入力データが制限内に収まっているかどうかチェックする方法。 「照合チェック」 入力データとファイルの内容を照合することでエラーの有無を確認する方法。例えば、商品の入力でその商品がマスタファイルに存在するかどうかチェックするなどのこと。 |
||||||||||||||||||||||||||||||||||||||||||||||||||
| 2-4. ソフトウェア方式設計 | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
ソフトウェア要件設計で得られた「各サブシステム」を「ソフトウェアコンポーネント」として「プログラム」に分割します。 ※ソフトウェアコンポーネント…ソフトウェア品目に存在する機能単位のまとまりのこと。 具体的には、ソフトウェア要件定義の内容に基づいて、どのように「プログラム」や「システム」を実現すれば良いかを具体的に定めます。
1. 機能分割・階層構造化…ソフトウェア要件設計の各サブシステムを「プログラム」に分割し、プログラムの実行順序を「システムフロー」で表現します・ |
||||||||||||||||||||||||||||||||||||||||||||||||||
| 2-5. ソフトウェア詳細設計 | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
ソフトウェア方式設計で、決めた「各プログラム」「モジュール」単位に分割します。モジュールはコーディングの対象となり、また、モジュール間インタフェースを定義して、次工程のプログラミングでコーディングできるように「設計書」にまとめます。ここでの「モジュール」を「ソフトウェアユニット」といいます。 ※ソフトウェアユニット…独立してコンパイル可能なまとまりのこと。
1. モジュール分割…モジュール分割手法は下記参照。 ●モジュール分割手法 プログラムをモジュール単位に分割してこれを階層化することを「モジュールの分割」と言います。ソフトウェア詳細設計の段階で行います。以下の方法があります。
データの流れを「S(Source)源泉」「T(Transform)変換」「S(Sink)吸収」に分割して、モジュールの階層構造を設計する技法です。それぞれ、「入力モジュール」「処理モジュール」「出力モジュール」となります。 「最大抽象入力点」これ以降は入力データが発生しない区切りの場所。 「最大抽象出力点」こり以降は出力データが発生しない区切りの場所。 2. TR分割(トランザクション分割) 機能の分割を行った際にデータの流れが分岐する場合に適用し、入力されたトランザクションにより、異なる処理を実行する場合に使用されます。 3. ジャクソン法(JSP) 入出力のデータ構造に着目してモジュールの階層構造を導きます。「JSP木構造図」を使用します。これは、「基本」「連続」「選択」「繰返し」の構成要素からなります。 4. ワーニエ法 入出力データの関係からモジュールの階層構造を導く技法です。「ワーニエ図」を使用します。これは、左から右に向かって入出力データを詳細化してデータ名の後にその繰り返し回数を明記します。 ●モジュールの独立性の評価 プログラムは、モジュール単位に分割しますが、良いモジュール分割とは、「独立性の高い分割」であり、「モジュール強度」と「モジュール結合度」で評価できます。 「モジュール強度」 モジュールがどれだけの機能を実現しているかを示す尺度で、強いほど独立性が高い。
●モジュールの結合度 モジュール同士の連結の度合いを示す尺度で、弱いほど独立性は高い。
|
||||||||||||||||||||||||||||||||||||||||||||||||||
| 2-6. プログラミング | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
モジュールを対象として、プログラミグ言語を用いてコーディングしてコンパイル、単体テストを行います。
注意点としては「保守性」「拡張性」を意識したプログラミングを行います。
●コーディング規約 コーディングにルールを定めたもので、これにより、コーディングスタイルが統一されて、「可読性」「保守性」が向上します。 ●構造化プログラミング 「ダイクストラ」によって提唱されたプログラミングの規範です。簡単に述べると「GoTo文を使用しないプログラム」を言います。実際は、以下の基本制御構造を使用します。 「順次」「選択」「繰返し」のみを使用してプログラミングを行います。 さらにダイクストラは、どんなプログラムも補助的なスイッチを使用することによりGoTo文のないプログラムを記述できることを主張しました。これを「構造化定理」と言います。 この試験の「擬似言語」は、まさに構造化プログラミングです。 ●エクストリームプログラミング（Extreme Programming 略してXP） Kent Beck氏らが考案・提唱しているソフトウェア開発手法で「少人数で素早く開発を進めていくソフトウェア開発手法」です。以下の特徴があります。 ・ソフトウェア要求仕様の変更などの変化に対して機敏に対応する ・初期段階の設計よりもコーディングとテストを重視する ・ドキュメントよりもソースコードを重んじる ・各工程を段階的に進めていくより、常にフィードバックを行って修正・再設計していくプロセスを重視する ・ペアプログラミングとは、２人のプログラマが１台のコンピュータを使って、 共同でソフトウェアの開発を行う方法で、XPでは、実践が提唱されている。 ●リファクタリング プログラムの「外部仕様を変えずに、内部構造を安全に変更する」ことがリファクタリングです。目的はプログラムを理解しやすい状態に維持し，拡張性や再利用性を高めることです。 |
||||||||||||||||||||||||||||||||||||||||||||||||||
| 2-7. テスト | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
テストは、以下の順に行います。 「単体テスト」→「ソフトウェア結合テスト」→「ソフトウェア適格性確認テスト」→「システム結合テスト」→「システム適格性確認テスト」の順に行われます。 ※各テストの詳細は、次の章で説明します。 |
||||||||||||||||||||||||||||||||||||||||||||||||||
| 3. ソフトウェア開発のモデル | ||||||||||||||||||||||||||||||||||||||||||||||||||
| 「ソフトウェア開発のモデル」とは、システムの一連の開発工程をモデル化したものです。以下の3種類があります。 ●ウォータフォールモデル
「利点」 ・全体の見通しがつきやすい(大規模システムに向いている)。 ・工程が順次進むため理解しやすい。 「欠点」 ・ユーザ要求に不明確な点を残しやすい。 ・仕様変更などに柔軟に対応できない。 ※このモデルでは、開発は、「トップダウン」で行い、テストは「ボトムアップ」で行います。 ●プロトタイプモデル システムの試作品(プロトタイプ)を作成してユーザに提供する。これにより、ユーザ要求を明確化でき、隠れたユーザ要求を洗い出すことが可能となります。 「要求のプロトタイプ」(ユーザの評価・修正) 「設計のプロトタイプ」(ユーザの評価・修正) 「システムのプロトタイプ」(ユーザの評価・修正) 「テスト」 上記のように各工程でプロトタイプを作成して、ユーザの評価を得て、必要ならば修正を行います。 ●スパイラルモデル これは、開発工程を何回か反復することでシステム開発を進めるモデルです。つまり、「システムの独立性の高い部分に分解して、その部分ごとに設計、プログラミング、テストの工程を繰り返します」。上記2種類のモデルの長所を生かしたモデルです。 |
||||||||||||||||||||||||||||||||||||||||||||||||||
| 4. プロセス中心アプローチ | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
要件定義・設計を実現するためには、「プロセス中心アプローチ」「データ中心アプローチ」「オブジェクト指向アプローチ」の3種類のアプローチがあります。各アプローチの方法について理解しましょう。 ●プロセス中心アプローチ システムを「システムが実現する機能」面から分析してこれを設計に役立てる方法論です。この方法は、システムの機能はデータを変化させるものとしてとらえます。具体的には以下の3種類を使用します。 1. DFD…データの流れを記述する。
2. HIPO・プロセスフロー…処理の順序を明確にする。 ・HIPOは、階層構造を表す「図式目次」と、入力、処理、出力を表す「IPOダイアグラム」で表現します。 図式目次の例
3. 状態遷移図…リアルタイムシステムで使用されることが多く、イベントの発生による状態の遷移を表現します。
|
||||||||||||||||||||||||||||||||||||||||||||||||||
| 5. データ中心アプローチ | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
●データ中心アプローチ システムを構成する安定した要素である「データ」に着目してこれをもとに分析・設計する方法論です。通常は、E-R図を使用します。 「E-R図」とは、システム化の対象を「エンティティ(実体)」とエンティテイ間の「リレーションシップ(関連)」で分析して、ERDを使用して記述します。関連には、「1対1」「1対多」「多対多」があります。具体的な流れは以下の通りです。 ・E-R図を使用したデータ分析 ・デーベースの設計 ・データベースに対する処理の分析 ・処理の設計 ・プログラミング ・テスト |
||||||||||||||||||||||||||||||||||||||||||||||||||
| 6. オブジェクト指向アプローチ | ||||||||||||||||||||||||||||||||||||||||||||||||||
|
●オブジェクト指向 「プロセス（操作）」と「データ（属性）」を一体化した「オブジェクト」を対象として分析・設計を行う方法論です。 1. データ 属性で変数として定義します。人間クラスがあった場合、「名前」「性別」などが該当します。 2. メソッド データを操作する手続きのことて、人間クラスの場合、「食事をする」「睡眠をとる」「仕事をする」などです。 3. カプセル化 データとメソッドを一体化すること。これによりデータは隠蔽されデータへのアクセスにはメソッドを公開して行うようにします。 4. クラスとインスタンス クラスは、オブジェクトがもつデータやメソッドを記述したものでオブジェクトの雛形です。インスタンスは、クラスから生成されたオブジェクトの実体で、コンピュータで実行する対象のものです。例えば、「学生クラス」があったとします。これをインスタンス化して「中学生の田中さん」「大学生の佐藤さん」というように実際の登場人物を具体化したものです。 5. 汎化-特化関係 これは、クラスが階層構造をとることが出来るため下位クラスに共通するデータやメソッドを上位クラスで定義することです。この時、上位クラスを「スーパクラス」、下位クラスを「サブクラス」と言い、サブクラスへ引き継がれることを「継承(インヘリタンス)」と言います。特化はサブクラスへ分解すること。汎化はサブクラスからスーパクラスを生成することです。 もう少し詳しく説明すると、 オブジェクト指向で抽象化を行うことを「汎化」と言います。 これは、「is-a 関係」とも言います。 例えば、「洗濯機」や「掃除機」を汎化すると「家電製品」になります。 「洗濯機 is a 家電製品」 「掃除機 is a 家電製品」と言う関係です。 スーパクラスとサブクラスをis-a 関係で見れば、 「サブクラス is a スーパクラス」 サブクラスからスーパクラスを生成することを「汎化」 スーパクラスをサブクラスに分解することを「特化」 と言います。 6. 多態性（ポリモーフィズム） 同じメソッドでも、オブジェクトによって異なる処理を行うこと。例えば、インターフェースを実装した複数のクラスで、抽象メソッドを「オーバーライド（再定義）」した場合、それぞれ処理内容は異なります。 7. 集約-分解関係（part-of関係） 「△は、○の一部である」で表される関係のことです。例えば、「タイヤ」と「自動車」の関係は、「タイヤは自動車の一部である」という関係があるため、「part-of関係」となります。 ●UML オブジェクト指向においてシステムの分析・設計に使用する図式表現です。事実上の世界標準となっています。 1. クラス図 システムに必要なクラスとクラス間の関連を記述します。
システムで行う処理を「オブジェクト間のやり取り」という観点から時系列に記述します。
利用者から見たシステムの振る舞いを記述する。 4. アクティビティ図 システムの動作(振る舞い)のことで、システムで行う処理の流れ(ワークフロー)やアルゴリズムなどを記述します。 5. ステートチャート図 あるオブジェクトに着目して内部状態がどのように遷移するかを記述する。 ●関連用語 「OMG」 オブジェクト指向技術の普及と標準化を図る非営利団体。 「ORB」 クライアントサーバシステムのような分散システム環境で、オブジェクト同士がメッセージを交換するための機能及びソフトウェアのこと。 「CORBA」 オブジェクト同士がメッセージを交換するための共通仕様です。 |
||||||||||||||||||||||||||||||||||||||||||||||||||
