自称週末ファーマーの国家試験受験記

自己啓発の延長なのか、自己実現の手段なのか、はたまた意地の張り合いか。生きているうちに“何か”を成し遂げたいから走り続けているような感じがする

第132話 経営情報システム23 モデリング技法

今回はモデリング技法についてやっていこうと思います。レビューの残りは情報だけですので連チャンしますぜ。

ソフトウエア開発の設計においては、業務プロセスや業務上発生するデータなどを図式化(モデリング)するのが一般的である。その代表的な技法を概観する。

1.DFD(Data Flow Diagram)
 システムの持つ機能(処理)とデータの流れを示す図式化技法である。DFDを用いることにより、データの流れを視覚的に把握することが出来る。

 ●DFD → 機能(処理)とデータの流れを図式化。POAで利用

2.E-Rモデル(Entity-Relationship model)
 システム化対象となるデータをエンティティ(実体)とリレーションシップ(関連)に分けて表現する図式化技法
エンティティとは、対象となるモノや人を表す。エンティティが持つ属性を、アトリビュートという。リレーションシップとは、エンティティとエンティティの関係を表す。 3層スキーマのうち、概念スキーマの設計は、データベースを設計する上でも重要な作業であり、その際にE-R図が利用される。

 ●E-R図 → データベースを設計。DOAで利用

3.UML(Unified Modeling Language)
 オブジェクト指向のソフトウエア開発におけるプログラム設計図の統一表記法
UMLは単なる表記法であって、開発手法ではない。またUMLで用いる各種図は、用途や目的を明確に定義したものではない。以下にUMLを列挙してみる。

ユースケース
 システムがどのように機能するかを表す図。システムに対するユーザ要求を明確にすることを目的としている。だからユーザを表す“棒人間”が登場する図
クラス図
 システムを構成するクラス(名前、属性、操作)間の関係を記述する。E-R図っぽい。
オブジェクト図
 システムのある時点におけるオブジェクト間の関係を記述する。
シーケンス図
 オブジェクト間のメッセージの送受信関係を時系列で記述する。
コミュニケーション図
 オブジェクト間のメッセージの送受信関係を相互の関連に着目して記述する。メッセージの相対順序関係が分かるように記される。
ステートマシーン図
 オブジェクトの状態遷移を記述する。あるイベント(操作)をしたらどのように遷移するかを示した図。
アクティビティ図
 設計対象の業務手順を表現する。
コンポーネント
 オブジェクトやコンポーネントの物理的な配置関係を記述する。ハードウエアが出たりします
コンポジットストラクチュア図
 クラスやコンポーネントの内部構造を静的に表現する。
タイミング図
 システムの動作を、時間とともに記述する。
インタラクションオーバービュー図
 システムの相互作用の流れを大まかに掴むための複合図。

本当は図とともに押さえたいところなんだけれど、ウデが未熟なものでして・・・。

4.状態遷移図(STD)
 外部設計工程における画面設計、内部設計工程におけるプログラム設計などに用いられる。発生した自称に応じて、システムがどのように動作するかを、状態を表す円と状態の遷移を表す矢印で表現する。円と矢印ですねぇ。

続いては、プログラム設計について。かるく。

プログラム設計は、プログラムの内部構造を設計する。プログラム設計では分割されたプログラムを、実際のプログラム(コーディング)単位である「モジュール」にまで分割し、モジュールの設計を行う。
プログラミングは、設計書をもとにプログラム言語を用いて作成する。複雑ではなく、分かりやすく、かつ後で修正しやすいようにプログラムを作ることで生産性の向上を図る。開発したシステムのテスト方法についてはその主なものを述べる。

1.テストケースの設計
 テストでは、テスト対象のソフトウエアに入力データを与え、その結果をあらかじめ予想している期待値と比較することで、誤りや欠陥を検出する。この入力値と出力地のペアをテストケースという。

1)ホワイトボックステスト
 プログラムの内部構造に着目してテストケースを設計する技法

 ホワイトボックステスト → 内部構造に着目

2)ブラックボックステスト
 テスト対象プログラムの外部使用をもとに、入力と出力に関するテストケースを設計する。どんな入力をするとどんな結果が得られるかに着目したテストケース。

 ブラックボックステスト → 入力と出力

2.単体テスト(モジュールテスト)
 一般的に1つのシステムやアプリケーションは複数のモジュールに分割して開発する。そのモジュールごとのテスト単体テストという。単体テストでは、各モジュールの品質を機能、構造の2つの側面から検証する。この際、機能を検証するためにブラックボックステストが、構造を検証するためにホワイトボックステストが用いられる

3.結合テスト(モジュール集積テスト)
 結合テストとは、分割して開発したモジュールを結合して行うテスト

1)トップダウンテスト
 上位のモジュールに順次下位のモジュールを結合させていくやり方。最初に上位モジュールが出来上がっている。次いで出来上がった下位モジュールをくっつけてテストする。
なお、下位のモジュールが出来上がらないとき、テスト用のモジュール(未完成品みたいなイメージでテストだけは出来る、みたいな)であるスタブを利用する。スタブは下位モジュールだから「シタブ」と覚える
2)ボトムアップテスト
 下位のモジュールから順次上位のモジュールを結合していく方法。上位のモジュールがまだ作成されていない場合、テスト用モジュールのドライバを利用する。

また、モジュール数が少ない場合には、1度に全て結合してテストする方法もある。すべてのモジュールの単体テスト終了後に行うビッグバンテストと単体テストを実施せず、いきなりモジュール全部を結合してテストする一斉テストがある。

4.システムテスト(総合テスト)
 サブシステムおよびシステム全体について行うテスト。機能や性能などが満たされているかどうかを総合的に検証する。

5.承認テスト(検収テスト)
 システム開発者からユーザにシステムを引き渡すとき、つまり検収時に行うテスト。
承認テストはユーザが主体となって行われるが、テストの基準書などソフトウエア開発者側と協同して作成する場合もある。

6.運用テスト(導入テスト)
 ユーザが主体となり、システムを運用しながら行うテストである。承認テストに合格すると、システムはユーザに引き渡される。運用テストでは、実際の稼働環境で運用して、業務上支障がないかどうかを検証する。

これまでテストまで見てきました。

なんだかいろんなテーマが出てきちゃうので今回はここでおしまいにしておきます。

続く。