このモデリングと要求仕様をよりよいものとすることがプログラミング 手法の一つの目標だといえるだろう。

これらの手法はプログラム開発を分かりやすくするためのものなので、 図が良く使われることが多い。しかし、図は必須というわけではない。

構造化技法は

• データ構造
• データフロー
• 構造化プログラミング
を合わせたような技法であり、例えば以下のようなデータフロー図に より要求仕様を決めていく。




このような方法は、以下のような利点ある。

• データの流れが良く見える
• 流れるデータと処理をおこなうバブルが良く分離している
しかし、これは実際には欠点でもある。
• データはファイルであり、データベース設計等の視点にかける
• リアルタイムでの応答は、このようなデータフローにはなりにくい
• プログラムコードの再利用、仕様の変更等に対処されていない
構造化技法は事務処理等のアプリケーションを作成するのには向いているが、 GUIを含むプログラムや、リアルタイムを重視したアプリケーションには 力不足ということができるだろう。

オブジェクト指向システム分析

Sally Shlaer,Stephen Mellor のObject Lifecycles (邦題:続オブジェクト 指向システム分析オブジェクトライフサイクル 近代科学社 ISBN4-7649-0238-9) をここでは使うことにしよう。ソフトウェア工学の教科書ではコード・ヨードン を使っているが、こちらの方がより詳細な記述になっている。ある意味では 教条的である。コード・ヨードン法は、どちらかというと精神主義的な感じ がある。

• 情報モデル どんなオブジェクトがあるか、オブジェクトの関係はどうか?
• 状態モデル 個々のオブジェクトの振る舞い
• プロセスモデル オブジェクトの協調動作

情報モデル

情報モデルは基本的にはデータベースと同じである。つまりオブジ ェクトの間の関係を記述した図である。ただ、オブジェクト( デー タベースではレコード)にIDがあること、そして継承関係があるこ とが異なる。

オブジェクトのIDは、オブジェクトへのポインタあるいはユニーク な識別子であり、データベースでのキーと同じ役目を果たす。しか し、オブジェクトのIDは普通はプログラマが直接指定することはな い。

オブジェクトの間の関係は、

• そのオブジェクトが他のオブジェクトを知っている / もっている
• そのオブジェクトが他のオブジェクトから参照されている
• お互いに参照しあっている

オブジェクトの中身を直接いじることなく、オブジェクトIDを 通してオブジェクトにアクセスすることにより、インタフェースと 実装の分離を安全におこなうことができる。しかし、 その分、実行は遅くなる。オブジェクトIDからメッソドを探す という操作が必要だからである。もし、メソッドを呼び出す時に、 そのオブジェクトが何かを指定してやれば、そういうデメリットはない。 C++などは、そういう発想で作られている。

継承関係は、あるオブジェクトからすべての属性を引き継ぎ、さらに 何んらかの属性をつけ加えることを意味する。実際には、属性だけで なく、 オブジェクトの振る舞いもなんからの形で引き継いでいることを さす。ただし、今の所を、属性以外の条件はそれほど明確ではない。 継承するオブジェクトのプログラム理論的な意味をすべて引き継ぐ という考え方もあるが、それを厳密に行うのは実はかなりやっかい なことだし、実用的でもない。

データベースといっても、オブジェクトには一般的な検索方法は 存在しない。もしデータベースが欲しければ、 それは自分で実装しなくてはならない。

Object in Java

例えば猫のオウブジェクトをJavaで記述すると、

public class Cat {
   String name;
   int  sex;
   int  weight;
   String  color;
   String  character;
}

問題

上に出てきた口座の例に出てくるclassをJavaで記述して見よ。 解答は、 そのURLを、kono@ie.u-ryukyu.ac.jp まで、5/7までにメールで送ること。 Subject には、 Software Engineering Lecture 5/15 __ Javaの宿題 を付けること。

例題について

Exporling Java の例題を、/usr/open/lectures/kono/java/exploringjava に置いておきました。興味のある人は動かして見て下さい。