SPAにおける課題
SPAで画面の一部だけを再描画して画面遷移することはUXを高めるために有効です。しかし、遷移先画面に対して遷移元画面のどの部分を再描画するかを、画面遷移全体に対して画面間の不整合が発生しないように決めていくうち、画面構成は複雑になりがちです。これは、保守開発作業を困難にします。設計書が陳腐化していたり、アプリをよく知る開発者が異動などで不在になっていたりする場合には、さらにこの作業は困難になります。Webアプリ開発では、顧客の要求に合わせて短期間で開発や修正を繰り返すことが多いため、ソース実装が優先になり、設計書の陳腐化が起こりやすいのです。
SPAの保守開発時の作業として、主に以下のものがあります。
1つの画面に閉じた開発
- 画面DOMの追加・削除
- 画面DOMの修正（種類・属性・配置など）
- 画面内ロジックの追加・削除・修正
複数の画面を考慮した開発
- 画面間で共有するデータの追加・削除・修正
- 画面の追加・削除・修正
- 画面遷移の追加
- 画面遷移の削除・修正
これらの作業のうち、「複数の画面を考慮した開発」の中の、「画面遷移の削除・修正」作業を支援対象として選定することとしました。SPAの保守開発を行う開発者へのヒアリングの結果、支援してほしい作業として優先度が高かったからです。
SPAにおける画面遷移の概念図を、図4に示します。従来のWebアプリでは、画面とソースファイルが1：1で直接ひも付いていますが、SPAでは画面が1つ以上の画面定義で構成され、それぞれの画面定義は1つ以上のソースファイルとひも付いています。
「画面遷移の削除・修正」作業では、削除・修正対象画面遷移の画面遷移ハンドラを特定した上で、その画面遷移ハンドラが定義された画面定義を特定し、最終的に削除や修正を行うソースファイルを特定しなければいけません。また、実際に削除・修正作業を行う前に、画面遷移を削除や修正した場合にどの画面に影響が出るかを事前把握しておく必要があります。しかしSPAでは、削除・修正を行うソースファイルの特定も、また削除・修正時に影響が及ぶ画面の特定も、容易ではありません。
画面遷移理解支援プロセス
SPAの保守開発における「画面遷移の削除・修正」作業での課題は以下の2点です。
- 課題【1】：画面遷移の削除・修正時に、修正すべきソースファイルの特定が困難
- 課題【2】：画面遷移を削除・修正した時に、影響が波及する画面の特定が困難
これらの課題解決に向け、自作ツール （以後、画面遷移理解支援ツール）で支援することを想定した新たな作業プロセス（以後、画面遷移理解支援プロセス）を提案します。提案する作業プロセスは以下（a．～e．）の通りです。
- a．画面遷移理解支援ツールで、ソースから設計の画面遷移図を自動生成する
- b．仕様の画面と設計の画面を手動でひも付ける
- c．削除・修正対象の画面遷移を手動で指定する
- d．対象画面遷移を実現するソースを強調表示する
- e．影響波及画面を強調表示する
a．では、画面遷移理解支援ツールでソースコードを自動解析して、設計の画面遷移図を自動生成します。設計の画面遷移図とは、それぞれの画面がどのような画面定義で構成され、どの画面定義からどの画面遷移ハンドラでどの画面へ遷移するかを示した図になります。図5に例を示します。
まず、「画面」という表現は、以降は「画面の一部」を示すこととします。画面とは1つの「画面定義」のことで、HTMLで記述される「テンプレート」やJavaScriptで記述される「画面コントローラ」の組で構成され、場合によってはより多くのファイルで構成される場合もあります。図のportalは1つの画面です。portalは内部にportal.topを含みます。同様に、portal.top.side、portal.top.side.targetをそれぞれ内部に含みます。ある時点ではこれら4つの画面が見えています。画面同士に親子関係がある場合は、このように入れ子構造で表現します。「画面コントローラ」では、newReservation画面遷移ハンドラにより、portalを頂点とした、portal.top、portal.top.side、portal.top.side.target、portal.top.side.target.newrsvという5つの画面で構成された状態に遷移することが記述されています。この時、左側のportal.top.side.targetは遷移することでなくなり、新たにportal.side.target.newrsvが登場します。これら消えるものや新たに登場するものが、遷移による変化を伴う重要な要素であるので「核となる画面」として識別し、ライム色で表現します。それぞれの画面では、対応するソースコードのファイル名を記載しています。例えば、portal.top.side.target画面定義に対応するソースコードは、target.htmlとtarget.jsになります。
b．では、仕様の画面と設計の画面を手動でひも付けます。このひも付け作業は、画面遷移理解支援ツール上で行います。図6に、このひも付け作業支援に向けたツールの実画面と、ひも付け作業後のイメージを示します。
画面遷移理解支援ツールにあらかじめ仕様の画面名リストを与えておき、仕様の画面ごとに、どの設計の画面が対応するかをユーザーがプルダウンで選択していきます。図6は、仕様の画面「国内線航空機予約画面」に対して、portal.top.side.target画面定義を核とする設計の画面をひも付けたところです。このひも付け作業は、1回設定を行っておけば再設定の必要がないので、仮に対象のアプリをよく知らないユーザーが「画面遷移の削除・修正」作業を行う場合でも、課題解決に向けたこの後の流れを行うことができます。
c．では、削除・修正対象の画面遷移を手動で指定します。a．で作成した設計上の画面遷移図において、削除・修正したい画面遷移をクリックすることで指定します。図7の例では、国内線航空機予約画面のportal.top.side.target画面定義で定義されたnewReservation画面遷移ハンドラをユーザーがクリックして指定したものと想定しています。
d．では、c．でユーザーが指定した画面遷移を削除・修正するために、修正すべき画面定義とソースファイルを、画面遷移理解支援ツールが強調表示します。図7の例では、newReservation画面遷移ハンドラをユーザーが削除・修正対象として選択したので、その画面遷移ハンドラを定義しているportal.top.side.target画面定義と、そのソースファイルであるtarget.htmlとtarget.jsが強調表示されています。これにより、「画面遷移の削除・修正時に、修正すべきソースファイルの特定が困難」という課題【1】を解決し、修正すべきソースファイルを容易に特定できました。
e．では、c．でユーザーが指定した画面遷移を削除・修正する際に影響が波及する画面を、画面遷移理解支援ツールが強調表示します。なお、手順を簡単にするため、ここでの影響波及では画面遷移を削除・修正したことでデータの流れが変わることに起因した影響は考慮しないこととしています。図7の例では、newReservation画面遷移ハンドラをユーザーが削除・修正対象として選択したので、影響波及画面としてその画面遷移先と画面遷移元の仕様上の画面が強調表示されています。黄色の丸枠で囲った「国内線航空機予約画面」と「国内線航空機新規予約画面」に対して、ピンク色の枠を付けることで強調しています。これにより、「画面遷移を削除・修正した時に、影響が波及する画面の特定が困難」という課題【2】を解決し、影響が波及する画面を容易に特定できました。
