2011年11月21日月曜日

「崖っぷちの欧州、ローマの炎上を許すな」のマインドマップとクラス図

11月19日(土)に横浜モデリング勉強会を行いました。
参加者6名で、懇親会も盛り上がりました。
また、会場には(株)アットウェア様の会議室をお借りしました。
参加された皆さん、アットウェア様、どうもありがとうございました。

この勉強会で、浅海が作成したモデルを紹介します。
モデルはMindmapModelingの手法で作成しました。(勉強会で使用したチュートリアル)

モデリングの対象は、JB PRESS誌に掲載されたMartin Wolf氏の記事(FT誌の翻訳)「崖っぷちの欧州、ローマの炎上を許すな」です。前回と同様に、時事ネタなのと、いろいろな情報が交錯していて、一見焦点が絞れないところが、モデリングの練習によい感じです。
この記事における現実世界の構造をオブジェクトモデルとして抽出します。

まず、最初の作業で記事中から単語を抜き出します。
単語を抜き出しながら、登場人物、道具、出来事を中心にMindmapModelingの定めた分類に従って仕分けしていきます。
この結果、できた最初のマインドマップが以下のものです。(図をクリックすると拡大します。)


次の段階では、抽出した、登場人物、道具、出来事の洗練を行います。
用語の名寄せ、用語の種類(generalization)や部品構成(aggregation)を整理していきます。
また、この段階で区分(powertype)の抽出を開始します。
以上の作業を行った結果のマインドマップは以下のものです。



このマインドマップをSimpleModelerでクラス図に変換すると以下のものになります。「国」を中心に、ある程度構造化ができていますが、まだまだ中に浮いたクラスがあることが分かります。


次の段階では、対象となる世界の動的な側面を捉える出来事や物語を整理していきます。
出来事や物語を洗練していくことによって、出来事や物語における登場人物や道具の役割が明確化され、より登場人物や道具の構造をさらに洗練させることができます。
出来事や物語で抽出した役割は、役割(role)としてモデル化して「役割」構造枝に配置し、役割の持つ構造を洗練していきます。

今回は、EUの「中心にいる国々」(事実上、ドイツですが)が主役の物語「欧州連合を救う」と、ギリシャやイタリアなど「支援を受ける側」が主役の物語「経済破綻を回避する」の2つの物語を軸にモデルを整理していきました。

今回のモデルでもう一点ポイントになるのがドメイン・ルール(Domain Rule)、制約条件です。
記事からは「緊縮財政政策 ⇒ 内需が弱くなる」、
「景気が回復しない ⇒ 投資家の信頼感を取り戻す可能性は低い」、
「構造改革 ⇒ 労働市場に影響を及ぼす」、
「労働市場に悪影響 ⇒ 社会的・政治的な混乱」、
「社会的・政治的な混乱 ⇒ 投資家の信頼感は揺らぐ」、
「競争力が回復する ⇒ 人員解雇と名目賃金下落をもたらす」、
「人員解雇と名目賃金下落 ⇒ 失業と社会不安、債権者の不安感」といったルールが抽出できます。

救う側であるEUの「中心にいる国々」も、「支援を受ける側」もこれらの制約条項の上で、金融政策、財政政策、労働政策などを立案、遂行していく必要があります。この記事の場合、こういった制約群で合成される非常に厳しい全体制約が物語の遂行をほぼ実現不可能にしているという絶望感が記事の重要なテーマと考えられます。
逆に、針の穴を通すほどの小さいストライクゾーンとなる、実現可能な組合せは何かというのが、テーマとしてあぶり出されてくるわけですね。
この「実現可能な制約条件の組合せ」の抽出は、システムを実現する上での重要なモデル要素なので、MindmapModelingでもモデルを記述することができるようになっています。これが、BOI構造枝「規則」(Domain Rule)というわけです。

MindmapModelingではBOI構造枝「規則」に記述するDomain Ruleの命名法や構造などは特に定めていません。現状では、OCLのような非常に限定した形でしか、制約を記述して実装に落し込む手法が一般的になっていないからです。
(ルールエンジンなどの商用ミドルウェアやJSR 94 Java Rule Engine APIなどは存在していて一部では活用されていると思いますが)

