SSR 次世代ソフトウェアアーキテクチャ

米国調査報告書

1. 概要

(1) 目的
　　 本分野で世界で最大の国際会議であるACM主催のOOPSLA(Object-Oriented Programming,
　　 Systems, Languages and Applications)を中心に，米国の先進企業の訪問を含めて最新技術動向
　　 を調査する．
(2)調査機関
　　1999年10月31日(日)〜11月7日(日)(7泊8日，うち機中1泊)
(3)調査対象
　1) OOPSLA　'99本会議，Enterprise Applications and Object Technology Symposium,ワークショップ
　　 [Colorado Convention Center, Denver, Colorado, USA]
　2) Omni-Vista, Incと同社President & Founderの Alan Davis氏ほか
　　 [Colorado Springs, Colorado, USA]
(4)参加メンバ：下記の調査研究委員会委員
　　　　青山 幹雄(新潟工科大)
　　　　佃 軍治(日立)
　　　　中島 震(NEC)
　　　　中谷 多哉子(Slagoon)
　　　　深澤 良彰(早稲田大)

　

2. 報告内容

題名	Enterprise Application & Object Technology Symposium
発表	Bob Marcus(GM)ほか
報告	青山 幹雄
概要	ビジネスプロセスを支援するアプリケーション開発やアプリケーション統合の問題点と方法，標準化などを議論
内容	3セッションから成る1日のシンポジウムで企業アプリケーション開発の問題点を議論した．最初にユーザ企業(Shell, Lockheed Martin, Lucent, Ford)の情報担当責任者などから 問題点の提起があった．次いで，ベンダやSI企業(TSI Software, IBM, International Group)からミドルウェアを中心とする技術の現状の紹介があった．最後にOMGとOAG（Open Application Groupなど)から標準化の話があったが，報告者は最後のセッションには参加しなかった． 　ユーザからの問題点は，アプリケーション統合が中心であった．EAI(Enterprise Application Integration)が第1の問題であること．オブジェクト指向でこの問題が扱われてうない，また貢献できていないことが指摘された．特に，企業買収などによる情報システムの統合や電子商取引サービスの短期提供など，アプリケーション統合のニーズが高まっている．しかし，パッケージソフトウェアを含む粗粒度なコンポーネントの統合が問題である．新規アプリケーションの30-40％がアプリケーション統合に費やされているとの指摘があった．コンポーネント連携のためのモデル，アーキテクチャ，ミドルウェアなどの技術開発が必要である． 　これに対し，第2のセッションCORBAなどのミドルウェア，EAIツール，XMLをベースとするドキュメント交換などが紹介されたが，技術が発展途上であること，多くのインタフェースがあること，などの技術的な不確定性の高さが指摘されている．統合のトポロジも，P2P(Point-to-Point), バス，パイプライン，ハブ，ネットワークなどがある． 1. End-User Perspective 　　1.Robert Marcus (Organizer, Chief Architect, Director of Technology, GM) 　　2. Tim Thomasma (Ford) 　　3.John Leary (Lockheed Martin) 　　4. Bruce Ambler (Lucent) 　　5. David Depinet (Shell Service International) 　最初にRobert Marcusがシンポジウム開催の背景と問題の全体像を示した． 　EAIが大企業におけるアーキテクチャ上の主要な課題になっている．しかし，オブジェクト指向技術のコミュニティでは，問題として扱われていないことが問題であると提起．シンポジウムの目的は，問題を明らかにし，現在の技術をアセスメントし，議論を巻き起こすこと． 　各ユーザの代表者が指摘したキーポイントは： 　　・ E-Commerce：E-Commerce is big driving force (Ambler, Lucent) 　　・ 購入するか開発するか(Buy or Build)：最近のソフトウェア関係の文献にしばしば現れるキーワード 　　・ EAIあるいはEnterprise Integration：企業全体でのアプリケーション統合−粗粒度コンポーネント(Large grained components)の統合，ERPパッケージの統合 　　・ スイート化：Application Suite Integration(Lockheed MartinのLeary) 2. Middleware: Fitting the Pieces Together 　　1.John Leary (Lockheed Martin) 　　2.Tony Percy(TSI Software) 　　3.Don Ferguson (IBM) 　　4. Max Doglgicer (International Systems Group) 最初にJohn Learyが問題の整理を行った． 　　・ミドルウェア統合パターン：ネットワーク，p-2-p(point-to-point)，バス，パイプライン，ハブ 　　・ エンタープライズにおけるミドルウェアに対する4つの視点
感想	昨年から企業アプリケーションにおける問題として取り上げられるようになったEAIが米国のユーザを中心とする産業界で大きな課題となっていることが分った．また，このようなシンポジウムがOOPSLAで開催されることは，OOPSLAの変化の一つであろう．最初のセッションは150名ぐらいの参加者があったが，2番目ではかなり減って，問題提起をするまでに留まった感じである．

　

題名	Analyzing Object-Oriented Software Architectures[Invited Talk]
発表	Rick Kazman (Software Engineering Institute, CMU)
報告	青山 幹雄
概要	品質特性を考慮してソフトウェアアーキテクチャを設計する方法論ABAS(Attributed-Based Architecture Styles)を中心にソフトウェアアーキテクチャ設計について紹介．
内容	1. Engineeringとは 　Engineeringとは何かということをM. Shawの化学工業との対比を例に示す． 　Engineering Designとはルーチンであり，イノベーションではない． 2.品質特性を満たすアーキテクチャ設計 　システムは要求された性能，変更容易性などの品質特性(Quality Attribute)を満たすべきである． 　品質特性を分析・設計できる方法論が必要． 　この観点からデザインパターンは基礎とはなるが十分ではない． 　但し，ここでは次のように考える． 　1)分析≠オブジェクト指向分析 　 分析とは設計において外部からの刺激(Stimuli)に対する応答の特性を分析すること 　2)アーキテクチャ≠設計 　 アーキテクチャとは個々の設計より高水準な抽象化である． 3.アーキテクチャスタイル(パターン) 　 アーキテクチャスタイルは次の3つから成る 　a)アーキテクチャパターン：コンポーネントとコネクタ 　b)トポロジーや振る舞いの制約 　c)非機能的特性の非形式的記述(informal description) 　 しかし，これらを分析する方法がない点が問題 目的：アーキテクチャスタイルに品質属性をベースとするモデリングのフレームワークを与える 分析モデル： 品質属性を外部刺激(Stimuli)とレスポンスの２つをルートとするツリーとしてブレークダウンする 　 例：性能，変更容易性，分析可能性，セキュリティ，ユーザビリティ これによって，プログラムレベル設計とシステムレベル設計のギャップを橋渡しする． ABASは属性をベース(Attribute-Centric)で分析を中心(Analysis-Centric)とする． ABASの構成要素 　a.問題記述と評価基準 　b.入出力(Stimulus/Response ) 　c. アーキテクチャスタイル 　d.分析 　クライアント／サーバアーキテクチャスタイルで性能や変更容易性という属性を考慮すると同一のトポロジーであるが異なるABASがありえる． 　 性能と変更容易性を考慮すると並列パイプラインとパブリッシュ/サブスクライブを組み合せたアーキテクチャが最も良い ．
感想	ABASは第1回のSSRの研究会で簡単に紹介したが，その際に参考とした論文の事例はもっと簡単な例であった．今回の事例は，実際的であり，説得力があった． 　アーキテクチャ設計に非機能的要求を持ち込むアプローチはいろいろ提案されており，今回の事例でも，有効性が感じられる．今後，研究動向を着目すべきであろう． 　 なお，ABASについての本を執筆中で，2000年中−下期に発行の予定．

　

