ストラタジーナム メニュー

2006年8月11日金曜日

UML中級講座 第85回 インタラクション図のメタモデル

インタラクション・フラグメント

インタラクション・フラグメントは、直感的にはインタラクション図そのものを示す包括的な抽象メタクラスです。
セマンティクス的には、イベントのトレースと同等のものになります。
図14-07は、インタラクション・フラグメントを定義するメタモデルのうち、コンバインド・フラグメントを説明する部分だけを切り出したものです。
コンバインド・フラグメントは、インタラクション・フラグメントの一種であり、インタラクション・オペレータと言う属性を持ちます。(属性は、alt、opt等の値を取ります。)
また、コンバインド・フラグメントは、インタラクション・オペランドを持ち、オペランドは、インタラクション・フラグメント(つまりあらゆるインタラクション)とインタラクション制約を持つ事が可能です。
オペランド自身が、インタラクション・フラグメントを所有するので、あらゆる形の入れ子が可能になります。
また、テクニカルなモデリングですが、Continuationもインタラクション・フラグメントの一種として定義されています。

図14-07




2006年8月8日火曜日

UML中級講座 第84回 コラボレーションとインタラクション図(2)

日本人は資格好きと言われますが、確かに歴史能力検定とか漢字能力検定とかの話を聞くといかにもと言う気がします。
一般的に、儒教の影響が強い国は資格好きだと言われていますが、欧米でも社員の採用の際には資格は大きな力を発揮します。
その資格として最も有名で顕著な例が、MBAです。
MBAと言っても、ある一定レベルの大学院以上でないとあまり効果は発揮しませんが、筆者が見聞きした例でお話ししたいと思います。
例えば、マーケティングマネジャーを外部から採用する際、ほとんどの会社ではMBAは必要条件の一つとされ、持っていないと書類選考の段階でどんどん落とされて行きます。
MBAを持っているから優秀だとは誰も思っていませんが、不適格の人材を採用するリスクを軽減するための措置で、その証拠に、内部からの登用ではあまりMBAは重視されず実績第一で審査されます。
また、80年代のMBAがまだ希少価値があった時代と違い、MBAだからと言ってエリートコースを歩める保証はありません。
純粋に入場切符を手に入れたに過ぎません。
そして、入り口切符としてのMBAの威光が効くのはせいぜい30代半ばまでであり、それ以降は経歴の方が重要視されて行きます。

筆者は以前シリコンバレーの会社でマーケティングの仕事をしていた事がありますが、その当時の上司はハーバードのビジネス・スクール出身で、また、同僚達の大部分はスタンフォードやMIT等の有名大学のビジネス・スクールの出身者達でした。
マーケティング部門では、MBAを持っている事自体はエリートでも何でもなくただの入社資格だったのです。
そして、面白い事にほぼ全員が理工系くずれでした。
理学部や工学部を卒業し、何年か会社勤めをした後、ビジネススクールに入ったと言う人ばかりで、それが一種の標準パターンでした。(ビジネススクール側も、実務経験者の入学を歓迎しています。)

コラボレーション・ユースとインタラクション・ユース

前回、コラボレーションとインタラクション図の関係をお話しましたが、本日はその具体例を見てみましょう。
図C13では、コラボレーションの例として”売買”を示しています。
買い手の法人組織Aと売り手の法人組織Bが、それぞれ小売店と卸業者にバインドされています。
下の図では、それらがインタラクション・ユースの形で表現されています。

図C13




2006年8月7日月曜日

UML中級講座 第83回 コラボレーションとインタラクション図

最近は、IT業界も活況を呈してきており、どこの会社も大忙しのようです。
しかしながら、この好景気もかつてIT産業が経験してきたものと少し性質が違ってきているようです。
IT業界はかつては好不況の景気の波の影響をほとんど受けない業界として有名でした。
以前は、売上など毎年上がるのが当たり前で、前年を割り込むなんて言う事態は想像の外でしたが、しかしながら、今では珍しい事ではなくなって来ています。
そして、その好不況の波に最も影響を受けているのが、システム・インテグレーターの様です。
システム・インテグレーターは(日本では特に定額請負が多く)プロジェクト自体のリスクが高い上に、少し景気が悪くなると一番最初にストップするのが新規開発案件であるため、業態そのものが高リスクな体質になっています。
また、ハードウエアに続き、最近ではソフトウエアも値段が下がりつつあり、ものによってはただで、通常の商品より良いと言うものまで出回ってきております。
従って、どこのシステム・インテグレーターも生き残り策を熱心に巡らしているようですが、すべてに共通して見られる現象は、サービスに対する強い志向と言えるでしょう。

コラボレーションとインタラクション図

インタラクション・ユースは、コラボレーション・ユースと強い関係があると述べましたが、本日は、その表記例を見て行きましょう。

図C12は、コラボレーションが分類子に適用される様を表現しています。
コラボレーションWは、superAとsuperBと言う二つのクラスからなるパート(xとy)を持っており、クラスEの内部構造に示されるクラスAとBは、それぞれクラスsuperA、クラスsuperBを特化したものです。
クラスEは、コラボレーションWを適用したコラボレーション・ユースw1を持っており、xとyの二つのパートが
クラスのインスタンスである:Aと:Bに結びつけられています。
下の図は、それをインタラクション図で表現したものです。

