Flex/AIR開発でデザイナとの
協業を楽にする「yui」

特集：デザイナとプログラマを“結”ぶオープンソース（前編）

クラスメソッド株式会社
渡邊 佳一
2008/10/1

RIA開発におけるデザイナとプログラマの協業問題

　昨今、Web開発では高品質なアプリケーションを短期間で開発することが求められるようになっています。またRIA開発においては、昔のWeb開発のようにプログラマが主となる状況ではなく、そのアプリケーションの性質上、デザイナの役割が重要になってきます。

　これらはさらにWeb開発を難しいものにしています。デザインはプログラマにとって敷居が高く、一朝一夕で身に付くものではありません。しかも状況に輪を掛けるかのように、RIAに期待を持ったクライアントの仕様は膨らむばかりです。

　それから、RIA開発においては「デザイナとプログラマの協業」というものが叫ばれてきました。「デザインとプログラマがお互いに自分の得意分野を出し合って、開発することでより高品質なアプリケーションが開発できるようになる」というものです。しかし現実問題として、なかなかデザイナとプログラマの協業は一筋縄でいくものではありませんでした。

　そんな中、「開発をシンプルに楽しく」というモットーを掲げて
「yui-frameworks」（以下、yui）の開発は始まりました。Adobe Flex/Adobe AIR（以下、Flex/AIR）開発における「デザイナとプログラマの協業」を実現するオープンソースのフレームワークとして、2007年7月7日にAlpha版がリリースされました。

　yuiは、クライアントサイドにおけるMVCを実現することで、役割を明確にしてデザイナとプログラマのお互いが依存しないような仕組みを作りました。しかも、単純にデザイナとプログラマが依存しないだけでなく、アプリケーションの拡張性や保守性なども考慮して作成されています。

　そんなyuiが2008年9月16日にBeta版としてリリースされました。Alpha版に比べ、さらにさまざまな機能を取り入れ、より開発をシンプルにし、完全なデザイナとプログラマの分業に近付いています。本記事では、Flex 3/AIR開発においての問題であるデザイナとプログラマの協業を可能にし、デファクトスタンダードのフレームワークとなり得るyuiについて、皆さんに紹介したいと思います。

コラム　「Flexのフレームワークといえば“Cairngorm”ってなかったっけ？」

2008年10月現在、Flex 3/AIR開発時に採用するフレームワークとして一番存在を知られているのは、「Cairngorm Framework」（以下、Cairngorm）でしょう。筆者は現在Flex技術のコンサルティングサービスを主な業務としていますが、その経験の中で顧客に採用するフレームワークを聞くと、最初に声が上がるのがCairngormになります。 しかし、Cairngormは1つのプロセスを実現するために、最低でも3つ以上のクラスを記述しなければならないなど、「開発の効率化において満足を得られるものではない」と筆者は感じています。筆者の携わる開発現場においても、積極的にCairngormを採用したことはなく、独自のフレームワークを作成し採用していました。いまのところは、「公のFlex 3/AIR開発の現場ではデファクトスタンダードとなるフレームワークは存在していない」といえるでしょう。 Cairngormの詳細は以下の記事をご参照ください。 連載インデックス「Flexのクライアントサイドをオープンソースで制覇する」 - ＠IT via kwout

「yui-frameworks」って、どんなもの？

　例に倣っていうと、yuiは「Flex/AIR開発におけるプレゼンテーションレイヤのオブジェクト指向フレームワーク」です。Flex/AIR関連のフレームワークやライブラリをSeasar2ファミリーと連携させるためのSuiteプロジェクトである「akabana」で開発されています。

　yuiを使用することによって、プレゼンテーションレイヤの役割を明確化し、デザイナとプログラマの協業を可能にします。では、具体的にはほかのフレームワークとどう違うのか、まずyuiのアーキテクチャについて解説したいと思います。

■ yuiのアーキテクチャ

　yuiでは、アーキテクチャのレイヤを以下のように定義しています。

図1　yuiのアーキテクチャ

• View
  MXMLコントロールの配置など、画面レイアウトを定義
• Action
  Viewが送出するイベントに対応したイベントハンドラを定義
• Logic
  外部インターフェイス呼び出しに対する処理やビジネスロジックなどを行う
• Service
  外部インターフェイスを定義
• Helper
  Viewに表示するデータの適用やViewの振る舞いに対する処理を行う

　Flex/AIRを利用して開発するRIAのクライアントで行うロジックには3つの種類があります。仕様に特化した「ビジネスロジック」、データを加工する「データロジック」、動的なユーザーインターフェイス（以下、UI）を構成する「ビューロジック」の3つです。

　Alpha版のyuiはシンプルな「Logic」「View」「Mode」といった役割で構成されていました。先ほどの3つのロジックの分類でいうと、Logicがビューロジック、ビジネスロジックといった2つの役割を担っており、コード量が膨大になる傾向にありました。

　Beta版では、Viewに依存する部分を「Helper」として切り出し、イベントのハンドリングを行う「Action」というレイヤを作りました。こうすることで各レイヤオブジェクトに明確な役割が与えられ、シンプルでテストがしやすくなっています。

　次ページでは、引き続きyuiの概要や、“7”つのライブラリ、“3”つの思想、“5”大機能について解説していきます。

コラム　「Flexであまり考慮されない“テストのしやすさ”」

この「テストのしやすさ」というのはこれまでのFlexフレームワークにはあまり考慮されていなかった部分です。アドビシステムズからFlex用のテスティングフレームワークとして「Automation API」なども提供されていますが、敷居が高くなかなか浸透していないのが現状です。 Adobe Flex 3 ヘルプ via kwout

1-2-3

INDEX
特集：デザイナとプログラマを“結”ぶオープンソース（前編）　 Flex/AIR開発でデザイナとの協業を楽にする「yui」
	Page1 RIA開発におけるデザイナとプログラマの協業問題 コラム　「Flexのフレームワークといえば“Cairngorm”ってなかったっけ？」 「yui-frameworks」って、どんなもの？ コラム　「Flexであまり考慮されない“テストのしやすさ”」
	Page2 コラム　「yuiを理解するのに必要な3つの設計思想、CoC・DI・POJOとは？」 分業を楽にするyuiの“5”大機能
	Page3 yui（結）でデザイナとプログラマを“結”び付けよう

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）