ただ、最近は関数型言語が実装言語として視野に入ってきたので、このあたりとの接続を念頭において、「規則」の記述方法について文法の拡張を行うことを考えています。
今回は、論理結合子「⇒」(ならば, conditional, material implication)を使ってみました。最終的には、実装の自動生成時に関数型言語が扱える論理式を自動生成するのが目標です。

とはいえ、「緊縮財政政策 ⇒ 内需が弱くなる」という論理式は「緊縮財政政策」ならば必ず「内需が弱くなる」ということですが、現実には100%ということはないので、現実世界のモデリングには使いづらい面があります。参考情報に留めるのか、様相論理の可能性演算子(◇, possibility operator)といったものを導入するか、色々と考えてみたいところです。

以上の作業の結果、作成したマインドマップが以下のものです。


このマインドマップをSimpleModelerでクラス図に変換したものが以下の図です。


以上のマインドマップとクラス図が勉強会で作成したものです。

クラス図にしてみると、名寄の甘いところや、モデル要素のステレオタイプの選択などで問題があることが分かります。
そこで、SimpleModelerでのクラス図生成を繰り返しながら洗練したマインドマップと、このマインドマップからSimpleModelerを使って生成したクラス図は以下のものです。



記事における現実世界の構造がそれなりに上手くとらえられていると思います。

このように記事を詳細にモデル化すると、記事の内容がより深く理解できますね。

「支援を受ける側」が取り得る方法は、制約条件の組合せからほぼ:
  • 緊縮財政、構造改革する。
  • 緊縮財政、構造改革による内需の縮小は、外需の取り込みでカバーする。
  • 緊縮財政、構造改革による社会の不安定化により、投資家が投資を引き上げないために不安感を払拭する対策を行う。
しかないことが分かります。

EU圏外の国から外需の取り込みを行うことも、社会の不安定化を払拭する施策も、相当難しそうですが、このあたりが今後のEUの動向を見定めるポイントかもしれません。

緊縮財政、構造改革を行う国が唯一取れる成長戦略が外需の取り込みである以上、自国通貨の切り下げ、相手国関税、非関税障壁の撤廃が最重要戦略となるわけで、(EUは入れてもらえませんが)最近TPPが政治的なイシューになっている背景がなんとなく見えてきますね。(記事の内容からの推論なので、感想の妥当性は無保証ですw)

2011年11月19日土曜日

横浜モデリング勉強会 (第2回)

今日(11/19)のモデリング勉強会の情報です。

http://atnd.org/events/21756

今回モデリングするのは以下のWeb記事です。

テーマ:  崖っぷちの欧州、ローマの炎上を許すな

モデリングは記事の問題領域であるドメインモデルを作成を目標にします。
  • 問題領域の構造を、エンジニアでない人が理解できるで構築している。
  • プログラムに落し込むことができる。
モデリングは各自のお好きなモデリング手法で行います。
一時間に一度程度、作成途中のモデルを見ながら議論します。
初学者の方は、MindmapModelingをお勧めします。

2011年10月31日月曜日

「TPP議論の本質はこれだ!」のマインドマップとクラス図

10月29日(土)に横浜モデリング勉強会を行いました。
札幌サテライトから2名参加があり合計6名の参加でした。
参加された皆さん、どうもありがとうございました。

この勉強会で、浅海が作成したモデルを紹介します。
モデルはMindmapModelingの手法で作成しました。(勉強会で使用したチュートリアル)

モデリングの対象は、田原総一朗氏のブログ記事「TPP議論の本質はこれだ!」です。時事ネタなのと、いろいろな情報が交錯していて、掴みどころがないのが、モデリングの練習によい感じです。
この記事における現実世界の構造をオブジェクトモデルとして抽出するという趣旨です。

まず、最初の作業で記事中から単語を抜き出します。
単語を抜き出しながら、登場人物、道具、出来事を中心にMindmapModelingの定めた分類に従って仕分けしていきます。
この結果、できた最初のマインドマップが以下のものです。(図をクリックすると拡大します。)


次の段階では、抽出した、登場人物、道具、出来事の洗練を行います。
用語の名寄せ、用語の種類(generalization)や部品構成(aggregation)を整理していきます。
また、この段階で区分(powertype)の抽出を開始します。
以上の作業を行った結果のマインドマップは以下のものです。


