開発とナレッジベース管理:GeneXus X と旧バージョンの比較

このドキュメントは、旧バージョンの GeneXus を使用した経験のあるユーザーを対象としています。このドキュメントの目的は、旧バージョンの GeneXus と GeneXus X の開発プロセスとナレッジベース管理に関連する概念、コンポーネント、および方法論を、新しいシナリオに基づいて比較することです。

GeneXus X および旧バージョンの GeneXus で使用可能な開発およびナレッジベース管理のコンポーネント

旧バージョンの GeneXus:
モデル (1 つの設計モデルと、1 つ以上のプロトタイプおよび本番運用モデル)。さらに、それぞれのモデルに、1 つ以上の環境 (ジェネレーター) とデータストア (DBMS) が含まれます。
GeneXus X:
新しいバージョンのナレッジベースで使用できるコンポーネントは、環境 (旧バージョンの環境とは概念が異なる)、Frozen バージョン、および開発バージョンです。環境には、1 つ以上のジェネレーターとデータストアが含まれます。
主な変更点は、モデルの概念がなくなり、設計/プロトタイプ/本番運用の環境の扱いが変わったことです。
上記のコンポーネントによって、開発プロセスの構成と開発するシステムの保守という 2 つの重要なタスクを実行できるようになっています。
開発作業の編成には、開発する対象と開発方法に関するすべてが関係します。たとえば、生成するプログラミング言語や、生成されたアプリケーションで使用するデータベースなどが含まれます。
一方、開発対象システムの維持には、開発する製品のバージョン、顧客への製品提供、各開発者が使用するナレッジベースのバージョンなどに関するすべてが関係します。
ここに、GeneXus X と旧バージョンの最初の大きな違いがあります。
これまでは、同じコンポーネントを使用して両方のタスクが実行されていました。つまり、同じコンポーネントの中に、ユーザーの要件に応じた異なる機能が含まれていました。
GeneXus X では、これらのタスクは明確に区別され、各タスクの実行に使用されるコンポーネントも区別されます。また、これらのタスクに関するすべてのことを GeneXus で実行し、すべてのナレッジを一元管理して混乱や不整合を避けるという考え方が採用されています。

開発プロセスの編成

GeneXus X では、このタスクに関連するオプションはナレッジベースナビゲータの [ 設定 ] ウィンドウにあり、使用されるコンポーネントは環境、ジェネレーター、およびデータストアです。
GeneXus X の環境は、旧バージョンのプロトタイプと本番運用モデルを設計モデルと統合したものに相当します。各環境には 1 つ以上のジェネレーターとデータストアが関連付けられています。
新しいプログラミング言語でアプリケーションを生成するには、新しい言語または新しい DBMS に対して、対応する特性を持つ新しい環境を作成する必要があります。
複数の環境を作成できますが、アクティブになるのはその中の 1 つだけです (アクティブな環境のことを「ターゲット環境」と呼びます)。[ ビルド ] オプションはすべて、そのターゲット環境に適用されます (F5、すべてをビルド、データベーステーブルの作成など)。
旧バージョンで考えると、GeneXus X で複数の環境を作成するということは、旧バージョンで複数のプロトタイプまたは本番運用モデルを作成することと似ています。ただし、GeneXus X ではすべての環境がデータ構造 (設計モデル) を共有しています。したがって、これらの GeneXus X の環境は、旧バージョンの同期されたプロトタイプまたは本番運用モデルに代わるものといえます。
GeneXus X では、データ構造 (トランザクション、テーブル) に対する変更は既存のすべての環境に適用され (旧バージョンに置き換えると、すべてのプロトタイプまたは本番運用モデルに対して自動的に影響を及ぼすような状態)、以降のビルド処理でその変更が反映されます。

開発対象システムの維持