題名	The Objects of E-Commerce
発表	Stuart Feldman (Director, Institute of Advanced Commerce)
報告	青山 幹雄
概要	電子商取引の現状をまとめて示した．
内容	1. 電子商取引におけるソフトウェアへの要求：俊敏さ(Agility)と信頼性の両方が必要 　電子商取引におけるValue Chainの重要さ 　市場予測：2002年に1兆ドル($1T)を超える 2.電子商取引のトレンド ： 　a. ソフトウェア以前にドメインの理解が重要 　b.技術によって製造コストが相対化した：ハードウェアのコモディティ化 　c.実行モデル(Execution Model)の重要性 　d.最適ビジネス構造の変化−ビジネスモデルの特許化：法律問題はまだ明確にはなっていない 3.電子商取引における技術の意義 　a.ネットワーク：バックボーンネットワークは2.4G，今後，10GからTBへ 　b. ビジネスとしての成長発展形態 　　　電子商取引は初期の興味本位から基幹の実ビジネス(Serious Business)となった 　　　進化の速度が速いだけでなく進化が不規則(irregular)である 　　　品質と速度の両面が求められる 　　　エンド・ツー・エンドでのソリューションが求められる：手段ではなく解決が求められる 　c.電子商取引の引き起こす新しいビジネス 　　 支払(Payment)，カタログ(Catalogue)，交渉(Negotiation)，カスタマイゼーション， 　　 仮想企業体(Virtual Enterprise)，電子市場(Marketplace) 　d.品質 　　 性能と遅延，セキュリティ，匿名性，プライバシーがホットな話題となる 　　 可用性=24×７：電話と同等な運用品質のWebが求められる−99.99995%(ダウンが3分/年) 　　信頼性と機能性： 4.ソフトウェアの役割 　従来型ソフトウェア：ソフトウェア構造が組織に規定される 　新しいソフトウェア：組織構造がソフトウェアによって規定される 　変化の速度：ブローカ=日，ビジネスモデル=4-12か月，ビジネスプロセスの変更=１年 　社会／政治の変化：数年 5.変化に対応するためには 　高信頼性コンポーネント(Reliable Building Block) 　分散ダイナミックシステム(Distributed Dynamic) 　ダイナミックインターラクション(Dynamic Interaction)：インタフェースの標準化，Well-definedなインタフェース 　ダイナミックな進化(Dynamic Evolution) 　分散データの管理−テラバイトデータ(10-100TB)の共有 　すでにマルチテラバイトデータを扱うシステムがある 　分散ビジネスの管理：仮想企業体，マーケットプレースが電子商取引の次の大きな課題 6.ビジネスプロセスの設計 　ビジネスプロセスの設計とプログラミング，組み合せとSequencing：例＝オークション 7.電子商取引のオブジェクト(Object of E-Commerce)−まとめ 　Basic Object：Make Money 〜>ここが落ち？ 　Technical Object：ビジネスモデル，ビジネスプロセス 例：粗粒度のプロセス(Coarse Grained Process)，支払，支払管理(Payment Gateway)，カタログ，仮想カタログ， コミュニティサービス，プライバシーサービス，サーチ，ワークフロー&データフロー管理， ドキュメント管理，マーケットプレース(交渉，オークション，ブローカ，交換)
感想	電子商取引のビジネス的な側面について要領良くまとまっていた．ただ，OOPSLAの講演としては技術的な内容に乏しかった．変化に対応するためのダイナミックなアーキテクチャや進化など，本WGの研究テーマを支持する指摘があった．

　

題名	GUIアプリケーションのオブジェクト指向開発の実践
発表	下記の内容に示す
報告	深澤 良彰
概要	“Practitioner Reports”の３セッションからGUIに関するセッションで発表された３件の発表について，概観する．
内容	A.L.Lovejoy and F.M.Mervine “Jaguar : A UI Framework for Java” 　GUIアプリケーションにおいて，処理内容を表すモデル，ユーザに対する表示を行うビュー，ユーザからの入力を扱うコントローラを明確に分けるべきであるというMVCアーキテクチャは，古くから有効性が強調されてきている．しかし，実際には，その分離が不十分であることが多い．本論文では，その分離が不十分な例として，AWT/JFC UIフレームワークを挙げている． 　これに対して，ProtocolAdapter，ViewAdapterと呼ぶ２層をモデルとUI（ビュー＋コントローラ）との間に置くことによって，完全な分離をはかろうとするアーキテクチャについて，その詳細が述べられている． B.Tophoven and P.Kreuser “Integrating an OO Aplication in a Non-OO GUI Environment” 　メインフレームベースの非オブジェクト指向言語（たとえばCOBOL）で書かれたレガシーアプリケーションに対して，クレジットカードを処理する機能をオブジェクト指向GUI上に実現し，両者を結合した時の考え方が述べられた．ルフトハンザで行われた開発の経験の発表であった． B.Schulthesis and M.L.Fussell “Leveraging Quality, Migrating a Mature High-level GUI Framework to Java” 　データウェアハウスのためのOLAP(Online Analytical Processor)を開発した時に，既存のJavaライブラリ（具体的に何を検討し，何を使ったのかは不明）には，UI層とドメイン層の明確な分離ができなかったので，UIフレームワークを新たに構築した経験が述べられた． 　この基本的なアーキテクチャは， 　 ・オブジェクトとその値を保持し，値の変更を他のオブジェクトに通知するValueModel 　 ・オブジェクトの属性をもつValueModelであるAspect 　 ・Aspectを調べる機能をもつAspectContainer 　 ・ドメインオブジェクトの属性とValueModelの属性を結合するPresenter から構成されている． １件目のJaguarと同じように，UIとアプリケーション本体から明確に分離することが目的である．
感想	“Practitioner Reports”という３つのセッションでは，合計９件の発表が行われた．いずれも30分のプレゼンテーションで，予稿は２ページである．このようなセッションの目的は，実務の経験を実務者に話し，今後の開発のために役立てるということであろう．2000名を越えるOOPSLA99参加者の8割以上は，研究者ではなく，実務に携わっているエンジニアであろうから，このようなニーズは高いはずである． 　 しかし，このような発表に必要な条件は，適用可能な環境が明確にされ，経験の結果が，綿密かつ理性的に評価されていることであると思う．経験だからといって，単に「こんなことしました！」というだけでは，学術的には「当たり前」，実務的には「我が社で使えるかどうかわからない」ということになってしまう．残念なことに，本セッションの３件の発表では，「こういう場合に，こうしました」，「こういういうソフトウェアを作りました」という域をでていないのが残念であった．

　

