MIS.W 公式ブログ

早稲田大学公認、情報系創作サークル「早稲田大学経営情報学会」(MIS.W)の公式ブログです!

デスマ回避!分析設計のススメ!【カウントダウンカレンダー2018冬4日目】

こんにちは. 51代プロ研のくまちゃんです. ついこの間秋学期が始まったと思っていたのに, もう12月だなんて時が経つのは早いですね...汗

長ーい(?)前置き

さっそく本題ですが, 皆さんはソフトウェア分析・設計という言葉をご存知でしょうか? 聞いたことがないという人も少なくないと思います. 僕もこの言葉を初めて知ったのは, 今年の5月, ソフトウェア工学Aの講義の中でした. 簡単に説明しておきましょう.

ソフトウェア分析

ソフトウェア分析とは, 作りたいソフトウェアの実装(プログラムを書くこと)を考慮せずに, そのソフトウェアがどのようなものか, どうあるべきかを考えることです. 具体的には, 次の3つのステップに分類されます.

  • ドメイン分析 : 今から扱うソフトウェアが対象とする世界にはどのような概念(モノ)があるのかを洗い出す作業のこと.

  • 要求分析 : 今から扱うソフトウェアはどんな機能を持っているべきかを洗い出す作業のこと. 各機能をユーザとシステムの間の交互のやり取りと考えたときに, どのような流れで実現されるかも考える.

  • システム分析 : 要求分析で洗い出された機能をシステムとして実現しようと考えたときに, 具体的にシステムをどのような構成にするべきかを考える作業のこと.

基本的には, これら3つのステップは上から順に進んでいきます. 徐々に「何を」扱うのか, 「何を」したいのかということから, 「どのように」実現するかへと変わっていきます.

ソフトウェア設計

ソフトウェア設計とは, 作りたいソフトウェアの実装を十分に考慮して, ひな形であるデザインパターンなども参考にしながら, 理解しやすい・再利用しやすいプログラムとなるようにソフトウェアの構造を考える作業をいいます. 使用するプログラミング言語ごとに設計の思想や細かく考えなければならない事項も変化していきます.

デスマ回避ってどういうこと??

デスマとは, デスマーチの略で, 主にプログラミングなどにおいて, 納期がギリギリになって大慌てで作業をせざる得ないような状況をいいます. 皆さんも, 課題等の着手がギリギリになって大変な思いをした, なんて経験が1度はあるのではないでしょうか...涙

みんなで, あるいは1人であっても, ある程度大きなソフトウェアを作ろうと思ったときには, 分析・設計をするとそんなデスマを回避できるかもしれません! 例えば次のような利点があります.

  • ソフトウェアの全体を把握してからプログラムを書き始められるので, 見通しがよくなる.

  • この人はこの部分を作る, 別の人はこの部分を作るというように役割分担がしやすくなる.

  • 仕様変更に強いプログラムを書くことがより簡単になる. 特に, 余裕がないからこの機能はやめよう, あるいは余裕が出てきたからこんな機能もつけようということがしやすくなる.

ケーススタディ

前置きがまあ長い, 長い!! そしてよくわからん!!
そんなあなたのために1つ例を使ってソフトウェア分析について考えてみましょう. 設計は先も言ったようにプログラミング言語によって様々異なる側面があるので, ここでは扱わないことにします. 宗教戦争したくないし

例として, オセロを扱いたいと思います. オセロを知らない人はきっといない(はず)なので, イメージを持ってもらいやすいのではないでしょうか. それではさっそく, ソフトウェア分析の3ステップのうちの最初である「ドメイン分析」を進めましょう!

ドメイン分析

オセロを知らない人はきっといない(はず)なんて言いましたが, そもそもオセロというゲームにはどんなものが出てくるでしょうか. そんなことを考えるのがドメイン分析です. 1人で考えていても抜けや漏れが出てきてしまうと思うので, みんな大好きWikipedia先生の力を借りましょう!

一言で言えば、プレイヤーは「石を黒白交互に挟むように打ってひっくり返し、最後に石が多い方が勝ち」となる。

具体的には次の通りゲームを進めていく。
1. 8×8のマス目の緑色のオセロ盤の中央に右上を黒として、石を黒白2個ずつ置き、ゲームを開始する。
2. プレイヤーは交互に黒石、白石を打つ。石は両面が白と黒になっており、石を打つとき、縦・横・斜め方向に相手色の石を自色で挟み、挟まれた石を自色に返す。相手の石を返すことができないマスに石を打つことはできない。
3. 打てるマスが全くない場合はパスとなり、相手が続けて打つことになる。パスの回数に制限はないが、返せる相手の石が1つでもある場合、パスをすることは認められない。
4. 最後まで打って、石が多い方が勝ちである。なお最後とは「マスが全て埋まった場合」、「両者とも打てるマスがなくなった場合」のいずれかである。

引用元 : オセロ(遊戯) - Wikipedia

この文章の中にいくつかの名詞が出てきています. それらを見つけて図として表してみましょう. ここでは, 統一的モデリング言語(UML)を用いて図を描いてみます. 僕はこんな感じにしてみました.

