ObjectSquare [2012 年 5 月号]

[技術講座]


IEEE Software November/December 2011 目次と要旨(日本語訳)

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

November/December 2011では、地球温暖化などのシミュレーションを行うための気候モデルソフトウェアにまつわる技術やプラクティスを集めた"Climate Change: Science and Software"という特集記事が掲載されています。気候モデルソフトウェアのオープンソース開発、コードの書き直し、アーキテクチャなど盛りだくさんです。本内容は、IEEE Software の許可の下でオージス総研が日本語に翻訳して掲載したものです。



IEEE Software

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

November/December 2011 (Vol. 28, No. 6):気候変動 - 科学とソフトウェア (Climate Change: Science and Software)

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

目次

編集長から (FROM THE EDITOR)
未来を保証する - 気候モデルソフトウェアの妥当性確認に関する調査 ("Assuring the Future? A Look at Validating Climate Model Software")

Forrest Shull

IEEE Softwareの 本号は独特でとりわけ興味深いドメインである「気候の研究を支援するために作成されたソフトウェア」を特集している. この分野では, 私たちすべてに直接的に重要である研究成果を生みだす, 異なる研究分野の専門家達を横断した連携が必要になる.
http://www.computer.org/csdl/mags/so/2011/06/mso2011060004.html

分野別記事(DEPARTMENTS)

洞察:アジャイル開発 (INSIGHTS: Agile Development)
ハリケーン気象学者からアジャイルアーキテクトが学べること ("What an Agile Architect Can Learn from a Hurricane Meteorologist")

Eric Richardson, Chemical Abstracts Service

さらに内容を知りたい場合は読んでください! 本記事は, SATURNカンファレスでの複数回の発表された内容に基づいており, 興味深い点が満載である. 私が最初に取った学位は化学なので, 私は本記事の話をすぐに化学の抄録に結びつけた. 著者は, アーキテクチャ面での英知をアジャイルの観点と天気予報の組み合わせで提供する.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.152

ソフトウェア技術(Software Technology )
リエンジニアリング技術 ("Reengineering Technologies")

Ricardo Perez-Castillo, Ignacio Garcia-Rodriguez de Guzman, Mario Piattini, and Christof Ebert

弛まなく変化するニーズを満たすため, ソフトウェアシステムは継続的に発展しなければならない. しかしながら, 時代遅れになった技術とともに統制の取れていない保守を行ってきた結果としてそのようなシステムはレガシーシステムになっていることが多い. 保守コストを制御し, 埋め込まれたビジネスルールを維持するために, 企業はレガシーシステムを発展させる必要がある. 本記事では, ソフトウェアリエンジニアリングのための技術を紹介する.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.145

アーキテクチャについて (ON ARCHITECTURE)
小さなもののアーキテクチャ ("The Architecture of Small Things")

Grady Booch

複雑さがあり, さらに組織化された複雑さがある. 純粋な複雑さは混沌としているのに対して, 組織化された複雑さはパターンの宝庫である. アーキテクチャの真髄とはそれらのパターンに名前を与え、その意図を尊重することである.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.148

観点 (VIEWPOINTS)
プログラミングからモデリングへ - そして再び戻る ("From Programming to Modeling - and Back Again")

Markus Völter

プログラミングとモデリングの違いはなんだろうか? 1つのものとすべきか? とりわけ関与する考え方と道具という点で, モデリングはプログラミングと世界が異なる. しかし, これら2つの二分法について著者がさらに考えた結果, 私たちが本当に求めているのは, 一方ではアプリケーションドメイン固有の関心事であり, 他方ではもっと技術的な関心事でより汎用性と再利用性があるものというような異なるソフトウェアの関心事を表現するための合成可能な言語モジュールだとの結論に至った. この考えは新しいものでないが, 特に必要なツールが成熟してきたということで再び議論するのに適切な時期になった.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.139

商売道具 (Tools of the Trade)
宇宙から学んだこと ("Lessons from Space")

Diomidis Spinellis, Henry Spencer

有人宇宙飛行と大規模ソフトウェアシステムは複雑さの点で双璧をなすものだとすると, ソユーズのような宇宙プログラムから私たち開発者が学べることができる点は多い. まず早期にプロジェクトのスコープや複雑さを制限することで成功や寿命という点で劇的な見返りがもたらされることがある. それに加えて, 早期の見積もり(及び後続する改訂)において寛大なマージンを加えることで開発と配置の苦痛が和らぐ. さらに大量に書き直しをするのではなく, 1歩ずつ動作するプログラムを徐々に発展させることでソフトウェアの顧客ベースや第3者の貢献を維持しつつ、アーキテクチャやチームの成功に寄与することができる. 最後にしっかりと定義されたモジュール構造によりソフトウェアの変更容易性を増すことができ、ソフトウェアの存続する期間に渡るスコープや規模の経済をもたらす.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.143

