Skip to content

Category: UML

動詞de!! モデリング ④「考え方編」

動詞deモデリングは、どうして「誰もが簡単に」できるのか。このモデリング手法が機能する原理についてお話しします。

Advertisements

動詞de!! モデリング ③「C言語編」

「モデリング」してますか? 今日は、「動詞de!! モデリング」、③C言語による実装編、という事で、実際にプログラミングに落としていく過程を、セイコーエプソンの萩原さんにお話いただきます。(①導入編、②実践編) では、萩原さん。よろしくお願いします。    モデリング習得3つの壁とその対応策   「オブジェクト指向の設計の敷居が高い」という点と「UMLの習得が難しい」という点、この部分について説明したいと思います。    オブジェクト指向にこだわらなければよい まず「オブジェクト指向の敷居が高い」というのはですね、対策としては「オブジェクト指向を使わない」と決める。「データ抽象」という、オブジェクト指向以前のものを使ってですね、それをやりきる、という形になります。 「データ抽象」が何かというと、データと関係する関数を同じ場所に置く、というものが「データ抽象」になります。 C言語でいうとですね、.cの所に関係するデータ、つまり変数と、その変数を使う関数を集める、ということですね。 別の言い方にすると、「モジュラーアプローチ」というようなものになってきます。これをクラスにする、という形になります。   .hと.cのペアですね。これをクラスと対応付けることができます。クラスの中で公開する関数はプラス、パブリック属性になりますが、これをヘッダーファイルに置きます。非公開にする関数は、Cですとstatic宣言した関数になりますね。変数は、基本的に非公開にしますので、static宣言します。 Cの場合、.cからヘッダーファイルにincludeします。この時、クラス図の関連線が対応することになります。このようにすると、C言語の技術者でもクラス図を描くことができます。まぁ、多分ですね、普段作っているCの構造、Cのソースコードと同じ構造のクラスがすぐ作れると思います。    使うUML図は3種類でよい。クラス図、コミュニケーション図、ステートマシン図 「UMLの習得が難しい」というものがありますが、これについてですね、使用するダイアグラムの種類を3つに絞りました。 1つはクラス図、もう1つはコミュニケーション図、最後は、ステートマシン図です。 クラス図というのは、先ほど言いましたように、要はファイル間の相関図です。「このファイルが、このファイルと関係する」つまりincludeしている、という状態を表します。そして、そのファイルに対して、こういう関数と変数があります、ということを図示するような形が「クラス図」になります。 もう一つ、コミュニケーション図、これは言ってしまえば、「関数呼び出し図」ですね。ファイルに関数がありますが、この関数を、このファイルから呼び出して、次にこの関数を呼び出す、という事がコミュニケーション図上に表現されています。 最後、ステートマシン図、状態遷移図ですね。 Cを使う、特に組込みのエンジニアの場合は、クラス図やコミュニケーション図を描けなくてもステートマシン図で描ける事があります。ま、描けない場合は努力してください、という話になってしまいますけども…。 これがステートマシン図です。この3つの図を使うことによって「UMLの図が多い」という事に対して、対応していく事ができます。C言語の設計者に対して大体30秒くらいで説明すればですね、大体ここら辺の図は使えるようになります。 萩原さん、ありがとうございました。組込みの現場では、いまだに、やはりC言語というのは重要な言語だし、よく使われてると思いますね。その中で、オブジェクト指向にこだわらずに、その「データ抽象」という重要な考え方を使って、今のC言語の技術者が良い設計をする為に使う、   そうですね、はい。   […]

koredake modeling UML

【対談】「これだけ」モデリング – Part 2/2

「これだけ」モデリングの生みの親、株式会社メソドロジックの山岸さんと、チェンジビジョン平鍋による対談、後半です。モデリングの威力や、出来上がった「モデル」ではなく「モデリング」というプロセス活動をチーム内で共有することが重要であること、など熱く語っています。(対談の前半は、こちら)

【対談】「これだけ」モデリング – Part 1/2

「これだけモデリング」は、なぜうまれたか - 対談その1。 UMLの仕様を全部使ってモデリングするなんて、無理。モデリングという「活動」を通して参加者に「残像」を残すことが重要。

「これだけ」モデリング – Part 2/2

