PR
hirocom6618
SE(システムエンジニア)の日常や仕事の日記です。
キーワードサーチ
▼キーワード検索
フリーページ
2005.07.05
テーマ： 仕事しごとシゴト(24480)
カテゴリ： カテゴリ未分類
先日、S社のUML講習に行ってきました。
数年前にUMLを使う機会があったのですが、現場では使えないなという勝手な印象を持っていたため、会社の薦めとはいえ気が進みませんでした。
講習会ではUMLのユースケース図やシーケンス図といった表記法を学びましたが、
その表記法よりも、それぞれ必要な場面があるということでした。
以前、会社でUMLで設計をするという方針があり、業務を知ったSEがその業務のユースケース図やシーケンス図を作成しました。
結局、自分の業務を知り尽くしたSEは仕様が明確なため、わざわざUMLで表記することに意味もなくなり、結局仕様書から作成することになりました。
今回の講習会で学んだのは、UMLはコミュニケーションツールであり、ユーザと仕様をつめるときはユースケース図、ユーザと処理の細かな遷移をつめるときはシーケンス図といった役割があるということでした。
以前は、UMLを設計代わりにしようとしたため、そもそも誰向けの図か分からないものになり、さらにオブジェクト指向言語の開発でなかったため、UMLでは実装までのイメージがつかめていませんでした。
当時の開発はUMLを使う場面でなかったということです。
XPやアスペクト指向といったソフトウェア開発論がありますが、実装まで見えてこないのはその開発にあてはまらないからだと思っています。
様々な方法論がある中で、必要な場面や設計の深さなどを判断して、開発がスムーズに行く方法論を見極めることが大切だと感じました。
数年前にUMLを使う機会があったのですが、現場では使えないなという勝手な印象を持っていたため、会社の薦めとはいえ気が進みませんでした。
講習会ではUMLのユースケース図やシーケンス図といった表記法を学びましたが、
その表記法よりも、それぞれ必要な場面があるということでした。
以前、会社でUMLで設計をするという方針があり、業務を知ったSEがその業務のユースケース図やシーケンス図を作成しました。
結局、自分の業務を知り尽くしたSEは仕様が明確なため、わざわざUMLで表記することに意味もなくなり、結局仕様書から作成することになりました。
今回の講習会で学んだのは、UMLはコミュニケーションツールであり、ユーザと仕様をつめるときはユースケース図、ユーザと処理の細かな遷移をつめるときはシーケンス図といった役割があるということでした。
以前は、UMLを設計代わりにしようとしたため、そもそも誰向けの図か分からないものになり、さらにオブジェクト指向言語の開発でなかったため、UMLでは実装までのイメージがつかめていませんでした。
当時の開発はUMLを使う場面でなかったということです。
XPやアスペクト指向といったソフトウェア開発論がありますが、実装まで見えてこないのはその開発にあてはまらないからだと思っています。
様々な方法論がある中で、必要な場面や設計の深さなどを判断して、開発がスムーズに行く方法論を見極めることが大切だと感じました。
お気に入りの記事を「いいね！」で応援しよう
Re:UML講習(07/05)
メディナス
さん
訪問ありがとうございました。
私もUMLとやらの説明は聞いた事がありますが、今ひとつ
現場で通常に使うのは難しいかなと言う感想だったので
知識として伺いました。
新しい動きとしてはありでしょう、が、完全に採用には
しばらく時間がかかりそうですね。
仕様の透明化というか万人が理解できるという意味では
意味があるのでしょうが、ＳＥサイドとしてはそれより
開発の運用自体の方が重要な訳ですし。確かにＳＥと
ユーザーさんの距離は近いに越した事は無いのでしょうが。 (2005.07.06 06:16:51)
私もUMLとやらの説明は聞いた事がありますが、今ひとつ
現場で通常に使うのは難しいかなと言う感想だったので
知識として伺いました。
新しい動きとしてはありでしょう、が、完全に採用には
しばらく時間がかかりそうですね。
仕様の透明化というか万人が理解できるという意味では
意味があるのでしょうが、ＳＥサイドとしてはそれより
開発の運用自体の方が重要な訳ですし。確かにＳＥと
ユーザーさんの距離は近いに越した事は無いのでしょうが。 (2005.07.06 06:16:51)
Re[1]:UML講習(07/05)
hirocom6618
さん
メディナスさん、訪問ありがとうございます。
おっしゃるとおり現場で使うにはもうしばらく時間がかかりそうです。
UMLはユーザさんから要望を聞き取るときに、仕様をユーザさんに分かりやすい形にできる点は個人的にすぐに使えそうな気がします。
UMLには継承や包含といった表現があるためユーザさんにとって分かりにくくなり、ユーザさんと開発者との設計の深さが違うために、未だに使いにくい印象を持っています。
現場でも統一することは難しいですが、UMLのいいところを実際使ってみようと思っています。 (2005.07.07 23:05:36)
おっしゃるとおり現場で使うにはもうしばらく時間がかかりそうです。
UMLはユーザさんから要望を聞き取るときに、仕様をユーザさんに分かりやすい形にできる点は個人的にすぐに使えそうな気がします。
UMLには継承や包含といった表現があるためユーザさんにとって分かりにくくなり、ユーザさんと開発者との設計の深さが違うために、未だに使いにくい印象を持っています。
現場でも統一することは難しいですが、UMLのいいところを実際使ってみようと思っています。 (2005.07.07 23:05:36)
こんばんは！
lexuoli
さん
はじめまして。ブログ拝見させていただきました。
私は現場でUMLを使っています。使っていると言うのは少し表現がおかしいかもしれませんが。分析～設計～詳細設計～実装までの成果物はUML準拠のモデルを作成し(ユースケース、クラス図、シーケンス図など)、CASEツールにてソース自動生成→実装を行っています。
初めての現場がこのプロセス、手法で開発をしているので、何が良いという比較はできないのですが、拡張的なシステムを作りこんでいくものにはクラス図などのモデルから拡張し、自動コード生成もできる点で導入メリットはあると思います。
(2005.09.10 02:29:08)
私は現場でUMLを使っています。使っていると言うのは少し表現がおかしいかもしれませんが。分析～設計～詳細設計～実装までの成果物はUML準拠のモデルを作成し(ユースケース、クラス図、シーケンス図など)、CASEツールにてソース自動生成→実装を行っています。
初めての現場がこのプロセス、手法で開発をしているので、何が良いという比較はできないのですが、拡張的なシステムを作りこんでいくものにはクラス図などのモデルから拡張し、自動コード生成もできる点で導入メリットはあると思います。
(2005.09.10 02:29:08)
【毎日開催】
15記事にいいね！で1ポイント
© Rakuten Group, Inc.
