＃祝メンバー、100名突破。ﾜｰｲ ( ^-^)o-o<※ ☆ ﾊﾟﾝｯ
どうも、管理人です。
最近、業務で Matlab + Simlink っていうブロック線図から、シミュレーションを作成するツールを使って仕事をしています。その前はエディタ使って、Java で Web アプリの構築だったので、最初は結構戸惑いました。・・・・
しかしながら、今でも困惑する事が多いです。なんていうか。「単なるプログラミングだったら、こんな事、楽勝なのに！！」と思うことが多々あります。またモデリングツールを使う場合、配置や配線が落ち葉、蜘蛛の巣にならないように、プログラムでコードをきれいに保つ以上に、モデルの見た目に気を使う割合が多いような気がします。まー、対象がきれいな数式で表現できる場合は数値計算の細かいことを考えずにスッキリ書けるんでそれはそれなりにメリットがあるのかなとも思いますが。（後はツールの使い方に習熟していないと言う理由もあるかもしれませんが）
というわけで、ちと強引な関連付けかも知れませんが、最近は MDA (Model Driven Architechure or Approch ? どっちでしたっけ)って、モデルを書いて、自動的にコード生成する事で生産性をあげようというのが一つの流れらしいですが、本当に？？と疑問に思うことも有ります。例えば、プログラムの場合なら、それなりの xUnit とかテト用のフレームワークも最近は豊富になってきたし、テスト・検証のノウハウも色々と蓄積されてきていると思いますが、MDA の場合は仮に自動生成したソースから、検証過程で何らかの不備（多分に仕様か設計の矛盾に由来する）が見つかっても、それが駆動可能なモデルのどこに由来するのかとか、どの程度研究されているのでしょうか。
やはり見た目の（設計→実装 部分）生産性よりも、システムを組み上ではどのように検証を進めるかが重要だと思う、今日この頃。皆さんのご意見（指摘・反論も歓迎します。）や実際に Visual 系のツールを使うコツなど、書き込んでいただければと思います。
よろしくお願いします。
どうも、管理人です。
最近、業務で Matlab + Simlink っていうブロック線図から、シミュレーションを作成するツールを使って仕事をしています。その前はエディタ使って、Java で Web アプリの構築だったので、最初は結構戸惑いました。・・・・
しかしながら、今でも困惑する事が多いです。なんていうか。「単なるプログラミングだったら、こんな事、楽勝なのに！！」と思うことが多々あります。またモデリングツールを使う場合、配置や配線が落ち葉、蜘蛛の巣にならないように、プログラムでコードをきれいに保つ以上に、モデルの見た目に気を使う割合が多いような気がします。まー、対象がきれいな数式で表現できる場合は数値計算の細かいことを考えずにスッキリ書けるんでそれはそれなりにメリットがあるのかなとも思いますが。（後はツールの使い方に習熟していないと言う理由もあるかもしれませんが）
というわけで、ちと強引な関連付けかも知れませんが、最近は MDA (Model Driven Architechure or Approch ? どっちでしたっけ)って、モデルを書いて、自動的にコード生成する事で生産性をあげようというのが一つの流れらしいですが、本当に？？と疑問に思うことも有ります。例えば、プログラムの場合なら、それなりの xUnit とかテト用のフレームワークも最近は豊富になってきたし、テスト・検証のノウハウも色々と蓄積されてきていると思いますが、MDA の場合は仮に自動生成したソースから、検証過程で何らかの不備（多分に仕様か設計の矛盾に由来する）が見つかっても、それが駆動可能なモデルのどこに由来するのかとか、どの程度研究されているのでしょうか。
やはり見た目の（設計→実装 部分）生産性よりも、システムを組み上ではどのように検証を進めるかが重要だと思う、今日この頃。皆さんのご意見（指摘・反論も歓迎します。）や実際に Visual 系のツールを使うコツなど、書き込んでいただければと思います。
よろしくお願いします。
|
|
|
|
コメント(32)
あと、補足ですが
MDA (Model Driven Architechure でしたね。）は一応、UML 書いて、そこから、そのまま実行可能なコードまで一気に自動的に生成しましょう。っていうのを念頭に置いてます。厳密なセマンティックスが必要な場合は OCL(Object Constrain Language) でカバーするそうですね。
しかし、図的なモデルの中に、宣言的とは言え、形式的な言語を埋め込んでしまうのは、経験的にかえって見通しが悪くなるような気もするのですが、どうなんでしょうか。（Flash + Action Script での開発経験で痛感したんですが、これってかなり乱暴な比喩でしょうか？）
うーん、もし 「MDA に対して君は誤解しているよ」と言う場合、なんかいいリファレンスがあれば、紹介していただけると幸いです。
MDA (Model Driven Architechure でしたね。）は一応、UML 書いて、そこから、そのまま実行可能なコードまで一気に自動的に生成しましょう。っていうのを念頭に置いてます。厳密なセマンティックスが必要な場合は OCL(Object Constrain Language) でカバーするそうですね。
しかし、図的なモデルの中に、宣言的とは言え、形式的な言語を埋め込んでしまうのは、経験的にかえって見通しが悪くなるような気もするのですが、どうなんでしょうか。（Flash + Action Script での開発経験で痛感したんですが、これってかなり乱暴な比喩でしょうか？）
うーん、もし 「MDA に対して君は誤解しているよ」と言う場合、なんかいいリファレンスがあれば、紹介していただけると幸いです。
どうもです。
Tomさん：
与太話、大いに結構です。\(^o^)／
ソフトウェア工学って追及している人とそうでない人のギャップが大きいと思い、このコミュを立ち上げましたので。「雑談から入るソフトウェア工学」をこのコミュの味にしようかと思っています。
アイディアプロセッサですか。確かにそのレベルでも良いかも知れないですね。例えば UML のクラス図から Java のクラスのスケルトンを作るような物は既に存在していたと思います。バージョン管理の関連から考えると、モデルかソースのどちらかを基準にして、片方は一時的な生成物として考えるのが妥当かなと思います。
しかしモデルを基準にすると、なんか実装時に融通きかなそうだし、ソースを基準にすると、モデルを変更した時の変更分のマージが大変そうだし。うーん一長一短。・・・「夢の掛け橋」は「銀の弾丸」と同意語なのか？
さわらさん＞ふとした疑問なんですが、MDAって「UMLを使うCASE」というイメージの延長を想像しても良いんでしょうか？
やはり同じ事を考えて、批判している人たちはいるみたいですね。「車輪の再発明じゃないのか」と
http://www.atmarkit.co.jp/aig/04biz/mda.html の下の方にそんな記述があります。強いて言うなら、CASE がソース生成の効率か、自動生成とリポジトリの構築に重きをおいていたのに対して、MDA はソースよりもモデルを重視しており、ソースはユーザーにあまり意識させないと言うところかもしれないですね。
さわらさん＞Visual系ツール使う時いつも思うのですが、タブレットPCをホワイトボード代わりにして、
ホワイトボードに書いた内容を直接ＰＣに取り込むための機器なら、いろんな文具メーカから出ていますね。あと以前、図形の自動整形ならそうですね。図学（CAD）系の研究をやっている所が新しい入力手法として、スケッチから製図データを作成する研究も有るみたいです。・・・・が製品かされたものはまだ無いのかな。・・
さわらさん＞無線LANで繋がって、それぞれのタブレットPCから一枚の絵を共有出来ればもっと便利？？？
アーキテクチャ・パターンの Black Board パターンは正にそう言ったアプリケーションの為のパターンですね。実装が設計に追いつかない？たしか前に NEC 何とかかんとかって会社が Java ＋ ORB でそんなアプリ組んでいたっけ。
Tomさん：
与太話、大いに結構です。\(^o^)／
ソフトウェア工学って追及している人とそうでない人のギャップが大きいと思い、このコミュを立ち上げましたので。「雑談から入るソフトウェア工学」をこのコミュの味にしようかと思っています。
アイディアプロセッサですか。確かにそのレベルでも良いかも知れないですね。例えば UML のクラス図から Java のクラスのスケルトンを作るような物は既に存在していたと思います。バージョン管理の関連から考えると、モデルかソースのどちらかを基準にして、片方は一時的な生成物として考えるのが妥当かなと思います。
しかしモデルを基準にすると、なんか実装時に融通きかなそうだし、ソースを基準にすると、モデルを変更した時の変更分のマージが大変そうだし。うーん一長一短。・・・「夢の掛け橋」は「銀の弾丸」と同意語なのか？
さわらさん＞ふとした疑問なんですが、MDAって「UMLを使うCASE」というイメージの延長を想像しても良いんでしょうか？
やはり同じ事を考えて、批判している人たちはいるみたいですね。「車輪の再発明じゃないのか」と
http://www.atmarkit.co.jp/aig/04biz/mda.html の下の方にそんな記述があります。強いて言うなら、CASE がソース生成の効率か、自動生成とリポジトリの構築に重きをおいていたのに対して、MDA はソースよりもモデルを重視しており、ソースはユーザーにあまり意識させないと言うところかもしれないですね。
さわらさん＞Visual系ツール使う時いつも思うのですが、タブレットPCをホワイトボード代わりにして、
ホワイトボードに書いた内容を直接ＰＣに取り込むための機器なら、いろんな文具メーカから出ていますね。あと以前、図形の自動整形ならそうですね。図学（CAD）系の研究をやっている所が新しい入力手法として、スケッチから製図データを作成する研究も有るみたいです。・・・・が製品かされたものはまだ無いのかな。・・
さわらさん＞無線LANで繋がって、それぞれのタブレットPCから一枚の絵を共有出来ればもっと便利？？？
アーキテクチャ・パターンの Black Board パターンは正にそう言ったアプリケーションの為のパターンですね。実装が設計に追いつかない？たしか前に NEC 何とかかんとかって会社が Java ＋ ORB でそんなアプリ組んでいたっけ。
続きです。
yoshiさん：
MOF(Meta Object Facility) って、最初は UML で UML（の拡張部分？）を定義づけしようというモデルじゃなかったでしょうか。それが他のモデルの意味論を UML で定義してそれをメタモデルと呼ぶなら、結局はそのモデルは UML は変換可能になるの（はずですよね？違う？）で、間接的ですが、UML ベースの MDA に行くような気もしますが、どうなんでしょう？
某コミュニティで話題沸騰中の DSL ですか。うーんまだよう分からないのですが、 DSL の Language ってのはドメインに特化したプログラム言語の事なんでしょうか。それとも UML が Language と名乗っているように、やはり図的な物であり、仕様や分析や設計を記述するための物なのでしょうか。この辺はまだ今ひとつピンときません。
またまた非常に乱暴な表現をするなら、例えば、事務処理系のアプリケーションを作成する際には、汎用的な Java よりも事務処理に強いし、オブジェクト指向もカバーしている Object COBOL を使った方が良いという話なのかな。（科学技術計算なら、Fortran 95とか ）・・・
Yoshiさん＞ 自分で言語を作ることができる「コンパイラコンパイラ」は，DSL実現のためのツールということができると思っています．
と言う事は、やはり実装用のプログラム言語の方なんでしょうね。
＃やはり .NET の特色を生かそうと言う事なんだろうか。
Yoshi さん＞どっちかっていうと，モデルとコードのトレーサビリティを重要視しているようです．
これは前の tom さんへの返事も書きましたが、バージョン管理の面で少々厄介な問題をはらんでいそうですね。
yoshiさん：
MOF(Meta Object Facility) って、最初は UML で UML（の拡張部分？）を定義づけしようというモデルじゃなかったでしょうか。それが他のモデルの意味論を UML で定義してそれをメタモデルと呼ぶなら、結局はそのモデルは UML は変換可能になるの（はずですよね？違う？）で、間接的ですが、UML ベースの MDA に行くような気もしますが、どうなんでしょう？
某コミュニティで話題沸騰中の DSL ですか。うーんまだよう分からないのですが、 DSL の Language ってのはドメインに特化したプログラム言語の事なんでしょうか。それとも UML が Language と名乗っているように、やはり図的な物であり、仕様や分析や設計を記述するための物なのでしょうか。この辺はまだ今ひとつピンときません。
またまた非常に乱暴な表現をするなら、例えば、事務処理系のアプリケーションを作成する際には、汎用的な Java よりも事務処理に強いし、オブジェクト指向もカバーしている Object COBOL を使った方が良いという話なのかな。（科学技術計算なら、Fortran 95とか ）・・・
Yoshiさん＞ 自分で言語を作ることができる「コンパイラコンパイラ」は，DSL実現のためのツールということができると思っています．
と言う事は、やはり実装用のプログラム言語の方なんでしょうね。
＃やはり .NET の特色を生かそうと言う事なんだろうか。
Yoshi さん＞どっちかっていうと，モデルとコードのトレーサビリティを重要視しているようです．
これは前の tom さんへの返事も書きましたが、バージョン管理の面で少々厄介な問題をはらんでいそうですね。
今晩は。ソフトウェア工学コミュもいつの間にか人数が増えて本当に嬉しいです。私が入ったころには25人くらいしかいなかったような記憶があります。未熟者ですが、今後ともよろしくお願いいたします。
それはそうと…
> しかしモデルを基準にすると、なんか実装時に融通きかなそうだし、ソースを基準にすると、モデルを変更した時の変更分のマージが大変そうだし。うーん一長一短。・・・「夢の掛け橋」は「銀の弾丸」と同意語なのか？
MDA知らないので、この辺りについてお伺いしたいです。あまりモデルが詳細だと結局コードとの整合性の問題が大きくなるような気がします。この問題はモデル→ソースコードという方向の変更しか許さないのであれば大丈夫だと思うのですが、MDAはそういう趣旨なんでしょうか？もしそうだとしたら結局ソースコードは要らない、という思想に行き着くことになると思います。
ただし、UMLで記述しようがJavaだろうが、そもそも実行できるほど詳細な情報を持ったものは既に抽象度が低すぎてモデルと呼べないような気がします。モデルというものは詳細な情報を捨てるのと引き換えに本質的な性質なり仕組みのみを表現し、人間の理解の一助となったり検証の材料として使いやすくなるところに妙味があるのだと思っておりました。実行可能なほど詳細なUMLの記述はソースコードに対してどのような抽象化を与えているのでしょうか？抽象化によってプログラム理解や検証や、ひいては保守なんかがしやすくなるのでしょうか？
それはそうと…
> しかしモデルを基準にすると、なんか実装時に融通きかなそうだし、ソースを基準にすると、モデルを変更した時の変更分のマージが大変そうだし。うーん一長一短。・・・「夢の掛け橋」は「銀の弾丸」と同意語なのか？
MDA知らないので、この辺りについてお伺いしたいです。あまりモデルが詳細だと結局コードとの整合性の問題が大きくなるような気がします。この問題はモデル→ソースコードという方向の変更しか許さないのであれば大丈夫だと思うのですが、MDAはそういう趣旨なんでしょうか？もしそうだとしたら結局ソースコードは要らない、という思想に行き着くことになると思います。
ただし、UMLで記述しようがJavaだろうが、そもそも実行できるほど詳細な情報を持ったものは既に抽象度が低すぎてモデルと呼べないような気がします。モデルというものは詳細な情報を捨てるのと引き換えに本質的な性質なり仕組みのみを表現し、人間の理解の一助となったり検証の材料として使いやすくなるところに妙味があるのだと思っておりました。実行可能なほど詳細なUMLの記述はソースコードに対してどのような抽象化を与えているのでしょうか？抽象化によってプログラム理解や検証や、ひいては保守なんかがしやすくなるのでしょうか？
モデルを中心とするか、コードを中心とするかはアプローチの違いですから、どちらがいいかの優劣はプロジェクトの初期の戦略決定に依存するでしょう。ただ、ソフトウェア資産の対象としてのコードは、プログラマの意図の伝達がしにくいこと、実装に依存する部分の保守性の抽象化への対応が弱いことが問題となるでしょう。しかし、アジャイルの観点では有利です。大規模化とアジャイルの双方の利点を生かすためには、大規模化のアーキテクチャの固定部分を確立して、スコープの限定された範囲でアジャイルな開発をコードベースで行うのが最近の傾向です。ですから、プロダクトライン（ソフトウェアファミリ）を適切なソフトウェアアーティファクトで構築して、可変部分をアジャイルで開発します。
DSLはアーキテクチャ部分の確立でのドメイン分析として有効ですし、可変部分の特定化としても有効だと思います。UMLに限定すると、動と静のモデルの分離のパラダイムにとらわれる制約があるので、DSLとの併用は有効な手段だと思っています。たとえば、フィーチャモデリングはUMLでは困難なドメイン分析の手法です。
MDAを生産性のためでなく、モデルを使った保守性のため、あるいは、モデルによるシステムの可視化のためと捕らえると、コードによる生産性の改善とはまた別の観点でモデルを捕らえることが可能でしょう。ビジュアル化は記法と意味の分離の点では、自由度を持たせつつ、形式論に持ち込めるように直感的な表現能力にはこだわるべきだと思っています。
DSLはアーキテクチャ部分の確立でのドメイン分析として有効ですし、可変部分の特定化としても有効だと思います。UMLに限定すると、動と静のモデルの分離のパラダイムにとらわれる制約があるので、DSLとの併用は有効な手段だと思っています。たとえば、フィーチャモデリングはUMLでは困難なドメイン分析の手法です。
MDAを生産性のためでなく、モデルを使った保守性のため、あるいは、モデルによるシステムの可視化のためと捕らえると、コードによる生産性の改善とはまた別の観点でモデルを捕らえることが可能でしょう。ビジュアル化は記法と意味の分離の点では、自由度を持たせつつ、形式論に持ち込めるように直感的な表現能力にはこだわるべきだと思っています。
どうもです。
コメントありがとうございます。→ hei,Izu-ru さん、まさよしさん tom さん。
tom さん> generic+aspect+α で・・・
確かに、Aspect 指向フレームワークでは、コンパイルなり実行時に、コードを混ぜていますよね（ウィービングって言うんでしたっけ？）。似たような仕組みをモデルの変更分のコードの反映に使えそうですが、さて Join Point はどこだって話しになりそうな。・・・その辺がαですか。
hei, Izu-ruさん>実行可能なほど詳細なUMLの記述はソースコードに対してどのような抽象化を与えているのでしょうか？抽象化によってプログラム理解や検証や、ひいては保守なんかがしやすくなるのでしょうか？
この辺の疑問については同じくです。
私の使っている（ドメインは限定されますが、あくまで一つの例として） Matlab + Simulink の場合はブロック線図だけで済む場合は割りと楽なんですが、そうでない場合、
＋プログラムちっくフローを実現させるためのブロックを入れる。ブロックとしての機能の粒度（＝抽象度かな）が本来のブロックよりは細かいために、その部分のモデルとしての可読性は一気に下がります。この辺で普通にプログラムを書いた方がよほど楽だと叫びたくなる原因です。
＋拡張用の仕組みを作って、自分で新規にブロックを作る。→簡単な入出力形式の関数（中の処理は幾ら複雑でも良い。）な場合は楽だけど、共有メモリへのアクセスとか副作用が伴うような物については、下手なことすると Simulink のフレームワーク全体の整合性が崩れてしまいます。いたるところ地雷だらけなので、結局全体の枠組みを理解するのも面倒なので、あまりその方法は使わない事にしています。そう結局ドメイン（この場合は制御系モデルという）が限定されてしまうんですよね。
コメントありがとうございます。→ hei,Izu-ru さん、まさよしさん tom さん。
tom さん> generic+aspect+α で・・・
確かに、Aspect 指向フレームワークでは、コンパイルなり実行時に、コードを混ぜていますよね（ウィービングって言うんでしたっけ？）。似たような仕組みをモデルの変更分のコードの反映に使えそうですが、さて Join Point はどこだって話しになりそうな。・・・その辺がαですか。
hei, Izu-ruさん>実行可能なほど詳細なUMLの記述はソースコードに対してどのような抽象化を与えているのでしょうか？抽象化によってプログラム理解や検証や、ひいては保守なんかがしやすくなるのでしょうか？
この辺の疑問については同じくです。
私の使っている（ドメインは限定されますが、あくまで一つの例として） Matlab + Simulink の場合はブロック線図だけで済む場合は割りと楽なんですが、そうでない場合、
＋プログラムちっくフローを実現させるためのブロックを入れる。ブロックとしての機能の粒度（＝抽象度かな）が本来のブロックよりは細かいために、その部分のモデルとしての可読性は一気に下がります。この辺で普通にプログラムを書いた方がよほど楽だと叫びたくなる原因です。
＋拡張用の仕組みを作って、自分で新規にブロックを作る。→簡単な入出力形式の関数（中の処理は幾ら複雑でも良い。）な場合は楽だけど、共有メモリへのアクセスとか副作用が伴うような物については、下手なことすると Simulink のフレームワーク全体の整合性が崩れてしまいます。いたるところ地雷だらけなので、結局全体の枠組みを理解するのも面倒なので、あまりその方法は使わない事にしています。そう結局ドメイン（この場合は制御系モデルという）が限定されてしまうんですよね。
続きです。
まさよしさん>ソフトウェア資産の対象としてのコードは、プログラマの意図の伝達がしにくいこと、実装に依存する部分の保守性の抽象化への対応が弱いことが問題となるでしょう。
確かに、フレームワークの部分なんかのコードは一筋縄じゃ行かないケースも多くややこしいですね。その場合は全体の設計モデルで理解した方が容易でしょうね。あと、「実装に依存する部分の保守性」ってのは、例えば、「データベースとして、RDBMS か XMLDB のどちらを使うか」って話でしょうか。その場合は単純に入出力関係を把握して、ブラックボックス（いわいる部品）として見れば良いような気もしますが。確かに Java で JDBC を使いこなそうと思うとそれなりに JDBC & SQL の世界を理解しないといけないし（抽象度はむしろ低いか。）、それを自分の必要とするデータ操作のロジックに反映させないといけないし。割りと面倒（慣れてしまえば関係ないと言う話もあります）そういう意味でしょうか。
そう言えば、JDBC に関連してよく、Object- Relational マッピングにおける、ミスマッチがどうのこうのって話がありますが、確かに作りたいアプリの本質とは関係ないけど、実装手法にプログラムが引きずられているし、RDBMS + SQL という世界も一緒に考えないといけないので。見通しは良くないですね。
まさよしさん＞UMLに限定すると、動と静のモデルの分離のパラダイムにとらわれる制約があるので、DSLとの併用は有効な手段だと思っています。たとえば、フィーチャモデリングはUMLでは困難なドメイン分析の手法です。
うーん、まさよしさんの日記も拝見させて頂いて、少し考えてみたのですが、結局、これって UML がオブジェクト指向土台にしたモデリング手法だからって事でしょうか。アスペクト指向など、オブジェクト指向を相補的な概念がプログラミングの世界から出てきていると思いますが、UML への反映はされていないですね。そうしたオブジェクト指向外の概念も使ってモデル化を行うなら、何らかの補完するようなモデル化技法が必要なような気もします。
まさよしさん>ソフトウェア資産の対象としてのコードは、プログラマの意図の伝達がしにくいこと、実装に依存する部分の保守性の抽象化への対応が弱いことが問題となるでしょう。
確かに、フレームワークの部分なんかのコードは一筋縄じゃ行かないケースも多くややこしいですね。その場合は全体の設計モデルで理解した方が容易でしょうね。あと、「実装に依存する部分の保守性」ってのは、例えば、「データベースとして、RDBMS か XMLDB のどちらを使うか」って話でしょうか。その場合は単純に入出力関係を把握して、ブラックボックス（いわいる部品）として見れば良いような気もしますが。確かに Java で JDBC を使いこなそうと思うとそれなりに JDBC & SQL の世界を理解しないといけないし（抽象度はむしろ低いか。）、それを自分の必要とするデータ操作のロジックに反映させないといけないし。割りと面倒（慣れてしまえば関係ないと言う話もあります）そういう意味でしょうか。
そう言えば、JDBC に関連してよく、Object- Relational マッピングにおける、ミスマッチがどうのこうのって話がありますが、確かに作りたいアプリの本質とは関係ないけど、実装手法にプログラムが引きずられているし、RDBMS + SQL という世界も一緒に考えないといけないので。見通しは良くないですね。
まさよしさん＞UMLに限定すると、動と静のモデルの分離のパラダイムにとらわれる制約があるので、DSLとの併用は有効な手段だと思っています。たとえば、フィーチャモデリングはUMLでは困難なドメイン分析の手法です。
うーん、まさよしさんの日記も拝見させて頂いて、少し考えてみたのですが、結局、これって UML がオブジェクト指向土台にしたモデリング手法だからって事でしょうか。アスペクト指向など、オブジェクト指向を相補的な概念がプログラミングの世界から出てきていると思いますが、UML への反映はされていないですね。そうしたオブジェクト指向外の概念も使ってモデル化を行うなら、何らかの補完するようなモデル化技法が必要なような気もします。
面白い話題で書きたい事は山ほどあるのですが、ちょっとだけコメントを致します。
OOの手法というのは予め予期できる類の変更や再利用（Basili先生に言わせると変更と再利用は裏表の関係にあるそうですが）には強いと思います。一方、私が今興味があるのはcode scavengingとか予期せぬ仕様変更でありまして。そういう問題に対してOO的な手法は有効なんだろうか？という問題意識を持って今回の議論に参加しております。
ハムレットさん：
静的な構造は図で表した方がすっきりすると思うのですが、ハムレットさんが15番目のコメントで例に挙げていらっしゃるような動的な振る舞いはプログラムで書こうが図（モデルが図式で表現されていると仮定してますが）で描こうが問題の難しさは同じではないかと愚考する次第であります。
それから、図がある程度大きくなるとレイアウトのような視覚的な情報が理解しやすさという点で重要になると思います。これは文字で記述されたプログラムとの大きな違いだと思います。（プログラムでもインデントとかはありますが）
まさよしさんが
> ソフトウェア資産の対象としてのコードは、プログラマの意図の伝達がしにくい
とおっしゃる点は同意いたします。フレームワークでhot spotがどう設定されているか、なんて情報は確かに図で表した方が見通しがよいと思います。でもプログラマの意図というのはhot spotだけじゃないですよね？ソフトウェアの汚い部分や複雑な箇所を記述する場合には、単に文字から図へと表現方法を変えても問題の難しさには変わりがないと思いますし、図上の要素の配置とかそういう本質的じゃないところで意図の伝達が阻害されるようなこともあるのではないかと思っております。
アスペクト指向に関しては良く分からないです。お恥ずかしい話なのですが、勉強不足なので何がアスペクトなのか、その定義すら自分の中ではっきり固まっていない体たらくで…
OOの手法というのは予め予期できる類の変更や再利用（Basili先生に言わせると変更と再利用は裏表の関係にあるそうですが）には強いと思います。一方、私が今興味があるのはcode scavengingとか予期せぬ仕様変更でありまして。そういう問題に対してOO的な手法は有効なんだろうか？という問題意識を持って今回の議論に参加しております。
ハムレットさん：
静的な構造は図で表した方がすっきりすると思うのですが、ハムレットさんが15番目のコメントで例に挙げていらっしゃるような動的な振る舞いはプログラムで書こうが図（モデルが図式で表現されていると仮定してますが）で描こうが問題の難しさは同じではないかと愚考する次第であります。
それから、図がある程度大きくなるとレイアウトのような視覚的な情報が理解しやすさという点で重要になると思います。これは文字で記述されたプログラムとの大きな違いだと思います。（プログラムでもインデントとかはありますが）
まさよしさんが
> ソフトウェア資産の対象としてのコードは、プログラマの意図の伝達がしにくい
とおっしゃる点は同意いたします。フレームワークでhot spotがどう設定されているか、なんて情報は確かに図で表した方が見通しがよいと思います。でもプログラマの意図というのはhot spotだけじゃないですよね？ソフトウェアの汚い部分や複雑な箇所を記述する場合には、単に文字から図へと表現方法を変えても問題の難しさには変わりがないと思いますし、図上の要素の配置とかそういう本質的じゃないところで意図の伝達が阻害されるようなこともあるのではないかと思っております。
アスペクト指向に関しては良く分からないです。お恥ずかしい話なのですが、勉強不足なので何がアスペクトなのか、その定義すら自分の中ではっきり固まっていない体たらくで…
hei, Izu-ru さん>
>アスペクト指向に関しては良く分からないです。お恥ずかしい話なのですが、勉強不足なので何がアスペクトなのか、その定義すら自分の中ではっきり固まっていない体たらくで…
実際、私もアスペクト指向を知って間もないときは、アスペクトは概念であることに気付かずに、アスペクト指向とは単なる実装手段だと思っていた時期がありました。
アスペクトの理解には、Edsger Wybe. Dijkstra の有名な原則である 関心事の分離 (Separation of Concerns) がポイントとなると思います。
アスペクト指向についてありがちな説明ですが、少しだけ。
OOPも異なる関心事を分離する有効な手段でしたが、クラスやオブジェクト間にまたがる関心事 = 横断的関心事(crosscutting concern) は分離しきれないといった面があります。ロギング、セキュリティ、トランザクション、セッション管理、プロファイリングなどが横断的関心事にあたります。このような従来での手法で解決できない横断的関心事の分離は、Advanced Separation of Concerns(ASOC)と呼ばれ、アスペクト指向プログラミング(AOP)はASOCを達成するためのパラダイムです。
また、アスペクトとはこのような複数のモジュールにまだがる横断的な視点(観点としての視点)そのものを指し示す概念だと思っています。
>アスペクト指向に関しては良く分からないです。お恥ずかしい話なのですが、勉強不足なので何がアスペクトなのか、その定義すら自分の中ではっきり固まっていない体たらくで…
実際、私もアスペクト指向を知って間もないときは、アスペクトは概念であることに気付かずに、アスペクト指向とは単なる実装手段だと思っていた時期がありました。
アスペクトの理解には、Edsger Wybe. Dijkstra の有名な原則である 関心事の分離 (Separation of Concerns) がポイントとなると思います。
アスペクト指向についてありがちな説明ですが、少しだけ。
OOPも異なる関心事を分離する有効な手段でしたが、クラスやオブジェクト間にまたがる関心事 = 横断的関心事(crosscutting concern) は分離しきれないといった面があります。ロギング、セキュリティ、トランザクション、セッション管理、プロファイリングなどが横断的関心事にあたります。このような従来での手法で解決できない横断的関心事の分離は、Advanced Separation of Concerns(ASOC)と呼ばれ、アスペクト指向プログラミング(AOP)はASOCを達成するためのパラダイムです。
また、アスペクトとはこのような複数のモジュールにまだがる横断的な視点(観点としての視点)そのものを指し示す概念だと思っています。
あけましておめでとうございます。
昨年は論議への参加、有益な情報の提供などありがとうございました。
本年もどうかよろしくお願いいたします。
アスペクト指向の概略説明ありがとうございました。→ tsune さん
では私も補足を少し、
もともと、Aspect Oriented Programming は Xerox の PARC で1990年代の後半から研究されてきたものです。Aspect 指向の研究の動機づけは、tsune さんがかかれているように、ロギングやセキュリティなどドメイン非依存の非機能要件の実装が、クラスやオブジェクトといったオブジェクト指向における基本モジュールに横断的に関わってしまうことを、どのようにきれいに扱うかといった問題からでした。
元々非機能要件が横断的になるは当たり前の話で、要件定義からシステム分析→設計の流れで、クラスというモジュールを構成・定義づける主な基準はやはりシステムの対象となるドメインのデータ構造や機能構成です。ロギングやセキュリティといった非機能要件は全てこうしたドメインのモデル化とは直交した（独立した）概念になります。つまり、対象となるモデル中のどこにでも、非機能要件のモジュールを組みこむ事が出来ますし、全体に関わる事も通常です。
オブジェクト指向プログラミングにおいては最初は、こうした非機能要件もログオブジェクト、セキュリティオブジェクト等のオブジェクトとして扱っていましたが、オブジェクトの関連や制約条件、またはメソッドにメッセージ交換は主にドメインやシステム化の対象となるモデルを反映したものです。それらに非機能要件のオブジェクトをどう組み合わせるかについては、まじめにやると煩雑（複数のオブジェクトに関わるデータフローのログ取りを考えてみればよく分かります。）で、ちょっとした変更でもコードの変更点が分散してしまうといった問題が出てきました。しかしながら人情としては、オブジェクトなんだから、出来れば抜き差し可能な（プラグイン可能な）形で連携させたいと考えてしまいます。（元々アプリケーションロジックの本質からは外れますが、運用上は重要です。）
最初の頃は、フィルターパターンによる、メッセージフック用オブジェクトやテンプレートパターンなどのフックメソッドにインターフェイスを使った多態（ポリーモルフィズム）を組み合わせて解決の道を図ろうとしましたが、
＊どこにフックを入れるか、
＊テンプレートをどのように組むか、
＊どのようにクラスを分類するか、
の決定が大変（大抵は運用時に変更される物ですよね。こういうのって）で、結局は実装時における煩雑さを設計に前倒ししただけ終わってしまい、システム化対象のドメインに沿ってきれい作ったはずの設計モデルが実装設計時には汚くなるといった結果で終わりました。
結局はドメイン依存の機能要件と非機能要件では関心のもたれ方が違うので、
・どのオブジェクトに対して（Pointcut ?）
・いつ、どのようなタイミングで非機能要件のメソッドを起動するか。（Join Point）
・どのような処理内容をもつ非機能要件のメソッドを起動するか。（Advice）
を別々に定義づけして、後で組み合わせたらええやん（ウィービング）というアイディアが生まれ、上記３つの関連するまとまった組み合わせの集合体をモジュールとして定義づけ、それをアスペクトと言う名で呼んだと言う事です。
アスペクト指向の動機づけや研究の経緯などに関する論文は以下の Web Site を参照してみてください。色々と面白い情報が得られます。↓
http://www.parc.com/groups/csl/projects/aspectj/
昨年は論議への参加、有益な情報の提供などありがとうございました。
本年もどうかよろしくお願いいたします。
アスペクト指向の概略説明ありがとうございました。→ tsune さん
では私も補足を少し、
もともと、Aspect Oriented Programming は Xerox の PARC で1990年代の後半から研究されてきたものです。Aspect 指向の研究の動機づけは、tsune さんがかかれているように、ロギングやセキュリティなどドメイン非依存の非機能要件の実装が、クラスやオブジェクトといったオブジェクト指向における基本モジュールに横断的に関わってしまうことを、どのようにきれいに扱うかといった問題からでした。
元々非機能要件が横断的になるは当たり前の話で、要件定義からシステム分析→設計の流れで、クラスというモジュールを構成・定義づける主な基準はやはりシステムの対象となるドメインのデータ構造や機能構成です。ロギングやセキュリティといった非機能要件は全てこうしたドメインのモデル化とは直交した（独立した）概念になります。つまり、対象となるモデル中のどこにでも、非機能要件のモジュールを組みこむ事が出来ますし、全体に関わる事も通常です。
オブジェクト指向プログラミングにおいては最初は、こうした非機能要件もログオブジェクト、セキュリティオブジェクト等のオブジェクトとして扱っていましたが、オブジェクトの関連や制約条件、またはメソッドにメッセージ交換は主にドメインやシステム化の対象となるモデルを反映したものです。それらに非機能要件のオブジェクトをどう組み合わせるかについては、まじめにやると煩雑（複数のオブジェクトに関わるデータフローのログ取りを考えてみればよく分かります。）で、ちょっとした変更でもコードの変更点が分散してしまうといった問題が出てきました。しかしながら人情としては、オブジェクトなんだから、出来れば抜き差し可能な（プラグイン可能な）形で連携させたいと考えてしまいます。（元々アプリケーションロジックの本質からは外れますが、運用上は重要です。）
最初の頃は、フィルターパターンによる、メッセージフック用オブジェクトやテンプレートパターンなどのフックメソッドにインターフェイスを使った多態（ポリーモルフィズム）を組み合わせて解決の道を図ろうとしましたが、
＊どこにフックを入れるか、
＊テンプレートをどのように組むか、
＊どのようにクラスを分類するか、
の決定が大変（大抵は運用時に変更される物ですよね。こういうのって）で、結局は実装時における煩雑さを設計に前倒ししただけ終わってしまい、システム化対象のドメインに沿ってきれい作ったはずの設計モデルが実装設計時には汚くなるといった結果で終わりました。
結局はドメイン依存の機能要件と非機能要件では関心のもたれ方が違うので、
・どのオブジェクトに対して（Pointcut ?）
・いつ、どのようなタイミングで非機能要件のメソッドを起動するか。（Join Point）
・どのような処理内容をもつ非機能要件のメソッドを起動するか。（Advice）
を別々に定義づけして、後で組み合わせたらええやん（ウィービング）というアイディアが生まれ、上記３つの関連するまとまった組み合わせの集合体をモジュールとして定義づけ、それをアスペクトと言う名で呼んだと言う事です。
アスペクト指向の動機づけや研究の経緯などに関する論文は以下の Web Site を参照してみてください。色々と面白い情報が得られます。↓
http://www.parc.com/groups/csl/projects/aspectj/
tsuneさん、ハムレットさん、情報ありがとうございます。
実は1997年のECOOP論文を読んだ後にAspcetJのマニュアルに目を通したのですが、なんか両者の内容が、アスペクトの内容とアスペクトの実装の仕方がえらく違っているような気がして混乱していたのでした。
tsuneさん：
> また、アスペクトとはこのような複数のモジュールにまだがる横断的な視点(観点としての視点)そのものを指し示す概念だと思っています。
論文でもそう書いてあったのですが、まだちょっとこの文言は曖昧で定義になっていないと思うのです。
ハムレットさんのおっしゃるようにある種の非機能要件をアスペクトと呼ぶのだと思うのですが、全ての非機能要件がアスペクトなのかというとちょっと違うような気がします。
例えば永続性とかはアスペクトとして捉える事ができるのか、捉える事によってどういう利益が得られるのか、とかちょっと考えただけでは良く分からないです。
アスペクトとして考えられている非機能要件の数が限定されているのなら、個別の対処法があるような気がします。例えばセキュリティに関しても、私は詳しくないのですが、私の周辺でsecure information flowとかやっている（やってるのかな？）人がいたような気がします。
と色々書きましたが、私もアスペクト指向プログラミングには関心を持っております。アスペクトが何か良く分からないところが面白い、というか、アスペクトとして捉えられる対象が広ければ広いほどその有用性が立証されると思っております。
実は1997年のECOOP論文を読んだ後にAspcetJのマニュアルに目を通したのですが、なんか両者の内容が、アスペクトの内容とアスペクトの実装の仕方がえらく違っているような気がして混乱していたのでした。
tsuneさん：
> また、アスペクトとはこのような複数のモジュールにまだがる横断的な視点(観点としての視点)そのものを指し示す概念だと思っています。
論文でもそう書いてあったのですが、まだちょっとこの文言は曖昧で定義になっていないと思うのです。
ハムレットさんのおっしゃるようにある種の非機能要件をアスペクトと呼ぶのだと思うのですが、全ての非機能要件がアスペクトなのかというとちょっと違うような気がします。
例えば永続性とかはアスペクトとして捉える事ができるのか、捉える事によってどういう利益が得られるのか、とかちょっと考えただけでは良く分からないです。
アスペクトとして考えられている非機能要件の数が限定されているのなら、個別の対処法があるような気がします。例えばセキュリティに関しても、私は詳しくないのですが、私の周辺でsecure information flowとかやっている（やってるのかな？）人がいたような気がします。
と色々書きましたが、私もアスペクト指向プログラミングには関心を持っております。アスペクトが何か良く分からないところが面白い、というか、アスペクトとして捉えられる対象が広ければ広いほどその有用性が立証されると思っております。
まさよしくんさん：
日記を拝読いたしました。なるほど、アスペクトとして考えるべき事柄は広範囲に渡っているのですね。例えば
> データ駆動型のメッセージ処理のスコープはすべてアスペクトです。
とありますが、これはデータを中心に繋がっているからでしょうか？
アスペクトとは
「開発に参加する者たちの頭の中では一つの事柄として存在するが、設計や実装上では複数の構成要素間に横断的に（分断されて）存在するように表現されてしまうもの」
という理解でよろしいのでしょうか？
以下、そうだとして話を進めます。
アスペクトという概念は別にプログラムコード中だけではなくて、例えばユースケース図などにも登場するわけですね。
ただ、ちょっと疑問に思ったのですが、こういう定義（私の理解が正しいとして）ですとアスペクトとして考えられる対象があまりにも広くなりすぎないでしょうか？しかも同じアスペクトでもモデルの抽象度が違うとまた違う表現になったりしないのでしょうか？
これもアスペクト、あれもアスペクト、でも問題の対処法はそれぞれ違う、ということにならないかなあ、と思ったりしたのですが…
アスペクトという用語を用いて
> デザインパターンの置き換えや機能要件に対するドメイン分析、分割ドメインの実装における複合化の支援機能
という問題に対する統一的な対処法が構築できる、というのがまさよしくんさんのお考えなのでしょうか？
日記を拝読して、ソフトウェア開発におけるアスペクトの位置づけは数学の世界に於けるカテゴリー理論のような気がしてきました。どっちもちょっとかじっただけですが。
日記を拝読いたしました。なるほど、アスペクトとして考えるべき事柄は広範囲に渡っているのですね。例えば
> データ駆動型のメッセージ処理のスコープはすべてアスペクトです。
とありますが、これはデータを中心に繋がっているからでしょうか？
アスペクトとは
「開発に参加する者たちの頭の中では一つの事柄として存在するが、設計や実装上では複数の構成要素間に横断的に（分断されて）存在するように表現されてしまうもの」
という理解でよろしいのでしょうか？
以下、そうだとして話を進めます。
アスペクトという概念は別にプログラムコード中だけではなくて、例えばユースケース図などにも登場するわけですね。
ただ、ちょっと疑問に思ったのですが、こういう定義（私の理解が正しいとして）ですとアスペクトとして考えられる対象があまりにも広くなりすぎないでしょうか？しかも同じアスペクトでもモデルの抽象度が違うとまた違う表現になったりしないのでしょうか？
これもアスペクト、あれもアスペクト、でも問題の対処法はそれぞれ違う、ということにならないかなあ、と思ったりしたのですが…
アスペクトという用語を用いて
> デザインパターンの置き換えや機能要件に対するドメイン分析、分割ドメインの実装における複合化の支援機能
という問題に対する統一的な対処法が構築できる、というのがまさよしくんさんのお考えなのでしょうか？
日記を拝読して、ソフトウェア開発におけるアスペクトの位置づけは数学の世界に於けるカテゴリー理論のような気がしてきました。どっちもちょっとかじっただけですが。
あけましておめでとうございます。
本年もどうぞよろしくお願いいたします。
アスペクト指向については大変興味があるのですが、少し勉強しただけなので理解が間違っている点等あれば、どんどん指摘していただければと思います。
AOPとアスペクトについては、たとえば、情報処理の2002年3月号に「AOPにおけるアスペクトについて議論する」という Communications of the ACM での議論の翻訳記事が載っているので、それが参考になるかもしれません。
その中で私が重要と思うポイントについて１つ。
「横断的という概念がある特定の分割方法に関係していることが重要です.」
「何が何を横断するのかを理解する ...中略... には, 支配的分割(dominant decomposition)の概念が役立つと思います.」
とあるように、アスペクト(というか横断的関心事)は、オブジェクト指向でも何でもいいですがある種の分割法を補う形で導入されるという点です。つまりアスペクト指向は他の技術と独立に定義できる概念ではないはずです。
ただ、そういうアスペクト指向の理想に現状のAOPが十分に答えれているかというとどうかな？と思っています。以前、AspectJの本を読んだときに理想と現実（Pointcut, Join Point, Adviceを用いたアプローチ）の間に大きなギャップがあるように感じました。
本年もどうぞよろしくお願いいたします。
アスペクト指向については大変興味があるのですが、少し勉強しただけなので理解が間違っている点等あれば、どんどん指摘していただければと思います。
AOPとアスペクトについては、たとえば、情報処理の2002年3月号に「AOPにおけるアスペクトについて議論する」という Communications of the ACM での議論の翻訳記事が載っているので、それが参考になるかもしれません。
その中で私が重要と思うポイントについて１つ。
「横断的という概念がある特定の分割方法に関係していることが重要です.」
「何が何を横断するのかを理解する ...中略... には, 支配的分割(dominant decomposition)の概念が役立つと思います.」
とあるように、アスペクト(というか横断的関心事)は、オブジェクト指向でも何でもいいですがある種の分割法を補う形で導入されるという点です。つまりアスペクト指向は他の技術と独立に定義できる概念ではないはずです。
ただ、そういうアスペクト指向の理想に現状のAOPが十分に答えれているかというとどうかな？と思っています。以前、AspectJの本を読んだときに理想と現実（Pointcut, Join Point, Adviceを用いたアプローチ）の間に大きなギャップがあるように感じました。
どうもです。
活発なご意見ありがとうございます。→ まさよしさん、 hei, Izu-ruさん、おとんさん。
確かにまさよしさんが日記にも書かれていたように、アスペクトは概念であり、AOP はアスペクトを思想的な土台にしたプログラム技術ですね。この辺は概念としてのオブジェクトとOOPの違いみたいなものでしょうか。前の私の説明でアスペクトの説明を非機能要件を使って行いましたが、確かにあれは AOP（もとい AspectJ か）でのアスペクト（英語で書くなら Apsect でしょうね。）の説明であって、概念としてのアスペクト（こっちは aspect かな）を AspectJ の世界で限定したものですね。
そういう意味で
hei izu-ru さん>実は1997年のECOOP論文を読んだ後にAspcetJのマニュアルに目を通したのですが、なんか両者の内容が、アスペクトの内容とアスペクトの実装の仕方がえらく違っているような気がして混乱していたのでした。
おとんさん>以前、AspectJの本を読んだときに理想と現実（Pointcut, Join Point, Adviceを用いたアプローチ）の間に大きなギャップがあるように感じました。
ってのは、むしろ誰しもが思う事のように思えます。そういう意味では、アスペクト指向技術はまさよしさんが言うように、まだまだ発展途上な技術だと思います。
あと、幾つか思うところがあるのですが、長くなるので一旦、切ります。
活発なご意見ありがとうございます。→ まさよしさん、 hei, Izu-ruさん、おとんさん。
確かにまさよしさんが日記にも書かれていたように、アスペクトは概念であり、AOP はアスペクトを思想的な土台にしたプログラム技術ですね。この辺は概念としてのオブジェクトとOOPの違いみたいなものでしょうか。前の私の説明でアスペクトの説明を非機能要件を使って行いましたが、確かにあれは AOP（もとい AspectJ か）でのアスペクト（英語で書くなら Apsect でしょうね。）の説明であって、概念としてのアスペクト（こっちは aspect かな）を AspectJ の世界で限定したものですね。
そういう意味で
hei izu-ru さん>実は1997年のECOOP論文を読んだ後にAspcetJのマニュアルに目を通したのですが、なんか両者の内容が、アスペクトの内容とアスペクトの実装の仕方がえらく違っているような気がして混乱していたのでした。
おとんさん>以前、AspectJの本を読んだときに理想と現実（Pointcut, Join Point, Adviceを用いたアプローチ）の間に大きなギャップがあるように感じました。
ってのは、むしろ誰しもが思う事のように思えます。そういう意味では、アスペクト指向技術はまさよしさんが言うように、まだまだ発展途上な技術だと思います。
あと、幾つか思うところがあるのですが、長くなるので一旦、切ります。
続きです。
hei Izu-ru さん>ハムレットさんのおっしゃるようにある種の非機能要件をアスペクトと呼ぶのだと思うのですが、全ての非機能要件がアスペクトなのかというとちょっと違うような気がします。
えーと、書き方が悪かったと思いますが、この辺は非機能要件がドメインのクラス構造に対して横断的に関連する事を使って、アスペクトを説明したのであって、決して非機能要件を以ってアスペクトと成すわけではありません。この辺はまさよしさんのご指摘にある通りです。
では、概念としてのアスペクトについて、とりあえず、あるシステム化の対象のどの部分（concern、ex データ構造、関数的機能表現など）をどのように捉えるか（aspect） という、その捉え方の部分だと思います。論文に載っている例では、今ひとつ説得力に欠けるので、自分の仕事に関連する部分で説明してみます。定義づけよりも例による説明ですんで、多分に大胆に間違いを恐れずに行きます。おかしいと思ったら適当に突っ込んでください。（ただ、概念の説明と言うのは往々にして難しいですよね。おとんさんの紹介して頂いた情報処理学会誌の記事にも結局、横断的関心事の説明はあっても、アスペクトについては明瞭でなかったですし。・・）
Web システムの構築をやっている人なら、大抵の人はデザインとロジックの分離という言葉を聞いた事があると思います。要はシステムのプレゼンテーション層、ユーザーインターフェイスを構築する上で、入出力に対するシステムの反応ロジックとユーザーインターフェイスの（見た目の）デザインを分けて管理しましょうと言う話です。Web でないシステムの場合は、U I/F のデザインもプログラム中に埋没してしまう事が多かったと思いますが、Web の場合は HTML と言うブラウザ上での画面のデザインを定義する標準化された言語があるので、それを積極的に生かして、プログラムと画面のデザイン定義は分けて行こうという話です。
実際に、仕様を決める際にもやはり見た目と言うのは、サーバーの業務ロジックに関連する機能に比べると変更点が多いですし、画面デザインの制作と入出力への動作ロジックのプログラムでは、要求される技能、才能も違います。実際に規模が大きく本格的になると、Web デザイナーとプログラマーが分業して作業を行います。
実際に経験したことのある人なら分かりますが、Web デザイナーと プログラマではものの考え方、仕事の進め方、関心事が全然違います。Web デザイナーは見栄えやユーザビリティなどに注意を払いながら仕事を進めますが、プログラマは機能仕様の実現を念頭に置いて進めます。ただシステムとして、デザインと機能は最終的には統合されないといけませんが、この統合過程は、異なる領域に住まうスタッフ間でのコミュニケーションの混乱・断絶と言う意味でも、HTML ファイルとプログラムの2種類の成果物を整合性を保ったまま管理すると言う意味でも大変な作業です。そういう意味で、
＋プログラムが支配的分割を担うなら、HTML 文書はデザインと言う意味でのアスペクトと言えるかも知れません。
＋またさらに画面デザインの中でも、レイアウト、HTML 文書の論理構造が支配的分割を担うとするなら、CSS 文書は画面の修飾（文字の色や枠組みの色、装飾）と言う意味でのアスペクトと言えるかも知れません。
＋ついでに簡便な動的画面のロジック構成を担う JavaScript も HTML ドキュメントに対するある種のアスペクトかもしれないですね。
次にアスペクトに絡ませながら、実装時におけるデザインとロジックの統合についての考察に進みますが、長くなるので一旦切ります。
hei Izu-ru さん>ハムレットさんのおっしゃるようにある種の非機能要件をアスペクトと呼ぶのだと思うのですが、全ての非機能要件がアスペクトなのかというとちょっと違うような気がします。
えーと、書き方が悪かったと思いますが、この辺は非機能要件がドメインのクラス構造に対して横断的に関連する事を使って、アスペクトを説明したのであって、決して非機能要件を以ってアスペクトと成すわけではありません。この辺はまさよしさんのご指摘にある通りです。
では、概念としてのアスペクトについて、とりあえず、あるシステム化の対象のどの部分（concern、ex データ構造、関数的機能表現など）をどのように捉えるか（aspect） という、その捉え方の部分だと思います。論文に載っている例では、今ひとつ説得力に欠けるので、自分の仕事に関連する部分で説明してみます。定義づけよりも例による説明ですんで、多分に大胆に間違いを恐れずに行きます。おかしいと思ったら適当に突っ込んでください。（ただ、概念の説明と言うのは往々にして難しいですよね。おとんさんの紹介して頂いた情報処理学会誌の記事にも結局、横断的関心事の説明はあっても、アスペクトについては明瞭でなかったですし。・・）
Web システムの構築をやっている人なら、大抵の人はデザインとロジックの分離という言葉を聞いた事があると思います。要はシステムのプレゼンテーション層、ユーザーインターフェイスを構築する上で、入出力に対するシステムの反応ロジックとユーザーインターフェイスの（見た目の）デザインを分けて管理しましょうと言う話です。Web でないシステムの場合は、U I/F のデザインもプログラム中に埋没してしまう事が多かったと思いますが、Web の場合は HTML と言うブラウザ上での画面のデザインを定義する標準化された言語があるので、それを積極的に生かして、プログラムと画面のデザイン定義は分けて行こうという話です。
実際に、仕様を決める際にもやはり見た目と言うのは、サーバーの業務ロジックに関連する機能に比べると変更点が多いですし、画面デザインの制作と入出力への動作ロジックのプログラムでは、要求される技能、才能も違います。実際に規模が大きく本格的になると、Web デザイナーとプログラマーが分業して作業を行います。
実際に経験したことのある人なら分かりますが、Web デザイナーと プログラマではものの考え方、仕事の進め方、関心事が全然違います。Web デザイナーは見栄えやユーザビリティなどに注意を払いながら仕事を進めますが、プログラマは機能仕様の実現を念頭に置いて進めます。ただシステムとして、デザインと機能は最終的には統合されないといけませんが、この統合過程は、異なる領域に住まうスタッフ間でのコミュニケーションの混乱・断絶と言う意味でも、HTML ファイルとプログラムの2種類の成果物を整合性を保ったまま管理すると言う意味でも大変な作業です。そういう意味で、
＋プログラムが支配的分割を担うなら、HTML 文書はデザインと言う意味でのアスペクトと言えるかも知れません。
＋またさらに画面デザインの中でも、レイアウト、HTML 文書の論理構造が支配的分割を担うとするなら、CSS 文書は画面の修飾（文字の色や枠組みの色、装飾）と言う意味でのアスペクトと言えるかも知れません。
＋ついでに簡便な動的画面のロジック構成を担う JavaScript も HTML ドキュメントに対するある種のアスペクトかもしれないですね。
次にアスペクトに絡ませながら、実装時におけるデザインとロジックの統合についての考察に進みますが、長くなるので一旦切ります。
続きです。
自分の経験上、話を Java に限定して行います。実際に Web アプリケーションで、プレゼンテーション層の実装（ブラウザに送る HTML フォーマットデータの生成）を行う場合、大体以下の３つのアプローチがあると思います。
１）プログラム中に HTML データを埋め込む（例、System.out.println メソッドで直に タグを書き込む、Jakarta ECS(Element Construction Set) など）
２）HTML ファイルの中にプログラムを埋め込む（例、JSP などのHTML の独自拡張仕様）
３）HTML ファイルと Java のプログラムを適当なインターフェイスモデルを使ってコンパイル時に機械的に統合する。（例、XMLC、PageMixer ）
個人的には、アスペクト指向に一番近いのは、３）だと思います。１）や２）では Web デザイナとプログラマの協業が難しいと思います。画面のデザイン仕様の変更に対して、デザインとロジックが上手く分離していないので、Java プログラムになるか、拡張 HTML ファイルになるかは別ですが、それぞれのファイルの修正は煩雑になります。それは、プログラムロジックと画面デザインと言う関心事（コンサーン）が明らかに違うからでしょう。（XML によるドキュメントモデルと Java のクラスベースのオブジェクト指向モデルの違いと面もある。）文字通り、どちらが支配的になるかは別にして。副次的な物が横断的に存在しているのは事実だと思います。
メジャーな所では ２）の例であげた、JSP の場合は タグライブラリの活用や Strut などのMVC モデルベースのフレームワークとの併用で、何とかその辺の不備を軽減しているとは思いますが、やはり、土台では関心事の分離に失敗しているように思えます。（ただそれを補う利点も有るとは思うのですが。・・）
私自身、最初は JSP ちっくな HTML の中に Java のプログラムを埋め込む形式で、Web アプリの開発を進めていましたが、画面数も多かった事があり、保守や次のバージョンの開発で、散々な目に会ったので、３）の XMLC を利用するようになりました。
XMLC は
＊画面仕様を記述したHTML ファイルから XMLC コンパイラを使って、機械的に DOM (Document Object Model) インターフェイスを使ったアクセスインターフェイスとその実装クラスを生成します。
＊また HTML ファイルの中の id 属性と SPAN タグを利用して、HTML ファイルのうち、仕様上、動的に変更する部分に対する簡易アクセス用メソッドを提供します。
＊Servlet からはアクセス用インターフェイスに対する DOM プロ
グラミングで特定のHTML ページの文書構造をロジックに応じて変更させる事で動的なページ生成を行います。
結局、HTML ファイルに独自の拡張をする事もなく、プログラムとの連携も id 属性と SPAN タグという HTML の標準仕様内で工夫すれば済む話と言う事（この程度なら CSS も使える Web デザイナーなら楽なものです。）で、上手くロジックとデザインを分離できていると思います。実際に保守性は随分向上しました。CSS の積極的な利用も併用すると、デザインの変更に伴うプログラムの変更は劇的に減りましたし、同じように Web デザイナーとプログラマ間のいざこざもかなり減りました。（PageMixer については XMLC が DOM を使っているところが処理効率などを考慮して SAX っぽい物に変っていると言う事です。詳しくは http://pagemixer.sourceforge.net/index.ja.html を参照してください。）
結局、アスペクトと言う観点で見ると、
＋XMLC コンパイラで HTML ファイルを機械的に Java のモジュールに変換できる事（AOP で言う所の ウィービングですか）
＋DOM という標準的なインターフェイスを使っている事。（プログラマに HTML への汎用的で明確なアクセスの手順を定義している。）
事が重要だと言う気がします。
..... To Be Continued ..............
自分の経験上、話を Java に限定して行います。実際に Web アプリケーションで、プレゼンテーション層の実装（ブラウザに送る HTML フォーマットデータの生成）を行う場合、大体以下の３つのアプローチがあると思います。
１）プログラム中に HTML データを埋め込む（例、System.out.println メソッドで直に タグを書き込む、Jakarta ECS(Element Construction Set) など）
２）HTML ファイルの中にプログラムを埋め込む（例、JSP などのHTML の独自拡張仕様）
３）HTML ファイルと Java のプログラムを適当なインターフェイスモデルを使ってコンパイル時に機械的に統合する。（例、XMLC、PageMixer ）
個人的には、アスペクト指向に一番近いのは、３）だと思います。１）や２）では Web デザイナとプログラマの協業が難しいと思います。画面のデザイン仕様の変更に対して、デザインとロジックが上手く分離していないので、Java プログラムになるか、拡張 HTML ファイルになるかは別ですが、それぞれのファイルの修正は煩雑になります。それは、プログラムロジックと画面デザインと言う関心事（コンサーン）が明らかに違うからでしょう。（XML によるドキュメントモデルと Java のクラスベースのオブジェクト指向モデルの違いと面もある。）文字通り、どちらが支配的になるかは別にして。副次的な物が横断的に存在しているのは事実だと思います。
メジャーな所では ２）の例であげた、JSP の場合は タグライブラリの活用や Strut などのMVC モデルベースのフレームワークとの併用で、何とかその辺の不備を軽減しているとは思いますが、やはり、土台では関心事の分離に失敗しているように思えます。（ただそれを補う利点も有るとは思うのですが。・・）
私自身、最初は JSP ちっくな HTML の中に Java のプログラムを埋め込む形式で、Web アプリの開発を進めていましたが、画面数も多かった事があり、保守や次のバージョンの開発で、散々な目に会ったので、３）の XMLC を利用するようになりました。
XMLC は
＊画面仕様を記述したHTML ファイルから XMLC コンパイラを使って、機械的に DOM (Document Object Model) インターフェイスを使ったアクセスインターフェイスとその実装クラスを生成します。
＊また HTML ファイルの中の id 属性と SPAN タグを利用して、HTML ファイルのうち、仕様上、動的に変更する部分に対する簡易アクセス用メソッドを提供します。
＊Servlet からはアクセス用インターフェイスに対する DOM プロ
グラミングで特定のHTML ページの文書構造をロジックに応じて変更させる事で動的なページ生成を行います。
結局、HTML ファイルに独自の拡張をする事もなく、プログラムとの連携も id 属性と SPAN タグという HTML の標準仕様内で工夫すれば済む話と言う事（この程度なら CSS も使える Web デザイナーなら楽なものです。）で、上手くロジックとデザインを分離できていると思います。実際に保守性は随分向上しました。CSS の積極的な利用も併用すると、デザインの変更に伴うプログラムの変更は劇的に減りましたし、同じように Web デザイナーとプログラマ間のいざこざもかなり減りました。（PageMixer については XMLC が DOM を使っているところが処理効率などを考慮して SAX っぽい物に変っていると言う事です。詳しくは http://pagemixer.sourceforge.net/index.ja.html を参照してください。）
結局、アスペクトと言う観点で見ると、
＋XMLC コンパイラで HTML ファイルを機械的に Java のモジュールに変換できる事（AOP で言う所の ウィービングですか）
＋DOM という標準的なインターフェイスを使っている事。（プログラマに HTML への汎用的で明確なアクセスの手順を定義している。）
事が重要だと言う気がします。
..... To Be Continued ..............
続きです。
ただ、HTML に Java プログラムを埋め込むような JSP がそれなりに主流になったのも、
1.局所的にみるなら、取っ付きやすい、分かりやすい。
2.タグライブラリのような、部品化の仕組みがあった。
3.処理速度の面で効率が良い（この辺は相対的な問題ですが）
という利点があるからだと思います。確かに XMLC の場合は DOM で HTML の文書構造を操作する形式なので、直感的ではないし、DOM のモデルにもなれる必要があります。時と場合によっては、まさよしさんの言葉を借りるなら、DOM の木構造と言う、「特定のクラス構造を横断的にトラバース」する事も必要で、結構直感的でない煩雑なプログラムになります。この辺は AOP にも似たような課題があるかもしれないですね。
後は部品化でしょうか。特に画面構成を断片化して、典型的な挙動を伴ったリストボックスやラジオボタン、又はその集合であるフォームなどの共通部品の作成などは全然支援していません。これは部品化はオブジェクト指向では普通の概念ですが、HTML のような構造化文書のモデルをベースにして場合は、データに操作が伴ったオブジェクトモデルの方が副次的なコンサーンだからでしょうか。むしろタグという、構造化文書のモデルにおける部品概念をそのまま使った JSP の方が部品化という意味では利点があったのかもしれません。
強引かも知れないですが、この辺は アスペクトの再利用性の向上が重要課題な事に通じるかもしれないですね。現実的には、Struts や Barracuda のような MVC アーキテクチャパターンをベースにしたフレームワークとの併用で解消すると言うのが妥当な所という気もします。
ただ、HTML に Java プログラムを埋め込むような JSP がそれなりに主流になったのも、
1.局所的にみるなら、取っ付きやすい、分かりやすい。
2.タグライブラリのような、部品化の仕組みがあった。
3.処理速度の面で効率が良い（この辺は相対的な問題ですが）
という利点があるからだと思います。確かに XMLC の場合は DOM で HTML の文書構造を操作する形式なので、直感的ではないし、DOM のモデルにもなれる必要があります。時と場合によっては、まさよしさんの言葉を借りるなら、DOM の木構造と言う、「特定のクラス構造を横断的にトラバース」する事も必要で、結構直感的でない煩雑なプログラムになります。この辺は AOP にも似たような課題があるかもしれないですね。
後は部品化でしょうか。特に画面構成を断片化して、典型的な挙動を伴ったリストボックスやラジオボタン、又はその集合であるフォームなどの共通部品の作成などは全然支援していません。これは部品化はオブジェクト指向では普通の概念ですが、HTML のような構造化文書のモデルをベースにして場合は、データに操作が伴ったオブジェクトモデルの方が副次的なコンサーンだからでしょうか。むしろタグという、構造化文書のモデルにおける部品概念をそのまま使った JSP の方が部品化という意味では利点があったのかもしれません。
強引かも知れないですが、この辺は アスペクトの再利用性の向上が重要課題な事に通じるかもしれないですね。現実的には、Struts や Barracuda のような MVC アーキテクチャパターンをベースにしたフレームワークとの併用で解消すると言うのが妥当な所という気もします。
追記（半分独り言）です。
まーしかし、改めて考えてみると Web システムにおけるプレゼンテーション層の実現手段って、Java に限っていえば J2EE 準拠で JSP & Struts って感じで結構、主流は決まってきたと言うイメージもあるのですが、アスペクト指向を導入して、改めて考え直せばまだ色々と面白い事が出来るかもしれないですね。うんうん。そうかな。 (?(｡_。).｡o0O?？
あと、話をモデル駆動(MDA) に戻しますと、素朴な疑問ですが、くだんの MDA における DSL（Domein Specific Language）ですが、 HTML もそれに該当するのでしょうか。同じ Language だし。ただ、駆動の基盤となるモデルにしては少し静的、構造的過ぎるような気もするし、けれど見た目上は JSP も HTML を土台にしている事はしているんだよな。・・・・、ちょっと違うか。
まーしかし、改めて考えてみると Web システムにおけるプレゼンテーション層の実現手段って、Java に限っていえば J2EE 準拠で JSP & Struts って感じで結構、主流は決まってきたと言うイメージもあるのですが、アスペクト指向を導入して、改めて考え直せばまだ色々と面白い事が出来るかもしれないですね。うんうん。そうかな。 (?(｡_。).｡o0O?？
あと、話をモデル駆動(MDA) に戻しますと、素朴な疑問ですが、くだんの MDA における DSL（Domein Specific Language）ですが、 HTML もそれに該当するのでしょうか。同じ Language だし。ただ、駆動の基盤となるモデルにしては少し静的、構造的過ぎるような気もするし、けれど見た目上は JSP も HTML を土台にしている事はしているんだよな。・・・・、ちょっと違うか。
ひとつ気になった点があります。画面とコードの分離、あるいは、より抽象的には、複数のコンサーンの分離においては、これらの分離を複合化する手段としての、のり言語の存在が重要です。MVCでは、MとVの分離をControllerがやりますが、一般的には、この部分は言語あるいはマップルールとするのが最近の流行です。しかし、この方法はまだ主流ではありません。MVCに代わって、ロジックのクラス構造と画面をマップするルール言語を実行するような感じです。Controllerの役割に近いのですが、ここは言語の実行環境の一部として動作します。いまの開発環境はこの部分をデザイン時にべたにやる方法のため、かなり暗黙的です。
どうもです。
まさよしさん> 複数のコンサーンの分離においては、これらの分離を複合化する手段としての、のり言語の存在が重要です。
なるほど、考えてみるとこれは実感ですね。確かに HTML の内容を動的に変える場合に、簡単な仕様なら XMLC コンパイラが自動生成するアクセスメソッドで要は足るのですが、ユーザーの権限レベルやＤＢからの取得データの件数や属性によって、動的にレイアウト・画面構成をカスタマイズする場合には、とたんにDOM プログラムだと煩雑になりました。
まさよしさん＞いまの開発環境はこの部分をデザイン時にべたにやる方法のため、かなり暗黙的です。
そうですね。最初の頃は漠然と「この辺もっと楽にならんかな・・・」と思いましたが、よく考えてみるなら実際の画面レイアウトとタグの木構造を表す、HTML の DOM の間にも意味的なギャップがある訳ですから、やはり DOM 木への操作が画面のレイアウトの変化として、どう表れるかを、暗黙のうちに頭で考えながらプログラムをしていたから煩雑だったんでしょうね。（だからこそ、Web デザイナーは HTML ファイルをなるべく直接さわらずに DreamWeaver 等の編集ツールを使うわけです。）
そういう時に、DOM の操作と言ったより基本的な手順を煩雑なぐらいに自分で組むのではなく、何がしか画面のレイアウト定義に特化したパラメトリックなスクリプトで動的な画面生成ロジックを組み、それを XMLC のオプションファイルとして使って、Java と HTML をつなげれたらなと思ったものです。（多分にコンパイル時に何がしかのツールでそのスクリプトを機械的に DOM ベースの Java プログラムに落とす事になるんでしょう。）
まさよしさん> 複数のコンサーンの分離においては、これらの分離を複合化する手段としての、のり言語の存在が重要です。
なるほど、考えてみるとこれは実感ですね。確かに HTML の内容を動的に変える場合に、簡単な仕様なら XMLC コンパイラが自動生成するアクセスメソッドで要は足るのですが、ユーザーの権限レベルやＤＢからの取得データの件数や属性によって、動的にレイアウト・画面構成をカスタマイズする場合には、とたんにDOM プログラムだと煩雑になりました。
まさよしさん＞いまの開発環境はこの部分をデザイン時にべたにやる方法のため、かなり暗黙的です。
そうですね。最初の頃は漠然と「この辺もっと楽にならんかな・・・」と思いましたが、よく考えてみるなら実際の画面レイアウトとタグの木構造を表す、HTML の DOM の間にも意味的なギャップがある訳ですから、やはり DOM 木への操作が画面のレイアウトの変化として、どう表れるかを、暗黙のうちに頭で考えながらプログラムをしていたから煩雑だったんでしょうね。（だからこそ、Web デザイナーは HTML ファイルをなるべく直接さわらずに DreamWeaver 等の編集ツールを使うわけです。）
そういう時に、DOM の操作と言ったより基本的な手順を煩雑なぐらいに自分で組むのではなく、何がしか画面のレイアウト定義に特化したパラメトリックなスクリプトで動的な画面生成ロジックを組み、それを XMLC のオプションファイルとして使って、Java と HTML をつなげれたらなと思ったものです。（多分にコンパイル時に何がしかのツールでそのスクリプトを機械的に DOM ベースの Java プログラムに落とす事になるんでしょう。）
- mixiユーザー
- ログインしてコメントしよう！
|
|
|
|
ソフトウェア工学 更新情報
-
最新のアンケート
-
まだ何もありません
-
ソフトウェア工学のメンバーはこんなコミュニティにも参加しています
人気コミュニティランキング
- 1位
- 暮らしを楽しむ
- 75505人
- 2位
- 写真を撮るのが好き
- 208299人
- 3位
- 音楽が無いと生きていけない
- 196031人