「プログラム設計技術」 · 2 概要...

1

「プログラム設計技術」「プログラム設計技術」--ソフトウェアの要求定義から設計までソフトウェアの要求定義から設計まで--

20062006年年1111月月2255日日

玉井玉井 哲雄哲雄

((東京大学大学院総合文化研究科）東京大学大学院総合文化研究科）

「経営情報学会 情報システム工学研究部会」

2

概要概要

ソフトウェアプロセスソフトウェアプロセス

要求分析要求分析

モデル化技術モデル化技術

オブジェクト指向モデルオブジェクト指向モデル

アーキテクチャ設計アーキテクチャ設計

「酒屋問題」を例として要求分析から設計まで「酒屋問題」を例として要求分析から設計までの流れを解説するの流れを解説する

3

ソフトウェアプロセスソフトウェアプロセス

4

プロセスとプロダクトプロセスとプロダクト

プロダクトプロダクト：： 中間製品を含めたすべ中間製品を含めたすべての生産物ての生産物プロセスプロセス：： プロダクトを産み出す工程プロダクトを産み出す工程

ソフトウェアの開発プロセスを単にソソフトウェアの開発プロセスを単にソフトウェアプロセスという．フトウェアプロセスという．

5

ソフトウェアのライフサイクル・モデルソフトウェアのライフサイクル・モデル

標準的なソフトウェア開発手順を定標準的なソフトウェア開発手順を定め開発作業をガイドめ開発作業をガイド

開発プロジェクトの管理モデルとして開発プロジェクトの管理モデルとして使用使用

開発方法論，ツールと開発環境，文開発方法論，ツールと開発環境，文書体系などを定める基盤書体系などを定める基盤

6

ライフサイクル・モデルライフサイクル・モデル

落水型ライフサイクル・モデル落水型ライフサイクル・モデル

分析

設計プログラミング

テスト

運用保守

7

VV--モデルモデル

分析

設計

プログラミング

単体テスト

運用保守

システムテスト

受入れテスト

8

落水型モデルの強調点落水型モデルの強調点

フェーズ間の明確な区切りときちんとフェーズ間の明確な区切りときちんとした文書による受け渡しした文書による受け渡し

フェーズの手戻りの 小化フェーズの手戻りの 小化

管理のし易さ管理のし易さ

9

他のライフサイクル・モデル他のライフサイクル・モデル

プロトタイピング型モデルプロトタイピング型モデル

逐次進化型モデル逐次進化型モデル

再利用モデル再利用モデル

並行開発プロセス並行開発プロセス((concurrent engineering)concurrent engineering)

軽快な軽快な((agile)agile)プロセスプロセス極端極端((extreme)extreme)プログラミングプログラミング((XP)XP)

10

プロトタイピング型モデルプロトタイピング型モデル

分析

設計プログラミング

テスト

運用保守

プロトタイピング

11

逐次進化型モデル逐次進化型モデル

分析

設計プログラミング

テスト

運用保守

12

極端プログラミング（極端プログラミング（XPXP））

ソフトウェア公開の予定をまず決め，それに従っソフトウェア公開の予定をまず決め，それに従って開発計画設定て開発計画設定

公開は小さな単位で頻繁に公開は小さな単位で頻繁に

開発プロジェクトを小さい作業の繰り返しに分割開発プロジェクトを小さい作業の繰り返しに分割

まずテストケースを作る．テストケースまずテストケースを作る．テストケース==仕様仕様

再構成再構成((refactoringrefactoring))の徹底の徹底

13

プロセスの評価プロセスの評価

プロセスの成熟度評価モデルプロセスの成熟度評価モデルSESE--CMM (Capability Maturity Model for CMM (Capability Maturity Model for Software)Software)

CMUCMU--SEISEIで開発で開発

元来は米国国防省のソフトウェア調達先の評元来は米国国防省のソフトウェア調達先の評価用モデル価用モデル

CMMICMMIに統合に統合

ISOISOにおけるプロセスモデルの標準化におけるプロセスモデルの標準化

14

何を作るか？何を作るか？-- 要求分析要求分析 --

15

要求工学要求工学

システムシステム//ソフトウェアへの要求を系統的ソフトウェアへの要求を系統的に抽出し，整理し，定義し，分析し，追跡に抽出し，整理し，定義し，分析し，追跡する方法する方法

19701970年代半ばに提唱年代半ばに提唱

19901990年代半ば年代半ばからから要求工学国際会議要求工学国際会議20042004年に京都で開催年に京都で開催

16

要求分析の考え方要求分析の考え方

要求抽出型要求抽出型

要求を持つユーザの存在を仮定要求を持つユーザの存在を仮定

代表的な手法代表的な手法: : シナリオ作成シナリオ作成

○○顧客指向顧客指向 ×散漫になりがち×散漫になりがち

ニーズ

意図 要求抽出

17

要求分析の考え方（２）要求分析の考え方（２）

目標指向型目標指向型

システム開発が目指す目標を展開しシステム開発が目指す目標を展開していく．ていく．

○○系統的，系統的， ×目標に特化した解×目標に特化した解

目標 目標木 要求

分解統合

葉の収集

18

要求分析の考え方（３）要求分析の考え方（３）

領域モデル型領域モデル型

対象領域を写像してモデルを作る．対象領域を写像してモデルを作る．

オブジェクト指向モデルなどを使用オブジェクト指向モデルなどを使用

○○要求変化に柔軟，×システムイメー要求変化に柔軟，×システムイメージが見えにくいジが見えにくい

モデル問題領域対象世界

写像

19

酒屋倉庫管理の目標展開酒屋倉庫管理の目標展開

在庫コストの減少在庫コストの減少顧客満足度の向上顧客満足度の向上

迅速な出荷迅速な出荷

在庫切れ在庫切れ防止防止

過剰在庫過剰在庫の圧縮の圧縮

入庫後入庫後即時登録即時登録

在庫状況の在庫状況の正確な把握正確な把握

速やかな速やかな出庫指示出庫指示

商品の滞留商品の滞留時間短縮時間短縮

出荷間違い出荷間違いの防止の防止

多様な銘柄多様な銘柄の仕入れの仕入れ

商品の商品の品質維持品質維持

よい商品よい商品よい注文対応よい注文対応 -

先入れ先入れ先出し先出し

-

20

要求の種類要求の種類

機能要求機能要求

非機能要求非機能要求性能性能

使いやすさ使いやすさ

安全性安全性((security)security)

保守性保守性

可搬性可搬性((portability)portability)

組織文化，法律などからくる制約組織文化，法律などからくる制約

21

要求仕様要求仕様

要求を厳密に定義，記述したもの要求を厳密に定義，記述したもの

通常は形式的通常は形式的//非形式的言語表現非形式的言語表現

「いかに「いかに((how)how)」」でなく「なにをでなく「なにを((what)what)」」

22

仕様記述の難しさ仕様記述の難しさ

対象とする問題領域の非論理性対象とする問題領域の非論理性

ユーザが要求を意識していないか，表現ユーザが要求を意識していないか，表現できないできない

開発者が，ユーザの言葉を理解できない開発者が，ユーザの言葉を理解できない

利害関係者の多さ利害関係者の多さ

ユーザの意図や外部条件が変化するユーザの意図や外部条件が変化する

対象となる問題領域が大きく複雑すぎ対象となる問題領域が大きく複雑すぎて，記述方法が分からないて，記述方法が分からない

23

仕様を読む人仕様を読む人

ソフトウェアの発注者，ソフトウェアの発注者，利用者利用者，操作者，操作者

ソフトウェアの開発者ソフトウェアの開発者

検査者検査者

書く人は？書く人は？開発者が利用者に聞きながら，また開発者が利用者に聞きながら，また

資料を分析して，記述することが多い資料を分析して，記述することが多い

24

モデル化技術モデル化技術

25

モデル化技術モデル化技術

モデルとはモデルとは

構造を持った対象を，その性質や動作構造を持った対象を，その性質や動作を理解するために抽象化したものを理解するために抽象化したもの

モデル構築の目的モデル構築の目的

対象世界（領域）の把握対象世界（領域）の把握 →→ 分析分析

開発するシステムの表現開発するシステムの表現 →→ 要求仕様要求仕様

26

UMLUML記法記法

Unified Modeling LanguageUnified Modeling Language

G. G. BoochBooch, J. , J. RumbaughRumbaugh の合流にの合流にI. JacobsonI. Jacobsonが後から参加が後から参加

19951995年年55月月 Unified Method (Unified Method (暫定版）暫定版）

19971997年年1111月月 OMGOMGよりよりUML1.1UML1.1

20032003年年33月月 UML1.5UML1.5

新版新版 UML2.0 UML2.0 (2004(2004年年1010月月))

27

UMLUMLの位置付けの位置付け

オブジェクト指向モデル記述言語オブジェクト指向モデル記述言語

これまでの分析や設計ノウハウを図これまでの分析や設計ノウハウを図を中心に集大成を中心に集大成

グラフ構造を持つモデル表現法のカグラフ構造を持つモデル表現法のカタログタログ

28

UMLUMLの図式の図式

ユースケース図ユースケース図

クラス図クラス図

振舞い図振舞い図状態図状態図

活動図活動図

系列図系列図

協調図協調図

実装図実装図コンポーネント図コンポーネント図

配備図配備図

29

共通問題共通問題ーー酒屋問題酒屋問題

ある酒類販売会社の倉庫では，毎日数個のコンテナが搬入されてくる．その内容はビン詰めの酒で，1つのコンテナには10銘柄まで混載できる．扱い銘柄は約200種類ある．倉庫係は，コンテナを受け取りそのまま倉庫に保管し，積荷票を受付係へ手渡す．また受付係からの出庫指示によって内蔵品を出庫することになっている．内蔵品は別のコンテナに詰め替えたり，別の場所に保管することはない．空になったコンテナはすぐに搬出される．

積荷票: コンテナ番号(5桁)搬入年月，日時内蔵品名，数量(の繰り返し)

30

さて受付係は毎日数十件の出庫依頼を受け，その都度倉庫係へ出庫指示書を出すことになっている．出庫依頼は出庫依頼票または電話によるものとし，1件の依頼では，1銘柄のみに限られている．在庫がないか数量が不足の場合には，その旨依頼者に電話連絡し，同時に在庫不足リストに記入する．また空になるコンテナを倉庫係に知らせることになっている．倉庫内のコンテナ数はできる限り 小にしたいと考えているからである．

出庫依頼: 品名，数量送り先名

31

受付係の仕事(在庫なし連絡，出庫指示書作成および在庫不足リスト作成)のための計算機プログラムを作成せよ．

出庫指示書： 注文番号送り先名コンテナ番号品名，数量 (の繰り返し)空コンテナ搬出マ－ク

在庫不足リスト: 送り先名品名，数量

• なお移送や倉庫保管中に酒類の損失は生じない．• この課題は現実的でない部分もあるので，入力

データのエラー処理などは簡略に扱ってよい．

32

酒屋問題の全体文脈図酒屋問題の全体文脈図

依頼者

倉庫係

受付係

コンテナ空コンテナ

注文品

積荷票出庫指示書

空予定コンテナ

在庫不足リスト不足連絡

出庫依頼書

33

オブジェクト指向モデルオブジェクト指向モデル

34

オブジェクト指向分析オブジェクト指向分析//設計設計

オブジェクトとオブジェクト間の静的・オブジェクトとオブジェクト間の静的・動的関係を捉える．動的関係を捉える．

分析→設計→実装が継ぎ目な分析→設計→実装が継ぎ目なしし((seamless)seamless)に進むことを唱に進むことを唱うう．．

種々の図式表現の提案種々の図式表現の提案→→ UML(Unified Modeling Language)UML(Unified Modeling Language)に統合の方向に統合の方向

35

オブジェクト指向の源流オブジェクト指向の源流

シミュレーション（シミュレーション（SIMULA67)SIMULA67)

抽象データ型抽象データ型((CLU(1976), Alphard(1976), CLU(1976), Alphard(1976), EUCLID(1977))EUCLID(1977))

知識表現（フレーム知識表現（フレーム(1975)(1975)，，KRL(1977)KRL(1977)，，KLKL--ONE(1985))ONE(1985))

