プロジェクト成果物提出完了

もうひとつの講義SWE621では、グループプロジェクトの宿題が出ていてその締め切りが今日でした。なんとか締め切りまでに成果物を提出することができました。厳密には締め切りは夜の11時59分までなので、いくつかのグループはまだ作業しているのではないかと思います。

このFallセメスターでは２つの講義を履修していて、もう一方の講義の中間テストは昨日で終わり、今日プロジェクトの成果物を提出し終えて、今かなりほっとしているところです。

プロジェクトの内容
SWE621は、Gomaa先生によるソフトウェア分析設計法の講義です。George Mason Univ.のIT系のコースにおいてこのクラスは中心的な位置付けになっていて、このクラスで出る課題（このプロジェクト）がもっとも大変だと言われているようです。実際、とても大変でした。
内容は、問題定義と１１個のユースケース記述が与えられ、分析モデルを完成させるのがPhase１の課題です。まず、コンテキストダイアグラムを作成し、システムのバウンダリを明らかにします。次に、スタティックモデリング（ビジネスモデリングみたいな感じ）を行い、エンティティクラスの抽出と各クラス間の関連をクラス図を用いて定義します。スタティックモデリングを通じて問題を理解することができます。次に、ダイナミックモデリングを行います。各ユースケースについて、コミュニケーションダイアグラムやシーケンスダイアグラム、ステートチャート等を用いて、ユースケースシナリオを実現すべく、オブジェクト間の関連とメッセージ送受信を定義します。Phase１の課題は大体ここまでです。

個人プレー
以前のエントリでもお話したとおり、今回は特別に私は一人でこのプロジェクトに取り組んでいます。Gomaa先生のリサーチアシスタントとして参加している研究プロジェクトに、この課題を利用することになっているからです。実際、Gomaa先生は私の設計を特別扱いしてくれていて、前もって私の設計に目を通し詳細を詰めました。おそらく、他の学生たちの採点にも利用するのではないかと思われます。研究プロジェクトとしては、各ユースケースについてアクティビティモデルを作成し、そこからソフトウェアアーキテクチャを自動生成できないか、詳細に検討する予定です。

個人プレーの利点
他の学生たちの様子を見ていると、グループ内でいろいろな点で合意を得るのに苦労しているようです。設計には正解はひとつだけとは限らずいくつもやり方がある場合が多いので、意見が分かれるとなかなかまとまらない危険性があります。その点、個人でやらせてもらったおかげで、合意を得るための時間の浪費を避けることができました。

個人プレーの欠点
今回の課題はそもそも５人一組のグループ向けに設計されているので、１１個もユースケースがあります。グループワークでは、一人２個か３個のユースケースに分担できそうです。実際、今日の提出までには、モデルだけでなく各オブジェクトの説明や各メッセージの説明も添付する必要があったので、３０ページ以上のドキュメントになりましたが、それを一人で作成するのにはとても時間を費やしました。

ソフトウェアを設計するには実装経験が必要
今回の課題を通じて再認識したのは、ソフトウェア設計の難しさです。今回の課題では、他の学生からたくさん質問を受けて、思わぬ英語の訓練になったのですが、共通して言えるのは、みんな実装経験があまりないので設計しようにもオブジェクトやスレッドのイメージが沸かないようです。そのせいで、ステートチャートでモデリングが必要なオブジェクトと必要のないオブジェクトの区別が付かなかったり、ある処理を行うのに必要な情報が抜けたりするようです。
また、興味深いのは、仕事をしているパートタイムの学生で実装経験（例えばJavaのプログラミング経験）があっても、少し抽象度の高いレベルでオブジェクトの振る舞いを頭の中で仮想的に模擬するのが難しいようで、実装できないような設計をしてしまっている場合があったことです。こちらではいったん学部を卒業したら就職しお金をためてから改めてマスターを採りにくるパートタイムの学生が多いのですが、やはり学部でのソフトウェアの勉強や数年の実務経験だけでは不十分なのかもしれません。