次の段階では、対象となる世界の動的な側面を捉える出来事や物語を整理していきます。
出来事や物語を洗練していくことによって、出来事や物語における登場人物や道具の役割が明確化され、より登場人物や道具の構造をさらに洗練させることができます。
出来事や物語で抽出した役割は、役割(role)としてモデル化して「役割」構造枝に配置し、役割の持つ構造を洗練していきます。

以上の作業の結果、作成したマインドマップが以下のものです。


モデリング勉強会での作業はここまででした。
その後、このマインドマップをSimpleModelerでクラス図に変換したものが以下のクラス図です。(クリックすると拡大します。)
クラス図にしてみると、まだまだ抜けているところがあることがよく分かります。
モデルとして欠陥があるわけではなさそうですが、名寄せが甘いところや、時間切れでモデルに記述しきれなかったところが明確になりました。


そこで、SimpleModelerでのクラス図生成を繰り返しながら洗練したマインドマップが以下のものです。


このマインドマップをSimpleModelerを使ってクラス図に変換したものが以下のクラス図です。(クリックすると拡大します。)
記事における現実世界の構造がそれなりに上手くとらえられていると思います。
短い記事ですが、丹念にモデル化していると存外大きな構造が背景にあることが分かります。



物語は記事中で一番重要視していると思われる「アメリカのアジア戦略」を抽出しましたが、時間があれば「アメリカの輸出増加戦略」や「日本のTPP外交戦略」というような物語を加えるとより内容が充実してくると思います。

2011年10月29日土曜日

モデリング勉強会

今日(10/29)のモデリング勉強会の情報です。

http://atnd.org/events/20884

今回モデリングするのは以下のブログ記事です。

テーマ:  TPP議論の本質はこれだ!

モデリングは各自のお好きなモデリング手法で行います。
一時間に一度程度、作成途中のモデルを見ながら議論します。

初学者の方は、MindmapModelingをお勧めします。

クラウド時代のデータアーキテクチャとモデリング

クラウド時代のデータアーキテクチャとモデリングについてちょっと思いついたことがあるのでメモ。



クラウドアプリケーションが従来のアプリケーションと異なる点の一つは、クラウド上に遍在する様々なデータをマッシュアップして使用することになるという点です。
自前で管理するデータだけでなく外部データを編みこんだドメインモデルに対して、アプリケーションが操作を行うことになります。
また、スケーラビリティを確保するため、CQRSのように参照系と更新系をアーキテクチャレベルで分割していく形が基本になるでしょう。
これは、自前データのサイズが巨大になる場合への対応にも有効ですが、外部データとの連携では必須のアーキテクチャです。自前データが巨大にならない普通のアプリケーションでも、外部データとの連携を行うのであれば、このアーキテクチャを採るのが得策です。

ドメインモデル

このアーキテクチャの上でドメインモデルは、以下の3つの種類に分類するのがよいのではないかというのがアイデア。

  • Application Domain
  • Actor Domain
  • Fact Domain
Application Domainは、アプリケーションが操作するドメイン。自前データと外部データをマッシュアップして見せます。
従来のドメインモデルとの違いは、外部データをマッシュアップすること。マッシュアップを行う場合、更新系を含めると実現方法が大変になってくるので、参照系を中心にするとよいでしょう。都合のよいことに参照系と更新系を分離するアーキテクチャにもマッチしています。
従来技術でもRDBMSのViewなどでこういった事が可能ですが、これをもっとアーキテクチャレベルで大掛かりにやるイメージです。(そういう意味ではデータベースの3層スキーマが近しいかも。)

外部データは、Actor Domainとしてモデル化します。Actor Objectは、アプリケーション外にあるオブジェクト(の代理オブジェクト)という意味ですが、このドメインモデル版という意図でActor Domainという名前にしてみました。
Actor Objectの場合、自前のオブジェクトでないので、決められた範囲でお願いはできるけど自由に操作できないという処理上の制約が出てきます。
Actor Domainもそういった制約を持ったドメインモデルをイメージしています。

そして、Actor Domainの外側にFact Domainを持ってきました。
Fact Domainは、クラウド上で発生する無数のイベントの生データをイメージしています。たとえばアプリケーションのログや、データベースのジャーナルなどです。

Actor Domainはアプリケーションの外部で、Fact Domainのデータを集約し、意味を付加したモデルとしてモデルインスタンスが公開されています。

Application Domainは、このAcotr Domainのインスタンスを、自前データとマッシュアップして、アプリケーションに取って意味のあるモデルのインスタンスとして、アプリケーションに提供します。