現実的なアーキテクト (THE PRAGMATIC ARCHITECT)
技術的負債を返済すべきか、返済せざるべきか ("To Pay or Not to Pay Technical Debt")

Frank Buschmann

技術的負債は, 設計や実装の判断の時間を経た結果を説明するのに広く用いられているメタファーである. しかしながら, 技術的負債に対するアーキテクトの立場は技術的な関心よりもビジネスの側面で動かされるべきである. そのため, アーキテクトが進言できるのは技術的負債が被害を及ぼす時期, 技術的負債を取り除くべきかどうかという点, 技術的負債の除去時期、除去方法のみである.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.150


特集: 気候変動ソフトウェア (FOCUS: Climate Change Software)

ゲスト編集者による「気候変動 - 科学とソフトウェア」入門 ("Guest Editors' Introduction: Climate Change - Science and Software")

Steve M. Easterbrook, University of Toronto
Paul N. Edwards, University of Michigan
Venkatramani Balaji, Princeton University
Reinhard Budich, Max Planck Institute for Meteorology

気候変動はまぎれもなく 21 世紀の世界的な問題の1つになりそうである. 記録されて以来もっとも暑かった過去 10 年間において、世界の国々で洪水, 熱波, 異常気象との闘いが見られた.実際の規模の大きさゆえに, この問題を理解したり, 予測したり, 解決するのは困難になっている. 気候科学の論文誌は定期的に特定の気候モデルの特集を行っており, そこでは与えられた大きな新リリースのモデルで求めた過去から現在に至るまでの結果が示される. しかしながらそれらの特集では, ソフトウェアとその開発を説明するよりもモデルで可能になった新たな科学に注目していることが多い. IEEE Software 誌の本特集では気候変動モデルの背後にある“ソフトウェア”に注目する.
http://www.computer.org/csdl/mags/so/2011/06/mso2011060032.html

くっきりとした気候コード:レガシー科学ソフトウェアを明確にするために書き直す ("Clear Climate Code: Rewriting Legacy Science Software for Clarity")

Nicholas Barnes and David Jones, Climate Code Foundation

くっきりとした気候コードプロジェクトは, 重要な地表の温度データセットを生成するために使われてきたGISTEMPというレガシーソフトウェアシステムを書きなおした. プロジェクトでは明快さを重視している. 関心を持つ人たちに対してソースコードを可能な限り明確にすることで全体的な理解を高めようとしたのである. その結果は理解も実行も変更も容易なPython のパッケージに結実し, 関心を持つ人が新たな研究上の疑問を問いかけ, 答えを得ることを可能にする. 開発の過程で, プロジェクトの発起人達はいくつかの些細なバグも見つけて修正したが, 地球温暖化についてのオンラインでの議論をよりよいものにすることであろうことを望んでいる.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.113

結合した気候モデルにおけるソフトウェアの複雑さと可変性を管理する ("Managing Software Complexity and Variability in Coupled Climate Models")

Spencer Rugaber, Rocky Dunlap, Leo Mark, and Sameer Ansari, Georgia Institute of Technology

結合した気候モデルは科学的, 数値的, アーキテクチャの可変性を表す. この可変性により複雑さを伴うような要求がもたらされる. しかしながら, この複雑さをしのぐためのテクニックがある.その一例がフィーチャー分析である. 気候モデルがより忠実で複雑になりゆくなかで, 気候モデリングコミュニティはソフトウェアの可変性に系統的に対処する方法を取り入れるべきである.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.114

気候モデル開発におけるソフトウェアのテスティングと検証 ("Software Testing and Verification in Climate Model Development")

Thomas Clune, NASA/Goddard Space Flight Center
Richard Rood, University of Michigan

