第0回　モデルベースソフトウェア　開発コミュニティキックオフ「UMLモデルを使った自動生成」アクティア代表取締役社長　大島則人氏

UMLモデルを使った自動生成 from Norihito Ohshima

2003年頃、Executable UMLと出会った。「動かないモデルはただのスケッチ」。OMG MDA ガイドラインver1.0）
動かないモデルを書いても効率が悪いだろう、がきっかけ。目的としては、動くモデルを作りたい。
モデル→Transformation→コード。モデルを変換することでコード生成する。（＝動くモデル。）動くモデル≒コード生成。
ただクラス図からget、setを書くだけでは嬉しくない。UMLでモデリングしたものをコード生成、ではなく、自動生成するためのモデルをUMLで作る。どういうプラットフォームでどういうモデルを書き、どう生成すると動くのか、を考えることでモデルを動かすことができる。考え方を変えないと動くモデルにならない。
まずは静的構造をモデリングする。クラスモデルに役割（stereotype）をつける。DB entity、Serviceなど。役割ごとにテンプレート（生成されるもの）を切り替える。役割は、標識がないと決められない。Domain Driven Design。設計の方法論が必要。
DDDの主なクラス分類：Entity（永続化されるドメインオブジェクト）、Value Object（ドメインの値）、Service（複数のドメイン操作）、Repository（英奥化装置とドメインの境界）。
Value Objectは、単なる文字列ではなく、「氏名という型」などとして記載していく。String　指名、date　申請日、categoly　申請状態、など。Service、Repositoryは、アプリケーションレイヤの設計。クラスの目的、テンプレートを判断し、生成していく。ステレオタイプをうまく使い、役割をどんどん与えていく。

振る舞い（操作）のモデリング：シーケンス図、コミュニケーションズで最終コードを作れない（保守したくない）。抽象的なところに作っていき、操作に直接コードを埋めていく方法でモデリングする。操作にコードっぽいものを作ってコード生成し、流用する。設計者がわかりやすいDSL（Domain Specification Language）。
たとえば、操作の中にコメントを作り、社員レポジトリ.findAll()などと具体的に書く。findAllは定義していないがあるものとして使っていく、などで設計の手間を減らす。ほかにも導出属性も。（合計旅費の計算を埋め込むなど。）ステレオタイプではタグ付き値で対応付ける。ステレオタイプでメソッド、URLで対応付けを埋め込む。実際に稼働させるとURLでGETリクエストでデータベースを呼び出し……ができる。

デモ：Bandicam（www.gomplayer.jp）　Magic Drowを使ってUMLを書いている。XMLのテキストモデルに変換し、XMLからコードに変換する。Maven使ってビルドかけて解釈してソースコード生成。warファイルが作られ、tomcatのディレクトリに直接おいて実行させる。Eclipse、Javasソースコードを必要としない。データベースは生成時に作られ、シミュレーションに使われる。Advanced REST。。（GoogleChrome）を使う。RESTインタフェースはJSONでポスト。