┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.19 2003/10/22
■ I N D E X
┃
┣【UML入門】Judeで始めるUML [6]
┗【ＸＰ】XP実践家への道 [5] 第五道標 - 「頻繁なリリース」と「リリース計画」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【UML入門】JudeではじめるUML [6]
福井は最近急に寒くなってきました。ファンヒーター、コタツ、エアコン、オ
イルヒーター、ハロゲンヒーター、ホットカーペット、、、とあり、それぞれ
温まり度合いや乾燥度合い、電気代、、、が違って毎年悩んでしまいます。(^^
今回はステートチャート図を描きますが、暖房器具の動作も状態で捉えること
ができそうです。例えば、「急激にあたため中の状態」や、「温度をキープし
ている状態」、「換気待ちの状態」などがあるでしょう。そして、「設定温度
になったイベント」や「換気が必要な時間になったイベント」によって状態が
変わると考えられます。
■ステートチャート図
ステートチャート図は、システムやオブジェクトの状態とその変化を表現する
図です。分析や設計のために描かれます。
システムやオブジェクトが、生成されてから無くなるまでの状態変化を表現し
ます。ある状態から別の状態へかわることを矢印（遷移）で表現します。また、
その遷移のきっかけとなる事象をイベントといい、矢印の近くに描きます。
ステートチャート図の例を見てみましょう。
寿司注文システムにおけるシステムの大まかな分析例：
http://objectClub.esm.co.jp/ml-arch/magazine/magazine19/jude_UML6.html#1
ボーリングにおけるゲーム進行の分析例：
http://objectClub.esm.co.jp/ml-arch/magazine/magazine19/jude_UML6.html#2
LEGOロボット制御における設計例：
http://objectClub.esm.co.jp/ml-arch/magazine/magazine19/jude_UML6.html#3
ステートチャート図を描くときのポイントは、対象を明確にすることだと思い
ます。もし、システム全体の状態を分析しているのか、それとも、注文クラス
の状態を分析しているのか、が曖昧になってしまうと、本質が見えない図になっ
てしまう恐れがあります。
自分の手で実際にステートチャート図を描いてみましょう。
■Judeでステートチャート図を描いてみる
1) ステートチャート図の作成
左側のツリーにおいて、クラスのポップアップメニューから「ステートチャー
ト図の作成」を選択します。
補足：Jude竹1.2.3では、ステートチャート図をパッケージの下にも作成でき
ます。
2) 開始状態、終了状態の作成
クラスやユースケースの作成方法と同様です。図の上の方の「開始状態」
「終了状態」作成ボタンをクリック後、図上の点をクリックします。
3) 状態の作成
開始状態、終了状態の作成と同様です。
作成時、既に図上に描かれている状態の中をクリックすると、状態を入れ子
にすることができます。配置後、状態名を入力します。
3-1) 状態の編集
もし必要なら、状態のポップアップメニューまたはプロパティビューから、
以下を編集します。
- entryアクション（入場アクション）...この状態になったときに実行
される動作
- doアクティビティ ... この状態にいる間実行される活動
- exitアクション（退場アクション）... この状態を抜けるときに実行
される動作
状態の名前だけを図に描きたい場合は、ポップアップメニューから「内部
遷移区画の表示」をオフにします。
4) 遷移（トランジション）の作成
関連の作成と同様です。「遷移」作成モードにして、状態の遷移元と遷移先
を指定します。
4-1) 遷移の編集
遷移のラベルは、次の形式で表記します。
”イベント(イベントのパラメータ１, パラメータ２)[ガード条件]/アクション”
例えば、”投球 [ストライク] / 祝福画面の表示”は、投球という出来事
があった場合に、もしストライクなら、祝福画面の表示を行いつつ、次の
状態に移ることを意味します。
◇ ◇ ◇
ステートチャート図は、システム全体の状態を分析するために描かれたり、画
面遷移を描くのに使われたりもしています。また、特に組み込み系のシステム
開発において、状態を中心に開発されることがよくあり、利用される機会も増
えているようです。
ステートチャート図に慣れるはじめの題材として、暖房器具などの身近なちょっ
とした機械を取り上げて、図を描いてみるのはいかがでしょうか？（岡村）
■今日のUMLクイズ
次のうち正しいものを選択してください（複数）
ア. ステートチャート図は、システムやオブジェクトの状態の変化に注目した
図である。
イ. ステートチャート図は、通常すべてのクラスについて作成する必要がある。
ウ. 遷移（トランジション）のラベルは、次の形式で表記する。
”[ガード]イベント/アクション（パラメータ）”
エ. 有名なデザインパターンの中に、Stateパターンというパターンがあり、状
態による振舞いの違いをポリモーフィズムによって実現している。
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?C001+5+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?C001+5+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?C001+5+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【ＸＰ】XP実践家への道 [5] 第五道標 - 「頻繁なリリース」と「リリース計画」
こんにちは、天野勝です。
今回から読まれる方もいらっしゃると思いますので、簡単にこの連載の概要を
説明します。この連載はRoy W. Miller(*1)の提案しているXPのプラクティス(*2)
を、筆者の解釈にもとづき皆様に紹介していくというものです。
☆ ☆ ☆
■約3分の2の機能はほとんど使われない
Standish Group(*3)の報告によると、まったく使われない機能が45%、ほとんど
使わない機能が19%だそうです。これは驚きの数字です。が、筆者にはとてもよ
く理解できる数字でもあります。
以前、電子的に作成した伝票をメールとFAXで送るというシステムを作ったこと
があります。電子データですので、メールであれば受信側に専用ビューアをイ
ンストールするだけですむのですが、FAXの場合は一筋縄ではいきません。メー
ルで送信する部分は、1日で完成したのですが、FAXのほうは様々な調査やテス
トなどで2週間みっちりかかりました。約10倍の工数です。
晴れてシステムリリースとなったのですが、実績を見て愕然、FAXが一通も送ら
れていません。エンドユーザに聞いてみると、まずは段階的に使っていくから、
取引が多く、メールを持っている相手に伝票を送るとのこと。IT革命と言われ
て久しいわけで、その後いつの間にかほとんどの取引先はメールを使える状態
なっていました。つまりFAXによる送信機能は一度も使わなかったわけです。
他にも1ヵ月半かけて作ったネットワークがないところでも使えるようなオフラ
インサブシステムが、できたころにはネットワークが通っていてまったくリリー
スすらされなかったという経験もあります。
ついついチャレンジングなことに力を注いでしまうエンジニアの性なのでしょ
うが、このような悲しい気持ちにはあまりなりたくないですね。
やはり顧客が独りよがりな仕様を決めるのではなく、エンドユーザをもっと意
識して仕様を考えるように促せばよかったと後悔しました。
XPには頻繁にリリースし、エンドユーザからのフィードバックを得られるよう
にという「頻繁なリリース」というプラクティスがあります。
頻繁なリリースといっても、クライアントにセットアップファイルを配布して
インストールしてもらうのでは、受け入れられにくいです。頻繁にアップデー
トするための仕組みが必要です。最近は定期的にサーバをチェックし、必要な
ときに自動でセットアップファイルをダウンロードして、セットアップする仕
組みのソフトが増えていますね。Webアプリケーションはその最たる例ですね。
■でも仕様の決定権は顧客にある
エンドユーザの声に耳を傾けるのは大事ですが、最終的な決定権は顧客にあり
ます。エンドユーザから様々な要望が挙がってくるでしょうが、その要望を実
現することによって得られるメリットと、実現にかかるコストのトレードオフ
を考慮しなくてはなりません。要望の多い機能であっても、元が取れないよう
であれば切り捨てるしかありません。
大きな声の1人のエンドユーザの意見が、エンドユーザの方たちの総意であると
は限らないという事実にも配慮が必要です。
XPの「リリース計画」では、顧客がこのトレードオフを考えて、いつ、どのス
トーリをリリースするかを決定します。機能の実現にどれだけのコストがかか
るかは、開発側に聞く必要があります。開発側は、ストーリをタスクに分割し、
コストを見積もり、場合によっては開発側の希望する優先順位や、リスクにつ
いても顧客に説明します。
開発側は優先順位を決めるときに、技術的に面白そうで単に興味があるからと
いった理由で決めないように自制してください。
☆ ☆ ☆
今回は顧客のプラクティスから「頻繁なリリース」と「リリース計画」を説明
しました。次回は、管理者のプラクティスの「責任の受け入れ」と「援護」に
ついて説明いたします。この連載に対するご意見お待ちしています。(天野勝)
*1: 「XP エクストリーム・プログラミング 適用編」の著者です
*2: http://www-6.ibm.com/jp/developerworks/java/021018/j_j-xp0813.html
*3: http://www.standishgroup.com/
______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?G001+4+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?G001+4+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?G001+4+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。
いつもぎりぎりに原稿を集めて、ぎりぎりに編集して、ぎりぎりに配信している
いっぱいいっぱいな、このメールマガジンですが、今回は、主要なライターが社
員旅行に出かけてしまい、一瞬青くなった編集人でした。
でも社員旅行から帰ってから、しっかり記事を仕上げてくれました。
なにせ記事のストックもほとんどありません。予定していた担当者が業務の都合
などで落ちると、編集人は泣きながら書けそうなライターを探し回ります。
毎週、自転車操業状態の「週刊メールマガジン」なのです。
いつの間にか19号まで続けることができましたが、編集後記も毎週ネタに苦しみ
ながら書いています。（編集後記は）毎週面白くない話ですみませんが、今後と
もよろしくお願いします。
（いりさ）
今日のUMLクイズの答え：ア、エ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/mlmagazine_help.html
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/mlmagazine.html
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.