日経コンピューター2014年2月6日号、91ページ
「脱出!暗闇プロジェクト」第三回の
セオリー4 品質を後付けしてもよいモジュールを見極める
だが、実は、品質は後付けできる方法がある
(作りかたによっては後付けできる)
その方法と、その証明とまではいかないけど、説明を書いてみる。
■まずは、品質とは
というと、ソフトウェア品質特性になる。
ここで、品質特性は、
機能性、信頼性、使用性、効率性、保守性、移植性
になる。機能性のうち、
正確性は、ロジックに依存する部分になる。
しかし、これ以外の、
信頼性を上げる→入出力障害に対応
使用性→ユーザーインターフェース(入出力)
効率性→資源=入出力+メモリ、CPU処理
保守性→表示部分+ロジック部分
移植性→表示部分+ロジック部分
となる。そこで、
・ロジック部分を分離して、ものすごく移植性が高くする
→簡単な数式で表現する
→または自動生成
すれは、あとは入出力の問題になる。
■方針
とすれば、このようにすると、品質を後付けできる。
(1)ロジック部分を、事前条件を満たした場合、
ある数式を実行し、結果を返す
という風にする。このとき、単純な数式で表現し、
複雑なものは、局所化し、別関数(別メソッド)にする
例
商品金額=税抜き金額*(1+その商品のそのときの消費税)
買い物合計=総計(商品金額*購入数)
(2)局所化した別メソッドはあらかじめ、作っておき、テストする
(3)(1)と(2)を単体テストまでして、確認しておく。
→ここで、スピードを確認。
また、移植性、保守性あるコードで書いているかチェック。
※つまり、この段階では、値を変数にセットする形にしておき、
画面、DBなど、外部の入出力部分は、まだ作らないし、接続しない
---ここまでが、コア品質。これ以降は、後付けできる-----------------
(4)とりあえず、入出力画面を適当につける
ここで、(3)の変数と、入出力画面をつける。
フレームワークに組み込み、画面は、コントローラーで接続する。
DBは、DAO部分を、O/Rマッパーなどのフレームワークに置き換える
(5)事前条件を満たすように、画面にチェック機能を付ける
(6)DBアクセスのチューニングをする
DBのセキュリティ向上
(7)UIを装飾したり、移植性を高める
画面のセキュリティ向上
(8)実際のセッションを使うのでなければ、ここで中間メモリに置き換える
などする
(9)暗号化など
(10)(4)~(9)を、満足のいく品質まで繰り返す、ないしは
どこかを重点的に行う。
■つまり、
機能ロジック部分が出来てしまい、これが入出力と疎な関係に
つなげてあれば(ラッパーをかぶせて、ラッパーを呼び出すようにする)
入出力部分の品質は、後付けできる。
ただし、仮にフレームワークを使っても、
ロジック部分と入出力部分が密な関係に成っていると
(モデルから、DBを直接JDBCのクラスを使って呼び出しているような場合)
ロジックに手をいれないといけないので、後付けはむずかしい。
「脱出!暗闇プロジェクト」第三回の
セオリー4 品質を後付けしてもよいモジュールを見極める
だが、実は、品質は後付けできる方法がある
(作りかたによっては後付けできる)
その方法と、その証明とまではいかないけど、説明を書いてみる。
■まずは、品質とは
というと、ソフトウェア品質特性になる。
ここで、品質特性は、
機能性、信頼性、使用性、効率性、保守性、移植性
になる。機能性のうち、
正確性は、ロジックに依存する部分になる。
しかし、これ以外の、
信頼性を上げる→入出力障害に対応
使用性→ユーザーインターフェース(入出力)
効率性→資源=入出力+メモリ、CPU処理
保守性→表示部分+ロジック部分
移植性→表示部分+ロジック部分
となる。そこで、
・ロジック部分を分離して、ものすごく移植性が高くする
→簡単な数式で表現する
→または自動生成
すれは、あとは入出力の問題になる。
■方針
とすれば、このようにすると、品質を後付けできる。
(1)ロジック部分を、事前条件を満たした場合、
ある数式を実行し、結果を返す
という風にする。このとき、単純な数式で表現し、
複雑なものは、局所化し、別関数(別メソッド)にする
例
商品金額=税抜き金額*(1+その商品のそのときの消費税)
買い物合計=総計(商品金額*購入数)
(2)局所化した別メソッドはあらかじめ、作っておき、テストする
(3)(1)と(2)を単体テストまでして、確認しておく。
→ここで、スピードを確認。
また、移植性、保守性あるコードで書いているかチェック。
※つまり、この段階では、値を変数にセットする形にしておき、
画面、DBなど、外部の入出力部分は、まだ作らないし、接続しない
---ここまでが、コア品質。これ以降は、後付けできる-----------------
(4)とりあえず、入出力画面を適当につける
ここで、(3)の変数と、入出力画面をつける。
フレームワークに組み込み、画面は、コントローラーで接続する。
DBは、DAO部分を、O/Rマッパーなどのフレームワークに置き換える
(5)事前条件を満たすように、画面にチェック機能を付ける
(6)DBアクセスのチューニングをする
DBのセキュリティ向上
(7)UIを装飾したり、移植性を高める
画面のセキュリティ向上
(8)実際のセッションを使うのでなければ、ここで中間メモリに置き換える
などする
(9)暗号化など
(10)(4)~(9)を、満足のいく品質まで繰り返す、ないしは
どこかを重点的に行う。
■つまり、
機能ロジック部分が出来てしまい、これが入出力と疎な関係に
つなげてあれば(ラッパーをかぶせて、ラッパーを呼び出すようにする)
入出力部分の品質は、後付けできる。
ただし、仮にフレームワークを使っても、
ロジック部分と入出力部分が密な関係に成っていると
(モデルから、DBを直接JDBCのクラスを使って呼び出しているような場合)
ロジックに手をいれないといけないので、後付けはむずかしい。