ObjectSquare [2012 年 3 月号]

[技術講座]


IEEE Software September/October 2011 目次と要旨(日本語訳)

翻訳:株式会社オージス総研 アジャイル開発センター 藤井拓

September/October 2011 では、ゲームソフトウェアにまつわる技術やプラクティスを集めた "Engineering Fun" という特集記事が掲載されています。 ゲーム開発のためのソフトウェアプロダクトライン (SPL)、オンラインゲームミドルウェア、実行時の修復などについてなど盛りだくさんです。 本内容は、IEEE Software の許可の下でオージス総研が日本語に翻訳して掲載したものです。



IEEE Software

私たちの使命: 先導的なソフトウェアの実践者のコミュニティを作るために, IEEE Software誌は迅速な技術の変化についていかなければならない思慮深い開発者やマネージャーに対して先進的なアイデアや専門家の分析,確かなアドバイス,思慮深い洞察を提供します. ソフトウェアの理論を実践へと翻訳するオーソリティです.

September/October 2011 (Vol. 28, No. 5):エンジニアリングの楽しみ (Engineering Fun)

謹んでIEEE SoftwareSeptember/October 2011 (Vol. 28, No. 5)号の目次と要旨をお送りします. 各号では無償の記事(英語)やポッドキャスト(英語)がいくつか提供されており, それらは要旨の下のリンクから入手することができます. 有償の技術的な記事を入手するために, 英語の印刷版[www.computer.org/subscribe/sw-jp] を通常価格の25%引き, またはデジタル版[www.qMags.com/ISW/jp]を US$19.95 で購読することができます.お問い合わせは, 編集長であるDale Strok (dstrok@computer.org)宛てに電子メールでお願い致します.

目次

編集長から (FROM THE EDITOR)
モンテズマを管理する:ソフトウェア開発の通常の課題すべてに対応し, それを楽しいものにする:Ed Beach氏のインタビュー(“Managing Montezuma: Handling All the Usual Challenges of Software Development, and Making It Fun: An Interview with Ed Beach” )

Forrest Shull

編集長のForrest Shull が, 面白く, 品質のよりよいゲームソフトウェアを作るためにソフトウェア工学のプラクティスがどのように使われているかを明らかにするためにAIのリードプログラマーのEd Beach 氏にインタビューを行った. 本インタビューは, Firaxis 社によって作られているベストセラーゲームのCivilizationシリーズを念頭に行った.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.103

レター (LETTERS)
Ann Miller を追悼する ("Remembering Ann Miller")

Jeffrey Voasが前IEEE Software 編集ボードのメンバであり, 最近亡くなったAnn Millerの追悼を記している.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.104

洞察:コードレビュー (INSIGHTS: CODE REVIEW)
技術移転:ソフトウェアセキュリティー市場の事例 ("Technology Transfer: A Software Security Marketplace Case Study")

Gary McGraw

Gary McGrawは, 技術的な達人であるとともに音楽家や料理家でもあるという, この業界の驚くべき人物の一人である. 彼は, 真に科学的な活動としてのプロセスによりソフトウェアセキュリティーを事実上定義したのである. (www.cigital.com/services/bsimm/でBSIMMをご参照ください). - Linda Rising, 担当編集者
http://doi.ieeecomputersociety.org/10.1109/MS.2011.110

アーキテクチャについて (ON ARCHITECTURE)
意図せず, つり合いが取れていない透過性 ("Unintentional and Unbalanced Transparency")

Grady Booch

セキュリティーとプライバシーは互いに依存する概念であるが, 代替の選択肢ではない. 両者ともに人間の関心の問題である. それらのポリシーとリスクはソフトウェアの比重が高いシステムの目録にできるかもしれない. セキュリティーとプライバシーのニーズにシステムのアーキテクチャをあつらえることは可能だし, 望ましいが, その結果はしばしば意図も予期もしないものになる.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.112

観点 (VIEWPOINTS)
素朴さの2乗:2つの分類とそれらの間のマッピングを求めて ("Naivete Squared: In Search of Two Taxonomies and a Mapping between Them")

Robert L. Glass, Iris Vessey