「モデリングしてますか?」 今回は、前回の続き「これだけモデリング」ですが、アジャイル開発の中で、もっとモデリングを使おうという話をしていただきます。「これだけモデリングは、アジャイルを加速する」という事で、山岸さん、よろしくお願いします。   皆さん、こんにちは。メソドロジックの山岸です。 今日は、「これだけモデリングは、アジャイルを更に加速する」というテーマで、お話をさせていただきます。  アジャイルとモデリング 最近、アジャイルが非常に盛んになっておりますが、そうした中で「アジャイルは、ドキュメント削減するんでしょ、だからモデリングやりません」という混乱が散見されており、そこが随分違うなと、私は思っています。 アジャイルといっても、最近のアジャイルの話題は、エンタープライズにどう適用するか、です。アジャイルというと、スプリントのサイクルのところに話がフォーカスされる、つまりプロダクトバックログを作ってから以降の話、という事です。 ただ、エンタープライズというのは、色んなシステムが複雑系を成しているというか絡み合ったもので、且つデータの移行などの複雑なもので、対象も複雑な業務なわけです。  スプリント以前のモデリング ですから、一定のリズムでアウトプットを出していくというようなスプリントのサイクルに入るまでの所、つまり、バックログを積むまで、にやっておかなければいけないことが、沢山あるんです。 実際に、1番重要なのは「業務を正確に把握する」というところですね。そこで、モデリングは非常に有効に働くと私は思います。 スプリントに入ると、非常に高速になるわけですが、そこに至るプロセスをできるだけ素早くやっていくという部分は同じだと思うのですが、業務を更に素早く把握しようとするとモデリングの力を借りざるを得ない訳ですね。 モデリングによって、先ずちゃんと地図を描いておくこと、それからエンタープライズの場合、システムを長期に渡ってメンテナンスしていくという意味では、やはりアーキテクチャを、きちんと設計した上でスプリントのリズムに入っていかなければいけない。 という事で、この辺りは、モデリング無しで素手でやれるような領域ではないと考えています。 更に業務を正確に手早く把握するためには、モデリングの力を十分に活かさないと、まず難しいでしょう。  スプリント中のモデリング 実際のスプリントに入ると、設計者と実装者は変わりませんから、同じメンバー間のコミュニケーションを高める、という意味では、わざわざUMLで設計書を描いて、それをベースにコーディングする、というような情緒なサイクルではなく、「素早くやる」という事であれば、全体の構造をちゃんと理解した上で、それを時々見る、ということで、最初の段階でモデル化したものを参照しながらという事になります。 また「コミュニケーションを活性化する」という事は、アジャイルの中で非常に重要なわけですが、言葉より伝わる、というモデリングは、スケッチとしてあるわけですよね。いくら言葉で言うよりも、お互いが共通理解しているノーテーションで描いた方が、よっぽど早く伝わる。その方がよっぽどアジャイルだ、という話が、1つあります。 そういうところで、モデリングを使うと、更にスピードが加速する事ができます。  リリース後、運用準備のモデリング それから、リリース後、エンタープライズというものは、ずっと使い続けて進化し続けますから、次の開発者に委ねていかなければいけないくらい寿命が長いものですね。ですから、その所では、設計の重要な情報というのをモデルのようなものを使って、保守していかなければならない。 「エンタープライズアジャイル」という領域でも、アジャイルをより加速するというポイントで、モデリングを設計する必要があると考えています。  要求獲得のためのダイアグラム それで、実際に何を使うのかというと、業務の要求獲得というか要求開発のためのモデリングというのは、簡単に言うと、この3つですね。 つまり、そもそもその業務で何をするのか、それが、どういうもので構成されて、それがどう動くのかを、表現するという事が、ここで必要となるいう事ですね。 そして、実際には、何をするのかっていうと、ユースケース図で表現しますし、誰がどうやって、という部分は業務フローで表現します。何で構成されているかは、概念クラス図で描くという事が基本になります。その場合も、ここに挙げましたような限られたノーテーションを出来るだけシンプルに使って表現する事が非常に重要です。  関わる人に「残像」として残るモデリング、これがベスト という事で、ここで重要なところは、あくまでも「業務理解のためのモデリング」という事で、抽象度を上げすぎて、”そもそも”みたいな話をしても、業務の特徴を表すことはできませんので、やはり、一定の業務イメージとか具体イメージを表現できるレベルにしておかなければいけないという事です。 それから、概念モデルを、そのまま設計モデルや、トレーサビリティを維持したままデータモデルやクラスの実装言語の設計モデルに持っていこうという考え方は、あまり考えない方がいいと思っています。 […]