更新系

更新系には、Application Commandというモジュールを用意しました。(Commandというのは仮です。他によい名前があったら取り替えると思います。)
Application Commandは自前のデータの更新を中心に、Application Domainへの更新依頼、Fact Domainの情報提供を行います。
Application Domainへの更新依頼はあまり多くないという仮定で点線にしてみました。

モデリング技術

こういったデータアーキテクチャを採る場合のモデリング技術として、どうも文書モデリング(SGML, XML系)が有効でないかというのが、データアーキテクチャと同時に思いついたアイデア。
従来アプリケーションでは、データモデル/オブジェクトモデルがモデリングの中心でしたが、ここまで説明してきたようなマッシュアップが基本となるデータアーキテクチャでは、異なったセマンティクスのモデルをマッシュアップする基盤として文書モデリングが重要になってくるのではないかということです。
2000年頃にも、こういう話題がよく出たと思いますが、クラウド時代になって改めて、この技術を適用する形が見えてきた感触です。
ただし、今回はXMLという文脈でなく、関数型という文脈ではないかというのが、今回のアイデアの軸。関数型プログラミングと文書モデリングの相性は相当よさそうです。
XMLはデータ表現形式としてはよいのですが、データ操作体系としてはまだまだ不十分でした。ここを関数型言語ですっきりと記述することが可能になってきたのは一つミッシングリンクが埋まってきた感じです。

オブジェクトモデル、データモデル、文書モデル、関数モデル。
Application Domainのメタモデルとして、4つのモデルをどのように配合していくとよいのか。まだまだノーアイデアですが、未開拓の領域だけに色々と面白そうです。
クラウドも現時点では、プラットフォーム技術やフレームワーク、プログラミング言語といった実装よりの技術に焦点があっていますが、次の段階ではこういったモデリング技術の所に焦点が移ってくるのではないかと考えています。

2011年9月19日月曜日

RESTのFeedを一覧表示するActivityの生成

8月27,28日に開催されたクラウド温泉@小樽のセッション、「クラウドアプリケーション(App Engine&Android)自動生成 - SimpleModeler/g3/g4デモ」でのSimpleModelerからAndroidアプリの自動生成のデモの話の続きです。

SimpleModelerでは、アプリケーション開発のベースとなるドメインモデルの実装を「自動コーディング」します。この部分はドメインモデルが決まれば、プラットフォーム上での実装はほぼ決まるので自動生成の格好のターゲットです。逆に、この部分を手組みでコーディングしていると相当の工数が必要となります。プログラム開発の生産性を上げるためには、この部分の生産性向上が重要になってきます。

ただし、エンティティに対するCRUD処理については自動生成である程度のモノを生成可能です。アプリケーション部分のサンプルという意味もこめて、データに対するCRUD処理を行なうActivityを生成する予定で、一部実現しています。

現在SimpleModelerが自動生成しているのは、サーバー上に格納されているエンティティCustomerをREST経由でアクセスして一覧表示を行うプログラムが以下のCustomerRestViewActivityです。

package com.demo;

import android.content.Context;
import android.os.Bundle;
import java.math.*;
import java.util.*;
import org.goldenport.android.*;
import org.goldenport.android.traits.ListViewTrait;

public class CustomerRestViewActivity extends GActivity<DemoController> {
    
    // @LayoutView(R.id.header)
    // TextView mHeader;
    // @ResourceString(R.string.header)
    // String mHeaderLabel;
    // @ResourceColor(R.color.header)
    // Color mHeaderColor;
    // @IntentExtra("message")
    // String mMessage;
    
    public CustomerRestViewActivity() {
        addTrait(new ListViewTrait());
    }
    
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
    }
    
    @Override
    protected int get_Layout_id() {
        return R.layout.customer_rest_view;
    }
    
    @Override
    protected void onStart() {
        super.onStart();
    //    if (mMessage != null) {
    //        mHeader.setText(mMessage);
    //    } else {
    //        mHeader.setText(mHeaderLabel);
    //    }
        set_list_adapter(gcontroller.getCustomerRestFeedAdapter());
    }
}

GActivity


CustomerRestViewActivityは、サーバー上に格納されているエンティティCustomerをRESTでアクセスしてListViewの一覧として表示するActivityです。基底クラスはGActivityで、型パラメータとしてDemoアプリケーションのコントローラであるDemoControllerを指定しています。

