ソフトウェア設計
先日、第一回わんくま同盟大阪勉強会に参加させていただいたので、論じてみる。「ソフトウェア設計」とわざわざ断っているのは、単に「設計」と書いた場合に誤解を招く危険があるのと、ここで扱いたい問題が SWEBOK で言う「ソフトウェア設計」だからである。
さて、ソフトウェア設計を定義してみると、以下のようになる。
ソフトウェア要求仕様の実現手段を検討し、ソフトウェア構築作業の入力成果物を作ること
これは、正確な SWEBOK からの引用ではない。私的な定義である。
一般的に、ソフトウェア開発は、上流工程で作成された成果物を入力として、下流工程の成果物を作る、という行為からなる。よって、上流工程である「要求」の成果物を入力とし、下流工程である「構築」のために成果物を作成するのが、「設計」だと考えられる。
しかし、少し現場に立ってみたら分かることだが、このような定義を行っても、実作業においては、本当に何の役にも立たない。定義はあくまでも定義である。実際にソフトウェア設計作業を行う場合には、実作業を行う上で決定しないといけない基準を決めておく必要がある。
基準とは、例えば、以下のようなものである。
- ソフトウェア設計工程では、(具体的に) 何を決めるのか
- ソフトウェア設計工程では、(具体的に) 何を作るのか
この回答に対して、さらに「具体的に」を積み重ねていくと、例えば、以下のようになる。
- モデリングツールを用いて UML でクラスを描く。
- クラスはクラス名, 属性, 操作を定義する。
- 操作には、戻り値とパラメータがあり、それぞれに型が必要になる。
- パラメータには、仮引数名がある。仮引数名は a または an で始まる。
どう考えても、キリが無い。しかし、これを決めないと、ソフトウェア設計作業はできない。一人や二人で行っているならともかくとして、個人の能力に依存しないプロジェクトを運営するなら、上記を決めるしかない。
さて、既にお気づきの方もいらっしゃるだろうが、上記の決定は、具体的な「システム」や「プロジェクト」に依存する。決定事項の一つ一つだけではなく、そもそも、何をどこまで決定しないといけないのかを決めるのも、その時の状況に依存する。
よって、ソフトウェア設計で、具体的なことを語ろうとすると、一つの壁にぶつかるだろう。その壁は、ソフトウェアエンジニアリングの世界が、未だに確固としたプロセスを定義できない現実そのものである。
勉強会で語るには、あまりにも難しいテーマであると、私は感じた。
