ログインしてさらにmixiを楽しもう

コメントを投稿して情報交換!
更新通知を受け取って、最新情報をゲット!

Software FactoriesコミュのSoftware Factories BoF @PDCでの小ネタ

  • mixiチェック
  • このエントリーをはてなブックマークに追加
シーメンスの人が2人来て、Q&A、時には参加者どうしのディスカッションありで、結構興味深かったです。最大30人近くの参加者がいました。
内容は後でまた整理しようと思いますが、DSLに関しては結構発言もあったのですが、Produce Lines(PL)はあまり実践的な話はなかったような印象です。

最後挨拶がてらにシーメンスの人(肩書きはProgram Managerでした)に「PLを勉強するにはどんな資料がいいですか?」と聞いてみたら、やっぱりgenerative programmingを挙げました。時間作って読みますか、やっぱり・・・

コメント(3)

generative programmingは体系化されている点ではいいのですが、PLについてはあまり期待できないです。ソフトウェアファミリーを抽象データ型をベースとして作っているのはいいのですが、関心の分離が形にはまりやすい例なので、事例としては、あまり参考になりません。そして、アスペクトの記述が古い点も問題です。ですが、流す程度に読むのはいいでしょう。
ごめんなさい。PLではなくてfeature modelingです。打ち間違えました。
feature modelingもほとんどFODAしか見たことがないのですが、ツリー状になっているのが、どうしても非機能要件が分散してしまうんじゃないかと。あと、どのくらいフィーチャーツリーが大きくなるのかな、と。大きくなったらサブノードで分割するんでしょうが、ユースケースより細かいことは確かだし、ツールを使うか手で描くかでも違うでしょうが、全体を把握するにはある一定の大きさ(視界に収まる程度の)までにしないと分析が細かくなりすぎて逆効果になる恐れもありますね。
フィーチャでの横断的関心としてアスペクトを表現した図があります。アスペクトのアスペクトのような関係もあるのですが、あまり複雑になると醜いです。木のノード間に破線で関係を示しますが、正統なフィーチャモデルではありません。また、排他的関係を示す記法もその他の関係の記述で拡張が可能です。
フィーチャモデル自体は他のコンセプトモデリングと同じで、どのスコープで記述するかを別に定義しなければなりません。この定義が明確であれば、分割や一部を別に詳細化などの定義が可能です。

ログインすると、みんなのコメントがもっと見れるよ

mixiユーザー
ログインしてコメントしよう!

Software Factories 更新情報

Software Factoriesのメンバーはこんなコミュニティにも参加しています

星印の数は、共通して参加しているメンバーが多いほど増えます。

人気コミュニティランキング