要求とシステムの橋渡しをする umlモデリング · u m l...

要求とシステムの橋渡しをするUMLモデリング

次世代開発フォーラム Winter

2005年12月16日平澤章

Copyright © 2005 Akira HIRASAWA all rights reserved. 2

自己紹介

氏名：平澤章（ひらさわあきら）

勤務先：ウルシステムズ（株） http://www.ulsystems.co.jp

自称：UML使いのコミュニケーション芸人著書：「オブジェクト指向でなぜつくるのか」

（日経BP社、2004年）現在の執筆活動（連載）

：日経ソフトウエア「UMLモデリング・レッスン」ブログ：「UMLモデリングレッスン執筆日誌」

http://d.hatena.ne.jp/ahirasawa/


アジェンダ

要求の整理術としてのUMLモデリングビジネスアプリケーションにおけるUMLの使い所概念モデルの事例紹介

モデリングの落とし穴

まとめ


要求定義 – システム開発で最も難しい仕事の1つ

開発ベンダー側では

仕様が決まらない。→スケジュール遅れ

後半段階で大きな仕様変更が入る。→コスト増大

顧客側では

“画面レイアウトを中心に仕様を決めたが、例外系のビジネスルールを伝えたら、仕様追加と言われた。”

“分厚い要求仕様書の承認を求められた。スケジュールを優先して、釈然としないまま承認したが、出来上がったシステムは使えない代物だった。”


要求を決められない本質的な理由

本質的なギャップ

臨機応変に進める人間の仕事vs 「論理の固まり」のコンピュータ

多くの企業に存在する独自の暗黙知や特殊用語。

そもそも（人間である）ユーザーが完全無欠な仕様を作ることはできない。

自由な発想をする人間の頭脳

必ずしも厳密ではない言葉

GAP!!


要求の整理術としてのUMLモデリング

論理的に整理する。

明確なセマンティクスを持った図で形式表現する。

可視化する。

直感的に表現する。

“形”で覚える。マインドマップと同様の効果

ソフトウェア設計に円滑に橋渡しする。

概念モデルをデータベース構造に変換する。

業務フローから機能仕様を抽出する。


モデリングセッションで共有する

参加者

モデラー（コーディネータ役）

システムとりまとめ担当者

エンドユーザー

議論の進め方議論の結果をその場でUMLとして整理する。 UMLの図を作りながら議論をナビゲーションする。

成果物

議論中はホワイトボードまたは、模造紙＋付箋紙に記録する。

セッションの後でモデリングツールに入力する。


アジェンダ



まとめ


UML - 統一モデリング言語

Unified Modeling Language 1997年に標準化団体OMGによって採択されたソフトウェア開発図面の標準

多種多様なダイアグラム

UML 1.xで10種類、UML 2.0では13種類のダイアグラム

幅広い適用範囲

設計（論理＆物理）、要求定義、業務分析


UML 2.0のダイアグラム(1)名称用途

1 クラス図クラスの仕様とクラス間の関係を表現する。

2 複合構造図全体－部分構造を持つクラスの実行時の構造を表現する。

3 コンポーネント図ファイルやデータベース、プロセスやスレッドなどのソフトウェアの実装構造を表現する。

4 配置図ハードウェアやネットワークなど、システムの物理構造を表現する。

5 オブジェクト図オブジェクト（インスタンス）間の関係を表現する。

6 パッケージ図パッケージ間の関係を表現する。


UML 2.0のダイアグラム(2)名称用途

7 アクティビティ図一連の処理における制御の流れを表現する。

8 シーケンス図オブジェクト（インスタンス）間の相互作用を時系列に表現する。

9 コミュニケーション図オブジェクト（インスタンス）間の相互作用を構造中心に表現する。

10 相互作用概要図条件によって異なる動作をするシーケンス図を、アクティビティ図の中に含めることで表現する。

11 タイミング図オブジェクト（インスタンス）間の状態遷移や相互作用を時間制約つきで表現する。

12 ユースケース図システムが提供する機能と利用者の関係を表現する。

13 ステートマシン図オブジェクト（インスタンス）の状態変化を表現する。


ビジネスアプリケーションにおけるUMLの使い所(1)

要求定義局面：人間同士のコミュニケーションの補助手段アクティビティ図：仕事の流れを整理する。

ユースケース図：システムで実現する機能を定義する。

クラス図：管理すべきデータ構造を整理する。

（ステートマシン図：モノの状態変化を整理する。）

UML と構造化分析で要求定義でやることは大きく変わらない。アクティビティ図：DFD相当ユースケース図：機能一覧相当

クラス図：ERD相当


ビジネスアプリケーションにおけるUMLの使い所(2)

設計局面：ソフトウェアの設計図パッケージ図：ソフトウェアの全体構造を定義する。

クラス図：クラス構造と役割（責務）を定義する。

シーケンス図：オブジェクトの実行時動作を定義する。（コミュニケーション図）

ビジネスアプリケーションにおける現実的なアプローチ

ロジックが冗長になりやすいプレゼンテーション層や永続層には、実績のあるフレームワークを採用することで、アプリケーション構造の標準化と省力化を図る。

個々のアプリケーションロジックについては、UMLを使った大がかりな設計は省略するアプローチが現実的。


ビジネスアプリケーションはデータ中心

イベントと登場人物を記録する「帳簿のシステム」

ビジネス活動としてのイベント契約、受発注、入出荷、請求、入金、支払、…