題名	チュートリアル “Testing Object-Oriented Software Systems”
発表	J.D.McGregor (Clemson Univ), M.L.Major (Software Architects)
報告	深澤 良彰
概要	オブジェクト指向開発技術を用いて開発されたアプリケーションソフトウェアをテストする技術・プロセスについてのチュートリアル
内容	まず，CMM，品質，UML，ライフサイクルなど基本概念についての整理が行われた． 　続いて，テスト作業そのものの分析が行われ，Risk, Frequency, Criticality の3つの視点のバランスに基づいたテストの重要性が強調された． 　 次に，プロジェクトの初期段階で行われるテストの１種として，レビューの重要性とその効果が述べられた． 　 下流工程のテスト法としては，ユースケース（シナリオ）の説明が行われ，そこからのテストデータの作成法について述べられた．この部分が，このチュートリアルの主眼であったと思われる． 　 上記以外に，HIT，PACT (Parallel Architecture for Component Testing)，OATS (Orthogonal Array Testing System) ，JUnitなどの研究レベルのものや具体的なテストツールの説明も行われた．
感想	テストは古くて新しいテーマである．新しいソフトウェア技術が発表されると，それに対応したテスト技術が発表されてきた．オブジェクト指向もその例外ではなく，オブジェクト指向プログラミングの普及とともに，そのテスト技術も研究され，発表されてきた．”Object Oriented Software Testing : A Hierarchical Approach” (S.Siegel et.al.，邦訳あり)，“Testing Object-Oriented Software” (D. C. Kung)，”Testing Object-Oriented Software : Life-cycle Solution” (I. Bashir，近刊) など書籍となっているものもある． 　オブジェクト指向がもつ（と言われている）特徴に，シームレスな開発がある．オブジェクト指向分析・設計・実装と，抽象化/具象化の反復的な適用によって開発を行うことができるということを意味している．こうなっていれば，要求仕様書，設計仕様書，プログラムとの間には，密接な関係付けが可能であり，ホワイトボックス型の良いテストケースが，各種仕様書から生成できるはずである． 　このチュートリアルの内容もこの一貫であった．50名ほどの参加者の中で，研究者は私を含め2名だけであり，実務者にとっては重大な問題と捉えられていることを強く感じた．

　

題名	Workshop on Multi-Dimensional Separations of Concerns in Object-Oriented Systems
発表	Harold Ossher (IBM Watson)ほか
報告	中島 震 (NEC)
概要	分割に関する異なる複数の視点を取り扱う技法について議論する．特に，複数視点の整理，独立に考えることが可能な視点，視点間の相互作用，等について議論する．
内容	○ MDSoC (Multi-Dimensional Separation of Concerns) 　 AOP (ゼロックス PARC)，SOP (IBM)，等の研究者が中心となって開催したワークショップ．プログラミングレベルが中心であるが，開発上流工程まで範囲を広げて議論． ○ MDSoCの基本概念 　 基本的な概念と用語についてコンセンサスを得ることが目的 　 - Artifact : 開発過程で生じる生成物．要求記述，設計モデル，プログラム，等 　 - Unit : Artifactの構成要素．記述形式，記述単位の大きさ，等が影響． 　 - Concern : ソフトウエアに関して，着目している「視点」． 　 - SoC (Separation of Concerns) : 同じconcernに対応するUnitを明示すること． 　 - Module : SoCを行なって単一の (主要) Concernに対応するUnitの単位． 　　　Artifact記述形式を持つことが多い． 　　　Moduleという用語の使い方について，Ungarが強く反対していた． 　 - Cross-Cutting Concenrs : Moduleを形つくる (主要) Concernにまたがる新たなConcner 　 - Cross-Cutting Modules : Cross-Cutting Concernに対応．記述形式がない． 　 - Synthesis : Composition，Weaving，等ともいう． 　 - MDSoC : Cross Cuttingに焦点を絞る．SoCからみると高階の概念． ○ MDSoCを支援する(プログラミング言語)機構 　 - プログラムコードレベルの concernを対象とした議論．すなわち，Artifactがソースプログラムである場合を対象． 　 - MOPベース自己反映計算では，ベースとメタの1段階分割が基本．複数のCross Cutに対応しようとすると，メタとベースが混合して見通しが悪くなる．つまり，メタレベルからベースレベルへの参照が繁雑になる． 　 - Concernの表現形式が必要．現状は，主要Concernを一つ選び，他は二次的なConcernとして扱う． 　 - コードを基本操作からなるとする場合，複数のConcernに対応することがある．コード断片が複数の設計上の決定に依存するということ． 　 - 事例として，ユーザ要求をConcernとし，Concern (ユーザ要求仕様)を実現するプログラムをオブジェクト指向フレームワークとして開発．フレームワークを動的にロードすることで，動的なConcner変更を可能とする研究がある．Concernのプログラムへのマッピング等が課題． ○ Concerns 　 - 具体例を通して，concernの種類を議論． 　 - GNUライブラリ (C++) のsortingプログラムを対象として，どのような concernから構成されるかを調査．約70個のconcernを抽出した．これは，functional capabilityと呼べるものである． 　 - Javaで記述したアプリケーションを対象として，複数の学生が独立にconcernの抽出を行なった．(1) 8つ程のconcern(feature : 機能) が得られた，(2) 作業者に依存して異なる concernが得られた．得られた結果をプログラム・モジュールの再設計に生かした． 　 - その他，問題領域概念・用語を concernとすることもある． ○ 開発プロセスにおけるMDSoC 　・ CatalysisやRational (4+1)の開発プロセスモデルで用いる各種設計ドキュメントを concern と呼ぶこともできる． ○ ホームページ http://www.cs.ucb.ca/~murphy/multid-workshop-oopsla99
感想	- Concernを明示的に取り扱うことの目的は? 　　 TraceabilityとDecompositionの2つの役割が特に有効と思われる． 　 - 開発プロセスの「どこに」Concernが現れるのか? 　　waterfall型 (分析モデルが設計モデルのconcernを与え，設計モデルがコードのconcernを与える)と，独立型 (分析/設計/コードを通して同じconcernが関連する)の2つの考え方があり得る．従来のAOPでは，コードレベルしか考えていないので，この2つの考え方に区別がない． 　- Concernは明示的な表現形式を持つべきか? 　 明示的な表現形式があると，concern間の相関，等の議論がしやすくなる．一方，ilitiles (性能，等)を，どのように表現すべきか不明なことが多い．concernの性質・種類に応じて考えるべきか． 　 - Concernの適切な大きさはどのくらいか? 　Concernを抽出することの目的に応じた最適な大きさがあると思われる．Traceabilityを目的とする場合は細かくなる傾向があるが，Decompositionの場合はある程度の大きさが相応しい．

　

