＜TOP PAGE＞
設計の手法について
この講座の内容の無断転記を禁止します
設計には、手順や考え方があり、適切な方法を選択することによって、短期間でシステム構築ができたり、
ミスなどを少なくすることが可能です。
-
視点について
視点とは、システム開発の解析・分析をするときの視点を指す言葉です。
コンピュータを導入する場合に、現行の流れを変えたくない場合には、ボトムアップで、
現状の業務形態を変革したい場合には、トップダウンが望ましいと思います。
ただ、どちらか一方の視点を採用することは少なく、
場合によっては逆の視点で判断を行う場面も必要になります。
- ボトムアップ
ボトムアップは、現行のシステムを分析し、それぞれの流れや考え方を積み上げていって、
システムを構築していきます。
- トップダウン
トップダウンは、理想の姿を定義し、それを実現するためには何をどう行えば良いのかを
検討する手法です。
- モデルついて
モデルは、開発を進めていく過程を決めることです。すなわち、
大まかなスケジュールを考えるときにモデルの存在が重要になってきます。
モデルは、複数存在しますが、大きく分けて４種類に分けることができると私は、考えています。
それぞれのモデルには、特有の考え方があるために、開発の途中でモデルを変更することは
不可能に近いでしょう。
今までの開発では、ウォータフォールモデルを中心に行われてきました。
ですが、オブジェクト指向の現在では、過程の順序が狂う場面もでてきてるので、
ウォータフォールモデルを採用する企業も少なくなってきています。
- ウォータフォールモデル
ウォータフォールは滝の意味です。すなわち、物事の順序を流れるように設計していくことを
取り決めたものです。簡単な流れを見てみましょう。
- 要求分析
- システムの要求や現行の分析を行い、スケジュール計画や工数・費用などを計画する。
- 基本設計
- おおまかな設計。システム全体をにらんだ設計で、
簡単なデータの流れやプログラムの概略動作を設計する。
- 機能設計
- 設計した各部分に機能を盛り込む。大まかなプログラムの流れに必要な機能を盛り込む。
- 詳細設計
- 機能が動作するように詳細な手順を設計する。異常時、特殊なデータ、
作業手順の戻しなどに対応するような計画を行う。
- プログラミング
- 詳細設計に従い、プログラムを組む。
- 単体テスト
- プログラムが動作するかテストを行う。通常は、プログラミングした者が自分の責任において、
ミスを無くし、設計通りの動作をするかテストする。
- 結合テスト
- 他のプログラムとの連携プレーをテストする。他のプログラムと共有するようなデータや、
プログラムを組み込み、全体の流れに異常がないかテストする。
- 運用テスト
- 業務を運用できるかテストする。実業務に近い形でのテストを行い、
負荷や異常時の対処を盛り込んだテストも行う。
- 運用
- 完成したので運用をしてもらう。
ウォータフォールモデルは、各社によって多少違うものの大まかな考えは同じです。
企業で使用しなくなってきているこのモデルは、どこに問題点があるのでしょう。
問題点は、どこかの工程でミスをしても、元には戻りにくいところです。特に、設計と開発が違う会社などでは、
ミスのなすりあいに発展しかねないことにもなります。それと、もう一点、
利用者が初めて確認できるのが運用テストの時点だということです。
利用者の想像通りのシステムが完成されれば問題は発生しないでしょうが、やはり、
思惑がずれることがあります。
- プロトタイピングモデル
プロトタイプは、最初に簡単なデモンストレーション（模擬）プログラムを作成し、
それを見てもらうシステムです。実際の流れは以下を見てください。
- 要求分析
- システムの要求や現行の分析。ウォータフォールモデルと同じ機能。
- プロトタイプの作成
- おおまかなプログラムの作成。画面や帳票でインターフェイスを確認し、プログラムの流れを模倣する。
- プロトタイプの検証
- 実際に顧客立ち会いで検討し、手直しが発生すると「プロトタイプの作成」へもどる。
- プログラミング
- 最終的な確認をおこなった後、本格的に作成する。ウォータフォールモデルと同じ機能。
- 単体テスト
- プログラムが動作するかテストを行う。ウォータフォールモデルと同じ機能。
- 結合テスト
- 他のプログラムとの連携プレーテストする。ウォータフォールモデルと同じ機能。
- 運用テスト
- 実際に近いデータでテスト運用を行う。ウォータフォールモデルと同じ機能。
- 運用
- 完成したので運用をしてもらう。ウォータフォールモデルと同じ機能。
この流れの基本は、ウォータフォールモデルの設計部分がプロトタイプに変更しただけのものですが、
利用者の立場で設計ができ、確認もとれるために、設計の変更が大掛かりにならない点があげられます。
-
スパイラルフローモデル
もう一つの設計モデルである、スパイラルフローについて考えてみます。
スパイラルフローは、基本的な流れや考え方は、プロトタイプと同じですが、
作成物が、正式版であり、完成品です。ですから、最初は基本的な機能を作成し、
それに肉付けをしながら目的のシステムを構築します。
それでは実際に流れを見てみましょう。
- 要求分析
- システムの要求や現行の分析。ウォータフォールモデルと同じ機能。
- 設計
- プログラムの動作を設計。ここで作成する設計は、１つの機能であり、全体に及ぶ機能ではない。
- プログラミング
- 最終的な確認をおこなった後、本格的に作成する。ウォータフォールモデルと同じ機能。
- テスト
- プログラムが動作するかテストを行う。ウォータフォールモデルの単体テストと
結合テストを加味したもの。
- 検証
- 実際に顧客立ち会いで検討し、動作確認が得られれば、次の付加機能の設計を行うために
「設計」段階へ戻り、
動作不十分の場合には、作成し直す。
- 運用テスト
- 実際に近いデータでテスト運用を行う。ウォータフォールモデルと同じ機能。
- 運用
- 完成したので運用をしてもらう。ウォータフォールモデルと同じ機能。
以上のような流れが、スパイラルフローです。
プロトタイプとスパイラルフローは、どちらもプログラムを作成し、顧客立ち会いの元に検証を行いますが、
プロトタイププログラムは、あくまでも検証用であり、実際の動作をプログラムする段階になると、
再構築の部分が発生しやすいため、同じ機能を作り替える可能性もあります。
スパイラルフローの問題点は、小さい部品といえども、最初に完成品を作成するために、
新人では無理な部分があります。
-
RAD（Rapid Application Development）
RADは、基本的にはスパイラルモデルに似ています。ただし、最初の決め事は、設計ではなくて、納期です。
手順は、開発の機能ごとに納期を決めて、優先順位の高い部分から取り掛かります。
１期限内に出来上がったシステムは、スパイラルと同じように機能の完成品です。
この方法だと最終的な運用時期を守ることができます。
また、もしずれ込んだとしても通常は使用しない機能が残ることになるので苦情の点からも逃れることが
可能になってきます。
問題点は、だれが納期を決定するかです。納期にはかなりの経験と勘が必要になります。
- アプローチについて
アプローチは、何に注目して設計を行っていくかを取り決めることです。
注目点は、データ、プロセス、オブジェクトなどに分けることができます。
プロセスとは、処理や業務のことで、データとは、データベースや伝票のことです。
また、オブジェクトは、データとプロセスを一体化した考え方です。
実際の違いについて見てみましょう。
- POA（プロセス中心アプローチ）
基本は、「どの部署が、どうのような要望があるのか」を設計します。
これは、調査・立案段階でしっかと捕らえておくことが重要になってきます。
流れは、次のとおりです。
- 現状把握
- どの部署から、どこの部署へ、何がどのように動いているのかをまとめます。
- モデリングの作成
- 把握した現状において、実際の伝票などの物の流れを詳細にしていきます。
- モデリングの具体化
- モデリングした物をシステムに置き換え、データやプログラム化します。
- プログラム開発
- ここからは、今までの流れと同じです。
プログラム開発以降は、他の流れと共通なので省略しますが、重要なのは、モデリングの作成です。
モデリングには、物理モデルと論理モデルがあり、物理モデルは現状をまとめたもので、
物や人、伝票などの流れを記述します。すなわち、現在の会社内部の伝票や流れを洗い出します。
論理モデルでは物理モデルを組み合わせて全体の流れを決める工程です。
実際には、DFDと呼ばれる表現方法で記述していきます。DFDは、
処理の流れを決まった図式と線で記述します。実際の記述方法に付いては、専門書を参照してください。
問題点としては、現状の環境が変化しないシステムで有効です。
システムが完成して、物や人の流れが変化すると、物理モデルも狂ってきます。
- DOA（データ中心アプローチ）
基本は、「業務の中で、どのようなデータ（情報）が動いているか」を設計します。
全体的な流れは、POAと同じです。最初に決定していくのは、データベースの定義から行います。
したがって、データベースの知識が前提条件となります。
DOAでは、データから定義するために、無駄なデータやダブったデータが存在しにくい点が上げられます。
DOAのモデリングでは、データモデリングを設計した後、プロセスモデリングを設計していきます。
実際には、ER図を用いてデータモデリングを行います。
- OO（オブジェクト開発技法）
オブジェクト指向開発は、DOAとPOAの開発技法を併せ持つ方法です。
データとコード（手続き）を一体化してとらえて開発を進めていきます。
具体的には、どのように考えていけばよいのでしょうか？まずは、オブジェクトとは何かを理解しましょう。
考えやすい題材として自動車にたとえてみましょう。特定の会社名や車名を出したくはないのですが、
説明のために少しだけ登場してもらいましょう。
トヨタには、マークⅡやカローラなどの車種があります。ここで、トヨタは、
マークⅡやカローラの上位なので「スーパークラス」といいます。また、マークⅡやカローラは、
「スーパークラス」に属するので、「サブクラス」と呼ばれます。
「スーパークラス」は１つ以上の「サブクラス」を持ちます。
また、マークⅡには、「ツアラー」とか「グランデ」などがあります。
これらもマークⅡからみると「サブクラス」です。
グランデからマークⅡをみると「スーパークラス」になります。
クラスの情報を配下のクラスに継承できます。
マークⅡならば、幅、高さ、エンジンの種類などが、
ＧＲやグランデなどでも使用します。
上位のクラスで使用する情報が下位クラスでも使用できることを継承といいます。
継承は、インヘリタンスとも言われます。（継承は、同じ領域をさすのでなく、ダビングすることもできます）
クラスの情報を継承して、サブクラスを作ったときに、サブクラスをインスタンスと言います。
正確には、クラスから生成された実体をインスタンスと言います。
インスタンスは、サブクラスと同じと考えて良いでしょう。このインスタンスは、オブジェクトとも言われます。
オブジェクトは、広い意味と狭い意味があり、大きく考えると、クラスもオブジェクトです。
（ちなみに、私は、クラスやインスタンスは使わずにオブジェクトを使います）
オブジェクトの内部は、プロパティ（属性）とメソッド（振る舞い）で構成されています。
プロパティは、オブジェクトの固有のデータで、メソッドは、オブジェクトのプログラム部分となります。
（プロパティはデータ、メソッドはコードでもかまいません）
ＧＲというオブジェクトには、エンジン形式、排気量、色などの属性があります。
この属性がプロパティです。メソッドは、乗りごごち、ハンドルの切れなど、動きの部分のことです。
この２つを一緒にすることをカプセル化といいます。
通常は、メソッドとプロパティは一緒になっているので、カプセル化しているのがほとんどです。
こんどは、開発の手順を見てみましょう。オブジェクト指向の開発の手順は、
大きく分けてOOA、OOD、OOPになります。これらの詳細は、次の項目で取り上げます。
実際の手順では、従来のように固定した設計の方法があるわけでなく、考え方が中心となります。
もちろん、フローチャートを使用してもかまいません。何を使用するかでなく、どう考えるかが重要です。
- OOA（オブジェクト指向分析）
ここでは、以下のものを定義していきます。
- クラス
- 関係
- 操作
- 属性と継承
現実のデータの組み合わせや関係、理想の操作などを一緒に設計することが大切です。
現状を設計するだけなら、ウォータフォールモデルと変わりません。
- OOD（オブジェクト指向設計）
実際の動作を盛り込んだ設計になります。
イベントの種類、エラー処理などをオブジェクトごとに書き出します。
具体的にWindowsの画面での動作で見てみると、「登録ボタン」がクリックされた場合には、
何をするか。リターンキーが押された場合には何をするか。マウスでドラッグされたら何をするか。
などを記述し、対応するエラーについても記述していきます。GUI設計です。
このほかには、DB設計や通信設計などがあります）
- OOP（オブジェクト指向プログラム）
ここでは、実際にプログラムとデータベースなどの定義やプログラムを行います。
プログラムだけではなく、データベースなどの設計なども入り込むためにOOI