Web上のおまけ:Robert L. Glass に対するMargaret-Anne Storeyのインタビューを視聴できます.(Web Extra: View Margaret-Anne Storey’s interview with Robert L. Glass )

著者らは, 自分たちが極めて重要と考える課題, つまりソフトウェア工学分野と情報システム分野におけるアプリケーションと解決策の関係について記述する. 特に, それらの 2 分野においてアプリケーション分野の分類と解決策の分類とそれら 2 つの間のマッピングが渇望されていると著者らは信じている. Web 上のおまけでは, 著者の一人である Robert L. Glass に本トピックの暗黒面についてインタビューしたものを提供している.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.89

証言 (VOICE OF EVIDENCE)
ソフトウェアプロダクトラインのテスティング ("Testing Software Product Lines")

Paulo Anselmo da Mota Silveira Neto, Per Runeson, Ivan do Carmo Machado, Eduardo Santana de Almeida, Silvio Romero de Lemos Meira, Emelie Engstrom

Web上のおまけ:補足マテリアルの視聴(Web Extra: View Supplemental Material )

ソフトウェアプロダクトラインに対するテスティングプラクティスについての 2 つの研究により, 既存の文献で述べられている必要なテクニックと既存の方法との間にギャップがあることが分かった. 本記事のWeb上のおまけでは本記事で言及されている 2 つの研究の参考文献を提供している.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.90

現実的なアーキテクト (THE PRAGMATIC ARCHITECT)
アーキテクチャを手入れする, パート2:リエンジニアリングとコードの書き直し ("Gardening Your Architecture, Part 2: Reengineering and Rewriting")

Frank Buschmann

本コラムの前回の記事で検討したリファクタリングに加えて, リエンジニアリングとコードの書き直しはシステムの品質を改善するための 2 つの一般的なアプローチである. リエンジニアリングは, 既存のソフトウェアを発展させて新たな振る舞い, 特色, 稼働品質を与えるための系統的なアプローチである. リファクタリングとリエンジニアリングは同じことではないし, それらはコードの書き直しとも異なる. コードの書き直しは, もっとも過激な変更であり, 黒板をきれいに消し去り, もう一度やり直すということを含んでいる.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.97

インパクト (IMPACT)
ソフトウェアマイレージ ("Software Mileage")

Michiel van Genuchten, Les Hatton

IEEE Software の最初の 7 本の Impact コラムを振り返り, 編集者はコード行数単位, 年単位の新規顧客数として定義されるソフトウェアマイレージという新たなメトリックスを提案する.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.107


エンジニアリングの楽しみ (FOCUS: ENGINEERING FUN)

ゲスト編集者によるエンジニアリングの楽しみ入門 ("Guest Editors' Introduction: Engineering Fun")

Clark Verbrugge, Paul Kruszewski

ビデオゲームの開発を成功させるためには, 結果としてできるプロダクトを確実に楽しいものにするということの難しさを理解することが前提になる. 取り組む際に, ソフトウェア要求, 一筋縄ではないマルチメディアの組み込み, その他のドメイン特化の関心事がソフトウェア開発に新奇な挑戦としてもたらされる. 本「エンジニアリングの楽しみ」特集のゲスト編集者は, いくつかの大きな課題について説明する. 記事では, 大規模, 複雑, グラフィカル, リアルタイム, 分散アプリケーションとして求められることを満たしつつ, なんらかの楽しいプレイヤー体験を提供しなければならないアプリケーションを設計及び作成することの難しさを説明する.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.98

デジタルゲーム開発をソフトウェアプロダクトラインで改善する ("Improving Digital Game Development with Software Product Lines")

Andre W.B. Furtado, Andre L.M. Santos, Geber L. Ramalho, Eduardo Santana de Almeida

デジタルビデオゲームの開発プロセスに再利用やソフトウェアプロダクトライン (SPL) の概念を導入するのは容易いことではない. 本記事では, SPLとゲーム開発の橋渡しを行い, ゲームサブドメインに適したドメイン特化言語やジェネレータを極めるための系統的なプロセスを提示する. 著者らは, 自ら提案したガイドラインを説明し, 評価するためにアーケードゲームのためのゲームSPLを事例として提示する.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.101

