あかさたの最近の仕事
2008-01-30 02:11 :
Kodougu でアクティビティ図を書いてみた
今、Kodougu のサクサク感向上開発をしているのですが、なかなか出来あがらないので、現実逃避（？）にアクティビティ図を作ってみました。結構、いい加減です。
作成時間は 15 分くらいです。年度内にはパフォーマンスを劇的に向上したクライアント（IE 向け）とメタモデリング機能を一般公開したいのですが、できるやら。。。
続きを読む
Posted by あかさた（編集）
2008-01-15 12:09 :
「Ruby on Rails によるシステム開発をモデリングで効率的に行う」連載記事を書いた
最近、八角研究所で技術記事を書いているのですが、そこで、Ruby on Rails の開発を潤滑に進めるために、モデリングを含めた開発プロセスを架空の事例に適用して紹介した連載記事を執筆しました。
続きを読む
Posted by あかさた（編集）
2007-12-26 03:32 :
ウェブアプリで画面に関するモデリングはあり得るのか考えてみた
ウェブアプリになってから、あまり画面そのものをモデリングする機会がありませんでした。スタンドアロンの GUI アプリでは画面のモデリングが必要となるケースが結構あった（複雑な画面を持つアプリケーションは画面上に配置されるコンポーネントを戦略的に管理しないと開発が成り立たなくなる）のですが、Kodougu を含めウェブアプリを作るようになってからあまり意識していませんでした。所詮画面のあるシステム、そうそう違いがあるとは思えないので、ためしに画面設計に関するモデリングを検討してみました。
続きを読む
Posted by あかさた（編集）
2007-11-28 16:46 :
Dojo UML なんてあるんだな
via Dojo/JavaScript Toolkitのメモ
Dojo UML（リンク先は結構重いので注意） というものがあるみたいです。Kodougu と同じく Dojo Toolkit を使っているそうです。Web 上でベクターグラフィックスなんて結構楽勝な時代になったってことか。
Posted by あかさた（編集）
2007-11-08 14:22 :
ユースケース図の include、extend、汎化について書いてみた
八角研究所で書いた技術記事の紹介です。Kodougu でユースケース図を実装した時に、include、extend、汎化の使い方を整理した記事を書きました。
ユースケース図は誤用が多い図というか、結構よくわからない図です。extend、include、汎化を多用していると、何を書いてあるのかよくわからなくなる場合も多く、それぞれの意味を正確に把握している人も多くないように感じます。クラス図が最もポピュラーでありながら、正確に使用できる人が少ないことと同じかもしれません。
UML に関係したモデリングツールの開発に携わるのは、非商用含めてかれこれ 5 本目くらいなのですが、その私も理解はかなりあいまいです（オイオイ）。そういう事情もあって、include、extend、汎化の使い方を整理した記事を、Kodougu の仕様検討という形で書きだしてみました。
ユースケース図の extend は必要か？
http://www.hakkaku.net/articles/20071107-66
UML の参考書片手に読んでいただければ幸いです。特に、私も執筆にかかわったその場でつかえるしっかり学べるUML2.0 が最も優れていると思います。（私は 5% くらいしか書いていませんが。。。）
# 手前味噌・・・とか言わないで！(^^;
Posted by あかさた（編集）
2007-10-17 10:10 :
Kodougu でユースケース図の実装を開始した
最近、Kodougu でユースケース図の実装を開始しました。いざ作り始めてみると以下の点をどうするかで悩み始めています。
・ Include/Extend をどうするか（特に拡張点の扱いは悩ましい）
・ システム境界はどうするか（UML 2.0 的には分類子であり、名前空間）
・ なんかユースケースの初期サイズが大きい(^^;
現在、Kodougu では UML は「Tiny UML 2.0」という名称で実装しています。名前のとおり、Tiny な実装を目指していて、ごてごてとした機能を嫌います。私の好みとしては、システム境界は単なる四角にして、Include は実装、Extend はいらないって感じですかねぇ・・・。
続きを読む
Posted by あかさた（編集）
2007-03-19 22:39 :
JUDE の販売本数
平鍋さんのブログを読んでいたら、以下のような記述がありました。
JUDE 今期('06/4-'07/3)の販売目標 - An Agile Way より
チェンジビジョンの決算を迎える訳ですが、JUDE/Professional の有償版販売目標である、６千本を、もう少しで達成します。
保守更新を含まないでですよね？ 私もこの手のツールのビジネスに関わっていたことがあるので、この本数が結構すごい（※）ことは承知しています。それでも、無償版が数十万本も出ていたことを考えると、思ったほど多くは無いなという感じを受けました。売り上げ的には保守更新もあるでしょうから、問題はなさそうですけど。
※ JUDE は無償版も結構使えてしまいますから、なおさら凄い。
Kodougu も近いといえば近い（遠いといえば遠い）ツールなので、こういうビジネス的な話題には思わず注目してしまいますね。(^^;
Posted by あかさた（編集）
2007-10-17 23:49 : GLAD!!
include、extend、汎化は欲しいです。
拡張点はいりません。extend にノートでいいんじゃないかな?
2007-10-18 00:32 : あかさた
コメントありがとうございます！
汎化は必須ですね！ さっそく実装してみました。
extend ってどんな時に使います？ なんか extend は誤読（私が読み間違う）が多くて苦手なんですよ・・・。orz
# 実装は簡単なので、必要性が確認できれば即入れられます。
# ユースケース図の実装はここまでで 30 分もかかってませんし。
2007-10-18 17:25 : あかさた
とりあえず、ユースケース内部に拡張点を書きこむ機能以外は全機能を実装しました。システム境界は UML 1.x 並ですが・・・。
2007-10-19 01:15 : GLAD!!
> extend ってどんな時に使います？
ヤコブソンのアスペクト本によれば、サブフローをユースケースとして切り出すのが include で、代替フローをユースケースとして切り出すのが extend ですね。
なかなか良い例が思い浮かばなかったんだけど、電子マネーで、
商品を買う <- <<extend>> - オートチャージする
なんてどうでしょうか?
2007-10-19 02:04 : あかさた
こんな遅い時間にありがとうございます！
私も調べてみました。コーバーンのユースケース本によると、ワープロソフトで、「文書を編集する」の拡張ユースケースとして、「スペルチェックを行う」という例が挙げられていました。この本では、拡張ユースケースは主ユースケースを中断して実行されるユースケースであり、基底ユースケースを制御しないものとして定義していました。
拡張は繰り返し開発において、基底ユースケースの変更回数を減らすテクニックだそうです。
電子マネーの例なら、拡張点として「残額確認」などを定義しておいて、オートチャージなどは次以降のイテレーションで検討するような場合に拡張は有効だそうです。ただ、代替フローは「チャージ金額が一定額を下回る場合、オートチャージを行う」というような記述で、包含ユースケースとしても記述できます。この辺、レビューの手間とプロジェクトの規模などバランスを見ながら選択するようです。
この本では拡張ユースケースは理解と維持が難しいため使用を必要最小限に抑えた方が良いとのことでした。私も同感です。特にテキストベースでユースケースを記述しなおしたときに、include は直感的なのですが、extend が直感的に書けませんでした。
いずれにしても、便利な機能には違いないのでツールとしては実装しました。