« 2006年06月 | メイン | 2006年08月 »

2006年07月25日

科学と魔法

長い梅雨も、もうすぐ明けようかという今日この頃、 皆様いかがお過ごしでしょうか。 梅雨は最後に各地で大きな爪跡を残しているようですが、もうすぐ雨続きの日々から抜け出し、 太陽の下で過ごせるようになりますね。なりますよね?! まぁ私はもっぱら、昼間に屋外に出て過ごす時間は極僅かではありますが。

ご無沙汰しておりました(*1)、 前回 に比べて幾分静かにお送りしてみようと思っている私 "岡部" が、 不定期にお届けする雑談コーナー第2回です。

今回のテーマは「科学と魔法」です。「科学と魔法」といえばファンタジー、 そういえば最近なにかとファンタジー分野の作品が話題に上ることが多い気がします。 私も子供の頃は、分厚い本を図書館から借りてきてはよく読んでいたものです。

ソフトウェアの世界では、もっぱら科学の力が大きいように私は思っています(*2)。 科学とは、誤解を恐れずに簡潔化するならば、「記号」と「帰納」と「演繹」です。

記号

そもそも人間は、現象をありのままに知覚しているわけではないですね。 「知覚」するということは、扱うことの出来る情報の形に当てはめているということです。 良い例かは判りませんが、そうであるが故に錯覚という現象が存在するわけです。 科学(その基礎である数学(的方法))では、それをより広義に適用し、 様々な事柄を記号として扱うことで、 複雑な考察も単純化する等して進めていけるようにしているんですね。

まぁ、普段意識せず使っている「名前」だって立派な記号です。

ソフトウェアの世界は、 少なくとも今は、 その仕組みがほぼ全て見えているままですから、 記号論だらけですね。

帰納
様々な具体的な事柄から、抽象化された法則を導くことですね。 記号化して帰納することで、共通法則を軸にして、 広範囲の事柄を抽象化して扱うことが出来るようになるわけです。
演繹
帰納とは逆に、大法則から具体的な結果について導くことですね。 三段論法なんかが該当します。 つまり、各具体的な事柄に当てはめるとどうなるか? を導くわけです。

ね、ソフトウェア自体も、ソフトウェア開発も、とっても科学的な活動でしょう? 実装技術だって、モデリングだって、みんな科学の力といって過言ではありません。

でも、ソフトウェアの世界には魔法の力も登場します。 皆さんの身近なアプリケーション等にも、魔法使いが居るでしょう?

魔法使い、それは「ウィザード」です。科学的に整然と作り上げられたソフトウェアを前に、 次に何をしたら良いのか解らなくなった時、目的に合わせて色んなお膳立てをしてくれるアレです。 なにをどうやったのか教えてくれないまま、気付くとお膳立てが済んでいる、手品師みたいなアレです。

私は、先にも述べたように、ソフトウェアにおいては科学の力が大きいと思っています。 それは、ソフトウェアがそもそも科学の力に基づいて成り立っている仕組みである,、 ということからも自明と言って良いでしょう。

でも科学というのは、時に人間の論理にはマッチしないことがあるんですね。 科学の良い所は、理論立てることで広範囲の問題を統一的に扱えることですが、 そうして用意された「これだけあれば、演繹でどんな問題も解けるでしょ」というセットを用意しても、 人間の側が使いこなせないという場合が、あるんですね。

そんな時に登場する助っ人がウィザードになるわけです。 ありがちなシチュエーションであれば、目的に応じて代わりにあれこれ操作してくれるわけですね。 「どんな問題でもこのセットがあれば解決できる」と言われても、オーバースペックである場合もありますし。

これまでの常識を覆して、いっそウィザード式の操作をメインにしてソフトウェアを開発しよう、 という動きもあります。それは、ソフトウェア開発の都合ではなく、 使う人の視点に基づいたユーザーインターフェースを提供するということでもあります。 ソフトウェア開発の都合で科学的な操作セットをそのまま押し付けるのは、 エゴであり、サボリだというわけです。

他方、だからといって、何もかもウィザード式にすれば良いかというと、そうでもありません。 科学的な操作セットが役に立つ(*3)こともありますし、 少なくともソフトウェアの内部は科学的で良いと思いますから。 ただ、機能を実現する方法と、ユーザーインターフェースの提供の仕方は、 別だということですね。 ユーザーインターフェース部分がちゃんと機能実装と分離しているならば、 使用者や目的に合わせて最適なインターフェースをラッパーとして提供すればよいのですから。

そうすれば、ソフトウェア(内部)の開発は科学の力で行い、汎用的に活用できるようにもしておきながら、 ユーザーに対しては用途や目的に応じて適切なインターフェースによってそのサブセットを提供するということが出来ます。 勿論同じユーザでも、違う用途や目的に対しても活用したいということになれば、 そのときにはインターフェースを追加したり組替えたりすれば良いですし、 原理的には同じ問題を扱っている異なるアプリケーションにおいても、 内部は同じでインターフェースの違いで対応することが可能でしょう。 オブジェクト指向であるとかコンポーネントベースの開発手法にも通ずる話ですね。

というわけで、今回はソフトウェアの構造的特徴とユーザーインターフェースのあり方について、 話題にしてみたのだと思います、多分。 それでは、またいつか、第3回でお会いしましょう。

