WO2016113914A1

WO2016113914A1 - 開発支援システム

Info

Publication number: WO2016113914A1
Application number: PCT/JP2015/051113
Authority: WO
Inventors: 祐介塩川; 英子宮前; 護清水
Original assignee: 株式会社野村総合研究所
Priority date: 2015-01-16
Filing date: 2015-01-16
Publication date: 2016-07-21
Also published as: JPWO2016113914A1; CN107111497A; JP6263282B2; US20170286068A1

Abstract

　部品化された要素を再利用することで画面開発を可能とする仕組みにおいて、部品を画面全体の外観との整合や調和を図りつつ容易に開発できるようにする。代表的な実施の形態によれば、再利用可能なコンポーネントについてその開発に係る要求を受け付けるコンポーネント開発コントローラと、コンポーネントについてのソースコードを含む情報を取得するコンポーネント開発モデルと、所定の背景画像を開発者端末に表示させるとともに、背景画像に重ねて、開発対象のコンポーネントの外観を表示するためのコンポーネント開発領域を表示させるコンポーネント開発ビューとを有し、開発対象のコンポーネントのソースコードが編集された場合に、当該ソースコードに基づいて開発対象のコンポーネントをデバイスの種類に対応したテンプレートによって規定される外観によりコンポーネント開発領域に表示させる。

Description

開発支援システム

　本発明は、Ｗｅｂアプリケーションの開発技術に関し、特に、マルチデバイスに対応した画面表示を行うＷｅｂアプリケーションの開発を支援する開発支援システムに適用して有効な技術に関するものである。

　近年、例えば、タブレット端末やスマートフォンなどのいわゆるスマートデバイスの業務活用が本格化しており、企業の基幹システムと連携するような中・大規模なシステムの開発案件も増える傾向にある。このような状況で、ユーザ企業の要件は複雑となり、ＩＴベンダー等の開発者にとって開発難易度も高くなってきていることから、開発の効率化を図って生産性を向上させることが重要となる。

　この点につき、例えば、ソースコードなどの開発成果物における共通部分・汎用部分の部品化や、開発時の部品の再利用を推進することが効果的である。さらに、マルチデバイスやマルチプラットフォーム（以下では単に「マルチデバイス」と総称する場合がある）対応を行うことで、デバイスやプラットフォーム毎の個別の開発部分を低減させることも有効である。

　マルチデバイスに対応した再利用可能な部品化の技術に関連して、例えば、特開２０１３－２３５３８７号公報（特許文献１）には、入出力項目を表示するためのコントロールの外観や属性、制御処理などを含むユーザインタフェースを、デバイスに応じてソースコードを変更することなく動的に変更するＷｅｂサーバシステムが記載されている。当該システムは、例えば、クライアント端末からの要求に基づいて、クライアント端末のデバイスの種類に係る情報を取得するデバイス取得部と、ソースコードに含まれるパーツオブジェクトについて、デバイス取得部により取得したクライアント端末のデバイスの種類に応じた、パーツオブジェクトの承継元の上位クラスに実装された、コントロールを表示する際の調整内容に基づいて、クライアント端末の画面上に対応するコントロールを表示させるＨＴＭＬデータを生成する応答処理部とを有する。

特開２０１３－２３５３８７号公報

　例えば、特許文献１に記載されたような技術を用いることで、Ｗｅｂアプリケーションの開発に際して、部品（パーツオブジェクト）を再利用可能とするとともに、１つのソースコードでマルチデバイス対応をすることが可能となる。

　しかしながら、実際は、１つのソースコードによるマルチデバイス対応といっても、例えば、ソースコード中でｉｆ文などによりデバイス毎に処理を書き分けることが必要となる場合もある。また、新たにデバイスが追加された場合にソースコードに処理を追記しなければならないなど、画面開発者にとって１つのソースコードによって完全なマルチデバイス対応をすることは困難である。

　また、マルチデバイス対応として、例えば、デバイスの画面サイズに応じてユーザインタフェースを切り替えることができる場合でも、実際は、ある画面において表示されるコントロールやパーツなどの大きさや表示形式、配置などを変更できるのみであり、複数画面の遷移を伴った変更を行うことは困難である。

　例えば、ＰＣ（Personal Computer）やタブレット端末に比べてスマートフォンの画面サイズは小さく、表示できる情報量に制約がある。そのため、例えば、メニューなどの一覧表示について、ＰＣやタブレット端末では１つの画面に常時全て展開した状態で一覧表示するのに対し、スマートフォンでは、通常時はメニュー表示を指示するアイコン等のみを表示しておき、当該アイコン等を介してメニュー表示が指示された際に別画面としてメニュー一覧を表示する、というようなインタフェースが採用される場合がある。従来技術ではこれらの場合に１つのソースコードで各パターンに対応できるようにすることは困難である。そこで、再利用可能な部品を用いて画面開発を行う場合に、デバイスが異なる場合でも１つのソースコードによってマルチデバイス対応を可能とするような仕組みが望まれる。

