PowerPoint プレゼンテーション

ソフトウェア工学
Software Engineering
†
九州産業大学情報科学部
松本正雄
Prof.Dr. M.J. Matsumoto
2009
2009
1

† This lecture is not of a traditional software
engineering but rather of advanced one
which is primarily oriented towards
business informatics. This series of lecture
is an enhanced version of those first
presented in the spring semester at
Informatik X Universität Dortmund,
Germany back in 1995 and at several other
Universities in Europe, US and Japan.
2009
2
ソフトウエア工学
工学的手法によるソフトウエアの健全
な開発
2009
3
ソフトウエア工学とは？
•
•
•
•
１．ソフトウエア工学の位置付け
２．内容骨子
３．何故ソフトウエア工学が必要か
４．履修の仕方
2009
4
情報技術の職業に絶対必要
• 企業の採用基準が一変した。
• 長年かかって仕事できるようになれば良い
ではなく、入社したらすぐ見当はずれでなく
仕事に立ち向かってゆける人を採用する
• ソフトウエア工学の知識なく情報の仕事を
するのは無理です。
• 友人に知らせてあげて。
2009
5
１．ソフトウエア工学の位置付け
•
•
•
•
実践的（理論的でなく）
技術寄り（業務寄りでなく）
大規模複雑系への対応
ソフトウエア開発の諸問題への対応
2009
6
Business Aspects
Enterprise Modeling
e-business
State of The
Solution Engineering
IT Strategy
State of The Practice
Software Engineering
2009
Technology Aspects
7
Business and Managerial Aspects
Enterprise Modeling
e-business
State of Art
IT Strategy
ソリューション工学
Solution Engineering
情報システムプロジェクト管理
State of Practice
IS Project Management
ソフトウエア工学
Software Engineering
2009
Technology Aspects
8
ソフトウエア工学の狙い
•
•
•
•
•
要求を把握し、それに叶うシステムを定義し、
そのシステム像を分析し、
最適な実現の仕方を設計し、
実装した後、合目的性などを検証する。
カットオーヴァ（運用開始）の後、ライフサイク
ル全体にわたりシステムを保守する。
• その全工程を工学的に支援する。
2009
9
課題
• 要求仕様の確定が困難→業務モデル立
脚
• 保守が困難→業務モデルから一気に形成
• 分析・設計・実装を暗箱+とする
• 独立した検査体制とする
• +Black Box
2009
10
ソフトウエア工学が対象とする工程群
要求定義工程
分析
設計
実装
検証（検査）
保守
2009
運用開始
11
ソフトウエア工学とソリューション工学の相対的関係
ソリューション工学のサイクル
問題の発見・同定
解決モデル練成
システム実現・実
践
2009
ソフトウエア工学の対応領域
12
ソリューション工学
問題発見同定
解決案策定
ソリューション
モデリング
システム実現
運用・進化
ソフトウエア工学
要求定義
システム分析
システム設計
モジュール
間設計
2009
実装
検査
モジュール内設計
13
ソフトウエア工学とソリューション工学
ソフトウエア工学
目的
ソリューション工学
ソフトウエアライフサビジネスライフサイク
イクルへの対応
ルへの対応
取り扱う工程ソフトウエア要求定
義から保守まで
問題同定からソ
リューション進化まで
手法
ソリューション工学
2009
ソフトウエア工学
14
２．内容骨子
• １分析と設計の基本的な考え方
– 分析や設計の手法は多い
– 背後にある基本的な考え方を理解する必要有り
– 例題演習（チーム討議して発表）
• ２ライフサイクルの基本的な考え方
– SWプロセスモデルの選択
• ３重要課題への対処
– 検証可能性への対処（VOD）
– 開発競争力向上への対処（Reuse）
– 変化への対応（SOA）
2009
15
３．何故ソフトウエア工学か
• １．経営からの厳しい要求
– 納期、品質、投資効果
• ２．品質・納期・原価・保守の根深い問題
• ３．開発環境の激変
–
–
–
–
Off Shore Development
COTS（Components off ｔhe Shelf）
パッケージの浸透（基幹系ERP）
構造化→OO指向→SOA指向
• ４．レガシー（Legacy）問題：新規系と統合
• ５． ITの社会に及ぼす影響
2009
16
一軸からニ軸の社会へ
生産者の論理
垂直統合
囲い込み
大都市の時代
インダストリ・ソリュ-ション
2009
中小企業・個人の論理
水平連携
インターフェースの標準化
地域の時代
コミュニティ・ソリュ-ション
17
４．履修の仕方
• 十分に理解すること
–
–
–
–
重要案件だが勉強する機会は稀だろう
質問ー大歓迎！mjm＠
出席ー出席率１００％が望ましい。
座席ー随意
• 例題演習は必ず提出すること。
• 試験：実施する
• 成績
– 日常の取り組み姿勢と理解度の両方を評価して決め
る。期末試験80%、レポートなど20%
2009
18
ソフトウェア設計・製造自動化技術
１．位置づけ
○システム開発
システム
開発
要求定義
分解など
システム分析
SystemsAnalysis
モジュール外設計
システム全体を
ハード/ソフト/人間
の３つの系に区分
け
ソフトウェア全
体のモジュール
への分解
Inter-module Design
分析設計
モジュール内設計
Intra-module Design
プログラム・モジュー
ル設定
実装（インプリ
メンテーション）
2009
検査
19
何故、分解に着目するか？
• システム全体を捉え、それをいかに作成す
るかが課題。
• モジュール１に分解し２、その設計まででき
れば、後は実装しシステム統合（組み上げ
れば）済む。
•
•
2009
注１：全体を構成する各部分を指す。構成要素とも言う
注２：モジュ-ル分解（Decomposition）と言う。
20
分解の方法
• 分析・設計方法から説明する場合もある。
• 工程としてのシステム分析・設計では、その方法
は多岐にわたり、本質を見失いがち。
• 中心課題は、該工程におけるモジュール分解な
ので、その方法をまず理解しよう
•
断片的な事柄の理解ではなく、課題を総括的に理解し
た上で、個別詳細方法を理解するほうが賢明。
•2009 その他の懸案は付随的である。
21
その他の懸案事項
• 最近、流行りのe-ビジネスモデリングとの関連
は？
• オブジェクト指向方法との関連は？
• プラットフォームアーキテクチャとの関連は？
2009
22
090414 課題演習
• モジュール分解を学
生管理システムを例
に行え
• 着目すること→静的
分解（機能階層、機能
情報関連）
2009
• 視覚化せよ
23
今流行のe-ビジネスモデリング
やSOAとの関連
• 定義１：“e-ビジネス”
 ITを駆使して新しいビジネスモデルを考案し執行する
• 定義2：“e-ビジネスモデリング”
 上記e-ビジネスのモデルを作成する。ビジネスの基本的
仕組み、プロセス、IT実装部分の同定など。
・定義3:SOA
 上記e-ビジネスモデルを構成する業務プロセスの粒度で
