今回はCozyモデル駆動開発で作成する成果物の管理方法について考えてみます。
ファイル構成
図はCozyモデル駆動開発におけるプロジェクトのファイル構成の案です。
プログラムはScalaによる記述を想定しているのでsbtのファイル構成を踏襲しています。
srcディレクトリの配下に以下のディレクトリを配置します。
- main
- メインのソースコード
- test
- テストのソースコード
さらにmain配下に以下のディレクトリ配置します。
- cozy
- Cozyモデル
- scala
- Scalaプログラム
以下でそれぞれの内容について説明します。
Cozyモデル
src/main/cozyディレクトリにCozyモデルを格納します。
Cozyでは、Cozyモデルと後述のScalaモデルの両方のコンテンツの情報を統合してプロジェクトのCozyモデルを作成します。
CozyモデルはScalaモデルで記述しきれない仕様をCozy形式で記述します。
cozyディレクトリには以下のディレクトリを配置します。それぞれのディレクトリが対応するモデルを格納します。
- business : ビジネス・モデル
- requirement : 要求モデル
- analysis : 分析モデル
- design : 設計モデル
ビジネス・モデル
businessディレクトリにはビジネス・モデルを格納します。
ソフトウェア開発におけるビジネス・モデルでは、開発するソフトウェアのビジネス上の位置づけや用途などのビジネス文脈を記述します。
ビジネス・システムを駆動するビジネス・モデルを作成し、これをソフトウェア開発の入力にするのが理想ですが、そのような本格的なアプローチが取れない場合はソフトウェア開発に必要な範囲でビジネス文脈を整理するのがよいでしょう。
前回はEssenseのアルファとしてビジネス・システム・アルファとして定義しました。
記述するモデルの候補としては以下のものが考えられます。
- ビジョン
- ゴール
- ビジネス・コンテキスト
- ビジネス・ユースケース
- ドメイン・モデル
また、ビジネスの計測と結果のフィードバック・ループに対応するため以下のモデルについても扱っていく予定です。
- KGI(Key Goal Indicator)
- KPI(Key Performance Indicator)
モデルは基本的には通常ファイルに自然言語のテキストとして記述する形になりますが、コンテキスト・モデルは図として記述するのが適切なので、これをどのように記述するのかは工夫が必要そうです。
要求
requirementディレクトリには要求モデルを格納します。
記述するモデルの候補としては以下のものが考えられます。
- ビジョン
- ゴール
- コンテキスト・モデル
- ユースケース
ビジョン、ゴール、コンテキスト・モデル、ユースケースはビジネス・モデルと同じ項目ですが、開発対象となるソフトウェア・システムのビジョン、ゴール、コンテキスト・モデル、ユースケースという点が異なります。
またビジネス・モデルで定義したKGIやKPIも、必要に応じて要求モデルに引き継がれるでしょう。
モデルの記述方法はビジネス・モデルと同様に通常ファイルに自然言語で記述するものが中心となります。
分析
analysisディレクトリには分析モデルを格納します。
作業分野「分析」と「設計」はEssense標準ではShape the Systemアクティビティ空間に所属するアクティビティということになるでしょう。
分析はPIM(Platform Independent Model)を、設計はPSM(Platform Specific Model)を記述するというモデルの抽象度に違いがあります。
しかし、実装主導の開発では開発ではPIMを意識しつつPSM主体の設計になると思うので、実務的には要求から直接設計に進み、必要に応じて分析も行う、というところが実際のところかもしれません。この点も加味して分析について検討していく予定です。
設計
designディレクトリには設計モデルを格納します。
設計モデルでは、実装に直結したモデルを構築します。
設計モデルを考える上で重要なのはプログラム自身が設計になっているといる点です。特にオブジェクト指向プログラミングで記述した場合には、オブジェクト・モデルとのインピーダンス・ミスマッチが低いので、場合によってはそのままモデルと考えてもよいかもしれません。
しかし、プログラミングの場合はプログラム動作上のさまざまな処理を追加していくため、抽象的なモデルとずれてきたり、境界が曖昧になってきます。この問題に対応するためアノテーションの仕組みを使ってモデルとして扱う箇所とモデルとして位置づけを記述していくことになるでしょう。また、JavaやScalaではプログラム内に仕様を自然言語で記述する仕組みがあるので、これを用いてより詳細にモデルの情報を記述することができます。
すべてのモデルをアノテーション付きプログラムで記述することはできないので、この記述できない部分は別の形でモデルを記述することになります。
一つはドメイン・モデルなど定型化して形式で記述したモデルです。
このモデルからはインタープリタで直接実行したり、実装を自動生成することができます。
最後にアーキテクチャ全体の情報やコンポーネントやクラスなどの仕様に関して自然言語による記述を行う場合があります。このような記述は通常ファイルに記述した上でプログラム・モデルと統合して設計モデルを組み上げていくことになるでしょう。
Scalaプログラム
本シリーズではプログラミング言語にScalaを用います。
Scalaプログラムとして開発するソフトウェアの本体のプログラムとテスト・プログラムを作成します。
本体
開発ターゲットの本体のScalaプログラムはsrc/main/scalaディレクトリに格納します。
前述したようにScalaプログラムにアノテーションとScaladocを併用することで、モデルとして扱うことができます。
プログラミング言語としてScalaを使用するので、Scaladoc形式でインタフェース仕様を記述します。
Cozyは、モデル、プログラム、テスト・ケースからそれぞれに記述された仕様を集め、マージしたものをプロジェクトの仕様として統合します。
テスト
Scalaによるテスト・プログラムはsrc/test/scalaディレクトリに格納します。
Cozyモデル駆動開発ではTDD(Test-Driven Development)、BDD(Behavior-Driven Development)でテストを動く仕様(executable specification)として扱っていきます。
これはテストを要求仕様、コンポーネント仕様として作成して活用していくという意図があります。
この場合は、自然言語で記述した要求モデルとどのように連携していくのかがポイントとなるでしょう。
TDD, BDDの基盤としてscalatestを使用する想定です。
まとめ
今回はCozyモデル駆動開発で作成する成果物の管理方法について考えてみました。
次回はビジネス・モデルについて具体的に考えていく予定です。
投稿
