[cppll:9366] Re: [御意見拝聴] UML をソフトの基本設計で使いますか？

こんにちは、赤坂＠いつもはROM です。

私もUML、C++を使っています。
面白そうなので、しゃしゃり出て来てしまいました(^^;; よろしくお願いします。

kenji@... (kenji) san wrote:
> 私自身は UML を基本設計の段階で使うとしたら use case を使った仕様の書
> き出しぐらいです。でも、これも箇条書きのメモと大差はありません。多くの
> 場合、ソフトをどのように記述していくか考えているときに作るものは、メモ・
> テキストとヘッダ・ファイルの書き出し（データ構造）です。これらの初期の
> 資料は自分のメモ書きでしかなく、人様に資料として提出できるものではあり
> ません。UML がこの役割を果たしてくれれば嬉しいのですが、現状の UML で
> は C++ プログラムの基本構造を記述するには機能不足だと感じています。

ユースケース(の書き方は)は別にメモでも何でも構わないと思います。
開発対象のシステム(ソフト)で、何をするのか(あるいは、何をしないのか)が
ハッキリすれば良いと思います。ここでの記述はそれ以外にも使えますよね。

小林さんのおっしゃられている"基本設計"は、"分析"と考えてよいですか？
# 私は普段、要求分析、分析、設計という工程(の名前)で考えていますので。

UMLで全てのことを表現できない、という意味では機能不足は否めませんね。
私は別にそれで構わないと思っています。
むしろ、UMLにどんどんダイアグラムが増えて簡単に覚えられなくなってしまう
（としたら、その）方が問題だと思っています。

> いと理解できません。ブロック図や回路図のように、全体を平面的に一目で理
> 解できる資料をソフトでも作れたら良いと思います。でも、このような方法は
> できて上がっていないと考えます。UML でも複数の STL コンテナの大まかな
> 依存関係を表現できるとは思います。でも「大まか」に限られると思います。
> そのため、 UML は基本設計の段階ではなく清書する段階で使えるツールだと
> 思います。

ソフト開発も汎用コンポーネントの組合せで開発するのが当たり前の世界になれ
ば、きっとブロック図や回路図のような図でシステムを表現することになるのか
もしれませんね。
# 現状の CASEツールは設計CADと呼ばれるのかな？

基本設計の段階で、大まかに捉えられるとしたら使えないのでしょうか？
少なくとも私の場合、この段階では実現可能性を検討するので、詳細については
UMLで表現する必要もないと思っています。
もっとも、気になる部分(検討事項)はノートアイコンでメモを取っておきます。

清書としてのUMLについては、機能が不足(全てを表現できない)という意味から、
小林さんにはむしろ役不足と感じますが、いかがでしょうか？

# UMLは使えないということではなく、UMLベースで開発していても
# 図で表現したいことを限定すれば良く、必要があればUML以外のダイアグラム
# で表現すれば問題ないと思います。


> UML が機能不足だとしても、複数の人間と共同でソフトを開発していくときは、
> UML を使うと思います。ソース・プログラムや自然言語以外に、プログラムに
> ついて情報を交換する手段は UML しかないからです。クラス図などはヘッダ・
> ファイルよりは他人に早くクラス構造を伝達できます。でも、一人でソフトを
> 開発しているときには（情報を伝達する必要のないときには）、クラス図は清
> 書する段階でしか使わないと思います。様々の可能性を検討しているときには、
> 機能が不足していて記述が面倒なクラス図は使えないと思います。

人に伝える(複数人で開発)場合と、自分ひとりで開発する場合では、基本設計で
行う範囲が変わるのでしょうか？
# 1人なら書かなくて済む図も書かなくちゃならない、ということですか？

「様々な可能性の検討」が何を差しているのか誤解しているかもしれませんが、
分析では、実現可能かどうかと、登場人物(クラス)と役割が適切かどうか、がポ
イントだと思っています。
そこでコラボレーション図(あるいはシーケンス図)が必要になってきます。1人
なら裏紙に書いたり、チームならホワイトボードに書いたりして検討することに
なります。直接、CASEツールで書いてしまうこともよくありますが、そんなに面
倒な記述でもないかなと。

また、この段階ではシグニチャの詳細は無視しています。

設計の段階では、ツールでコード(スケルトン)生成を行っているため、細かいシ
グニチャを記述します。これは結構面倒くさいです(^^;;

# 個人的には、UMLで大まかに表現できれば、後はゴリゴリ実装すれば良いの
# ではないかとも感じますが、MDAだとそうは行かないでしょうね。

話を戻すと、分析では大まかにクラスを検討するだけなので、
その目標からはUMLのダイアグラムで充分かな、と私は思っています。

> 私は、このように UML を考えていますが、世間では、一人で設計するときで
> も UML を基本設計に使えると主張する方もいらっしゃいます。もし回路で基

私は1人でも（殆どのケースで）やはりUMLを使います。
もちろん、要求および実現方法が明確で検討の必要がなければ書かないと思いま
す。私がUMLを使うのは、いまだにクラス分割がおぼつかないためです(^^;;

kenji@... (kenji) san wrote:

> UML の使い方は、言語、分野により変わってくると思います。JAVA と C++ で
> は UML の使いか方も変わってくると思います。

そうですね。
設計最終段階のコード生成に関わる部分については、JavaやC++で当然異なる部
分もあると思います。

コード生成を行わないならその違いの部分まで表現する必要もない、
というのが私の考えですが。

kenji@... (kenji) san wrote:

> コラボレーション図は、なんらかのタイミングを取り出して、そのときのイン
> スタンス間での method の遣り取りを図示したものだと理解しています。
>
>     ┌─────┐  1:funtion1(x) ┌─────┐
>     │instance A├───────→│instance B├─ ...
>     │          │←───────┤          │
>     └─────┘  2:funtion2(y) └─────┘
>
> こんな図を手で書くのは面倒です。多分、自動生成させるのでしょう。

前述の分析レベル(シグニチャはいい加減なレベル)で、ツールより
むしろ、ハンドフリーで書きます。

自動生成されれば嬉しいですが、それはコードを書いた後ですよね。
それを見てコードを修正するなら、書く前に正しくしておきたいです。
# リファクタリングすれば良いのか。

> でも、STL コンテナにインスタンスを保存し、管理制御するような、インスタ
> ンスがダイナミックに生成消滅するプログラムの動作に対応したコラボレーシ
> ョン図を自動生成できるとも思えません。できたら、どのようににコラボレー
> ション図を導き出しているのか教えていただけますでしょうか。

私の場合、分析レベルで使うので、コンテナの詳細は全く書きません。
(コンテナが必要だろうけど無視して)複数の要素をどう扱うのかだけを書きます。
# やりたい事をコンテナがサポートしているかどうかは、気になれば確認します
# が、ダイアグラムに書くのはノートにコメント位ですね。

> 私自身はコラボレーション図を私は、書いたことも、書きたくなったこともあ
> りません。清書のためのシーケンス図を書いたことがあるだけです。コラボレ
> ーション図を書く手間と解りやすくなる効果を計りにかけて、手間を惜しん
> でいます。

私が表現しようとするレベルの記述に価値がないと判断されるなら、
コラボレーション図はあまり役に立たないと思います。
# 書く手間が惜しいということで良いのではないかと思います。

> 私には、これを UML で解りやすく書けるとは思えません。自分の naming
> convention -- Singlton class は最後に Sglt をつける、list container は、
> 頭に lst をつけるなどを前提に、プログラム・コードを追ったほうが、効率
> 的だと思っています。この意味でプログラムの構想・検討段階では UML はあ
> まり使えないと思っています。

見たい視点の違いなので、詳細はソースコードで、というのもアリですね。

私と違うのは、構想・検討段階での対象が、
・私は大雑把、
・小林さんはかなり細かい(私から見ると詳細設計のレベル？)
のではないかと想像します。

小林さんの行っている、基本設計(あるいは、構想・検討段階)と
内部設計(あるいは詳細設計)ではどんな視点の違いがあるのでしょうか？

> もっとも、このような方法は人様にプログラムの構造・動作についての情報を
> 伝達する手段としては有効ではないと思います。プログラマーが共通して理解
> している UML ドキュメント・ツールを使う意味はあると考えます。

正確で数百ページにわたる設計ドキュメントと、大雑把だけど平易で読みやすい
数十ページのドキュメントがあるとしたら、私は喜んで後者を選択します。
# UMLなんてそんな風に使えば良いのではないでしょうか？

では。
# 長文失礼しました。m(_._)m

--
赤坂 英彦 (Hidehiko AKASAKA)
akasaka.h@...