設計指針 モデリング

設計情報を構成する要素

Wagby EEでは業務アプリケーションの設計情報を「構造」と「振る舞い」という視点で整理します。

構造

静的な事柄を記述したもの。その中核は（データの格納単位である）「モデル」と、モデル間の「関係性」です。

1つのモデルには複数のモデル項目が含まれています。モデル項目は他のモデルと関連するもの、および、式によって導出されるものがあります。

モデルは業務の視点からみた切り口ですが、多くの場合は永続化される必要があります。Wagby EEは永続化のためにリレーショナルデータベースを用いるため、モデル定義は最終的にテーブル定義につながっていきます。

振る舞い

動的な事柄を記述したもの。入力ルールやトランザクション処理（複数のモデルを同時に更新する処理）をはじめ、画面遷移や権限によるアクセス制御などを含みます。

利用者からみた画面操作の使い勝手も、振る舞いとして捉えています。

モデルの性質

「モデル」とはデータを格納する意味上の単位です。モデルはその性質上、図1に示すような区分が可能です。

選択肢

"男性", "女性" といった簡単なものから、業種コードや伝票種別など、さまざまです。業務ルールに基づいてコード設計を行いますが、通常、コード値は（いったん決めると）変更は行いません。コードに対応した内容部（文字列）は変更することもあります。

また、選択肢はその性質上、いったん割り当てたコードを削除することもありません。削除してしまうと、そのコードを参照していた他のすべてのデータに影響が及ぶためです。そのため物理削除ではなく論理削除（データベース上の記録は残すが、アプリケーションからは不可視とする）が用いられます。

マスタ系

「リソース」とも呼びます。システム稼働に際して、事前に登録されている必要のあるデータです。例えば商品マスタや、お得意先マスタがあります。

マスタデータの事前登録では、Excelなどで入力を行ない、それをシステムにアップロードして一括登録するという運用が便利です。Wagby EEは「アップロード更新」という機能によって実現しています。

トランザクション系

「イベント」とも呼びます。日々の業務によって登録、更新され、蓄積されていくデータです。Wagby EEではマスタ系、トランザクション系のいずれも「モデル」で表現します。

データの登録方法を把握する

洗い出したモデルを、今度はデータの登録方法という視点で整理します。図2に示すように「画面からの入力」「CSV,Excelから一括登録」「基幹系から取り込み」「別システムとの連携」「事前設定」といったアプローチがあります。

このうち「基幹系から取り込み」「別システムとの連携」は Wagby EE 標準機能ではサポートしていません。これらは専用のツールを利用するか、またはバッチプログラムを個別に作成して対応します。

Wagby EEのメリットは、モデルに対応した（リレーショナルデータベース上の）テーブルがすべて自動で作成され、かつ、外部からアクセス可能なように構造も明らかにしていることです。そのため、既存ツールを含む、さまざまな手法を活用してデータを登録・更新・閲覧できるようになります。

既存テーブルの再利用

Wagby EEでは、定義したモデルの設計情報をもとにテーブル定義文 (create table) を用意します。しかしすでに既存テーブルがある場合、この構造に準じてモデルを設計することで、既存テーブルを再利用することもできます。

Wagby EEでは、モデルに対するテーブル名や、モデル項目に対するテーブルの項目名・型を個別に指定することができます。これらをリポジトリ（設計情報）に明記することで、既存テーブルの活用が可能です。

注意点

すでに基幹系システムが稼働しているが、そのうちの一部サブシステムをWagby化したい、という場合があります。既存テーブルをどのように再利用するかについては案件毎によって採用する方針が異なります。代表的な注意点を整理します。

• Wagby EEでは「日付型」として扱いたいが、既存テーブルでは yyyyMMdd という8桁の文字列である、というように型が異なる場合があります。これを解決するシンプルな方法は、データベースに「ビュー」を定義することです。Wagby EEからは（テーブルではなく）ビューを操作させ、ビュー側で既存テーブルとの整合性を確保します。
• Wagby EEによるモデル設計は、自動的に第三正規系のテーブル構造を生成します。例えば明細情報（繰り返しコンテナ）はキーで紐づく別テーブルになります。しかし既存テーブルがこのような構造ではなく、オカレンスとしてデータを保持するような場合（例：電話番号1、電話番号2を項目として定義しており、三つ目の電話番号は管理できない）も、やはり工夫が必要です。

主キーの設計

個々のモデル定義において、重要なのが（自身を識別するための）「主キー」の設計です。 Wagby EEにおける主キーは次の性質があります。

• 主キーは重複してはなりません。ユニークである必要があります。
• 主キーは一度割り当てると、変更できません。

主キーの設計は、キーの値に意味を持たせるかどうか（人工キーまたは自然キー）、そして単一項目をキーとするか複合キーとするかという視点で行っていきます。

設計の判断基準は業務要件によって異なりますが、システム的な視点では単一項目の人工キー（いわゆる順序方式）がもっとも単純で、取り扱いが容易です。そのため、まず人工キーで扱うことができないかどうかを最初に検討することをお薦めします。

モデル同士の関係を把握する

ここまで整理したところで、モデルの関係性を整理します。各モデルを「ER図」(Entity-Relationship) と呼ばれる構造で表現します。

ただしWagby EEは静的な構造だけではなく、「画面上で関連付けを操作する方法」まで指定することができます。リストボックス、ラジオボタン、チェックボックス、検索画面などです。また、参照連動や絞り込みという機能もあるため、ER図にメモ書きするような形で、参照方法についても整理しておくとよいでしょう。

最初のアプリケーション開発を行う

モデル同士の関係性を把握できたタイミングで、いくつかのモデルについて、WagbyDesignerを用いて設計情報を登録してみます。

なお、この段階では計算式や画面レイアウト、利用者の権限などは定まっていません。これらは後回しで結構です。

ここでの目的は、早い段階でモデルの構造から動作するアプリケーションを起こし、モデル項目に追加するものはないか、モデル同士の関連は適切かをレビューすることです。

最初から完璧なアプリケーションを目指すのではなく、この段階では設計情報のチェック（ただし静的なレビューではなく、動作するアプリケーションを用いてレビューする）という意図でビルドを行ってください。

レビュー

ビルドしたアプリケーションを関係者でレビューします。このとき、「実際にアプリケーションを操作する現場担当者」をどのタイミングで加えるかはプロジェクト毎によって異なります。プロジェクトリーダーにて判断してください。

この時点で求められるWagby EEのスキル

ここまでの設計を行うために求められるWagby EEのスキルは次のとおりです

• モデルの定義方法
• モデル項目の定義方法
• 他モデルの参照方法
• 外部キーを用いた関係性の定義方法
• 繰り返し

次のテーマ

次章では構造におけるもう一つの切り口である「計算式」を扱います。