Skip to content
Trending Topics: UML•GSN/D-Case•UML-theory•SysML•GSN-practice

Category: UML-practice

動詞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言語の技術者が良い設計をする為に使う、   そうですね、はい。   […]

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

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

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

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