Piece Frameworkによるブログアプリケーションの作成

第4回 画面遷移設計とフロー定義(1)

この記事を読むのに必要な時間:およそ 2 分

前回の記事では,Piece Frameworkのインストールとプロジェクトディレクトリの作成,サンプルアプリケーションの動作確認を行いました。今回から2回に渡って,ブログアプリケーションの画面遷移設計とフロー定義ファイルの作成,画面遷移のみのアプリケーションの動作確認を行います。

画面遷移設計から着手する

第2回の記事で述べたように,Piece_UnityにはWebフローコントロール機能が備わっています。この機能によって得られる利益として,Webフローコントロールや,フロー定義ファイル,アプリケーションフローの一覧性,画面遷移コードのないアクションクラスといったものを挙げました。しかし,利益はこれらに留まりません。フロー定義ファイルに書き出されたアプリケーションフローと対応するHTMLから,ごく簡単に動作するアプリケーションが得られるのです。

この点に着目し,筆者はPiece_Unityによるアプリケーション開発プロセスとして,開発の初期段階で画面遷移のみのアプリケーションを作成し,それに手を加えて完成に近づけていくというプロセスを推奨しています。例え画面遷移のみであったとしても,動作するアプリケーションを開発の初期段階に用意することには下記のようなメリットがあります。

  • 顧客やユーザにとっては,画面や画面遷移を早期にレビューできることで,最終的に満足度の高いアプリケーションに誘導しやすい。
  • 開発者にとっては,早期に顧客やユーザ,加えて仮想顧客としての開発者自身からのフィードバックを受けられることで,仕様の確定やアプリケーションアーキテクチャの改善が促進される。

画面遷移の設計

では,早速画面遷移の設計に取りかかりましょう。今回はブログアプリケーションの画面遷移ということで,エントリー管理機能を取り上げます。下記の図は,一般的なブログアプリケーションのエントリー管理機能として考えられる,エントリーの一覧表示,エントリーの新規追加,エントリーの更新,エントリーの削除を実行できる画面と,それらの画面の関連を考えて設計したものです。

ブログアプリケーションの画面遷移図

ブログアプリケーションの画面遷移図

フロー定義ファイルとフローの粒度

Piece_Unityアプリケーションの画面遷移は最終的にフロー定義ファイルとして表現されることになります。フロー定義ファイルは,アプリケーションを構成するページフローを表現するためのDSLとして機能します。

ひとつのフロー定義ファイルには,単一の画面からアプリケーションの全画面までのさまざまな大きさのページフローを定義することができます。とはいえ,アプリケーションの全画面を単一のフロー定義ファイルで定義するといった方法はおすすめできません。実際のアプリケーションには多数の入口-エントリポイントが必要であり,それらはナビゲーションメニューや特定の画面,ブックマークなどから直接アクセスできる必要があります。トップページしかブックマークできないようなWebサイトはあきらかに好ましくありません。

この理由から,筆者はエントリポイントの必要性に応じてフローを切り出し,それらのフロー間の関係から単一のアプリケーションのフローを構成することが望ましいと考えています。フローを分割する理由は,エントリポイントの必要性以外にあってはならないというのが現在の筆者の考えです。

さて,さきほどの画面遷移図を見てください。画面の色は,その画面が属するフローを示しています。このアプリケーションは,新規エントリー入力画面,エントリー一覧画面,エントリー参照画面を入口とする3つの異なるフローから構成されていることがわかります。

著者プロフィール

久保敦啓(くぼあつひろ)

Piece Frameworkのアーキテクト及びプログラマー。PEARのNet_UserAgent_Mobileの開発者でもある。今春に株式会社アイテマンを設立。

URLhttp://iteman.typepad.jp/

コメント

コメントの記入