意味データモデル（意味データモデル（ER(1976))ER(1976))

動的プロセスモデル（動的プロセスモデル（ACTOR(1977))ACTOR(1977))

マルチメディア（マルチメディア（Smalltalk(1977))Smalltalk(1977))

36

オブジェクトの抽象化オブジェクトの抽象化

カプセル化カプセル化静的な特性静的な特性((属性，状態属性，状態))と動的な特性と動的な特性((動作，操動作，操作，メッセージ受発信作，メッセージ受発信))を単位化を単位化

情報隠蔽情報隠蔽

クラス階層クラス階層汎化汎化//特化特化((継承継承))

クラスクラス//インスタンスインスタンス

多相性（ｐｏｌｙｍｏｒｐｈｉｓｍ）多相性（ｐｏｌｙｍｏｒｐｈｉｓｍ）

オブジェクト間の関係オブジェクト間の関係静的関係：静的関係： 集約，関連集約，関連

動的関係：動的関係： メッセージ交換メッセージ交換

37

統合統合プロセス（プロセス（Unified ProcessUnified Process））

UMLUMLを記法とした開発プロセスを記法とした開発プロセス

I. JacobsonI. Jacobsonのユースケース法を中心のユースケース法を中心ににOMTOMTややBoochBooch法を統合法を統合