「これだけ」モデリング – Part 1/2

モデリングしてますか? 今日は、メソドロジックさんにお伺いして、山岸さんが提唱されている新しいコンセプトである、「これだけモデリング」について、お話をしていただきたいと思います。 それでは山岸さん、どうぞよろしくお願いいたします。 こんにちは、メソドロジックの山岸です。今日は「これだけモデリング」という話を、短い時間ですが簡単にご説明させていただきます。    モデリングの威力はすごい。しかし,これだけ役立つのに、なぜ使われていないのか? 私は、20年前にブーチ法というものに出会って、モデリングを知ったのですが、それから今まで自分が関わったプロジェクトでは、大体モデリングをやってきたという経験があります。今となっては、モデリングせずにプロジェクトをやるのは、素手で戦っているというような感じで、非常に違和感があり、凄く野蛮な気がします。 UMLが出てきて既に15年以上経っていますが、これだけ役に立つものなのに、なぜか意外に使われていない、という事に驚きを感じています。 というのは、モデリングが、どれくらい役に立つものか、という事が、あまり分かってないんじゃないのかというのも1つですし、あとは、導入のハードルが高いと思ってる人が多い。あるいは、使い方が間違ってるんじゃないかと思われる時もあります。 要は、かけてるコストに対して、ちゃんとしたリターンを得てないのではないかと思います。コストパフォーマンスを十分取れてないから使わない。今まで(モデリング)無しでも、物が作れているかどうかは、ともかくとして、無しで作っちゃってる、という技術があります。あえてここでモデリングを勉強して、更に、今までやってない作業を加えてプロジェクトを回す事に対して、皆さんは、あまりメリットを感じないかもしれませんね。加えて、最近のアジャイルブームで「ドキュメントを書かない」という流れの中でモデリングもやらないみたいな混乱、もあると思います。 私が思うに、「場に合わせて、適切なレベルでモデリングをする」というのは、非常に効果が高いと思います。 それを、皆さんは、今日この場でお勧めしたいと思います。  モデリングが根付かない理由 悪い例からお話しますと、そもそも皆、生真面目にやりすぎている。UMLは13種類のダイアグラムがあるんですけど、それに対して、それぞれの図の表記に困ってしまっていて、「それを逐一勉強した上で、プロジェクトに取り掛かろう」とか、どのレベルの詳細度まで描くか、をあまり考えないで“やたら”描いてるという事が、多々見られるわけですね。 やはり「小難しくし過ぎてる」というのは、一つあると思います。 非常に細かいレベルまで表記方法にこだわって描いていくことや、抽象度をすごく上げて、”そもそも”というレベルのモデルを描いても、描いたモデルは、返って伝わらなくなりますね。 私は、よく英語に例えるのですが、”一番通じるレベル”があって、例えば国際語としての英語というのは、必ずしもネイティブのような英語を喋ってても、他の国の人には伝わらないわけですね。なので、“このレベルで使うと、1番よく伝わる“というレベルがあるんですよね。そして、モデリングしてきた人は、誰が取り決めたわけではないけれど、一様に”このレベル”という感覚が、共有できてると思っています。 ですから、そのレベルのものを習得して、逆にそれ以上のものは使わない、というような、そういう“ほどいい使い方”を、皆さんにお勧めしたいと思っています。 そもそも、そういう風に生真面目にやったり、難しくしすぎちゃうのは、何のためのモデリングをしているのか、という所を見失っているケースが多いですね。  モデリングの目的を明確にして、自分たちの「ほどよい」レベルを見つけよう モデリングの目的は、大きく幾つかあると思っています。 1つはやはり、「物を理解するため」にモデリングするという事ですね。 理解についても「全部を理解する」と「複雑な詳細を理解する」という、理解のためのモデリング。それから「伝達するため」、「記録するため」そういった目的もあります。 他の言い方をすると、スケッチとしてのモデル、設計書としてのモデル、プログラム言語としてのモデルなど、色々なレベルの使い方もあります。 それから、扱い方にしても、描き捨てるのか、中間生成物として使っていくのか、最終成果物として残すのか、あるいは保守資料としてメンテナンスまでするのか、そういったものが分類としてありますね。 ですので、今、モデリングをしようとする時に、どういう目的で、何のために、どの程度描いて、この先どう扱うのかというところを決めると、おのずと”ほどよいレベル”というのが定まってきます。  UML13種図のうち、4図だけ使えばいい 図としては大体このくらい知っていればいいでしょう。13種類あるうちの4つを知ってればいい。 ただし、図を使うシーンがあります。他えばクラス図だと、概念クラス、設計クラス、データ設計図など。クラス図だけれど、使うシーンによって使い方が違います。こういう所を意識して、黄色く塗ったあたりを、特に皆さんには必ず習得して欲しいですし、ここに挙げたところが標準的に使っていただければいいんじゃないかと思っています。 あとは、各ダイアグラムにしても、細かく色んなノーテーションがあるので、ダイアグラムごとに「この程度のノーテーションを使いましょう」というお勧めなレベルもあります。 […]