　一方で、上記のような仕組みを実現するには、画面開発者に対して再利用可能な部品を提供することが必要であり、これらの部品を作成・開発する作業にも効率性が求められる。再利用可能な部品は、最終的には背景や他のコントロール、パーツなどと組み合わせて画面上に配置されることから、特に外観においてこれらとの整合・調和が必要となる。この点、再利用可能な部品を単独で開発する場合には、作成→実行（テスト画面上での表示）→外観の確認→外観の再調整、という試行錯誤を繰り返すことになり、テスト環境の準備なども含めて作業効率が大きく低下してしまう。

　そこで本発明の目的は、部品化された要素を再利用することでマルチデバイス対応のＷｅｂアプリケーションに係る画面開発を可能とする仕組みにおいて、再利用可能な部品を、画面全体の外観との整合や調和を図りつつ容易に開発できるようにする開発支援システムを提供することにある。

　本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

　本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、以下のとおりである。

　本発明の代表的な実施の形態による開発支援システムは、クライアント端末からのリクエストを受けて前記クライアント端末のデバイスの種類に応じた処理結果画面を応答するＷｅｂアプリケーションの画面開発を支援する開発支援システムであって、以下の特徴を有するものである。

　すなわち、開発支援システムは、１つ以上の画面パーツの組み合わせからなり、前記各画面パーツが画面表示される際の外観を前記デバイスの種類毎に規定したテンプレートを有し、前記Ｗｅｂアプリケーションの画面開発に再利用可能なコンポーネントについて、その開発に係る要求を開発者端末を介して受け付けるコンポーネント開発コントローラと、前記コンポーネント開発コントローラからの指示に基づいて、前記コンポーネントについてのソースコードを含む情報を取得するコンポーネント開発モデルと、前記コンポーネント開発コントローラからの指示に基づいて、前記開発者端末から指定されたデバイスの種類に対応した所定の背景画像を前記開発者端末に表示させるとともに、前記背景画像に重ねて、開発対象の前記コンポーネントの外観を表示するためのコンポーネント開発領域を前記開発者端末に表示させるコンポーネント開発ビューと、を有する。

　そして、開発対象の前記コンポーネントのソースコードが編集された場合に、当該ソースコードに基づいて、開発対象の前記コンポーネントを、前記開発者端末から指定されたデバイスの種類に対応した前記テンプレートによって規定される外観により前記コンポーネント開発領域に表示させる。

　本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

　すなわち、本発明の代表的な実施の形態によれば、部品化された要素を再利用することでマルチデバイス対応のＷｅｂアプリケーションに係る画面開発を可能とする仕組みにおいて、再利用可能な部品を、画面全体の外観との整合や調和を図りつつ容易に開発することが可能となる。

本発明の実施の形態１であるＷｅｂサーバシステムの構成例について概要を示した図である。（ａ）、（ｂ）は、本発明の実施の形態１におけるデバイス毎のレイアウトの相違の例について概要を示した図である。（ａ）、（ｂ）は、本発明の実施の形態１におけるデバイス毎のレイアウトの相違の他の例について概要を示した図である。（ａ）、（ｂ）は、本発明の実施の形態１におけるデバイス毎のコンポーネント表示の相違の例について概要を示した図である。（ａ）、（ｂ）は、本発明の実施の形態１におけるデバイス毎のコンポーネント表示の相違の他の例について概要を示した図である。本発明の実施の形態１におけるエディットビューでの指定内容と、これに伴う画面表示時の処理の流れの例について概要を示した図である。本発明の実施の形態２である開発支援システムの構成例について概要を示した図である。本発明の実施の形態２におけるコンポーネントの開発画面の例について概要を示した図である。本発明の実施の形態２におけるコンポーネントの開発画面の例について概要を示した図である。本発明の実施の形態２におけるコンポーネントの開発画面の例について概要を示した図である。本発明の実施の形態２における画面開発を行う場合の処理の流れの例について概要を示した図である。

　以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

　（実施の形態１）
　＜システム構成＞
　図１は、本発明の実施の形態１であるＷｅｂサーバシステムの構成例について概要を示した図である。本発明の実施の形態１であるＷｅｂサーバシステム１００は、画面パーツをコンポーネント化してコンポーネント１９０の一覧として有するとともに、コンポーネント１９０が配置される１つ以上の画面領域からなるレイアウトのパターンとしてレイアウト１８０の一覧を有している。そして、各レイアウト１８０および各コンポーネント１９０は、それぞれ、デバイス毎に最適化された画面出力をするように作成されたテンプレートを有しており、Ｗｅｂサーバシステム１００は、これらに基づいてデバイス毎に最適化された画面出力を自動的に行う。