題名	Objects and Agents : Convergence, Compromise, or Collision?
発表	Grosof (IBM Watson R. C.), McCabe (Fujitsu USA)，Arnold (SUN)
報告	中島 震 (NEC)
概要	エージェント技術の現状を概観し，オブジェクト技術との関連を3つの視点から議論する．
内容	エージェント技術の現状を概観し，オブジェクト技術との関連を3つの視点から議論する．(1) Convergence (両者は統合する)，(2) Compromise (異なる技術であるが共通する部分がある)，(3) Repulsion (全く異なる技術である)．特に，CORBAのような分散オブジェクト基盤とエージェント技術の関連，ならびに今後の標準化について議論する． ○ エージェント技術概観 　 - NASA Deep Space One Remote Agentが良い成功例 　 - ネットワーク管理，E-Commerce，DB統合，等が良い応用 　 - エージェント技術は「オブジェクトよりも高い レベルでのデザイン概念」という見方もある． ○ McCabeのポジション 　- 知的エージェントこそが重要 (Cognitive Agents) 　- Cognitive Agentsをベースに，より高度なTalktive Agentsの コミュニティを作っていく． 　- システム構築の基礎は並列オブジェクトモデル ○ Arnoldのポジション 　 - 分散AI，アクティブ・コンポーネント等でいう自律性が重要 　 - (SUNの立場としては) ポストPC世界がエージェント技術の時代である． 　 Jiniのような自己編成 (self-configuraion)で有用． ○ Grosofのポジション 　 - エージェントは3つの側面を持ち，Medeatorである．3つの側面とは， 知的 (AI)，経済上の決定者 (E-Commerce)，分散エンティティ (移動性)，である． 　 - ネットワーク管理，E-Commerce，DB統合，等が良い応用 ○ 質疑応答から 　 - セキュリティの問題がある筈 　 - 開発方法論について，既存オブジェクト指向技術が使えるか? 　東芝の移動パターンに関する研究事例がある．今後の課題であろう
感想	- パネラ3人とも，OMG Agent-TGのメンバ． 　先日のFIPA川崎会議 (10月18日 - 22日)で，これまでのFIPA路線を大幅修正する方向を打ち出した主要メンバらしい． 　 (1) エージェントは「知的」であらねばならないということ， 　 (2) 分散システムの基盤にエージェント概念を持ち込もうということ， は本来独立な議論であろう． 　 - 「知的」という側面を強調するがために，「移動エージェント」は特に議論しないという雰囲気を作っている．一方，(2)の観点からは，分散システムの中で，何らかの「コード移動」を行なうことは有用である． 　 - まとまりのない内容であった．本パネルの目的は，「路線変更中のFIPA」を宣伝することだったのだろうか?

　

題名	Is UML Also an ADL?
発表	D. Coleman (HP)，D. Garlan (CMU)，C. Kobryn (EDS)，G. Booch (Rational)，S. Iyenger (Unysis)，D. D'Souza(ICON Computing/PLATUNUM)
報告	中島 震 (NEC)
概要	UMLの現状と今後をADLという観点で見直す．
内容	○ オブジェクト指向システム開発技法 として重要になっているテーマにソフトウェアアーキテクチャがある．一方，開発技法の基礎となる設計記法としてUMLが標準化されている．では，UMLでソフトウェアアーキテクチャを中心とした開発を行なうことについて，どのような問題があるのであろうか? ○ David Garlan 　 - ソフトウェアアーキテクチャ (SA) は，要求とコードのブリッジとなる．ここで，要求はオブジェクト指向モデルで表現され，コードはオブジェクト指向プログラミング言語で作成される．SAでは，「オブジェクト」バイアスは，どのように作用するであろうか? 　 - SAの特徴 : 互いに関連するコンポーネントからなること，種々の Ilities が重要であること，要求とコードをつなぐ理由つけを与えること，将来の変更を扱うこと． 　 - UMLとの関係 : コネクタをUMLでどのように表現するか，SAの表現物を解析するということについてUMLの解析技術で十分か． ○ Chris Kobryn 　 - UMLをADLとしてうまく使うためにどのようにすべきかを考えたいが，依然としてSA自身が未熟な技術である． 　 - SAにも，エンタープライズビュー，分散コンポーネント，特定ドメイン，等の考え方がある． 　 - SAの技術は開発プロセス依存であり，しかもグレインサイズの大きな方が有用である． 　 - 現在，UML 1.3を作業中であり，UML RTF として Architecture WGを設けて検討している． ○ Grady Booch 　 - Rational社では，例の 4+1がソフトウェアアーキテクチャである． 　 - 現実的なソフトウエアシステムでは，コンポーネントが階層的になることはあまり重要でない．むしろ，複数ビューが重要(だから 4+1)． 　 - 4+1の各ビューをUMLで記述すればよい． ○ Iyenger 　- CORBA Componentモデルでは，従来IDLで行なっていた記述をUMLで行なう． 　- CORBA/ORBはconnectorに相当するが，他のモデル化もあり得る． ○ D'Souza 　- SAはインプリメンテーションの抽象的なビューである． 　- SAをスタイルの集まりとして見る．たとえば，JavaBeansスタイル，並列スタイル，オブジェクト関係モデル，機能要求スタイル，等がある． 　- 各々のスタイルをUMLで表現することが概ねできる． 　- UML 1.3のように，UML記法を2層化する方向では，各スタイルをコアで表現できれば良い (還元主義)． ○ その後の議論から 　- 非機能要件はUMLで表現できない．解析性のある記述形式が欲しい． 　- SAでは，ビューあるいはトレーサビリティが重要．問題領域ドメインごとにビューが異なる． 　- 現状のADLは特定の目的 (ビュー)を想定することが多い．現実のソフトウェアのように複数ビューに対応するためには，ADLのセマンティックス上の統合が問題となる． 　- CACMの11月号にUMLをアーキテクチャ記述に適用した成功例がある．
感想	- とてもわかりやすく面白い議論であった． - 何をソフトウェアアーキテクチャ(SA)とするか，SAを表現するということは何か，ということが未解決である．SAを明示することのご利益が何かをはっきりさせないと上記の問題はみえてこない．やはり，開発過程モデルと強い関連にある技術という印象を持った． - UMLで表現できるか，という問題はあまり興味あることではない．本パネルの主旨も，「UMLの現状をADLという観点で見直す」ということと思う．実際，UML 1.3で進行中の2層化では還元主義にたって，アーキテクチャあるいはスタイルを表現するコアを検討中と聞く．その結果，SAをUMLで表現することが可能になり，UMLの守備範囲を広げることができる．しかし，そもそもの問い「SAのご利益は?」ということには答えない．やはり，「SAは開発プロセス依存」ということで，記法を定義するUMLからは，うまく排除するということなのであろうか?

　

