プラットフォームのメリット   
トップページ ≫ 製品 ≫ プラットフォーム ≫ プラットフォームのメリット
プラットフォーム
プラットフォームのメリット
ソリューション
応用事例
  プラットフォームのメリット
 メリット1    開発工数の低減
従来のアプリケーション開発では、詳細な制御を作りこまなくてはなりませんでした。



複雑な制御はプラットフォームが行いますので、アプリケーションプログラム開発は 簡単なスクリプトを記述するのみとなります。これにより、開発工数を低減 する事が可能です。




 メリット2    機能の水平展開の優位性
従来の開発においては1つの機能のプログラムソースを別のプログラムへ 移植する事によって、ソフトウェア資産を再利用していました。
しかしその利用に際しては、その都度、移植作業が発生します。

プラットフォームならば、ライブラリに1つの機能を追加すれば、全ての スクリプトから呼び出し可能となり、ソースやDLLなどを移植する手間を 省く事ができます。
また、資産の所在や管理が簡潔になります。
Capitalは、標準で充実したライブラリを持っていますので、全ての アプリケーションスクリプトはすぐに高機能なライブラリを利用する 事ができます。




 メリット3    不具合のドッペルゲンガーの解決
従来のソフトウェア資産活用では、移植作業によって、多くの複製が 個々のプロジェクトのプログラムに含まれているという状況が生まれます。 これでは、それらのソフトウェア資産の中に不具合が見つかった場合、 多くの複製を全て修正するという大変な作業が発生します。
複製の中にはそれぞれのプロジェクトの事情でカスタマイズが加えられている 場合もあり、単純に修正済みファイルをコピーしただけではコンパイラを 通らない場合などもあります。

それに対して、プラットフォームでは、1機能のソースはライブラリの中だけ なので、1つのファイルを修正すれば全てのアプリケーションプログラムの 該当機能を修正できます。これにより、不具合のドッペルゲンガーに 悩まされる事はありません。




 メリット4    ソフト資産の整理
上記でも述べました通り、従来の移植を中心としたソフトウェア資産活用では、 複製が数多く存在し、最新版がどれなのかも不明確です。
また、全体としてどんな資産があるのかリストアップする事が困難です。

プラットフォームで一元管理すれば、ソフト資産の複製は1つしか存在せず、 さらに、どのようなものがどれだけあるのかを簡単にリストアップできます。
これにより、次のステップの戦略や開発計画が立てやすくなります。




 メリット5    インタプリタだからこそ高品質のライブラリ
通常の開発方式では、開発中のアプリケーション内部に大量のテスト用コードを 記述するのは無理があります。また、テスト用に別プロジェクトを作成すると、 製品用のプロジェクトとテスト用のプロジェクトで、ソースが一部異なっている というようなケースも考えられます。
それに対して、インタプリタは製品とはまったく別のテスト用プロジェクトを 作ったとしても、インタプリタのコアは同じですから、全く同じライブラリを テストする事ができます。これにより、テスト用プログラムを充実したものに する事ができます。また、ライブラリテスト用にテストデータを作成するにも、 充実したライブラリが活用できますので、テストを極めて充実させる事ができます。
例えば、CapitalはQRコードをデコードするライブラリを持っていますが、これは、 画像が回転されていても認識できる機能を持っています。そして、その機能をテスト するには回転した画像をテストデータとして与える必要があります。Capitalの ライブラリには画像回転のライブラリもありますので、例えば1度きざみで360回 のテストを自動で行う事ができます。

こうした画像認識のようなプログラムは特殊な条件が成り立った時にのみ顕在化する 不具合が時々見られます。ですから、このように緻密なテストが行える事は製品の 信頼性向上に大きく寄与するものです。
このように簡単にプログラムが作れる事がライブラリの品質の向上にもつながっています。




 メリット6    『共有と分担』を高レベルに実現
プラットフォームにおける開発は、アプリケーションのスクリプトと ライブラリ開発とに完全にセパレートされています。
Capitalは、標準で充実したライブラリを持っていますが、必要に応じて ライブラリを追加する事が可能です。
ライブラリはその機能において、専門的なプログラマが担当する事が適当です。 また、スクリプトはライブラリをブラックボックスとして利用する事が 目的ですので、ライブラリの内容を全て理解しているプログラマである必要は ありません。
例えば、メールを送信する機能を利用するのに、メール送信のライブラリが TCP/IPをどのように制御しているか理解していなくても、メール送信という 機能を利用する事はできます。
逆にライブラリ開発者はアプリケーションが使われる現場の状況を詳細に 知る必要はありません。その部分はスクリプト開発者が実情に従って 機能利用のプログラム仕様を考えるからです。
このようにスクリプト開発者とライブラリ開発者がそれぞれの持ち場を担当 する事で効率的にシステムを構築する事ができます。
一般的な開発でも、一応の役割分担は出来ますが、同じ言語で開発して しまうと、結局完成したものは、ひとまとまりになってしまい、後にメンテナンス する場合にどこからどこまでがブラックボックス機能なのか分からず、全ての ソースに目を通さなくてはならないという事になってしまいます。
このようにライブラリ開発とスクリプト開発のセパレーションが良い事によって、 ライブラリの複数のアプリケーションでの共有が簡単になります。
従来型のようにセパレーションが悪いと、あるアプリケーションで使われている ライブラリを他のアプリケーションで活用する事が困難になるからです。



 Copyright© 2013 Universal Device Network All Rights Reserved.