　Ｗｅｂサーバシステム１００は、例えば、サーバ機器やクラウドコンピューティングサービス上に構築された仮想サーバからなるサーバシステムであり、例えば、図示しないＯＳ（Operating System）や、Ｗｅｂサーバプログラム１１０、言語処理系１２０、フレームワーク１３０などのミドルウェアや基盤等の上で稼働する、もしくはこれらを利用するソフトウェアとして、ＭＶＣ（Model View Controller）モデルによって開発、実装されたコントローラ１４０、モデル１５０、エディットビュー１６０、コンポーネントビュー１７０、レイアウト１８０およびコンポーネント１９０などの各部（モジュール）を有する。

　Ｗｅｂサーバプログラム１１０としては、例えば、Ａｐａｃｈｅ（登録商標）　ＨＴＴＰ　Ｓｅｒｖｅｒなど、Ｗｅｂサーバにおいて一般的に用いられているものを適宜用いることができる。また、Ｗｅｂサーバプログラム１１０上で稼働するアプリケーションシステムの基盤となる言語処理系１２０およびフレームワーク１３０としては、例えば、動的なＷｅｂページを作成するために用いられるＰＨＰなどのスクリプト言語、およびＰＨＰで実装されたＺｅｎｄ　Ｆｒａｍｅｗｏｒｋなどを適宜用いることができる。

　コントローラ１４０は、ＭＶＣモデルにおけるコントローラ（Ｃ）としての機能を有し、クライアント端末２００上の図示しないＷｅｂブラウザ等からのリクエストを受けて、モデル１５０に対してデータの操作要求を行ってデータを取得したり、エディットビュー１６０に対して画面表示を要求したりする。モデル１５０は、ＭＶＣモデルにおけるモデル（Ｍ）としての機能を有し、ビジネスロジックを実行してデータの操作や取得を行う機能を有する。ビジネスロジック（ＢＬ）は、例えば、データベースなどを有する他のＢＬサーバ３００に対して要求を行って実行させるようにしてもよい。

　エディットビュー１６０およびコンポーネントビュー１７０は、ＭＶＣモデルにおけるビュー（Ｖ）としての機能を有し、モデル１５０のデータに基づいて画面生成を行って表示する機能を有する。エディットビュー１６０は、画面の構成を行う機能を有し、後述するように、画面において用いるレイアウト１８０を指定するとともに、レイアウト１８０によって表示される領域に配置するコンポーネント１９０をそれぞれ呼び出して設定を行う。コンポーネントビュー１７０は、このレイアウト１８０およびコンポーネント１９０の情報に基づいてレンダリングを行ってＨＴＭＬ（HyperText Markup Language）データを作成し、クライアント端末２００に対して出力する。

　このとき、コンポーネントビュー１７０は、後述するように、クライアント端末２００のデバイスに応じてレイアウト１８０およびコンポーネント１９０に対して設定されている画面表示のためのＷｅｂテンプレートをテンプレートエンジン１７１により処理することで、対象のデバイスに最適化された画面出力を行う。

　Ｗｅｂテンプレートは、図示するように、クライアント端末２００の種別（ＰＣ、スマートフォン（スマホ）、タブレット端末）毎に、レイアウト１８０に対するものとして、それぞれ、テンプレート（ＰＣ用）１８１ｐ、テンプレート（スマホ用）１８１ｓ、テンプレート（タブレット用）１８１ｔ（これらを総称してテンプレート１８１と記載する場合がある）、およびコンポーネント１９０に対するものとして、それぞれ、テンプレート（ＰＣ用）１９１ｐ、テンプレート（スマホ用）１９１ｓ、テンプレート（タブレット用）１９１ｔ（これらを総称してテンプレート１９１と記載する場合がある）を有する。図１の例では、ＰＣ、スマートフォン、およびタブレット端末の別にテンプレート１８１および１９１を用意しているが、これに限らず、他のデバイスのものや、同じ種類でも画面サイズが異なったり、ＯＳやＷｅｂブラウザが異なるデバイスのものを有していてもよい。

　テンプレートエンジン１７１は、テンプレート１８１および１９１などのＷｅｂテンプレートに規定されたデザインや外観の内容に基づいて実際の画面を作成する機能を有する。なお、テンプレートエンジン１７１には、例えば、ＰＨＰにおいて主に用いられているＳｍａｒｔｙなどの一般的なテンプレートエンジンを適宜用いることができる。

　コントローラ１４０やコンポーネントビュー１７０は、Ｗｅｂサーバシステム１００として汎用的に提供することができる。また、画面部品としてのレイアウト１８０やコンポーネント１９０（テンプレート１８１および１９１も含む）は、他の開発案件で作成されたものを再利用したり、対象の開発案件において予め作成されたものを用いたりすることができる。また、モデル１５０についても、対象の開発案件等において別途作成されたものを用いることができる。一方、エディットビュー１６０は、画面開発者がソースコードとして作成することになるが、デバイス毎の相違は、テンプレート１８１や１９１（およびテンプレートエンジン１７１）が吸収するため、画面開発者がデバイス毎の相違を意識することは不要である。

