[2012 年 3 月号] |
[技術講座]
September/October 2011 では、ゲームソフトウェアにまつわる技術やプラクティスを集めた "Engineering Fun" という特集記事が掲載されています。 ゲーム開発のためのソフトウェアプロダクトライン (SPL)、オンラインゲームミドルウェア、実行時の修復などについてなど盛りだくさんです。 本内容は、IEEE Software の許可の下でオージス総研が日本語に翻訳して掲載したものです。
謹んでIEEE SoftwareのSeptember/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)宛てに電子メールでお願い致します.
Forrest Shull
編集長のForrest Shull が, 面白く, 品質のよりよいゲームソフトウェアを作るためにソフトウェア工学のプラクティスがどのように使われているかを明らかにするためにAIのリードプログラマーのEd Beach 氏にインタビューを行った. 本インタビューは, Firaxis 社によって作られているベストセラーゲームのCivilizationシリーズを念頭に行った.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.103
Jeffrey Voasが前IEEE Software 編集ボードのメンバであり, 最近亡くなったAnn Millerの追悼を記している.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.104
Gary McGraw
Gary McGrawは, 技術的な達人であるとともに音楽家や料理家でもあるという, この業界の驚くべき人物の一人である. 彼は, 真に科学的な活動としてのプロセスによりソフトウェアセキュリティーを事実上定義したのである. (www.cigital.com/services/bsimm/でBSIMMをご参照ください). - Linda Rising, 担当編集者
https://doi.ieeecomputersociety.org/10.1109/MS.2011.110
Grady Booch
セキュリティーとプライバシーは互いに依存する概念であるが, 代替の選択肢ではない. 両者ともに人間の関心の問題である. それらのポリシーとリスクはソフトウェアの比重が高いシステムの目録にできるかもしれない. セキュリティーとプライバシーのニーズにシステムのアーキテクチャをあつらえることは可能だし, 望ましいが, その結果はしばしば意図も予期もしないものになる.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.112
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 に本トピックの暗黒面についてインタビューしたものを提供している.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.89
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 つの研究の参考文献を提供している.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.90
Frank Buschmann
本コラムの前回の記事で検討したリファクタリングに加えて, リエンジニアリングとコードの書き直しはシステムの品質を改善するための 2 つの一般的なアプローチである. リエンジニアリングは, 既存のソフトウェアを発展させて新たな振る舞い, 特色, 稼働品質を与えるための系統的なアプローチである. リファクタリングとリエンジニアリングは同じことではないし, それらはコードの書き直しとも異なる. コードの書き直しは, もっとも過激な変更であり, 黒板をきれいに消し去り, もう一度やり直すということを含んでいる.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.97
Michiel van Genuchten, Les Hatton
IEEE Software の最初の 7 本の Impact コラムを振り返り, 編集者はコード行数単位, 年単位の新規顧客数として定義されるソフトウェアマイレージという新たなメトリックスを提案する.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.107
Clark Verbrugge, Paul Kruszewski
ビデオゲームの開発を成功させるためには, 結果としてできるプロダクトを確実に楽しいものにするということの難しさを理解することが前提になる. 取り組む際に, ソフトウェア要求, 一筋縄ではないマルチメディアの組み込み, その他のドメイン特化の関心事がソフトウェア開発に新奇な挑戦としてもたらされる. 本「エンジニアリングの楽しみ」特集のゲスト編集者は, いくつかの大きな課題について説明する. 記事では, 大規模, 複雑, グラフィカル, リアルタイム, 分散アプリケーションとして求められることを満たしつつ, なんらかの楽しいプレイヤー体験を提供しなければならないアプリケーションを設計及び作成することの難しさを説明する.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.98
Andre W.B. Furtado, Andre L.M. Santos, Geber L. Ramalho, Eduardo Santana de Almeida
デジタルビデオゲームの開発プロセスに再利用やソフトウェアプロダクトライン (SPL) の概念を導入するのは容易いことではない. 本記事では, SPLとゲーム開発の橋渡しを行い, ゲームサブドメインに適したドメイン特化言語やジェネレータを極めるための系統的なプロセスを提示する. 著者らは, 自ら提案したガイドラインを説明し, 評価するためにアーケードゲームのためのゲームSPLを事例として提示する.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.101
Alexandre Denault, Jorg Kienzle
大規模複数プレイヤーオンラインゲーム (MMOGs) の設計は, 優れた性能と楽しいゲームプレイを提供しつつも, スケーラビリティ, 信頼性, 信頼性, 公平性を達成しなければならないために難しい. 本記事では, 前述した課題に対処するための複雑さをゲーム開発者から見えなくした MMOG ミドルウェアである Journey を紹介する. Journey は, オブジェクト指向技術を中心にしてロードバランシング, フォールトトレランス, 不正行為検出能力を提供するために peer-to-peer のネットワークインフラ上に構築されている. 実験結果では, Journey を200 台以上のマシンで動作させた性能測定結果を示す.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.88
Eduardo Jimenez Chapresto, Kenny Mitchell, Francisco Jose Seron
本記事では, リーダーボードに基づく, あらゆるタイプのビデオゲームで示されるゲームプレイのメトリックスに対応可能な Tracktivity と呼ばれる柔軟で拡張可能なシステムを紹介する. このシステムには, 結果的としてゲームプレイ体験を増すための動的な競争のバランスやドライバーの進行を含む, 新たな可視化手段が組み込まれている. また, 本記事ではシステムのユースケースと収集されたデータを可視化及び分析するテクニックを紹介する.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.71
Chris Lewis, Jim Whitehead
ゲームは, プレイヤーに提供する可能性によりプレイヤーを絶えず驚かせるような発現的なものでなければならない. しかしながら, 発現性のために予測できなくなり, ゲームが望ましくない状態に至らないだろうことを開発者が検証するのが困難になる. さらに性質が悪いのは, バグを見つけてもそれがどのように生じるのかを突き止めるのが非常に難しくなる. 著者らは, ソフトウェアを実行時にモニターし, 実行している途中にゲームを修正するために使えるシステムである Mayet を紹介する. これらの機能が提供されていることで, 開発者は素晴らしいゲーム体験を作ることに集中し, きわどいケースや追跡できないバグに煩わせないですむようになる.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.87
Darja Smite, Claes Wohlin
ソフトウェア関連の作業のグローバリゼーションが一般的になってきた. コスト削減戦略の一部として, プロダクト中心のソフトウェア会社の多くはプロダクトの開発を海外の関係会社や委託先に移転し始めた. 不幸なことに, ソフトウェアプロダクトを 1 つの拠点から他の拠点に移すのは組織の面またはプロダクトの面でよいビジネス戦略にならないことがある. 本記事では, 著者らがスウェーデンに本社をおく大きな製品開発会社であるエリクソンにおいて関係会社へのソフトウェア開発の移転で得られた知見を考察する. この知見は, 一定の製品, スタッフ, プロセスの特性が海外の関係会社への移転を促進するということを示している. この会社が行った研究に基づき, 著者らは移転の課題を軽減するための重要な因子と拠点間でのソフトウェア関係の作業の移転を促進する 7 つの戦略を説明する.
https://doi.ieeecomputersociety.org/10.1109/MS.2010.112
Vieri del Bianco, Luigi Lavazza, Sandro Morasca, Davide Taibi
信頼できるかどうかは, どのようなプロダクトの評価においても極めて重要な特性だが, オープンソースソフトウェアではなおさら重要になる. 著者らは, ソフトウェア会社がオープンソースソフトウェアを採用/不採用と決める理由や動機を見つけ出すための調査を行った. 著者らは, オープンソースソフトウェアのコンポーネントまたはプロダクトを選択する際に使われた具体的な信頼因子に重要度に基づいてランキングを行った. これらの因子の重要度のランキングや動機はオープンソースソフトウェアの開発者(利害関係者に対して自分たちのプロダクトやコンポーネントの有用性を高めるため)と, オープンソースソフトウェアの見込みユーザーの両者にとって役立つであろう.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.93
Rodolfo Toledo, Eric Tanter
ZAC は, アスペクト指向に基づく JavaScript の実用的で軽量なアクセス制御用ライブラリである. ZAC のアクセス制御アーキテクチャはJavaやC#のライブラリと似ており, スタックに基づいている. しかしながら, ZAC はその他の機能をもっと表現力のあるアクセス制御で統合している. 第 1 に, アクセス制御ポリシーはオブジェクトのレベルで適用されるのでリソースのアクセスに対してよりきめ細かな制御が可能になる. 第 2 に, ZAC のポリシーはスクリプトの実行履歴に基づく判断を行うことができる. このことで, 制限時間付きの実行のように他のモデルを使ったら不可能なようなポリシーを開発者が設定することができる.
https://doi.ieeecomputersociety.org/10.1109/MS.2010.154
Panos Louridas
多くのプロジェクトで, テスティングはすべての作業を通じてもっとも多くのリソースを費やす. 企業は, 切手の収集のように明確な戦略を持たずに間に合うだけのテストケースを集めがちである. 不十分な品質, 可視化, テストの進捗管理で苦しんでいる会社は多い. 本記事では, テスト管理を紹介する.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.111
Olly Gotel, Stephen Morris
要求分析者は, Web の解析データの分析, ワイヤーフレーミング, ユーザストーリーのようなアジャイル開発や利用者中心設計のテクニックを含む適切なツールとそれらの使用法を備えた道具箱を必要としている. さらに, 創造性に関する文献を読み, 制約の除去, ストーリーテリング, その他のようなテクニックを取り入れることができる.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.105
Diomidis Spinellis
CPU はもはや, より高速になろうとはしていない. その代わりに, CPU 製造会社は各 CPU に複数のコアを詰め込み, 我々開発者にそれらを有効に利用することを求めている. 複数のスレッドやより高いレベルの API を使うための並列処理のコードを書くというのは非常に難しい作業である. 代替のアプローチとしては複数コアを容易に利用できるプログラミング言語を用いることがあるだろうが, それにも莫大な努力が求められる. 第 3 の方法は, この責務を他に任せることでアプリケーションがマルチコアの取り扱いに巧みだと見せかけることである. アプリケーションが Web に対するリクエストに( Web アプリケーションサーバにそのリクエストを引き渡すことで)対応したり, SQL 命令を(商用のリレーショナルデータベース管理システムを通じて)配信すれば, もっと高いレベルでは複数のコアを活用することは簡単である. 複数のコアを活用するためのもう 1 つの高いレベルの方法は, OS により処理を複数の独立したプロセスに分割させるというものである. これは, 通信プロセスでパイプラインを使ったり, GNU パラレルにより処理を同じプロセスの多数のインスタンスに分割したり, make -j により独立して処理できる要素を並列化することで実行できる. アプリケーションのレベルでは, map-reduce や filter-reduce テクニックを使うと同様なことが実行できる.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.95
© 2012 OGIS-RI Co., Ltd. |
|