プログラミング言語（含：データベース定義言語、設計ツールのUI）が大きく発展し、その影響を受けてソフトウェアの設計方法も様変わりしました。プログラミング言語が進化すれば、ソフトウェア設計方法も変えて行かなければならないからです。

　例えば、詳細設計書について言えば、アセンブリ言語の時代には、ソースコードを読んでも何を意味するのか読み取るのはかなり困難だったため、分り易い表現手段としてフローチャートを用いていました。しかし、プログラミング言語が高水準化し、プログラムのモジュール構造、データ構造、アルゴリズムなどを、フローチャートなしに読み取ることができるようになると、詳細設計書で厳密なフローチャートを書く必要がなくなり、もう少し大づかみの表現で間に合うようになってきました。現在では、JAVAやCなどのプログラミング言語に対応するエディターが整備されていますので、詳細設計書そのものも不要となりつつあります。詳細設計書をソースコードの一部に含めることが可能となったのです。

　ソフトウェアの設計方法に大きな影響を与えているものとして各種設計ツールがあります。多くのシステム開発で使用されているのが画面設計ツールと帳票設計ツールです。これらを使用して、画面や帳票が直接設計できますので、ソフトウェアの設計が格段に容易となりました。

　このように、ソフトウェア・システムは、複数のプログラミング言語を組み合わせて開発することが当たり前となっています。

　図１はプログラミング言語（含：データベース定義言語、設計ツールのUI）とウォーターフォル型の各工程との関係を示しています。

図１　プログラミング言語インターフェース

　図１の空色の部分はユーザインターフェースが使用される工程を示しています。設計者は各ユーザインターフェースを使用してコード化します。また、図１から判るように、機能の一部は詳細設計工程なしにコード化できるようになっています。

　パッケージソフトウェアを使用する場合、設計者は機能設計（要求定義）工程でコード化できます。

　フレームワーク（既定の骨組み）は、データベースを中心としたトランザクションシステムのような、対象領域が限定されたソフトウェアの構築に適しています。フレームワークとは、ソフトウェアの主要な部分（幹）は動作確認済みで、枝葉になる部品を用意すれば目的のソフトウェアが構築できるEasy-Order型の開発ツールです。構造設計／詳細設計工程ではフレームワークを念頭において枝葉となる部分を設計します。

　データベースソフト、画面設計／帳票設計ツールのユーザインターフェースを使用してコード化するのは、構造設計工程です。

　パッケージソフトウェアやフレームワーク、各種設計ツールが使用できない機能については、汎用プログラミング言語（COBOL、JAVA、Cなど）やプログラム部品（モジュールやクラスなど）を使用してコード化する必要があります。この場合、構造設計工程では、クラスやそのメソッド、モジュール（の機能）を定義し、詳細設計工程では、プログラム部品や汎用プログラミング言語を念頭において、その機能の処理方式を記述します。ここでは、汎用プログラミング言語対応のエディターを使用することができます。

　上記の通り、プログラミング言語の進化は、ソフトウェアの設計全体に大きな影響を与えています。その結果、従来にはなかったことが設計上の注意点として挙がってきました。思いつくだけでも次の点は事前に十分調査しておくべきと考えます。

・	プログラミング言語の評価
・	ソフトウェア保守とプログラミング言語の寿命
・	障害対応の困難さ

１）　プログラミング言語の評価

　COBOL言語を使用して、ソフトウェアを設計していた頃は、機能設計時にソフトウェアの動作条件を予め定め、これらを満足するためには何をどうすべきか後で決定することができました。フリーハンドで設計していましたから可能だったと言えます。しかし、高水準のプログラミング言語（含：データベース定義言語、設計ツールのUI）の使用を前提とした設計では、プログラミング言語に含まれる明示的・暗黙的制約条件が利いてきますので、事前に十分調査しておかなければ、後になって、取り返しがつかないことになりかねません。

　機能設計工程でソフトウェアの動作条件を明確にし、プログラミング言語の制約条件とすり合わせておく必要があります。

２）　プログラミング言語の寿命とソフトウェア保守

　市場の要求であったり、発注者の要求であったりしますが、ソフトウェアはリリース後も機能の変更や追加を余儀なくされます。リリース後何年保守が必要か予め知っておかなければなりません。プログラミング言語にも寿命があります。ソフトウェアを保守している間はソフトウェアの開発ツールは生きていなければなりません。安易に寿命の短いツールを使って作り直しになることがないように注意すべきです。

３）　障害対応の困難さ

　各種開発ツールを利用する場合、それらの信頼性が問題となります。開発ツールの障害が即ソフトウェアの障害となるからです。一般に開発ツールのベンダーはソースコードを公開していません。更に、障害対応もしてくれないケースが多々あります。このような危険性を念頭において、ツールの限界まで使わないようにするとか、オープンソースのソフトウェアを活用するなど、危険を回避する必要があります。

■