　＜レイアウトとコンポーネント＞
　図２は、本実施の形態におけるデバイス毎のレイアウトの相違の例について概要を示した図である。レイアウトとは、画面全体を１つ以上の領域に区分し、その領域の配置のパターンを指すものであり、図２（ａ）では、タブレット端末でのレイアウト、図２（ｂ）では、スマートフォンでのレイアウトの例をそれぞれ示している。

　図２の例では、レイアウト１８０として「一覧、明細型レイアウト」を選択した場合を示しており、ヘッダ領域（ヘッダ領域４０１、４１１）およびフッタ領域（フッタ領域４０４、４１４）の他に、複数の項目を一覧表示する一覧領域（一覧領域４０２、４１２）と、その中から特定の項目を選択した際にその詳細な内容を表示するコンテンツ領域（コンテンツ領域４０３、４１３）とを有するレイアウトについて示している。

　図示するように、図２（ａ）のレイアウトでは、１つの画面内に４つの領域が全て配置されている。一方、図２（ｂ）のレイアウトでは、左側の画面において一覧領域４１２が表示されている状態で、一覧領域４１２の中から特定の項目を選択すると、右側の画面に遷移して、一覧領域４１２に代って、選択された項目を表示するためのコンテンツ領域４１３が表示されることを示している。同一のレイアウト１８０におけるこのようなデバイス毎の相違は、上述したように、テンプレート１８１（この場合はテンプレート（タブレット用）１８１ｔおよびテンプレート（スマホ用）１８１ｓ）に規定され、コンポーネントビュー１７０のテンプレートエンジン１７１によって実際の画面に反映される。

　このように、画面上に表示される部品やコントロールの単位だけではなく、画面全体のレイアウト（画面遷移を伴うものも含む）の単位でも、レイアウト１８０およびテンプレート１８１によりデバイス毎の相違を吸収・隠蔽する。これにより、デバイスによっては画面遷移を伴うレイアウトを有しているような場合であっても、エディットビュー１６０についてはデバイスを意識することなく開発することができる。

　図３は、本実施の形態におけるデバイス毎のレイアウトの相違の他の例について概要を示した図である。図２と同様に、図３（ａ）では、タブレット端末でのレイアウト、図３（ｂ）では、スマートフォンでのレイアウトの例をそれぞれ示している。図３の例では、レイアウト１８０として「検索条件、結果表示型レイアウト」を選択した場合を示しており、ヘッダ領域（ヘッダ領域４０１、４１１）およびフッタ領域（フッタ領域４０４、４１４）の他に、検索の際の条件を入力、指定するパーツ等を表示する検索条件領域（検索条件領域４０５、４１５）と、その検索条件に基づく検索結果を表示する検索結果領域（検索結果領域４０６、４１６）とを有するレイアウトについて示している。

　例えば、図３（ａ）と図２（ａ）において各領域の配置が異なるように、エディットビュー１６０において指定するレイアウト１８０を変更することで、コンポーネントビュー１７０のテンプレートエンジン１７１によって各領域のデザイン、外観を自動的に切り替えることができる。

　図４は、本実施の形態におけるデバイス毎のコンポーネント表示の相違の例について概要を示した図である。図２と同様に、図４（ａ）では、タブレット端末でのレイアウト、図４（ｂ）では、スマートフォンでのレイアウトの例を示しており、それぞれ、図２の例で示した「一覧、明細型レイアウト」において「メニュー」のコンポーネント１９０をヘッダ領域４０１、４１１に表示させた場合を示している。

　図示するように、図４（ａ）のタブレット端末でのレイアウトでは、ヘッダ領域４０１に４つのメニューボタンが横並びに表示されている。一方、図４（ｂ）のスマートフォンのレイアウトでは、左側の画面において、ヘッダ領域４１１にはメニューを表示させるアイコンのみが表示されており、このアイコンをタップすると右側の画面に遷移して、ヘッダ領域４１１が拡張され（ヘッダ領域４１１’）、この領域にメニューボタンが縦並びに表示されることを示している。同一のコンポーネント１９０におけるこのようなデバイス毎の相違は、レイアウト１８０の場合と同様に、テンプレート１９１（この場合はテンプレート（タブレット用）１９１ｔおよびテンプレート（スマホ用）１９１ｓ）に規定され、コンポーネントビュー１７０のテンプレートエンジン１７１によって実際の画面に反映される。

　なお、本実施の形態におけるコンポーネント１９０は、１つの画面パーツやコントロールからなるものに限らず、図示するように、複数のパーツやコントロール（図４の例では４つのメニューボタン）の集合や組み合わせによって構成してもよい。