題名	Java Optimization 1
発表	下記の内容に示す
報告	中島 震 (NEC)
概要	下記の内容に示す
内容	1.Escape Analysis for Java 　発表：M. Gupta (IBM Watson R. C.)ほか 　概要：プログラム依存グラフ上の到達解析によるEscape解析．解析結果を利用してコンパイラコードの最適化． 　内容： 　○ Escape解析 4件の第1件目． 　○ Escape解析とは？ 　― メソッド内で生成消滅が完結し外部に出ていかないオブジェクトを静的解析によって求めること．method-local― synchronized宣言されたオブジェクトであって，複数スレッドから参照されないオブジェクトを静的解析によって求めること．thread-local 　○ Escape解析を行なう目的は（応用は）？ 　― method-local → オブジェクトを特殊領域 （スタック）に割り付ける． 　 通常のヒープに割り付ける方法だと，ヒープが複数スレッドの共有資源であること，オブジェクト生成消滅に伴うGC処理を行なうこと，等から実行性能が落ちる． 　― thread-local → synchronizationを削除することができるので，実行性能を向上できる． 　○ JavaのEscape解析の基本手法は？ 　 ― 大域的に参照可能なオブジェクトであること，メソッド起動の実引数として外部に出ていくオブジェクトであること，を決定する． 　 (1) 解析手法: Escape解析向けに考案したプログラム依存グラフ上の到達解析技術． 　 (2) 入力: クラスファイル (JVML) 　 (3) 最適化の実現: IBMのJavaコンパイラ (HPCJ)で利用し，生成コードを最適化． 　 (4) ベンチマーク結果: 　新規生成オブジェクトの70%がmethod-local，11%から92%をロック削除可能 (単一スレッドのアプリケーションを対象)，全体で2%から23%の性能向上 　 thread-local解析について，flow-sensitiveな解析とflow-insensitiveな解析との両方を行ない比較．両者で有意な差がないことを示す． 2.Escape Analysis for Object-Oriented Languages. Application to Java 　発表：Bruno Blanchet (INRIA Rocquencourt) 　概要：抽象解釈に基づくEscape解析．解析結果を利用してコンパイラコードの最適化． 　内容： 　 ○ Escape解析 4件の第2件目． 　(1) 解析手法: Cousotの抽象解釈に基づく解析技術．副作用の扱いを工夫． 　(2) 入力: クラスファイル 　(3) 最適化の実現: SilicompのJavaコンパイラ (TurboJ)で利用し，生成コードを最適化． 　(4) ベンチマーク結果: 　 13%から95%がmethod-local， 20%以上 (最大99%)をロック削除可能 (単一スレッドのアプリケーションを対象)，全体で44% (平均21%)の性能向上 ． 3.Removing Unnecessary Synchronization in Java 　 発表：Jeff Bogda (UC Santa Barbara) 　 概要：synchronization除去に特殊化したコンパクトな手法．解析結果を用いてクラスファイルを最適化変換．JVM上で実行可能． 　内容： 　○ Escape解析 4件の第3件目． 　synchronization除去に特殊化することで，4つの研究の中で最も小さい計算量の手法を実現． 　 (1) 解析手法: 制約ベースで行なうflow-insensitiveな解析技術． 　 (2) 入力: クラスファイル 　 (3) 最適化の実現: クラスファイルの書き換え 　 (4) ベンチマーク結果: 　最大で90%のロック削除可能(単一スレッドアプリケーションを対象)，20%-36%の性能向上 　 Java解析の基盤ツールとしてOSUIFを用いている．
感想	最適化の実現手法 (クラス改変)が怪しそう．元のプログラムと等価か?

　

題名	Java Optimization 2
発表	下記の内容に示す
報告	中島 震 (NEC)
概要	下記の内容に示す
内容	1.Compositional Pointer and Escape Analysis for Java Programs 　発表：John Whaley (MIT) 　概要：プログラム依存グラフ上の到達解析技術．解析結果を利用してコンパイラコードの最適化． 　内容：Escape解析 4件の第4件目．4つの研究の中で最も計算量が大きいが汎用的な手法． 　(1) 解析手法:プログラム依存グラフ上の到達解析技術．Kildall流データフロー解析手法を適用． 　(2) 入力: クラスファイル 　(3) 最適化の実現: IBMのJavaコンパイラ (Jalapeno)で利用し，生成コードを最適化． 　(4) ベンチマーク結果: 　 22%から95%がmethod-local，24%から67%をロック削除可能(単一スレッドアプリケーションを対象) 　感想： 他の応用にも使うことを想定している表現を採用しているので，今後の拡張に興味あり．IBM WatsonのJalapenoグループと交流あり． 2. An Efficient Meta-Lock for Implementing Ubiquitous Synchronization 　 発表：Ole Agesen (SUN Microsystems) 　 概要：SUN JDK1.1.1のモニターキャッシュによる方法の問題(間接参照による実行効率低下)を解消する手法を提案する． 　内容： 　 (1) 表現 : オブジェクトごとにメタロック (2ビット) と，詳細情報 (ロックレコード or モニター) へのポインタを持つ．メタロックはモニター獲得のためのロック． 　(2) synchronizedのロック処理は，メタロックの獲得を行なってから，モニター獲得を行なう，という2段階方式．contentionが生じた時は，メタロックのロックレコードに待ち状態として格納されるので，busy waitが不要 　(3) アトミック操作 : メタロックのlock/unlock 　(4) その他 : SPARCアーキテクチャに最適化 　感想： Sun Microsystemsからの本当のリリース版には，HotSpotでの手法が入るらしい．「SPARCアーキテクチャに最適化」というところがネックなのでしょうか? 3. A Study of Locking Objects with Bimodal Fields 　 発表：小野寺 (日本IBM) 　 概要：IBM Watson R. C.のthin-lockによる方法を改善する手法を提案する． 　内容： 　 Thin-lockの問題点 (競合するスレッドはbusy wait，deflationがない)を解決する tasuki lockを提案．Thin-lockの仮定 (contentionの局所性，長時間占有は少ない)を満たさないマルチスレッドで作動するアプリケーションに対しても実行性能が落ちないことを目指す． 　感想： 既存の研究の多くが，単一スレッド・プログラムを対象とする性能向上で良しとするのに対して，大規模なマルチスレッドAPでの評価でも良い結果が出ているので，気持ちの良い研究．
感想

　

