netail.net

_ AspectJ ▲

aosd-discuss メーリングリストで，Concern って何，という話が出ていた．

それに対して，Ana Moreira が次のようにまとめていた．

Message-ID: 00fb01c2ff46$bd31b420$0100a8c0@microrede.pt

List-Archive: http://aosd.net/pipermail/discuss/

Subject: Re: [aosd-discuss] How determine what is crosscuting in requierements level

A concern is anything with interest for a system; therefore, a concern may be a functional requirement or a non-functional requirement. Any requirement(functional or non-nonfunctional) can be described in terms of other (sub)requirements. So, you have requirements at different levels of granularity.

A concern cuts across another concern (is crosscutting) if one is related with the other, or needed in the other.

_ 工事 ▲

家の前でガス管の夜間工事をしてるので，寝不足．派手な音はしないが，ライトの明滅がうっとうしい．

_ 論文 ▲

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 が変化していき，結局，アスペクトの結合順序などに依存した結果となる．

この論文では，アスペクトの適用をコード変換とインタフェース変換に区分していて，インタフェース変換は，インタフェースのメソッド集合を追加するだけなので順序の影響を受けないが，コード変換は順序の影響を受ける．

……ということから，コード変換のほうは開発者が考慮するような環境が望ましく，データフロー解析などが重要になるかもしれない，というふうに主張している．

_ IPSJ ▲

論文２本目が採録決定．これで D が取れる．

_ 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 ...

しかし，実験するときには，その環境で得られた結果が実プロジェクトなどで本当に適用可能かどうか，についてはきちんと吟味する必要がある，ということで話を締めくくっていた．