　図５は、本実施の形態におけるデバイス毎のコンポーネント表示の相違の他の例について概要を示した図である。図３と同様に、図５（ａ）では、タブレット端末でのレイアウト、図５（ｂ）では、スマートフォンでのレイアウトの例を示しており、それぞれ、図３の例で示した「検索条件、結果表示型レイアウト」において「検索結果一覧」のコンポーネント１９０を検索結果領域４０６、４１６に表示させた場合を示している。図示するように、図５（ａ）のタブレット端末でのレイアウトでは、検索結果領域４０６に検索結果一覧が表形式で表示されている。一方、図５（ｂ）のスマートフォンのレイアウトでは、遷移した右側の画面の検索結果領域４１６に検索結果一覧がリスト形式で縦並びに表示されることを示している。

　＜処理の流れ＞
　図６は、エディットビュー１６０での指定内容と、これに伴う画面表示時の処理の流れの例について概要を示した図である。上述したように、画面開発者は、ソースコードとして以下の処理を行うようなエディットビュー１６０を作成するが、その中では、デバイス毎の相違を意識することなくレイアウト１８０およびコンポーネント１９０を指定して配置、設定するだけでよい。デバイス毎に最適化された画面表示は、テンプレート１８１や１９１に規定された内容に基づいてコンポーネントビュー１７０（およびテンプレートエンジン１７１）が実行時に動的に行う。

　エディットビュー１６０では、まず、予め作成されているレイアウト１８０の一覧の中から、画面表示に用いるレイアウト１８０を取得する（Ｓ０１）。この時点ではレイアウト１８０に設定された各領域にはまだ何も表示すべきコンポーネント１９０は配置されていない。次に、予め作成されているコンポーネント１９０の一覧の中から、ステップＳ０１で取得したレイアウト１８０に配置する１つ以上のコンポーネント１９０を取得する（Ｓ０２）。この時点ではまだコンポーネント１９０には表示すべきデータなどの設定は何もされていない。

　その後、ステップＳ１９０で取得した各コンポーネント１９０に対して、表示すべきデータとして、モデル１５０から取得したデータを設定する（Ｓ０３）。なお、モデル１５０によるデータの取得は、コントローラ１４０を介した指示により実行される。次に、データを設定した各コンポーネント１９０を、ステップＳ０１で取得したレイアウト１８０における適当な領域に配置されるよう位置指定する（Ｓ０４）。そして、各コンポーネント１９０の配置位置を指定したレイアウト１８０をコンポーネントビュー１７０に渡して画面描画を指示する（Ｓ０５）。

　このとき、クライアント端末２００のデバイスの種類に係る情報も併せてコンポーネントビュー１７０に渡す（もしくはコンポーネントビュー１７０自身がリクエストメッセージの内容から取得する）。デバイスの種類に係る情報は、例えば、クライアント端末２００からのリクエストメッセージのＵｓｅｒ－Ａｇｅｎｔヘッダから取得するなど、公知の技術により取得することができる。なお、ここでのデバイスの種類に係る情報には、機器の種別の他に、例えば、ＯＳ、Ｗｅｂブラウザやそのバージョン等の情報も含まれるものとする。

　コンポーネントビュー１７０では、渡されたレイアウト１８０および各コンポーネント１９０について、それぞれ、デバイスの種類に対応したテンプレート１８１および１９１を取得して、テンプレートに規定されているデザインに従ってデータを含めた画面描画を行う。例えば、各コンポーネント１９０については、デバイスの種類（図６の例ではスマートフォン）に対応したテンプレート（スマホ用）１９１ｓを取得して、これに規定されているデザインに基づいてデータを含めてコンポーネント１９０を画面描画する（図６の例では検索結果の一覧表示）。また、レイアウト１８０については、テンプレート１８１ｓを取得して、これに規定されているデザインに基づいて各領域を描画するとともに、指定された領域の位置に画面描画された各コンポーネント１９０を配置する（図６の例では検索結果領域４１６に検索結果の一覧表示を配置する）。

　以上に説明したように、本発明の実施の形態１であるＷｅｂサーバシステム１００によれば、画面パーツをコンポーネント化するとともに、コンポーネント１９０が配置される１つ以上の領域からなるレイアウト１８０のパターンを有している。そして、各レイアウト１８０および各コンポーネント１９０は、それぞれ、デバイス毎に最適化された画面出力をするように作成されたテンプレート１８１、１９１を有しており、Ｗｅｂサーバシステム１００は、これらのテンプレートを処理するテンプレートエンジン１７１を有するコンポーネントビュー１７０を備える。

　これにより、画面のレイアウトおよびコンポーネントが部品化され、エディットビュー１６０のソースコードにおいてこれらを呼び出すことにより、デバイスに応じて最適化された画面表示を動的に行うことが可能となる。すなわち、画面開発者は、デバイス毎の相違を意識することなくエディットビュー１６０のソースコードを作成することができる。さらに、レイアウト１８０やコンポーネント１９０におけるデータの処理や振る舞いを制御する機能と、テンプレート１８１、１９１によって規定されるデザイン（ＨＴＭＬやＣＳＳ（Cascading Style Sheets）など）とを分離することで、デザイナーによる開発成果物を画面パーツとして容易に取り込むことが可能となる。

