財務会計システムにおけるアプリケーションの自動生成に関する研究
M2013SE007 村上 晃輝
指導教員：野呂 昌満

1

はじめに

2

SOA に基づくアプリケーション開発におけるアプリケーションフレームワーク

アーキテクチャに基づくソフトウェア開発において，アプリケーションフレームワークを利用した開発が一般的
アプリケーションフレームワークとは，オブジェクト指である．ドメインを限定した際，アーキテクチャ上には不 向に基づいたアプリケーションの再利用技術である．開変部分と変動部分が存在する．アプリケーションフレー 発者はホットスポットと呼ばれるアプリケーション固有
ムワークには，アーキテクチャ上の不変部分と変動部分 の部分のみを作成することで，アプリケーションを完成に対応する箇所があり，それぞれフローズンスポットと させることができる．
ホットスポットと呼ばれている．フローズンスポットは，SOA に基づくアプリケーション開発におけるアプリケーさらに 2 種類に分類される．1 つ目は対象ドメインのアプ ションフレームワークの例を図 1 に示す．各 Abstract クリケーション全てに共通する部分で，本研究では完全フ ラスは対象ドメイン固有の部分であるので，完全フローローズンスポットと呼ぶ．2 つ目は仕様上の共通部分で， ズンスポットである．各 Concrete クラスは，実現レベル実現レベルでは対象ドメインのアプリケーションごとに では異なるが仕様上はこの構造は不変なので，自動生成異なる部分だが抽象化した対象ドメインのアプリケーショ 可能フローズンスポットである．ConcreteAction クラスンの共通部分である．本研究ではこの部分をコード自動生 のメソッド内の Action 記述は，ビジネスロジックを実現成可能フローズンスポットと呼ぶ．本研究では，Service する箇所でありアプリケーションごとに異なる部分なのOriented Architecture(以下，SOA) に基づくアプリケー で，ホットスポットである．
ション開発を前提としており，ビジネスロジックを実現している Action 記述がホットスポットとなる．
アプリケーションの完全自動生成を目標とした場合，ビジネスロジックのコード自動生成は一般的には困難とされている．その理由としては，ホットスポットはアプリケーションごとに異なることからコード自動生成の手法が一般化されていないということが挙げられる．
本研究の目的は，ホットスポットであるビジネスロジックの標準化によるコード自動生成の支援である．ビジネスロジックを組み立てる基準を提案してそれぞれを部品化することで，定型コードとの対応付けが可能となり，コード自動生成の支援に繋がる．
本研究で取り扱う問題点の解決策として，ロジックパ 図 1 SOA に基づくアプリケーション開発におけるアプターンを提案する．ロジックパターンは，頻出するロジッ リケーションフレームワーククをパターンとして定義したものである．パターンを用いてロジックを表現することにより，ビジネスロジック 3 財務会計処理のロジックパターンの定義の標準化を行なうことができると考える．
3.1 ロジックパターンの定義
ロジックパターンの抽出は，アプリケーションドメイ
本研究ではロジックパターンを「成功事例のロジックをンを財務会計システムに限定して行なう．ドメインを限集めて共通部分を抽象化して名前を与えた解法」と定義定することで，抽象度の低いロジックパターンを定義することができ，具体的なロジックのコード自動生成が可 する．ここで言う「共通部分」は，特定のデータを対象「解法」は，特能となる．財務会計処理は簡潔な処理が多いことからロ とした処理の流れや処理の順序が相当し，定のロジックを組み立てたいという状況において用いらジックパターンを抽出しやすいと考え，本研究では対象ドメインを財務会計システムに限定する．ロジックパター れる方法である．ロジックパターンの記述テンプレート
ンは，既存システムのコードの分析により抽出する．抽 [3] は，名前・状況・解決・フォース・アルゴリズム (表現出されたロジックパターンを抽象化し，デザインパター 方法) とする．ロジックパターンを表現する方法として，
ン [1] を適用する．デザインパターンを適用することで関 Unified Modeling Language(以下，UML) で定義されて心事を分離することができ，ロジックの部品化が可能と いるアクティビティ図を採用する．アクティビティ図はなる．事例検証として既存システムの分析を行ない，ロ UML の中で振舞いを表す図であり，ロジックを表すのに最適な図である．シーケンス図とは異なり通信相手のオジックパターンの適用可能性の分析を行なう．
ブジェクト生成を明記する必要がないので，より粒度の高いレベルでロジックを取り扱うことができる．ロジッ
クパターンは，処理内容や処理データという付加情報を与えて具体化することによりビジネスロジックとなる．

