ソフトウェアの標準と部品化 1

今回はソフトウェア開発に関連した標準指向や部品化についての話題です(専門的な細かい話ではないですが)。

近年は、ソフトウェアのモデル化にUML記法が利用されることが一般化してきているようです。

いくつかの理由がありますがデザインパターンと同様、モデル化、設計の共通の表現としてコミュニケーションやドキュメンテーションを作成するために利用しやすい状況にあるということだろうと思います。

　　▼@IT「5分で絶対に分かるUML」
　　　　(わかる人にしかわかりませんが、平易に簡潔に説明してあります。)
　　　　http://www.atmarkit.co.jp/fjava/devs/01fivemin/fivemin00.html

　　▼IT用語辞典 e-Words : デザインパターン【design pattern】
http://e-words.jp/w/E38387E382B6E382A4E383B3E38391E382BFE383BCE383B3.html

このような手段や技法、とりわけ標準化が必要となる共通の手法に関しては、ある程度の支持者ができると、宗教的とも言える働きかけを廻りにする人が現れたり、関連した製品などを事業とする企業も勢いづくので、その発言や宣伝では「絶対的」であるかのような表現を用いられることもしばしば見受けられます。

UMLは、長期間かけながらユーザーが増えたことでようやく共通の言葉としての表現力を持ち始めた所と言えると思いますが、やはり「実装ソースコードではなくUMLのモデルが資産だ」というような過激な表現を見かけることもあります(上のリンク先の@ITの記事も最後のページには「UMLを用いない設計はオブジェクト指向にあらず」と書かれていますね)。

ソフトウェアの資産というものは簡単そうに見えて非常に難しく、多くの人が取り組まれていながら決定的な方法というものは、まだ確率されていない(運用はされてある程度の成果はあるにせよ)難しい問題だと考えています。

資産化と言われる場合、開発という視点では、ソースコードの共有や部品化を指すことが多いかと思います。

部品化も共有化も日常的に行われていますが、言語の標準すら変化していますから、良く言われるハードウェアの部品のようにそのまま利用することができないことが往々にしてあります(以前のコードは、上位互換の新しいコンパイラですら無変更ではコンパイルできないこともあります)。

　　▼IT用語辞典 e-Words : コンパイラ【compiler】
　　　　http://e-words.jp/w/E382B3E383B3E38391E382A4E383A9.html

10年前にWindows用のGUIを自分のプログラムで使いやすいように部品化していた人がWEBサーバーでPHPやJavaの仕事をしていたり、する場合には全く部品が役に立っていません。

開発言語やシステムに関してもかたくなに保守的に不変にしなければ、部品の規格が変化してしまうので、部品が部品にならなくなります。

ところが、ハードウェアもOSも変化しますから不変を保ちながら長期にわたって保守、運用しつづけることは中々困難です。

システム導入時と同じシステムと開発関連一式を新規に揃えることも困難ですから状況に応じて変更しながら運用して行くことになります。

そのような中には、COBOLやFortranで書かれたコードを一新するというような劇的な変更が必要となる局面も発生します。

システム変更のプロジェクトを開始するとして旧式システムや以前主流であった開発言語で開発経験のある技術者など、有用な人員が確保できなくなるため人的にも難しい状況が生まれます(有用なコードを移植しようにも以前の言語を十分に理解できなければコード自身は使えません)。

コードの部品化の努力がなされていても、このような変化には無力に近いため、先に挙げたようなUMLモデル化などのもう１段階抽象化が高いレベルでの資産化などの発言になるのだと思いますが……

この話題は次回につづけます。それでは、次回もよろしくお付き合いください。