|
[2012 年 5 月号] |
［技術講座］
November/December 2011では、地球温暖化などのシミュレーションを行うための気候モデルソフトウェアにまつわる技術やプラクティスを集めた"Climate Change: Science and Software"という特集記事が掲載されています。気候モデルソフトウェアのオープンソース開発、コードの書き直し、アーキテクチャなど盛りだくさんです。本内容は、IEEE 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）宛てに電子メールでお願い致します.
Forrest Shull
IEEE Softwareの 本号は独特でとりわけ興味深いドメインである「気候の研究を支援するために作成されたソフトウェア」を特集している. この分野では, 私たちすべてに直接的に重要である研究成果を生みだす, 異なる研究分野の専門家達を横断した連携が必要になる.
https://www.computer.org/csdl/mags/so/2011/06/mso2011060004.html
Eric Richardson, Chemical Abstracts Service
さらに内容を知りたい場合は読んでください! 本記事は, SATURNカンファレスでの複数回の発表された内容に基づいており, 興味深い点が満載である. 私が最初に取った学位は化学なので, 私は本記事の話をすぐに化学の抄録に結びつけた. 著者は, アーキテクチャ面での英知をアジャイルの観点と天気予報の組み合わせで提供する.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.152
Ricardo Perez-Castillo, Ignacio Garcia-Rodriguez de Guzman, Mario Piattini, and Christof Ebert
弛まなく変化するニーズを満たすため, ソフトウェアシステムは継続的に発展しなければならない. しかしながら, 時代遅れになった技術とともに統制の取れていない保守を行ってきた結果としてそのようなシステムはレガシーシステムになっていることが多い. 保守コストを制御し, 埋め込まれたビジネスルールを維持するために, 企業はレガシーシステムを発展させる必要がある. 本記事では, ソフトウェアリエンジニアリングのための技術を紹介する.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.145
Grady Booch
複雑さがあり, さらに組織化された複雑さがある. 純粋な複雑さは混沌としているのに対して, 組織化された複雑さはパターンの宝庫である. アーキテクチャの真髄とはそれらのパターンに名前を与え、その意図を尊重することである.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.148
Markus Völter
プログラミングとモデリングの違いはなんだろうか? １つのものとすべきか? とりわけ関与する考え方と道具という点で, モデリングはプログラミングと世界が異なる. しかし, これら2つの二分法について著者がさらに考えた結果, 私たちが本当に求めているのは, 一方ではアプリケーションドメイン固有の関心事であり, 他方ではもっと技術的な関心事でより汎用性と再利用性があるものというような異なるソフトウェアの関心事を表現するための合成可能な言語モジュールだとの結論に至った. この考えは新しいものでないが, 特に必要なツールが成熟してきたということで再び議論するのに適切な時期になった.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.139
Diomidis Spinellis, Henry Spencer
有人宇宙飛行と大規模ソフトウェアシステムは複雑さの点で双璧をなすものだとすると, ソユーズのような宇宙プログラムから私たち開発者が学べることができる点は多い. まず早期にプロジェクトのスコープや複雑さを制限することで成功や寿命という点で劇的な見返りがもたらされることがある. それに加えて, 早期の見積もり（及び後続する改訂）において寛大なマージンを加えることで開発と配置の苦痛が和らぐ. さらに大量に書き直しをするのではなく, １歩ずつ動作するプログラムを徐々に発展させることでソフトウェアの顧客ベースや第3者の貢献を維持しつつ、アーキテクチャやチームの成功に寄与することができる. 最後にしっかりと定義されたモジュール構造によりソフトウェアの変更容易性を増すことができ、ソフトウェアの存続する期間に渡るスコープや規模の経済をもたらす.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.143
Frank Buschmann
技術的負債は, 設計や実装の判断の時間を経た結果を説明するのに広く用いられているメタファーである. しかしながら, 技術的負債に対するアーキテクトの立場は技術的な関心よりもビジネスの側面で動かされるべきである. そのため, アーキテクトが進言できるのは技術的負債が被害を及ぼす時期, 技術的負債を取り除くべきかどうかという点, 技術的負債の除去時期、除去方法のみである.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.150
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 誌の本特集では気候変動モデルの背後にある“ソフトウェア”に注目する.
https://www.computer.org/csdl/mags/so/2011/06/mso2011060032.html
Nicholas Barnes and David Jones, Climate Code Foundation
くっきりとした気候コードプロジェクトは, 重要な地表の温度データセットを生成するために使われてきたGISTEMPというレガシーソフトウェアシステムを書きなおした. プロジェクトでは明快さを重視している. 関心を持つ人たちに対してソースコードを可能な限り明確にすることで全体的な理解を高めようとしたのである. その結果は理解も実行も変更も容易なPython のパッケージに結実し, 関心を持つ人が新たな研究上の疑問を問いかけ, 答えを得ることを可能にする. 開発の過程で, プロジェクトの発起人達はいくつかの些細なバグも見つけて修正したが, 地球温暖化についてのオンラインでの議論をよりよいものにすることであろうことを望んでいる.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.113
Spencer Rugaber, Rocky Dunlap, Leo Mark, and Sameer Ansari, Georgia Institute of Technology
結合した気候モデルは科学的, 数値的, アーキテクチャの可変性を表す. この可変性により複雑さを伴うような要求がもたらされる. しかしながら, この複雑さをしのぐためのテクニックがある.その一例がフィーチャー分析である. 気候モデルがより忠実で複雑になりゆくなかで, 気候モデリングコミュニティはソフトウェアの可変性に系統的に対処する方法を取り入れるべきである.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.114
Thomas Clune, NASA/Goddard Space Flight Center
Richard Rood, University of Michigan
過去 30 年以上に渡り, 気候モデルの多くが少数の大気のプロセスを比較的単純に表現したものから複数の学問領域に渡る複雑なシステムへと成長してきた. その期間でコンピューターインフラはパンチカードのメインフレームから現代的な並列クラスターに移行してきた. モデルの実装は複雑でもろく, ますます拡張や保守がしづらいものになってきた. モデルの実装の検証は気候全体のシミュレーション結果の詳細な分析とシステムレベルの回帰テストのなんらかの組み合わせだけにほとんど頼っている. 開発者の時間と計算資源の観点ではコストが高いことに加えてこれらのテスティング方法論は検出, 分離, 診断が可能な種類の欠陥に限定される. これらの大きな粒度のテスティングの弱点を細かい粒度の単体テストで軽減することは不格好で生産性を落とすものだとみなされている. 商業ソフトウェアツールにおける近年の進歩により系統的な小粒度のテスティングのルネッサンスがもたらされている. このことで気候モデルソフトウェアのテスティングの方法論に新たな可能性が開かれている.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.117
Joshua Introne, Robert Laubacher, and Thomas Malone, MIT Center for Collective Intelligence
気候変動の政策作成者にとってモデルは中心的な役割を果たすが, それらは非常に複雑で計算を行うための注文が多いため, 専門家がそれらを実行し, その結果を解釈することが多い. このことで利害関係者が代替シナリオを検討しづらくなっており,モデルが複雑で不透明だとの見方を増やし, 究極的には社会の確信を減らしかねない. Radically Open Modeling Architecture (ROMA) はこれらの問題を解決するためのWebサービスであり, 2つの主要機能を提供している. 主要機能の1つは代理シミュレーションの生成と実行であり, 代理シミュレーションはより大規模な統合された評価モデルの高速近似である. もう1つの主要機能はモデルを部品化して見せてユーザが部品を組み合わせることで新たな実行可能な合成モデルを作ることを可能にするものであり, 保存されたモデルを実行するものである.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.115
Isaac Held and David Randall
“オープンソースの気候モデル開発は行う価値がある”においてIsaac Heldは完全なオープンソースの気候モデリングを行うことには教育学的な価値がありえるとともに, 積極的な研究者やその分野の初心者に道具箱を提供することによる直接的に科学的に重要なものにさえなりえると説明している. ”気候モデルはオープンソースになるべきか？”においてDavid Randallはモジュール性のあるモデルをコーディングするということでコミュニティに基づく気候モデル開発は促進されるかもしれないが, 本当の気候システムはモジュール性がないために問題を生じかねないことを説明している.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.144
Neil B Harrison, Utah Valley University
Paris Avgeriou, University of Groningen
ソフトウェアアーキテクチャレビューはアーキテクチャについての潜在的な問題点を特定するのに効果的であるものの, 費用と時間がかかり, 大量のアーキテクチャの文書化を一般的に前提としている. 重要なアーキテクチャ上の課題を特定できたら, 非常に短い開発サイクル, 最小限の文書化, 頻繁な要求の変化があるプロジェクトに対してもアーキテクチャレビューは有用なものになりえるだろう. 我々は, 品質特性の達成における重要な課題を特定するための, システム中のアーキテクチャパターンを用いた有用で費用がかさまないアーキテクチャレビュー方法を開発した.
https://doi.ieeecomputersociety.org/10.1109/MS.2010.156
Malik Hneif and Sai Peck Lee, University of Malaya
ソフトウェア開発では, 機能と品質という2つの要求分野を満たすソフトウェアシステムを作ること目指す.ソフトウェア品質の1つの側面は, セキュリティ, 性能, 可用性のような非機能特性 (NFAs ) である. ソフトウェア開発者は, ソフトウェア開発の間に適切なガイドラインを適用することで非機能特性に関する要求を満足することができる. しかしながら, 異なるガイドラインが非機能特性品質に及ぼす影響が異なることやガイドライン間の関係のためにこのプロセスは複雑になっている. そのため , 適切なガイドライン一式を見つけるのは容易ではない. 本記事では,ソフトウェア開発のライフサイクルで非機能特性品質を改善するために適用できるような適切なガイドライン一式をソフトウェア開発者が得るためのステップバイステップの方法を紹介する. 本方法は, 異なるガイドラインが非機能特性とガイドライン間の関係に及ぼす影響を管理するものである.
https://doi.ieeecomputersociety.org/10.1109/MS.2010.157
Daniel Menasce, Hassan Gomaa, Sam Malek, and Joao Sousa, George Mason University
サービスの品質に関するトレードオフが絡むようなアーキテクチャ判断を人手で行うのは大変である. SASSY (Self-architecting Software Systems) フレームワークは候補ソフトウェアアーキテクチャを自動的に生成し, 利害関係者が定めたシナリオベースのサービス品質（QoS）ゴールに最もかなうものを選択する. このことでドメインの専門家は機能とサービス品質に関する要求に集中できるようになる. QoS の点で最適なアーキテクチャを自動生成したり, 実行時に素早く再構成することでSASSY はサービス指向システムを合成する労力を削減する. 自己アーキテクティングはシステム開発の初期と実行時に行われるので, それによりシステムは自己適合, 自己修復, 自己管理, 自己最適なものになる.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.22
James Bret Michael, Doron Drusinsky, Thomas W. Otani, and Man-Tak Shing, Naval Postgraduate School
システムの検証と妥当性確認を行うための継続的かつ積極的なプロセスには, 形式的な表明が自然言語の要求の意図を捉えているか否かの妥当性確認を行うためのシナリオベースのテスティングの利用が含まれる. このプロセスはステートチャートの表明と実行時の実行モニタリングにより自動化されている. 高信頼性システムを独立して検証及び妥当性確認するためのシステム参照モデルとしてステートチャートの表明を使うことができる.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.151
Yuki Tsuchitoi and Hideki Sugiura
おなじみの大きさのデジタルコピー機や多機能プリンターの中に, システム規模として数百万行のコードでいくつかの重複した領域に入り込む機能をもたらされている - 多くの現代的システムのテーマ.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.133
Tracy Hall, Sarah Beecham, David Bowes, David Gray, and Steve Counsell
2000 年から 2010 年に渡る欠陥予測モデルに関する研究文献を系統的にレビューし, モデル, 開発状況, 方法論を十分に記述した研究を 36 件特定した. 著者らはそれらの研究のうち 19 件とそこで示された206ケのモデルを定量的に分析した. その結果, 産業界のソフトウェア開発者が自分たちの状況に合う欠陥予測モデルを開発または最適化するのに役立つ, いくつかの大事な特性を特定した.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.138
Neil Maiden
要求分析者は適切な質問を繰り返し発する必要がある. 要求分析者は好奇心が強く, 事前に起こることが何であるかに加えて人々が何かを欲しがる理由を知るべきである. そのためには, 要求分析者は躊躇いを減らし, 自分たちや自分たちの利害関係者が回答に満足するまで質問をし続けなければならない.
https://doi.ieeecomputersociety.org/10.1109/MS.2011.149
Tom DeMarco
遅延はソフトウェアプロジェクトの失敗のもっとも一般的な形である.その原因は地上から見ると複雑に思えるが, もう少し離れると驚くほどシンプルに見える. Tom DeMarco が音声掲示板の編集者である Philippe Kruchten との興味深く刺激的な音声インタビューにおいて説明する.
Webのおまけ: 補足マテリアルへのアクセス (.mp3)
https://www.computer.org/csdl/mags/so/2011/06/mso2011060104.html
| © 2012 OGIS-RI Co., Ltd. |
|