ユースケース重視はある意味で機能ユースケース重視はある意味で機能要求に基づくモデル化への回帰．そ要求に基づくモデル化への回帰．それだけに実践的．れだけに実践的．

38

統合プロセスの概要統合プロセスの概要

ユースケースユースケースの記述の記述

クラスの同定クラスの同定

クラス図の作成クラス図の作成

協調関係の記述協調関係の記述

状態遷移図の作成状態遷移図の作成

パッケージ化パッケージ化

39

ユースケースユースケース

II．．JacobsonJacobsonが提唱した手法が提唱した手法UMLUMLでも採用でも採用

ユースケースとは利用者がシステムを使ユースケースとは利用者がシステムを使う際のシナリオう際のシナリオ

ユースケースとそれを使う役割（アクタ）のユースケースとそれを使う役割（アクタ）の関係を示すのがユースケース図関係を示すのがユースケース図

要求を分析し，必要なオブジェクトを定め要求を分析し，必要なオブジェクトを定めるために用いる．るために用いる．

40

注文受付

在庫不足

コンテナ搬入

出庫指示

倉庫係

受付係

アクタ

ユースケース

《include》

《include》

ユースケース図

《extend》

41

ユースケース（２）ユースケース（２）

記述項目記述項目ユースケース名ユースケース名

