Software Engineering Lecture 5/30

Menu Menu


先週の復習

来週、6/6 は休講とします。


オブジェクト指向分析・開発

巨大なプログラムを多数の人により開発する。そのためにはプログラムを適切な要素に分割しなければならない。その分割パターンを調べるのがソフトウェア工学だとともいえる。


ソフトウェアライフサイクル

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

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

構造化技法は

を合わせたような技法である。例えば以下のようなデータフロー図を使う。

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

しかし、これは実際には欠点でもある。構造化技法は事務処理等のアプリケーションを作成するのには向いているが、GUIを含むプログラムや、リアルタイムを重視したアプリケーションには力不足ということができるだろう。</p>


UML

UML (Unified Modeling Language)は、Booch法, OMT法、OOSE法を統一した分析手法用に開発されたオブジェクト指向分析に用いる図法を規格化したものである。UML では、以下のような図を用いる。


概念モデル

概念モデルは基本的にはデータベースと同じである。つまりオブジェクトの間の関係を記述した図である。ただ、継承関係があることが異なる。



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

などが一般的だ。これらをさらに細かく、has-a, part-of などに分ける手法もあるが、オブジェクトとしての実現という視点から見ると、オブジェクトの属性(インスタンス変数)に代入されたオブジェクトへの参照というだけだと言える。

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

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


card.pl

Perl/Tk でトランプのカードを作ってみる。

最初の版 これを、module 化する。

モジュールにしてみた版 (未完成) さらに精密なオブジェクトを作成する。(CardPile や Undo など)

CardPlay module


オブジェクト

いつ作るのか?
    最終的には、Unix のmalloc を使って作成されている

いつ削除するのか?
    明示的にfree すれば良い?
    勝手に削除すると、そのオブジェクトを参照しているオブジェクトが困る
    参照がなくなるまで削除しない
    Garbage Colletion => 参照がなくなったら自動的に削除する

属性の実装法
    Perl では、連想配列を使う
    配列を使う方法などがある


問題

Perl/Tk のモジュールCardPlay のオブジェクトの作成部分を解析して、CardPlay の概念モデルを図示せよ。


宿題

上に出てきた問題の解答は、kono@ie.u-ryukyu.ac.jp まで、来週までにメールで送ること。Subject には、
   Software Engineering Lecture 5/30

を付けること。


Shinji KONO / Sun Jun 4 14:53:01 2000