Software Engineering Lecture 5/30
Menu Menu
先週の復習
- 無名データ
- パッケージ
- オブジェクト
- gcd の例題
- SimpleCard の例題
来週、6/6 は休講とします。
オブジェクト指向分析・開発
巨大なプログラムを多数の人により開発する。そのためにはプログラムを適切な要素に分割しなければならない。その分割パターンを調べるのがソフトウェア工学だとともいえる。
ソフトウェアライフサイクル
このモデリングと要求仕様をよりよいものとすることがプログラミング手法の一つの目標だといえるだろう。
- 構造化技法
- オブジェクト指向分析/開発
構造化技法は
- データ構造
- データフロー
- 構造化プログラミング
このような方法は、以下のような利点ある。
- データの流れが良く見える
- 流れるデータと処理をおこなうバブルが良く分離している
- データはファイルであり、データベース設計等の視点にかける
- リアルタイムでの応答は、このようなデータフローにはなりにくい
- プログラムコードの再利用、仕様の変更等に対処されていない
UML
UML (Unified Modeling Language)は、Booch法, OMT法、OOSE法を統一した分析手法用に開発されたオブジェクト指向分析に用いる図法を規格化したものである。UML では、以下のような図を用いる。
- ユースケース アクタ(外部エージェント)が行うイベントの記述
- 概念モデル 現実世界に対応したオブジェクトの静的な関係を表す
- 相互作用図 時系列に対応したユースケースの具体的な記述
- 設計クラス図 ソフトウェアのオブジェクトの静的な関係を表す。概念モデルにメソッドが付加されたもの。
- 状態図 個々のオブジェクトの振る舞い
- パッケージ ソフトウェアのアーキテクチャの階層的表現
- 汎化 概念のgeneralization/specialization の関係
概念モデル
概念モデルは基本的にはデータベースと同じである。つまりオブジェクトの間の関係を記述した図である。ただ、継承関係があることが異なる。
オブジェクトの間の関係は、
- そのオブジェクトが他のオブジェクトを知っている / もっている
- そのオブジェクトが他のオブジェクトから参照されている
- お互いに参照しあっている
オブジェクトの中身を直接いじることなく、オブジェクトIDを通してオブジェクトにアクセスすることにより、インタフェースと実装の分離を安全におこなうことができる。しかし、その分、実行は遅くなる。オブジェクトIDからメッソドを探すという操作が必要だからである。もし、メソッドを呼び出す時に、そのオブジェクトが何かを指定してやれば、そういうデメリットはない。C++などは、そういう発想で作られている。
継承関係は、あるオブジェクトからすべての属性を引き継ぎ、さらに何んらかの属性をつけ加えることを意味する。実際には、属性だけでなく、 オブジェクトの振る舞いもなんからの形で引き継いでいることをさす。ただし、今の所を、属性以外の条件はそれほど明確ではない。継承するオブジェクトのプログラム理論的な意味をすべて引き継ぐという考え方もあるが、それを厳密に行うのは実はかなりやっかいなことだし、実用的でもない。
card.pl
Perl/Tk でトランプのカードを作ってみる。最初の版 これを、module 化する。
モジュールにしてみた版 (未完成) さらに精密なオブジェクトを作成する。(CardPile や Undo など)
オブジェクト
いつ作るのか?
最終的には、Unix のmalloc を使って作成されている
いつ削除するのか?
明示的にfree すれば良い?
勝手に削除すると、そのオブジェクトを参照しているオブジェクトが困る
参照がなくなるまで削除しない
Garbage Colletion => 参照がなくなったら自動的に削除する
属性の実装法
Perl では、連想配列を使う
配列を使う方法などがある
問題
Perl/Tk のモジュールCardPlay のオブジェクトの作成部分を解析して、CardPlay の概念モデルを図示せよ。
宿題
上に出てきた問題の解答は、kono@ie.u-ryukyu.ac.jp まで、来週までにメールで送ること。Subject には、Software Engineering Lecture 5/30を付けること。