アクタアクタ

事前条件事前条件

基本系列基本系列

事後条件事後条件

代替系列代替系列

42

クラスの同定クラスの同定

インターフェース・クラスインターフェース・クラスアクタとシステムのインターフェースアクタとシステムのインターフェース

実体クラス実体クラスひとまとまりのデータを包含するものひとまとまりのデータを包含するもの

制御クラス制御クラスユースケースを実行するための制御ユースケースを実行するための制御

的役割を果たすもの的役割を果たすもの

43

クラス図クラス図所有者

氏名年令住所

自動車

モデル年式

トラック

積載量

乗用車

何人乗り

エンジン

排気量

車体

サスペンション方式

車輪

直径

1

＊

１

1

＊

関連

(association)

集約

(aggregation)汎化

(generalization)

1

多重度

１

44

酒屋問題のユースケース図酒屋問題のユースケース図

コンテナ搬入

在庫不足

出庫指示

注文受付

<<include>>

<<include>>

<<extend>>

倉庫係

受付係

45

酒屋問題酒屋問題ユースケース名：コンテナ搬入ユースケース名：コンテナ搬入

アクター：倉庫係，受付係アクター：倉庫係，受付係事前条件：事前条件：基本系列：基本系列：

1.1. 倉庫係は，搬入されたコンテナの内容と積荷票を倉庫係は，搬入されたコンテナの内容と積荷票を照合し，積荷票を登録する．照合し，積荷票を登録する．

2.2. システムは，在庫不足として登録されている注文システムは，在庫不足として登録されている注文で，この入荷により在庫不足が解消されたものがあで，この入荷により在庫不足が解消されたものがあれば，それを受付係に知らせる．れば，それを受付係に知らせる．

3.3. 在庫不足が解消された注文があれば，受付係はそ在庫不足が解消された注文があれば，受付係はそれらにつき出庫指示ユースケースを実行する．れらにつき出庫指示ユースケースを実行する．

事後条件：事後条件： 搬入されたコンテナの持つ内蔵品のデータ搬入されたコンテナの持つ内蔵品のデータが，参照可能である．出庫があった場合は，それに応が，参照可能である．出庫があった場合は，それに応じて在庫データが更新されている．じて在庫データが更新されている．

46

ユースケース名：注文受付ユースケース名：注文受付

アクター：アクター： 受付係受付係

事前条件：事前条件：

基本系列：基本系列：

1.1. 受付係は，顧客から注文を受ける．受付係は，顧客から注文を受ける．

2.2. 受付係は，その注文についての在庫状況をシステムに問い受付係は，その注文についての在庫状況をシステムに問い合わせる．合わせる．

3.3. システムは注文に応ずることができる在庫があることを受付システムは注文に応ずることができる在庫があることを受付係に伝える．係に伝える．［代替系列］［代替系列］ 在庫が不足している場合は，在庫不足ユース在庫が不足している場合は，在庫不足ユースケースへケースへ

4.4. 受付係は，この注文につき出庫指示ユースケースを実行す受付係は，この注文につき出庫指示ユースケースを実行する．る．

事後条件：事後条件： 出庫に応じて在庫データが更新されている．出庫に応じて在庫データが更新されている．

47

ユースケース名：出庫指示ユースケース名：出庫指示

アクター：アクター： 受付係，倉庫係受付係，倉庫係

事前条件：事前条件： 当該の注文に対して在庫が存在する．当該の注文に対して在庫が存在する．

基本系列：基本系列：

