UMLの導入を成功させるためには
株式会社オージス総研
組み込みソリューション部
渡辺 博之

1

はじめに
この資料は、UMLの導入をこれから進めていくことが決まっている どうしようか迷っている とても無理だと思っている

方々に対して、弊社の今までの支援事例から、お役に立ちそうなポイントをピックアップしたものです。
少しでもヒントになることがあれば幸いです。
21

目次
UMLとオブジェクト指向
UML導入のロードマップ
UML導入のポイント
事例紹介

3

UMLとオブジェクト指向

4

2

両者の違いUML
オブジェクト指向を前提としたモデリング言語
 考えたことを表現するためのツール 図の読み方や書き方
 覚えて慣れることが大事

オブジェクト指向
考えるためのツール
 ものの見方や考え方
 使いこなすには、それなりの経験が必要→ オブジェクト指向を理解しないとUMLは使えない？
5

オブジェクト指向とは？
ソフトウェアの開発技術のひとつ
大きく、以下の2つの特徴がある

複雑なものを整理して分かり易くする
 主として、分析段階で利用できる技術ソフトウェアを部品化しやすい 主として、設計・実装段階で利用できる技術

63オブジェクト指向で「分かり易くなる」しくみ
オブジェクト指向の考え方

単純なもの

構造で考える分ける
複雑なことつながりを考える

抽象化する

単純なもの

単純なもの

「構造で考え」「抽象化する」ことで「分かり易くなる」
7

例：待ち合わせたかし君は１４：００にひろし君、ごろう君と公園で、16:00にはゆかりちゃんと図書館で待ち合わせをしています

84

例：待ち合わせ構造で考える
ひろし君
:人

構成要素
構成要素

ひろし君
約束する

関係

約束する １４：００ 約束する

たかし君

: 待ち合
わせ

ごろう君

公園

約束する

たかし君
:人

１６：００

モデルにすると…

ご ろう君 :人

時刻：14:00
場所：公園
: 待ち合
わせ
時刻：16:00
場所：図書館

図書館
約束する

ゆかりちゃん:人

インスタンス図

ゆかりちゃん9

例：待ち合わせ抽象化する概念

待ち合わせ時間場所

モデルにすると…

約束する

待ち合わせ- 時刻- 場所

人
2..*

人概念

待ち合わせを人の間に交わされる約束として考える。

0..n２人以上が必要

クラス図

105

これって、結構むずかしい!?
本質を見つけることの難しさ


構造的に考えたり、抽象化することは苦手な人が多い

西洋人と東洋人の思考の違い（注1） ？


西洋人は「分析的思考」かつ「単純さ」を好む
 対象そのものの属性に目を向け、カテゴリーに分類すること

で対象を理解する
 すべてのものは「モデルとして単純化できる」と考える


東洋人は「包括的思考」かつ「複雑さ」を仮定する
 対象をとりまく「場」全体に注意を払い、個々の対象ではなく、対象とさまざまな場の要素との関係を重視する
 世界は「モデルで説明できるほど単純ではない」と思っている
問 ： 次の３つのうち、仲間はずれはどれですか？ ｛パンダ、サル、バナナ｝
注1：「木を見る西洋人 森を見る東洋人」 リチャード・E・ニスベット著 （ダイヤモンド社）より

11

UML導入のロードマップ

126

UMLとオブジェクト指向の習熟曲線
UMLの方が、圧倒的に立ち上がりが早い
UML

習得度合い
オブジェクト指向
2〜3ヶ月

期間
13

UMLで期待できる効果
モデルベースの工学的な開発
作ろうとするモノの仕様がきちんと表現されている
 その結果、誰がいつ作っても同じものができる


それによりもたらされる、品質の向上と期間の短縮
ソフトウェアの内部が見える
 早い段階で間違いを修正できる

147

従来型の実装中心の開発
仕様が違う!!!
もっといいやり方があるのに!!!
細かすぎてよくわからない!!!
頭の中にあるアイディア