　（実施の形態２）
　上記の実施の形態１において、画面開発者は、エディットビュー１６０のソースコードから部品化されたコンポーネント１９０を呼び出すことで画面開発を行うことができる。しかしながら、そのためには、部品化されたコンポーネント１９０を予め作成・開発して画面開発者に対して提供することが必要であり、コンポーネント１９０を作成・開発する作業にも効率性が求められる。コンポーネント１９０は、最終的には背景や他のコンポーネント１９０などと組み合わせてレイアウト１８０に応じて画面上に配置されることから、特に色彩や大きさなどの外観においてこれら周辺環境との整合・調和を図りつつ開発することが必要となる。

　そこで、本発明の実施の形態２である開発支援システムは、画面開発者が利用可能なコンポーネント１９０を、画面全体の外観との整合や調和を図りつつ容易に開発できるようにするコンポーネント開発機能を提供する。具体的には、画面開発者が利用可能なコンポーネント１９０を、画面全体の外観を表示する背景画像上で外観の整合・調和を確認しながら開発するようなＷｅｂアプリケーションを、上記の実施の形態１におけるＷｅｂサーバシステム１００を利用して、Ｗｅｂサーバシステム１００上で稼働する１つのアプリケーションとして実装することで実現する。

　＜システム構成＞
　図７は、本発明の実施の形態２である開発支援システムの構成例について概要を示した図である。本実施の形態の開発支援システム１０１は、上述したように、実施の形態１において図１に示したＷｅｂサーバシステム１００をベースとして構成された開発環境であり、画面開発者が使用するＰＣ等の開発者端末２０１に対して、再利用可能なコンポーネント１９０を、画面全体の外観を表示する背景画像上で開発可能とするコンポーネント開発機能を提供するシステムである。

　開発支援システム１０１におけるＷｅｂサーバプログラム１１０、言語処理系１２０、およびフレームワーク１３０については、実施の形態１の図１に示したＷｅｂサーバシステム１００と同様であるため、説明は省略する。

　コンポーネント開発コントローラ１４１は、ＭＶＣモデルにおけるコントローラ（Ｃ）としての機能を有し、本実施の形態では、開発者端末２０１上の図示しないＷｅｂブラウザ等からのリクエストを受けて、後述するコンポーネント開発モデル１５１を介して、開発者端末２０１を使用して開発者が開発するコンポーネント１９０のソースコードのテキスト情報を取得する。ソースコードの保存や更新機能を有していてもよい。また、開発対象のコンポーネント１９０について、後述するコンポーネント開発ビュー１６１に対してソースコードのテキスト、もしくは実行時の外観を画面表示するよう要求する。

　コンポーネント開発モデル１５１は、ＭＶＣモデルにおけるモデル（Ｍ）としての機能を有し、本実施の形態では、開発対象のコンポーネント１９０の情報を取得してコンポーネント開発コントローラ１４１に応答する。これを実現するため、本実施の形態では、全てのコンポーネント１９０（実際には、当該コンポーネント１９０のソースコードが記録されたファイル）は、所定のフォルダやディレクトリに配置されているものとする。

　コンポーネント開発ビュー１６１は、ＭＶＣモデルにおけるビュー（Ｖ）としての機能を有し、コンポーネント開発モデル１５１のデータに基づいて画面生成を行って表示する機能を有する。すなわち、本実施の形態では、コンポーネント開発モデル１５１が取得した開発対象のコンポーネント１９０の情報に基づいて、ソースコードのテキストを編集可能なように表示し、もしくは実行時の外観を背景画像と併せて画面上に表示する。

　背景画像の表示は背景表示部１６２が行い、コンポーネント１９０のソースコードのテキスト表示および実行時の外観の表示は開発領域表示部１６３が行う。コンポーネント１９０の実行時の外観の画面表示の際には、実施の形態１の場合と同様に、テンプレートエンジン１７１が、デバイス毎に最適化された画面出力を行うよう作成されたテンプレートを呼び出してこれを処理することで表示する。

　開発者端末２０１に表示される画面においてデバイスの種類を指定できるようにすることで、指定されたデバイスに応じたテンプレートおよび背景画像を用いてコンポーネント１９０の画面表示を切り替えられるようにしてもよい。これにより、同一の開発者端末２０１上でデバイス毎に画面表示を動的に切り替えてコンポーネント１９０の外観等を確認することができる。

　なお、実施の形態１では、コンポーネント１９０を含む画面を表示するクライアント端末２００のデバイスに応じて、レイアウト１８０を用いて画面表示を最適化するものとしていたが、本実施の形態では、開発中の未完成なコンポーネント１９０を表示させることから、コンポーネント１９０の外観を表示させる際にレイアウト１８０を利用した画面の構成は行わず、固定的な背景画像上に表示させるものとする。従って、図７の構成例では、実施の形態１の図１に示した構成例におけるレイアウト１８０の一覧を有さない構成となっている。一方でこれに限られず、開発対象のコンポーネント１９０の外観の確認の際にも、実施の形態１と同様に、レイアウト１８０を用いて画面上での配置と表示を行うようにしてもよい。