題名	Implementation Experience
発表	下記の内容に示す
報告	中島 震 (NEC)
概要	下記の内容に示す
内容	1. Practical Experience with an Application Extractor for Java 　発表：Frank Tip (IBM Watson) 　概要：不要なライブラリ機能 (Dead Method, Dead Field等)を削除するツールJAXを報告． 　内容： 　Javaを含むオブジェクト指向言語ではプログラムの一部としてライブラリが重要である．機能の高い豊富なライブラリがあると，プログラム作成の手間が軽減できる反面，すべてのライブラリをリンクするプログラムは不必要に規模が大きくなる．そのため，ライブラリから本当に必要な部分だけを抽出する解析機能が必要になる．特に，Javaの場合，クラスロード機能を使う場合に，転送対象プログラムの大きさが転送時間に影響を与えるので，この種の抽出は重要． 　 静的な解析により不要なライブラリ機能 (Dead Method, Dead Field等) を削除する．削除した結果，クラスの構造や階層関係 (スーパーとサブの融合，等)を変更する． 　 クラスファイルの書き換えにより，ZIP形式で平均50%(13.4%から90.2%)を削減した． 　感想：用いている静的解析技法の詳細は不明．ちょっと怪しいところもありそう．JAXはIBMの Alpha worksから入手できる． 2.A Performance Evaluation of the Mobile Agent Platform 　 発表：D. Hagimont (INRIA) 　 概要：Javaベースの移動エージェントとRMIベースのクライアントサーバ型分散システムの実行性能を比較して，移動性が有用であるとする． 　内容： 　 移動性が有効と考えられる分散システム形態を対象に，同様機能をRMIで作成した場合との比較によって，移動エージェントの性能的な有効性を実証する．測定対象の例題は， 　 (1) 複数サイトのサーバ巡回 　 (2) データコンプレス・プログラムの移送によるクライアント/サーバ間通信最適化，である ． 用いた移動エージェントシステムは，Agletsと自前の最小システムである．AgletsはATP (移動プロトコル)の処理負荷が高いので遅い． 　国際的なインターネット (フランス，英国，スイス) を利用して性能測定を行なった． 感想：移動エージェントというよりも，移動コード(上記の(2)の応用)を想定しているらしい． 3. Implementing Jalapeno in Java 　 発表：Bowen Alpern (IBM Watson) 　 概要：コンパイラベースのJava処理系Jalapeno開発に関する逸話． 　内容： 　 サーバ用高速Java処理系を，コンパイラベース (JITでない) で開発．ターゲット環境は，PowerPC/AIXに限定．Javaによって処理系を記述したことが特徴 (Java-in-Java)．マルチプロセッサ対応でもある．クラスローダによる動的ロード機構もサポート． 　システム開発はブーツトラップ的に行なう． 　 (0) イメージファイルを読み込み実行する boot image runner(C言語+アセンブラ)を開発． 　 (1) Java compilerと最小機能を持つboot image writerをJavaで作成する． 　 (2) (1)と既存JVM上で作動させる．特に，(1)自身を「コンパイル」する． 入力はクラスファイルである． 　 (3) (2)と(0)を用いると，コンパイラの実行イメージを「実行」できる． 　 (4) (3)のコンパイラを用いて，(1)を拡張して作成したフル仕様Javaシステムをコンパイルする．Javaで開発できるので生産性が高い．JDKが持つ標準ライブラリの全て(native methodを含む) Javaで書き直す． 　(5) (4)のコンパイル結果のイメージファイルを(0)で実行するとフル仕様のJavaシステム (Jalapono)が完成する．計算機上での実行イメージを得るためには，Javaが持つタイプでは扱いきれない，メモリアドレス等を表現する必要があった． 　 感想：Javaのコンパイラとして非常に面白い．Jalapenoの技術内容に関する説明とシステム記述言語としてのJavaに関する感想が混合した発表でわかりにくかった．
感想

　

題名	Formal Specification
発表	下記の内容に示す
報告	中島 震 (NEC)
概要	下記の内容に示す
内容	1. Featherweight Java : A Minimal Core Calculus for Java and GJ 　 発表：五十嵐 淳 (東大，Univ. Pennsylvania) 　 概要：Javaのためのミニカリキュラス FJの提案 　 内容： 　 B. Pierce，Phil Wadlerとの共同研究． 　Javaタイプシステムの特徴を取り込んだカリキュラスの提案，クラスはプリミティブ（Cardelli/Abadiのような構造サブタイプでない），subject reduction theoremが成立する (Javaでは成立しない．実行時チェックが必要．)．種々の拡張言語をFJにコンパイルすることで厳密な議論を行なう．実際，Pizza（GJ）に対して適用したら，rawtypeに関連して不良が見つかった． 　 SUNが次期Java言語仕様の拡張として，Pizzaで提案した ジェネリックを入れようとしているので，言語仕様に誤りがあってはならない．今回のFJによる厳密な定義の試みは，重要なアプローチである． 　 感想： FJは，理論家好みの単純なもの．それでも，Pizzaの問題点を指摘できる等，面白い． 2. A Formal Specification of the Java Bytecode Language and Bytecode Verifier 　 発表：Stephen N. Freund (Stanford Univ.) 　 概要：JVMバイトコード・ベリファイアのためのタイプシステム．Stanford大学のMitchelグループによる一連の研究の総括的な報告． 　内容： 　 JVMバイトコード・ベリファイアのためのタイプシステム．ベリファイアアルゴリズムの厳密化が目的．なるべく，JDKの方法に忠実でありかつ厳密にすることで，商用システムのための参照モデルにすることを狙う．今までの一連の研究を集大成し，JVM仕様のほとんどすべて含むことが特徴．特に，サブルーチン，配列，初期化，等を扱える． 　感想： 他の論文で述べた成果の要約的な内容なので細かい議論がわかりにくい．
感想

　

