|
前回は概要を中心に考察しましたので、今回は実態に触れてみたいと思います。
まず ハッキリ言って 仕様以前の問題なのです。
それは 要件定義 が最も基本的だという話になります。
たとえば…。
95系のＯＳだと 「メモ帳」の最大編集可能サイズは 64k Byte なのです。
NT系だと空きメモリーの許す限りなのです。
この差は大きいです。
仮想メモリーを使うにしても、その大きさも違います。
ここに 500kByte のテキストファイルがあります。
そのソフトウェアを使うと 文字コードが変換されます。
そのソフトウェアは途中経過も表示するものとします。
ここで要件と言うのは
この２点なのです。
途中経過を表示するために（メモ コントロール）というＯＳ提供の機能を利用します。
（その方が簡単に作れるからです。 コスト面からのアプローチですが。）
ところが、このＯＳ提供の機能部品がバージョンによって仕様が異なる訳です。
具体的には扱うことのできる文字数に差があるわけです。
このコントロールを使ってソフトウェアを作成すると NT系ＯＳでは問題なく動作します。
ところが 95系だと 取り扱い可能な文字数が限定されるため、そのままでは動作できません。
なぜなら 扱うファイルサイズが 500kByte もあり、全体を収容できないからです。
さて、どうしましょう？
ここで大切なのが 要件 なのです。 仕様定義はそこから行われるからです。
要は 途中経過の表示ですから、全体を表示する必要は無いのです。
仮にそのウィンドウを画面いっぱいに拡大しても、表示可能な文字数は 64kByte を超えません。
だから、現在処理中のテキストだけで良いのです。
ＮＴ系ＯＳであれば処理は一直線なのです。
- テキストファイルの読込み
- 文字コード変換（加工）
- 結果の表示（メモ コントロールに追記）
- すべて変換し終わったらファイル化（書出し）
これだけで処理が終わってしまいます。
これを 95系ＯＳ上で再現するには…。
- 加工可能なサイズだけテキストファイルの読込み
- 文字コード変換（加工）
- 結果の表示（メモ コントロールに表示）
- 一時ファイルに結果を追記
- 1.へ戻って未処理部分から読込み、
- すべて変換し終わったら一時ファイルから結果ファイルに書き込み
と言う結果になります。
こうすると、見た目は変換工程を表示する事が可能になります。
これは一例に過ぎませんが、データを小分けする事によって実現しています。
そして重要な事は、仕様はともあれ要件を満たしていることなのです。
当然、処理が複雑化し処理効率は良くありません。
ですが、無いからといってオリジナル機能を実装するとコスト面で納期や価格に跳ね返ってきます。
この方法は「有る機能を有効に使う」という手法で問題を解決しています。
そして、ＯＳによって挙動を変更すれば、最小限のコストでバージョン間の互換性が得られます。
今度は同じ例で、違ったアプローチをしてみます。
95系では NT系で拡張された機能は使えません。
だったら 拡張された機能と同等のモジュールを作ってしまう というアプローチがあります。
この場合、既に供給されている機能はそれを使い、その機能が無ければオリジナル機能に頼ります。
これは言い換えると、既にある機能を重複して実装する結果になります。
つまり、追加した部分だけが無駄になります。
機能的には要件を満たしても、ＯＳを変更すると、その部分が全く使われなくなります。
メモリの無駄遣いになるのです。
どうせなら ＯＳによる違いを オリジナルコードで代替えして実装する方が互換性が上がります。
まったくＯＳの差に関与しなくなるからです。 とは言うものの、既にある機能なのです。
既にある機能を作り、検証し信頼性までも保証する事自体が無駄なのです。
現実の問題の例としてメモ コントロールを上げましたが、本当はこれだけではありません。
タイマーやファンクションコールなど微妙な差異があります。
本当は それを保証するのがＯＳの互換性なのですが、現実には保証されていません。
極端な言い方をすると ハードウェアを買い換えさせる手段として使われたりします。
対するユーザーもバカではありません。
互換性が重視されるのに、それを無視した製品は買わないし売れないのです。
かつて Windows ME がそうであったように Vista の普及度が低迷しているのは こういう理由からなのです。
互換性を切り捨てるだけの強力な根拠や理由があれば 誰でも納得する部分なのですが、
現実にそうではないだけにソフトウェア作成者を始めユーザーが困るという訳です。
個人的には、もうＭＳの時代は終わってもいいと思うんですけどね…。
|
ゲーム
