Skip to content

Tag: UML

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

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

基本編(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つを結びます。そして名前を入れてみましょう。 名前は例えば、「顧客」から見たときに、「注文を発行する」がよろしいでしょうか。ここに名前を入れます。 次に多重度も入れてみましょう。 […]