題名	Omni Vista社 訪問
発表	Alan Davis (CEO, Omni Vista)ほか
報告	中谷 多哉子
概要	下記の内容に示す
内容	1)プロジェクト管理ツールのデモと説明 　 ツール概要： 　・Featureから要求（要件）、要件に対する優先度、難易度、見積もり工数の対応付けを行い、予算とシステムに取り込む要件の計画立案を行う。 2)企業コンセプト 　 ・経理担当，技術担当，マーケティング担当の共同作業によってシステムの仕様を決定する． 　 ・システム開発における共同作業プロセスは以下のようになる．すべての作業はインクリメンタルに進められ，マーケティング担当と顧客によって最終的な要件定義と開発計画が立てられる． 　 i．マーケティング担当は，顧客と対話を行って顧客がシステムに求めるFeatureを決定する． 　 ii．技術担当はマーケティング担当が提示する顧客のFeatureに対する問題解決手段としてシステムの要件を導き，顧客のFeatureに対する要件の妥当性をマーケティング担当と話し合って，システム要件案を作成する． 　 iii．システム要件案に対して，技術担当は開発工数と開発に必要なリソースを見積もる． 　 iv．マーケティング担当は，顧客とともに，求めるFeatureの優先順位を与える． 　 v．技術担当は，優先順位に基づいた開発計画を立案し，リソース面での実現可能性を経理担当と話し合う． 　 vi．求められた実現予測に対して，マーケティング担当，経理担当，技術担当は，顧客とともに，開発計画の見直し，優先順位の再評価を行う． 　 vii．技術担当は，顧客とともに要件の競合状態を検討し，解消する． 3)事業内容の特徴 　 視覚的にリソース配分とシステム開発内容との関連を示すことが可能である．ツール上で示される要件は顧客が求めるシステムのFeatureに対して定義されるのであって，顧客がシステムの機能要件を示すのではない．Featureとはシステムが問題解決した世界の特徴を意味する用語である．要件はFeatureを実現するための手段であり，技術的な観点から決定すべき事柄であり，顧客やマーケティング担当は検討できないという立場が取られている． 　 ツールでは，各要件に対する属性は顧客ごとに追加削除が可能である．以下にツールの概観を示す．ここに示された４つのビューのほかにもプロジェクトの視点が提案されており，各視点で描かれたグラフを参照することができる． 　図１　Omni-Vistaの全体図 　図２　要件定義と見積もりの画面 4)その他：要求管理ツール 　 Alan Davisは要求定義ツールとしてRational Softwareが販売しているRequisitionというツールを開発した．このツールは，Feature，要件，ユースケース，サブユースケースの依存関係を管理し，顧客のが提示するFeatureが変化したことによる影響分析が可能となっている．個々の項目の関連は親子関係や詳細化/抽象化，参照関係などを自由に開発者が定義できる．また，他のRational Softwareのクラス図，シーケンス図などとも関連付けが可能であり，システム開発の上流から下流までの開発項目の変更による影響分析ができるようになっている．さらに，影響があると判定された項目は表を用いて視覚的に識別可能な表示がなされ，影響内容の確認と未確認の状態も表に示される． 参考資料：Requisition(www.rational.comからダウンロード可能)
感想	要求工学はやっと日本でも活性化し始めた（？）分野である．Alan Davisの翻訳を行わないかといわれたが．．．日本出版用に特別な章を新たに付け加えることも可能であるとの提案も受けた． 　 今回の会談での収穫は，Featureという用語の意味と使い方である．日本語に訳しやすい言葉ではないと思ったが，完成したシステムが満たすべき特徴と解釈すると理解しやすいかもしれない．顧客には要件を定義させないという考えが，日本でも現実的であるかどうかはともかく，FeatureとRequirementsとの差異を意識した要求分析は重要であると思われる．

　

題名	Responsibility-Driven Design: Practical Techniques for Modeling Object Behavior
発表	Rebecca Wirfs-Brock and Alan McKean
報告	中谷 多哉子
概要	半日のチュートリアルで，責任駆動型アプローチの方法論の説明と演習があった．
内容	責任駆動型アプローチは，システムの振る舞いや責任に基づいてオブジェクトを抽出する方法論として位置づけられている．演習ではユースケースとCRCカードを用い，以下の例題からオブジェクトの抽出を行い，抽出されたオブジェクトを抽象化してクラス図を作成した．また，簡単なメーリングシステムをもとに，Abstract FactoryパターンやStateパターンを用いたクラス図の洗練化の演習もあった． ・例題 　 交通事故にあい，瞬きによる意思表示しかできなくなった高齢者の会話支援システム．１語の単語や特定された文字に続く文字を頻度の高い順に提示するなどの機能を持つ． ・モデル概要 　 システムのアーキテクチャはUI，コントローラ層，エンティティ層といった階層型アーキテクチャが取られると説明された． ・CRCカードにはオブジェクトの名前，責任，協力オブジェクト，属性を記述する． ・方法論評価 　 「R. Sharble and C. Cohen: “The Object-Oriented Brewery: A Comparison of Two Object-Oriented Development Methods,” Software Engineering Notes, Vol.18(2), pp60?73」に，データ駆動型方法論と責任駆動型方法論の比較を定量的に行った結果が発表されている．この論文の結果を用いて責任駆動型の方が定量的に望ましいモデルを構築できる点が示された． ・データ駆動型によって定義されたモデルも，モデルの洗練によってより好ましいモデルに再構造化できることが示された．再構造化には，Abstract FactoryパターンやStateパターンを適用した例が示された．
感想	内容が多すぎて時間が足りなかった．チュートリアル参加者のほとんどがUMLを用いている技術者であり，講習はあまり効果的であったとは思えないが，方法論全体の流れや，分析者が異なっても同じようなオブジェクトを抽出することがよくわかった．責任駆動型設計法は有名であり，文献も読んでいたので今回のチュートリアルによって新しい情報は得られなかったが，方法論の解釈に誤りがなかったことは確認できた．責任駆動型方法論の講習の進め方は参考になった．

　

題名	Usage-Centered Design with Essential Use Cases
発表	James Noble and Larry Constantine
報告	中谷 多哉子
概要	下記の内容に示す
内容	ユーザ中心のユースケースは従来のユースケースとは違うことが強調された． 　従来のユースケースはシステムの振る舞いや機能を記述するものであるが，ユーザ中心のユースケースには，システムがユーザのために何をするかを記述し，どのようにそれが達成されるかは定義されない．Alan Davisらが言うFeatureに相当する考え方であると思われる．Alan DavisのFeatureに対して「User Intention」，Requirementsに対して「System Responsibility」が対応付けられると思われる． 　Usage-Centeredという題が示すとおり，チュートリアルの内容は一貫して，「利用者にわかる言葉とはどのようなものか」が強調されており，抽象化された概念を用いたユースケースやシナリオの記述は厳しく批判された．従来のUseCaseに対して次のような批判もあった． 　 　 i．従来のユースケースはオブジェクト指向ではない．なぜならば，システムと利用者の相互作用が時系列で示されているだけである． 　�A．インタフェースがシステムのすべてと考えられている． 　�B． どのようにシステムとユースケースは結びつくのか 　�C．ユーザが興味を持っているのは問題領域のオブジェクトであるが，ユースケースのどこにオブジェクトがいるのか． Usage Centeredでは，次のような記述となる． User Action System Response カード投入 カードを読む PIN要求 PIN入力 PIN確認 オプションメニュー表示 キーを押す アカウントメニュー表示 キーを押す ．．． これを書き直して，必須ユースケースを記述すると次のようになる． User Intention System Responsibility 識別する 識別子確認 選択肢の提示 選択する お金を与える お金を得る 　ユースケースにはユーザの役割に着目してユーザの動作とシステムの応対を記述する．その後，類似ユースケースを分類し，具体的なユースケースを必須ユースケースに簡潔に書き直して一般化する．
感想	ユースケースの最新動向の情報収集を行うために参加したチュートリアルであったが，１枚のスライドに１５行以上も書かれると内容が把握できなくなる．何を言おうとしているのかわからなかったが，ユースケースの抽象化については議論されており，じっくり内容を吟味するとそれほど期待外れのチュートリアルでもなかったようだ．コンスタンチンが強調しているのは，ユースケースをいきなり書くのではなく，利用者のシステムを会した行動を吟味したうえで，システムに期待する利用者の意図に対するシステムが提供する責任の意義を把握せよということである．この過程では，あらゆる資料に目を通せといった問題領域分析に関する作業も要求されるようである．

　