図C12




2006年8月4日金曜日

UML中級講座 第82回 複合構造図とインタラクション図

複合構造図とインタラクション図

複合構造図が導入されるまではクラスは単純な形をしていましたので、必然的にインタラクション図も単純ですんだのですが、UML2.0以降になって、インタラクションに内部構造を持った分類子が参加して来るようになり、表記も変わってきました。

パート分解

パート分解は、生存線の内部構造を表現するインタラクション・ユースの特殊形で、コネクタブル・エレメントがインタラクションの参加者として登場します。
(コネクタブル・エレメントは、複合構造図の開設時にほんの少し触れましたが、コラボレーションは、コネクタブル・エレメント間の関係として定義されます。)

図C11は、パート分解の例で、(a)で AC_UserAccessと言う名前のパート分解を呼び出しています。
図(b)のp1とp2は内部のコネクタブル・エレメントを表し、そして、直接"Please Enter"と言うメッセージをインタラクション・ユースの外側に送信しています。
(参考: この様なフラグメントを、エクストラーグローバル コンバインド・フラグメントと呼びます。)

図C11




2006年8月3日木曜日

UML中級講座 第81回 インタラクション・ユース(2)

昨日に引き続き、インタラクション・ユースについて解説致します。

図C09は、インタラクション・ユースを呼び出す例です。
Establish Access("不正なピン番号”)と言う風に、インタラクション・ユースに入力パラメータを渡す事が可能です。
この図の場合、不正なピン番号を渡していますので、オプションのコンバインド・フラグメントは実行されずドアは開かれません。(ただし、厳密には、この図ではオプションの実行条件が明示されていませんので、曖昧な形になっています。)

また、出力パラメータの結果の値や、インタラクション・ユースが値を返す場合の戻り値を、コロン(:)の後ろに書く事が可能です。

図C09

図C10は、結果の戻り値が記述された例です。
まず、a_op_b自身がインタラクション・ユースであり、戻り値を返すことに注意して下さい。(戻り値の型Verdictは、判定結果(合否もしくはpassとfailを表すタイプです)
そして、戻り値自身が生存線としてインタラクションに参加しています。

動きとしては、まずa_util_bというインタラクション・ユースを呼び出す際、s1とwの2つの入力パラメータを渡しており、さらにwは出力パラメータとしても働き(入出力パラメータ)、その結果が12である事が示されており、さらにa_util_bの戻り値が9で返され、その値がxx.xcに代入されます。
その次の代替コンバインド・フラグメント(”alt"のオペレータを持つコンバインド・フラグメント)では、結果に応じて、a_op_bに値がセットされる事が示されています。

図C10




2006年8月2日水曜日

UML中級講座 第80回 インタラクション・ユース

本日は、インタラクション・ユースについて解説します。

インタラクション・ユース

以前は、インタラクション・ユースは、インタラクション・オカランスと呼ばれていましたが、用語の一貫性の観点から改められました。
語感的には、オカランスは、イベント・オカランスに代表されるように、メッセージの送受信など、事象の発生に焦点を当てたものに使用され、ユースは、ユース・ケースやコラボレーション・ユースなどのように、役割に焦点を当てた場面で使用されます。
インタラクション・ユースは、感の鋭い方はお気付きと思いますが、コラボレーション・ユースと深い関係があります。
さらに言うと、コラボレーションの別の表現と見なす事が出来ます。
インタラクション・ユース内の参加者は、個々のインスタンスを表現しているのではなく、参加者の役割を表現しています。

図C08



図C08の図(b)は、インタラクション・ユースの表現例です。
この図のインタラクション・ユース"N"の参加者、":B"や":C"は、個別のインスタンスを表しているのではなく、インスタンスの役割を表象しています。
従って、インタラクション・ユース"N"が複数回呼び出された場合、登場するインスタンスは、呼び出される度ごとに異なっている可能性があります。(もちろん同一の場合もあります。)
個々のインスタンスは、呼び出す側が決定する形になります。


2006年8月1日火曜日

UML中級講座 第79回 Continuation

このブログに掲載している図は筆者が書いたものではなく、以前弊社に勤務していたモンゴルからの留学生の方にまとめて書いておいてもらったものを使用しています。
現在、彼女はアメリカ留学中ですが、最近になってつくづく書いておいてもらって良かったと感謝しています。
ブログも70回を超えると、だんだん書く事が負担に感じつつも、読んで下さる方がいらっしゃる事を唯一の励みとして続けておりますが、図まで自分で書いていたら、きっと15回目ぐらいでやめていたと思います。

Continuation

Continuationは、代替コンバインド・フラグメント(”alt ”のついたコンバインド・フラグメント)中で用いられるラベルで、アクティビティ図中のコネクターと同じように、同じラベルが付いたContinuationに制御がジャンプします。
従って、完全に表記法上の問題と言えるでしょう。
図C07は、Continuationの使用例で、図(a)のQestionは、図(b)で表されるインタラクション・ユースを呼び出し、図(b)の代替コンバインド・フラグメントの"OK"から、図(a)の"OK"へ制御がジャンプし、図(b)の"notOK"から図(a)の"notOK"へジャンプする事を示しています。
図(c)は、(a)と(b)をまとめたもので、全く等価の振舞いをします。

図C07