 |
||||||||||
|
仕様記述言語とコミュニケーション フェリカネットワークスの栗田氏によれば、従来の開発手法では「適当に書かれた仕様に基づいて適当にレビューして、開発して適当に試験していた」ためにいくらレビューやテストをしてもその「正しさ」が判断できない曖昧な状況だったという。このため現場の担当者のストレスは大変なものがあった。 これに対して仕様記述言語を用いたことで、「明確な仕様記述に基づいて、論理的なレビューを実施でき、仕様記述に基づいて明確なテスト仕様を作成し、テストを実施することができるようになった」ため、従来のような曖昧な状況が生じなくなったとのことだ。これにより、客観的に仕様の問題点を摘出しやすくなるだけでなく、現場の担当者のストレスも減少したということである。 これは、仕様記述言語を開発者の共通言語とすることでコミュニケーションを改善できた好事例である。成功した理由として、仕様記述の読み書きのしやすさの問題とも関係するが、自然言語による表現や問題領域の知識の表現と仕様記述内容との対応関係を明確にしておくことが大切であることがあげられる。
仕様記述言語と再利用 組み込み開発などでは、明確な仕様書があるのではなく、作っては直し、作っては直しの繰り返しで開発していることが多い。また、この過程でようやく業務知識が担当者に身についてきたとしても、今度はその内容を他の人に引き継げるかというと、それも仕様がないから難しいという現状がある。 もし現場の担当者の業務知識を仕様記述することで、知識の可視化を可能にすることができれば、組込み開発現場での知識の再利用が進むだけでなく、仕様が明確になるのでテストも容易化できるようになるだろう。 しかし、仕様記述言語を用いて業務知識や開発対象システムを現場の担当者だけで記述できるかといえばなかなか難しいかもしれない。そこで仕様記述の専門家が、現場の担当者がどのようなシステムを開発しているかを聞きながら仕様記述することで、現場の業務知識の明確化を進めていくのが現実的なやり方になると思われる。また現場の担当者も専門家とコラボレーションする過程で自分たちの業務知識の曖昧さや常識を疑うことで結果的に仕様記述の質を向上できる可能性がある。 HowとWhatとWhy プログラム言語では機能をどのように実現するかという「How」を記述するのに対して、仕様記述言語ではどのような機能を作成すべきかという「What」を明確に定義する。 しかし、その機能がなぜ必要か、どのような特性を持つべきかというような「Why」を記述することはできない。したがって、仕様記述言語によって記述された仕様がよいかどうかを判断するためには、システム開発の目標という別の視点が必要となる。これらの目標は、セキュリティや性能、操作性などの非機能要求によって定義する必要がある。 まとめ 今回は、Z言語とVDM-SLの基本的なデータ型や言語の違いを比較した。また仕様記述言語の適用上の留意点を紹介した。現場レベルで仕様記述言語の効果を実感したプロジェクトが出はじめたことは素晴らしい。 しかし、まだ課題も多いのが実情だ。例えば、AADL（Architecture Analysis & Design Language）などのアーキテクチャ記述言語と仕様記述言語の併用の課題があげられる。これらの課題を1つずつ解決していき、今後もこの分野における技術開発を後押ししていきたい。また、技術開発がソフトウェア開発手法の今後の発展に寄与してくれることを期待しつつ、筆を置くこととする。 |
||||||||||
|
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