　また、本実施の形態では、Ｗｅｂアプリケーションの開発環境である開発支援システム１０１を、実行環境である実施の形態１の図１に示したＷｅｂサーバシステム１００とは別に独立して実装した場合を例としているが、これらを同一のサーバシステムとして共存させる構成とすることも可能である。また、このサーバシステムを開発者端末２０１上に構築し、スタンドアロンの開発環境を構成することも可能である。

　＜画面例＞
　図８～図１０は、開発支援システム１０１によって開発者端末２０１の画面上に表示されるコンポーネント１９０の開発画面の例について概要を示した図である。開発画面では、画面上部において開発対象のデバイスを選択することができる（図８の例では「ＰＣ」が選択されている）。開発者端末２０１の実際のデバイス種別に関わらず、開発支援システム１０１は、ここで選択されたデバイスに対応する表示形式とすることで、デバイスをエミュレートする。これを実現するため、例えば、開発者端末２０１から開発支援システム１０１に対して開発画面表示のリクエストを送信する際に、リクエストに含まれるデバイスを特定する情報を、ここで選択されたデバイスによって更新する等の対応を行う。

　図８に示した例は初期画面であり、背景画像１６４と、これに重ねてコンポーネント開発領域１６５として白地の枠が表示されている。図８の例では背景画像１６４の詳細内容は省略しているが、フレームやコントロール、パーツなどの表示の単位や区切りについての例を網掛け枠によって示している。なお、本実施の形態では、背景画像１６４は、例えば開発対象のＷｅｂサイトのトップページ等をスクリーンキャプチャした静的な画像データを用いるものとしているが、これに限られない。例えば、実施の形態１において説明したものと同様の構成により、各コンポーネント１９０をレイアウト１８０に基づいて配置して、デバイスの種類に応じて動的に画面描画したものを用いることもできる。

　開発者は、コンポーネント開発領域１６５をマウス等によりサイズ変更したり、ドラッグ＆ドロップによって適当な位置に移動させたりすることができる。ここで設定されたサイズは、開発されたコンポーネント１９０が実際に表示される際のサイズとなるよう自動的にソースコードに設定するようにしてもよい。なお、位置については、当該コンポーネント１９０が実際に利用される際には、実施の形態１において示したように、レイアウト１８０によって配置位置が規定されることになる。

　コンポーネント開発領域１６５は、初期状態の開発モードではテキスト編集が可能なように構成されており、開発者は、コンポーネント開発領域１６５のサイズおよび位置を設定した後、図９の例に示すように、コンポーネント開発領域１６５内でソースコードを直接編集する。編集したソースコードは、例えば、図示しない保存ボタン等を介した開発者からの指示・操作により、サーバサイド、すなわち開発支援システム１０１上にコンポーネント１９０のソースコードとして直接保存することができる。

　開発したソースコードに基づいてコンポーネント１９０の外観等を確認するため、開発者からの指示・操作に基づいて、コンポーネント開発領域１６５は開発モードから確認モードに切り替えられる。確認モードでは、コンポーネント開発領域１６５は、対象のコンポーネント１９０を呼び出し、図１０の例に示すように、テンプレートエンジン１７１を介して実行時の外観を実際に画面上に表示させることができる。開発者は、コンポーネント１９０の動作や外観について背景画像１６４との整合・調和などを確認した後、図９の画面に示す開発モードに戻って、再度ソースコードの修正等を行うことができる。

　なお、ソースコードの編集・保存やバージョン管理等の開発機能として、例えば、Ｅｃｌｉｐｓｅなどの一般的に利用可能な外部の開発環境を用いることもできる。この場合、開発者は、Ｅｃｌｉｐｓｅ上で直接ソースコードの編集や保存等を行ってもよいし、コンポーネント開発領域１６５を外部エディタとしてここで編集等を行うようにすることも可能である。

　図１１は、開発支援システム１０１によって開発者端末２０１上で画面開発を行う場合の処理の流れの例について概要を示した図である。ここでは、図８～図１０の画面例において示した処理の流れの概略を示しており、まず、開発支援システム１０１のコンポーネント開発ビュー１６１における背景表示部１６２が、開発者端末２０１の図示しないＷｅｂブラウザ上に背景画像１６４を表示させる。背景画像１６４のデータは、例えば、開発支援システム１０１に予め登録しておいてもよいし、開発者が随時指定できるようにしてもよい。さらに、コンポーネント開発ビュー１６１における開発領域表示部１６３が、白地のコンポーネント開発領域１６５を背景画像に重ねて表示させて開発モードとする。

