«前の日(04-20) 最新 次の日(04-22)» 追記

netail.net

自作フリーソフトや,ゲームに関する雑記を公開してます.
日記はソフトウェア工学の論文ネタが中心です.

最近のお知らせ (古いものはこちら)


2003-04-21 古い日記からの変換データ

_ カード契約

シティバンクのクリアカード(VISA)を作ってみた.別に他でもいいといえばいいのだが…….とりあえず,学生のうちにいくつか試してみる方針.

それにしても,住所と本人確認のためだけに待ち時間のほうが長い電話をするって馬鹿げてるような気がする.電子署名+住基ネットでの住所確認とかできるようにならないかな.できたらできたで危険な気はするが…….指定された住所と氏名が対応するか yes/no を返すクエリーくらいなら担当してくれてもいいような気がする.


2004-04-21 古い日記からの変換データ

_ 論文

Marek Majkut:Generation of Implementation for the Model Driven Architecture with Syntactic Unit Trees.

なぜかファイルにはさまってた.読み忘れていたのか,それとも読んだが意味がなかったのか.

Syntactic Unit と呼んでいるのはようはテンプレート(スケルトン)コードで,UMLの図からテンプレートの中身を埋めるという話.

どうやって図にコードを対応させるのか,というあたりの具体性があまりない.

_ 論文

査読の都合で,Cohesion 話の論文をチェック.

Jianjun Zhao, Baowen Xu:Measuring Aspect Cohesion.FASE 2004.

・データの依存関係があるか・呼び出し関係があるかといった関係をもとに,スコアを重み付きで足しこんで 0~1 の範囲で計算する.AOP な適用部分は,アドバイスを扱うこととまた inter-type declaration をアスペクトの一部とみなすこと,だろうか.pointcut 定義についての扱いをどうするべきかはけっこう微妙な気がする.「いつ呼ばれるか」という意味では,外側に影響しているだけなので coupling のほうにしか影響しないのかもしれないが,同一 pointcut にふたつのアドバイスが存在する場合のほうがふたつ,関係ないアドバイスがあるよりはcohesion が高いような気もする.少し怪しいが.

_ POPFile

スパムがたいがい多くなってきたので導入してみた.Norton AntiSpam に比べると,いわゆるプロキシとしてがんばってますーという動作方法が明瞭なところと,学習させやすいところが嬉しい.


2005-04-21

_ [AspectJ]サンプル作り

記事掲載用のサンプルをひたすら作る.モジュール化してうれしい例にしないといけないところが難しい.それにしても,AspectJ 1.5M2は,Genericsやannotationもちゃんと使えるし,エラーメッセージもちゃんと出るしで,前に使っていた1.0の時期に比べるとかなり快適になった気がする.

_ [論文]Early Aspect アプローチの分類

Jethro Bakker, Bedir Tekinerdogan, Mehmet Aksit: Characterization of Early Aspects Approaches.

Proceedings of Workshop on Early Aspects 2005, Chicago, Illinois, March 2005.

過去の Early Aspects で登場した要求分析〜設計段階でのアスペクト識別の方法について整理した論文.Early Aspects 関連で調べるときには開始地点としてよさそう.

アスペクトのモデリングは詳細設計レベルで行っているものはあるが,Early Aspect に対して詳しく行っているものはないとか,また取り出されたアスペクトについての評価も行われていないとか,色々研究でまだカバーされてない範囲について言及している.


2008-04-21

_ [論文] データの来歴を分析する

久しぶりに研究関連の話題です.正確には論文じゃなくて CACM の記事ですが.

Luc Moreau et al.: The Provenance of Electronic Data. CACM, Vol.51, No.4, pp.52-58, April 2008. [ACM DL]

Provenance というのは,芸術作品や考古学などで登場する 品物の由来,来歴の意味で, たとえば絵画では,誰がいつ描いて,途中で誰が修復したか, といった情報らしいです. 電子データでも,そのデータがどうやって作られたか(誰が書いたか,どんな元データを使って作ったか,など),誰が所有していたか,などのデータを残すことで,そのデータを安心して使えるだろう,というのが記事の趣旨になります.

来歴データは,SOA システム上で記録するとしたら, サービスの状態,使用しているアルゴリズムなどへの言及や, メッセージの処理順序や時刻,関連についての情報などだと考えられます. そして,たとえばあるメッセージが,別のメッセージへの返信である, 別のメッセージのデータを元に計算されたデータである(M2 = f1(M1))といった 関係を, "is-caused-by","is-response-to" という原因を意味する辺や "is-based-on", "is-justified-by" というデータ依存辺によって, 循環なし有向グラフで表現することができる,と述べています.

データの来歴の使い方については, 記事では病院での医療情報や,科学系の大規模シミュレーションの パラメータや計算プロセスなどの来歴を題材にしています. メーラでよくある「転送済み」「返信済み」みたいなフラグも, 派生データの存在を示すという意味で,来歴の一種かもしれません.

ソフトウェア工学だと,ソフトウェア・タグに話としては似ているし, もっと粒度の小さい履歴を記録しようという人たち (開発者の統合開発環境での振舞いを記録するアプローチとか) にとっても参考になる記事なのではないかと思います. また,「このデータはこういう方法で計算されたよ」という計算 過程を示すという意味では, JAIST の方々の法令工学でやりたいことの1つにも 関連してるかもしれません.