パターン編(3) 分析・設計パターンの重要さと書籍紹介

当「モデリングしてますか」チャンネルの”パターン編”の意味、なぜパターンを知っておくことがよい­モデリングにつながるのかについて解説します。世の中には、ソフトウェア開発活動に役­立ついろんなカテゴリのパターンが存在します。分析パターン、設計パターン、実装パタ­ーン、アーキテクチャパターン、などなど。お薦めの書籍とともに紹介します。 [スクリプト] モデリングしてますか? 今日は、パターン編という事で、ソフトウェアのパターンの重要性について、最初にお話ししたいと思います。 パターンとは? パターンとは、歴史を話すと凄く長くなるので、今日は話しませんが、ソフトウェアの色々な開発活動の中で、よく行われている例(パターン)が、いくつもあって1つのパターンを形成します。こういう風にやるとうまくいくんだ、というものに名前をつけて、集めてくる手法です。 例えば、実装のコードレベルのパターンもあれば、設計レベルや、分析レベル、ビジネスレベルのパターンもあり、非常に広範囲に使われる言葉です。 パターンとは、「名前」と、「名前が使われる文脈」と、「解こうとしてる問題」があって、「解決」があります。 だから、「文脈」、「問題」、「解決」をセットにして名前を付けたもの、という言われ方をしますが、基本的にはコードのように、固い再利用ではなく、考え方や知識を再利用するフォーマットになります。 デザイン/設計/ビジネスで使用されるパターン 1番良く知られているのが、この「オブジェクト指向における再利用のためのデザインパターン」という、95年に書かれた本です。ソフトウェアの中で、パターンが非常に花開くきっかけとなった本です。この本が書かれる前に、James o. Coplienが「Advanced C++ Programming Styles and Idioms」という本の中で「イディオム」として、実装のパターンを解説しております。 それから、Kent Beckの「Smalltalk Best Practice Patterns」ですが、これも実装レベルのパターンとして、非常に有名です。後にKent Beckは、Java版に書き直して、「Implementation Patterns」という本に変えています。これは実装のパターンです。 それから、分析に入ると、1番有名な本としては、「アナリシスパターン―再利用可能なオブジェクトモデル」で、Martin Fowlerが書いた本です。この本は、分析レベルで現れるパターンについて、書かれており非常に分厚い本です。 おそらく、これが書かれるおおもとになったのは、インフォメーションエンジニアリングという言葉を作った、James Martinの「オブジェクト指向方法序説〈基盤編〉」です。James J. […]

パターン編(2) 顧客、注文、商品をつなぐ「モノ – コト – モノ」パターン

