Software Engineering Lecture 6/12

Menu Menu

先週の復習

先週の復習

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

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

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

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

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

構造化技法は

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

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

しかし、これは実際には欠点でもある。構造化技法は事務処理等のアプリケーションを作成するのには向いているが、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 の概念モデルを図示せよ。

ユースケース

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

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

図の書き方

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

PC Unix上で、UMLを記述するのには、Tgif が便利だろう。Idraw も使えるが、残念ながら、一部のPostScript Printer (Oki 600PS)などでは日本語がうまく出力されないようである。琉大のパッチをあてた Tgif ならば、そういう問題は生じない。(逆に言えば、Tgif でも Oki 600PSではパッチが必要になる。不幸なことである...)

Tgif/Idraw は、Draw 系ツールと呼ばれ、回路図やUML、あるいは、論文で使うような説明的な図に向いてる。Gimp/Xpaint などは、Pictrue系あるいはPaint系などと呼ばれ、画像の処理や、お絵書きに向いてる。Draw 系のツールは、出力が可読形式になっていることが多い。 ( Windows や Mac では、そのようなことは、めったにない。それは、単に絵を書くだけの知能しか持たないユーザを対象にしているからだろう....)

Draw系の出力を処理することにより、例えば、UML図から、プログラムを生成することなどが、Perl などを使って簡単に実現できる。

問題

前回のCard.pm の概念図を Tgif を使って記述し、Perl のプログラムを生成するPerl のプログラムを作成してみよ。

参考: Tgif のobj ファイルから Idraw のファイルを生成するプログラムがある。これ を使ってみよう。

図のメールでの送り方

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

図は、Tgif の obj ファイルなどを送っても、可哀想な Windows ユーザは見ることができないだろう。PostScript に変換すれば、GhostScript などを使って見ることができるかも知れない。しかし、もともとのWindows には、そんなものは入っていないので、GIF などに変換する必要があるかも知れない。しかし、GIF にしてしまうと、画面の解像度などに強く影響されてしまう。解決策は、もちろん、Windows なんか使わないというのが一番であるが、馬鹿に合わせることも、世の中では必要であろう...

なので、ここでは PostScript で送ることにする。PDF という PostScript のサブセットを使うことも出来るが、PDF を生成するプログラムは、Windows 上では有料である。Free のものも若干存在するようである。

Tgif から PostScript を生成するには、print command を使えば良い。Idraw からは、生成する必要さえない。もともと Idraw は、PostScript を構造化したファイル形式を使っているからである。しかし、PostScript は、フォントなどの設定から、(特に Level 3から)互換性が落ちているので、メールでやりとする際には気を付ける必要がある。

Unix から MIMEのメッセージを送る方法はいくつかある。しかし、どれもめんどくさいことも確かである。tar + uuencode のような形式で送る、あるいは、shar という shell script を生成して送るような方法もある。

(shar を使って、コンピュータ・ビールスのようなものを送ることもできるが、Unix では、そのまま見えてしまうので、ださださなものになってしまう。しかし、最近流行った、I LOVE YOU のメール経由のビールスは、本質的にはそのようなものである。しかし、それらは、Visual Basic などに隠されているので、Windows などでは脅威となりうるらしい。そんなシステムを君達は本当に使うのか? それはともかく...)

MIME を送る方法は、 

	mailto (metamail コマンド)
	mhn (MH の MIME comamnd)
	mnews
などがある。metamail は、RSI (琉大標準インストール)には入ってないかも知れない。mnews が MIME に対応してるかどうかは version によるらしい。mhn を使う方法が直接的なので、それを使ってみよう。

comp で手動でメールを作成したあと、 

    #<text/plain;charset=iso-2022-jp;encoding=7bit
    #image/gif [photo] test.gif
という形の文をいれておく。本文は、JIS にしておこう。これを、 
	edit mhn
とすることにより、MIME 形式に展開される。正しいことをざっと確認して、送信すれば良い。こういうプログラム も便利らしい。

(MIMEで、Word などの文書を送ることは慎むべきだろう。理由は何故か?)

概念モデルの実装

Perl では、参照関係は、無名ハッシュを使って実装する。概念モデルでは、対応は様々である。以下の関係を実装するオブジェクトは、Perl の無名配列への参照を使うことにより簡単に実装できる。

宿題

解答は、kono@ie.u-ryukyu.ac.jp まで、来週までにメールで送ること。Subject には、 
   Report on Software Engineering Lecture 6/12
を付けること。

Shinji KONO / Mon Jun 11 17:32:39 2001