　なお、コンポーネント開発領域１６５は、例えば、ＩＦＲＡＭＥタグによるインラインフレームとして、開発者端末２０１上において当該開発画面を表示している図示しないＷｅｂブラウザに対して入れ子のブラウザ要素として形成することができる。また、上記の例では、新規にコンポーネント１９０を開発するものとし、白地のコンポーネント開発領域１６５を表示させているが、開発者からの指示により既存のコンポーネント１９０を修正のために呼び出して、そのソースコードを表示させるようにしてもよい。

　開発者は、図８に示したように、コンポーネント開発領域１６５のサイズおよび位置を設定した上で、図９に示したようにソースコードを作成し保存する。コンポーネント１９０のソースコードは、開発支援システム１０１上の所定のフォルダやディレクトリに保存される。そして、開発者からの指示等により開発モードから確認モードに切り替えられると、コンポーネント開発ビュー１６１は、対象のコンポーネント１９０を呼び出して、テンプレートエンジン１７１により外観を形成し、図１０に示すようにコンポーネント開発領域１６５上に表示させる。

　ソースコードの開発環境として、Ｅｃｌｉｐｓｅなどの外部の開発環境を用いる場合は、例えば、コンポーネント開発領域１６５は常時確認モードとなっており、Ｅｃｌｉｐｓｅ上で行われたソースコードの更新・保存等を、コンポーネント開発ビュー１６１の開発領域表示部１６３が監視することで、更新された対象のコンポーネント１９０を呼び出して、コンポーネント開発領域１６５に動的に外観を表示させることができる。

　以上に説明したように、本発明の実施の形態２である開発支援システム１０１によれば、開発者が、開発者端末２０１上において背景画像１６４上に重ねて表示されたコンポーネント開発領域１６５上で、コンポーネント１９０のソースコードの開発と、実行による外観表示とを随時切り替えて行えるようにする。これにより、画面全体での外観の整合・調和などを適宜確認しながら、コンポーネント１９０の開発を効率的に行うことが可能となる。

　以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は上記の実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、上記の実施の形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、各実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。

　本発明は、マルチデバイスに対応した画面表示を行うＷｅｂアプリケーションの開発を支援する開発支援システムに利用可能である。

１００…Ｗｅｂサーバシステム、１０１…開発支援システム、１１０…Ｗｅｂサーバプログラム、１２０…言語処理系、１３０…フレームワーク、１４０…コントローラ、１４１…コンポーネント開発コントローラ、１５０…モデル、１５１…コンポーネント開発モデル、１６０…エディットビュー、１６１…コンポーネント開発ビュー、１６２…背景表示部、１６３…開発領域表示部、１６４…背景画像、１６５…コンポーネント開発領域、１７０…コンポーネントビュー、１７１…テンプレートエンジン、１８０…レイアウト、１８１ｐ…テンプレート（ＰＣ用）、１８１ｓ…テンプレート（スマホ用）、１８１ｔ…テンプレート（タブレット用）、１９０…コンポーネント、１９１ｐ…テンプレート（ＰＣ用）、１９１ｓ…テンプレート（スマホ用）、１９１ｔ…テンプレート（タブレット用）、
２００…クライアント端末、２０１…開発者端末、
３００…ＢＬサーバ、
４０１…ヘッダ領域、４０２…一覧領域、４０３…コンテンツ領域、４０４…フッタ領域、４０５…検索条件領域、４０６…検索結果領域、４１１、４１１’…ヘッダ領域、４１２…一覧領域、４１３…コンテンツ領域、４１４…フッタ領域、４１５…検索条件領域、４１６…検索結果領域

Claims

　クライアント端末からのリクエストを受けて前記クライアント端末のデバイスの種類に応じた処理結果画面を応答するＷｅｂアプリケーションの画面開発を支援する開発支援システムであって、
　１つ以上の画面パーツの組み合わせからなり、前記各画面パーツが画面表示される際の外観を前記デバイスの種類毎に規定したテンプレートを有し、前記Ｗｅｂアプリケーションの画面開発に再利用可能なコンポーネントについて、その開発に係る要求を開発者端末を介して受け付けるコンポーネント開発コントローラと、
　前記コンポーネント開発コントローラからの指示に基づいて、前記コンポーネントについてのソースコードを含む情報を取得するコンポーネント開発モデルと、
　前記コンポーネント開発コントローラからの指示に基づいて、前記開発者端末から指定されたデバイスの種類に対応した所定の背景画像を前記開発者端末に表示させるとともに、前記背景画像に重ねて、開発対象の前記コンポーネントの外観を表示するためのコンポーネント開発領域を前記開発者端末に表示させるコンポーネント開発ビューと、を有し、
　開発対象の前記コンポーネントのソースコードが編集された場合に、当該ソースコードに基づいて、開発対象の前記コンポーネントを、前記開発者端末から指定されたデバイスの種類に対応した前記テンプレートによって規定される外観により前記コンポーネント開発領域に表示させる、開発支援システム。
　請求項１に記載の開発支援システムにおいて、
　前記コンポーネント開発領域は、大きさおよび／または位置を開発者の指示により変更可能である、開発支援システム。