開発方法

大きな流れとしては「要件定義、分析、設計、製造、テスト、配備、運用」となるのだが、
構造化にしろ、OOにしろ、DOにしろ、いまいちしっくり来ない感じがしていた。

ベストプラクティスとしての方法を紹介するというスタンスであって、
論理的でない部分が多かったように思う。
今にして思えば、論理的に説明するための基礎が不足していたからではないだろうか？

そこで、いくつかの素案をメモしておく；

・要件定義：実現したいシステムを表現したもの(単なる要望でなく、実現基準を持つ)
・分析：モヤモヤしている要件を複数の次元に分解して詳細を明らかにしたもの
　　例）業務機能、基盤機能、性能、システム把握、運用性、操作性、、、
・設計：上記の複数次元からなら定義を１つのシステムとして実現(実装、運用)できるような要素に分解し、その作成の筋道を明らかにしたもの
・製造：設計指示をもとに実行できるコードを生成し、単体レベルテストを実施する
・テスト：システム全体の要求を満たすかのテスト
・配備：実際の運用環境に適用する
・運用：

■トレーサビリティ

システム開発で分析や設計に力をいれるのは、トレーサビリティを確保するためだと思うようになった。
というのは、実際のシステム運用において、障害が発生したり拡張要求が発生した場合に大元の要件と対応する実現物(コードなど)の対応がとれないことが多く、これがシステムの理解を悪化させているのではないかと思えたからだ。トレーサブルでないシステム(これが大半だと思うが)では、システムの現状に関して信頼できる資料は実際に動作しているコードのみとなる。要件とコードの対応がつかないのでは当然である。

しかし、トレーサブルでないことがデファクトとなっているシステムをトレーサブルなものにすることができるのであろうか？これに対する構想を以下に述べる；

■現在使用可能なトレーサブル

たとえば、DBのテーブルやOOのEntity定義などはほぼ完全にトレーサブルと言える。要件として、「これ、これ、これ」と指定された項目をまとめて管理するという枠組みは非常にシンプルであり、正規化などで形式が変わってみていても上流の定義に戻すことは容易である。つまり、下記のような双方向変換が容易にできる。

データ定義　＜＝＞ モデル ＜＝＞ コード

■モデリングの限界

UMLなどのモデリングでは、なんでも出来そうに思われるが、それは上記のデータ構造に関してであり、動的な側面の記述という観点からは、基本的に用意された定義だけを使っている限り意外と表現力が乏しいと感じる；

例えば、簡単は電卓の動作をUMLだけで記述することが出来るであろうか？ 特にNキーロールオーバのような複数同時実行する場合の挙動を記述するのは簡単ではない；さらに、それが出来たとしても、そこから何らかの言語への変換が出来るであろうか？ 既存の変換ツールは状態変化(ステート図)を対応するクラスの挙動に変換するという極めて狭い領域をカバーするものが多いと感じる(すべてを見たわけではないのだが、、、)

■代替えとしてのDSL

では、UML以外のモデリングとして何が考えられるであろうか？ それはDSLだと考えている。
UMLで特定のDSLを記述することができれば間接的にUMLで表記したことにはなるが、そこにこだわる必要性を今は感じない。

例えば、機能表現に特化したDSLでシステム要件の機能部分を分析し、性能に特化したDSLでシステム性能要件と記述するという形にすれば、分析作業とは「システム要件をM次元の直交要素に分解しそれを固有のDSLで記述すること」と考えることができる。

さらに、設計は記述されたDSL要素から実現コードへのコンバータの生成(定義)と捉えることができる；
DSLをテストフレンドリにしておけば、生成されたコードをDSLを使用してそのままテストすることができ、要件が変わってDSLを書き換えたらテストまで自動で流すことができるようになる。

要件 ＜＝＞ M次のDSL記述 ＜＝＞ 実行コード

■開発作業の変化

DSLを中心に捉えてみると、システム開発作業は以下のような形にすることができる；

１）要件定義：聞き取りと文書化
２）DSL作成
３）コンバータ開発
４）生成、テスト
５）システムテスト

DSL作成の中でもUI部分やデータ定義などで分業できる要素があり、コンバータ部分は開発会社の強みとして自社で抱え、システムテストは人件費の安いところに外注するという工程も成り立つと思う。

そのためには、DSL ＝＞システムテスト という生成ツールが欲しいところである。