実際、旧バージョンには、タスクに固有のコンポーネントや機能は存在していませんでした。そのため、状況に応じて使用可能なもので間に合わせていました。これには、一貫した概念や方法論の欠如といった明らかな問題がありました。各チームがそれぞれ独自のプロシージャーや、同じ概念 (モデル、ナレッジベース) が異なる目的で使用されたため、混乱が生じていました。
GeneXus X では、このようなあいまいさをなくし、これらのタスクの概念を統一しているだけでなく、中央の 1 箇所、つまりナレッジベースですべてを管理するようになっています。
これらすべてを実現するために、バージョンの概念が導入されました。1 つのナレッジベースには、複数の Frozen バージョンと開発バージョンを含めることができます。これらのコンポーネントは、[ Knowledge Base Versions ] ツールウィンドウから管理します。
Frozen バージョンは、開発バージョンの状態を特定の時点でフリーズしたもので、後で使用できるように保持されます。旧バージョンに置き換えると、Frozen バージョンとは、新しいプロトタイプまたは本番運用モデルを作成し、それに設計モデル情報をコピーして、今後変更できないようにしたものといえます。
標準的な例としては、開発中のアプリケーションを顧客に提供する場合が考えられます。その時点で、将来参照する場合に備えてこれまでの状態をフリーズする、つまり、Frozen バージョンを作成します (読み取り専用として開発バージョンから切り離す)。その後、アクティブな開発バージョンで開発作業を続けます。万が一顧客のバージョンを修正する必要が生じた場合は、進行中の開発作業と並行および直交して、顧客に提供したバージョンそのものから修正を開始できます。顧客のバージョンを修正するために、上記の Frozen バージョンから新しい開発バージョンを作成します。
これまで、このようなタスクでは顧客にアプリケーションを提供するたびにナレッジベースが増え、ナレッジベースを一元管理できなくなっていました。また、新しいナレッジベースを修正または調整した時点で整合性が失われる可能性がありました。
GeneXus X では、これらすべてが同じナレッジベースで一元管理されるため、整合性が維持され、バージョン間での透過性および影響分析の信頼性が向上します。
旧バージョンでは、本番運用モデルに対する変更には、プロトタイプモデルに対する変更が含まれていました。GeneXus X では、異なる開発バージョンで作業するとき、ある開発バージョンでの変更は別の開発バージョンに影響しなくなりました。
つまり、旧バージョンに置き換えると、各 Frozen バージョンは独立した異なるナレッジベース (ただし、別のナレッジベースから作成されたもの) であり、それぞれ固有の環境 (対応するジェネレーターとデータストアを含む) と固有のデータモデルなどを持っているといえます。一方、GeneXus X のナレッジベースには、旧バージョンでアプリケーション開発の管理と維持に使用していたすべてのナレッジベースが含まれます。
これらの新しい機能は、保守オプションのさらなる拡張と単純化を可能にします。たとえば、1 つのナレッジベース内に、異なる顧客に提供した同じアプリケーションの複数のバージョン (おそらく異なるバージョン) を格納できます。そのため、これらすべてのバージョンを、新しいバージョンのアプリケーションまたは特定の修正プログラムに容易かつ透過的にアップグレードすることができます。

GeneXus X と旧バージョンにおける開発の概念と手順の比較

旧バージョンでの概念	GeneXus X での概念
設計モデル。	システムの論理的表現を含む、環境の一部。
プロトタイプ/本番運用モデル。	実行プラットフォーム情報を含む、環境の一部。
1 つのプロトタイプ/本番運用モデルに複数の環境。	1 つの環境に複数のジェネレーター。
1 つのプロトタイプ/本番運用モデルに複数のデータストア。	1 つのジェネレーターに複数のデータストア。
同期された複数のプロトタイプ/本番運用モデル。	同じ開発バージョンの複数の環境。
同期されていない異なるプロトタイプ/本番運用モデル。	異なる開発バージョン (完全に同じにするには、両方のバージョンが同じデータ構造を持つ必要があります。旧バージョンではデザインが共有されますが、GeneXus X では共有されません)。

操作	旧バージョン	GeneXus X での操作
アプリケーションの新しい実行プラットフォームを追加する。	プロトタイプ/本番運用モデルと適切なプラットフォーム情報を追加する。	新しい環境と適切なジェネレーターとデータストアを追加する。
設計モデルのプロパティを変更する。	設計モデルのマスタープロパティウィンドウ (モデルの編集) でプロパティを変更する。	[ 設定 ] ウィンドウでルートノードのプロパティを変更する。
プロトタイプ/本番運用モデルのプロパティを変更する。	プロトタイプ/本番運用モデルのモデルのプロパティウィンドウ (モデルの編集) でプロパティと DBMS オプションを変更する。	[ 設定 ] ウィンドウで環境、ジェネレーター、データストアの各プロパティを変更する。
アプリケーションを稼働させる (リリースする)。	新しいプロトタイプ/本番運用モデルを追加し、そのモデルからアプリケーションをビルドする。	開発経路 (通常、メインの経路) でバージョンをフリーズさせ、この Frozen バージョンから新しい開発バージョンを作成して、アプリケーションをビルドする。すべて同じナレッジベースに格納する。ｆ
顧客に配布するバージョンをフリーズする。	ナレッジベースを物理的に複製する。	同じナレッジベースの新しい Frozen バージョンを作成する。
顧客ごとに異なる Frozen バージョンを格納する。	ナレッジベースを物理的に複製する。	同じナレッジベースの複数の Frozen バージョンを作成する。
リリースバージョンのエラーを修正する、またはリリースバージョンを調整する。	新しく複製 (バックアップ) し、別のナレッジベースで修正する。	Frozen バージョンから新しい開発バージョンを作成し、この新しいバージョンを修正する。すべて同じナレッジベースに格納する。
顧客のアプリケーションをアップグレードする。	本番運用モデルの影響分析を行い、新しいアプリケーションをビルドして、古いアプリケーションと置き換える。	開発経路にあるバージョンをフリーズし、この Frozen バージョンから新しい開発バージョンを作成する。さらに、この開発バージョンを使用してアプリケーションを生成し、古いアプリケーションと置き換える。
複数の顧客の異なるリリースバーションをアップグレードする。	相互に完全に独立した異なるナレッジベースの本番運用モデルの影響分析を行う (同期が失われることが多い)。	開発経路にあるバージョンをフリーズし、この Frozen バージョンから、各顧客向けの新しい開発バージョンを作成する。さらに各顧客のアプリケーションを生成する。作業全体は同じナレッジベースで実行され、同期も維持される。