Software Engineering Lecture s5

Menu Menu

先週の復習

テンプレート
無名データ
パッケージ
オブジェクト
SimpleCard の例題

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

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

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

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

構造化技法
オブジェクト指向分析/開発

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

構造化技法は

データ構造
データフロー
構造化プログラミング

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

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

データの流れが良く見える
流れるデータと処理をおこなうバブルが良く分離している

しかし、これは実際には欠点でもある。

データはファイルであり、データベース設計等の視点にかける
リアルタイムでの応答は、このようなデータフローにはなりにくい
プログラムコードの再利用、仕様の変更等に対処されていない

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

UML

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

ユースケースアクタ(外部エージェント)が行うイベントの記述
概念モデル現実世界に対応したオブジェクトの静的な関係を表す
相互作用図時系列に対応したユースケースの具体的な記述
- シーケンス図時系列に対応したユースケースの具体的な記述
- 協調図メッセージの流れに沿ったオブジェクトの相互作用の記述
- 契約相互作用後の事後条件
設計クラス図ソフトウェアのオブジェクトの静的な関係を表す。概念モデルにメソッドが付加されたもの。
状態図個々のオブジェクトの振る舞い
パッケージソフトウェアのアーキテクチャの階層的表現
汎化概念のgeneralization/specialization の関係

概念モデル

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

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

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

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

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

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

オブジェクト

いつ作るのか?

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

いつ削除するのか?

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

属性の実装法

    Perl では、連想配列を使う
    配列を使う方法などがある

問題5.1

トランプのカードゲームの概念モデルを図示せよ。

Perl/Tk のモジュール CardPlay module CardPlay のオブジェクトの作成部分を解析しても良い。

ユースケース

ユースケースはユーザが、対象とするシステムで何をするかを説明する文書である。

問題5.2

マルチユーザ・カードゲームを作る時のユースケース一つを取り出し、記述してみよ。

図の書き方

UML などの図は、専用のエディタを作ることも多い。Java で記述されたツールや、C++ で記述されたものある。しかし、コンピュータ上で記述することは必須ではない。特に、UMLは手書きでも使えるように設計されている。

図のメールでの送り方

図を送るには、MIME (Multipurpose Internet Mail Extensions) を使う。

使用するフォーマットとしては、

     PDF
     JPEG

などが良いと思われる。しかし両方とも編集できないという欠点がある。

添付ファイルだと巨大なバイナリを配布することになるし、添付ファイルにはウィルスの脅威が付きまとうので、WWWなどにバイナリを置いて、そこのURLを示すのが良い。必要ならば検証用のMD5を計算して同時に送る。

問題5.3

カードゲームのGUIを含むプログラムを、問題5.1の概念モデルにそってJavaを用いて実装せよ。

    build.xml

を含み、画像を含む

jar

を生成すること。

作成したプログラムは学科のCVSに登録し、repository をメールに含めること。

適当な Solitare ゲームで良いが、異なるゲームを複数実装できるようにすること。