3.2

表 1 事務処理ロジックまとめ
ロジック名

項目

説明

DBQuery

概要事前条件DB にアクセスする
特定の目的を持って DB へアクセスしようとしている
特定の目的を達成し，DB へのアクセスが完了している対象データを DB へ登録する対象データが DB に存在しない
対象データが DB に存在する
DB に存在する対象を更新する
対象データが DB に存在する対象データが書き換えられる

アプリケーションドメインの限定

ホットスポットのコード自動生成の支援を行なうためには，アプリケーションドメインを限定する必要がある．
事後条件
アプリケーションドメインを限定せずにロジックパター
概要ンを定義すると，抽象度の高いロジックパターンとなっ
DB 登録 Query 事前条件てしまう．抽象度が高いということは，どのような場面事後条件でも適用できる反面，詳細なロジックを扱うことができ概要なくなってしまう．出来る限り多くのビジネスロジック
DB 更新 Query 事前条件
事後条件
コードを取り扱う必要があるので，アプリケーションドメインを限定してロジックパターンを定義する．
本研究では，アプリケーションドメインを財務会計システップを実行する．最後に，生成された対象データをステムに限定してロジックパターンの定義を行なう．財DB に登録する処理ステップを実行する．また，ロジック務会計処理は簡潔な処理が多いことからロジックパターというアクティビティは，開発者が独自に記述する処理ンを抽出しやすいと考え，本研究では対象ドメインを財ステップであり，ロジックパターンのホットスポットで務会計システムに限定する．本研究では Case Study の一ある．本研究では，これを事務処理の DB 登録 Query の例としてアプリケーションドメインを財務会計システムロジックパターンと定義する．に限定する．本研究で実施した手順でロジックパターンを定義することで，他のアプリケーションドメインにおけるホットスポットのコード自動生成も可能になると考える．

3.3

事務処理のロジックパターンの定義

第 3.1 節の定義に基づき，本節では事務処理のロジックパターンについて定義する．このステップは，ビジネスロジックを自動生成するためのキーとなるロジックパターンをボトムアップにより定義するステップである．現行
システムを分析し，定型コードを抽出する．抽出結果を記述テンプレートに従って記述し，事務処理のロジックパターンの定義を行なう．財務会計処理より抽象度の高い事務処理を先に対象とすることで，いきなり財務会計処理を対象とするよりもロジックパターンの共通部分を抽出しやすいと考える．
現行システムを分析した結果，事務処理のロジックは3 種類に分類できることがわかった．データベース (以下，DB) への Query を行なうロジック，DB へデータを登録する Query を行なうロジック，DB にあるデータを更新する
図 2 事務処理のロジックパターン (DB 登録 Query)
Query を行なうロジックの 3 種類である．事務処理ロジッ
クの詳細を表 1 に示す．DBQuery は，DB 登録 Query と
3.4 財務会計処理のロジックパターンの定義
DB 更新 Query の抽象化したロジックである．
抽出した事務処理のロジックをアクティビティ図で表
本節では，図 2 の事務処理のロジックパターンを基に，現する．DB 登録 Query をアクティビティ図で表現した 財務会計処理のロジックパターンを定義する．事務処理
結果を図 2 に示す．以下では，DB 登録 Query を対象と のロジックパターンに財務会計特有の処理を付加するこしてロジックパターンの定義を行なう．DB 更新 Query とにより，財務会計処理のロジックパターンの定義を行と DBQuery のロジックパターンに関しては，紙面の都 なう．現行システムの分析の結果，財務会計システムの合上，省略する．
主な処理は，申請・承認・変更・取消・転送・確認の 6 種
DB 登録 Query は主に 4 つのステップで構成される． 類であることがわかった．これらの処理に着目してロジッ
メタデータの取得とは，DB に登録するデータのメタデー クパターンの定義を行なう． 申請は，事務処理の登録タを取得する処理ステップである．DB に登録するデータ の具象化された処理である．承認・変更・取消 / 削除・が必要とするメタデータの数だけメタデータ取得という 確認は，事務処理の更新の具象化された処理である．確
処理ステップを重ね，登録対象のデータを生成する処理 認は，事務処理の DBQuery(DB アクセス) の具象化された処理である．以上のことから，各財務会計処理に当て 3.5 ロジックパターンに対するデザインパターンの適用
はまる事務処理のロジックパターンを具象化することで， 本研究で定義したデータ申請ロジックパターンに適用
財務会計処理のロジックパターンの定義を行なう．
可能なデザインパターンの一部を表 3 に示す．各デザイ
財務会計処理の 申請に関するロジックパターンを図 3 ンパターンが表現するロジックと，ロジックパターンのに示す．事務処理の DB 登録 Query パターンに基づき， 一部が表現するロジックが一致する場合，適用可能だと再び現行システム分析することで，申請のロジックパター 考える．
ンを定義した．事務処理のロジックパターンと異なる部
分は，実行処理の登録が申請になった点，申請が実行さ表 3 データ申請ロジックパターンに適用可能なデザインれる前に，実行処理を確認する点である．大まかな処理
パターンの流れは事務処理の DB 登録 Query パターンと変わらない．本研究では，図 3 を「データ申請」ロジックパターン
分類
パターン名ロジックと定義する．記述テンプレートに従って定義したロジッ
生成
Abstract Factory 種類や部品の数が固定のオブジェクト
クパターンを表 2 に示す．の生成
Factory Method
構造Composite