Journey:大規模複数プレイヤーオンラインゲームミドルウェア ("Journey: A Massively Multiplayer Online Game Middleware")

Alexandre Denault, Jorg Kienzle

大規模複数プレイヤーオンラインゲーム (MMOGs) の設計は, 優れた性能と楽しいゲームプレイを提供しつつも, スケーラビリティ, 信頼性, 信頼性, 公平性を達成しなければならないために難しい. 本記事では, 前述した課題に対処するための複雑さをゲーム開発者から見えなくした MMOG ミドルウェアである Journey を紹介する. Journey は, オブジェクト指向技術を中心にしてロードバランシング, フォールトトレランス, 不正行為検出能力を提供するために peer-to-peer のネットワークインフラ上に構築されている. 実験結果では, Journey を200 台以上のマシンで動作させた性能測定結果を示す.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.88

レーシングゲームプレイメトリックスの取り込みと分析 ("Capture and Analysis of Racing Gameplay Metrics")

Eduardo Jimenez Chapresto, Kenny Mitchell, Francisco Jose Seron

本記事では, リーダーボードに基づく, あらゆるタイプのビデオゲームで示されるゲームプレイのメトリックスに対応可能な Tracktivity と呼ばれる柔軟で拡張可能なシステムを紹介する. このシステムには, 結果的としてゲームプレイ体験を増すための動的な競争のバランスやドライバーの進行を含む, 新たな可視化手段が組み込まれている. また, 本記事ではシステムのユースケースと収集されたデータを可視化及び分析するテクニックを紹介する.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.71

実行時のゲームの修復, あるいは如何にして心配をするのを止め, 発現を愛するに至ったか ("Repairing Games at Runtime or, How We Learned to Stop Worrying and Love Emergence")

Chris Lewis, Jim Whitehead

ゲームは, プレイヤーに提供する可能性によりプレイヤーを絶えず驚かせるような発現的なものでなければならない. しかしながら, 発現性のために予測できなくなり, ゲームが望ましくない状態に至らないだろうことを開発者が検証するのが困難になる. さらに性質が悪いのは, バグを見つけてもそれがどのように生じるのかを突き止めるのが非常に難しくなる. 著者らは, ソフトウェアを実行時にモニターし, 実行している途中にゲームを修正するために使えるシステムである Mayet を紹介する. これらの機能が提供されていることで, 開発者は素晴らしいゲーム体験を作ることに集中し, きわどいケースや追跡できないバグに煩わせないですむようになる.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.87


通常記事(REGULAR ARTICLES)

主要記事:ソフトウェアマネジメント (FEATURE: SOFTWARE MANAGEMENT)
ソフトウェアプロダクトの移転を促す戦略 ("Strategies Facilitating Software Product Transfers")

Darja Smite, Claes Wohlin

ソフトウェア関連の作業のグローバリゼーションが一般的になってきた. コスト削減戦略の一部として, プロダクト中心のソフトウェア会社の多くはプロダクトの開発を海外の関係会社や委託先に移転し始めた. 不幸なことに, ソフトウェアプロダクトを 1 つの拠点から他の拠点に移すのは組織の面またはプロダクトの面でよいビジネス戦略にならないことがある. 本記事では, 著者らがスウェーデンに本社をおく大きな製品開発会社であるエリクソンにおいて関係会社へのソフトウェア開発の移転で得られた知見を考察する. この知見は, 一定の製品, スタッフ, プロセスの特性が海外の関係会社への移転を促進するということを示している. この会社が行った研究に基づき, 著者らは移転の課題を軽減するための重要な因子と拠点間でのソフトウェア関係の作業の移転を促進する 7 つの戦略を説明する.
http://doi.ieeecomputersociety.org/10.1109/MS.2010.112

主要記事:ソフトウェア品質 (FEATURE: SOFTWARE QUALITY)
オープンソースソフトウェアが信頼できるかに関する調査 ("A Survey on Open Source Software Trustworthiness")

Vieri del Bianco, Luigi Lavazza, Sandro Morasca, Davide Taibi