org.goldenport.android.GActivityが、g4におけるActivityの基底クラスです。主に以下の機能を提供しています。

  • DI
  • コントローラクラスの自動バインド
  • トレイトによる機能拡張
  • 非同期更新処理

DI(Dependency Injection)

g4では、Google Guice (without AOP)を用いたDIコンテナ機能を提供しています。XMLで定義された各種ViewやリソースをActivityのインスタンス変数に自動インジェクトすることができます。
自動生成されたCustomerRestViewActivityを、自前で拡張するためのヒントとして以下のコメントが入っています。
この機能は次回の記事で説明することにします。
// @LayoutView(R.id.header)
    // TextView mHeader;
    // @ResourceString(R.string.header)
    // String mHeaderLabel;
    // @ResourceColor(R.color.header)
    // Color mHeaderColor;
    // @IntentExtra("message")
    // String mMessage;

コントローラクラスの自動バインド

g4では、画面表示を行うクラスであるGActivity(Activityのサブクラス)から、アプリケーション・ロジックを分離してコントローラとして実装します。コントローラはGControllerのサブクラスになります。
Activityからアプリケーションロジックを分離して、コントローラ側で実現することにより、以下の効果を期待しています。
  • アプリケーション全体のロジックをコントローラに集中させることで、アプリケーションの見通しを良くし、拡張性、保守性を高める。
  • GUIを経由しないで、アプリケーションロジックのユニットを可能にする。
  • アプリケーションロジックを複数のActivityから共用できる。
GActivityでは、コントローラクラスを自動的にインジェクトするので、GActivityの実装では、特に初期化処理なしでコントローラを参照して使うことができます。 
生成されたonStartメソッドにはヒントのコメントがあります。この不要なコメントを削除したonStartメソッドは以下のものになります。
@Override
    protected void onStart() {
        super.onStart();
        set_list_adapter(gcontroller.getCustomerRestFeedAdapter());
    }
「super.onStart()」はお約束。
set_list_adapterメソッドで、コントローラから返されるListAdapterを設定しています。
GActivityで定義しているインスタンス変数gcontrollerから参照しているコントローラ(DemoController)から、ドメインエンティティCustomerをRESTのフィードとしてアクセスするListAdapterを取得しています。
このListAdapterは、バックエンドにページング付きのREST通信と通信結果のキャッシュ機能を持っています。この機能を実現するために、SimpldeModelerが生成するAndroidコードで説明したとおり、ActivityからRESTドライバにいたるまで相当数のコードが自動生成されています。また、g4ベースでサーバサイドのコードも自動生成していることは、SimpleModeler (クラウド温泉@小樽)で触れました。このあたりのメカニズムはいずれ紹介したいと思います。

トレイトによる機能拡張

ActivityにListViewやGralleryなどを操作するロジックをハードコーディングしてしまうと、ロジックを他の目的に再利用させることができません。
これらの機能を持つ基底クラスを作るのが次善策ですが、拡張性や保守性に問題があります。
この問題を解決するために、g4ではScalaのトレイトライクなメカニズムを導入しました。
ListViewTraitは、ListViewを操作する機能を持つトレイトです。GActivityのaddTraitメソッドによりListViewTraitを追加することによりGActivityにListViewを操作する機能が追加されます。
以下のようにコンストラクタでトレイトListViweTraitを追加しています。
public CustomerRestViewActivity() {
        addTrait(new ListViewTrait());
    }

非同期更新処理

ListViewTraitが内部で自動的にハンドリングしているので、CustomerRestViewActivityには直接みえていません。
ListViewTraitが、一覧データのローディング時にプログレスバーを画面上に表示し、ローディングが完了した時点で表示を終了する処理を行っています。

2011年9月1日木曜日

SimpldeModelerが生成するAndroidコード

8月27,28日に開催されたクラウド温泉@小樽では、「クラウドアプリケーション(App Engine&Android)自動生成?SimpleModeler/g3/g4デモ」のセッションで、SimpleModelerからAndroidアプリの自動生成のデモを行いました。

クラウド温泉@小樽に向けてブログに書いてきたものを実演しました。

デモに使ったモデルは以下のCSV、demo.csvをコンバートして生成したDEACustomer.java、DEEBuy.java、DERGoods.javaの3つのScala DSLで記述したものです。