個人個人による検討
ソースコード手戻りの多発うまくつながらない!!!
15

モデルベースの開発
考え方や設計方針をレビュー

モデルに反映UseCase#1

頭の中にあるアイディア

user
UseCase#2
:E

E
1

2:

1..nA

1:

B
1:A

:C

1..nC

D

UMLにより記述されたモデル

頭の中のイメージをモデルで表現

ソースコード168

効果的なUML導入プラン
抽象的（全体視点で要点が理解し易い）
ステップ3

ステップ2
モデル開発による品質・ 生産性の向上が期待できるモデル開発によるメリットに加え、オブジェクト指向による部品化が可能

オブジェクト指向によるモデル開発

モデル開発
いきなりこのステップは難しい

MDA

汎用性なし

汎用性あり

ステップ1
実行可能なモデル開発
MDA
理解しにくく品質・効率共に問題を抱える

機能分割によるソースコード開発

オブジェクト指向によるソースコード開発

これだけだと理解しにくく、大規模になるにつれ品質・効率に問題発生

具象的（正確だが詳細すぎて分かり難い）
17

ステップ1：モデル開発への移行モデルで議論する文化の形成
「作った結果」ではなく、「作ろうとするモノ」をモデルで表し、議論できるモデルは使い捨てでよい
理解し、議論するためにモデルを使う
 最終的なソースを作るためのスケッチでよい

オブジェクト指向よりも、まずは考えを早期に形にすることが大事

モデルの構成要素はオブジェクトでなくても可 ソース単位、関数単位もアリ

対象を分割し、その塊同士の協調を議論することで、モデルの抽象度が上がり、全体の品質が向上する
18

9

ステップ2：オブジェクトを使った構造へ
モデルの中身を、よりわかりやすく、かつ変化に強い構造にする

対象を「構造で考え」て「オブジェクト」に分割していく キーは、「凝集度の高さ」と「結合度の低さ」
 複雑なものは「一人で全部面倒見る」のではなく「それぞれの専門家に任せる」発想へ

概念化にはそれほどこだわらない 同じようなクラスがあっても構わない

その結果として、保守性の向上、知識の局所化をめざす
機能追加や修正の影響が一部でとどまる
 各専門家による並行開発がやり易い

19

ステップ3：クラスによる抽象化
モデルの中身を、より汎用性の高い、かつシンプルな構造にする

対象を「概念化」して「クラス」にまとめる
 キーは「抽象的」な考え方
 同じようなオブジェクトは同じ概念として１つの「クラス」にする

コード量が減り、保守性・再利用性が向上する
機能追加や修正の影響がより局所化する
 クラスを利用した差分開発が可能になる


20

10

各ステップへの移行タイミング
プロジェクト期間中に移行できると理想的分析/設計
要求

初期の計画立案
計画立案

実装
反復の度に、実行可能な成果物がリリースされる

テスト

評価

導入
ステップ1
ステップ2
ステップ321

UML導入のポイント

22

11

UML導入のポイント 開始前

問題を共有する

現在の開発スタイルの問題点をメンバー全員で共有する

目的を明確にする


UMLを導入することで何を得たいのかを明らかにする
 ロードマップを参照

23

UML導入のポイント 運営

早期の非公式レビューが重要
これこそが、モデル開発のメリット
 早い時期に頻繁にレビューして、間違いや無駄な検討にかかるコストをなくす 作ろうとするものの理解や考え方をチーム内で共有する
 メンバー同士の技術的な成長やシナジーも期待できる


24

12

UML導入のポイント モデリング

基本は3つのモデルの使い分け

何をやりたいのか？
 ユースケースモデル

そのためには、どんなものが必要か？
 クラス図、オブジェクト図

やりたいことを実現するには、何（＝オブジェクト）をどんな順番で動かせばよいのか？
 相互作用図（ユースケース単位に作成）

25

UML導入のポイント モデリング

3つのモデルの使い分け:E