過去 30 年以上に渡り, 気候モデルの多くが少数の大気のプロセスを比較的単純に表現したものから複数の学問領域に渡る複雑なシステムへと成長してきた. その期間でコンピューターインフラはパンチカードのメインフレームから現代的な並列クラスターに移行してきた. モデルの実装は複雑でもろく, ますます拡張や保守がしづらいものになってきた. モデルの実装の検証は気候全体のシミュレーション結果の詳細な分析とシステムレベルの回帰テストのなんらかの組み合わせだけにほとんど頼っている. 開発者の時間と計算資源の観点ではコストが高いことに加えてこれらのテスティング方法論は検出, 分離, 診断が可能な種類の欠陥に限定される. これらの大きな粒度のテスティングの弱点を細かい粒度の単体テストで軽減することは不格好で生産性を落とすものだとみなされている. 商業ソフトウェアツールにおける近年の進歩により系統的な小粒度のテスティングのルネッサンスがもたらされている. このことで気候モデルソフトウェアのテスティングの方法論に新たな可能性が開かれている.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.117

気候変動評価モデリングにおけるオープン開発方法を可能にする ("Enabling Open Development Methodologies in Climate Change Assessment Modeling")

Joshua Introne, Robert Laubacher, and Thomas Malone, MIT Center for Collective Intelligence

気候変動の政策作成者にとってモデルは中心的な役割を果たすが, それらは非常に複雑で計算を行うための注文が多いため, 専門家がそれらを実行し, その結果を解釈することが多い. このことで利害関係者が代替シナリオを検討しづらくなっており,モデルが複雑で不透明だとの見方を増やし, 究極的には社会の確信を減らしかねない. Radically Open Modeling Architecture (ROMA) はこれらの問題を解決するためのWebサービスであり, 2つの主要機能を提供している. 主要機能の1つは代理シミュレーションの生成と実行であり, 代理シミュレーションはより大規模な統合された評価モデルの高速近似である. もう1つの主要機能はモデルを部品化して見せてユーザが部品を組み合わせることで新たな実行可能な合成モデルを作ることを可能にするものであり, 保存されたモデルを実行するものである.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.115

主張/反論 (Point/Counterpoint)

Isaac Held and David Randall

“オープンソースの気候モデル開発は行う価値がある”においてIsaac Heldは完全なオープンソースの気候モデリングを行うことには教育学的な価値がありえるとともに, 積極的な研究者やその分野の初心者に道具箱を提供することによる直接的に科学的に重要なものにさえなりえると説明している. ”気候モデルはオープンソースになるべきか?”においてDavid Randallはモジュール性のあるモデルをコーディングするということでコミュニティに基づく気候モデル開発は促進されるかもしれないが, 本当の気候システムはモジュール性がないために問題を生じかねないことを説明している.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.144


通常記事 (REGULAR ARTICLES)

主要記事:ソフトウェアパターン (FEATURE: Software Patterns)
パターンに基づくアーキテクチャレビュー ("“Pattern-Based Architecture Reviews")

Neil B Harrison, Utah Valley University
Paris Avgeriou, University of Groningen

ソフトウェアアーキテクチャレビューはアーキテクチャについての潜在的な問題点を特定するのに効果的であるものの, 費用と時間がかかり, 大量のアーキテクチャの文書化を一般的に前提としている. 重要なアーキテクチャ上の課題を特定できたら, 非常に短い開発サイクル, 最小限の文書化, 頻繁な要求の変化があるプロジェクトに対してもアーキテクチャレビューは有用なものになりえるだろう. 我々は, 品質特性の達成における重要な課題を特定するための, システム中のアーキテクチャパターンを用いた有用で費用がかさまないアーキテクチャレビュー方法を開発した.
http://doi.ieeecomputersociety.org/10.1109/MS.2010.156

主要記事:非機能要求 (FEATURE: Nonfunctional Requirements)
ソフトウェアの非機能特性における品質改善のためにガイドラインを活用する ("Using Guidelines to Improve Quality in Software Nonfunctional Attributes")

Malik Hneif and Sai Peck Lee, University of Malaya

ソフトウェア開発では, 機能と品質という2つの要求分野を満たすソフトウェアシステムを作ること目指す.ソフトウェア品質の1つの側面は, セキュリティ, 性能, 可用性のような非機能特性 (NFAs ) である. ソフトウェア開発者は, ソフトウェア開発の間に適切なガイドラインを適用することで非機能特性に関する要求を満足することができる. しかしながら, 異なるガイドラインが非機能特性品質に及ぼす影響が異なることやガイドライン間の関係のためにこのプロセスは複雑になっている. そのため , 適切なガイドライン一式を見つけるのは容易ではない. 本記事では,ソフトウェア開発のライフサイクルで非機能特性品質を改善するために適用できるような適切なガイドライン一式をソフトウェア開発者が得るためのステップバイステップの方法を紹介する. 本方法は, 異なるガイドラインが非機能特性とガイドライン間の関係に及ぼす影響を管理するものである.
http://doi.ieeecomputersociety.org/10.1109/MS.2010.157