チェンジビジョン平鍋が「リソース系の顧客および商品、とイベント系の注文をつなぐパ­ターン」を易しく紹介します。 前回の「パターン編(1) 注文書を表現するヘッダー明細パターン 」の続きです。 モデリングしてますか? 前回は、ヘッダー明細パターンという事で、「注文」と、「注文明細」、もう少し詳しくいうと、このような「注文書」の中で、この「注文明細」と、全体の「注文」の関係について解説をしました。今回は、前回登場しなかった「商品」という概念について、今回は詳しくお話ししたいと思います。 「商品」という概念とは? ここには「注文明細」とありますが、注文の1行は、1つの商品と紐付いています。 そのため、「商品」という概念を登場させます。 このように注文明細の中にある「タオル」という注文に対して、「単価」「数量」「金額」がありますが、この「商品」をモデリングすると、このようになります。「商品名」と「定価」という風に、データ構造しておきます。 ここで、「単価」と「定価」は重なるのですが、場合によっては「定価」から値引きをする場合があるので、このような形にしておきます。「注文明細」から見ると、「商品」は1つと決まっていて「商品」から見ると、「注文」は複数対応する事があるというパターンになります。 「モノ – コト – モノ」パターン ここからが面白いんですが、両脇にある「顧客」と「商品」は割と長く存在しているものです。 「注文」とは、一時のものです。 このような「顧客」や「商品」の事を、「リソース」という言葉で表す事があります。 それから、「注文」は、寿命が長い2つのオブジェクト(リソース)の間にあって、一時のトランザクションを示すものを、「イベント」と呼ぶ事があります。このように2つのリソースを、結びつけて1つのイベントが起こるというパターンは、非常によく起こる事ですね。 ここをヘッダー明細パターンといいましたが、色々よび方がありますが、この事を、児玉さんは、「モノ – コト – モノ」パターンという非常に良い名前をつけています。 また、企業の情報システム構築のデータ構造では、このパターンは非常によく出てきます。 リソース2つがあって、真ん中にイベントがある。特徴は、イベントには必ず「日付」があるという事ですね。 それから、前回お話しできなかったのですが、この「注文明細」の合計が「注文」になります。そのため、「注文金額」というのは、実際には「注文明細」から掛け算して、足し合わせたものになるので、自動的に決まりますね。これを、「派生属性」と呼んで、斜線で表します。 応用がきくパターン まとめると、よく見る「注文書」とは、1つの注文の明細になっています。「件名」と「金額」が、1つの注文になっています。 […]

パターン編(1) 注文書を表現するヘッダー明細パターン

業務上非常によく出てくるパターンとして「ヘッダー明細」を取り上げます。基本編(1) まずはクラス図の「顧客ー注文」の先にあるものです。 [スクリプト] モデリングしてますか? このビデオシリーズ、パターン編の第1回目は、ヘッダー明細パターンというのを、やってみたいと思います。 このパターンは非常に、よく使われるので、色々な場面で出てきます。 「注文」のパターンを考える 今回は、前回基礎編でご説明した「クラス図」で出てきた、「顧客」やそれに対する「注文」がありましたね。 その「注文」を、詳しくみていきたいと思います。 前回の通り、「顧客」には「名前」と「メールアドレス」があって「注文」には、「日付」があり「金額」がありますね。 このような描き方になっていますが、一般的に、「注文」というのは複数の商品からなっていますよね。 「注文書」を思い浮かべてください。 よくビジネスで使われているので、皆さん、当然見た事があると思いますが、注文書には、お客さまの名前、件名があり、金額があります。メールアドレスや電話番号もあると思います。そして上部には、注文の日付がありますね。それから注文の番号があります。 次に、自分の会社の名前があって、下部には合計金額の内訳があります。内訳として、品名、単価、数量、金額があります。 つまり、この例でいくと、「ロゴマークデザイン」というデザイン料として単価が1万円、数量が1ケ、金額が1万円となり、「タオル」の単価が1000円が10ケで2万円となっています。それで、金額の欄を足したものが、合計の金額となっているわけです。 注文書をモデリングしてみる 非常によく出てくるフォーマットと思いますので、これをモデリングしてみたいと思います。 この「注文」の中に「金額」がありますが、「金額」の下をみていくと、1行1行クラスとして表現しています。 その1行の事を、「注文行」という事もありますし、「注文明細」と呼ぶ事もありますね。そこには、「単価」があって、「数量」があります。「注文」は、「注文明細」を保持していますよね。 もし「注文」がなくなれば、「注文明細」の意味が無くなるわけですから、正確に描くと、「注文」の多重度は1になります。 「注文」には、複数の「注文明細」があり、そして「注文明細」に「単価」と「数量」があり、これを掛け算したものが、1つの行の 商品に対する金額になります。 これを足し合わせたものが、注文全体の金額になるというパターンになっています。この強い保持している関係を、UMLでは「コンポジット」という黒い四角で表します。 このように全体があって、部分が行に分かれていて、それぞれの行の合計が、全体になっている、というのをヘッダー明細パターンと 呼んで、注文も、注文明細も、例えば見積もりや、売上に対して、このようなパターンが成り立ちます。 もう1度、先ほどの注文書で復習すると、1行1行書かれているものが、注文明細になるんですね。 「商品」という概念があって、「商品」との関係を描くことによってもう少し注文書全体を、細かくみていきたいと思います。 まとめ このようなUMLを使ったパターンは、多く本が出ていますので、また次回紹介したいと思います。 例えば、細川さんが書かれた、「UMLによる一気通貫DBシステム設計 […]