システム構成要素に対応づけてシステムを形成すること
をSOAと言う
2009
24
プログラムや
データ
モジュール
ソフトウエア
情報通信システム
ビジネスプロセス
ビジネスモデル
エンタプライズシステム
2009
25
何に着目するか？
• 機能（システムに具備されるサービス、処理、操
作、制御）
• 振舞（時間の流れに沿って展開される動作、状
態遷移）
• 情報（情報の粒度は粗から細まで多々ある）
• 性能（時間性能）
• 品質（信頼性）
• 構造（制御の構造、プラットフォームやアプリケー
ションのアーキテクチャ構造など）
• 構成要素
•
- オブジェクト
•
- コンポネント
2009
26
モデル化とは
• 懸案の本質を明らかにすること
– 着目している懸案以外は捨象する。
• モデル化の例
• 情報モデル
• 構造モデル
• 振舞モデル
• 状態遷移モデル
– など
2009
27
分析と設計
分析
設計
目的
ハード、ソフト、２段階のモ
人間の繋がりにジュール設計
手法
分解（システム
分解）
分解（モジュー
ル分解）
注意点
分担の適切さ
モジュール分解
の視点
2009
28
オブジェクト指向開発方法
（OODM）との関連
• OODMはオブジェクトに着目して、システムの分
析、設計、実装などを行う方法である。
• UMLの場合ユースケース、アクティビティ、オブ
ジェクト、クラス、コンポジット構造、コンポーネン
ト、シークエンス、コミュニケーション、相互作用
概要、ステートマシン、配置、タイミング、パッ
ケージの12図式がある。
• システム全体と構成部分との関係、構成部分の
解明が（実装可能な程度に）本来必要
2009
29
○開発区分
開発区分
ー“工程”に基づく
ー“場”と“視点”に基づく
●理想的区分･･･････図1.1参照
●現実的区分･･･････図1.2参照
2009
30
システム開発の作業手順
• 何を最初に検討するか？
2009
31
例題
• 地震を感知したら、警報を発するシステム
2009
32
ソフトウェア設計・製造自動化技術
１．方法
分解(Decomposition)
○システムのモジュール分解
システム全体をモジュールにいたるまで分解
○目的
●複雑さの克服
●開発作業の分担
○目標
モジュールへの分割とその内容定義やインターフェース規定を行う。
○方法
分割征服(Divide and Conquer)
●目安
モジュール独立
G.J.Myersの指針
Cohesion(凝集度)
・モジュールの強度･･････････表2.1参照
2009
・モジュール間の結合･･･････・表2.2参照
33
ソフトウェア設計・製造自動化技術
１．方法
○分析アプローチ
システム全体のはたすべき機能を、HW、SW、人間／組織
に割りふり、各要素間の関連を明らかにしていく。
○システム分析と結果の表現方法
要素の粒度（Granularity ）
粗い（Coarse Grain）＝大きい塊
細かい（Fine Grain）＝小さい塊
2009
34
システム分析の方法
• １）静的分析
•
機能階層
•
機能情報関連
•
DFD（Data Flow Diagram）
• ２）動的分析
•
時間軸に基く振る舞い（シーケンスチャートSequence Chart）
•
状態遷移(状態遷移図)
•
非同期処理(ペトリネット)
•
シュミレーション的性能分析
• ３）統合的分析
•
構造化分析（SA）
ジャクソン法(JSD)
2009
35
090414 課題演習
• モジュール分解を学
生管理システムを例
に行え
• 着目すること→静的
分解（機能階層、機能
情報関連）
2009
• 視覚化せよ
36
目標・目的
単位管理
機能
学生管理
研究室所属管理
履修管理
機能
機能
B
A
登録
成績
機能
a
機能
b
機能
Ｘ
機能
y
レベル１
C
機能
c
機能
Z
レベル2
レベル3
図2.14 機能の階層的関係
2009
37
学生管理システム
履修管理
単位管理
履修登
録
報告
成績登録
確認
研究室所属
管理
単位管理
記録
レベル１
レベル2
レベル3
機能の階層的関係
2009
38
分解（学生管理システムの場合）
• 学生管理システム
– 単位管理
– 履修管理
– 研究室所属管理
• さらに分解の余地はあるか？
2009
39
層（Layer） Layer by Layer
①レベル１での機能と情報の関連分析
②レベル１での機能と情報の関連分析
③レベル１での機能と情報の関連分析
2009
図２．１６機能と情報の関連分析のアプローチ
40
Operational Viewpoints
Monitor and control
operators
User type A
Target
Immediate environment
User type B
SYSTEM
(embedded systems)
Other
SALFS
Directly
Connected
COSTS
ENHANCEMENTS
2009
systems
EXPANSION PERFORMANCE
RELIABILITY
41
(出典：CORE)
実体関連図 Entity Relationship
ER Diagram
Generate
Service Request
Postponed Request
Generate
Service Action
Associate
Associate
Allocate
Customer Service ID
Use
Customer Device
Record
Switching
Service
Have
Use
Customer Record
Cable
Main Processor
Use
Cabinet
Extdended Wire
Associate
Work
One A for one B:
A
B
One A for many B:
A
B
One A for zero one B:
A
B
A
B
One A2009
for zero or many B:
Work
Engineer
Connect
pole
42
CALL
SUBSCRIBER _REGISTER
INTERFACE
ENV
_HANDLER
A_OFF_HOOK
CONNECT_DIG_REC
CONNECTION
DLAL_TONE
DLALLED_DIGIT
DLAL_TONE_OFF
DIGIT
FETCH_NEXT_DIGIT
DIALLED_DIGIT
RING_TONE_TO_A
DIGIT
SEND_RING_TONE_TO_A
CONNET_CALL_HANDLER
DISCONN_DIG_REC
RING_TONE_A_OFF
A_ON_HOOK
B_ANSWER
CONVERSATION
A_ON
DISC_B
2009
シーケンスチャート
43
CALL_HANDLER
SUBSCRIBER _REGISTER
INTERFACE
ENV
A電話上げ
時
間
の
流
れ
接続（DIG_REC）
接続
DLAL_TONE
番号ダイアル
DLAL_TONE_OFF
番号
次の桁FETCH
番号ダイアル
番号
repeat
接続（CALL_HANDLER）
Aへリングトーン
Aへリングトーン返す
（DIG_REC）切り離し
Aへのリングトーンオフ
A電話機置く
Bが応答
会話
A電話機置く
Bと切り離し
シーケンスチャート
State Transition Diagram状態遷移図
Diagram showing state and its transition triggered by event
[Expression A]
Active活動
中
Finish Breakfast
[Expression B]
In Sleep
Bed in Time
Intermediate
寝ぼけ状態
Intermediate
In Sleep睡
眠
Morning Call
Active
Morning Call
Finish Breakfast
2009
Bed in Time
45
状態遷移図
状態、遷移、イヴェント
ベッドに就く
活動中
寝ぼけ状態
朝食完了
状態
睡眠
目覚時計が鳴
（四角のなかに状態名を書く）
凡例
A
B
なにやかや
2009
（ＡからＢへの）遷移
イヴェント（トリガーとも言う）
46
状態遷移図
[図]
活動中
朝食完了
ベッドに就く
睡眠
寝ぼけ状態
目覚時計が鳴
[シーケンスチャート]
睡眠
寝ぼけ状態
活動中
目覚時計が鳴
朝飯完了
2009
ベッドに就く
47
状態遷移図
状態、遷移、イヴェント
[図]
活動中
朝食完了
ベッドに就く
寝ぼけ状態
睡眠
目覚時計が鳴
48
状態遷移表
• 状態Ａ
• 状態1 状態Aから状態1へ遷移する条件（イベント起
生）
• 状態2 状態Aから状態2へ遷移する条件
• 状態3
• 状態Ｂ
• 状態1
• 状態2
• 状態3
• 状態C
2009
49
状態遷移表
• 状態睡眠中
•
状態1 睡眠中
•
状態2 寝ぼけ
•
状態3 活動
• 状態寝ぼけ
•
状態1 寝ぼけ
•
状態2 活動
•
状態3 睡眠
• 状態活動
•
状態1 睡眠
•
状態2 寝ぼけ
•
状態3 活動
2009
－
目覚まし時計鳴る
不可
－
朝食完了
不可
就寝
不可
-
50
状態遷移
• 状態の数が増えれば遷移の数も増える
• そのことへの解決方法
•
階層化
2009
51
空
転送要求
データ通信
異常処理
終了確認
転送終了
2009
52
空
異常終了
異常発生
転送要求
データ通信
異常発生
異常処理
異常発生
終了確認
転送終了
階層化しない状態遷移図
2009
53
空
転送要求
異常終了
データ通信
異常処理
異常発生
終了確認
転送終了
2009
階層化した状態遷移図
54
詳細な例は148-9コマ参照
• 腕時計の制御例
• 電源on-off
• アラーム機能on-off
• ビープ音制御
• など
2009
55
CORE Stages
and outputs
Problem Definition
Problem
Statement
Terms of
reference
Viewpoint Structuring
Viewpoint
Descriptions
Viewpoint
structure
Work
plan
Tabular collection
Preliminary Data
flow and Action
Descriptions
Date structure
and history
descriptions
Single
viewpoint
models
descriptions
Combined
viewpoint
model
descriptions
2009
System Constraints
Specification
Tabular
collection
forms
Data Structuring
Single Viewpoint
Modeling
Data
Structure
Diagrams
Combined Viewpoint
Modeling
Single
viewpoint
models
Constraints Analysis
Combined
viewpoint
models
56
機能情報関連図
• 機能間を流れる情報を追記した図
2009
57
機能情報関連図（学生管理システムの場合）
成績
単位管理
単位情報
履修管理
卒研単位情報
2009
単位取得情報
研究室所属管理
58
機能階層（ペイロールの例）
ペイロール
月例給与計算
勤怠データ入力
データ確認
計算
帳(票)表出力
賞与
査定データ
2009
賞与計算
59
演習提出
•
•
•
•
•
ペイロールシステム
機能階層図と機能情報関連図
docファイル（下位互換）
K’Life レポート機能で送信
09.4.17（金）正午12:00
2009
60
何故、機能分解？
• SOA技術の根幹である
• 次が分からないとSOAが理解できない
–
–
–
–
–
2009
機能とは
機能の詳細化
機能と情報の関連
サービスとは
サービス指向アーキテクチャとは
61
不具合例
• ファイルが読めない
• ファイルの冒頭に学籍番号氏名ナシ
• 類似回答（僅少部分変更してあるが）
– 自主性ナシ
• 枝問の一部しか回答せず
• 設問無視
2009
62
多い間違い
• １．機能階層図と機能情報関連図の間の矛盾
– 機能が不一致
– レベルが不統一
• ２．機能情報関連図において
– 機能間を流れる情報を示さず、一連の処理の流れを
示している
– 機能や情報に漏れがある
– 辻褄が合わない
• 方向間違い
• 情報間違い
• 機能間違い
2009
63
ペイロールシステムの機能階層図
ペイロールシステム
月例給与
賞与計算
年末調整
社会保険
税改定
レベル１
ペイロールシステムの機能情報関連図
勤怠データ
給与データ
月例給与額、給与データ
月例給与
年末調整
賞与計算
人事給与査定データ, 給与データ
人事課
課
2009
注給与データ＝（基本給、手当、税、控除）
賞与額、支払保険料
64
誤字訂正
誤：ペイロールシステムの機能情報階層図
正：ペイロールシステムの機能情報関連図
2009
65
レベル2以下の表示
• レベル1の各機能ボックスを詳細化
• レベル１図から詳細図へ辿れる仕組み
– 3次元階層図で示す
– 各レベル/各機能に階層項番を付けて示す
– ドリルダウンで詳細を見れるようにする
2009
66
3次元階層図
①レベル１の機能情報関連
②レベル2の機能情報関連
③レベル3の機能情報関連
2009
機能情報関連図を層の積み重ねで示す
67
「月例給与計算機能」の３次元表示例
①レベル１の機能情報関連
賞与
昇給
月例
上から下へ辿る：詳細が分かる
下から上へ辿る：要約が分かる
年調
勤怠データ
②レベル2の機能情報関連
確認
数値確
月給計算
遅
刻
③レベル3の機能情報関連
早
退
2009
無断欠
勤
減
点
機能情報関連図複数層（ペイロール月例の場合）
68
3次元表現の作成法
• 機能階層図を見て各機能を階層ごとに描く
– すべての機能について行う
• 各層において機能ごとに機能情報関連図
を描く
– すべての機能について行う
• 必要なだけ層を詳細化する（→分解）
• 矛盾、欠損、不完全が無いようにチェック
2009
69
エンタプライズシステムの
• 機能階層図→次図参照
2009
70
エンタプライズシステム
• 仕入計画管理
–
–
–
–
発注処理
仕入処理
仕入訂正処理
発注終了処理
• 販売管理
• 生産管理
2009
71
エンタプライズシステムの
• 機能情報関連図→次図参照
• 注
• １）前図（機能階層図）の仕入計画管理下
のレベル3朱記部分だけ着目せよ（詳細図
示）。
• ２）販売管理、生産管理などは機能名だけ
で詳細は示していない。
2009
72
仕入先
商品倉庫
返
品
情発
報注
情
報
ク報
レ
ー
ム
情
入
荷
検
査
報
告
発情
注報
情
報
318
仕入計画管理
仕
入
計
画
情
報
発
注
終
了
情
報
仕
入
実
績
情
報
発注情報
発注計画情報
318.1
・朱記部分→レベル３
・参考に→その外側にレベル２の機能名だけ
納
品
情
報
・
請
求
情
報
発注処理
318.2
入
荷
情
報
仕入処理
ク
レ
ー
ム
情
報
仕
入
訂
正
処
理
318.3
仕入訂正処
理
318.4
発注終了処
理
買
掛
情
報
仕入実績情報
経営計画管理
買
掛
情
報
入
庫
・
返
品
情
報
返
品
情
報
財務管理
生産管理
在庫管理
2009
73
販売管理
まとめ
• 何故モジュール分解するのか
• その方法
– 「静的分解方法」の場合
• 何に着目するのか
– 機能階層図
– 機能情報関連図
• 工程での違いは？
– 分解の根本的な考え方は同じ
– 分解の対象が違うだけ
2009
74
以上が習得できたらDFDへ
• DFDとはデータフロー図Data Flow Diagram法
• DFDは静的分解に次を追加
– DB→二重線
– 流れの始点Sourceと終点Sink→長方形
– Real Time DFDでは信号や制御の流れ
• DFDが描ければ、次を簡単に設計できる
– モジュールの階層化と実行制御
– データ辞書→DB
2009
75
DFD例示：学生管理システム
• 分析設計を行え
– 通常の学生管理を支援するシステムとする。
– 機能情報関連や機能階層の図示
• 機能情報関連図を示せ
• 機能階層を分解せよ（必要な階層数だけ）
– DFDなど他の手法、を用いて分解せよ。
– 結果を比較せよ
2009
76
取得単位管理
取得済単位情報
履修管理
3年末取得単位数
成績情報
卒研単位
研究室所属
機能情報関連図
2009
77
学生管理システム
単位管理
履修管理
履修管理
研究室所属管理
成績管理
再履修
機能階層
2009
78
学生
エラー*
エラー*
履修管理
履修db
教員
単位・評価
報告
履修登録
正常データ
db更新
成績管理
正常データdb更新
成績db
学生管理
警告
学生db
応答
問い合わせ
問題学生
学部・大学
学生管理情報システム
2009
79
演習090421 図書館システム
• 分析設計を行え
–
–
–
–
2009
通常の図書館業務を支援するシステムとする。
機能情報関連図と機能階層図を描き、
必要なだけ詳細化（分解）せよ。
上記システム案件をDFDなどの他の手法を用
いて分解し、結果を比較せよ
80
演習090421
• 分析設計を行え
– 要求定義は通常の図書館業務を支援するシ
ステムとする。
– 機能階層図、機能情報関連図
– DFD（データフロー図）
– を示した後、静的分解とデータフロー図法の
比較考察を箇条書きで記せ。
2009
81
図書館システム
•
•
利用者サービス機能
－会員管理
• 受け入れ処理（会員登録）
•
•
•
• 抹消処理（会員取消）
– 貸出処理
• 貸し出し期限切れ書籍検索
– 督促状発行
– 返却処理
• 期限内返却か
• 期限超過ー罰
蔵書管理
ー受入・廃棄処理
－利用統計処理
ー修理依頼
ー未返却図書処理
予実算管理
他図書館連携業務
82
演習時の注意
• システムの主要機能に思いを馳せよ
• 立場：利用者、延滞者、書店、（図書係員、大学、
他図書館）
• データフローを追え！DFD書けたらモジュール構
像を想起せよ。
• 詳細は後回し、全体を先に把握せよ！
• 詳細化は階層を下げて考え、書けば済む
• 一度にすべて書けなくても、後から追加可能→
• システム拡張の問題
2009
83
この後
•
•
•
•
•
•
１．機能階層図を導き出す
２. DFや格納データ項目の詳細を整理→DB化
３．層別に深く掘り下げ（必要レベルまで）詳細化
４．設計とその検証を行う（→pp113-121）
５. 各種技法使用して実装へ
ーOOD（従来的システム構築）Object-oriented
Development
• ーSOA（最新技術：即システム運用へ）Service^oriented Architecture
2009
84
図書館システム
レベル2
余実管理と蔵書管理だけ取り上げた例
利用者
却下
購入希望
予実管理
許可
予算実績DB
蔵書管理
蔵書DB
2009
発注
納品
書籍販売店
85
前図の機能階層図
図書館システム
予実管理
2009
蔵書管理
86
利用者サービスを追加
図書館業務システム
予実管理
2009
蔵書管理
利用者サービス
87
図書館業務システム
ソース・シンクを追記した例
利用者
却下
延滞者
購入希望
返却督促
予実管理
返却
許可
予算実績DB
不具合はないか？
蔵書管理
蔵書DB
発注
納品
書籍販売
貸出要求
貸出す
利用者
2009
88
図書館業務システム
レベル2
この後、レベル2のそのほかの機能も追記する。
利用者
却下
レベル2の各機能を詳細化し、図示する。
購入希望
誤りがないかチェックする。
予実管理
結
果
通
知
許可
予算実績DB
会員
登録/
削除
F1
F2
蔵書管理
蔵書DB
発注
納品
書籍販売店
利用者サービス
会員DB
2009
F1：貸出/返却要求
F2 :督促
89
利用者サービスを高度化
• 利用者からの要求
–
–
–
–
蔵書の照会
貸し出し（待つ場合の予約）
返却（通常、延滞後）
その他の問い合わせ
• システムの機能（利用者向け）
– 問い合わせへの応答
– 延滞者発見と通知
• システムの機能（管理向け）
–
–
–
–
未返納本の処理
破損・有効期限満了本の処置
購入処理（書店対応）
購入本の配架
• システムの機能（本部・学部向け）
– 予実算管理
– 利用方法改定
– 中期運営計画
• 他図書館との連携
2009
– 融通（借り貸し）
90
DFD演習に見る間違い
•
•
•
•
•
階層間違い
DBが一元的でない
ソース・シンクが間違い
システム境界線が不明
規約違反
2009
91
可視化
•
•
•
•
Visualization
目に見えるようにして、意思疎通する
理解
改良、洗練化
2009
92
図書館業務システム（続）
サービス要求（照会・
貸出・返却）
利用者
却下
利用者サービス
要求対応
希望
予実管理
問合せ
許可
応答
蔵書管理
発注
納品
2009
書籍販売
93
図書館業務システム（続）
サービス要求（照会・
貸出・返却）
利用者
却下
利用者サービス
要求対応
希望
会員DB
予実管理
他図書館
問合せ
許可
応答
要求
応答
蔵書管理
予実DB
要求
本部・学部
2009
蔵書DB
発注
納品
書籍販売
対処
94
図書館業務システム（続）
サービス要求（照会・
貸出・返却）
利用者
却下
利用者サービス
要求対応
希望
他図書館
予実管理
問合せ
許可
応答
要求
応答
蔵書管理
要求
本部・学部
納品
書籍販売
対処
未返却
2009
発注
リスト
督促
督促
利用者
95
以下同様に詳細化や拡張
• 利用者サービスを詳
細化せよ
• 「他図書館連携業務」
にも対応できるようシ
ステムを拡張せよ
2009
96
集計
40
35
30
25
20
第二回
•
•
•
•
出席者数
39
レポート提出者数 12
優秀
4
努力賞
5
15
10
5
0
出席
2009
優
選外
97
出来具合
158
100
DFD
モジュ-ル構造
50
50
212
90 45 （照会・貸だけ）
45（同左）
081
80 40 （照会・貸返だ
け）
70 35 （貸返だけ）
40（同左）
046
2009
35（同左）
98
続
DFD
モジュ-ル構造
128
45 45 （冗長）
0（無し）
034
50 50 （照会・貸
返だけ）
0（無し）
080
45 40 （貸だけ）
5（非対応）
187
40 40 （貸だけ）
0（無し）
2009
99
DFD
モジュ-ル階層
083 20
0（無し）
20（DFD非対応）
079
0
0（無し）
0（無し）
056
5
0（データ無きDFD) 0（無し）
2009
100
環境
・政治
・経済
・技術
(市場)
操縦管理
・生産
環境動向情報
・意思決定
・長期計画
環境動向情報
実
績
報
告
操縦指令情報
経営管理
(達成予算等)
・販売(購買)
・研究開発
経営計画
需要者
方
針
・
目
標
財務報告情報
・市場分析(販売予測)
・サービス
請
求
情
報
請
求
情
報
財務管理
・原価計算
予算情報等
・財務分析
実績報告情報
入
金
情
報
供給者
・予算編成
・実績(収支)計算
・売掛、買掛管理
・人事計画
人事異動情報等
労務・勤労情報等
労
状務
況・
勤
労
報
告
情
報
人情
事報
計等
画
人事管理
・人員配置計画
・労務管理
人件費情報等
人事異動・労務支出情報等
・給与計算
2009
操縦実績情報等(売掛,買掛,契約,生産
等)
価格.経費情報等(生産,販売原価及び価格,信用状況等)
図2. 13 機能情報関連図
101
支
払
情
報
システム分解技法の要点
システムの階層分割
●Layer-by-Layer Decomposition
●分割の一般指針･･･強度を強く、結合度を
弱く(Composite Designの指針)
2009
102
システム全体の外部環境を明確
Layer(層) by Layer
Decomposition
レイヤ１
:機能の構成要素
：ファイル
：コール（呼び出し）
：データの参照
レイヤ２
構成要素間の関係を定める
SADT= Systems
Analysis And
Design Technique
レイヤ３
最終的には、簡単にコーディングできるプログラムモジュールへ
2009
103
Procedure is laired
Procedure for super
ordinate module
Procedure for
subordinate module
2009
Procedure for ultimately
subordinate module
104
表2.1 モジュール強度（凝集度）の程度
強
暗合的
strength)
度
(coincidental
説明
1つのモジュールとしての塊に特に意味関連性がない。
そうしたモジュールを修正すると、それをCALLしている
モジュールに影響を与える可能性が大。
論理的な視点から複数の処理機能をまとめる。例えば、
入力処理と言う論理的モジュールはカード、磁気テープ、
磁気ディスクなどからの入力処理を内包させることが可
能だが、モジュールの内部が複雑になり、使用側からの
パラメタ指定が多くなる傾向がある。
論理的
(logical strength)
時間的
(classical strength)
論理的モジュールの１種であるが、実行タイミングを考
慮して、グループ化したモジュールのこと。例えば、初期
化時に行うべき処理を集めたモジュール。
手順的
(procedural strength)
流れ図を見て,複数個のブロックをまとめてモジュールと
して構成したような手順的モジュール。
(communicational
手順的な強度に加え、モジュールを構成する各内部要
素に密接な関係がある場合、そのモジュールを連絡的
と言う。
情報的
(information strength)
個別に使用可能な機能複数を構成上1つのモジュール
にしたもの。構成後も個々の機能は別々に利用出来る。
機能的
(functional strength)
モジュールは切っても切れない関係性の強いもので構
成され、１つの機能を意味する。
連絡的
strength)
表2.2 モジュール結合度の程度
結合度
内容結合
(content coupling)
共通結合
(common coupling)
外部結合
(external coupling)
制御結合
(control coupling)
スタンプ結合
(stamp coupling)
データ結合
(data coupling)
説
明
あるモジュールが他のモジュールの内容を直接参照している場
合。高級言語では、通常EXTERNAL 属性のデータしか参照し
あえないので、この結合関係は作成しにくい
データの共通領域を設け、関係するモジュールはそれを参照し、
実行される。
例：FORTRANのCOMMON領域,PL/1のEXTERNAL属性をも
ち、%INCLUDEで共有しあうデータ領域を通してのモジュール間
結合関係
共通結合と似ているが、共通データを参照する際、各モジュール
は参照項目名に対し外部宣言(PL/IならEXTERNAL属性)を行う
機能コード、標識、スイッチなどの制御情報を引数としてCALLす
るCALLされたモジュールの処理の流れは、その引数により決
定される
データ領域が共通領域になく、同一データ構造を参照する際、モ
ジュール間の引数としてデータ構造名を渡し、参照する方法
モジュール間のデータはすべて引数として渡す。しかも、データ
はすべてデータ要素であり、制御要素やデータ構造はない
モジュール分解の目安
• モジュール（構成要素）の
– 強度（凝集度）は強く
– 結合度は弱く
• 何故か？
• モジュールの独立性はできるだけ高いほう
が良いので。
2009
107
Modularity and Software Cost
Cost to interface
Cost of efforts
Region of minimum cost
Total software cost
Cost /module
Number of modules
Figure 7.8
Cohesion
…A measure of the relative function strength…
Coincidental
Temporal
Communicational
Logical
Procedural
Sequential
Functional
Low ● ● ●
2009
“Scatter-brained”
●
●
Cohesion spectrum
Figure7.9
●
●
●
●
High
108
“Single-minded
●
Modularity and Software Cost
Region of minimum cost
Total software cost
Cost to interface
コ
ス
ト
Cost /module
システムを構成するモジュール数
Cohesion
Coincidental
Logical
Low ● ● ●
2009
“Scatter-brained”
●
●
Temporal
Communicational
Procedural
Sequential
Cohesion spectrum
Figure7.9
●
●
●
●
Functional
High
109
“Single-minded
●
今まで説明した事項
分解
ー考え方（①トップダウン、②データ抽象化、③データフロー）
ー具体的方法
● モジュール外（システム分析やシステム設計）
•
1-1. 機能階層図
•
1-2. 機能情報関連図
•
1-3. DFD
•
1-4. シーケンスチャート
•
1-5. 状態遷移
•
1-6. ペトリネット
● モジュール内（モジュール設計）
•
2-1. 制御構造設計法
•
2-2. データ構造設計法
2009
110
ソフトウェア設計・製造自動化技術
2. ．設計技術/ソフトウェア設計
目的
ソフトウェア(の機能)を、最終的には、いくつかのプログラムモジュー
ルの有機的結合体で実現する仕方を決定する
目標
1) そうしたプログラムモジュール群とその構成の決定
2) プログラムモジュールの機能(詳細)仕様決定
ソフトウェア設計（大別して２つの段階）
1)大域的：
モジュール外（間）設計→「モジュールに至る分割を意識」
2)局所的：
モジュール内設計→「モジュールの設計を意識」
モジュールのアルゴリズムの設計、
2009
ロジックの設計、
ローカルデータの設計
111
モジュール外内とは
• モジュール外とは、
システムレベルからモジュールレベル
（内部は含まず）までの範囲
• モジュール内とは、
モジュールの内部
2009
112
機能の呼び出し関係に着目
(トップ・ダウン設計法)中央集権型
システム分解の基本枠組み
(階層分割)
データ抽象化に基づくモジュールに着目
(データ抽象化設計法)地方分権型
順次データ列の変換に着目
(データ・フロー設計法)連邦型
2009
図2.1 ソフトウェアモジュール外設計法
113
トップダウン設計（Top Down）
●まず、主要機能要素について,その内部処理を
副機能呼び出しを含む形で設計
●副機能について、順次、同様に設計してゆく
データ抽象化設計（Data Abstraction）
●データとそれに関連する、互いに関係の強いいくつかの操作機
能を１つのモジュールにまとめる
データフロー設計（Data Flow)
●順次データ列を扱う場合、構成要素間を流れるデータに着目し
て設計する
●設計後の実現の仕方
○各処理を並列プロセスとし、中間データ列
をプロセス間通信のメッセージバッファとする
○Myersの複合設計における方式
2009
○Jacksonのプログラムインバージョン
114
設
計
順
序
：１入口の手続き
：呼び出し関係
2009
図３トップダウン設計
115
要素間の関係
トップダウン設計吟味
システム全体を最初から見通せる場合、効果的。
上位の機能
理解し易い
下位の機能
コマ切れ機能でとなり、それぞれ単独では
理解し難い。インターフェースも複雑化。
データ抽象化技法
と組合わせて使用
2009
116
データ抽象化設計法
吟味
データ抽象化は、良いモジュール化を得る上で有効
一般に何を外部手続きとするかの設計が難しい。
2009
117
テ
ー
ブ
ル
き使
を用
コ側
ー
ルか
すら
るは
だ、
こ
けれ
でら
よの
い外
部
手
続
共通データ
(a) 複雑な共通データを介したモジュール化
clear
add
search
テーブルモジュール
clear
情
報
隠
蔽
add
search
名前
内容
属性
hash
(b)抽象化技法を使ったモジュール化
2009
（ｃ）抽象的なテーブルの概念
図4 データ抽象化技法によるモジュール化
118
拡張
同じ構成の抽象データを複数個宣言して使えるようにしたもの→抽象データ
データの実体(オブジェクト)にその操作(メソッド)が付随していると把える。
型理論 (Type theory)
・パラメータ付抽象データ型
・ジェネリック関数
(複数の型のデータを統一的に扱える関数)
2009
119
(紫合,ソフト設計技法、ソフトウェア科学‘８４より)
データフロー設計＊
システム分析(SA)の機能情報関連図に似ている。
制限：
機能は、並列に動作するプロセス。
情報は、プロセス間で扱われるデータストリーム
＊データフロー図（Data Flow Diagram）設計ではプロセス並列性
を条件にしていないので注意
2009
120
出力1
処理１
中間データ１
処理３
処理２
処理４
多間データ３
中間データ２
図５データフローダイアグラム（DFD）
モジュール化
(a) 制限に合っている例
2009
出力2
：データフロー
(a) 制限に合わない例
121
データフロー図
A
モジュール間結合方法：データの受け渡し関係による
D1
D2
B
C
等価
モジュール間結合方法：呼び出し関係に基づく
制御フロー図
P
パラメータの渡し先
コール関係
A’
2009
B’
C’
図７複合設計でのデータフロー→制御関係変換
122
データフロー設計法
吟味：
・並列処理特有の非同期性にまつわる複雑さを軽減
・独立性の高い、扱い（理解し）やすいモジュール化
(理由) データフローの各プロセスは、入出力のデータだけが
外部とのインターフェイスになる
・通常のプログラミング言語では効率よく実現できない。
変換(データフローの通常プロセスへ)
・マイヤーズの構造化設計
・ジャクソンのプログラムインバージョン
2009
123
システム分析法
ソフトウェア設計・製造自動化技術
2.4．設計技術/まとめ
静的(主に、機能に関して)
●境界明確化とハードウェア、ソフトウェア、人間系の役割分担分析
●システム(ソフトウェア)の階層構造分析(Structural)
●機能・情報関連分析(Functional)
●オブジェクト指向分析(Object-oriented)
動的(主に、振舞に関して)
●時系列分析
●状態遷移分析
●非同期処理分析
●シュミレーションを使った分析
複合的(主にデータフローを基にした階層モジュールとその制御構造に関して)
●構造化設計（Rossほか）
●プログラミングインバージョン(Jackson)
2009 variation
●Some
124
応用
• 前述は基本的考え方
• 実践上は、基本的考え方を基にした具体
的設計法でモジュール設計を行う
• その１つがDFD
2009
125
DFD
• DFDとはData Flow Diagram（データフ
ロー図）の略
• DFD設計法
2009
126
Data Flow Diaguram
端末
Data
flow
データ
フロー
source
process
Data
flow
process
process
destinatio
n
Data
flow
process
process
structure chart
=階層モジュール
Data Flow
definitions
Process
Description
DB
Defin
itions
Program module
names
項目名にインデンテーショ
ンをつけて
Structured English
図式間の関係
Data
Dictionary
Decision table Decision
tree structure
127
STRUCTURE CHART
Issue-pay-checks
Emp-num
For all employees
Employee-pay
record
Salaried-pay
record
Net-hrly-pay
Hrly-pay
record
Emp-name
Emp-pay
Net-salaried-pay
Employee-pay
record
Get-emp-pay-rec
Calculate-net-pay
Calculate-net-pay
Calculate-net-pay
For hourly worker
For salaried worker
For salaried worker
Nomal-deductions
gsp
Pay-rate
Gross-hrly-pay
Gross-sal-pay
nd
Nomal-pay
Gros-hr-pay
Hrs-wked
Tax-details
Tax-details
bonuses
Calculate-gr-pay
Calculate
Calculate-gr-pay
For hourly
Normal deductions
For salaried
worker
Any diagram may be annotated
using the text selection in the
2009 methodology menu
worker
Paychecks
Tue Nov 08 ,1988 3:48System
128
Architect
不正問合せ
問合せへの
正当
問合せ元
問合せ
問合せ
問合せへの
問合せ
内容を
応答
応答作成
応答先
編集
口座
情報
2009
DBからのデータ/
顧客状況
図DFD sourceとdestinationとデータベースの表し
方
129
(Invalid)
Inquiry
Inquiry
(Valid)
Source of
Inquiry
Inquiry
EDIT
INQUIRY
PRODUCE Response
Destination
Inquiry
INQUIRY
of Response
RESPONSE
Account
Master
Data/Status
Info
データベース
2009
図DFD sourceとdestinationとデータベースの表し
方
130
システムを階層的なデータフロー図で表現
INVENTRY
CUSTOMER
LOW
STOCK
OVFRDUE
NOTICE
PHONE
PRODUCT
PAYMENT
NOTICE
CHECK
CHECK
Get
INVENTORY
CUSTOMER
PRODUCT
INVOICE
REGIONAL
OFFICE
XACT
POST
OFFICE
ATTACH
EDIT
XACT
AND
ORDER
PACKAGE
INVOICE
CANCEL
CANCEL
PROCESS
DATA
CANCEL
ORDER
ROUTE
PRODUCE
CONFIRM
ATION
CUSTOMER
CONFIMATION
ORDER
AIR POST
PACKAGE OFFICE
INVENTORY
PAYMENT
INVOICE
CUSTOMER
INVOICE
PAYMENT INVOICE
PROCESS
PAYMENT
DATA
PRODUCE
INVOICE
INVENTORY
INQURY
CUSTOMER
PROCESS
INQUIRY
INVOICE
INQUIRY DATA
INQUIRY RESPONSE
プロセス：機能を
表す
PRODUCE
INQUIRY
RESPONSE
ABC
2009
図1.1 信用販売会社の論理的なDFD
データストア：蓄積
131
型データ
MAIN
record
record
#1
#4
#3
#2
GET
EDIT
EDIT
EDIT
EDIT
WRITE
SEQUENCE
RECORD
TYPE 1
TYPE 2
TYPE 3
TYPE 4
RECORD
RECORD
RECORD
RECORD
RECORD
record
record
GET
CHECK
CHECK
CHECK
CHECK
RECORD
SEQUENCE
ALPHA
NUMERIC
HISTORY
error
error
error
text
text
text
error
text
PRINT
ERROR
2009
図1.6 編集プログラムのstructure chart
132
Overall data flow
diagram
(Chapter 3)
Explosion
of each
process
External logic
of process
Content
Immediate access
analysis
And structure
Of data flows
IF…
THEN…
c
(Chapter5)
ELSE…
B
A
Immediate-access
diagram(Chapter
7) 2009
Logic tools
SO…
Data dictionary
133
の表示を
つり銭を
定する
符の表示計算
投入物をを刷する
する
入金額を取る
算する
入要求
投資金額のをけ取
進入物
不足をる
進入物を
入れる
ックする
中央変換部分
購入金額
コイン投入口
コイン投入/返却口
カード貯蔵場所
取り消し
購入枚数ボタン
ボタン
切符つり銭受け
表示機
投入物を
受け取る
１
活,非活
トリガ
活,非活
中央変換
部分
切符を発行
する
要求金額
の総計
発行切符
切符の表示を
決定する
切符の表示
投入金額を
精算する
投入モ-ード
トリガ
要求金額の総計
投入OK
購入要求を
受け取る
切符の表示
を印刷
投入金額」の過
不足チェックする
投入物を
返却する
つり銭を
つり銭指示
計算する
投入金額の総計
図10.2-3 複数のダイアグラムを一枚のダイヤグラムに変換
処理に対する非手続き的仕様を前節のGRACEの解説で説明した等関係式の集合として与え、これを実現するモ
ジュール仕様を設計し、SPACEのロジックテーブル郡」として生成する。
2009
134
DFDまとめ
• １．階層ごとにデータフロー図を作成する
• ２．その時、プロセスとデータに注意を払う
• ３．モジュール呼び出し関係図がおのずと
出てくる（制御図）
• ４．データフロー図を階層化する
• ５．モジュール構造図やDBが抽出できる
2009
135
Inventory control adjustments
MANAGE
MENT
SAFETY FACTORS
BULK FACTORS
Pro are
report &
handle
queries
Assemble
Requisition
for
publisher
Detemine
recorders
(inventory)
ORDER HISTOY
NVENTORY
Penoing reos
Purchase orders in prograss
Satisly
Create
CUSTO
All{oders
MERS
Verity I
Back
nventory
available &
order or
requisition
adiuse stock
(not carreid)
Noninventory
back-orders,
pending
items
Regs
Alter back order
update
inventory
titles
Verily
shipment
contents
level
Predaid
orders
Oder&paymennt
shloment
Edit
Varily
Order &
payment
credit is
credititorders
OK
Enter
Generate
pre-payment
shipping
details
note
Pubushers
acctpayeled
invoice
(if present)
Verity
Amagurasu
acctpayeled
Invoice
Orepare
payment
to
Payment of invoice
vendors
Apply payment
To
Generate
vendors
Conlirmation
Check for books upolied
& paid
2009
Invoice
136
RDS SYSTEMS.Inc
SYSTEM LEVEL Dataflow Diagram
Vendor
Customer
purchoses
Cpos
Ven-invoice
Ven-pur-order
Custome
accoumling
sales
Ven-pock-slip-dk-copy
Cpo-sold
P1
P3
sales
accounling
of goodsand
customers
Ven-pur-order-copy
Goods-descreponcynoticotion ssiscrepnotific
Inventory-credit
Customer-pok-slip
Hemstockwec
Cust-shipping-nolilicotion
P2
Iereivinng
Vendor-
Orderd-goods
purchose file
hab
inventory
U-g-r-h
ungrderdgoods and
return notificotion
Shelveg
Archives file
system
starage
shipping
Process 2 has been highlighled using
the style pen feature
PRINTING USING TH REDUCE TO ONE PAGE FEATURE
Note many font styles available,any fonts under Windows are supported
2009
RSD SYSTEMS INC SYSTEM DATAFLOW
TUE NOV 08,1998 15:19 system archilect
137
RSD SYSTEMS.INC
Cust-billing-copy
SYSTEM LEVEL Dataflow Diagram
Customer
accounting
vendor
Cust-statement
CDOS
customer
sale
Cust-payment
Ven-pur-order
Ven-invoice
Purchases
P3
P1
Accounting of
goods and
customers
Ven-pack-slip-&-goods
Cpo-sold
sales
Paid-ven-purchases
Ven-pur-oder-copy
Inventory-credit
Item_stock_rec
Customer-pak-slip
Inv_credit
P2
receiving
hub
inventory
Innentory-debit
shopping
2009
Goods-descrepancynotification
Unorderd
goods and
return
notification
D-n
Discrep
-notific
file
Order-goods
shelves
strage
Paid-cust-bills
Archives
files
system
Cust-shipping-notification
Process 2 has been
138 using the
highlightted
Style Pen feature
Word/Mellor Real Time Dataflow Diagram
STRT/ENDMEASMILE
DRIVER
ENGINE
CTRLON/OFF
MAINTAIN
AUTO SPEED
ENGINE_ON_OFF
STAT/STPINCSPD
RESUME_FLAG
AUTO_SPEED
BRAKE
ROTATION RATE THROTTLE_ROSITION
BRAKE PEDAL
DRIVE SHAFT
2009
THROTTLE
Real-Time Support is provided at no
CRUISE CONTROL
Additional charge
Tue Sep13,1988 19:52
System Architect 139
DATAFLOW DIAGRAM-DEMARCO
D
?
Ven-po
P1.2
Po-form
Cust-po
D
P1.3
Unknown-part-num
Fill-out standrd
part-suppliers
Generate ven-po
Standard-cust-po
Under stock-notification
P1.1
Back-orders
Check-stock
onhand
Ven-po-copy
Ver-stand-cust-po-form
D inventory
Custome-bill-copy
P1.4
Dummy-cust-po
Gen-cust billpack-inv
P1.5
Fill-back-order
Inventory-credit
Cust-invoice
This text has been included using the text symbol
from the methodology menu.
Note that crosshatched arrowheads
2009
Cust-packing-slip
Indicate
That dataflow is connected on one side only
1.Sales
Mon Nov07,1988
15:18
140
System Architect
DATAFLOW DIAGRAM-DEMARCO
Vendor-invoice
0
0
ven-pur-file
Vendor Name
ven-pur-file
P2.2
Rec-ven-invoice
Ven-pack-slip-&-goods
Inventory-credit
Vendor info
Inventory-credit
P2.1
Rec-ven-packingslip
Left expond indicolor indicoles
that a “Commel” is attached
Goods-discrepancy-notification
Goods-discrepancy-notification
Ordered-goods
Unordered-goods-&-ret-notficat
1.Sales
Receiving Deparetment processing.
Note that level Numbers
2009may be automatically generated
Mon Nov07,1988
15:18
System Architect
141
演習060508：図書館システムの
分析設計
• DFD（Data Flow Diagram）法でモジュー
ル分解せよ
• Source と Destinationは適宜
• 明示すべき図
– DFD（階層有りと階層無し）
– モジュール構造図
2009
142
（貸し出し不可能）
要求
貸し出し情報
要求者
要求処理
DB検索
2009
貸し出し処理
結果
DB更新
更新済み
143
演習070515 モジュール分解を行え
• 1.各種レンタルショップのシステム
– 分解時の着眼点は
•
•
•
•
機能階層
データフロー
機能情報関連
その他
• 2.警報システム（非常事態発生を検知し通
報する）
2009
144
レンタルショップのD/F
貸し出し不可能
（応対不可能）
要求
貸し出し情報
利用者
要求処理
DB検索
貸し出し処理
結果
DB更新
貸し出し
更新済み
DB更新
買出し墨
2009
売り上げ貸し出す
145
複合設計
• １．データの流れに着目してトランザクショ
ン分析
• ２．機能間のデータの流れを明確にする
• ３．機能の集合ごとにグループ化（源泉、
変換、吸収）する。
• ４．上記グループ分けを基にモジュール構
造図やDB辞書等を作成する。
2009
146
システム全体構造と情報の流れ
モジュール化
支援ツール
モジュール
モジュール
インターフェス
詳細設計
支援ツール
支援ツール
設計
辞書
関数
関数名と意味記述
関数のコール関係
2009
パラメータ・データ宣言と意味記述
パラ
メータ
Ｆ１
意味記述
関数call
関数１
Parm1
parm2
パラメータ1 F2,f3
147
パラメータ1
設計の流れ
関数
要素
意味
モード
{IF：正常処理）
[THEN]
F1
オープン
P1
条件の間
データ入力
F2
P2
2009
インターフェース設計
処理方式の設計148
「状態遷移図の登録イメージ」
システム制御形状メニュー画面編集
symbol
relation
line Dot_line
グラフ編集
path
作図補助
relation
Cha_arc
領域
アク
属性
P_ state
量子
no
state
接ア
yes
Rext＿state
yes
input
Int_inp
output
2009
149
状態遷移
• システム内部の状態が遷移する（状態遷
移マシーン）は正当性検証に特段の工夫
が要る。
• 午後の情報システムプロジェクト管理で詳
説するので、そこで聞いて欲しい。
2009
150
Citizen quartz muiti alarm
Alarm-ataus
main
Chimestotus
displays
light
off
wait
regular
Deep-test
date
disa
dle
00
disoolod
on
10
time
b
10
c
01
Alarmsbeep
2min in date
2min in date
deep
anable
Thit t1
quiet
dead
T hitT2Alarms
stopwotht
zero
off
reg
２-beep
out
chime
update2
alarm2
alarm2
off
2009
off
hr
10
on
log
update1
on
min
1min
power
Alarm２-ataus
ok
hr
on
alarm1
10
on
1min
Alarms
３-beep
disa
dle
beep
min
bina
anable
enable
151
State Transition Diagram Analysis Facilities
STD Editor
no
yes
Retrieval facilities
Program Translator
STD Simulator
Ba----------
In service ?
? Blocking ?
-------------------
?dight analaysis
--------------------
Ha---------------
2009
Ha---------------
Yes?
Ros_main
No?
(
Await first
Int stat
:
Local?
Int t
:
Yes?
Int V
:
Yes?
State-task_init(); for
ret
152
Petri Net
• 考案者： Karl Adam Petri
• システムの動的振る舞いを表現するには
最小限
• -動作の基本要素であるアクション種類
• -アクションの実行順序関係
• を記述
2009
153
Petri-netの４要素
• トークン：処理されるべきリソース
• プレース：トークンを保持するための組織や装置
• アーク：イベント生起に必要なリソースをトラン
ジッションに供給する。またイベントに基づき処理
されたリソースを他の場所へ移動するためのも
の
• トランザクション：モデル化対象世界でのイベント
またはイベントに基づく処理
2009
154
発火fire
• 発火：トランジッションによりトークンが処理される
ことをトランジッションの発火と言う。
• 発火可能：トランジッションの入力となるプレース
のすべてにトークンがある（必要リソースがすべ
て揃った）とき発火可能となる。
• トークン移動：トランジッション発火によりトークン
は入力プレースから出力プレースへ移動し、次に
発火可能となったトランジッションが発火する
2009
155
非決定性
• １つのプレースｐ１を２つのトランジッション
T1,T2が共有する場合、T1,T2は競合する
と言い、どちらが発火するか非決定的。
2009
156
T1
P2
A3
A1
Ｐ１
x
T2
P3
A2
A4
2009
157
非同期処理
• 状態遷移では１つのプロセスの状態しか
扱わない。
• Petri-netでは複数のプロセスの動作を１つ
の枠組みで表現できる。
2009
158
合
BEGIN
否
ＳＴＤ
FORK
ＭＧ
ＦＣ
JOIN
ＳＮ
X
Z
Y
ＰＮ
図3.9 example of Petri Net class
PN
END
図3.10 control flow of a programFree choice Petri Net
producer :
consumer :
SN
FC
s
STD MG
2009
図3.11 relation among Petri
Net classes
159
図3.12 producer-consumer pｒoblem
P1 :
reader 1 :
P2 :
・
・
・
R1
TR1
C1
R1
・
CS1
R1
M
・
TW
CS2
F1
F2
reader 2 :
図3.13 mutual exclusion problem
・S
P
・
Q
writer
W
・
TR2
・
R
R2
図3.14 reader-writer problem
C2
d
c
b
a
e
x
f
y
z
2 out of
3 net
2009
図3.15 cigarette smokers’ problem
F1
・
F2
F3
F4
F5
・
・
・
・
T1
T2
T3
T4
T5
1
2
3
4
5
160
図3.16 dining philosopher problem
Petri-netを動かしてみよう
•
•
•
•
•
条件が満たされると
発火！
リソースは、次へ
条件が満たされると
また発火！
2009
161
モジュール内設計法
● 大局的設計段階でシステムの全体構造、複数モジュー
ルへの分割とモジュール間の関係、個々のモジュール
の機能などを定義後、
●局所的設計段階で、個々のモジュールの実現の仕方
を定める。
◇ 設計法
○制御構造に着目した方法
構造化プログラミング
○データ構造に着目した方法
Warnier法、
Jackson法
○モジュールを機能視点から、複数の断片に分け、そ
2009
れらを結合してゆく方法
PAM など
162
制御構造に着目したモジュール内
設計法
• 構造化プログラミングで許される3構造の
みを使用してモジュールを表現
• 順次制御
• 選択制御（亜流あり）
• 繰返制御（亜流あり）
2009
163
Yes
S1
S2
S1
P
No
S2
P1
case
P2
S1
S2
Pn
No
P
S
Yes
･････
Sn
S
No
S1
S2
(a) 順次制御
if P then
S1
else
S2
end
case
(P1) : S1
(P2) : S2
・
・
・
While P
S
end
P
Yes
iterate
S
until P
(Pn) : Sn
end
(b) 選択制御
(c) 繰り返し制御
図15 基本制御構造
2009
164
Until繰り返しの盲点
• 条件Pが満たされれば、終了してSを実行
せず、次へ行く。
• そのはずが、最初、Pが満たされていても、
Sを実行してから条件P判定。
• このロジックを甘く見たため、大事故に。
2009
165
While 文字＝空白
get 文字
end
空白をスキップ
if 文字＝“／” then
コメントをスキ
ップ
get 文字
get 文字
iterate
if 文字 = “＊” then
“＊／” までスキップ
語を識別
“＊／” 以外を
スキップ
while 文字＝ “＊”
get 文字
else
“／” 記号識別
end
get 文字
end
until 文字＝ “／”
end
第1レベル
第2レベル
プログラムの段階的詳細化の例
2009
第3レベル
第4レベル
コメントは／＊・・・・・・＊／で示されているものとする
166
A
A
B
CALL I B (d)
D
put d to D
get x from D
d
IB
Integer Q 初期値 = 1
goto L (Q) ;
L (1) ;
Q = n ; return ;
L(n) :
図8 Jackson のプログラムインバージョン
2009
167
データ構造に着目したモジュール内
設計法
• 入力と出力のデータの構造的関連に準拠
してモジュール構造を決定する
2009
168
＊
コマンド列
＊
コマンド
コマンド名
コマンド名D
出現順
＆
コマンド名C
パラメータ
ファイル名パラメータ
コマンド名B
パラメータ
担当者パラメータ
日付パラメータ
日付
ファイル名
(a) データの構造図
担当者
コマンド名A
パラ
メータ部
コマンドB
パラ
メータ部
コマンドA
(b) 具体的なデータの出現例
図17 コマンド列データの構造
2009
169
コマンド列
出力
コマンド
コマンド名
レポート
パラメータ部
レポート名
レポート本体
パラメータ
日付
: データ
の対応
本体行
ファイル名
担当者
(a) 入力データ構造
(b) 出力データ構造
コマンド列→出力
コマンド→レポート
コマンド名→
レポート名
パラメータ部
パラメータ
日付
2009
ファイル名
レポート本体
本体行
担当者
(c) 入力と出力をつき合わせたデータ構造
図19 入力と出力のデータの構造上の関連（例）
170
前記の構造を反映したモジュール
内設計
• コマンド列処理
• コマンド列と出力処理
2009
171
コマンド列の処理
全体の前処理
端末から読み取り
コマンド列の処理
while not end
コマンド前処理
コマンド名処理
パラメータ部の処理
パラメータ部前処理
端末から読み取り
while パラメータ認識
パラメータの処理
パラメータ前処理
case パラメータの種類
( 日付 ) : 日付パラメータの処理
（ファイル名） : ファイル名パラメータの処理
（担当者） : 担当者パラメータの処理
end
パラメータ後処理
end
端末から読み取り
パラメータ部後処理
コマンド処理
コマンド後処理
end
全体の後処理
2009
図18 データ構造を反映させたプログラム構造
172
「コマンド列」と「出力処理」
全体の前処理
端末入力
コマンド→レポート処理
while not end
「コマンドとレポート出力」前処理
コマンド名→レポート名処理
パラメータ部処理
パラメータ部前処理
while パラメータ指示
パラメータ処理
パラメータ前処理
case パラメータの種類
( 日付 ) : 日付パラメータの処理
（ファイル名） : ファイル名パラメータの処理
（担当者） : 担当者パラメータの処理
end
end
パラメータ後処理
端末入力
パラメータ部後処理
レポート本体前処理
Wile 本文行先未完
本文行作成
本文行出力
end
レポート本体後処理
コマンド→レポート後処理
end
2009
全体の後処理
173
ミニテスト
• 177参照
2009
174
演習070522 モジュール内設計
• 各種レンタルショップシステムについてモ
ジュール内設計を行え。
– 制御構造に着目して
– データ入出力に着目して
2009
175
070522モジュール内設計演習
• 制御構造法適用できた：田中宏宗
• 貫、藤本、淵脇、倉本、坂原、畑、野見山、
梶山、白川、豊住、古田、吉村将太、川添、
増永、：制御パターン不適用
• 林田、山口、中村仁、小田浩之、小田慧
介：ある部分をｆ/c表現
• 久冨、緒方、廣松、弓崎、吉村晴、伊藤瞬：
白紙
• 西丸、松並、廣田、菅原、梅野、山田、松
井（構造図）：意味不明
2009
176
発注
要求返
購
入貸
却
･････返却処理
購入出
一般要求処理モジュール
2009
無
有
発注処理
発注処理モジュール
図15 制御構造に基づくモジュール設計（回答例）
177
質問：モジュール内設計法として正
しいのはどれか？
• 1.データ入力と出力の間に関係性があるとき、制御構造
設計法は有効である
• 2.データ入出力に関係性がないとき、データフロー設計
法は有効である
• 3.制御構造とはモジュールにおける実行の制御の構造
を意味する。
• 4.制御構造設計法では３種類の制御構造の組み合わ
せしか使用できない。
• 5.上記4の3種類で全ての場合に対応でき、検証レ
ビューが容易化される。
2009
178
今後の講義予定
• 206参照
2009
179
実時間系の分解
• 動的設計手法を使用する
–
–
–
–
実時間DFD
シーケンスチャート
アクテイヴィテイ図
状態遷移図・状態遷移表
• 階層無し
• 階層有
– ペトリネット図
– その他
2009
180
a
b
制御部
c
A
a
入力データ
B
c
A
a →A
変換部
出力データ
C
b
B
b→ B
変換部
c→C
変換部
図9 制御関係によるモジュール化が適切な例
（入力－出力に対応があるとき）
I
I→M
変換
M
M→O
変換
入力データ
I
出力データ
図10 データフロー関係によるモジュール化が適切な例
（入力－出力に対応がないとき）
2009
181
C
検索結果
コマンド
検索
製品管理システム
製品
データ
2009
報告書
登
録
DB
報
告
182
製品管理システム
コマンド処理
コマンド
制御
コマンド
パラメータ
検索結果
登録処理
検索処理
報告処理
製品
データ
エラーメッセージ
ハンドラ
エラー
メッセージ
抽象
データベース
報告書
：抽象化技法による
多入口操作をもつ
モジュール
DB
図12 第1レベルの構造
2009
183
登録処理
登録コマンド
制御
エラー無
のとき
エラーの
個数
データ
解析処理
データベース
登録処理
製品
データ
エラー
メッセージ
DB コマンドファイル
エラーメッセージ
ハンドラ
2009
抽象
データベース
図13 登録処理の構造
184
データ解析処理
語分解
語列
製品
データ
構文
チェック
修正
語列
DBコマンド
生成
DBコマンド
チェック
DBコマンド
列
DBコマンド
ファイル
エラーメッセージ
ハンドラ
図14 データ解析処理の構造
2009
185
これまでの説明は一般論
• システム分解を具体的に行う場合
• 一般論でも行える。
• 図書館システムについて大局的から局所
的分解まで行ってみよ。
• 警報システムについて同様に行え。
• 違いに気がつくか。
2009
186
領域固有のシステム分解
• 実時間型ソフトウエア • 情報処理型ソフトウエア
• 並行プロセスの制御
• 入出力データ構造に留意
• 状態遷移に留意
• 入出力データやDB構造と
処理の対応関係に留意
2009
187
システム分解
System Decomposition
ケース・スタディ１：実時間システムの場合
2009
188
P
P
コンカレント
P
状態マシン
アルゴリズム
I1
2009
命令
189
システム分解のレベル
関心事
コンカレント
スティミュリ／応答パターン
イベントの同期制御
システムとのインタラクション
状態マシン
機能分析
アルゴリズム
タスク選択／呼び出し
グローバル・データの取扱い
データ構造
オペレーション
論理判断
制御
図4 実時間システムの分解例
2009
190
あいまい／非形式的
具体的／形式的
システム
併行マシン
状態マシン
アルゴリズム
命令
順次
2009
図3 実時間システムの設計の進め方
191
提示仕様（レベルM）
ふるまい要求
テスト要求
構造要求
性能要求
分析
下位レベルのモデルが要求を
満たせない場合
分析
テストモデル
ディシジョン･モデル
ふるまいモデル
分析
分析
性能モデル
ふるまいモデル
ディシジョン･モデルが要求を満たせない場合
送り出し仕様（レベルM＋１）
2009
192
図6 段階的洗練化
実時間系の設計
状態に基づくソフトウエア設計（State-based
・ふるまいのビュー
・機能のビュー
・構造のビュー
CAD）を行う
（状態図）
（アクティビティ図）
（モジュール図）
以下、「警報通知システム」を例に説明する
2009
193
早期警報システム
監視
OP_COM
[in (IDLE)]/GO
・
比較
OUT_OF_
RANGE/
STOP(TK_MS)
SU_COM
SP(SET_UP)
コマンド待ち
RESET
TIME_OUT
設定
警報表示
・
計測
切り離し
切り離し
接続
接続
・
GO
計測中
休止
SP(TK_MS)
2009
194
図７状態図（簡単な例）
オペレータ
接続
警報メツセ-ジ
切離
早期警報系
SU_COM
OP_COM
早期警報制御
範囲（上限・下限）
値の設定
RESET
範囲外
範囲確認
設定
測定
測定値格納変数
TK_MS
計測値
測定値と範囲値を
比較
警報表示
範囲内
2009
図８アクティビティ図
195
計測部METERING_
DEVICE
OPERATOR
OK.
MM
監視部MONITOR
DO
OPERATOR
KEYBOARD
KM
コマンド処理部
COMMAND_
HANDLER
CC
MD
表示部
DISPLAY_
SCREEN
比較部COMPARATOR
2009
図９モジュール図（簡単な例）
196
EWS_CONTROL
OP_COM
[in (IDLE)]/GO
・
COMPARING
SU_COM
SP(SET_UP)
WAITING_FOR_
COMMAND
OUT_OF_
RANGE/
STOP(TK_MS)
MONITORING
RESET
TIME_OUT
SETTING_UP
DISPLAYING
・
MEASURING
DISCONNECTED
DISCONNECT
CONNECT
CONNECTED
・
GO
OPERATING
IDLE
SP(TK_MS)
2009
197
図７状態図（簡単な例）
OPERATOR
DISCONNECT
CONNECT
EARLY_
WARNING_
SYSTEM
WARNING_
MESSAGE
SU_COM
OP_COM
UP_
LOW_
LIMITS
EWS_CONTROL
RESET
OUT_
OF_
RAN
TAKE_
MEASUREMENTS
(TK_MS)
SET_UP
RANGE
COMPARE
DISPLAY
MEASUREMENTS
OUT_OF_RANGE_VALUES
2009
図８アクティビティ図（簡単な例）
198
METERING_
DEVICE
OPERATOR
OK.
MM
MONITOR
DO
OPERATOR
KEYBOARD
KM
COMMAND_
HANDLER
CC
MD
DISPLAY_
SCREEN
COMPARATOR
2009
図９モジュール図（簡単な例）
199
システム分解
System Decomposition
ケース・スタディ２：データ処理型システムの場合
2009
200
システム分解のレベル
機能分解／システム構造階層
フォーム設計
コンポーネントとフォームの関係付け
システム
プログラム
部品
2009
主要関心事
主制御構造
入力－処理－出力
部品呼び出し
アルゴリズム
図５データ処理型の分解例
201
フォーム
システム構成単位
R：
帳票
S：
画面
W：
作業単位
E：
実行単位
実行制御用
使用
F ：ファイル
実体
構成
リンク用JCL
ロードモジュール
P ：ﾌﾟﾛｸﾞﾗﾑ単位
コンパイル用JCL
オブジェクトモジュール
ソースプログラム
呼び出し
A
多対多関係
１対多関係
１対１関係
B
C
図１０ (a) 概念モデル
S2
W1
E2
E1
E3
P2
P1
S1
P5
R1
P6
P9 P10
P8
P6
P9
P7
P3
R2
P10
R3
F1
2009
図１０システム構造の設計
F2
F3
202
図１０ (b) 実際の構造モデル
⑤マトリックス ①組織構造図
②サブジェクト
エリア図
③機能階層図 ④機能依存図
戦略情報
計画
⑥ER図
⑦プロセス
階層図
⑧プロセス
依存図
ビジネス
エリア分析
⑪マトリックス
[[[アクション
⑫会話フロー図 ⑬画面設計
ビジネス
システム設計
⑨プロセス
⑩構造図
アクション図
⑰データ構造設計
xx xxxx
xxx x
⑭プロト
タイピング
xxxxxxx
xxx
⑮プロシィージャ
アクション図
⑯構造図
[[[アクション
技術設計
ワークステーション
メインフレーム
⑲コード生成
⑱データベース生成
製造
DB2
テーブル
トランザク
ション
コントローラ
スクリーン
応用
プログラム
2009
203
図3.3‐2 IEF（Information Engineering Facility）の概要
ソフトウエアCAD
目的
○良質の設計を効率的に
○標準化ドキュメントによる意思疎通の容易化
構成
○良質の設計を効率的に
○標準化ドキュメントによる意思疎通の容易化
インスピレーション源
（類似性、経験、知識）
表現形式
（仕様言語、数学、論理）
設計対象モデル化
ツール系
設計情報ベース
（仕様）
論
駁
2009
クリティカルビュー
（無矛盾性、テスト容易性、
妥当性）
確認
了解
演繹
低位仕様検討
却
下
204
Designing by CASE
Purpose
○Help efficient good design
○Easy to communicate by standardized
Structure
○Modeling design entity
○Design description language
○Repository
Inspiration Source
(Experience,Expertise)
Representation
(Specification lang.,Mathematics)
Design Entity Modeling
Tools
Repository
Reject
Criticize
Critical Review
(Incontradiction,Reasonability,Testability)
Validation
Reasoning
Agree
2009
Lower Level
Specification Study
205
Methodlogies
Programming Techniques
・Structured Programming
GO TO less
Sequential , Selection , Repeat
・Topdown Programming
Stepwise Refinement
Structured Techniques
・Data Flow Diagram
・ER Diagram
・State Transition
Object-oriented Paradigm
Formal Approach
Design Methods
・Modularity
・Abstraction
・Encapsulation
・Information Hinding
2009
Semantics Abstraction
206
残り７回の講義予定
•
•
•
•
•
•
•
•
•
•
１．ソフトウエア開発プロセス（工程）論 2
２．ソフトウエア検証方法 3
３．ソフトウエア開発の技術革新
３．１再利用（Reuse） 2
３，２ SOA技術
４．最近の話題
４．１ SOX法
４．２ Web 2.0の世界
５．ITは社会貢献できるか
６．まとめ
2009
207
ソフトウエア開発プロセス
• ソフトウエア開発を組織的に行うプロセスとし
て、何が良いかは永年課題である。
• 該プロセスのモデル（工程の見本）
• ウォーターフォール（Water Fall）
• ラピッドプロトタイピング（Rapid Prototyping）
• スパイラル（Spiral）螺旋型
2009
208
SYSTEM
REQUIREMENTS
VALIDATION
SOFTWARE
REQUIREMENTS
VALIDATION
PRELIMINARY
DESIGN
VALIDATION
DETAILED
DESIGN
VALIDATION
CODE AND
DEBUG
DEVELOPMENT
TEST
TEST AND
PREOPERATIONS
VALIDATION TEST
OPERATIONS
AND
MAINTENANCE
REVALIDATION
2009
Figure 2. Waterfall model
209
システム要求定義
手戻り
VALIDATION
ソフトウエア要求定義
VALIDATION
分析・概要設計
VALIDATION
詳細設計
VALIDATION
実装・デバッグ
DEVELOPMENT
TEST
検査・試験的運用
VALIDATION TEST
運用・保守
REVALIDATION
2009
Figure 2. Waterfall model
210
Project
Plan
Rapid
Analysis
Database
Development
Menu
Development
Function
Development
Prototype
Iteration
Modeling
Benchmarking
Detailed
Design
Implementation
Training/
Maintenance
2009
211
Figure 4. Rapid-prototype cycle model
プロジェクト
計画
Benchmark Test
ラピッド
分析
DB
開発
評価結果が良く
ない
ユーザインター
フェース設計
主機能開発
試作品の迅速作成と評価が主眼
本格的製品の開発ではない
プロトタイピング
ベンチマーク
モデル作成
詳細設計
実装
運用準備/
保守
2009
Figure 4.
Rapid-prototype
life
212
cycle model
Spiral Model
DETERMINE OBJECTIVES
ALTERNATIVES &
CONSTRAINTS
CUMULATIVE COST
EVALUATE ALTERNATIVES
INDENTIFY , RESOLVE
RISKS
risk analysis
risk analysis
risk
analysis
COMMITMANT
PARTITION
R
proto
A type
prototype
prototype
operational
prototype
rqts.plan concept of
Life cycle operation
plan
development requirements
validation
plan
unit
test
code
integradesign
validation
integration
tion and
and
verification
and test
test
acceptance
implementation test
DEVELOP , VERIFY
PLAN
2009
NEXT PHASE
NEXT LEVEL PRODUCT
213
RA Requirements
Analysis
Spiral Model
CUMULATIVE COST
目標（含む代替）および
制約
決定
代替目標の評価
リスクの同定と解決
リスク分析
リスク分析
リスク
分析
コミツトメント
分割
R
proto
A type
運用指向の
プロトタイプ
プロトタイプ
プロトタイプ
要求定義概念
Life cycle 設計
検討
実装
単体
テスト
開発計画立案要求の検証
システム統合
とテスト
設計の検
証
運用
将来計画
2009
システム
統合テスト
アクセプタンス
テスト
次期システム
の開発と検証
214
リスク（危機）の高いシステムの場合
• リスク：作業の進行を妨げる諸々の要因
• 予測できない危機も含めて、その対策講じ
ながら進める仕方
• リスクに直面して、プロジェクトの進捗を止
めないようにしたいが、リスクの解消もしな
ければならない。
2009
215
Life Cycle Model : Characteristics
対照性
L/Cモデル
ウォーターフォール
特徴
2009
オペレーショナル
（スパイラル）
－洗練化
－進捗の仕方
－システム
段階的
フェ－ズドアプローチ
塑像的システム
繰り返し対話的
プロトタイプベース
彫刻的システム
－リスクへの配慮
ハイテクノロジ・リスク
－管理の特徴
工程管理指向
ハイアプリケーショ
ン・リスク
新規開発指向
－プロトタイプ作成
造り捨て的（Throwaway）
進化的（Evolutional）
216
演習課題：プロセスモデル
• １．ソフトウエア開発では何故プロセスが問
題なのか？
• ２．何故プロセスモデルを議論するのか？
• ３．プロセスモデルの代表例を３つ挙げそ
れらの特徴を記せ
2009
217
Life Cycle Model : Characteristics
Waterfall
Model
－Refinement
－Approach
－System
－Orientation
Stepwise
Phased
System
Architecture
High Tech.
Risk
Managementoriented
Interactive
Prototyping based
System
Sculpture
High Appl
Risk
Productionoriented
－Prototyping
Throw-it-away
Evolutional
－Risk
2009
Operational
Model
218
Water fallウｫータフォールの特徴
• 品質は確かなものが得られる
• 時間・工数を多く必要
• システムの動作、性能、品質（使い易さ）が
かなり後工程にならないと分からない
・コスト高
・簡単な仕様のシステム作りに対しては、プ
ロセスが重過ぎる
2009
219
製品のライフサイクル
• ライフサイクルとは？
• 製品が生まれて、活用され、やがて寿命が
尽きるまでの期間を言う
• ライフサイクル内で何が行われるか？
2009
220
製品のライフサイクル
Life cycle
What
要求定義
分析
運用
現実
世界
仮想
世界
システム統合
設計
How
2009
221
製品ライフサイクル（ロの字形表現）
要求定義
ソフトウエア分析
システム仕様
WHAT
何を作るか
製品
の使
用者
検証
設計
実世界
IT世界
HOW
如何に
作るか
実装
システム統合
2009
ソフトウエア設計
222
何故寿命が尽きるか
• 前提としている技術アーキテクチャが古くなる
• サイクルを回して製品を改良しても勝てない
• 改良しても使用者の要求に添えなくなる
2009
223
Software development process and its cycle
USER REQUIREMENT
SPECIFICATION
U
S
E
R
FIANL
VERIFICATION
in A CYCLE
DEVELOPER’S
DEFINITION
SYSTEMISABLE
SPECIFICATION
WHAT
DESIGNING
実世界
IT世界
HOW
SYNTHESISE
PRODUCT
2009
REAL WORLD
SYNTHESISABLE
SPECIFICATION
ABSTRACT WORLD
224
ロの字形の注意
•
•
•
•
左半分は実世界、右半分は仮想世界
上半分はWhatの世界（何を作るのか）
下半分はHowの世界（如何に作るのか）
４事象は時計周りに、要求定義、分析、設
計、システム統合
• 何周か回れば、ライフサイクル終了
2009
225
R
M
R
M
要求定義
要求定義
分析・設計
W
分析・設計
H
W
H
（a）上工程
R
M
分析・設計
製造
R
M
分析・設計
W
W
H
製造
H
（b）中工程
R
R
M
M
W
W
最終検証
2009
製造
H
検証
（c）下工程
図１．２開発工程区分：現実（右）と理想（左）の対比
製造
H
226
開発プログレス
課題
分析
設計
実装
現状分析
WHY
脈絡分析
WHAT
WHY
機能仕様
HOW
WHAT
WHY
HOW
WHAT
WHY
HOW
WHAT
WHY
HOW
WHAT
WHY
HOW
WHAT
WHY
HOW
WHAT
WHY
HOW
WHAT
設計制約
システム設計
詳細設計
プログラムコード
ﾄﾞｷｭﾒﾝﾃｰｼｮﾝ
運用環境
“システム開発は２W１Hの連鎖である”
図１．３上・中工程の視点
2009
227
ソフトウエア・プロセス
ｿﾌﾄｳｴｱ・ﾌﾟﾛｾｽ＝分解ﾌﾟﾛｾｽ＋合成ﾌﾟﾛｾｽ＋検証
Analysis
Synthesis
Verify
支援系
ユーザ（開発者にExplicit）：ツール系
ツール系の基盤：環境系
ソフトCAD
2009
228
(A cycle of software process) = (Analytical Process) + (Synthetical Process) + (Verification)
要求
製品ライフサイクル（ V字形の表現）
システム検証
.
要求定義
システム設計
実装
2009
統合検証
製品
システムテスト
開発機上・実機上
統合テスト
単体テスト
単体検証
229
V字形の注意
• 左側路線は物作り、右側路線はテスト
• 中央は検証（左右の突合せ）
2009
230
(A cycle of software process) = (Analytical Process) + (Synthetical Process) + (Verification)
V字形ソフトウエア
ライフサイクル
Need
s
User Requirement
Specification
Systemisable
Specification
Systemisable
Specification
2009
Total Verification
Software,Manuals etc.
Integrated
System Test
Successive
Cycles
Deliverable
Product
Integrated
System
Systhesised
Program
231
Advanced Software Process Nucleus
real world
abstract world
PROCESS REALM
f-spec
needs
r-spec
User requirement
Specification
Systemisable specification
functional
structural
behavioral
performance
Decomposer
System Verification
Knowledge
Object Base
+
metrics
What’s view
decomposer specification
functible
structural
behavioral
Dynamics Ananlyser
design rational
Logic Composer
System
Operation
Realm
2009
Software plus
documentation
System Synthesiser
How’s view
synthesisable specification
Feedforward type management (quality,project,cost-risk,product configuration)
232
オブジェクト/オペ
レーション概念
データ
中心設計
カプ
セル化
データ型
ソフトを構造
体ととらえた
時、右の要素
から構成され
る
クラス
AKO
関係
階層
概念
継承
データ型
型と形
の分離
型と形の
連動
オブジェクト
指向
APO関係
構造化
次元
概要
図と地
2009
抽象
データ型
空間
概念
状態/時間
概念
並列
プロセス
メッセージ
通信
オブジェク
トの自律性
ACTOR理論
図14 ソフトウェア設計技術の発展の経緯
FRAME理論
233
Paradigm Comparison
Decisions
and
Rationale
Formal
Development
Informal
Requirement
Requirements
Analysis
Formal
specification
Validation
Automation
Based
Paradigm
Mechanical
Optimization
Turning
Maintenance
Fomal specification
Informal specification
Prototyping standard
Prototyping uncommon
Specification is the prototype
Prototype created manually
Prototype valided against intent
Code validated against intent
prototype becomes implementation
Prototype discarded
implementation machine aided
Implementation manual
Testing aliminated
Code tested
Formal Specification maintained Development
Concrete source code maintained
automaticallly documented
Design decidsions lost
Maintenance by replay
2009
Concrete
Source
Program
Maintenance by patching
234
Current paradigm
informal
Requirement
Requirements
Analysis
inFormal
specification
Concrete
Source
Program
coding
Validation
Validation
Maintenance
Testing
Turning
Maintenance
2009
235
次の文は正しいか？
• １．ソフトウエア開発プロセスを問題にするのは、
健全に開発をしたいが、最適な進め方が不明だ
から。
• ２.ソフトウエア開発プロセスモデルとは、開発プ
ロセスの雛形を指す。
• ３．ウォータフォール型では、各工程で正しい結
果が出たか検証して、合格なら次工程へ、さもな
ければ元へ戻る。
• ４．ラピッドプロトタイピング型の主目的は、早期
ベンチマークテストを実施し、基本構想の妥当性
を峻別することである。
2009
236

Download Report