振舞い

CommandMemento
Visitor

サブクラスを用いたインスタンスの生成
木構造のオブジェクトの利用 (処理実行)
要求に見合った処理
オブジェクトのスナップショットの保存，再利用オペレーション委託によるオペレーシ
ョンの実行

データ申請ロジックパターンにデザインパターンを適用した結果を図 4 に示す．図 4 では，Command パターンと Memento パターンの適用を行なった．Command パ
ターン適用により分離されるロジックは，要求に応じた処理で，図 4 では「対象データ申請」と「申請取消の対象データの設定 (申請データの取消)」である．Memento パ
ターンにより分離できるロジックは，「memento の生成」と「memento の取得」である．それぞれの分離できるロジックはビジネスロジックから分離されたので，ビジネスロジックに依存せずに変更することができる．
図 3 財務会計処理のロジックパターン (データ申請)

表 2 財務会計処理のロジックパターン (データ申請)
名前状況

解決

フォース

アルゴリズム

データ申請
指定データの申請を行なうロジックを組み立てたい
申請の取消を考慮したロジックとしたい
柔軟に変更可能な Action コードを作りたい
指定データのメタデータを取得し，指定データを生成，申請を行なう
適用デザインパターンを選択し，主要ロジックから特定の関心事を分離申請というロジックは各アプリケーションに依存しており，同一の Action クラスにて申請を行なうと，申請処理自体の変更が困難となる申請の取消をする際，復元する情報を Action クラスで設定してしまうと，復元したい情報が固定となってしまう．
申請対象データのメタデータ取得を Action クラスで行なうと，メタデータの取得方法を変更したい場
合は Action コード自体を変更しなければならなくなってしまう
図 3 参照図 4 データ申請ロジックパターンに対するデザインパターンの適用

事例検証