題名	Subject and Aspect
発表	下記の内容に示す
報告	中谷 多哉子
概要	下記の内容に示す
内容	Siobhan Clarke, William Harrison, Harold Oshher and Peri Tarr 1. Siobhan Clarke, William Harrison, Harold Oshher and Peri Tarr: "Subject-Oriented Design" （概要） 　 オブジェクト指向のモデルというのは，そのシステムのライフタイムに比べて役に立つとはいえない．その原因となっているのが次の事項であると考えられる． 　 ・設計モデルは巨大であり，モノリシックであり，その構造は要求のモデルとは一般にまったく異なる構造となっている． 　 ・設計は再利用が難しい． 　 ・このような設計が介在しているため，要求とコードの構造上の関係付けが困難である． 　 ・UMLはコードを生成するが，設計から要求事項が読み取れなくなりやすい． 　以上の問題意識のもとで，より柔軟なdecomposition，compositionを行えるようにし，要求しようとコードのどちらも設計と密接な関係を保持できるようにする手法を提案する． 　 この手法Subject-Oriented Programmingで提案されたものを引き継いでいる．Subject-Oriented Programmingは，コードをsubjectに分解させ，システム全体のモデルはsubjectを合成することによってできあがる．新しい要求が提案されたとき，新しいsubjectが生成される．新しい設計では，既存のsubject設計にsubjectの設計を合成すればよい．同様に，コードについても新しいsubjectのコードが生成されて，既存のコードと合成される． 　 例として，式の評価を行うSoftware Engineering Environmentが取り上げられ，自然言語の要求仕様からUMLによる設計，Javaによる実装を行い，初期システムからどのような要求変更に対して対応したかが示されている． 　 今後は合成関係と調停の意味論と統合の仕様をUMLにしたがって定義する． 2. Mik Kersten and Gail C. Murphy: "Atlas: A Case Study in Building a Web-Based Learning Environment" （概要） 　 AtlasとはAdvanced Teaching and Learning Academic Serverの略である．Web上での学習支援システムで学生は履修の登録ができ，さらに個人的にアレンジされた履修科目の資料をナビゲートできる．開発言語には当初，C++が採用されていたが，開発が進むにつれて保守の問題が発生した．そこでAspect指向を導入し，AspectJが採用された．Aspect指向はまだ市民権を得ているとはいえないので，この例を用いて，Aspectとオブジェクト指向の効果について議論する． 　 AtlasのAspectは次のものである． 　・シングルサーバ，アプリケーションサーバ，並行アプリケーションサーバ，アプレットという４つのネットワーク環境における支援が必要（ネットワークコンテキストに多様性がある） 　 ・処理は単純：学生のブラウザから要求がJavaのウェブサーバに到着→Atlasに委譲される→Atlasのコードがアプリケーションの機能を学生に送り返すという反応をする． 　Aspect指向を導入した開発の経験から，妥当な期間でよりよく構造化されたシステムを構築することができるようになった． 3. Elizabeth A. Kendall: "Role Model Designs and Implementations with Aspect-Oriented Programming" （概要） 　 　AspectJで開発したAspect指向の調査結果を報告する． 　Roleオブジェクトを介してオブジェクト間が関連を持つことによって，関連付けられるオブジェクトの役割が，オブジェクト固有の役割とRoleが提供する新たな役割を持つオブジェクトとみなすことができる．しかし，この方法だとオブジェクトと新たなRoleを持つオブジェクトとが同じオブジェクト識別子を持つという制約のもとで，不整合が発生し，さまざまな付加的な役割をもつオブジェクトが「精神分裂症状態のオブジェクト」となってしまう．この機能を提供するモデルとしてBureaucracyパターンを用いると，メッセージを受けるAgentCoreオブジェクトがすべての付加的なRoleが提供する役割への委譲メッセージを持たなければならないなどの問題が発生する．これらの問題を解決するために，AspectJの導入を考えた． 　付加的なRoleはStaticAspectというオブジェクトとして定義され，役割を付加したいオブジェクトのクラスにStaticAspectを編み込んでいく．これだと，オブジェクト間が立場によってメッセージを投げ合うcross-cutが発生する．（cross-cutによって役割の分担が実現できる） 　Subject-Orientedを取り入れてみた結果，SOPの考え方はAOPに取り込むことが可能であるが，SOPが動的な役割変化を支援できないのに対してAOPはできることがわかった．また，SOPを支援する言語はないがAOPを支援する言語はあるので，AspectJによる実現を選択した． 　Roleオブジェクトの実現については5つの選択肢が考えられた．これらを組み合わせたHybridアプローチで問題解決を試みた．最終的に，AOPにSOPを取り込み，オブジェクト指向役割モデルの実装をAOPのコードに組み込んだ．その結果，「精神分裂状態のオブジェクト」やインタフェースの保守労力を減らすことができ，動的な役割の割り当て，糊付けAspectによるオブジェクト階層の柔軟な統合(SOPの特徴)，個々の興味の対象ごとのモデル化，表現，統合が可能となった．その結果，コード量を減らすことができた． 　AspectJは役割の多重定義や併合を支援していないので，手作業でこれを進めた．AspectJは今後SOPの考え方を導入して，これらの機能を提供することを期待する．
感想	オブジェクトの再利用は多重視点に基づく役割の変化を実現できないと，推進されないと思う．SOPは，視点ごとに問題領域のモデル化を行い，問題領域全体で矛盾なく機能が実現されることを目指している．AOPが対象としているモデルは問題領域を見る視点の違いによるモデルの差異というよりは，実現上の構造の差異を分割して設計し，最終的に統合しようという試みであると解釈した．オブジェクトのRoleを動的に変化させ，視点ごとに異なる動作を実現しようとすると両者の取り込みが必要となる．3つめの論文が非常に興味深かった．

SSRの活動については，下記のWebページをご覧下さい． http://www.iisf.or.jp/SSR/index.html

[ Top ]