「ユビキタス言語ドキュメント」をソフトウェアカスタマイズプロジェクトとして扱うことができます。ドキュメント管理用のソフトウェアをいくつか用意し、それを特定のニーズに合わせる必要があります。ソフトウェアプロジェクトでは、通常、ユーザーニーズの収集から始め、情報アーキテクチャと設計ソリューションを構築してから、実装に進みます。以下はこのプロセスの例です。
ユーザーは何を必要としますか?組織によっては、異なるドメインの異なる機能を持つ人々が、問題や解決策を説明するために共通言語の方言を使用したいと考えています。ここでは発音はおそらく重要ではなく、文法は言語の文学形式に基づいているため、この方言はその語彙(単語と音声の数字)によってのみ定義されます。方言を文書化するには、語彙(用語集)の管理に最適な文書構造を設計する必要があります。
このドキュメントを使用して、単語または頭字語の意味を学習したり、同義語または定義によって正しい単語を見つけたり、ドメインを構成するすべての単語を学習したりすることができます。
これらのユーザーのニーズにとって、wikiは確かに良い選択です。どのように適合しますか?ConfluenceやMediaWikiなどの優れたウィキシステムでは、次のことが可能です。
- 用語ごとに記事を作成します。
- テンプレートに記事の共通構造を定義して、集約に使用できる共通セクションを含めるようにします。
- 他のWiki記事の用語定義へのリンクを簡単に追加します。
- 用語定義を含む集計テーブルを作成し、他のドキュメントに埋め込みます。
現在、情報アーキテクチャの文書化にConfluenceを使用していますが、ユビキタス言語の定義はその一部です。このドキュメントの最高レベルは、ドメインの記事です。すべてのアプリケーションには、セキュリティ、支払いなどの複数のドメインがあります。これらのドメインは、ユビキタス言語を介して記述できるシステムとユーザーの相互作用の数によって定義されます。インタラクションページのサブページでこれらのインタラクションによって導入された用語の一覧。親ページに集計テーブルを配置して、たとえば、どのシナリオがドメインで構成され、どの用語がそのドメインで定義されているかを確認できるようにします。
このドキュメント構造が完了し、より詳細なシステム仕様に進むと、シナリオのIAおよびUL定義を参照できます。たとえば、「コンポーネントAはシステムBとの統合を実装して、相互作用C(IAシナリオリンク) Z(ULリンク)」。