|
|
|||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||
| このページの最終更新日: 2012/06/21
提案日: 2010/07/27 |
|||||||||||||||||||||||||||||||
|
クラスコラボ図を使った開発の流れ
概要 概要文章 別ページ「クラスコラボ図」の記事で、クラスコラボ図という新しい図の描き方を提案しました。もし、このクラスコラボ図を使ってソフトの開発を行うのであれば、次の5段階の流れで開発を進めれば効率よく開発できる、といったアイディアです : 1. WannaDoリストを作る、2. シナリオステート図を描く、3. クラスコラボ図を描く、4. コーディング(実装)する、5. テストコードを作り、テストする。 背景 開発しやすかったクラスコラボ図の使い方 背景文章 別ページ「クラスコラボ図」の記事で、クラスコラボ図という新しい図の描き方を提案しました。クラスコラボ図とは、簡単に言えば、四角の中にクラス名を書いてクラスを描き、その間に矢印を描いて、あるクラスから別のクラスの関数を呼び出す動作を矢印で表したものです。これによって、複数のクラスがお互いに協調し合う様子を見える化します。 このクラスコラボ図を使って、実際にいくつか小規模のソフトを開発してみました。その中で、クラスコラボ図をどのタイミングでどのように作るとよいかを試行錯誤しました。その結果、開発しやすくなるようなクラスコラボ図の使い方が分かりました。 そこで、クラスコラボ図を使ってどのようにソフト開発を進めていくのかについて記載します。 どんなもの? 5段階の流れで開発を進める 方法文章 別ページ「クラスコラボ図」の記事で、クラスコラボ図という新しい図の描き方を提案しました。もし、このクラスコラボ図を使ってソフトの開発を行うのであれば、次の5段階の流れで開発を進めれば効率よく開発できる、といったアイディアです。
この5段階の流れを見ると、クラスコラボ図を描く前に、WannaDoリストとシナリオステート図を作る2つの段階があります。この方法のポイントは、クラスコラボ図を描く前に、これら2つのリストと図を作ることで、クラスコラボ図が描きやすくなる、といった点にあります。WannaDoリストとシナリオステート図は、以降で例を使って詳しく説明します。 これ以降では、「入力しやすいGUI」を作る例を具体的に考えて、この5段階の流れに沿って実際にリストや図を作ってみます。「入力しやすいGUI」とは何なのかについては、以降で実際に作るWannaDoリストとシナリオステート図を順に見ればよく分かると思います。それでは、開発の流れがどのようになるのか、具体的に見ていきます。 1. WannaDoリストを作る はじめにWannaDoリストを作ります。WannaDoリストは、そのソフトにどんな機能がほしいのか、そのソフトで何がしたいのかをリストに挙げたものです。What I Want to Doを示すリストです。「入力しやすいGUI」を作る例に対してWannaDoリストを書くと、例えば次のようになります。
上のWannaDoリストから、入力しやすいGUIを作るために、ここでは「背景を赤に変える」、「ヒントマーク & ヒントを表示する」の2つの機能を実装したいことが分かります。このように、WannaDoリストを作ることで、「入力しやすいGUI」ではどんな機能がほしいのかを具体的に示すことが出来ます。 WannaDoリストと似たものとしてToDoリストがありますが、WannaDoリストはToDoリストとは違います。ToDoリストには、これから実装すべき項目の中で、どう実現するかが分かるようになったものを書きます。ToDoリストには、項目を読めば実装の作業が分かるような、作業可能な項目だけを書きます。なので、ToDoリストを書くには、実現方法が分かるレベルまで、内容を噛み砕いて検討する必要があります。 一方、WannaDoリストは、どうやって実現するかは分からなくてよく、これから実装したい項目を単に書き留めたものです。それを実現する方法は、これ以降で考えていくので、WannaDoリストには、このソフトでいったい何がしたいのか、だけに注力して項目を書きます。WannaDoリストを書いて、内容を噛み砕いて検討し、実現方法が分かったら、ToDoリストを書く、といった順番になります。 WannaDoリストに書く内容は、ソフトウェア開発手法の中で、よく「要件定義」と言われます。要件定義とは、客先が実装してほしいと考えている機能をはっきり書き上げることです。WannaDoリストも、要件定義と本質的に同じことをしています。WannaDoリストは、ほしい機能を忘れないために、より気軽にメモした要件定義と捉えることも出来ます。 次に、シナリオステート図を描きます。この図は、WannaDoリストで書いたほしい機能を、より具体的に説明します。図を描くために、1つの例に限定して、実際にほしい機能を利用する状況を考えます。そして、その例の中で起こる、見た目の変化や、中身のデータの変化など、何らかの変化するものに着目して、その変化の前後を状態遷移図(状態ステートマシン)を使って表すことで、ほしい機能を図にしたものです。「入力しやすいGUI」を作る例に対してシナリオステート図を描くと、例えば次のようになります。
上のシナリオステート図では、ほしい機能を利用する例として、GUIに「入力1」と「OK」ボタンの2つのUI要素がある場合を考えています。このGUIを実際に利用すると、GUIの見た目がどのように変化していくのかを表しています。 上のシナリオステート図の見方を説明します。図の最も左上の[A]の状態から始まります。[A]は、まだ何も入力していない空の状態です。[A]で、「入力1」のテキストボックスに正しく入力した場合は、下の[D]へとGUIが変化します。[D]で、「OK」ボタンをクリックして、動作が終了します。 もし、[A]のときに「入力1」に誤って入力した場合は、右の[B]へと変化します。[B]では、テキストボックスの背景を赤色にして、ミス入力を修正するように喚起しています。これと同時に、テキストボックスの右上に[?]のヒントマークを表示します。ここで、ユーザーがこの[?]をクリックすると、右の[C]へと変化します。[C]では、[?]の周りに新しく説明文が表示されて、正しい入力の方法を解説します。どこかをクリックすると、説明文が消えて、[B]に戻ります。そして、「入力1」を正しく入力すると、[D]へと変化します。 このように、シナリオステート図は、ほしい機能を利用するある一例を示します。一例のケースに限定することで、WannaDoリストに書いたほしい機能がどのようなものなのかを具体的に表します。この図では、テキストボックスの入力の例に限定しています。本当はもっといろいろなUI要素を使うことも可能ですが、テキストボックスとボタンの2つのUI要素しか使いません。分かりやすく示すために、単純な入力操作に限定しています。 シナリオステート図は、変化するものに着目して、その変化の前後を状態遷移図で表します。上の図では、GUIに操作を加えたときに起こる、見た目の変化に着目して、その状態が変化していく様子を状態遷移図で表しています。変化していく様子を具体的に描くことで、ほしい機能を分かりやすく表します。状態遷移図では、通常、1つの状態を示すのに、1つの四角を描きますが、シナリオステート図では、四角の代わりに、見た目のイラストを1つ描きます。
3. クラスコラボ図を描く これまで1.でWannaDoリストを作って、まずほしい機能を書き出し、それを基に2.でシナリオステート図を描いて、ほしい機能をより具体的に表しました。これらのリストと図を作ることで、ほしい機能とはいったいどんなものなのか、どのように動作するものなのかが具体的に見えるようになりました。そのため、この段階で、クラスコラボ図がとても作りやすくなっています。ここで、ようやくクラスコラボ図を作り始めます。 シナリオステート図には、ほしい機能の動作が具体的に描かれているので、主としてシナリオステート図を見ながらクラスコラボ図を作ります。「入力しやすいGUI」を作る例に対してクラスコラボ図を描くと、例えば次のようになります。
クラスコラボ図では、ほしい機能を実装するために、どのようなクラスを作って、お互いをどのようにコラボレーションさせればよいかを描きます。クラスコラボ図の作り方は、別ページ「クラスコラボ図」の記事で詳しく記載しています。 上のクラスコラボ図の見方を説明します。上の図では、不適切な文字を入力すると、背景を赤に変える機能を実装するために、「検証」クラス[C]を作ります。テキストボックス[A]などの入力型のUI要素1つに対して、[C]を1つ用意します。入力型UI要素が公開するイベントに[C]を登録して、入力内容が変化した瞬間を[C]に通知してもらいます。変化した瞬間ごとに、[C]は入力内容が正しいかを判定して、OKかエラーかを決めます。そして、エラーであれば、イベント元のUI要素の背景を赤に変えます。 [C]の検証でエラーだった場合は、ヒントマークを表示します。そのため、ヒントマークのUI要素として、[D]を作ります。[C]の検証でエラーだった場合は、[C]が[D]を表示して、エラーが解消されたら、[D]を非表示にします。ユーザが[D]をクリックした場合は、説明文ボックスを表示します。説明文ボックスのUI要素として、[E]を作ります。[D]をクリックしたら、[E]を表示して、もう一度[D]か[E]をクリックしたら、非表示にします。 クラスコラボ図を作る際に、シナリオステート図に描かれた変化の様子を見ることで、いろいろ細かな点に気付くことが出来ます。例えば、テキストボックスの入力方法を見て、入力内容の変更イベントに登録する必要性に気付いたり、ヒントマークや説明文ボックスのUI要素が必要な点に気付いたりします。また、背景を赤に変える動作を見て、「検証」クラス[C]を作る必要性に気付いたりします。このように、シナリオステート図を作って変化の様子を具体化しておいたことで、クラスコラボ図がとても作りやすくなります。 4. コーディングする 3.でクラスコラボ図が完成したら、そのクラスコラボ図を見ながら、コードを書いて機能を実装します。クラスコラボ図は、どのようなクラスをいくつ作ればよいかを示します。「入力しやすいGUI」を作る例では、前述のクラスコラボ図から、クラスは、「検証」クラス[C]1つ、UI要素は、ヒントマーク[D]と説明文ボックス[E]の2つ作ればよいことが分かります。 クラスコラボ図の中で、クラスにつながる矢印が、そのクラスに実装すべき動作を示します。クラス[C]につながる矢印に注目すると、クラス[C]には、次の動作を実装すればよいことが分かります。
また、[D]のクリックイベントには、[E]を表示／非表示する動作を実装します。 5. テストコードを作り、テストする 4.で機能を実装したら、テストコードを作ってテストを行います。ここで、もう一度、2.で作ったシナリオステート図が役に立ちます。シナリオステート図は、見た目が変化する様子を表すと同時に、テストで確認すべきテストケースを表しています。 シナリオステート図には、当初ほしいと考えていた機能が具体的に表されています。なので、シナリオステート図を見ることで、それらの機能が本当に実装できたかを確認するには、どんな条件で何をテストすればよいのかが分かります。このように、シナリオステート図に戻ってテストケースを考えることで、当初のほしい機能が漏れなく実装されているかを、確実にチェックすることが出来ます。 クラスコラボ図を描く前に内在する仕事を洗い出す 前述したように、クラスコラボ図を描く前には、WannaDoリストとシナリオステート図を作る2つの段階がありました。クラスコラボ図を描くときは、まず、WannaDoリストを作って、どんな機能がほしいのかを明確に記します。その後、WannaDoリストの内容に基づいてシナリオステート図を描いて、どのようなシナリオの中でその機能を使い、どのように状態が変化していくかを具体化します。 これらを作ることで、その機能の中に内在している、クラスがすべき処理を洗い出すことが出来ます。シナリオステート図の中で、矢印を付けて状態が変化する様子を描いた部分が、すなわち、クラスが何らかの処理をして、状態を変化させる部分になります。この何らかの処理が、クラスのすべき仕事です。このように、クラスが処理すべき仕事を、具体的に図の中で洗い出せるため、クラスコラボ図が描きやすくなります。
シナリオステート図のシナリオとステート シナリオステート図は、ほしい機能を利用する一例のケースに限定して描きます。どのような順番で操作して、どのようにその機能を使うのかを、図で描けるように限定します。シナリオステート図のシナリオとは、この限定した利用ケースのことを指しています。 シナリオステート図は、変化するものに着目して、変化の様子を具体的に描くことで、ほしい機能を分かりやすく表します。ある状態から次の状態へ変化する様子は、数ある図法のうち、状態遷移図で表すのが最も適切です。そのため、シナリオステート図では状態遷移図を使います。シナリオステート図のステートとは、状態遷移図のステートを指しています。
複雑なケースはシナリオステート図を複数描く シナリオステート図は、ほしい機能を一例のケースに限定して描きます。具体的に図で描けるように1つに限定してしまいます。そのため、いろいろな利用パターンがある複雑な利用ケースを描く場合は、図に描けない部分が出て来てしまいます。 この場合は、無理に1つの図に詰め込むことはせず、複数のシナリオステート図に分けて描くようにします。シナリオステート図は、常に1つの利用ケースに限定して描き、描けなかった分は2つ目のシナリオステート図に描きます。そして、この2つの図がセットで、ほしい機能を表すようにします。 状態変化のないものはシナリオステート図を描かない 前述の節とは逆に、UIの動作がワンパターンであったり、データ処理の流れが一定であったりと、状態の変化がない場合は、シナリオステート図を描く必要はありません。状態の変化がない場合は、シナリオステート図を描いても、状態を表すイラストを1つ描くだけになってしまい、図が多くを示しません。 同様に、クラスが1つしか要らないような単純な機能であれば、クラスコラボ図を描く必要はありません。クラスが1つしか要らない場合は、クラスコラボ図を描いても、クラスを表す四角を1つ描くだけになってしまい、図が多くを示しません。 WannaDoリストとシナリオステート図で説明資料が出来上がる WannaDoリストとシナリオステート図を作れば、このソフトはいったい何をするのか、を具体的に伝える説明資料が出来上がります。本来、クラスコラボ図を作りやすくするために作った、WannaDoリストとシナリオステート図が、後に説明資料としての成果物にもなり、一石二鳥です。 シナリオステート図はUI系とアルゴリズム系の2種類ある シナリオステート図には、GUIの見た目が変化する様子を描いたUI系シナリオステート図と、データの内容が変化する様子を描いたアルゴリズム系シナリオステート図の、2つの種類があります。前述の「2. シナリオステート図を描く」の節で「入力しやすいGUI」の例として挙げた図は、UI系シナリオステート図です。以下にもう一度、同じ図を掲載します。
一方、アルゴリズム系シナリオステート図は、データの内容が変化していく様子を具体的に描いたものです。簡単な図の例として、「スタック」の機能を表したシナリオステート図を次に示します。「スタック」は、データを保管するリストの1つで、データの追加(プッシュ)と取り出し(プル)が出来るリストです。「スタック」では、データを入れた順にデータを取り出します。
上の図では、例えば、スタックに1→2→3と入れると[A→C]、3→2→1と取り出せる様子[D→F]を表しています。このように、アルゴリズム系シナリオステート図では、何らかのアルゴリズムによって、データの内容が変化していく様子を描きます。ほしい機能がアルゴリズムの場合は、アルゴリズム系シナリオステート図を描いて、その機能を図にします。 上の図では、簡単に図を描くために、一例のケースに限定しています。スタックに1→2→3と入れるパターン以外にも、スタックは様々な動作をします。1、2、3を順に入れる必要もなく、3個を続けて入れる必要もありません。しかし、シナリオステート図では、1つの利用ケースに限定することで、ほしい機能がどのようなものなのかを具体的に表します。 より複雑な例 はじめに挙げた「入力しやすいGUI」を作る例に、もう1つ「入力を誘導する」機能を追加して、ここではより複雑な例を考えます。前述した5段階の流れに沿って、WannaDoリスト→シナリオステート図→クラスコラボ図を順に作ります。 1. WannaDoリストを作る まず、次のように、WannaDoリストの3番目に、「入力を誘導する」機能を追加します。
次に、シナリオステート図を描きます。WannaDoリストに書いた3つの機能を1つのシナリオステート図にまとめて描くと、図が複雑になるので、ここでは2つのシナリオステート図を作ります。1つは、WannaDoリストの1 & 2番目の項目にある「修正を喚起する」機能を描きます。この機能に対するシナリオステート図は、前述の「2. シナリオステート図を描く」の節ですでに作りました。以下にもう一度、掲載します。
そして、もう1つのシナリオステート図は、3番目の項目にある「入力を誘導する」機能を描きます。この機能に対してシナリオステート図を作ると、例えば、下の図のようになります。お互いの機能が独立していないので、「入力を誘導する」機能に加えて、「修正を喚起する」機能の一部である「背景を赤に変える」機能も描いています。ここでは、例として、GUIに「入力1」、「入力2」、「OK」ボタンの3つのUI要素がある場合に限定して考えます。
上のシナリオステート図の見方を説明します。まず、最も左上の[E]の状態から始まります。[E]は、まだ何も入力していない空の状態です。[E]では、はじめに入力すべき「入力1」のテキストボックスの周りを青色にして、入力を誘導しています。ここで、正しく入力した場合は、下の[G]へとGUIが変化します。[G]では、次の入力箇所である「入力2」の周りを青色にして、次の入力へと誘導しています。さらに、「入力2」も正しく入力した場合は、下の[I]へと変化します。[I]では、次にクリックすべき「OK」ボタンの周りを青色にして、ここをクリックするように誘導しています。 もし、[E]のときに「入力1」に誤って入力した場合は、右の[F]へと変化します。[F]では、テキストボックスの背景を赤色にして、ミス入力を修正するように喚起しています。「入力1」を正しく入力すると、[G]へと変化します。[G]、[H]も、[E]、[F]と同様に動作します。 3. クラスコラボ図を描く シナリオステート図が出来たので、次に、クラスコラボ図を作ります。シナリオステート図を作ったので、「入力を誘導する」機能が、具体的にどのような動作をする機能なのかイメージが固まりました。ここでは、その動作イメージを基に、コード上でどのように実現するかを考えます。クラスコラボ図は、例えば、下の図のようになります。
上のクラスコラボ図の見方を説明します。上の図では、次に入力すべき所の周りを青に変える機能を実装するために、「誘導」クラス[G]を作ります。[A]や[B]など周りを青に変えたいUI要素1つに対して、[G]を1つ用意します。「検証」クラス[C]が公開するイベントに[G]を登録して、未入力、入力エラー、入力完了の検証結果が変化した瞬間を[G]に通知してもらいます。もう一つ、誘導の順番で1つ前に当たる「誘導」クラス[F]のイベントにも[G]を登録して、未完、完了の状態が変化した瞬間を[G]に通知してもらいます。 [G]では、これらのイベントが来た時に、[C]と[F]の2つの状態から、次のような規則で青の四角領域[H]を表示／非表示にします。
この規則によって、次に入力すべき所の周りを青に変えることが出来ます。上のクラスコラボ図では、規則によって青の四角[H]が表示／非表示する動作が分かりにくいので、前述のシナリオステート図で使った例に沿って、[C]と[F]の状態と、[H]の表示状態がどのように変化していくかを、次の図に示します。
上の図は、3つのクラスコラボ図を縦に並べて、[C]、[F]、[H]の状態が変化していく様子を表したものです。それぞれのUI要素(入力1、入力2、OKボタン)に対して、1つずつ「検証」クラス[C]と「誘導」クラス[F]を作ります。これらのクラスは、上の図のような形のイベントの参照構造を持ちます。この参照構造の場合、入力を誘導する順番は、入力1→入力2→OKボタンとなります。 上の図では、それぞれの「誘導」クラスが、前述した規則『1つ前の「誘導」クラス[F]の状態が「完」で、「検証」クラス[C]の状態が「未」の場合、青の四角[H]を表示する』に従って動作しています。すると、上の図のように、ユーザーの入力に応じて、次に入力するべき所の周りが順に、青に変わるようになります。 このように、クラスコラボ図だけでは動作の様子が分からない場合は、クラスコラボ図を1つの状態として、クラスコラボ図が変化する様子を、再度、シナリオステート図で描くことが出来ます。前述のシナリオステート図の内容に対応させて、クラスコラボ図の中にあるクラスの状態が変化する様子を、シナリオステート図で表します。 世の中の似た機能 現状文章 (同じこと、似たことがされている場合のみ) 図を用いた開発の代表として、UMLがある。書籍「入門 UML 2.0」の中では、UMLを使った開発の流れとして、次のような順でUMLを使うことが多いと書かれてある。
このうち、1～4番目は、基本的な点で、本記事のクラスコラボ図を使った開発の流れと同じと考えることが出来ます。1.のユースケース図では、要件、すなわち、実装すべき機能を洗い出します。本記事の流れでも、最初にWannaDoリストを作り、実装すべき機能をリストアップします。WannaDoリストでは、ユースケース図のように図と表を使って、細かく洗い出すことはしません。その代わりに、次のシナリオステート図でどんな機能なのかを具体的に図で表します。WannaDoリストは、細かく書く必要がないので、より気軽にメモすることが出来ます。 2.のアクティビティ図では、処理の流れを検討します。本記事の流れの中では、処理の流れに注目して図を作るステップはありません。その代わりに、シナリオステート図で、機能が利用されるシナリオを具体的に図示するので、その機能がどのような動作をするのかが分かり、シナリオステート図を見れば処理の流れを容易にイメージすることが出来ます。 3.のクラス図、4.のコミュニケーション図は、クラスコラボ図に対応します。クラスコラボ図は、クラス図やミュニケーション図の書き方を取り入れたもので、よく似ています。クラス図、コミュニケーション図とクラスコラボ図の違いは、別ページ「クラスコラボ図」の記事の「世の中の似た機能」の節に説明があります。本記事の流れの中には、シーケンス図、コンポーネント図に対応するステップはありません。必要であれば、適宜、これらを取り入れます。 ユースケースを作る、要件定義、クラスの設計...実装、テスト
※ご意見、ご感想、改善点、その他の情報などがありましたら、メールにてお知らせ願います。 |
