┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.20 2003/10/29
■ I N D E X
┃
┣【Topics】「Jude 竹ver1.2.4」が新しくリリース！
┣【Topics】【新着記事】JavaPress掲載のUML記事2本をUPしました
┣【UML入門】Judeで始めるUML [7]
┗【ＸＰ】XP実践家への道 [6] 第六道標 - 「責任の受け入れ」と「援護」
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 「Jude 竹ver1.2.4」が新しくリリース！
〇 〇━━━━━━━━━━━━━ ━━・
成長を続けるフリーのUMLモデリングツール、Judeの新バージョン Jude 竹 1.2.4
がリリースされました！
いくつかの不具合修正に加え、アイテムドラッグ時の自動スクロールなど、多
くの操作性を向上しています。是非お試しください。
Jude： http://www.ObjectClub.jp/Jude/
リリースノート： http://www.ObjectClub.jp/Jude/Release_Note.html
ダウンロード： http://www.ObjectClub.jp/Jude/download.html
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 【新着記事】JavaPress掲載のUML記事2本をUPしました
〇 〇━━━━━━━━━━━━━ ━━・
JavaPress Vol.31に掲載された、UML記事2本をUPしました。
「JavaソースとみるUML入門」
http://www.ObjectClub.jp/Java2UML/
「Judeで体感UML」
http://www.ObjectClub.jp/TryUMLwithJude/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【UML入門】JudeではじめるUML [7]
今回は、アクティビティ図を取り上げます。
アクティビティ図は、状態遷移の特別なものとして扱われていることもあり、
前回のステートチャート図と似た表現を含みます。ただし、図の用途は異なり
ますので、そのあたりをみていきましょう。
■アクティビティ図
アクティビティ図は、名前のとおり活動（動作、処理）に注目して、その順序
や並行性を表現する図です。ユースケースを分析するためにそのシナリオをア
クティビティ図で表現したり、複雑なアルゴリズムを表現するために利用され
ます。プロセスの実行手順を記述できるので、ワークフローの記述にも利用さ
れています。
例を見てみましょう。
寿司注文ユースケースのシナリオ記述例：
http://objectClub.esm.co.jp/ml-arch/magazine/magazine20/jude_UML7.html#1
UML仕様書にあるサービス受付のワークフローの例：
http://objectClub.esm.co.jp/ml-arch/magazine/magazine20/jude_UML7.html#2
ステートチャート図で見た”開始状態”、”終了状態”がありますし、前回見
た”状態”に似たマークもあります。左右が丸い矩形は、”アクション状態”
という活動にあたるものです。”状態”と”アクション状態”の形は、ちょっ
とだけ違うのですが、気づきましたか？
矢印は、ステートチャート図でも登場した”遷移”です。全体を分割している
大きな矩形は、”スイムレーン”と呼びます。菱形は、”選択”や”連結”と
いう条件分岐を表現する要素です。
その他に、並行性を表現するための”同期バー（フォークとジョイン）”や、
”アクション状態”間で受け渡しされるオブジェクトを表現する”オブジェク
トフロー状態”が、図の構成要素になっています。
ステートチャート図と違って、アクティビティ図では、遷移のきっかけとなる
イベントが描けません。それは、アクション状態の場合は、その動作が
終了した時点で、遷移するということが決まっているためです。
アクティビティ図では、シーケンス図やコラボレーション図と同じように振舞
いを表現します。シーケンス図やコラボレーション図では、オブジェクト間の
メッセージのやりとりに注目しているのに対して、アクティビティ図では動作
の順序や関係、並行性に注目している点が大きく異なります。
それでは、手を動かしてアクティビティ図を描いてみましょう。
■Judeでアクティビティ図を描いてみる
前回描いたステートチャート図と同様に、描くことができます。
1) アクティビティ図の作成
左側のツリーにおいて、操作のポップアップメニューから「アクティビティ
図の作成」を選択します。（パッケージ、クラス、ユースケース、操作の配
下に作成できます）
2) スイムレーンの作成
図の上の方の「スイムレーン」作成ボタンをクリック後、図上の点をクリッ
クします。クリックする場所により挿入される場所がかわります。幅は、右
側の線をドラッグして変更します（Jude1.2.4で改善）。
3) 開始状態・終了状態の作成
「開始状態」「終了状態」作成ボタンを利用します。
4) アクション状態の作成
状態の作成と同様に、「アクション状態」作成ボタンを利用します。
状態のように入れ子にすることはできません。
動作のラベルが長く折り返したい場合は、アクション状態のサイズを変更し
ます。
5) 遷移（トランジション）の作成
「遷移」作成モードにして、状態の遷移元と遷移先を指定します。
必要に応じて、ガード条件を設定します。
6) オブジェクトフロー状態の作成
通常の状態の作成と同様に作成します。
ここで、オブジェクトフロー状態は、スイムレーンの境界にも配置できる仕
様になっています。また、オブジェクトフロー状態につながる遷移の矢印は、
UMLの仕様に沿って、破線で表示されます。ポップアップメニューからオブ
ジェクトの状態を設定できます。
◇ ◇ ◇
「JudeではじめるUML」の連載は、今回で終わりです。今回までに、コンポー
ネント図と配置図以外のUMLの図について見てきました。これで、UMLでよく使
われる図を一通り見てきたことになります。かなり大雑把な例と説明で少しで
も参考になったのか気にかかるところですが、今まで読んで頂き、ありがとう
ございました。最後に、今回の連載記事とほぼ同等の主旨と内容の記事を紹介
しておきます。（岡村）
■参考記事：「Judeで体感UML」（初出：JavaPresss Vol.31）
http://www.ObjectClub.jp/TryUMLwithJude/
UMLとUMLツール初心者を対象に、ボーリングの点数に関する例で、Judeを使い
ながらUMLを体感する記事です。
■今日のUMLクイズ
次のうち正しいものを選択してください（複数）
ア. アクティビティ図では、オブジェクト間のメッセージのやりとりを表現する。
イ. アクティビティ図は、主にユースケースシナリオの記述や、複雑なアルゴ
リズムの記述、ワークフローの記述に利用される。
ウ. アクション状態は、かならずいずれかのスイムレーンに属する。
エ. アクション状態から次のアクション状態へは、特別なイベント発生時では
なく、元のアクション状態の動作が終了した時点で遷移する。
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?C001+6+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?C001+6+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?C001+6+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【ＸＰ】XP実践家への道 [6] 第六道標 - 「責任の受け入れ」と「援護」
こんにちは、天野勝です。
今回から読まれる方もいらっしゃると思いますので、簡単にこの連載の概要を
説明します。この連載はRoy W. Miller(*1)の提案しているXPのプラクティス(*2)
を、筆者の解釈にもとづき皆様に紹介していくというものです。
☆ ☆ ☆
全11回を予定している本連載の折り返し地点まできました。
今回は管理者のプラクティスである「責任の受け入れ」と「援護」を説明しま
す。
■開発者にコミットメントしてもらおう
管理者たるもの、開発者に気持ちよく働いてもらって、高生産性を引き出し、
高品質なものを作ってもらわなくてはなりません。
管理者は開発者をコントロールするのではなく、組織をマネジメントするのが
お仕事ですよね。P.F.ドラッカーの言葉によると「働く人たちを生かす」(*3)
のが、マネジメントの役目の一つです。開発者を生かすためには、開発者にコ
ミットメントしてもらうというのが、その解決策の一つになります。コミット
メントとは、約束に対してその約束を果たすために徹底的に関わること、といっ
た意味の言葉です。
では、その約束はどのように決めていくのがよいでしょうか。
昔読んだ文献(*4)に、
(a)上司が一方的に決めたスケジュールは守られないことが多い。
(b)上司と部下で相談して決めた場合、(a)よりはスケジュールが守られる傾向
があり、期間も(a)よりも短く設定されることが多い。
(c)部下が自分で決めた場合、より短い期間でスケジュールが立てられ、それが
強く守られる傾向がある。
というような話がありました。これは、自分で決めたのだから自分の責任で、
約束を果たさなくてはならない、という気持ちになるからなのだと思います。
より強くコミットメントしてもらうには、開発者が自ら約束をしてもらうのが
望ましいようです。
管理者があまり口出ししないのがマネジメントとしては美徳とされており、XP
には、開発者に「責任の受け入れ」をしてもらうように、というプラクティス
があります。
XPではイテレーションの最初にそのイテレーションの計画を立てます。このと
きユーザが作成したストーリをもとに開発者がタスクに分割します。続いて、
タスクの担当者を決め、タスクにかかる時間を見積もりますが、この担当者を
決めるには開発者が自ら「サインアップ」し、サインアップした担当者が自身
で時間を見積もります。誰もサインアップしないタスクがあっても、決して管
理者が「○○君は、このタスクね。」と一方的に割り当てたり、さらには「まぁ、
4時間ぐらいで終わるね。」などと決めてしまうのはよろしくありません。
■さらに強く、開発者にコミットメントしてもらおう
「責任の受け入れ」を実践することで、開発者が開発にコミットし、高品質の
製品を、高い生産性で開発できるようになってきたら、さらにその上を目指し
たくなるものです。
XPのプラクティスは、それ単独でも効果がありますが、複数のプラクティスを
同時に実践することで、相互補完され、相乗効果が出てきます。ここでもう一
つ「援護」というプラクティスを実践してみましょう。開発者を1リソースとし
てみるのではなく、同じ人として尊重し、開発者が余計なことに煩わされない
ように支援するというものです。荷物を両手に持ってドアの前に立っている人
がいたら、そのドアを代わりに開けてあげるのです。全体的な効率の改善を考
えるのです。
例えば、開発者が全社的な会議に参加を余儀なくされているとします。参加す
る開発者にも、会社としてもあまり意味がないことが分かっている(*5)のなら
ば、その会議の主催者に交渉し、その開発者が参加しなくてもよいようにする
のも管理者の役目です。
開発者が自ら約束をし、管理者がそれを精力的に手助けしてくれる。そんな状
況ならば、開発者は喜んで開発をしてくれることでしょう。
☆ ☆ ☆
今回は管理者のプラクティスから「責任の受け入れ」と「援護」を説明しまし
た。次回は、今回と同じく管理者のプラクティスの「ミラー」と「最適ペース」
について説明いたします。この連載に対するご意見お待ちしています。(天野勝)
*1: 「XP エクストリーム・プログラミング 適用編」の著者です
*2: http://www-6.ibm.com/jp/developerworks/java/021018/j_j-xp0813.html
*3: 「マネジメント[エッセンシャル版]-基本と原則」P.F.ドラッカー
ダイヤモンド社
*4: 出典の分かる人がいたら、編集室宛にメールください。m(_ _)m
*5: そんな会議ならば、その会議そのものを見直すべきですが・・・
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?G001+5+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?G001+5+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?G001+5+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。
オブジェクト倶楽部では、クリスマスイベントを開催します。
で、現在企画のツメをしている真っ最中なのですが。
イベントのタイトル、サブタイトルがなかなか決まらず、先日平鍋さん、天野
さんとイベントについてのミーティングをしていました。
本当は「オブジェクト倶楽部クリスマス会」なんて、まんま、なタイトルをつ
けたかったのですが、平日に、一応、内容は真面目なので、「参加者が会社に
言えないタイトルはまずいだろう」と、もう少し、まともなタイトルになりま
した。
XPアンギャも、同じ理由で「日本全国XPセミナー」という正式名称がついてい
たんですね。 どっちが正式名称なんだか(笑)。
イベントの詳細については、近々告知します。お楽しみに。
（いりさ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒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.