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やアスペクト指向といったソフトウェア開発論がありますが、実装まで見えてこないのはその開発にあてはまらないからだと思っています。
様々な方法論がある中で、必要な場面や設計の深さなどを判断して、開発がスムーズに行く方法論を見極めることが大切だと感じました。
お気に入りの記事を「いいね！」で応援しよう
【毎日開催】
15記事にいいね！で1ポイント
© Rakuten Group, Inc.
