UMLモデリングの基礎
ITエンジニアにとって，今やUMLモデリングのスキルは必須と言って良いでしょう。特に要求の妥当性を判断するため，システムの導入によって業務がどう変わるのかを可視化する上でモデリングは大いに役立ちます。 この講座では，RFP（Reruest For Proposal）の作成までに必要な，業務とシステムの分析について，UMLモデリングの基礎を解説します。Part1～Part2は「基本編」として，モデリングの意義や大まかな手順を学びます。その上でPart3～Part12において「演習編」として，中古車の買取・販売の業務を題材に，モデリングの実際を見ていきます。 なおこの講座では，基本的にUML1.5をベースした表記を用います。これを拡張したUML2.0が登場していますが，実際には大抵の場合UML1.5 で事足ります。UMLモデリングの基礎を学ぶ上では，シンプルなUML1.5を使う方が良いでしょう
JUDE を Mac OS X で使う
JUDE/Community は無料で使える UML モデリングツールです。Java で書かれているので、もちろん Mac OS X でも動作します。コマンドラインから起動してもいいのですが、せっかくなので、通常のアプリケーションのようにダブルクリックで起動できるようにする方法を紹介します。 (2009-08-30追記) Mac OS X 10.6 Snow leopard でも、同じ手順で作成できることを確認しました。 準備 材料と道具として、次の 2つが必要です。 この記事の執筆時点 (2009年 2月 27日) 時点での JUDE/Community の最新バージョンは 5.4.1 です。JUDEの公式サイトで登録後ダウンロード (無料) してください。jude_community-5_4_1.zip というファイルが落ちてくると思うので、それをダブルクリックして展開しておきます。
JUDE Community Site - 開発者ブログ - Mac OS X用 JUDE Pro/Com 5.5の非公式リリース
Mac用のJUDE Professional/Community 5.5をリリースしました。 （追記：Mac用のJUDE/Community 5.5で重大な問題が発見された為、公開を停止させていただきました。ご了承下さい。） JUDE/Professional 5.5 for Mac OS X http://jude.change-vision.com/public/mac/jude-professional-5_5-MacOs.zip 詳細はWindows版に準じます。 JUDE/Professional update情報 http://jude.change-vision.com/jude-web/download/update_pro.html#professional JUDE/Community update情報 http://jude.change-vision.com/jud
UML 2 コンポーネント図
UML 2 コンポーネント図の概要 by Scott W. Ambler, Copyright 2003 コンポーネントベース開発(component-based development: CBD)とオブジェクト指向開発は一緒に使われるものであり、コンポーネントを構築するための基礎技術としてはオブジェクト技術が好んで使われることがよく知られています。私は通常、UMLコンポーネント図をアーキテクチャレベルの成果物として使います。これはビジネスソフトウェアアーキテクチャや技術ソフトウェアアーキテクチャのモデリングに使いますが、たいていはその両方です。物理アーキテクチャ、特にハードウェアの問題に関しては、UML配置図またはネットワーク図を使うとよいでしょう。実際私の場合は、これらの図を行き来して作業を進めます。 規模の大きなチームではコンポーネント図が特に有効です。サイクル0で行う最初のアーキテ
UML 2 配置図の概要
by Scott W. Ambler, Copyright 2003 UMLの配置図 (deployment diagram) では、処理ノードやそのノード上で動くコンポーネントが実行時にどう構成されるかを静的に表します。違う言い方をすると、配置図には、システムのハードウェアと、そのハードウェアにインストールされたソフトウェア、種類の異なるマシン同士を接続するためのミドルウェアを表します。アプリケーションが複数のマシンに配置される場合には、配置図を作成するとよいでしょう。たとえば、POS(point-of-sales)アプリケーションがシンクライアントのネットワークコンピュータ上で動き、会社のファイアウォールで保護された複数の内部サーバや、Microsoft .NETのようなWebサービスアーキテクチャを使って配置された顧客サービスシステムなどとやりとりをする場合が考えられます。また、配置
「関連」や「関係」の落とし穴（前編）
関連の多重度とオブジェクト図 第2回「クラス図の落とし穴」でも述べたように、クラスの意味はそれがどんな「関連」によってほかのクラスとつながっているかということに依存して決まります。クラス図においてそのくらい関連は重要なわけです。関連にまつわる落とし穴はいくつかありますが、基本は、悩んだらインスタンスレベルの「オブジェクト図」を描いて具体例で判断する、というのが鉄則です。こうすればほとんどの誤解から逃れられます。ちなみに、関連はクラスレベルのモデル要素、それに対応するインスタンスレベルは「リンク」と呼ばれるので覚えておくとよいでしょう。 ここでは、関連の多重度にまつわる落とし穴を整理しておきましょう。 多重度とは、その関連に参加する両側のクラスのインスタンス同士の数量的な制約のことです。従って、片側のクラスのインスタンスを1個固定したときに相手側のクラスの多重度はそのインスタンスが何個対応す
あなたはテキスト指向、それともダイヤグラム指向？
あなたはテキスト指向、それともダイヤグラム指向？：UML BASIC LECTURE（1）（1/2 ページ） ユースケースのわな：機能 vs. 価値の提供（サービス） 書籍や文献、セミナーなどが増えてきた関係で、ユースケースという技法が数年前と比較するとだいぶポピュラーになってきました。いろいろなところで話をするときも、以前は「ユースケースって何」といった入門的なところからの話題が多かったのですが、いまは「本当はどこまで書けばよいのか」「どうすれば効果的に使えるのか」といった実践的な部分に関心が移ってきているようです。実はそれはUML全体にもいえることなのですが、特にとっつきやすいユースケースにおいて、最も顕著であるといってよいでしょう。 とはいえ、ユースケースの考え方自体はそれほど新しい概念ではなく、もともとの発想は1967年といいますから、業界的には古い考え方といってもよいかもしれませ
「関連」や「関係」の落とし穴（前編）
そのほかの「関係」 では関連のほかは「どういう関係」なのでしょうか。汎化関係は、オブジェクト指向を特徴付ける概念なので、分かりやすいと思います。つまり、物事を分類するときに用いる関係で、ある概念に対してより一般的な概念がある場合、それらを汎化関係にある、とします。親子関係、スーパークラスとサブクラス、祖先と子孫などの用語が使われることもあります。 次に実現ですが、実は意味的には依存の一種になります。実現の意味は「仕様とその実装の関係」なので、仕様が変わればもちろん実装は影響を受ける、つまり依存していることになります。ですので、依存関係のステレオタイプで<>としても同様ですが、表記法としては独立したものを持っていますので、このようにしておきます。具体的には、例えば、インターフェイスとそれを実装するクラスをイメージすれば良いでしょう。ユースケースとユースケースの実現、などにも使われますが、意味
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
関係
http://www.rarestyle.net/main/uml/Activity/Activity.aspx
IDEA * IDEA