ユースケースモデル「何をやりたいのか？」2:
1::A:C

相互作用図「何をどう動かして仕事を進めるのか？」#機能（=ユースケース）ごとに書く

UseCase#1

2:

user
UseCase#2

1:

E

クラス図
「どんなものが必要か？」:A:D

11..nAB
11..nC

D26

13

UML導入のポイント モデリング

組み込みに必要な＋2 のモデル


オブジェクト内部はどのように動いているのか？
 状態図
 システム全体や動作が複雑なクラスについて書くシーケンスやアルゴリズムをどうするか？
 アクティビティ図
 複雑な手続きや制御手順、アルゴリズムについて書く

27

UML導入のポイント モデリング

異なるモデルを交互に作る

特定のモデルだけに時間をかけない 特にクラス図
 ある程度できたら、異なる視点から検討する

たとえば・・・クラス図と相互作用図
 ある程度の構造が決まったら、オブジェクトの使い方（相互作用図）を検討してみる
 その結果、不要なオブジェクトや足りないオブジェクトが明確になる → クラス図への反映

2814

UML導入のポイント モデリング
実装方法の詳細はモデル化しない「やりたいこと」と「どう実装するか」は別の話
 実装方法とは、「モデルを動かす仕組み」
 モデルに仕組みを混在させると、モデルの意味（わかりやすさ）が希薄化
 まずは、「やりたいこと」の検討が必要

例.
イベント送信の仕組が書かれた相互作用図
 状態図の実装方法が定義されたクラス図 デザインパターンが過度に導入されたモデル
29

UML導入のポイント モデリング
最低限のドキュメントは必要
大きくて詳細なモデルは理解しにくい

情報量が多くなると可読性は極端に悪化する
 簡素なモデル > 詳細なモデル > ソースコード

以下の補足ドキュメントは必須


モデルの概要 モデルの大まかな構成や動作の特徴

モデリング指針 なぜこのような構造にしたのか？
 なぜこのような順序で協調するのか？
30

15UML導入のポイント スキル

モデリングのためのスキル

国語力 考えを理解し、言葉にする能力

論理力
 物事を構造的に整理する能力

抽象力
 物事を一般化して本質をとらえる能力

網羅力
 もれぬけなく、矛盾しないように検証する能力

31

UML導入のポイント スキル
ゴールするためのスキル

バランス感覚 過度にモデルを洗練させない あまりに「抽象的」or「詳細すぎる」モデルを書かない
 実際に動かすことが大事

モデルはあくまでもその過程でしかない

コミュニケーションスキル
 モデルによる早期検証を活かすにはこれが必須

自分の意図を伝え、相手の意図を正しく理解する
複数の視点が品質・効率に寄与 コミュニケーションコストを低く抑えることも大事ホワイトボードは必須

32

16

事例紹介

33

半導体製造装置概要
開発対象はウェハ搬送（この装置で一番厄介なところ）
 メンバーは5名、期間は約半年


モデル開発がもたらした効果
新しい制御アルゴリズム（複数ウェハと2つのアーム）に対し、モデルを机上シミュレーションすることで論理的な検証が可能に
 さらに、実装してシミュレーションすることで、ある程度の実時間を検証


34

17

必勝パターン
適用範囲全体ではなく一部への適用
 複雑なところ、厄介なところほど効果的

運営
ドメインエキスパートの継続的な参加
 技術的なリーダー（シップ）の存在
技術UMLはステップ1から段階的に導入
 モデル開発と実装メカニズム開発は別作業
 ツールの使用、ソースはスケルトンまたは手実装
 レビューや勉強会での継続的・日常的なスキルアップ
35

まとめ
UMLは、まず使ってみて、モデル開発のメリットを実感するところから始めましょう
モデルに過度の完璧性を求めないようにしましょう
モデルを作ったら頻繁にレビューしましょう
オブジェクト指向は、ある程度時間をかけて導入していきましょう

36

18