Upload
vokhuong
View
223
Download
0
Embed Size (px)
Citation preview
Copyright © 2005 Akira HIRASAWA all rights reserved. 2
自己紹介
氏名 :平澤 章(ひらさわ あきら)
勤務先 :ウルシステムズ(株) http://www.ulsystems.co.jp
自称 :UML使いのコミュニケーション芸人 著書 :「オブジェクト指向でなぜつくるのか」
(日経BP社、2004年) 現在の執筆活動(連載)
:日経ソフトウエア「UMLモデリング・レッスン」 ブログ :「UMLモデリングレッスン執筆日誌」
http://d.hatena.ne.jp/ahirasawa/
Copyright © 2005 Akira HIRASAWA all rights reserved. 3
アジェンダ
要求の整理術としてのUMLモデリング ビジネスアプリケーションにおけるUMLの使い所 概念モデルの事例紹介
モデリングの落とし穴
まとめ
Copyright © 2005 Akira HIRASAWA all rights reserved. 4
要求定義 – システム開発で最も難しい仕事の1つ
開発ベンダー側では
仕様が決まらない。→スケジュール遅れ
後半段階で大きな仕様変更が入る。→コスト増大
顧客側では
“画面レイアウトを中心に仕様を決めたが、例外系のビジネスルールを伝えたら、仕様追加と言われた。”
“分厚い要求仕様書の承認を求められた。スケジュールを優先して、釈然としないまま承認したが、出来上がったシステムは使えない代物だった。”
Copyright © 2005 Akira HIRASAWA all rights reserved. 5
要求を決められない本質的な理由
本質的なギャップ
臨機応変に進める人間の仕事vs 「論理の固まり」のコンピュータ
多くの企業に存在する独自の暗黙知や特殊用語。
そもそも(人間である)ユーザーが完全無欠な仕様を作ることはできない。
自由な発想をする人間の頭脳
必ずしも厳密ではない言葉
GAP!!
Copyright © 2005 Akira HIRASAWA all rights reserved. 6
要求の整理術としてのUMLモデリング
論理的に整理する。
明確なセマンティクスを持った図で形式表現する。
可視化する。
直感的に表現する。
“形”で覚える。 マインドマップと同様の効果
ソフトウェア設計に円滑に橋渡しする。
概念モデルをデータベース構造に変換する。
業務フローから機能仕様を抽出する。
Copyright © 2005 Akira HIRASAWA all rights reserved. 7
モデリングセッションで共有する
参加者
モデラー(コーディネータ役)
システムとりまとめ担当者
エンドユーザー
議論の進め方 議論の結果をその場でUMLとして整理する。 UMLの図を作りながら議論をナビゲーションする。
成果物
議論中はホワイトボードまたは、模造紙+付箋紙に記録する。
セッションの後でモデリングツールに入力する。
Copyright © 2005 Akira HIRASAWA all rights reserved. 8
アジェンダ
要求の整理術としてのUMLモデリング ビジネスアプリケーションにおけるUMLの使い所 概念モデルの事例紹介
モデリングの落とし穴
まとめ
Copyright © 2005 Akira HIRASAWA all rights reserved. 9
UML - 統一モデリング言語
Unified Modeling Language 1997年に標準化団体OMGによって採択されたソフトウェア開発図面の標準
多種多様なダイアグラム
UML 1.xで10種類、UML 2.0では13種類のダイアグラム
幅広い適用範囲
設計(論理&物理)、要求定義、業務分析
Copyright © 2005 Akira HIRASAWA all rights reserved. 10
UML 2.0のダイアグラム(1)名称 用途
1 クラス図 クラスの仕様とクラス間の関係を表現する。
2 複合構造図 全体-部分構造を持つクラスの実行時の構造を表現する。
3 コンポーネント図 ファイルやデータベース、プロセスやスレッドなどのソフトウェアの実装構造を表現する。
4 配置図 ハードウェアやネットワークなど、システムの物理構造を表現する。
5 オブジェクト図 オブジェクト(インスタンス)間の関係を表現する。
6 パッケージ図 パッケージ間の関係を表現する。
Copyright © 2005 Akira HIRASAWA all rights reserved. 11
UML 2.0のダイアグラム(2)名称 用途
7 アクティビティ図 一連の処理における制御の流れを表現する。
8 シーケンス図 オブジェクト(インスタンス)間の相互作用を時系列に表現する。
9 コミュニケーション図 オブジェクト(インスタンス)間の相互作用を構造中心に表現する。
10 相互作用概要図 条件によって異なる動作をするシーケンス図を、アクティビティ図の中に含めることで表現する。
11 タイミング図 オブジェクト(インスタンス)間の状態遷移や相互作用を時間制約つきで表現する。
12 ユースケース図 システムが提供する機能と利用者の関係を表現する。
13 ステートマシン図 オブジェクト(インスタンス)の状態変化を表現する。
Copyright © 2005 Akira HIRASAWA all rights reserved. 12
ビジネスアプリケーションにおけるUMLの使い所(1)
要求定義局面:人間同士のコミュニケーションの補助手段 アクティビティ図 :仕事の流れを整理する。
ユースケース図 :システムで実現する機能を定義する。
クラス図 :管理すべきデータ構造を整理する。
(ステートマシン図 :モノの状態変化を整理する。)
UML と構造化分析で要求定義でやることは大きく変わらない。 アクティビティ図 :DFD相当 ユースケース図 :機能一覧相当
クラス図 :ERD相当
Copyright © 2005 Akira HIRASAWA all rights reserved. 13
ビジネスアプリケーションにおけるUMLの使い所(2)
設計局面:ソフトウェアの設計図 パッケージ図 :ソフトウェアの全体構造を定義する。
クラス図 :クラス構造と役割(責務)を定義する。
シーケンス図 :オブジェクトの実行時動作を定義する。(コミュニケーション図)
ビジネスアプリケーションにおける現実的なアプローチ
ロジックが冗長になりやすいプレゼンテーション層や永続層には、実績のあるフレームワークを採用することで、アプリケーション構造の標準化と省力化を図る。
個々のアプリケーションロジックについては、UMLを使った大がかりな設計は省略するアプローチが現実的。
Copyright © 2005 Akira HIRASAWA all rights reserved. 14
ビジネスアプリケーションはデータ中心
イベントと登場人物を記録する「帳簿のシステム」
ビジネス活動としてのイベント 契約、受発注、入出荷、請求、入金、支払、…
ビジネスの登場人物(組織、人、物) 顧客、自社組織/社員、商品、在庫、設備、…
コンピュータ
xx情報の登録
xx情報の検索
xx情報の更新
アプリケーション機能の多くは「登録・更新・検索」ばか
り。
データ構造は、ビジネスの特徴を雄弁に表現す
る。
Copyright © 2005 Akira HIRASAWA all rights reserved. 15
UMLによる概念モデリング
クラス図を使って「管理すべき情報の構造」を表現する
本質的にビジネスアプリケーションは「データ中心」
「概念」を表現する。
「管理すべき情報の単位」を明確にする。
それをズバリと表現する名前をつける。
Copyright © 2005 Akira HIRASAWA all rights reserved. 16
概念モデリングの効果
システムがわかる
データ構造を理解することで、表面的な機能だけでなく、システムの本質的な仕様を理解できる。
ビジネスがわかる
データ構造には、現実世界の様子や企業の戦略が反映される。
設計の準備ができる。
データベースの概念設計の成果物としてそのまま利用できる。
Copyright © 2005 Akira HIRASAWA all rights reserved. 17
概念モデリングの基本
データ構造の表現に注力する。
メソッドは考慮せず、属性と関連で表現する。
集合論で整理する。
クラスは集合、継承は全体/部分集合と解釈する。 カプセル化やポリモーフィズムなどのオブジェクト指向プログラミングのメカニズムについては、ソフトウェア構造を考える段階(=設計)まで先送りする。
Copyright © 2005 Akira HIRASAWA all rights reserved. 18
概念モデリングの三大要素
クラス
クラスは集合、インスタンスは集合の要素
関連
集合の要素同士の結びつき
継承
全体集合と部分集合
Copyright © 2005 Akira HIRASAWA all rights reserved. 19
概念モデリングの三大要素1:クラス
同様の性質を持つ情報の集まり(集合)を「クラス」として表現する。
必要に応じて、そのクラスを特徴づける重要な属性を記述する。
概念モデリングの段階ではメソッドは考えない。
取引先
(株)成長工業
・・・
(株)満腹食堂
豪邸建設(株)
零細商事(有)
Copyright © 2005 Akira HIRASAWA all rights reserved. 20
概念モデリングの三大要素2:関連
「インスタンス」(集合の要素)同士の結びつきを「関連」として表現する。
結びつく要素数の規則(=多重度)を明確にする。
取引先
(株)成長工業
・・・
(株)満腹食堂
豪邸建設(株)
(有)零細商事
営業職
敏腕 一郎
・・・
懐 広志
才色 麗子
(有)衛生食品
担当する
Copyright © 2005 Akira HIRASAWA all rights reserved. 21
全体集合、部分集合の関係を「継承」として表現する。
概念モデリングの三大要素3:継承
営業職
敏腕 一郎
・・・
懐 広志
才色 麗子
技術職
・・・
本懐 一郎
職人肌 富夫
秋葉 萌恵
社員
Copyright © 2005 Akira HIRASAWA all rights reserved. 22
概念モデリングに現れるお決まりのパターンイベントと主体
イベントと在庫
イベントと場所
全体と部分
イベントと対象
分類と対象
全体集合と部分集合
グループとメンバー 主体と対象
これらのパターンについては日経ソフトウエア誌の連載「UMLモデリング・レッスン」で解説しています!
Copyright © 2005 Akira HIRASAWA all rights reserved. 23
アジェンダ
要求の整理術としてのUMLモデリング ビジネスアプリケーションにおけるUMLの使い所 概念モデルの事例紹介
モデリングの落とし穴
まとめ
Copyright © 2005 Akira HIRASAWA all rights reserved. 24
事例(1) 自動車ディーラー
新車の場合、販売時は「販売車種(=種類)」で、納車後は「車両(=モノ)」で管理する。
同じ車名でも、装備のバリエーションにより、管理すべき販売車種の数は非常に多い。(人気車種だと数十万以上の組み合わせがある。)
Copyright © 2005 Akira HIRASAWA all rights reserved. 25
事例(2) 人材派遣
契約は派遣スタッフと企業それぞれと締結する。
契約は短期契約でバリエーションが多い。
スキルをもとにして、仕事とスタッフのマッチングを行う。しかし実際は…
Copyright © 2005 Akira HIRASAWA all rights reserved. 26
事例(3) 損害保険の商品仕様損害保険は特約のバリエーションが多種多様である。同じ「特約」と呼ぶものでも、大きく性質が異なるものを含んでいる。
システム的に複雑なのは、商品仕様と契約、保険料計算ロジックに集中する。保険料支払いは、人手による判断が入るため、システムが提供する機能は比較的シンプルとなる。
Copyright © 2005 Akira HIRASAWA all rights reserved. 27
アジェンダ
要求の整理術としてのUMLモデリング ビジネスアプリケーションにおけるUMLの使い所 概念モデルの事例紹介
モデリングの落とし穴
まとめ
Copyright © 2005 Akira HIRASAWA all rights reserved. 28
モデリングの落とし穴(1)アプリケーションの議論をおろそかにする
症状
アプリケーション仕様よりも、モデルの表現方法の議論に熱中してしまう。
対処法
モデリングは、あくまでも要求を整理する道具と割り切る。
Copyright © 2005 Akira HIRASAWA all rights reserved. 29
モデリングの落とし穴(2)アナリシスパターンに心酔してしまう
症状 「アナリシス・パターン」(マーチン・ファウラー著)に登場する概念やパターンを不適切な場面で多用する。 知識レベルと操作レベル
動的分類と多重分類
パワータイプ
責任関係、観測と測定、…
対処法 それらの概念やパターンを採用することで、出来上がったシステムの保守性が実際に向上するかどうかを評価基準にする。
Copyright © 2005 Akira HIRASAWA all rights reserved. 30
モデリングの落とし穴(3)概念モデルを神の作品にしてしまう
症状
有識者やモデラーが作った概念モデルを神格化してしまい、後から参加したメンバーが変更できなくなる。
対処法
有識者やモデラーも人の子であり、思い違いや考慮漏れをすることもある、と割り切る。
Copyright © 2005 Akira HIRASAWA all rights reserved. 31
アジェンダ
要求の整理術としてのUMLモデリング ビジネスアプリケーションにおけるUMLの使い所 概念モデル事例紹介
モデリングの落とし穴
まとめ
Copyright © 2005 Akira HIRASAWA all rights reserved. 32
モデラーに必要なスキル
1. 論理的思考能力 ヒアリングした情報を集合論で整理するスキル
2. コミュニケーション能力 セッションを盛り上げるスキル
焦点をブレさせずに議論を仕切るスキル
3. ソフトウエア開発力 データベース構造をイメージできる技術力
作り込むソフトウェアの複雑さをイメージできる技術力