Wagbyの設計は「データ」を中心に行います。具体的には業務データの構造を整理することを設計の入り口としています。これをモデリングといいます。

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

構造

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

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

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

振る舞い

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

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

Wagby では、「構造」と「振る舞い」という区分において、「構造」を土台として扱います。つまり設計の起点はモデルの定義になります。このような考え方は一般に "データ中心アプローチ (DOA; Data Oriented Approach)" として知られています。

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

図1 モデルのおおまかな性質

選択肢

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

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

Wagbyでは選択肢を含む、すべてのモデル参照関係で論理削除をサポートしています。

マスタ系

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

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

トランザクション系

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

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

図2 モデルへのデータ登録方法の整理

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

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

一つのモデルに対して、複数の登録・更新方法を提供する場合は注意が必要です。Wagbyでは更新時に(競合によってデータが破壊されないように)ロックをかけます。このロックを無視して外部から同じデータを更新されると不整合が生じます。そのためアプリケーション全体でWagbyのロックルールに適合させるようにします。またはWagby側のモデルを読み取り専用とする、一定時間間隔で同期をとるといった方法があります。
新規開発案件の場合、この説明はスキップしてください。

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

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

注意点

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

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

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

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

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

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

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

図3 ER図の例

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

モデルの関係性を整理する前に、Wagbyが提供する「他モデルの参照」機能の概要を学んでおくことをお薦めします。
WagbyはER作図ツールを含んでいません。市場にはさまざまなツールが存在しますので、これらを活用して関係性を整理してください。(小規模なシステムであれば、紙を使っても把握できます。)

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

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

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

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

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

繰り返しになりますが、今の段階におけるレビューの目標は "忘れていたモデルやモデル項目はないか" を検証することです。ここで使い勝手や文字の色などに話が及ぶと議論が発散します。プロジェクトリーダーは現時点でのゴールを意識してレビューを行うよう指導してください。

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

Wagbyの機能(マニュアル)すべてを一度に把握する必要はありません。最初は「構造に関する定義」から進めていきます。

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