信頼できるかどうかは, どのようなプロダクトの評価においても極めて重要な特性だが, オープンソースソフトウェアではなおさら重要になる. 著者らは, ソフトウェア会社がオープンソースソフトウェアを採用/不採用と決める理由や動機を見つけ出すための調査を行った. 著者らは, オープンソースソフトウェアのコンポーネントまたはプロダクトを選択する際に使われた具体的な信頼因子に重要度に基づいてランキングを行った. これらの因子の重要度のランキングや動機はオープンソースソフトウェアの開発者(利害関係者に対して自分たちのプロダクトやコンポーネントの有用性を高めるため)と, オープンソースソフトウェアの見込みユーザーの両者にとって役立つであろう.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.93

主要記事:Web 2.0 (FEATURE: WEB 2.0)
JavaScriptにおけるアクセス制御 ("Access Control in JavaScript")

Rodolfo Toledo, Eric Tanter

ZAC は, アスペクト指向に基づく JavaScript の実用的で軽量なアクセス制御用ライブラリである. ZAC のアクセス制御アーキテクチャはJavaやC#のライブラリと似ており, スタックに基づいている. しかしながら, ZAC はその他の機能をもっと表現力のあるアクセス制御で統合している. 第 1 に, アクセス制御ポリシーはオブジェクトのレベルで適用されるのでリソースのアクセスに対してよりきめ細かな制御が可能になる. 第 2 に, ZAC のポリシーはスクリプトの実行履歴に基づく判断を行うことができる. このことで, 制限時間付きの実行のように他のモデルを使ったら不可能なようなポリシーを開発者が設定することができる.
http://doi.ieeecomputersociety.org/10.1109/MS.2010.154


分野別記事(DEPARTMENTS)

ソフトウェア技術 (SOFTWARE TECHNOLOGY)
テスト管理 ("Test Management")

Panos Louridas

多くのプロジェクトで, テスティングはすべての作業を通じてもっとも多くのリソースを費やす. 企業は, 切手の収集のように明確な戦略を持たずに間に合うだけのテストケースを集めがちである. 不十分な品質, 可視化, テストの進捗管理で苦しんでいる会社は多い. 本記事では, テスト管理を紹介する.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.111

要求 (REQUIREMENTS)
要求トレーサリー ("Requirements Tracery")

Olly Gotel, Stephen Morris

要求分析者は, Web の解析データの分析, ワイヤーフレーミング, ユーザストーリーのようなアジャイル開発や利用者中心設計のテクニックを含む適切なツールとそれらの使用法を備えた道具箱を必要としている. さらに, 創造性に関する文献を読み, 制約の除去, ストーリーテリング, その他のようなテクニックを取り入れることができる.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.105

仕事の道具 (TOOLS OF THE TRADE)
見せかける ("Faking It")

Diomidis Spinellis

CPU はもはや, より高速になろうとはしていない. その代わりに, CPU 製造会社は各 CPU に複数のコアを詰め込み, 我々開発者にそれらを有効に利用することを求めている. 複数のスレッドやより高いレベルの API を使うための並列処理のコードを書くというのは非常に難しい作業である. 代替のアプローチとしては複数コアを容易に利用できるプログラミング言語を用いることがあるだろうが, それにも莫大な努力が求められる. 第 3 の方法は, この責務を他に任せることでアプリケーションがマルチコアの取り扱いに巧みだと見せかけることである. アプリケーションが Web に対するリクエストに( Web アプリケーションサーバにそのリクエストを引き渡すことで)対応したり, SQL 命令を(商用のリレーショナルデータベース管理システムを通じて)配信すれば, もっと高いレベルでは複数のコアを活用することは簡単である. 複数のコアを活用するためのもう 1 つの高いレベルの方法は, OS により処理を複数の独立したプロセスに分割させるというものである. これは, 通信プロセスでパイプラインを使ったり, GNU パラレルにより処理を同じプロセスの多数のインスタンスに分割したり, make -j により独立して処理できる要素を並列化することで実行できる. アプリケーションのレベルでは, map-reduce や filter-reduce テクニックを使うと同様なことが実行できる.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.95



記事の内容を5点満点で評価してください。
1点 2点 3点 4点 5点
記事に関するコメントがあれば併せてご記入ください。

© 2012 OGIS-RI Co., Ltd.
Prev Index Next
Prev Index Next