ビジネスの登場人物（組織、人、物）顧客、自社組織/社員、商品、在庫、設備、…

コンピュータ

xx情報の登録

xx情報の検索

xx情報の更新

アプリケーション機能の多くは「登録・更新・検索」ばか

り。

データ構造は、ビジネスの特徴を雄弁に表現す

る。


UMLによる概念モデリング

クラス図を使って「管理すべき情報の構造」を表現する

本質的にビジネスアプリケーションは「データ中心」

「概念」を表現する。

「管理すべき情報の単位」を明確にする。

それをズバリと表現する名前をつける。


概念モデリングの効果

システムがわかる

データ構造を理解することで、表面的な機能だけでなく、システムの本質的な仕様を理解できる。

ビジネスがわかる

データ構造には、現実世界の様子や企業の戦略が反映される。

設計の準備ができる。

データベースの概念設計の成果物としてそのまま利用できる。


概念モデリングの基本

データ構造の表現に注力する。

メソッドは考慮せず、属性と関連で表現する。

集合論で整理する。

クラスは集合、継承は全体/部分集合と解釈する。カプセル化やポリモーフィズムなどのオブジェクト指向プログラミングのメカニズムについては、ソフトウェア構造を考える段階（＝設計）まで先送りする。


概念モデリングの三大要素

クラス

クラスは集合、インスタンスは集合の要素

関連

集合の要素同士の結びつき

継承

全体集合と部分集合


概念モデリングの三大要素1：クラス

同様の性質を持つ情報の集まり（集合）を「クラス」として表現する。

必要に応じて、そのクラスを特徴づける重要な属性を記述する。

概念モデリングの段階ではメソッドは考えない。

取引先

（株）成長工業

・・・

(株)満腹食堂

豪邸建設(株)

零細商事(有)


概念モデリングの三大要素2：関連

「インスタンス」（集合の要素）同士の結びつきを「関連」として表現する。

結びつく要素数の規則（＝多重度）を明確にする。

取引先

(株)成長工業

・・・

(株)満腹食堂

豪邸建設(株)

(有)零細商事

営業職

敏腕一郎

・・・

懐広志

才色麗子

(有)衛生食品

担当する


全体集合、部分集合の関係を「継承」として表現する。

概念モデリングの三大要素3：継承

営業職

敏腕一郎

・・・

懐広志

才色麗子

技術職

・・・

本懐一郎

職人肌富夫

秋葉萌恵

社員


概念モデリングに現れるお決まりのパターンイベントと主体

イベントと在庫

イベントと場所

全体と部分

イベントと対象

分類と対象

全体集合と部分集合

グループとメンバー主体と対象

これらのパターンについては日経ソフトウエア誌の連載「UMLモデリング・レッスン」で解説しています！


アジェンダ



まとめ


事例(1) 自動車ディーラー

新車の場合、販売時は「販売車種（＝種類）」で、納車後は「車両（＝モノ）」で管理する。

同じ車名でも、装備のバリエーションにより、管理すべき販売車種の数は非常に多い。（人気車種だと数十万以上の組み合わせがある。）


事例(2) 人材派遣

契約は派遣スタッフと企業それぞれと締結する。

契約は短期契約でバリエーションが多い。

スキルをもとにして、仕事とスタッフのマッチングを行う。しかし実際は…


事例(3) 損害保険の商品仕様損害保険は特約のバリエーションが多種多様である。同じ「特約」と呼ぶものでも、大きく性質が異なるものを含んでいる。

システム的に複雑なのは、商品仕様と契約、保険料計算ロジックに集中する。保険料支払いは、人手による判断が入るため、システムが提供する機能は比較的シンプルとなる。


アジェンダ



まとめ


モデリングの落とし穴(1)アプリケーションの議論をおろそかにする

症状

アプリケーション仕様よりも、モデルの表現方法の議論に熱中してしまう。

対処法

モデリングは、あくまでも要求を整理する道具と割り切る。


モデリングの落とし穴(2)アナリシスパターンに心酔してしまう

症状「アナリシス・パターン」（マーチン・ファウラー著）に登場する概念やパターンを不適切な場面で多用する。知識レベルと操作レベル

動的分類と多重分類

パワータイプ

責任関係、観測と測定、…

対処法それらの概念やパターンを採用することで、出来上がったシステムの保守性が実際に向上するかどうかを評価基準にする。


モデリングの落とし穴(3)概念モデルを神の作品にしてしまう

症状

有識者やモデラーが作った概念モデルを神格化してしまい、後から参加したメンバーが変更できなくなる。

対処法

有識者やモデラーも人の子であり、思い違いや考慮漏れをすることもある、と割り切る。


アジェンダ

要求の整理術としてのUMLモデリングビジネスアプリケーションにおけるUMLの使い所概念モデル事例紹介


まとめ


モデラーに必要なスキル

1. 論理的思考能力ヒアリングした情報を集合論で整理するスキル

2. コミュニケーション能力セッションを盛り上げるスキル

焦点をブレさせずに議論を仕切るスキル

3. ソフトウエア開発力データベース構造をイメージできる技術力

作り込むソフトウェアの複雑さをイメージできる技術力


上流工程の技術者として活躍しよう！

UMLモデリングを身につけて、ユーザー要求とコンピュータシステムの橋渡しをしよう！

要求とシステムの橋渡しをする umlモデリング · u m l...

Documents