f:id:kumachan_math:20181130211337p:plain
概念レベルクラス図
これでドメイン分析は完了です!

要求分析

オセロのソフトウェアで実現したい機能をあげてみましょう.

答えは案外単純です. 僕はこんな感じにしてみました. 要するに, オセロをプレイしたいんですよ, ええ.

f:id:kumachan_math:20181130213140p:plain:w450
ユースケース

次に, オセロゲームのユーザとシステムの間の交互のやり取りをフローチャートとして描いてみましょう. 幸いこれはWikipedia先生がほとんど答えを書いてくれています. 僕はこんな感じにしてみました. 決して見やすくはないですがですが, まあこんな感じで流れをかくのだなぁと雰囲気だけ見てみてください.

f:id:kumachan_math:20181130222421p:plain:w450
アクティビティ図
さて, ここでソフトウェア分析の必要性が1つはっきりと見えました. それは, このオセロゲームのシステムを僕はユーザ対コンピュータで対戦するものにしようとしているということを明確にすることができたということです. もしなんとなくプログラムを書き始めていたら, Aさんはユーザ対コンピュータを想定していたのに, Bさんはユーザ対ユーザを想定していて全く違うものができていたなんて悲劇が起こるかもしれないのです. しかし今, こうして図にしたことで, 「今回はユーザ対コンピュータのものしか考えませんよ」ということを決めて宣言した, 読者である皆さんと共有したということになります.
それ以外にも, 「各局面では石の数が何対何であるかを見られるようにしましょう」とか「石が置けなくなったときのパスはユーザからのアクションを求めないでシステムが自動でやるようにしましょう」なんてことがこの図1つでわかります.

お絵かきは重要なんです. いいですか, お絵かきは重要なんです. (大事なことなので

フローチャートもかけたので, いよいよこれをシステム化することを考えましょう.

システム分析

システム分析では, 先に記述した相互の動作をいかにシステムとして実現するか, その内部構造を考えていきます. 今回は最新のアーキテクチャ思想ではありませんがモデル・ビュー・コントローラアーキテクチャ(MVC)にそってシステム化することを考えましょう.

MVCでは, システムのコンポーネントをモデル・ビュー・コントローラという3つに分類して考えるアーキテクチャをいいます. それぞれの役割は次のようになります :

  • モデル : システムが扱うデータ. 概ねドメイン分析で現れた概念がそのままデータになることが多い.

  • ビュー : ユーザに対して見せる画面やそのサブウィンドウ・部品など. ただ表示するだけでなく, ユーザからの入力を受け取る役目も持つ.

  • コントローラ : ビューからの入力刺激をきっかけとして各種処理を行ったり, モデルの内容を変更したりする.

僕はこんな感じにしてみました. これまた, 決して見やすくはないですが, こんなものです. 仕方ないです. 丸に取手のようなものがついているのがビュー, 丸にぐるっと1周矢印が書かれているのがコントロール, 丸の下に横線がついているのがモデルです. 矢印は, 指している側が指されている側の関数を呼び出すといった感じです.

f:id:kumachan_math:20181201020822p:plain
コミュニケーション図

ようやく分析まで終わりました. よしこれで設計だ! プログラムに向けて一直線...!! としてしまって本当にいいでしょうか...?
このMVCを書き表した図, 抜けや漏れはありませんか? (あれ, 各プレイヤーの石を置ける場所があるかどうかって誰が判定するんでしょうか...それに, スコアを更新したはいいけど, 表示ってされそうでしょうか...)
さらに戻って, フローチャートは本当に作りたいシステムを表現できているんでしょうか. 実はユーザ対ユーザがよかったとかないでしょうか.

とまあこんな感じで, 一筋縄ではいかないのが分析工程です. 大丈夫です, ソフトウェア分析は難しいんです. 悩んでいいんです. あ, でも, プログラムになっちゃってから悩まないでください. さもなくば, デスマの3文字があなたの前に現れます.

加えて, 悩んだ時に図を見ながらみんなで悩めるのもこうした工程を踏むメリットです. プログラムになってから他の人に相談したって, 「ちょっと読むから時間ちょうだい」ってなります. でも, 図の段階なら多少見づらいものであったとしても, 1からプログラムを読むよりは時間がかかりません. 修正が楽なんです. 悩むのが楽なんです.

まとめ

長々と書いていきましたが要するに,
お願いです. 大きなシステムを作ろうと思った時には, いきなりプログラムを書き始めないで, イメージを持つために, 共有するために, まずは作りたいシステムを図に起こしてください
僕が言いたいのはこれだけです. 本当にこれだけです. ここだけ読めばいいです. あといらないです.

そんなわけで, 今日はソフトウェア分析・設計, それからUMLという言葉を覚えて帰ってくれれば嬉しいです. お絵かきは重要です(3回目)

明日は, りょーたろーくんの「イルカとサメと宇宙人と」だそうです. ちょっと不思議なタイトルですね. 僕も読むのが楽しみです. お楽しみに! 以上51代くまちゃんことUMLおじさんがお送りしました!