demo.csv
#actor,parts,attrs
customer,,phone
#resource
goods,,note
#event
buy,customer;goods
そのうちの一つ、DEACustomer.javaのソースコードは以下のものです。DEEBuy.javaとDERGoods.javaもだいたい同じコードになります。

DEACustomer.java
package com.demo

import org.simplemodeling.dsl._
import org.simplemodeling.dsl.datatype._
import org.simplemodeling.dsl.domain._
import org.simplemodeling.dsl.domain.values._

case class DEACustomer extends DomainActor {
  term = "customer"
  caption = "customer"
  brief = <t></t>
  description = <text></text>

  id("customerId", DVICustomerId())
  attribute("name", DVNCustomerName())
  attribute("summary", XString)
  attribute("phone", XString)
}

case class DVICustomerId extends DomainValueId {
  term = "customerId"
  caption = "customerId"
  brief = <t></t>
  description = <text></text>

  attribute("value", XString)
}

case class DVNCustomerName extends DomainValueName {
  term = "customerName"
  caption = "customerName"
  brief = <t></t>
  description = <text></text>

  attribute("value", XString)
}
デモでは、このモデルからg4上で動作するJavaソースコードを生成し、Androidアプリケーションとして動作させました。Javaソースコードの生成は、一部デモに間に合わなかったものもあったので、その後、少し改良しました。その改良版では、以下のソースコード(33ファイル、4.7Kステップ)を生成します。
  • BuyRestFeedAdapter.java
  • BuyRestFeedRepository.java
  • BuyRestViewActivity.java
  • CustomerRestFeedAdapter.java
  • CustomerRestFeedRepository.java
  • CustomerRestViewActivity.java
  • DDBuy.java
  • DDCustomer.java
  • DDGoods.java
  • DEACustomer.java
  • DEEBuy.java
  • DERGoods.java
  • DVIBuyId.java
  • DVICustomerId.java
  • DVIGoodsId.java
  • DVNCustomerName.java
  • DVNGoodsName.java
  • DemoAgent.java
  • DemoApplication.java
  • DemoContext.java
  • DemoContract.java
  • DemoController.java
  • DemoErrorModel.java
  • DemoFactory.java
  • DemoG3Driver.java
  • DemoModel.java
  • DemoModule.java
  • DemoProvider.java
  • DemoRepository.java
  • GoodsRestFeedAdapter.java
  • GoodsRestFeedRepository.java
  • GoodsRestViewActivity.java
  • IDemoRestDriver.java
このJavaプログラムをクラス図にすると以下のようになります。
BuyRestViewActivity, CustomerRestViewActivity, GoodsRestViewActivityがAndroidの画面クラスであるActivity(Androidの画面クラス)です。これらのActivityがサーバー上に格納されているデータを画面に表示します。
これらのActivityからDemoControllerを経由して、ドメインモデルを管理するクラスDemoModelにアクセスします。データの管理は、サーバーから取得したフィードデータをメモリ上に保持するクラスBuyRestFeedRepository, CustomerRestFeedRepository, GoodsRestFeedRepositoryで行い、これらのクラスをAndroidのウィジェットであるListView用のアダプタBuyRestFeedAdapter, CustomerRestFeedAdapter, GoodsRestFeedAdapterが使用します。
また、サーバーとの通信はDemoG3Driverが行います。今回のデモではサーバー側はg3なので、g3と通信するためのドライバを使用していますが、ドライバはインタフェースIDemoRestDriverを実装していれば取り替え可能な構造になっています。
クラス図の下に、Documentオブジェクト(DTO)であるDDCustomer, DDBuy, DDGoodsがありますが、これらのオブジェクトでデータのやりとりを行います。
クラス図のざっくりとした説明は以上の通りです。追々詳細な情報を書いていく予定です。
ここで強調したいのは、(トイプログラムではなくて)ある程度本格的なアプリケーションを作成する場合、ごく小さなドメインモデルからでも、これらのクラス群を作成しなければならないということです。一般的なJavaプログラムでも必要なものもありますし、Android特有のクラスもありますが、いずれにしても相当量のコーディングが必要になります。しかも、これらのクラス群はドメインモデルが決まれば、Android上でどう実装するのかというのも、ほとんど決まってしまうので、人力でコーディングするのは、かなりもったいない作業です。こういった定型部分を自動コーディングしてしまうことがSimpleModelerの目的です。