netail.net
自作フリーソフトや，ゲームに関する雑記を公開してます．
日記はソフトウェア工学の論文ネタが中心です．
最近のお知らせ (古いものはこちら)
2004-04-12 古い日記からの変換データ [長年日記] ▲
2004-04-11 古い日記からの変換データ [長年日記] ▲
_ 論文 ▲
Profes の間に読んだ最後の論文．
Andrea De Lucia, Mark Harman, Robert Hierons, Jens Krinke:Unions of Slices are not Slices.
プログラム P のスライス P' は，Weiser の定義から，以下の条件を満たす．・P' は，P から０行以上の文を消している．・P が停止する入力なら，P' も停止する．・P' は，ある変数群 V について P と同じ値を計算する．
この条件には意外と自由度が高く，Static Slice を複数計算したとき，それらの和を取ると，スライスではなくなってしまう場合がある，というもの．Dynamic Slice については，既存研究があるらしい．
安易に union を取るのはよくない，らしいがスライスの union, intersection にはどのくらい意味があるのか，という議論はどれくらいあるのだろうか．
参考文献を（暇があれば）あたってみることにする．
_ 論文 ▲
Profes 余暇の利用して読んだ論文その３．
Raju Pandey, Brant Hashii:Providing Fine-Grained Access Control for Java Programs.ECOOP 99, pp.449-473, 1999.
アクセス制御を外付けする．条件判定に，インスタンスのフィールドやクラスの情報を使えるので，アスペクトとして if でテストするコードを追加する実装にかなり近いアプローチだという気がする．
外付けするのは，モバイル端末がサイトに勝手にアクセスするのを防ぐ，といった，「後付け」制限になるため．Readonly でも，機密データならばアクセスできない，といった制限も考えられる．このあたりは Java の SecurityManager などが関連しているともいえる．
この機能，今なら本当にアスペクトで実現しそう．
_ 論文 ▲
Profes の余り時間で読んだ論文その２．
Gunter Kniesel, Dirk Theisen:JAC - Access Right based encapsulation for Java.Software Practice and Experience, 00(S1), 1-21(2000).
いわゆる "const" を Java に導入する話．オブジェクトの状態を，ローカル変数で定義される local state と参照しているオブジェクトの状態で定義される transitive state に区分している．
そして，参照変数に readonly という修飾子を追加し，this が "readonly" として参照されたコンテキストではreadonly が付加されたメソッドしか実行できない．また，mutable と明示的に定義されたデータしか変更できない．
this のとりうるコンテキスト＋変数のコンテキスト＋メソッドのコンテキスト，で static に型チェックを行うというもの．
これは，JDK 1.5 で導入されるとかいうものと同じ？
_ 論文 ▲
Profes 2004 の暇な時間に読んだ論文．
Pascal Costanza, Gunter Kniesel, and Michael Austermann:Independent Extensibility for Aspect-Oriented Systems.
6ページのショートペーパー．
アスペクトが予期せぬ環境で使用され，副作用をもたらすことは避けられない．アスペクトを適用するごとに join point が変化していき，結局，アスペクトの結合順序などに依存した結果となる．
この論文では，アスペクトの適用をコード変換とインタフェース変換に区分していて，インタフェース変換は，インタフェースのメソッド集合を追加するだけなので順序の影響を受けないが，コード変換は順序の影響を受ける．
……ということから，コード変換のほうは開発者が考慮するような環境が望ましく，データフロー解析などが重要になるかもしれない，というふうに主張している．
_ Profes 2004 ▲
Session 12: COTS
Profes 2004 最後のセッションの論文二つ．（残り１つは発表取り消し）
Jingyue Li, Reidar Conradi, Parastoo Mohagheghi, Odd Are Sæhle, Øivind Wang, Erlend Naalsund, Ole Anders Walseth:A Study of Developer Attitude to Component Reuse in Three IT Companies.
３つの企業（Ericsson, EDB, Mogul）での調査結果．
・コンポーネントは十分（期待通りに）効果的に働くか？
・コンポーネントが効果的なら，コンポーネントをたくさん使うか？
・関連したコンポーネントについて，十分な情報が得られるか？
・component quality と reuse level は関係あるのか?
といったことについて，開発者にアンケートをとっている．
その結果，Ericsson は Reuse レベルが高かったよう．会社ごとに，回答の範囲がある程度固まっていたので，嘘ではなさそう．
会社が reusable components repository に投資することは期待されていなかったらしい．component structure, interface は理解できる．コンポーネントの設計ルールについても理解できる．でも，そのコンポーネントのドキュメントが良いとは思っていなくて，非形式的な，ソースコードがベース．
この評価の話は，特定の企業で，人数も少ないという点から，妥当性という点で弱い，と本人たちも言っていた．
Mercedes Ruiz, Isabel Ramos, Miguel Toro:Using Dynamic Modeling and Simulation to Improve COTS Software Process.
Software process simulation によってCOTS ベースなプロセスの dynamic behavior を調べたりしよう，というものらしい．
Traditional Estimation (WBS, statistical correlation) + System Dynamics Modeling
Simulation 実行データと実際のデータをDBに持っておいて，「現状で実行するとこうなる」，という状態と改善した状態を比べるような話らしい．あまり興味がないのでちゃんと聞いてない．
_ Profes 2004 ▲
論文整理続き．Session 10: Software Process Assessment
Fredrik Ekdahl, Stig Larsson:Selecting CMMI Appraisal Classes Based on Maturity and Openness.
必ずしもCMMIでなくてもよいらしいが．組織の状態を Maturity, Openness でとらえると，Maturity や Openness は必ずしも単調に増加するわけではなく，組織の変化などの影響で下がったりもする．
Openness は外部からの援助などを（対価を払ってでも）獲得しようという行動の度合いで，経験的，企業の振る舞いから，現在は主観的，定性的に決めている．
いくつかの企業についてマッピングを行っていたが，現段階では，そのうち何か面白い結果が出るかも，という程度の話．
Pasi Ojala:Combining Capability Assessment and Value Engineering: a BOOTSTRAP example.
Value Engineering(価値工学; 最小コストの製造法を得るための設計・製造工程の分析とかの工学)を導入してみました，という話．
Value = 価値(worth) / cost worth = 客がいくら支払ってくれるか or かかったかもしれないコストcost = 実際にかかったコスト
+Capability, +Value: Situation is in control
+Capability, -Value: Wasted Quality
-Capability, +Value: Do something / Improve
-Capability, -Value: Do not worry
Full assessment を行って，すべてのプロセスに対して Maturity を，また，Value を部分的に計算して，価値の高いところから改善していこう，というもの．それなりに面白そうな話ではあった．
Marcello Visconti, Curtis A. Cook:Assessing the State of Software Documentation Practices.
ドキュメントが大事 --- コードを書く前に欠陥を取り除くことが重要，という立場の論文．
Key Practices/Sub practices/Questionsという構成．GQM に近い気がする．
意外と，「良いドキュメント」はやりたいと思っていても実際には実践できていない，らしい．
_ Profes 2004 ▲
Session 8: Software Process Improvement 2あんまり興味がないので適当．
Mingyang Gu, Xin Tong:Towards Hypotheses on Creativity in Software Development.
Creative Work の割合が開発効率に影響するのではないか，と考えて "Creative Work" と discipline-based work と，それ以外のタスクにかかった時間を，学生相手に調べてみたという論文．
しかし，Creative Work が高いからといって開発速度が変わるわけではないらしい．UML がアイディア記述のための道具として役立っていた，といった報告もしていた．
Lasse Harjumaa, Ilkka Tervonen, Pekka Vuorio:Using Software Inspection as a Catalyst for SPI in a Small Company.
アンケートによる分析→目標の設定→improvement pattern を選ぶ，という形でのソフトウェアプロセス改善．
pattern ベースでやるのはガイドラインとしては便利なのだが，・行動リストが一般的すぎたり・同じようなパターンが複数あったり・結果がどうなるか書いてなかったりするときがあるので注意が必要である，と言っていた．
もちろん，small/large company で違うかもしれない．small であるという仮定がどの程度効いているのかはよく分からない．
_ Profes 2004 ▲
Session 6: Industrial Experiences経験論文系．
Marek Vokáč, Oluf Jensen:Using a reference application with Design Patterns to produce Industrial Software.
「お手本」をもとにシステムを構築するという話のよう．再利用については，２つ目の Key note でも言われていたが，パターンやアーキテクチャ，モデルといった抽象度の高いレベルで再利用をしましょう，ということになるらしい．
そうすることで，そんなに経験をつんでないチームでもそれなりにいいものが作れた，らしい．他のプロジェクトでも使えるか？という問題があるが，requirements が reference application にマッチするかどうか，がキーとなる．
Keynote 2:"Embedded Software Development -Today and Tomorrow-"Mr. Takashi Yamamura (Ricoh Company, Ltd.)
品質を下げずに再利用を行うためにはソースコードではなくモデルを再利用する，また，品質はテストではなく設計によって確保する，という話．
Component == Fixed part + Variable Part となるらしい．このあたりは，チュートリアルで聞いた話とも同じ．
それにしても，実際にバグ数が減少して，時間あたりのソースコード量での生産性が倍程度に向上している，という具体的なグラフを見せてくれた点が面白かった．
_ Profes 2004 ▲
Profes 2004 論文整理．
Session 3: Measurement
Felix Garcia, Francisco Ruiz, Mario Piattini:Definition and Empirical Validation of Metrics for Software Process Models.
プロセスに対するメトリクス．プロセスモデルの保守性，理解容易性，変更容易性などをやはり GQM paradigm ベースで評価している．
10 Software Process Models に対して適用してみていて，NA, NWP, NDWPIn, NDWPOut と modifiability time との相関があるらしい．（ここでのmodification というのは activity の追加とか）
Pasquale Ardimento, Maria Teresa Baldassarre, Danilo Caivano, Giuseppe Visaggio:Multiview Framework for Goal Oriented Measurement Plan Design.
色々なメトリクス，ゴールがあるが，実際にはメトリクス間の依存関係があったり時間的な制約によってはかれるものが限られたりする（テストフェイズまで進まないと計れないものなど）．どうやったらこれらをうまく管理できるか？という話．
ゴールとプロセス/プロダクトの表を作って，全体を管理ゴールの「解釈」についてはデシジョンテーブルを使うGQM ベースなアプローチを使っている．GQM パラダイム，やっぱりみんな好き？使いやすいのかな？
Magne Jørgensen, Kjetil Moløkken:Does Awareness of Previous Estimation Performance Lead to Less Overconfidence.
以前のプロジェクトの情報を使えば，見積もりが大きすぎる/小さすぎるという状態を抑えられるはずである，という仮定に基づく実験．
Estimate = 100% として実際にかかった工数が何％であったかを調べている．
そして，実際に過去のデータを使ってみたところ，ある程度抑えることができた（９０％~１５０％）．ただし，１５０％というのは overconfidence かもしれないが．
組織間を超えた結果の適用などは難しそう．また，過信を抑えるのと，正確さを向上するのとは違うよう．評価結果が "どのくらい信用できるか" といった感じのものらしい．
_ Profes 2004 ▲
適当に論文をピックアップ．あんまり興味がないので適当．
Session 2: Software Quality
Jukka Riekki, Pekka Isomursu, Minna Isomursu:Evaluating the Calmness of Ubiquitous Applications.
ユビキタスコンピューティングでは「いつでもどこでも」が重要なので，システムの availability などを考える必要がある．
Calmness に注目して，分析結果から簡単な図表現を作って，何が足りないか考えよう，というものか．なんかよく分かってないが．
Axel Spriestersbach, Thomas Springer:Quality Attributes in mobile Web Application Development
ユビキタスなシステムは，環境にあわせてインタフェースなどを変化させる．（たとえば入力項目数が減るなど）
このとき，applications x devices の組み合わせが発生する．これに対して，次の対策が取れる．
・再実装：高ユーザビリティだが高コスト
・自動変換：低コストだが低ユーザビリティ
・一部自動変換（GUI は抽象 widget クラスで作るが アプリケーションレベルで一部書き換え）
Cost -- Usability はおおむね比例のように感じられるが，実際には，一部は自動変換するというアプローチがコスト対効果が良く，少ないデバイス集合からだんだん対応デバイスを増やしていく方法が良い，といったことを言っていたように思う． Lerina Aversano, Gerardo Canfora, Giuseppe Capasso, Giuseppe A. Di Lucca, Corrado A.Visaggio:Introducing Quality System in Small and Medium Enterprises: An experience report.
Quality System は導入・使用におけるコストが，活用への大きな障害になるというわけで，開発した Quality System を使ったケーススタディ．
・開発者が既に慣れているものを使うと， 導入コストは低くなったらしい．
・GQM での品質比較を行った結果， 期待品質と実際の品質の差はほとんどなかったらしい．
_ Profes 2004 ▲
Profes 2004 で聞いた情報整理その１．
Richard Turner による Key note:
Best Practices は真実だと思っているが事実とは異なるかもしれない，という話から始まっていた，
物をもつときはしっかり抱える，という practice を盲目的に実践してしまうとケーキを押しつぶしてしまう，…というところから始まって，
"Wrap well" practice from cake melted mess. "Cool in stream" practice from butter experience nearly drowned dog."Tie to string" practice from puppy experience → very dirty bread and very angry aunt.
ということで，not blindly applied practice,apply empiricism to practice.ということになる．
その利益は qualitative (Schedule, Quality, Cost) であって数値としては見えてこない．
Best Practice の Pedigree (系図) として・誰が作ったか・どのくらい時間が経ったか・データはあるか・使って成功した人はいるか ...といった情報も役立つ．
また，コンテキスト（プロジェクトサイズ，ライフサイクル，...）も重要だし，効果が出てくるまでの時間も問題となる．たとえば，データを集め始めてから効果が出るまで組織などの支援は続くか？プロジェクトが終わってしまわないか？といったことを考慮する必要がある．
Beware the myth. Trust, but verify ...
しかし，実験するときには，その環境で得られた結果が実プロジェクトなどで本当に適用可能かどうか，についてはきちんと吟味する必要がある，ということで話を締めくくっていた．
2004-04-05 古い日記からの変換データ [長年日記] ▲
_ Profes2004 ▲
Tutorial 2:A Feature-Oriented Method for Product Line Software EngineeringKyo C. KangPohang University of Science and Engineering
続き．
ドメインのスコープだけは，広すぎないようにしないといけなくて，基準としては「変化するものが多すぎるときは，もっと狭める」らしい．また，開発者だけだと，実装の詳細に踏み込みすぎるので気をつけましょう，とも言っていた．ドメインが未成熟なときは terminology の定義も必要．
モデルが複雑になりすぎるのを抑えるために，モデルが複雑になりすぎたときは抽象クラスの作成や，共有されるようなクラスが多いときは逆に違いをはっきりさせるために派生クラスの作成を行ったりもする．また，ドメインからアーキテクチャ上にマップするときに１対多対応になってしまうものは，１対１になるように分解する，といったことによって目的を達成するらしい．
_ Profes2004 ▲
Tutorial 2:A Feature-Oriented Method for Product Line Software EngineeringKyo C. KangPohang University of Science and Engineering
Feature-Oriented Programming と関係あるのかな？ということで聞きにいってみたチュートリアル．チュートリアルの担当者は，SEI でドメイン分析 FODA とかを研究していた人らしい．
特定のドメインに対するソフトウェア群（たとえば「エレベータ制御」--どんな場所に設置されるか，何人乗せられるか，実際に動かす対象などが異なる）をうまく共通のアーキテクチャ，コンポーネント群を使って構築しようというのが基本コンセプト．
ただ，ソフトウェアの変更や継続的なメンテナンスにもドメイン分析は有効である，とは言っていた．一つのシステムが変化していくのを，Product Line の開発として考えれば，確かにその通り．
ハードウェアなら CPU やメモリ容量が仕様に相当するが，ソフトウェアならサービスがそれに当たる．ドメイン上で，必要なサービスや品質特性を分析して，それをアーキテクチャ上のコンポーネントにマッピングしていく．コンポーネントを，さらに実際のソフトウェア部品などに対応させていく．
Capability と Operating Environment を顧客とアナリストがつくり，開発者が，アナリストと一緒に Domain Technology やImplementation Technique を考えていく．Feature の階層構造から，わりと自然に，ドメインに対応するクラスが導出できるものらしい．で，抽出された要素をアーキテクチャ上にマップしていく．
2004-04-03 古い日記からの変換データ [長年日記] ▲
_ EDエディタ ▲
1.2 から 1.3 に移行してみたら，なぜかファイルから関連付けで開いたとき，ファイルはちゃんと復号されるのだが，なぜか暗号化エラーのダイアログが出る．謎．
ファイルごとのパスワード設定機能とかは必要ないので，とりあえず 1.2 に戻してみた．
_ Java ▲
Java から USB を使えるらしい．JVM さえあれば OS を選ばない，という意味では，能動的にユーザが制御するようなデバイスを作るときにはけっこういいかも．ネイティブコンパイルできるのならカーネルに組み込み……というわけにはいかないんだろうけど（JDK をリンクするとバイナリが大きくなるだろうから）．
http://www-6.ibm.com/jp/developerworks/java/040312/j_j-usb.html
_ コードクローンからのアスペクトマイニングというのが狙っている人はやはりいるらしい．私自身は検討したけれど捨てているのだが． ▲
・どれがアスペクト候補か，というのをどうやって決めるか・うまくアスペクト候補を引き剥がせるか・アスペクト候補に該当するがクローンでないものを どうやって一緒に引き剥がすか・クローンだけれどお互いに関係ないものをどうやって区別するかといった問題山積みなところが気になる．
_ PROSE ▲
Dynamic AOP の実装．ミドルウェアとかに使おうと思っているらしい．しかし，ユビキタス・コンピューティングな世界では，端末が，移動先で（地域的な設定を持った）アスペクトの影響を受ける可能性がある．このとき，アスペクトは，他のベンダーが提供したものである可能性が高いので，セキュリティ上の問題などがかなり大きいように思われるので，そのあたりに研究ネタがありそう．……という話を，某企業から東工大に出かけている人がしていた．
_ Fragile Base Code Problem ▲
ベース（通常はクラス）コードが変更されて，Join points が変化し，アスペクトの pointcut 定義がうまく動かなくなって，プログラムが壊れてしまう問題．
これに対して，semantic join points のような，もっと違う「何か」を使おう，という動きがある．region アプローチなどは，システムの状態に注目しているので，ある意味では semantic join points に属するのかもしれない．
_ AOSD ▲
AOSD 2004 Technical Papers: Languages II
Maja D'Hondt, Viviane Jonckers:Hybrid Aspects for Weaving Object-Oriented Functionality and Rule-Based Knowledge.
business rule を論理型言語(prolog)で書いて，メインプログラムはオブジェクト指向(smalltalk)で書いて，メソッド呼び出しに対して assert や query のような論理型言語が得意とする部分を実行させる，らしい．効果のほどは不明．
メソッドのパラメータなどが prolog 側にどう渡されるか，といったGeneral Model がよく分からない，といった指摘が出ていた．
Remi Douence, Pascal Fradet, Mario Sudholt:Composition, Reuse and Interaction Analysis of Stateful Aspects.
Aspect Interaction を真面目に取り扱っている数少ない人たち．この人たちは，ベースプログラムと，アスペクトの実行はまったく別のものだ，と考えているよう．同じ join point で複数のアドバイスが動くとき，干渉であると考えている．
また，「ひとつのアスペクトは必ずしも *すべての* アプリケーションで動く必要はない」と言っている点もえらいところかも．
ベースプログラムを，正規言語のようなものに直して，アスペクトとくっつけて，問題が起きないか調べましょう，という形式的手法を用いたアプローチ．
この手の形式手法は，どう動くのか直観的でないので，有効性についてもあまり考えられないのだが，もうちょっと，形式手法，制約言語といった系統のベースプログラムが壊れない，アスペクトが壊れないといったことを調べる人には頑張ってほしいところ．
_ AOSD ▲
AOSD 2004 Technical Papers: Applications II
Charles Haley, Robin Laney, Bashar Nuseibeh:Deriving Security Requirementsfrom Crosscutting Threat Descriptions.
「脅威」を { (action, harm), asset } と定義して，要求と，それに対応するドメイン要素，エンティティをインタフェースで相互に接続し，問題が起きるかどうかを考えよう，というもの．
あまり縁がない分野だったりするので効果のほどはよくわからないが．脅威を明示する，というタイプの手法なので，Potential Problem については対処できない．たとえば，金庫の鍵がないと金庫は開けられない，ということは明示できるが，鍵の管理に問題がある可能性に気づくことはない，らしい．
_ AOSD ▲
Bruno Harbulot, John Gurd:Using AspectJ to Separate Concernsin Parallel Scientific Java Code.
Java コードを，並列処理(MPI)な部分だけをアスペクト化した，という論文．しかし，スレッドが増えると，同期コードのコストが上がって高速化されていなかったり，どうも取り上げている例が悪いような気がする．ちょっと残念．
_ AOSD Invited Paper ▲
What are the Key issues for Commercial AOP Use - How does AspectWerkz Address them ?Jonas Boner, BEA
AspectWerkz は，XML と xDoclet 的タグ付けを使ってアスペクトを記述する．基本は「多少特殊な情報を付加した」 Java コードという形．そのおかげでIDEは自由に選べるようになっている．
また，AspectWerkz では，AspectJ などで使う pointcuts / advice 以外に，pointcuts--advice 連結の「binding」が増えているところも特徴らしい．
Class loader の管理はけっこう大事だと考えている様子（複数のクラスローダが同時には使えないため）．Runtime Weaving は，unwoven なメソッドの実行にはオーバーヘッドがかからないところが利点である，といっていた．
IDE 等ツール連携に関しては JSR-175 のメタデータ付加によって対応するつもりらしい．また，将来的には AOP をサポートするJVM (JRockit JVM 1.5)，JVMTI ベースの Weaving，Java 1.5 への対応を考えているらしい．
開発環境に対して依存しすぎないように，という立場などは特徴的なところか．今のところ使う必要がないので AspectWerkz を使おうとは思わないが．
_ AOSD ▲
AOSD 2004 Technical Papers: Industry Paper
Miguel Pessoa Monteiro, Joao Miguel Femandes:Object-to-Aspect Refactorings For Feature Extraction.
リファクタリングを行う際に，・ローカル変数への参照の扱い・抽出したアスペクトの配置（可視性）という問題がある，ということを言っている論文．
「どこをアスペクトに追い出すべきか」といった議論とは，論点が違う．可視性の問題には，Encapsulation を守るべきか，Aspect の効果をうまく使うべきか，といった悩ましい問題があるみたい．
