拝啓、サカモトと申します。

Another Gahaku.Text Powered Blog

目次

ニュース

元○○

記事カテゴリ

書庫

Blog 利用状況

絵画はこっち。

UML。

仕事の性質上、昔ながらのフローチャートとかは良く使います。

「図」としての仕様書という意味で。

もちろん他にも仕様書はありますが、あくまで「図」に限るとフローチャートと業務フローくらいしか使ったことありません。

 

で。

 

UMLってかれこれ10年くらい(?)「有益だ!」「仕様書はUMLで作成のこと(?)」とかあったと思うんです。ちゃんとやったことないので、「思う」しか言えませんが。

 

名称とか概念とかはあちこちの記事を読んでなんとなーくつかんではいるんですが、「さぁ!じゃあ実務でGO!」というレベルには程遠い知識だと思います。

 

なのでちょこっと実務で使いつつ勉強をしようと思っているのですが、何から始めて良いのか分りません。

 

「まず、この範囲で適用することをお勧めする」

とか

「うちの現場ではこうやってる」

とか

「とりあえずこの本を読め」

とか

「そもそもUMLなんて・・・」

とか

ご意見を賜りたく。

投稿日時 : 2008年4月25日 8:04

Feedback

# re: UML。 2008/04/25 9:08 επιστημη

字を読むより絵を観るほうがわかりやすい/誤解が少ないと
思われるから絵で表現するわけで。
で、どうせ絵を描くならせっかくだからギョーカイ標準使おうよ。

のひとつがUMLやと思います。
使えそーなとこから使ってけばいぃんじゃないかと。

# re: UML。 2008/04/25 10:29 やまだ

>「図」としての仕様書という意味で。

いや、UML だって同じようなもんだと思うんですが。

とりあえず、使ってみるとしたら一般的には「クラス図」あたりからですかねぇ。

> フローチャートと業務フロー

本来の使い方とは違うかもしれないけど、この辺だったら「アクティビティ図」使ってみる、というのもありかもしんない。

いや、それで何が変わるの?と言われたら、それまでかもしんないけど。
少なくとも「UML書けば、ソースコードまで自動生成!」ってのは、現在のところ幻想だと思っとります。

# re: UML。 2008/04/25 10:40 επιστημη

おもきし"幻想"でしょね現時点では。
むしろ文章が故の曖昧さを極力排除し、
「共通のボキャブラリの基で仕様を語る」
ことに意義がある思うですます。

# re: UML。 2008/04/25 10:53 NAL-6295

実際に仕事で活用したのは11年くらい前に制御系の仕事でUMLの前身であるBooch法(クラス図が雲な奴)を使ったくらいですね。
Rational Roseを利用してクラス図とオブジェクト図を書いていました。
ユースケース仕様とシナリオ仕様は文章で書き、
その後にクラス図オブジェクト図を書いて、
スケルトンコードを自動生成した後に操作仕様をコメントで書いて、
テスト用のスタブクラスを実装してから、操作仕様を実装していました。
クリーンルームを採用していたので、それぞれの成果物フェーズでレビューがあり、一定以上の指摘や不具合があった場合は修正ではなく作り直しといった段取りを踏んでいました。
それ以降のプロジェクトではオフィシャルな仕様書として活用したことはないです。
だいたい、クラス図をスケッチ程度に利用するくらいです。

# re: UML。 2008/04/25 11:58 凪瀬

一律適用は難しいんですよね。

かなり上位の設計での概念を表現するには便利なんですが
実装レベルをいちいちクラス図、シーケンス図なんてやってられない。

どの抽象度で用いるかという切り分けが肝で、そして規約にしにくい部分です。
補助資料的に添付するのはよいのですが、必須資料とされると誰も読むことのないナンセンスな図ができるだけだったりします。

# re: UML。 2008/04/25 12:19 biac

> 実装レベルをいちいちクラス図、シーケンス図なんてやってられない。

ですます。
パッケージレベルというか、 クラス群の玄関クラスというか、 そんなレベルでクラス図、シーケンス図あたりを書くといいんじゃないかな。 機械に読ませるんじゃなくて、 人間が読むんだから、 コードと正確に一致していることよりも、 理解できることのほうが大事。
# だから、 シーケンス図の左側に、 矢印と高さを合わせて日本語の説明をまとめて書かせたり f(^^;

とりあえずお勧めの本: 「UML モデリングのエッセンス」( マーチン・ファウラー )
http://www.amazon.co.jp/exec/obidos/ASIN/4798107956/bluewatersoft-22