1.1. 受付係はシステムに出庫指示書を作成するよう指受付係はシステムに出庫指示書を作成するよう指示する．示する．

2.2. システムは出庫指示書と，空きコンテナが生じる場システムは出庫指示書と，空きコンテナが生じる場合はその空きコンテナ番号を，倉庫係に示す．合はその空きコンテナ番号を，倉庫係に示す．

3.3. システムは，在庫データを更新する．システムは，在庫データを更新する．

事後条件：事後条件： 出庫に応じて在庫データが更新されてい出庫に応じて在庫データが更新されている．る．

48

ユースケース名：在庫不足ユースケース名：在庫不足

アクター：アクター： 受付係受付係

事前条件：事前条件： 指定された注文の在庫が不足している．指定された注文の在庫が不足している．

基本系列：基本系列：

システムは注文に応じた在庫がないことを受付係システムは注文に応じた在庫がないことを受付係に知らせる．に知らせる．

受付係は，顧客に在庫不足連絡を行う．受付係は，顧客に在庫不足連絡を行う．

システムはこの注文を，在庫不足により未出荷でシステムはこの注文を，在庫不足により未出荷であるものとして登録する．あるものとして登録する．

事後条件：事後条件： 当該注文が在庫不足で未出荷であることが当該注文が在庫不足で未出荷であることが登録されている．登録されている．

49

酒屋問題のクラス図酒屋問題のクラス図受付

注文受付（注文）在庫不足注文の検索（品名）：注文の集合

倉庫

コンテナ登録在庫充足？（注文）：論理値出庫指示（注文）：出庫指示書，空コンテナ

注文

受付年月日品名数量納入年月日受付状況：在庫不足／在庫あり／出庫済み

在庫不足登録（　）出庫済登録

顧客

住所名前

在庫不足連絡（注文）

コンテナ

搬入年月日時

在庫確認（品名）：数量出庫指示（品名，数量）搬出可能？：論理値

内蔵品

品名数量

1 1

1 保管する

*

1積荷内容

**

1

*

1

注文者

50

注文受付（在庫有りの場合）の系列図注文受付（在庫有りの場合）の系列図受付 倉庫 コンテナ 注文

注文受付（注文）

在庫充足？（注文）集計

在庫確認（注文. 品名）

数量

…

充足

出庫指示（注文）

出庫指示書，空コンテナ

在庫更新

出庫指示（品名，数量）

…

出庫済登録

51

注文の状態遷移図注文の状態遷移図

在庫確認中

受付済み

出庫待ち

在庫確認済み[在庫有り]

出庫済み

出庫完了

記録抹消

在庫不足中

コンテナ搬入

在庫確認済み[在庫無し]

52

アーキテクチャ設計アーキテクチャ設計

53

酒屋問題のアーキテクチャ酒屋問題のアーキテクチャ

問題：問題： 入庫情報はコンテナ単位入庫情報はコンテナ単位注文は品目単位注文は品目単位

アーキテクチャ設計上の判断アーキテクチャ設計上の判断

情報をコンテナ単位に保持．品目単情報をコンテナ単位に保持．品目単位のデータは必要に応じ抽出位のデータは必要に応じ抽出

情報を品目単位に保持．コンテナが情報を品目単位に保持．コンテナが入庫するたびに，それを品目単位に入庫するたびに，それを品目単位に変換変換

54

酒屋問題のクラス図酒屋問題のクラス図受付

注文受付（注文）在庫不足注文の検索（品名）：注文の集合

倉庫

コンテナ登録在庫充足？（注文）：論理値出庫指示（注文）：出庫指示書，空コンテナ

注文

受付年月日品名数量納入年月日受付状況：在庫不足／在庫あり／出庫済み

在庫不足登録（　）出庫済登録

顧客

住所名前

在庫不足連絡（注文）

コンテナ

搬入年月日時

在庫確認（品名）：数量出庫指示（品名，数量）搬出可能？：論理値

内蔵品

品名数量

1 1

1 保管する

*

1積荷内容

**

1

*

1

注文者

55

注文受付（在庫有りの場合）の系列図注文受付（在庫有りの場合）の系列図受付 倉庫 コンテナ 注文

注文受付（注文）

在庫充足？（注文）集計

在庫確認（注文. 品名）

数量

…

充足

出庫指示（注文）

出庫指示書，空コンテナ

在庫更新

出庫指示（品名，数量）

…

出庫済登録

56

品目クラスの導入品目クラスの導入

57

酒屋問題のクラス図酒屋問題のクラス図品目クラス導入版品目クラス導入版

58

注文受付の系列図注文受付の系列図品目クラス導入版品目クラス導入版