┏━━━━━━━━━━━━━━━━━━━━━━━━━━■
┃ ■┃
●┃● ● オ ブ ジ ェ ク ト 倶 楽 部 ■ ┃
┃ ■ ┃
┗━━━━━━━━━━━━━━━━━━━━━━■━━━┛
No.32 2004/01/28
■ I N D E X
┃
┣【Topics】第3回「UML ロボットコンテスト」実施説明会ご案内
┣【UML入門】UML2 ピンポイント解説[1]
┗【プログラミング】リファクタリング−プログラミングの体質改善 [4]
〇━━━━━━━━━━━━━━━━━━━━━━━━━━━T o p i c s━
〇 【新着記事】第3回「UML ロボットコンテスト」実施説明会ご案内
〇 〇━━━━━━━━━━━━━ ━━・
ＵＭＬロボットコンテストが4/13(火)開催されます。コンテスト内容、技術情
報や参加方法についての実施説明会のご案内です。
詳細：http://www.otij.org/release/20040126/
ＵＭＬロボットコンテストとは？
ＵＭＬモデルをLEGO Mindstormsロボットに実装し、動くＵＭＬとして実現され
その成果を競います。同じテーマを要求課題としたＵＭＬモデルが一同に会し
ます。参加者相互のモデル交換や意見交換、審査団からの評価といった技術者
交流の大きな機会となるでしょう。おもしろそう！今年こそは！ＵＭＬの実践、
教育に！とお考えの皆様、まずは実施説明会にふるって参加ください。お待ち
しております。
第1回 UMLロボットコンテスト
http://www.otij.org/event/umlforum/2002/umlrobo/
第2回 UMLロボットコンテスト
http://www.otij.org/UMLForum2003/robocon/
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━1 s t ■━
■
┗【UML入門】UML2 ピンポイント解説[1]
UML2.0の仕様が決まりつつあります。とかくMDA(Model-Driven Development)が
大きく取り上げられることが多いのですが、この連載では、今までみなさんが
使ってきたクラス図やアクティビティ図といった図(Diagram)、に注目して、そ
の記法と意味の1.x からの変更点について、数回で解説していきたいと思いま
す。
なお、この連載は、書籍紹介記事でも取り上げた、Martin Fowler 著の"UML
Distilled"の第3版が出版されたことが動機です。連載では、この書籍をもと
に、正確な仕様記述でなく、実際に図を書くときの注意点としての変更をわか
りやすく解説していこうと考えています。
◆図の種類
まず始めに、UML2の全図（13個）の名前を、分類とともに示します。
（構造図）
┣クラス図 (Class Diagram)
┣コンポーネント図 (Component Diagram)
┣コンポジットストラクチャ図 (Composite Structure Diagram)
┣配置図 (Deployment Diagram)
┣オブジェクト図 (Object Diagram)
┗パッケージ図
（振る舞い図）
┣アクティビティ図 (Activity Diagram)
┣ユースケース図 (Use case Diagram)
┣ステートマシン図 (State machine Diagram)
┗（相互作用図）
┣シーケンス図 (Sequence Diagram)
┣コミュニケーション図 (Communication Diagram)
┣相互作用概観図 (Interaction overview Diagram)
┗タイミング図 (Timing Diagram)
括弧内の図は、「分類」であり、具体的な図ではありません。具体的な図は13
個です。
UML1 では、図の種類は何種類あったか覚えていますか？実は、「数え方によっ
て異なる」というのが正解です。「オブジェクト図」と「パッケージ図」の扱
いかたによります。これらは第一級の図としては扱われていませんでした。UML2
では、これら２つの図が正式に定義されています。
また、「コンポジットストラクチャ図」、「相互作用概観図」、「タイミング
図」が新しく追加されています。
コラボレーション図が見当たりませんが、どうしたのでしょう。実は、「コミュ
ニケーション図」と名前を変えてしまったのです。理由は、「コラボレーション」
という概念と名前が衝突したためです。コラボレーションは、UML1でも、パター
ンなどの表記に使われていましたね。また、「ステートチャート」も「ステート
マシン」と名称変更されています。
あたらしく出た図ですが、大雑把には、以下のようなものです。
・コンポジットストラクチャ図
実行時の、クラスの内部構造を表現する図。
クラスの内部を階層的に表現できます。コンポーネントの表現に適していま
す。
・相互作用概観図
アクティビティ図の各アクティビティの中に、シーケンス図を描いた図。
複数のシーケンス図をアクティビティ図を使ってつないだ、と捉えることも
できます。
・タイミング図
複数のオブジェクトの状態変化を、横軸を実時間として描いた図。
特に、リアルタイム制御系などで、実時間の制約を表現したいときに使えま
す。
以上が、13個の全図です。
今回は、第1回目として、図の種類について書きました。
余談ですが、13という数、なにやら不吉な印象を与えますね。UML2が巨大・複
雑になりすぎて、Unwanted Modeling Language とならなければ良いのだが…と
いう一抹の不安がありますね。
（平鍋）
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?C002+0+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?C002+0+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?C002+0+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2 n d ■━
■
┗【プログラミング】リファクタリング-プログラミングの体質改善 [4]
さて、前回は不吉な匂いから『スイッチ文』を紹介しました。今回は予定通り
『長すぎるメソッド』を紹介します。メソッドが長すぎるとこんなことが起き
ますよね。
[メソッドが長いときに見られる症状]
・読む気が起きない（読みにくい）
・長い処理の一部に、どこかで見たようなコードが現れる（重複したコード）
読みにくいことは、保守にも拡張にも悪影響を及ぼします。また、重複したコ
ードについては、連載の２回目でも触れたように、同じ修正を複数箇所で必要
とするため問題が大きいです。
さて、長いことが問題ならば解決は簡単そうです。処理のまとまりに対して、
適切な名前で『メソッドの抽出』を行い、メソッドを短くしていきましょう。
この過程で、重複した部分は複数箇所から同じように抽出され、解消されるこ
とでしょう。また、適切な名前を与えることで、内部の細かい実装を読まずに、
コードを読み進めることができるようになります。ここまで来ると理想的です
よね。
・・と終わることができるなら苦労は少ないです。長いメソッドでは、全体が
一時変数によって複雑に絡み合っていることが多いものです。一時変数がいつ
までも使われていてメソッド分割しにくくありませんか？ また、そのような
状態で無理矢理メソッド分割すると、引数が多すぎて嫌になりませんか？ こ
のような症状を解消するためのリファクタリングを紹介します。
『一時変数の分離』
一時変数に何度も値が代入されていたら注意が必要です（ループの中は除きま
す）。本当は何の関連もない処理なのに、一時変数を使いまわしているせいで、
メソッドを抽出することが難しくなってしまいます。また、このような場合に
は、どこでどんな値を代入しているのかを変数名から想像することもできない
ので、読んでいて混乱してしまいますよね。
型が同じだからといって一時変数を使いまわさずに、意味のある名前を付けた
一時変数を、それぞれの用途に合わせて作成しましょう。
『問い合わせによる一時変数の置き換え』
メソッドを抽出したいのですが、その範囲が一時変数で溢れかえっています。
メソッドを抽出すると、これら全てが引数になるので、どの引数にどんな意味
があるのかを読み取るのが難しくなってしまいます。けれど、注意して見てく
ださい。その一時変数に入っている値は、その場で取得できる値ではないです
か？
例えば、getメソッドで取得できる値は、一時変数で扱う必要はありません。
毎回getメソッドを呼べばいいのです。また、ある計算結果を一時変数に入れて
使いまわしているかもしれません。これも計算処理をメソッドにして、毎回計
算すればいいのです。とにかく一時変数をなくしてしまいましょう。このよう
なときは速度で不利になる気がして、気が進まないこともあると思いますが、
そんなときは実測してみましょう。大抵の場合、全然遅くなかったりしますよ。
以上の２つのリファクタリングは、長すぎるメソッドを細分化していくための
下準備にあたります。ほとんどのケースはこれでメソッドの抽出を行いやすく
なるでしょう。しかし、上記のリファクタリングだけでは一時変数を減らすこ
とができずに、メソッドの抽出がうまく行えないときもあります。そのような
ときに威力を発揮するのが、次のリファクタリングです。
『メソッドオブジェクトによるメソッドの置き換え』
複雑なアルゴリズムを処理しているときにありがちなのですが、一時変数が絡
み合って、メソッド分割がうまく行えないことがあります。このようなときに
は、Method Objectパターン[Beck]を利用して、アルゴリズムをクラス化してし
まいましょう。まず、新しいクラスを作成して、たくさんある一時変数をクラ
スの属性にします。すると、メソッドを分割しても、変数の値はどこからでも
アクセスできるので、簡単にメソッドを分割できます。
今回は、不吉な匂いから『長すぎるメソッド』を紹介しました。サンプルコー
ドがなかったので、効果をイメージしにくかったかもしれませんね。イメージ
をつかめなかった方は、手持ちのコードを眺めて試してみてください。きっと
効果を体感できますよ。
次回は、不吉な匂いから『多すぎる引数』を紹介する予定です。わかりにくい
点や質問などは随時とりあげていきたいと思いますので、気軽にご意見をお寄
せください。お待ちしております。
_______________________________________________________________________
この記事への評価にご協力をお願いします。
URLをクリックして、「ご協力ありがとうございました」のメッセージがご使用
のブラウザに表示されれば投票完了です。
良かった：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E002+3+0
普通：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E002+3+1
イマイチ：
http://objectclub.esm.co.jp/cgi-bin/question.cgi?E002+3+2
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
■
┗編集後記
こんにちは、編集人です。
クリスマスイベントでの平鍋さんのオープニングビデオを公開しようかと企画
中です。ただサイズがかなり大きいので、現在四苦八苦しております。。応募
者多数なら公開します。公開を希望する方、メールにてご連絡ください。
さて。今週からこの編集後記にて、ことわざや四字熟語、名言などを強引にソ
フトウェア開発に結び付けた「強引な一言」を掲載していきます。
今週の強引な一言
*** 虎の威を借る（故事）***
実力もないのに、「オブジェクト指向だから大丈夫」「XMLだから心配ない」な
どと言っていませんか。自分に染み付いた知識を増やすことが肝要です。
（さとみ）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━--■--●--■
● ご意見、ご感想は ⇒このメールに返信ください
〇 配信中止、アドレス変更は ⇒http://www.ObjectClub.jp/mlmagazine_help.html
〇 免責事項、過去の記事は ⇒http://www.ObjectClub.jp/mlmagazine.html
■ 発行：オブジェクト倶楽部 ⇒http://www.ObjectClub.jp/
■ 編集代表：平鍋 健児
Copyright (c)2003-2004 オブジェクト倶楽部. All Rights Reserved.
powered by Eiwa System Management, Inc.