[OFAD]Everforthのモデル体系

前回「クラウド・サービスのモデリング」で、クラウド・サービスを開発する際のモデリングの枠組みについて考えました。

クラウド・サービスの開発はSPaaS(Service Platform as-a-Service), OFP(Object-Functional Programming), OFAD(Object-Functional Analysis and Design)の3つの要素から構成されるという枠組みを提示しました。

今回は、この枠組の中のOFADを実現するためにEverforthが採用しているモデル体系についてご紹介します。

モデリングの参照モデル

クラウド・サービスのモデリングを議論するための参照モデルとして以下のものを使用します。

この参照モデルでは、モデルは大きく以下の2系統に分かれます。

• ドメイン・モデル
• アプリケーション・モデル

ドメイン・モデルは、利用者やサービス提供者、開発者といったステークホルダー間で共有する事業ドメインのモデルです。最上流では用語集にまとめられたドメイン・オブジェクトが、最終的にはデータベースで管理されたり、センサーなどの外部デバイスとして実現されます。

アプリケーション・モデルは、各ステークホルダーの要件を定義し、ここからサービスとして実現する方法を定義するモデルです。ビジネス・ユースケースからユースケースとして定義した物語を、サービスに落としこみます。

クラウド・サービスの設計と実装

分析と設計のアクティビティによって以下の2つのモデルが作成されます。

• ドメイン・モデル
• サービス・モデル

この2つのモデルから、サービス・プラットフォーム上にクラウド・サービスを構築する際の、設計と実装を行う際の流れを以下にまとめました。

スクラッチのシステム開発の場合には、この2つのモデルからシステム全体を開発するわけですが、サービス・プラットフォーム上でクラウドサービスを開発する場合、サービス・プラットフォームが提供するDSLに載せる形で開発することになります。

ドメイン・モデルについては、業界全体の現時点での技術レベル的に80%程度は自動生成することを前提にするのが合理的です。サービス・プラットフォームを使う場合は、サービス・プラットフォームが提供するDSLに合わせた実装を自動生成することになります。

サービス・モデルはOFPを用いて実装することになります。この場合も、サービス・プラットフォームが提供するDSLに合わせた実装になります。

Everforthでのモデリング

「モデリングの全体像」と「クラウド・サービスの設計と実装」の参照モデルについて説明しました。この参照モデルにそった形でEverforthで採用しているモデリングの枠組みは以下になります。

モデルは大きくサマリ・モデルと詳細モデルの2つに分かれます。

サマリ・モデル

サービス毎にサマリ・モデルとして以下のモデルを作成します。

• マインドマップ・モデル
• WireFrame(WF)
• API利用一覧
• サービス記述

マインドマップ・モデル

マインドマップ・モデルは拙著「マインドマップではじめるモデリング講座」のものをベースにしています。ざっくりいうとマインドマップでビジネス・ユースケースとドメイン・モデルを記述するための手法です。

マインドマップ・モデルで作成したモデルは基本的にOOADのモデルなので、必要に応じて本格的なOOADモデリングに展開可能です。

WireFrame

WireFrame(WF)はWebやiOS/Androidアプリ開発で一般的に使われているものを採用しました。画面設計を中心にしたモデルです。ただし、画面とクラウド・サービスが提供するAPIの関係を定義する拡張を行っています。

API利用一覧

API利用一覧は、WFで定義したものも含めて、WebやiOS/Androidアプリケーションからクラウド・サービスのAPI利用方法一覧です。

サービス記述

サービス記述は、開発するサービスの概要情報を定義したものです。

このサービス・プラットフォームのカスタマイズ情報を定義することがサービス記述の重要な目的の一つになっています。

レギュラー・モデル

またサービスの要件が複雑な場合は、必要に応じてレギュラー・モデルとして以下のモデルを作成します。

• ユースケース・モデル
• ドメイン・モデル

ユースケース・モデルは拙著「上流工程UMLモデリング」で定義したユースケース一覧とユースケース詳細の2つの帳票を用いています。いずれもExcelやGoogleスプレッドシートなどの表計算ソフトで作成します。ユースケース一覧の作成が主で、必要に応じてユースケース詳細を作成するバランスで運用しています。

ドメイン・モデルはモデル・コンパイラEverforthModelerのDSLとして記述します。DSLはemacs-org形式のプレインドキュメントです。EverforthModelerはDSLのモデルから、サービス・プラットフォームが定義するエンティティ管理のDSLを自動生成します。

ユースケース・モデルを作成することで、自然にドメイン・モデルが整備されます。このドメイン・モデルの実装はモデル・コンパイラで自動生成してサービスに組込みます。そして、このドメイン・モデルを操作するサービスをユースケース・モデルをベースにAPI仕様としてまとめOFPによる実装につなげていきます。

まとめ

EverforthでApparel Cloudを開発する際に使用しているモデル体系についてご紹介しました。

実装技術としてはScalaによるOFPを使用していますが、要件定義や分析といった上流工程におけるモデリングの重要性は通常のエンタープライズ開発と変わるところはありません。ベースとなる方法論としてはOOADが引き続き有力です。

ただ、(1)クラウド・サービス・プラットフォームを前提とする、(2)実装技術で関数型成分が重要になる、という2つの要因によってモデリングの具体的な手法には少なからず影響が出てきます。

このいった点も含めて、クラウド・サービスのモデリングの方法論について、実践の経験をベースに今後もブログで検討を進めていきたいと思います。