*1
元々、筆不精なんです。書くこと自体は嫌いではないんですが。 書くことは色々と自分の為にもなりますしね。
*2
「それはオマエが理系だからだろう!」とか言われてしまうと、 そうなのかも知れませんけどね。 「理系」と「文系」については、またどこかで論じてみたいですね。 違わないかに見えて違うところと、違うかに見えて違わないところが、 あったりしますよね。 いずれにせよ、そんなにはっきりと線引きがあるとは、思わないですけれども。
*3
私は、科学的な操作セットが全くなくなってしまうのは困ります。 逆にそういう操作セットさえあれば、自分で演繹して問題に対処すれば良いので、安心です^^;
岡部 太一
テクニカルデプト デベロップメントグループ
システムエンジニア

2006年07月21日

UML仕様書の読み方

皆さんはUMLの仕様書を読んだことがありますでしょうか?
OMGがUMLの認定試験(Ocup)を始めたこともあって、
以前よりはUMLの仕様書を読んだことがある技術者は
増えてきたのではないかと思います。
(以前はツールベンダーや一部コンサルタントしか読んでいなかった)

UMLの仕様書はもちろん英語ですし、ページ数も多いので
ちょっと読むのに躊躇するかもしれませんが、
コツさえつかめば簡単だったりします。
(UML2.0になってUML1.X時代よりはるかに読みやすくなりましたし)

UMLの仕様書はあらかじめその構成を知っておくと読みやすくなりますので
今回はちょっとだけ解説したいと思います。
(ちなみにUMLの仕様書はここからダウンロードできます)

UMLの仕様書は大きく構造(Structure)に関する要素(クラスやコンポーネント等)と
振る舞い(Behavior)に関する要素(アクションや相互作用等)の2つのPartに分けられて解説されています。
さらにその中は章ごとに分けられ(だいたいダイアグラム単位と考えればよいでしょう)
UMLの各要素(クラス、コンポーネント、ユースケース等)が解説されています。
以下にUML仕様書の構成を俯瞰してみました(要素「クラス」の場合)。

UML Specification(UMLの仕様)
 └Structure(構造に関する要素)
   └Classes(クラス図関連要素のパッケージ)
     ├Overview(パッケージの概要説明)
     ├Abstract Syntax(メタモデル)
     ├Class Description(所属要素群)
     │  └Class(要素)
     │    ├Generalizations(継承元の要素)
     │    ├Description(概要説明)
     │    ├Attributes(保持する属性)
     │    ├Associations(関連する要素)
     │    ├Constraints(制約)
     │    ├Additional Operations(オプション)
     │    ├Semantics(要素の意味)
     │    ├Notation(表記法)
     │    ├Presentation Options(表記上のオプション)
     │    ├Style Guidelines(表記上のガイドライン)
     │    └Examples(表記例)
     │
     └Diagrams(所属要素群の表記例一覧)

私がいつもUML仕様書を読んで各要素の調査を行う際には、
以下のような手順を踏んでいることが多いですね。

1)調査対象となる要素のAbstract Syntax(メタモデル)を確認
2)その要素のClass Description(要素説明)を確認

Abstract SyntaxはMOFで表現されたUMLのメタモデルのことで、
各要素がどんな概念なのかをモデルとして表現しています。
文章からはつかみにくいことも、モデルを見れば理解できることが多いですね。

                         テクニカルデプト  橋本 大輔

2006年07月19日

なんでも実装技術から

この業界はなんでも実装技術から注目される傾向がありますね。
オブジェクト指向もJavaや.NETのような実装技術が普及した後で、
UMLが注目されていますし、コンポーネント開発もEJBのような
実装技術から注目されています。

最近流行のSOAもまずは実装レベルの製品ばかりが注目され、
ビジネスプロセスモデリング等はその後といった順番のようです。
SOAの目的はビジネスとシステムの部品の粒度をあわせることで、
保守性や再利用性を向上させることですから、
ビジネスプロセスモデリングによってしっかりとビジネスが
整理できていないと、SOAの目的は100%実現しないんですが。

SOAの場合、ベンダー側の責任も大きいのかもしれませんね。

                         テクニカルデプト  橋本 大輔

2006年07月04日

UML Profileとは?

UML ProfileとはUMLを特定のビジネスドメイン(業務分野)や
プラットフォーム(実装技術)向けに拡張するための
ステレオタイプがセットされた仕様のことです。
UMLを拡張するためには、UMLで定義されている
「ユースケース」や「クラス」などの要素に対して
ステレオタイプを付けて意味を加えます。

例えば、UML Profile for EDOCに定義されたステレオタイプ
《ProcessComponent》は、UMLの要素Classifier(分類子)を拡張しています。
このステレオタイプには、タグ(Property)としてprimitiveSpec、
primitiveKind、isPersistent、granularityなどが用意されており、
通常のClassifierでは用意されていない内容をこの要素に定義することができます。

UML Profileを利用したモデリングはMDAでも重要です。
MDAにおけるモデル変換定義を行う際に、多くの場合は
PIMとPSMで使用するUML Profileに定義されたステレオタイプ間の
マッピング(対応付け)を行うからです。

パターンウィーバー向けにも様々なUML Profileデータが提供されています。
サンプルモデルも用意されていますので、UML Profileを使用したモデリングをお試しください。
http://pw.tech-arts.co.jp/download/uml_Profile.html

                         テクニカルデプト  橋本 大輔