基本編(3) システムの利用者と利用場面を表現するユースケース図

UMLユースケース図を、モデリングツール astah*でサンプル図を描きながら解説。”ユースケースは「機能」ではない!がポ­イント” [スクリプト] モデリングしてますか? 今日は、ユースケース図について、簡単にお話ししたいと思います。 ユースケース図というのは、システムと利用者の間の、インタラクションを表現したものです。 ユースケースという言葉は難しく、システムの機能分を描くという風に、表現する方もいらっしゃいますが、それは大きな誤解です。システムと利用者が、そのシステムを使う「場面」を描いていきます。ユースのケースを描いていくというものが、ユースケース図です。 DVD/ビデオのレンタル店を例に挙げた場合 例えば、DVDやビデオのレンタル店のシステムを、考えてみましょう。 そこには、これは「アクター」と呼ばれる、「会員」や、「店員」がいます。その場合、例えば、「DVDを検索する」というユースケースと、もう1つは、「店員が会員を登録する」というのが、もう1つのユースケースです。 ポイントは、機能を表現しているように見えますが、これを機能としてブレイクダウンしていくのではなく、ユーザーがある目的を持って、それを達成するまでを、ひとまとまりとして描いていきます。 どちらかというと、「店員」がこの機能を使うと読むのではなくて、「店員」がこのユースケースに入っていって、この場面に参加する、という風にとらえるのが正しい捉え方です。 astahでユースケース図を描く では、実際のastahで、どのように描いていくか見てみましょう。 astahでユースケース図を作成するには、「図」メニューから、「ユースケース」を選びます。 メニューバーを見ると、いくつかのアイコンが見えます。 「アクター」それから「ユースケース」、これらのアイコンをクリックして作成していきましょう。 まずアクターを選んで、「会員」というアクターを作成しました。そして、「DVDを検索する」というユースケースを作ります。 次にもう1度、「アクター」を作ります。今度は、「管理者」といったもう1つ別のアクターを作ります。 今度は、図面上でダブルクリックをする事によってユースケースを作る事も出来ます。「会員を登録する」にしましょう。 次に、アクターとユースケースを、結んでみましょう。 アクター上でホバーし、アクターとユースケースを結ぶ事ができます。 また、関連のメニューを、選択し、そこから描く事もできます。最後に、システムバンダリを描いて完成です。 ここには、ユースケースがありますが、ユースケースのシナリオを描くには、ユースケース上で右クリックして、そこから「ユースケース記述を開く」というメニューを選択します。するとここに、ユースケースの概要、それから事前条件、事後条件、基本系列を入力する事もできます。 今回は、ユースケース図について簡単にご説明をしました。他にも、ユースケース自体をインクルードという関係を使って別のユースケースを描いたり、エクステンドという関係を使って、例外的なユースケースを描いたりしますが、基本的には、アクターとそれが参加するシステムとの利用場面を記述しているものです。 そして、四角の枠で囲って、機能の範囲を明確にします。 ユースケースと連動するアクター アクターにはもう1つ種類があって、支払システムとシステムが連動して動いている、つまり、今回の対象とするシステムの外に、別のシステムがあって、それと連動して動いているというような、ユースケース図も描く事ができます。 例えば、「貸出」というユースケースを描いていますが、「貸出」は「支払システム」(レジ)と連動していると思います。 もう1つ、「貸出」は、「会員」ではないですね。「店員」が、自分の名札とレジに連動し、「店員」のユースケースとして「貸出」になります。 […]

基本編(2) 動きを表現するシーケンス図