あと、 おそらく余談になると思うけど…
UML で一番誤解されてると思うのが、 ユースケース図。
ユースケース駆動開発とか言われて (いや、 それは良いのだけど f(^^: )、 ユースケース図だけを描きまくってみても何にも出来ません。
もしも 「ユースケース駆動で…」 とか言われたら、 ユースケース ( not 図 ) の書き方を勉強しましょう。
「ユースケース実践ガイド」 ( アリスター コーバーン)
http://www.amazon.co.jp/exec/obidos/ASIN/4798101273/bluewatersoft-22

# re: UML。 2008/04/26 7:44 さかもと画伯

なるほど・・・・。

ご意見からうかがえることは

・神話になっているように万能じゃないよ
・まずは○○図から、としぼって使ってみる
・正式文書としての普及はまだまだ
・実装時にちまちま書けない

という感じでしょうか?

あれこれと調べていると「UML側」からの記事とか書籍しかないので、いかにも「万能!絶対つかえ!」みたいな印象を受けていたのですが、なるほどー。


型通りにとらえず、もうちょっと柔軟に考えて適用していきたいと思います。

ありがとうございました。

# re: UML。 2008/04/26 13:42 やまだ

んー、
・これさえ使っとけばOKというもんではない
・なんでもかんでもこれでやろうとするな
・無条件にいきなり全面展開しようとするな
って、感じで使いどころさえ間違えなければ問題なく使えるかと。
#使えるからって、それで何が解決する、っていうレベルの話ではないけど。

「正式文書として」というより、その中で使われる図面としての利用ではないかと。

# re: UML。 2008/04/27 23:10 もしもし

勉強しようと思って黄色い本買ったけど、買っただけで勉強した気になってしまうのは受験生時代の負の遺産ですかそうですか。

# re: UML。 2008/04/28 17:36 さかもと画伯

>やまだっち

なかなか正式文書にはなりづらいみたいですねー。
マインドマップとかと同じ感じ・・・。

全面展開は無理そうなので、ごく一部に適用してみようかと思います。

>黄色のもしっち

負の遺産です。
むしろ、「負」だけです。
「負し負し」とかに名前を変えたりするとよいかもしれません。

# re: UML。 2008/04/29 2:58 やまだ

> 負の遺産です。
んにゃ、正解だと思うぞわたしゃ。
所詮は記法なんだから、わかった範囲で使ってわからなくなったら読めばよいだけだと思う。
そういうわけで、いつでも読めるように手元にある、これで問題ないと思うし。

> マインドマップとかと同じ感じ・・・。
ちわう。
良し悪しじゃなくて、マインドマップはノードに何を書くか、どういう木構造にするかは完全に人に依存するでしょ?どういう粒度で何をどのように書くかはルールを決めないと統一できないし、それを知らないと解釈できない。
UMLだと何をどう書くかがある程度決まっているので、共通のルールに則って書けるし読める。
「UMLで書いたから」と言えば記法の説明は不要。

> なかなか正式文書にはなりづらいみたいですねー。
だから、正式文書の「一部には」なるって言うとうやん。全部をUMLだけで済まそうという思想はないと思うが。
まあ、要するにこういうのは回りにどの程度受け入れる土壌があるのかによるんだけど。要求定義とかで使う分には難しいかもしれないなぁ(お客さんがUMLを知らなかったら意味がない)。

# re: UML。 2008/04/29 3:01 やまだ

>「負し負し」とかに名前を変えたりするとよいかもしれません。

いやその前に「だめもと画伯」に。
#「さかもとが吐く」でもOK。

# re: UML。 2008/04/30 7:46 さかもと画伯

>やまだっち

おぉ~。
なるほど、少なくとも「ルール」は共通だからか・・・。

UML、休日に調べまくりましたが、まだ漠然としか分らず。「実業務のどの場面で?」とか考えると、ルールは理解できても実践が・・・。

もうちょっと勉強しよっと。

さかもとは吐きました、飲み過ぎて。

# re: UML。 2008/04/30 11:11 やまだ

独自の図を使って、設計書を書くとその図がどういう記法で書かれているか、という説明が必要。
共通の記法を使うと、その辺の説明はいらん、というメリットがある。
ある程度先も含めて閉じた範囲でなら、あえて移行する必要はないかもしれない。
記法を多くの人で共有するコストを考えるか否か、ではないかと。

# re: UML。 2008/04/30 15:09 さかもと画伯

>やまだっち

なるほど、「どの言葉」かを共有できれば世界で通用すると。大げさに言えばそんな感じでしょうか?

共有するにあたってのコストは確かに捨てがたいですねー。ちゃんと考えなきゃ・・・。


細かい記法より先にそっちを考えなきゃ・・・。

# re: UML。 2008/05/01 16:34 biac

さかもと画伯 wrote:
> なかなか正式文書にはなりづらいみたいですねー。

いやだから、 UML は文書になりません ってば。 f(^^;

設計文書の一部分に含める図の表記法として、 UML を採用するかどうか、 ってだけです。
  設計文書 = 文章 + 表 + 図 + 絵
の、 図の部分を UML を使って描くかどうか、 ってだけのこと。
だから、
1. 設計文書にどんなことを書くか?
2. 設計文書をどんなふうに書くか?
って問いがあったとして、 どっちにも答えられないと設計文書は作れないわけですが、 でも、 1. が主で 2. が従です。 より大切なのは 1. で、 2. は本質じゃない。 で、 2. の答を考えるときに、 その選択肢の一つとして UML がある、 っていうだけのこと。 ( で、 UML を選んでおけば、 そこは世界共通ですよ~、 と。 )

前述の 「UML モデリングのエッセンス」 には、 開発のどんな局面でどんな図を使うべきか、 なんてヒントも書かれてて、 お勧めですよ~、 と f(^^;
http://www.ogis-ri.co.jp/otc/hiroba/ogisbooks/UMLDistilled.html

# re: UML。 2008/05/01 17:51 さかもと画伯

>biacさん

あぁぁぁ~よく分んない~~wwww

何か、基本的な概念を勘違いしているような・・・。

ご紹介頂いた本、買い求めてみます。


変な(すごくパーフェクトな)イメージを持ち過ぎてるんだろうか・・・。

タイトル
名前
Url
コメント