財務会計システムに限定したときに本研究で定義したロジックパターンはビジネスロジックの 50%程度の適用可
本章では，定義したロジックパターンの適用可能性に能性を秘めていることがわかった．また，ロジックパターついて検証する．現行システムに対してロジックパター
ンはビジネスロジックのコード自動生成の手がかりになンを適用し，ロジックパターンの適用可能性を分析する．
るということがわかった．今後の課題として，今回対象現行システムのビジネスロジックを担うコードに注目し，とした既存システム以外の財務会計システムを対象としコードをアクティビティ図で表現した際にロジックパターてロジックを抽出し，本研究で定義したロジックパターンが網羅可能なコード数について分析した．分析結果のンを洗練する必要がある．
一部を表 4 に示す．ここで言う適用可能性とは，「パターンの適用可能行数」を「ロジック部分のコードの行数」で 5.3 ビジネスロジックのコード自動生成に関する考察割った値の小数点第二位を四捨五入したものである．
本研究では，ビジネスロジックのコード自動生成の手がかりとなるロジックパターンの定義を行なった．デザ
表 4 ロジックパターンの適用可能性に関する検証
インパターンを適用することで，ロジックパターンの構成要素と定型コードとの対応付けが可能となり，ロジッ
ロジック
ファイル名
ロジック部分の パターンの適 適用可能
クパターンからコード自動生成が可能であるということ
パターン
コードの行数用可能行数性 (%)
がわかった．ロジックパターンを用いてコード自動生成
振替伝票申請158
115
72.8
データ申支払伝票申請
260
161
61.9を実現することで，本来の目的であるアプリケーション請の完全自動生成が達成できると考える．
小目的科目申請
10973
67.0
ロジックパターンを用いたコード自動生成を実現する
振替伝票承認82
5465.9
伝票承認
956063.2には，以下の項目を明確にする必要がある．これらの項
データ更目的予算一括承認
338
53
15.6
目は，本研究の今後の課題となる．
新4

単位間振替更新
予算補正
小目的科目承認解除
管理階層更新

77
105
83
156

7155
38
32

92.2
52.4
45.8
20.5

• 各アクティビティ・制御フローとデザインパターンの定型コードとの関連付け• コード自動生成ツールに対して必要となる入力– 適用ロジックパターン

5考察

5.1

ロジックパターンに対するデザインパターンの適用に関する考察

第 3.5 節で一般的な技術であるデザインパターン適用により，ロジックパターンの関心事を分離することができた．生成，振舞いに関するパターンを適用する場合，分離された関心事とデザインパターンの定型コードとの対応付けが可能となる．また，主要のロジックから関心事を分離できる．以上のことから，新たなアクティビティを部品として作成し，ロジックパターンに対して付け替えが可能となる．
本研究では全てのデザインパターンの適用をしていない．よって今後の課題として，適用可能な全てのデザインパターンを適用する必要がある．また，適用可能なデザインパターンを組み換え可能にしてロジックパターンを洗練することで，より柔軟なロジックパターンとする必要がある．

5.2

ロジックパターンの適用可能性に関する考察

第 4 章での検証の結果，本研究で定義したロジックパターンは現行システムのビジネスロジックコードの 50%程度適用可能ということがわかった．適用可能性の値が明らかに低いものがあるが，これはビジネスロジックに SQLに関するロジックが含まれていたからである．他のロジッ
クでは，SQL に関するロジックはモデル内のメソッドに記述されている．このことから，本研究で定義したロジックパターンは SQL に関して考慮されていないことがわかった．以上のことから，アプリケーションドメインを– 適用デザインパターン

6おわりに本研究では，ロジックパターンを定義することにより，アプリケーションの完全自動生成の支援を試みた．既存システムからロジックパターンを抽出してデザインパターンを適用することで，ロジックパターンにおける関心事を分離することができた．既存システムに対してロジックパターンを適用することにより，ロジックパターンの適用可能性について分析した．本研究の成果として，本研究で定義したロジックパターンがビジネスロジックのコード自動生成の手がかりとなることがわかった．今後の課題として，ロジックパターンの可変部分を分析し，定型コードとの対応関係を明確化することでビジネスロジックのコード自動生成を可能にすることが挙げられる．

参考文献[1] E. Gamma, J. Vlissides, R. Helm, and R. Johnson, Design Patterns: Elements of Reusable ObjectOriented Software, Addison-Wesley, 1995.
[2] 岡村美和，菊島靖弘，青山幹雄， 業務プロセスのパターン化による大規模業務システム開発の効率化とその評価， ソフトウェア・エンジニアリングシンポジ
ウム 2014 論文集，pp.9-14，2014．
[3] 鷲崎弘宜，丸山勝久，山本里枝子，久保淳人，ソフト
ウェアパターン， 近代科学社，2007．