OMGによってMDA（Model Driven Architecture）が発表されて数年が経過しました。
現状、MDAはどこまで実現されているのでしょうか？

これまでMDA対応をウリにしたツールはたくさんリリースされましたが、
それらの多くは単にコード生成機能を備えたUMLツールであり
「MDA＝モデルからのソースコード生成」という誤解を生んでしまいました。

MDAベースのソフトウェア開発では、まず実装技術に依存しないモデル（PIM）を開発し、
そこから実装技術に依存したモデル（PSM）に変換して、ソースコードを生成します。
このように本来MDAが目指していたのは、モデルを実装に依存しない視点と
実装に依存する視点に切り分けることで、変更に強くすることだったはずです。
（MDAの概要はOMGのMDA guideを参照してください）

これを実現するため、MDAツールにはMOF（Meta Object Facility）
を基盤としたモデルの変換機能が必要になります。
これまでもモデル変換機能を備えたMDAツールもありましたが、
ベンダー独自の仕様で開発されており、標準仕様は存在していませんでした。

OMGでは、MDAを実現するために数年かけてモデル変換に関連した
標準仕様の策定を進めており、ほぼ完成に近いところまできています。
仕様策定に加わっているベンダーは、ツールの開発も同時に進めているでしょうから、
OMG標準ベースのMDAツールがリリースされる日も近いのではないでしょうか。

なお、OMGにおけるMDAのPIM開発関連仕様には、
ビジネスシステム用のUML Profile for EDOC、
組み込みシステム用のExecutable UMLなどがあります。
EDOCはOMGで標準化され、すでに公開されていますが、
UML1.4がベースになっているため、UML2.0対応が待たれるところです。
また、Executable UMLはこれまで各ベンダーの独自仕様でしたが、
現在OMGでスティーブ・メラーを中心に標準仕様の策定が進められています。

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

投稿者: hashimoto 日時: 18:14 | パーマリンク | トラックバック (0)

テクノロジックアートの橋本です。
今回はEA（Enterprise Architecture）について取り上げたいと思います。
数年前に一時流行ったEAですが、最近は日本版SOX法などの動きもあり、
本格的に導入しようとする企業が増えてきました（SOX法についても今度取り上げたいと思います）。
しかし、EA自体はざっくりとした枠組みが決まっているだけですので
各企業ごとに具体的なモデルの表記法や開発手法、管理手法等を定めなければなりません。

日本政府でも情報システムの調達制度を見直し、EAの導入を進めるため、
これらの統一的な手法を示すガイドラインを定めました（業務・システム最適化計画策定指針）
このガイドラインでは、各EAの体系ごとに作成すべきモデルが表記法も含めて規定され、
モデルの専門家でない人にも分かりやすい一方、様々な種類の表記法を採用しているために
対応できるツールがない（または限定されてしまう）という問題がありました。
（DMM、DFD、WFA、ERなどの表記が規定されている）

この問題を解決するための１つの手段は、ガイドラインで規定されたモデルを
すべてUMLで表現できるようにしてしまうことです。
UMLには特定の対象をモデリングするために、UML自体を拡張するメカニズムがあります。
これがUML Profileと呼ばれるものです。

弊社が委員として参加しているINTAP（情報処理相互運用技術協会）の
オープンシステムモデリング技術委員会では、上記のガイドラインで規定されたモデルを
UMLベースで表現するための議論を進めてきましたが、
その成果が「日本版EA対応UML Profileに関する研究報告書」として公開されました。

この報告書には、上記ガイドラインの各成果物を、
UML2.0ベースで表現するためのUML Profileが定義されています。
このUML Profileデータとサンプルモデル（パターンウィーバー用）は、
以下のURLからダウンロードできますので、一度お試しいただければと思います。
（パターンウィーバーの評価版でもお試しいただけます）

http://www.intap.or.jp/
http://net.intap.or.jp/INTAP/information/report/17-rm_odp-report.pdf
http://www.intap.or.jp/odp/index.html

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

投稿者: hashimoto 日時: 23:18 | パーマリンク

テクノロジックアートの橋本です。
ちょっと宣伝になってしまいますが、今回はツールの話題を取り上げます。
弊社で扱っているUMLツールパターンウィーバーが2月末に
マイナーバージョンアップされました。
マイナーといっておいて実は内部的には大きく変わっており
ほとんどメジャーバージョンアップ並みの変更が行われています。

今回のバージョンアップの目玉はなんといっても名前空間のサポートです。
これにより、しっかりとしたモデル管理が行われるようになったため
かなり本格的なモデリングにも耐えられるようになったと思います。
従来からの画像出力やPDF出力、ソースコードのフォワードがついて
￥7,800ですから、ますますお得感の増したUMLツールになったのではないでしょうか。

なお、2.1の発売と同時にプラグイン開発キットもリリースされました。
これはパターンウィーバーの追加機能を独自に作成するためのキットで、
C++ソースコード出力プラグインなどもこのキットで作成されています。
名前空間のサポートとプラグイン開発キットのりリースにより
いろいろなツールとの連携なども容易になったのでこれからが楽しみです。

ちなみに評価版は以下よりダウンロードできます。
http://pw.tech-arts.co.jp/download/community_edition.html

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

投稿者: hashimoto 日時: 22:28 | パーマリンク

テクノロジックアートの橋本です。
私は普段の業務でUML・モデリング関連のコンサルティングを担当しています。
このブログでもこれに関連した話題を中心に情報発信していきたいと思います。
１回目の投稿ということで、UMLを活用するためのポイントについてとりあげたいと思います。

現状UMLはJavaなどオブジェクト指向ベースの開発が一般的になったこともあって
設計の道具として、かなり浸透してきたのではないかと思います（使われ方のレベルは様々ですが）
技術者の中でUMLという言葉を知らない人はほとんどいなくなりましたし、
設計書の中では、クラス図やシーケンス図が当たり前のように登場しています。
モデリングツールも安価なものから高価なものまでいろいろ販売されていますね。

ただ、UML本来のメリットを引き出して活用するというレベルまでには
なかなかたどりつけていないのではないかと思います。
UMLを活用するために必要な知識は、表記法だけでなく、
オブジェクト指向の基礎知識はもちろんのこと、開発プロセス、
アプリケーションアーキテクチャなど多岐にわたります。
また、モデリングのポイントである粒度、上流～下流までのシームレス性などは、
知識よりも経験によって身についていくものです。
プロジェクトに合わせてUMLの中から使用するダイアグラムを選択して
サブセット化する能力も重要です。

これらは簡単に身に付くものではなく、
モデリングを何度もおこなって経験を積んでいくことが大切です。
特に一番確実で効率よくスキルが向上する学習法は、
小さい範囲でいいので、上流～下流までをなるべくシームレスにつなげて
プログラムまで落としてみることかと思います。
プログラミングすることでその上流のモデルに問題点が見つかり、
それをモデルに反映していくことで、精度の高いモデルが完成します（イテレーティブですね！）

この学習法で身に付く重要なスキルは後工程を考えたモデリングができるようになることです。
（例えば、どの粒度でユースケースを書くと、クラス図にどう影響するか？
　どうシーケンス図を書くと、プログラミングにどう影響するか？など）
このスキルを鍛えることで、上記の粒度やシームレス性などが意識された
品質の高いモデルが書けるようになっていきます。

最初の投稿ということで張り切って長くなりましたが、
今後はもっと細かい内容の投稿もしていく予定ですのでよろしくお願いいたします(^^;

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

投稿者: hashimoto 日時: 19:54 | パーマリンク