主要記事:ソフトウェアアーキテクチャ (FEATURE: Software Architecture)
SASSY: 自己アーキテクティングサービス指向システムのためのフレームワーク ("SASSY: A Framework for Self-Architecting Service-Oriented Systems")

Daniel Menasce, Hassan Gomaa, Sam Malek, and Joao Sousa, George Mason University

サービスの品質に関するトレードオフが絡むようなアーキテクチャ判断を人手で行うのは大変である. SASSY (Self-architecting Software Systems) フレームワークは候補ソフトウェアアーキテクチャを自動的に生成し, 利害関係者が定めたシナリオベースのサービス品質(QoS)ゴールに最もかなうものを選択する. このことでドメインの専門家は機能とサービス品質に関する要求に集中できるようになる. QoS の点で最適なアーキテクチャを自動生成したり, 実行時に素早く再構成することでSASSY はサービス指向システムを合成する労力を削減する. 自己アーキテクティングはシステム開発の初期と実行時に行われるので, それによりシステムは自己適合, 自己修復, 自己管理, 自己最適なものになる.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.22

主要記事:要求分析 (FEATURE: Requirements Analysis)
高信頼性ソフトウェアシステムに対する検証と妥当性確認 ("Verification and Validation for Trustworthy Software Systems")

James Bret Michael, Doron Drusinsky, Thomas W. Otani, and Man-Tak Shing, Naval Postgraduate School

システムの検証と妥当性確認を行うための継続的かつ積極的なプロセスには, 形式的な表明が自然言語の要求の意図を捉えているか否かの妥当性確認を行うためのシナリオベースのテスティングの利用が含まれる. このプロセスはステートチャートの表明と実行時の実行モニタリングにより自動化されている. 高信頼性システムを独立して検証及び妥当性確認するためのシステム参照モデルとしてステートチャートの表明を使うことができる.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.151

インパクト (Impact)
あなたのコピー機の中の1千万行 ("10 MLOC in Your Office Copier")

Yuki Tsuchitoi and Hideki Sugiura

おなじみの大きさのデジタルコピー機や多機能プリンターの中に, システム規模として数百万行のコードでいくつかの重複した領域に入り込む機能をもたらされている - 多くの現代的システムのテーマ.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.133

証言 (Voice of Evidence)
欠陥予測モデルを開発する:産業界に研究が示せるもの ("Developing Fault-Prediction Models: What the Research Can Show Industry")

Tracy Hall, Sarah Beecham, David Bowes, David Gray, and Steve Counsell

2000 年から 2010 年に渡る欠陥予測モデルに関する研究文献を系統的にレビューし, モデル, 開発状況, 方法論を十分に記述した研究を 36 件特定した. 著者らはそれらの研究のうち 19 件とそこで示された206ケのモデルを定量的に分析した. その結果, 産業界のソフトウェア開発者が自分たちの状況に合う欠陥予測モデルを開発または最適化するのに役立つ, いくつかの大事な特性を特定した.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.138

要求 (Requirements)
躊躇う分析者 ("The Inhibited Analyst")

Neil Maiden

要求分析者は適切な質問を繰り返し発する必要がある. 要求分析者は好奇心が強く, 事前に起こることが何であるかに加えて人々が何かを欲しがる理由を知るべきである. そのためには, 要求分析者は躊躇いを減らし, 自分たちや自分たちの利害関係者が回答に満足するまで質問をし続けなければならない.
http://doi.ieeecomputersociety.org/10.1109/MS.2011.149

音声掲示板 (Sounding Board)
遅れるプロジェクトは皆同じである ("All Late Projects Are the Same")

Tom DeMarco

遅延はソフトウェアプロジェクトの失敗のもっとも一般的な形である.その原因は地上から見ると複雑に思えるが, もう少し離れると驚くほどシンプルに見える. Tom DeMarco が音声掲示板の編集者である Philippe Kruchten との興味深く刺激的な音声インタビューにおいて説明する.
Webのおまけ: 補足マテリアルへのアクセス (.mp3)
http://www.computer.org/csdl/mags/so/2011/06/mso2011060104.html



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

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