Skip to content

Tag: software modeling

【対談】技術レビューの現場におけるGSNの活用法 〜 デンソークリエイト 小林さん

モデリングしてますか? 前回に引き続き、デンソークリエイトの小林さんと今日は対談という事で、よろしくお願いします。   ありがとうございます。     GSN(Goal Structuring Notation)って、実際に描いてみると難しいじゃないですか。     そうですね。     今回は「GSNやD-caseをレビューに使う」という話でしたが、そもそも、GSNやD-Caseをレビューに使いたいと考えたきっかけは、何だったんですか?    もっと中に踏み込んだ議論をしたくてGSNを使い始めた うちの会社では、レビューの場では「手順」をしっかり抑えておこうと、チェックリストなど色々あるのですが、最近それに慣れてしまったメンバーもいて、プロダクトの中身について議論する機会が減ってきたんです。 そこで、GSNというフォーマットを使うと、「前提」という形で考え方などを見える化できるので、中に踏み込んだ議論ができるようになるんじゃないかな、と。 なるほど。 確かに、議論は個人個人違うじゃないですか。でも、前提というか、周り、議論を支える前提となる基準だったり、コンテキストや、エビデンスとか、実は議論と関係なく存在してますよね。会社でプロセスを決めてくっていうのは、議論構造を決めてくよりも、実は基準を決めてくことじゃないんですか? はい。その辺りに基づいて議論を作っていくと、相手が非常に納得できるという流れになるんじゃないかと思います。  GSNで、知見を「コンテキスト」として定義、蓄積、形式知化する やはり、過去にやった人が持っている知見って貴重で、毎回同じ失敗を繰り返したくない、と、皆そうですよね?あれって、GSNでうまく吸い出せないですかね?   そこは、GSNのコンテキストという形で定義して、それをどんどん蓄積していくという形ができると、非常にいい流れになるんじゃないかな、と。     なるほど。じゃあ、GSNは、議論の構造としては、勿論描く。それは毎回描いても構わないんだけど、そこでやってく中で出てきた知見を、うまくコンテキスト側に押し出していく。 それを、会社なり組織なり、あるいはもうちょっと言うと世界標準なり認証機関を持つ認証かもしれないですが、そっち側の形式知化していく、という活動が、GSNの持ってる力なんでしょうかね? […]

技術レビューの現場におけるGSNの活用法(2)〜相手と自分の共通理解をつくるには

「モデリングしてますか?」 DENSOクリエイトの小林さんを再度お招きして、GSNを使ってレビューをする際に問題となる「共通の合意の作り方」についてお話ししていただきたいと思います。では小林さん、よろしくお願いします。   前回「議論においては、前提を相手と合わせる事が大切だ」とお話させていただきましたが、今回は、そこについて簡単に紹介させていただきたいと思います。 まずはじめに、相手と自分の、議論の前提の認識が合っているかどうか、という状況を図示すると、おそらくこういう4ディションになるのではないかと思います。  自分と相手が共に知っている状態 1つ目については「自分と相手が共に知っている状態」。ここは、実際の開発現場で考えると、相手がずっと仕事をやってきて、自分も一緒に仕事をやってきた、というのが、このディションになるのではないかと思います。  相手は知らず、自分のみ知っている状態 – しっかり教える 「相手が知らなくて、自分が知っている」所というのは、自分たちの技術に、お客様が非常に関心を持ってくれている、「新しく仕事を始めよう」という状態、あるいは、お客さんの方の窓口が変わった、という場合は、こういう所になります。 ここでは、自分の知っていることを相手にしっかり説明しておかなければ、相手が、いつまで経っても「自分のこととして仕事に取り組んでくれない」とか「中を見てくれない」といったことになるのではないかと思います。  相手のみ知って、自分が知らない状態 – しっかり教えてもらい明文化する 「相手が知っていて、自分が知らない」という領域については、お客さんが長らくやってきた製品開発の中で、自分たちが参入する、という場合になると思うのですが、ここの前提もしっかり合わせておかないと、後になって「なぜこんな事も分からないのか?」というような話があがるかもしれません。 そういうリスクがあるので、ここの領域については、相手にしっかり教えてもらって、明文化するという事が必要になると思います。 前後しますが、ここ (相手が知らず、自分のみ知っている領域)は「教えてあげる」という事がいりますね。  自分も相手も知らない状態 – 一緒に前提を作り上げる 最後に「自分も知らずに、相手も知らない」という領域については、相手と自分が一緒になってまずは前提を作っていくという作業があって、それに基づいて仕事を始めるとうまくいくのではないかと思います。 ここは「一緒に作り上げる」ということが大切ではないかと思います。 議論自体は、こういう形になると思ってます。  議論の周囲にある「相手と合意しているもの」を明らかにしてから議論を形作る 議論の対象がこのスコープだとします。その時に、先ほどのモデル(相手と自分の状態)を念頭に置きながら、どういった前提文書があるか、相手と合意形成されている前提文書や証拠文書、こういったものをしっかりと洗い出すことが、まず大事だと思います。 その上で、議論の対象となるもの、「何を主張したいか」ということ、例えばこの主張が妥当であることを証明したいのであれば、前提文書等を用いて、この主張を分解していき、相手と合意形成をできる証拠文書に基づいて、ここを証明する、と、こんな形で先ほどの議論モデルを念頭においてまとめてくると、GSNでこういった形で伝わるのではないかと。 そこが合ってることによって、共通理解をもったGSNを書いて、相手に納得してもらえるのではないかと、そういうことを考えています。 はい、ありがとうございました。 […]

【対談】「これだけ」モデリング – 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つの注文になっています。 […]

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

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

基本編(1) クラス図

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