UMLシーケンス図を、モデリングツール astah*でサンプル図を描きながら解説します。 [スクリプト] モデリングしてますか? 今日は、シーケンス図をやってみたいと思います。 シーケンス図は、複数のオブジェクトが協力して、1つのゴールを達成する、そのような振る舞いを表現した図です。例として、このような携帯のアプリを考えてみます。 携帯に、こんな情報(右図)を入力して登録ボタンを押すと、それがサーバーに送信されて、ユーザー登録が行われる。そんな一連のアクションを、シーケンス図で表現してみたいと思います。 シーケンス図には、2通り描き方があって、1つは、ラフに登場するオブジェクトを描いていく方法と、もう1つは、クラス図を前提として、そのクラスの参加する振る舞いを描いていく。この2種類があります。 今日はその両方のやり方で、やってみたいと思います。 実際に、描くシーケンス図は、このようになります(右図)。 ユーザーが3つの情報を入力して、登録ボタンを押すと、アプリがサーバーに登録を行う、このようなモデルです。 では、実際のastahで見てもらいましょう。どうぞ。 ラフな”シーケンス図を描いてみる ここでは、ラフなイメージのシーケンス図を描きます。 まず、ライフラインを1つ選んで描いていきます。ここに、ライフラインの種類を選ぶ事ができます。 1つ選んで、ここでは利用者という名前にしましょう。 もう1つ、アプリを代表するライフラインを作ります。「アプリ」と入れます。 次に、利用者が、そのアプリに対して何を操作するかをメッセージを使って描いていきます。 ここでメッセージを選ぶ事も出来ますが、astahではこのバーを引っ張る事によって、描き入れる事ができます。 ここでは、名前を入力するので「名前」と入れます。 次にもう1つ描いてみましょう。 名前の他にも、利用者が入力するものとして「呼び名」というものを入れてみましょう。 「呼び名」と「名前」をアプリに設定します。 それから、例えば「アバター」というのも、ここに入れてみましょう。利用者が、アプリに対して「名前」と「呼び名」と「アバター」を設定した後、この3つの情報を入れて「了解」というボタンを押すとします。 もう1つのライフラインを追加します。 そうすると次に、この情報で、「アプリ」が「サーバー」に向かって、情報を「ユーザー設定」という風に、「サーバー」に対して呼び出します。ここではリターンのシーケンスも入れたいので、リターンメッセージを追加して、これで一通りできました。 利用者が、アプリに対して、入力したものがサーバーに送られた、そんな図が、1つ描けました。 先にクラス図を描いてから、シーケンス図を作成する 次に、最初からクラス図がある場合、これらのクラスが参加するシーケンス図を描いていきたいと思います。 ここに「利用者」、それから「アプリの画面」、「サーバー」、3つのクラスを用意しています。この3つからシーケンス図を描いていきましょう。 […]

基本編(1) クラス図

UMLクラス図の基本を、モデリングツール astah*を使って解説。 [スクリプト] モデリングしてますか? この短いビデオシリーズでは、astah*を使って基本的なUMLの図の描き方について、実践的なレクチャーをしていきたいと思います。このコンテンツは、どんどん増えていきますので、随時チェックしてください。  概念レベルのクラス図 クラス図には、実装レベルのクラス図と、それから概念レベルのクラス図があります。概念レベルのクラス図は、ユーザーが使う言葉を分析して、それをダイアグラムにしたものです。 ここでは、概念レベルについて説明していきたいと思います。例えばここに、「顧客」と「注文」という2つの言葉があります。例えば「顧客」ですと、「名前」という属性や、「email」という属性を持っているでしょう。 それから「注文」ですと、「日時」や「金額」といった属性を持っていることになると思います。  モデリングツールでクラス図を描いてみる では、実際にクラス図を描いていきましょう。 ここにクラス図のアイコンがあります。ここをクリックして、 クラスを描きますが、astahではダブルクリックでもクラスを描く事ができます。 「顧客」と入力しましょう。 次に、属性ですが、ここにオレンジ色のボタンがあるのが見えますでしょうか。これをクリックして、属性を追加する事が出来ます。 「名前」と入力しましょう。 それからもう1つ、もう1回、このオレンジをクリックして「email」と入力します。 さて、同じように「注文」クラスを作っていきます。 ダブルクリックをして「注文」と入力。今度は、ショートカットの[Ctrl + R]で入力しましょう。 そして、注文の日時を入力し、ここで改行を入力すると自動的にもう1つ属性が追加できます。 「金額」と入力します。 このクラスの関係を、次に作っていきます。 関係を作るには、ここに関連のアイコンがありますが、astahで同じように、簡単に関連を作る事ができます。 クラスをホバーすると、ここに関連のアイコンが出てきますね。これを引っ張って描く事もできます。 あるいは、ここに色んな関連の種類を選ぶ事も出来ます。 今回は普通の関連を選んで、2つを結びます。そして名前を入れてみましょう。 名前は例えば、「顧客」から見たときに、「注文を発行する」がよろしいでしょうか。ここに名前を入れます。 次に多重度も入れてみましょう。 […]