５−５−３ ClearStructuralFeatureAction
入力ピンで指定されたオブジェクトから、構造化特性の値をすべて一度に取り去るアクションです。（例え構造化特性の多重度の下限を下回っしまっても、取り去ってしまいます。）
指定された構造化特性に値が全くなかった場合は、何も起こらないことを意味します。
図 １１−０７
2006年6月30日金曜日
UML中級講座 第60回 ClearStructuralFeatureAction
昨日触れましたモチベーションに関しては別途議論したいと思いますが、今回は構造化特性アクションのうち残った最後の項目、ClearStructuralFeatureActionについて解説致します。
５−５−３ ClearStructuralFeatureAction
入力ピンで指定されたオブジェクトから、構造化特性の値をすべて一度に取り去るアクションです。（例え構造化特性の多重度の下限を下回っしまっても、取り去ってしまいます。）
指定された構造化特性に値が全くなかった場合は、何も起こらないことを意味します。
図 １１−０７
５−５−３ ClearStructuralFeatureAction
入力ピンで指定されたオブジェクトから、構造化特性の値をすべて一度に取り去るアクションです。（例え構造化特性の多重度の下限を下回っしまっても、取り去ってしまいます。）
指定された構造化特性に値が全くなかった場合は、何も起こらないことを意味します。
図 １１−０７
2006年6月29日木曜日
UML中級講座 第59回 RemoveStructuralFeatureAction
このブログは、"プロマネBlog"と名乗る割にはプロマネの話を殆どしないではないかという、友人達の心無い批判(?)に応えるため、本日は組織とモチベーションについてお話したいと思います。
最近は、(J)SOX法関連の話題が多くなってきました。
このSOX法は、広く知られておりますように、アメリカのエンロン社やワールドコム社の巨大粉飾疑惑と破綻がきっかけで制定されることになりました。
実は筆者は、９０年代にワールドコム社と多少関わり合いをもっており、従業員の年金基金が破綻して実質上年金が受け取れなくなったであるとか、経営幹部が謎の自殺を遂げたと言った話を聞くたびに当時の同僚達の顔が浮かび、心が揺るがされる人間の一人です。
会計学に詳しい人に聞くと、これらの会社で行われた会計操作は、手法としてはむしろ在り来たりなものばかりだそうですが、何しろその規模が桁近いに大きく、当の会社だけでなく、アメリカ資本市場へ拭いがたい不信感を生み、アメリカ社会そのものにも大きな影響を与えました。
では、なぜこのような巨大な粉飾が行われたのでしょうか？
筆者は、ワールドコムとの経験を通じて、犯行はCEOを含む少数のトップグループによるものだと考えています。
何故かというと、それ以外の人間にとっては、それだけの巨大粉飾を行なうモチベーションが働かないからです。
従来から、会計操作はどの会社でもあったと思いますが、今回の犯罪の背景としては、９０年代の株式市場中心主義があったと思います。
この株式市場中心主義においては、経営者の能力は、時価総額を上げる事、つまり株価を上げる事であるという考え方が支配的であり、エンロンやワールドコムの経営者達は事実ストックオプション等を通じて、巨額の利益を得る事ができました。
もちろん、利益を粉飾するというは、税額が上がるという負帰還（Negative Feedback)が働きますが、株式市場で得られる巨額の利益に比べれば、モチベーションに対する抑止力としては極めて弱いものです。
今回制定されたSOX法においては、従来の市場中心的なコーポレートガバナンスの手法ではなく、不正に関しては、経営者に対する責任を厳格に問うという姿勢がいっそう強化されています。
この株式市場中心主義的なアプローチは、日本においても、数年のタイムラグはあっても、確実に浸透して来ていました。
昨今、「村上ファンドが阪神ファンの逆鱗に触れ（？）、撤退を余儀なくされている云々」と言うニュースが流れていますが、その一端を象徴していると思います。
さて、組織の話を少ししたいと思います。
組織内に新しいルールを導入する際、最も注意しなければならないのはメンバーのモチベーションの問題です。
人をコントロールするという事は、端的にはモチベーションをコントロールする事です。
よく、新しいルールを導入したけども上手く行かないと言う話を聞きますが、圧倒的にモチベーションがコントロールされていない場合が多いようです。
人間は、機械ではないためルールだけ決めても、モチベーションが弱いとなかなか動きません。
また、不正に対する誘惑に対しても、罰則だけ強化しても無駄であり、不正が確実にあばかれうると言うことを、（少なくとも）思い込ませておく必要があります。
人は欲望や恐怖と言った原始から変わらぬ強い活力源を持ち、それを効果的かつ有効に、そして平和的に利用する事が、現代のマネジメントに要求されるスキルでしょう。
５−５−２−２ RemoveStructuralFeatureValueAction
入力ピンで指定されたオブジェクトから構造化特性の値を取り去るアクションです。
取り去る値を入力ピンで指定することも可能ですし、除去する場所をremoveAt（removeAtは整数値を取る）で指定することも可能です。
値を指定した場合、構造化特性中に該当する値が存在しない場合は、何も起こらないことを意味します。
指定された構造化特性が関連端であった場合、意味的にはリンクを消滅させることと同じ意味になります。
また、属性isremoveDuplicatesがtrueの時は、指定した値が複数ある場合はその重複する値すべてが取り除かれます。
図 １１−０７
最近は、(J)SOX法関連の話題が多くなってきました。
このSOX法は、広く知られておりますように、アメリカのエンロン社やワールドコム社の巨大粉飾疑惑と破綻がきっかけで制定されることになりました。
実は筆者は、９０年代にワールドコム社と多少関わり合いをもっており、従業員の年金基金が破綻して実質上年金が受け取れなくなったであるとか、経営幹部が謎の自殺を遂げたと言った話を聞くたびに当時の同僚達の顔が浮かび、心が揺るがされる人間の一人です。
会計学に詳しい人に聞くと、これらの会社で行われた会計操作は、手法としてはむしろ在り来たりなものばかりだそうですが、何しろその規模が桁近いに大きく、当の会社だけでなく、アメリカ資本市場へ拭いがたい不信感を生み、アメリカ社会そのものにも大きな影響を与えました。
では、なぜこのような巨大な粉飾が行われたのでしょうか？
筆者は、ワールドコムとの経験を通じて、犯行はCEOを含む少数のトップグループによるものだと考えています。
何故かというと、それ以外の人間にとっては、それだけの巨大粉飾を行なうモチベーションが働かないからです。
従来から、会計操作はどの会社でもあったと思いますが、今回の犯罪の背景としては、９０年代の株式市場中心主義があったと思います。
この株式市場中心主義においては、経営者の能力は、時価総額を上げる事、つまり株価を上げる事であるという考え方が支配的であり、エンロンやワールドコムの経営者達は事実ストックオプション等を通じて、巨額の利益を得る事ができました。
もちろん、利益を粉飾するというは、税額が上がるという負帰還（Negative Feedback)が働きますが、株式市場で得られる巨額の利益に比べれば、モチベーションに対する抑止力としては極めて弱いものです。
今回制定されたSOX法においては、従来の市場中心的なコーポレートガバナンスの手法ではなく、不正に関しては、経営者に対する責任を厳格に問うという姿勢がいっそう強化されています。
この株式市場中心主義的なアプローチは、日本においても、数年のタイムラグはあっても、確実に浸透して来ていました。
昨今、「村上ファンドが阪神ファンの逆鱗に触れ（？）、撤退を余儀なくされている云々」と言うニュースが流れていますが、その一端を象徴していると思います。
さて、組織の話を少ししたいと思います。
組織内に新しいルールを導入する際、最も注意しなければならないのはメンバーのモチベーションの問題です。
人をコントロールするという事は、端的にはモチベーションをコントロールする事です。
よく、新しいルールを導入したけども上手く行かないと言う話を聞きますが、圧倒的にモチベーションがコントロールされていない場合が多いようです。
人間は、機械ではないためルールだけ決めても、モチベーションが弱いとなかなか動きません。
また、不正に対する誘惑に対しても、罰則だけ強化しても無駄であり、不正が確実にあばかれうると言うことを、（少なくとも）思い込ませておく必要があります。
人は欲望や恐怖と言った原始から変わらぬ強い活力源を持ち、それを効果的かつ有効に、そして平和的に利用する事が、現代のマネジメントに要求されるスキルでしょう。
５−５−２−２ RemoveStructuralFeatureValueAction
入力ピンで指定されたオブジェクトから構造化特性の値を取り去るアクションです。
取り去る値を入力ピンで指定することも可能ですし、除去する場所をremoveAt（removeAtは整数値を取る）で指定することも可能です。
値を指定した場合、構造化特性中に該当する値が存在しない場合は、何も起こらないことを意味します。
指定された構造化特性が関連端であった場合、意味的にはリンクを消滅させることと同じ意味になります。
また、属性isremoveDuplicatesがtrueの時は、指定した値が複数ある場合はその重複する値すべてが取り除かれます。
図 １１−０７
2006年6月28日水曜日
UML中級講座 第58回 WriteStructuralFeatureAction
昨日、中野長者の話をしましたが、筆者のオフィスのあるこの街には、様々な長者伝説が伝わっています。
おそらく、他の伝承と同じく、長い年月の間に複数の話が重奏して現在の伝説になったのだと思いますが、筆者なりに原風景をたどってみました。
現在、新宿区、中野区、渋谷区の３つの区の境界が住宅地の細い路地を縫うように交錯するこの辺りは、かつては神田川の氾濫原であり、普段は神田川が細流として流れる荒れ地であったようです。
そして、人跡まばらなこの辺り一帯は、総称として漠然と「なかの」と呼ばれていました。
そこに、今から６００年以上前、鈴木九郎さんと言う人が紀州から移り住んできました。
鈴木氏は馬を商う事をなりわいとしており、今でも良馬を産み育てることは難しい事業ですが、おそらく優れた技術の持ち主だったのでしょう、後年、大変な大金持ちになったそうです。
しかしながら、現在この地には鈴木氏の子孫は全く伝わっておりません。
彼には、一人娘がいたようですが、（おそらく皮膚病だと思われる）難病を患い、若くして亡くなってしまったようです。
最愛の一人娘を失った悲嘆は、いくら巨万の富があっても癒すことができないのは、今も昔も変わりません。
彼は、全財産を仏法に委ね、屋敷を寺院としました。
最近の改修の際、成願寺の仏像の胎内から出てきた骨片を調べたところ、老人男性と若い娘の骨だと解りました。
おそらく、鈴木氏父娘だと言われています。
５−５−２ WriteStructuralFeatureAction
入力ピンで指定されたオブジェクトの構造化特性の値を変更するための抽象メタクラスで、具体的なアクションは、AddStructuralFeatureValueActionとRemoveStructuralValueActionの２つのサブクラスが規定しています。
歴史的には、UML1.5のWriteAttributeActionを一般化したもので、当然のことながらクラスの属性の更新を行なうこともできます。
なお、属性は複数の値を着けることができ、内部的には順序付のリスト構造の形で保持されます。
５−５−２−１ AddStructuralFeatureValueAction
構造化特性の値を付け加える為のアクションで、値の置き換えを行うことも可能です。
構造化特性は、複数の値が順序づけられて並べてある構造をしており、挿入点(insertAt)を指定して新しい値を挿入します。
属性isReplaceAllがtrueの場合、新しい値の挿入前に古い値がすべて取り除かれ、値の入れ替えが可能です。
指定された構造化特性が関連端であった場合、意味的にはリンクを形成することと同じ意味になります。
（注）挿入点（insertAt)は、整数値を取り、１は先頭を意味し、＊は末尾に付け加えることを意味します。
図 １１−０７
おそらく、他の伝承と同じく、長い年月の間に複数の話が重奏して現在の伝説になったのだと思いますが、筆者なりに原風景をたどってみました。
現在、新宿区、中野区、渋谷区の３つの区の境界が住宅地の細い路地を縫うように交錯するこの辺りは、かつては神田川の氾濫原であり、普段は神田川が細流として流れる荒れ地であったようです。
そして、人跡まばらなこの辺り一帯は、総称として漠然と「なかの」と呼ばれていました。
そこに、今から６００年以上前、鈴木九郎さんと言う人が紀州から移り住んできました。
鈴木氏は馬を商う事をなりわいとしており、今でも良馬を産み育てることは難しい事業ですが、おそらく優れた技術の持ち主だったのでしょう、後年、大変な大金持ちになったそうです。
しかしながら、現在この地には鈴木氏の子孫は全く伝わっておりません。
彼には、一人娘がいたようですが、（おそらく皮膚病だと思われる）難病を患い、若くして亡くなってしまったようです。
最愛の一人娘を失った悲嘆は、いくら巨万の富があっても癒すことができないのは、今も昔も変わりません。
彼は、全財産を仏法に委ね、屋敷を寺院としました。
最近の改修の際、成願寺の仏像の胎内から出てきた骨片を調べたところ、老人男性と若い娘の骨だと解りました。
おそらく、鈴木氏父娘だと言われています。
５−５−２ WriteStructuralFeatureAction
入力ピンで指定されたオブジェクトの構造化特性の値を変更するための抽象メタクラスで、具体的なアクションは、AddStructuralFeatureValueActionとRemoveStructuralValueActionの２つのサブクラスが規定しています。
歴史的には、UML1.5のWriteAttributeActionを一般化したもので、当然のことながらクラスの属性の更新を行なうこともできます。
なお、属性は複数の値を着けることができ、内部的には順序付のリスト構造の形で保持されます。
５−５−２−１ AddStructuralFeatureValueAction
構造化特性の値を付け加える為のアクションで、値の置き換えを行うことも可能です。
構造化特性は、複数の値が順序づけられて並べてある構造をしており、挿入点(insertAt)を指定して新しい値を挿入します。
属性isReplaceAllがtrueの場合、新しい値の挿入前に古い値がすべて取り除かれ、値の入れ替えが可能です。
指定された構造化特性が関連端であった場合、意味的にはリンクを形成することと同じ意味になります。
（注）挿入点（insertAt)は、整数値を取り、１は先頭を意味し、＊は末尾に付け加えることを意味します。
図 １１−０７
2006年6月27日火曜日
UML中級講座 第57回 ReadStructuralFeatureAction
現在使っている西新宿のオフィスは、駅からさほど遠くなく、周りも下町情緒が残っており、何といっても静かですので気に入っております。
近くには神田川が流れ、ぶらぶら散歩するにもなかなか良いところです。（足を伸ばせば、南こうせつとかぐや姫の歌碑もあるとか聞きます。）
歴史的にも古くから開けたところのようで、中野長者の伝説が伝わります。
この中野長者は相当の大金持ちであったらしく、成願寺という長者の屋敷跡に立てられたお寺の山号は多宝山と言い、立派な伽藍が残っています。
また、このオフィスをかつて借りていた会社（２社）は、後年上場をはたしたと言うことで、近所では縁起ビルとしても知られています。
しかしながら、最近はだんだんと手狭になってきたので、近々引っ越そうかと考え始めております。
さて、本日はReadStructuralFeatureActionを解説します。
UML1.Xの時代は、クラス構造が単純でしたので、単に属性を読み書きすれば良かっただけでしたが、UML2.0になって、構造化分類子が登場し、オブジェクトが内部構造を持つようになった結果、その内部構造を読むためのアクションが必要になってきました。それが、ReadStructuralFeatureActionです。
５−５−１ ReadStructualFeatureAction
入力ピンに置かれた対象オブジェクトのSturcturalFeatureで指定された値を読んで出力ピンに置くアクションです。
例えば、カプセル化クラス A１ の中にクラスA2が存在し、A2の属性Ｂをアクセスしたい場合、入力ピンにはA1のインスタンスを置き、SAtructuralFeatureは A1中のA2中のＢを指定します。
歴史的には、UML1.5のReadAttributeActionを一般化したものです。
従って、対象オブジェクトの属性を読んで出力ピンに置くことも当然出来ます。（その場合、StrructuralFeatureは、属性名を指定します。）
図 １１−０７
近くには神田川が流れ、ぶらぶら散歩するにもなかなか良いところです。（足を伸ばせば、南こうせつとかぐや姫の歌碑もあるとか聞きます。）
歴史的にも古くから開けたところのようで、中野長者の伝説が伝わります。
この中野長者は相当の大金持ちであったらしく、成願寺という長者の屋敷跡に立てられたお寺の山号は多宝山と言い、立派な伽藍が残っています。
また、このオフィスをかつて借りていた会社（２社）は、後年上場をはたしたと言うことで、近所では縁起ビルとしても知られています。
しかしながら、最近はだんだんと手狭になってきたので、近々引っ越そうかと考え始めております。
さて、本日はReadStructuralFeatureActionを解説します。
UML1.Xの時代は、クラス構造が単純でしたので、単に属性を読み書きすれば良かっただけでしたが、UML2.0になって、構造化分類子が登場し、オブジェクトが内部構造を持つようになった結果、その内部構造を読むためのアクションが必要になってきました。それが、ReadStructuralFeatureActionです。
５−５−１ ReadStructualFeatureAction
入力ピンに置かれた対象オブジェクトのSturcturalFeatureで指定された値を読んで出力ピンに置くアクションです。
例えば、カプセル化クラス A１ の中にクラスA2が存在し、A2の属性Ｂをアクセスしたい場合、入力ピンにはA1のインスタンスを置き、SAtructuralFeatureは A1中のA2中のＢを指定します。
歴史的には、UML1.5のReadAttributeActionを一般化したものです。
従って、対象オブジェクトの属性を読んで出力ピンに置くことも当然出来ます。（その場合、StrructuralFeatureは、属性名を指定します。）
図 １１−０７
2006年6月26日月曜日
UML中級講座 第56回 構造化特性アクション
日本とアメリカで企業文化が異なるのは周知の事実ですが、日本でも会社によって随分と文化が違うのと同じように、アメリカでも会社によってかなり異なります。
有名な例としては、東海岸（ボストンやニューヨークがある方）と西海岸（ロスアンジェルスやシリコンバレーがある方）の文化的違いです。
筆者は両方の企業での勤務経験があるのですが、これからお話します事は非常に印象的な光景として脳裏に残っています。
今から十数年前、シリコンバレーのベンチャー企業に勤めていた折、その会社の経営幹部のX氏（その当時55歳ぐらいでした）が、エンジニア達と雑談していた時に、話題が、X氏が昔立ち上げた企業の話になりました。
その企業は、比較的順調に成長して最終的にIBMに買収されることになり、Ｘ氏はIBM社にVP（バイスプレジデント）として迎えられる事になりました。
Ｘ氏がIBMのVPになると言う話を聞いて、当時存命中であった彼のご母堂はたいへん喜んだそうです（IBMは、その頃、東部エスタブリシュメントを代表する企業でした）。
さて、X氏が、IBM本社で開催される経営会議に初めて参加した時の事です。
彼は、張り切って、会議室に一番乗りで向かい、他のメンバーが来るのを待っていました。
ちなみ、X氏は特異な風貌をしており、靴下は真っ赤で、大柄のジャケットを着け、ネクタイはいつもミッキーマウス柄のものが好みで、一見するとサーカスのピエロのようなフレンドリーな印象を与えます。
この日は、彼はいつもよりもさらに（彼の流儀で）粧し込んで会議に臨んだそうです。
ところが、ダークスーツ姿の他のVP達は、入室するやX氏を見ると驚いたように目を背け、誰も彼には声を掛けず、まるでX氏がその場に居ないかのような態度を取ったそうです。
ここまでの話は、筆者にとってもさほど驚く話ではなかったのですが、驚いたのは、むしろこの話を聞いていたエンジニア達の反応です。
X氏が、「VP達が全員席につき、CEOがお付の人間を従えて厳かに入場してきた。そして、CEOが議長席に着き、おもむろに話を始めると、驚いたことに、全員がノートを取り出し、いっせいにメモを取り始めたんだ。」と言うと、聞いていたエンジニア達は大爆笑し、中には机を叩いて苦しそうに身もだえするほど笑っている人もいました。
次にお話する話も、90年代初頭の昔話です。
東部と西部で企業文化が変わると言いましたが、西部地域の同じシリコンバレーであっても、企業文化はまちまちです。
最も東部的だと言われたのは、CPUを作っているインテル社です。
今は知りませんが、当時はインテル社のマネージャは（驚いたことに）いつもネクタイをしていると言うことで有名でした。
一般的に言って、大きな工場を持つハードウエア中心の会社の経営者やマネージャ達は、俺は金を持っているんだと言わんばかりのキンキラの格好をしていないと社員になめられると言われています。
フォーマルさを基準として数直線を引くと、最も厳格なのがインテル社になり、シスコ・システムズあたりがその真ん中の中点辺りに位置し、ソフトウエア中心の企業になればなるほど、カジュアルな会社になって行き、アップル社はかなりくだけた部類に属しました。
そして、その当時最もくだけた会社として最右翼にランクされた会社がタンデム社であり、くだけた事で有名なカリフォルニア人たちをして、「もはや、会社の体をなしてない」と言わしめたほどでした。
タンデム社は、その後、他社に買収されて行きました。
5-5 構造化特性アクション
図 １１−０７
UML1.Xでは、オブジェクトは単純な構造でしたので、属性を読み取ったり（ReadAttributeAction)、書き込んだり（WriteAttributeAction)という簡単なアクションで済んでいたのですが、UML2.Xで構造化分類子が登場し、単に属性の読み書きでは不十分になった結果、この構造化特性アクションが導入されました。
基本的には、対象のオブジェクトにたいし、その構造的特性を読み書きするためのアクションですが、具体的には、ReadStructualFeatureAction、WriteStructualFeatureAction、ClearStructualFeatureActionの３つのサブクラスが意味を与えています。
有名な例としては、東海岸（ボストンやニューヨークがある方）と西海岸（ロスアンジェルスやシリコンバレーがある方）の文化的違いです。
筆者は両方の企業での勤務経験があるのですが、これからお話します事は非常に印象的な光景として脳裏に残っています。
今から十数年前、シリコンバレーのベンチャー企業に勤めていた折、その会社の経営幹部のX氏（その当時55歳ぐらいでした）が、エンジニア達と雑談していた時に、話題が、X氏が昔立ち上げた企業の話になりました。
その企業は、比較的順調に成長して最終的にIBMに買収されることになり、Ｘ氏はIBM社にVP（バイスプレジデント）として迎えられる事になりました。
Ｘ氏がIBMのVPになると言う話を聞いて、当時存命中であった彼のご母堂はたいへん喜んだそうです（IBMは、その頃、東部エスタブリシュメントを代表する企業でした）。
さて、X氏が、IBM本社で開催される経営会議に初めて参加した時の事です。
彼は、張り切って、会議室に一番乗りで向かい、他のメンバーが来るのを待っていました。
ちなみ、X氏は特異な風貌をしており、靴下は真っ赤で、大柄のジャケットを着け、ネクタイはいつもミッキーマウス柄のものが好みで、一見するとサーカスのピエロのようなフレンドリーな印象を与えます。
この日は、彼はいつもよりもさらに（彼の流儀で）粧し込んで会議に臨んだそうです。
ところが、ダークスーツ姿の他のVP達は、入室するやX氏を見ると驚いたように目を背け、誰も彼には声を掛けず、まるでX氏がその場に居ないかのような態度を取ったそうです。
ここまでの話は、筆者にとってもさほど驚く話ではなかったのですが、驚いたのは、むしろこの話を聞いていたエンジニア達の反応です。
X氏が、「VP達が全員席につき、CEOがお付の人間を従えて厳かに入場してきた。そして、CEOが議長席に着き、おもむろに話を始めると、驚いたことに、全員がノートを取り出し、いっせいにメモを取り始めたんだ。」と言うと、聞いていたエンジニア達は大爆笑し、中には机を叩いて苦しそうに身もだえするほど笑っている人もいました。
次にお話する話も、90年代初頭の昔話です。
東部と西部で企業文化が変わると言いましたが、西部地域の同じシリコンバレーであっても、企業文化はまちまちです。
最も東部的だと言われたのは、CPUを作っているインテル社です。
今は知りませんが、当時はインテル社のマネージャは（驚いたことに）いつもネクタイをしていると言うことで有名でした。
一般的に言って、大きな工場を持つハードウエア中心の会社の経営者やマネージャ達は、俺は金を持っているんだと言わんばかりのキンキラの格好をしていないと社員になめられると言われています。
フォーマルさを基準として数直線を引くと、最も厳格なのがインテル社になり、シスコ・システムズあたりがその真ん中の中点辺りに位置し、ソフトウエア中心の企業になればなるほど、カジュアルな会社になって行き、アップル社はかなりくだけた部類に属しました。
そして、その当時最もくだけた会社として最右翼にランクされた会社がタンデム社であり、くだけた事で有名なカリフォルニア人たちをして、「もはや、会社の体をなしてない」と言わしめたほどでした。
タンデム社は、その後、他社に買収されて行きました。
5-5 構造化特性アクション
図 １１−０７
UML1.Xでは、オブジェクトは単純な構造でしたので、属性を読み取ったり（ReadAttributeAction)、書き込んだり（WriteAttributeAction)という簡単なアクションで済んでいたのですが、UML2.Xで構造化分類子が登場し、単に属性の読み書きでは不十分になった結果、この構造化特性アクションが導入されました。
基本的には、対象のオブジェクトにたいし、その構造的特性を読み書きするためのアクションですが、具体的には、ReadStructualFeatureAction、WriteStructualFeatureAction、ClearStructualFeatureActionの３つのサブクラスが意味を与えています。
2006年6月23日金曜日
UML中級講座 第55回 TestIdentityAction
昨日、Mac OSの上でWindowsを走らせる話をしましたが、さっそく友人から、そんなややこしい事をせずに、初めからWindowsを使って書けばいいじゃないかと言う指摘を受けました。
当初から予想されたリアクションですが、それに対して答えるのは難しい問題です、と言うよりも、Windows使いの方に納得してもらえるような答え方がない、と言った方が正確でしょう。
筆者は、学生時代に、いくつかのパソコンを経て、往年の名機Apple IIにたどり着き、その素晴らしい設計思想に感動したくちです。
そして、卒業後入社したところで、これも名機として名高い初代IBM-PCに遭遇しました。
IBMは、現在ではPCを作るのを止めてしまったようですが、この初代IBM-PCは、その後20年以上にわたって、PC産業に多大なる影響を残しています。
Apple IIやIBM-PCには、単なる機械を超えた何かがあり、20数年経って登場したMacOSにも、その息吹を感じると言ったら、Windows使いの方には、納得して頂けるでしょうか？（無理ですね、すみません）
５−４−３ TestIdentityAction
入力ピンに置かれた2つのオブジェクトが同一のものかどうかを調べます。同一であればtrue、そうでなければfalseを出力ピンに置きます。
５−４−４ ReadSelfAction
すべてのアクションは、振る舞いもしくは振る舞いの一部であり、振る舞いは何らかの分類子の特徴です。（例えば、操作は何らかのクラスの特徴）
このReadSelfActionは、アクションが行われる主体（ホスト・インスタンスと呼ばれます）を、出力ピンに置くアクションです。
これは、パラメータの情報だけではアクションの主体が特定できない時などに、ホスト・インスタンスにアクセスするために付け加えられたアクションです。
また、親のオブジェクトが存在しないときは、振る舞いそのものがホスト・インスタンスとなります。
図11−06
当初から予想されたリアクションですが、それに対して答えるのは難しい問題です、と言うよりも、Windows使いの方に納得してもらえるような答え方がない、と言った方が正確でしょう。
筆者は、学生時代に、いくつかのパソコンを経て、往年の名機Apple IIにたどり着き、その素晴らしい設計思想に感動したくちです。
そして、卒業後入社したところで、これも名機として名高い初代IBM-PCに遭遇しました。
IBMは、現在ではPCを作るのを止めてしまったようですが、この初代IBM-PCは、その後20年以上にわたって、PC産業に多大なる影響を残しています。
Apple IIやIBM-PCには、単なる機械を超えた何かがあり、20数年経って登場したMacOSにも、その息吹を感じると言ったら、Windows使いの方には、納得して頂けるでしょうか？（無理ですね、すみません）
５−４−３ TestIdentityAction
入力ピンに置かれた2つのオブジェクトが同一のものかどうかを調べます。同一であればtrue、そうでなければfalseを出力ピンに置きます。
５−４−４ ReadSelfAction
すべてのアクションは、振る舞いもしくは振る舞いの一部であり、振る舞いは何らかの分類子の特徴です。（例えば、操作は何らかのクラスの特徴）
このReadSelfActionは、アクションが行われる主体（ホスト・インスタンスと呼ばれます）を、出力ピンに置くアクションです。
これは、パラメータの情報だけではアクションの主体が特定できない時などに、ホスト・インスタンスにアクセスするために付け加えられたアクションです。
また、親のオブジェクトが存在しないときは、振る舞いそのものがホスト・インスタンスとなります。
図11−06
2006年6月22日木曜日
UML中級講座 第54回 DestroyObjectAction
筆者はこのブログをアップル社のパワーブックを使って書いているのですが、インターネットユーザーの大部分はマイクロソフト社のインターネット・エクスプローラーを使用して見ているとのことですので、時々確認のために手持ちの古いIBM/PCや、マックOSの上でWindows環境をエミュレートするVirtualPCを立ち上げて見ています。
ところが、前者は持ち運びができず、後者はスピードが非常に遅いので、何か良い方法がないかと思っていたところ、先日発売開始されたMacBookとその上でWindows環境をエミュレートするParallelsと言うソフトの組み合せがなかなか評判が良いということで、早速、手に入れて走らせてみました。
結果は、スピードの点で全く申し分なく、VirtualPCは言うに及ばず、実機であるIBM/PCの速度を凌駕し（多分機械が古いせいでしょう）、またWindowsだけでなく、Linuxもインストールでき、なかなか快適なワーキングベンチが実現出来ました。
ところが、後になって気付いたのですが、モバイルで使っているPHSモデム（WillcomのAH-F401Uと言う機種です）がintelMac に対応しておらず、昨日は一日中オフラインの状況になってしまいました。
かつて、携帯電話が出回り始めたころ（十数年前）は、携帯電話でいつ呼び出されるかも知れないと言う状況が１つのストレス源でしたが、今や逆にオフライン下におかれることがストレスになってしまったようで、落ち着かない一日でした。
さて、前回に引き続き、オブジェクトアクションの１つ、DestroyObjectActionを解説します。
５−４−２ DestroyObjectAction
入力ピンのオブジェクトを消滅させるアクションであり、初期値やリンクを設定したり、ステートマシンの遷移を引き起こしたりと言った副作用を全く伴いません。
また、オブジェクトとしてリンクオブジェクトも対象になり、その場合DestroyLinkActionの定義に沿って処理されます。（DestroyLinkActionの項を参照。）
【属性】
このアクションは2つの属性、isDestroyLinksとisDestroyOwnedObjectsを持っており、意味は次の通りです。
❑ isDestroyLinks 初期値はfalse
• この属性がtrueの場合、対象のオブジェクトが関わっているリンクもすべて消滅させる。
❑ isDestroyOwnedOwnedObject 初期値はfalse
• この属性がtrueの場合、対象のオブジェクトが所有するオブジェクトもすべて消滅させる。
【制約】
• i 入力ピンの多重度は１
図１１−０６
ところが、前者は持ち運びができず、後者はスピードが非常に遅いので、何か良い方法がないかと思っていたところ、先日発売開始されたMacBookとその上でWindows環境をエミュレートするParallelsと言うソフトの組み合せがなかなか評判が良いということで、早速、手に入れて走らせてみました。
結果は、スピードの点で全く申し分なく、VirtualPCは言うに及ばず、実機であるIBM/PCの速度を凌駕し（多分機械が古いせいでしょう）、またWindowsだけでなく、Linuxもインストールでき、なかなか快適なワーキングベンチが実現出来ました。
ところが、後になって気付いたのですが、モバイルで使っているPHSモデム（WillcomのAH-F401Uと言う機種です）がintelMac に対応しておらず、昨日は一日中オフラインの状況になってしまいました。
かつて、携帯電話が出回り始めたころ（十数年前）は、携帯電話でいつ呼び出されるかも知れないと言う状況が１つのストレス源でしたが、今や逆にオフライン下におかれることがストレスになってしまったようで、落ち着かない一日でした。
さて、前回に引き続き、オブジェクトアクションの１つ、DestroyObjectActionを解説します。
５−４−２ DestroyObjectAction
入力ピンのオブジェクトを消滅させるアクションであり、初期値やリンクを設定したり、ステートマシンの遷移を引き起こしたりと言った副作用を全く伴いません。
また、オブジェクトとしてリンクオブジェクトも対象になり、その場合DestroyLinkActionの定義に沿って処理されます。（DestroyLinkActionの項を参照。）
【属性】
このアクションは2つの属性、isDestroyLinksとisDestroyOwnedObjectsを持っており、意味は次の通りです。
❑ isDestroyLinks 初期値はfalse
• この属性がtrueの場合、対象のオブジェクトが関わっているリンクもすべて消滅させる。
❑ isDestroyOwnedOwnedObject 初期値はfalse
• この属性がtrueの場合、対象のオブジェクトが所有するオブジェクトもすべて消滅させる。
【制約】
• i 入力ピンの多重度は１
図１１−０６
登録:
投稿 (Atom)