軟件工程第4章

需求獲取SOFTWARE

ENGINEERING工程4.1

Capturing

the

requirements需求獲取Requirement: a

feature

of

the

system

or

adescription

of

something

the

system

iscapable

of ng

in

order

to

fulfill

thesystem’s

purpose需求是系統(tǒng)的特征，或為了實現系統(tǒng)目標系統(tǒng)能做什么的一個描述。需求過程是用來導出、確認和

系統(tǒng)需求文檔的一組結構化活動

需求分析的目標是準確理解用戶的要求，進行細致的

分析，將用戶的非形式的要求轉化為完整的需求定義，再將需求定義轉換為相應的形式的規(guī)格說明。需求分析工作是生存期中重要的一步，也是決定性的一步。只有通過需求功能和性能的總體概念描述分析才能把為具體的開發(fā)的基礎。需求規(guī)格說明，從而奠定需求分析工作也是一個不斷認識和逐步細化的過程。該過程將劃階段所確定的

范圍逐步細化到可詳細定義的程度，并分析出各種不同的

元素，然后為這些元素找到可行的解決方法。Why

are

requirements

important

?需求為什么重要？The

causesof

failed

projects

1994Standish

）1. plete

requirements

(13.1%)Lack

of

user

involvement

(12.4%)Lack

of

resources

(10.6%)Unrealistic

expectations

(9.9%)Lack

of

executive

support

(9.3%)不完整的需求缺少用戶的參與缺少資源不切實際的期望缺乏行政支持6.

Changing

requirements

and

specifications

(8.7%)改動需求和規(guī)格說明Lack

of

planning

(8.1%)System

no

longer

needed

(7.5%)缺少計劃不再需要該系統(tǒng)需求為何重要—有關錯誤的一些事實事實1在

生命周期中，一個錯誤發(fā)現得越晚，修復錯誤的費用越高階段相對修復費用需求階段0.1～0.2設計階段0.5編碼階段1單元測試階段2驗收測試階段5階段20表4.1

生命周期中修復

的相對費用需求為何重要—有關錯誤的一些事實事實2許多錯誤是潛伏的，并且在錯誤產生后很長一段時間才被檢查出來Boehm從TRW公司所做的

項目中得出結論：所有被檢測出來的錯誤中的54％實際上是在編碼和單元測試階段以后才被發(fā)現的；更糟糕的是，此類錯誤中的絕大部分（占45％）是屬于需求和設計階段的，而編碼階段的錯誤只占9％。需求為何重要—有關錯誤的一些事實事實3在需求過程中會產生很多錯誤DeMarco在一份

中，被檢查出來的錯誤的56％產生的根源可以追溯到需求階段。AIRMICS所進行的一項 發(fā)現，在一份軍方大型管理信息系統(tǒng)的需求規(guī)格說明書中存在著500多個錯誤，當然這僅僅是一個

項目中的一次需求為何重要—有關錯誤的一些事實事實4在需求階段，代表性的錯誤為不明確、疏忽、不一致和二義性研究

對 A7E飛機上的飛行操作程序進行實地測試，得出的研究數據表明：

A7E項目中77％的需求錯誤特點是不明確、疏忽、不一致和二義性。49％不正確的事實31％疏忽13％不一致5％

二義性2％

放錯位置需求為何重要—有關錯誤的一些事實事實5需求錯誤是可以被檢查出來的發(fā)現錯誤的方法 發(fā)現錯誤的比例（％）651056檢查單元測試集成測試演進其他Basili和Weiss的數據表明：在A-7E的 定義文檔中，33％的需求錯誤是通過人工檢查出來的。Celko覺得利用自動分析工具能夠從SRS中檢查出來相當數量的錯誤。需求為何重要—有關錯誤的一些事實由上面這些事實，能得出如下四點結論：在需求過程中會產生很多錯誤（事實3和4）許多錯誤并沒有在早期被發(fā)現（事實2）這樣的錯誤是能夠在產生的初期被檢查出來的（事實5）費用會–如果沒有及時檢查出來這些錯誤，直線上升（事實1）需求過程不僅是可能的而且也是值得的需求分析的任務“建造一個系統(tǒng)的最的部分是決定要建造什么……沒有別的工作在做錯時會如此影響最終系統(tǒng)，沒有別的工作比以后矯正更?！盕red

BrooksThe

process

of

determining

the

requirementsforasoftwarebasedsystem基于

系統(tǒng)的需求定義過程需求分析階段研究的對象是

項目的用戶要求。

開發(fā)項目是要實現目標系統(tǒng)的物理模型。作為目標系統(tǒng)的參考，需求分析的任務就是借助于當前系統(tǒng)的邏輯模型導出目標系統(tǒng)的邏輯模型，解決目標系統(tǒng)的"做什么"的問題。實現步驟如圖：1、獲得當前系統(tǒng)的物理模型所謂當前系統(tǒng)可能是需要改進的某個已在計算機上運行的數據處理系統(tǒng)，也可能是一個人工的數據處理過程。在這一步首先分析現實世界，理解當前系統(tǒng)是如何運行的，了解當前系統(tǒng)的組織機構、輸入輸出、資源利用情況和日常數據處理過程，并用一個具體模型來反映自己對當前系統(tǒng)的理解。這一模型應客觀地反映現實世界的實際情況。2

抽象出當前系統(tǒng)的邏輯模型在理解當前系統(tǒng)"怎樣做"的基礎上，抽取其"做什么"的本質，從而從當前系統(tǒng)的物理模型抽象出當前系統(tǒng)的邏輯模型。在物理模型中有許多物理的因素，隨著分析工作的深入，有些非本質的物理因素就成為不必要的負擔，因而需要對物理模型進行分析，區(qū)分出本質的和非本質的因素，去掉那些非本質的因素即可獲得反映系統(tǒng)本質的邏輯模3

建立目標系統(tǒng)的邏輯模型分析目標系統(tǒng)與當前系統(tǒng)邏輯上的差別，明確目標系統(tǒng)到底要"做什么"，從而從當前系統(tǒng)的邏輯模型導出目標系統(tǒng)的邏輯模型。具體做法：①

目標系統(tǒng)與當前系統(tǒng)在邏輯上的差別；②將變化的部分看做是新的處理步驟，對數據流圖進行調整；③由外向里對變更部分進行分析，憑經驗推斷其結構，獲得目標系統(tǒng)的邏輯模型。4、補充目標系統(tǒng)的邏輯模型補充內容包括：①說明目標系統(tǒng)的用戶界面。根據目標系統(tǒng)所處的應用環(huán)境及它與外界環(huán)境的相互關系，有可能與它發(fā)生聯(lián)系和作用的部分，從而決定人機界面。②說明至今尚未詳細考慮的細節(jié)。這些細節(jié)包括系統(tǒng)的啟動和結束、出錯處理、系統(tǒng)的輸入輸出和系統(tǒng)性能方面的需求。③其它。例如系統(tǒng)的其它必須滿足的性能和限制等等。需求分析的過程需求分析階段的工作，可以分成以下四個方面：問題識別（提?。┓治雠c綜合編制需求分析階段的文檔需求分析評審1

問題識別解決要求被開發(fā)

做什么，做到什么程度的問題。另外，需要建立分析所需要的通信途徑，以保證能順利地對問題進行分析。需求分析的通信途徑功能，2

分析與綜合進行各種要求的一致性分析檢查；從數據流和數據結構出發(fā)，逐步細化所有的功能；對數據域進行分解，并分配到各個子功能上，以確定系統(tǒng)的構成和各個主要成分；找出系統(tǒng)各成分之間的聯(lián)系、接口特性和設計上的限制。判斷是否存在因片面性或短期行為而導致的不合理的用戶要求，是否有用戶尚未 真正有價值的潛在要求。剔除其不合理的部分，增加其需要部分。綜

系統(tǒng)的解決方案，給出目標系統(tǒng)的詳細邏輯模型。3

編制需求分析階段的文檔需求說明書：把分析 和用戶雙方共同的理解和分析結果用規(guī)范的方式描述出來，作為今后各項工作的基礎；初步的用戶手冊：著重反映目標 的用戶功能界面和用戶使用的具體要求。用戶手冊能強制分析 從用戶使用的觀點來思考問題；編寫確認測試計劃，作為今后確認測試的依據；修改和完善 開發(fā)計劃：在需求分析階段對目標系統(tǒng)有了更進一步的了解，因此能夠更準確地估算開發(fā)成本、進度和資源需求，需要對 開發(fā)計劃做適當的修改。4

需求分析評審對功能的正確性、文檔的一致性、完備性、準確性和清晰性，以及其它需求給予評價。必須理解并描述問題的信息域，根據這條準則應該建立數據模型；必須定義應完成的功能，這條準則要求建立功能模型；必須描述作為外部事件結果的行為，這條準則要求建立行為模型；必須對描述信息、功能和行為的模型進行分解，用層次的方式展示細節(jié).需求分析的任務需求分析的原則.需要能夠表達和理解問題的信息域和功能域.以層次化的方式對問題進行分解和不斷細化.要給出系統(tǒng)的邏輯視圖和物理視圖需求分析形成需求文檔需求確認需求定義（不斷演進）需求規(guī)約（不斷演進）設計階段需求過程的總結需求提取需求提取、分析和協(xié)商的螺旋4.2

需求獲取技術需求獲取技術包括兩方面的工作：·建立獲取用戶要求的方法的框架；·支持和

需求獲取的過程的機制。Requiremen

icitation

需求提取（引出）需求提取是通過與客戶、系統(tǒng)用戶和其他與系統(tǒng)開發(fā)相關的

交流來發(fā)現需求的過程。必須從項目干系人的角度考慮問題，花時間找到他們的真正需求為提出系統(tǒng)需求，必須理解待解決問題、組織的

業(yè)務過程、系統(tǒng)可能使用方式、系統(tǒng)的應用領域，以及文檔中與系統(tǒng)相關的內容，

相關人員

他們需要的系統(tǒng)服務和系統(tǒng)約束主要來源是新系統(tǒng)的各種系統(tǒng)相關者，即項目干系人。主要考慮下面這些：1.系統(tǒng)的用戶，從兩個方向來收

料：流水平方向：在各分工協(xié)作部門中尋找物流、人力流信息流、單據流、報表流、數據流等流程。垂直方向：針對不同層次用戶提取業(yè)務操作用戶：錄入、修改、提交、處理、打印、界面、傳輸、通信、時間、速度等方面的需求管理用戶：業(yè)務管理、作業(yè)控制需求主管（決策）用戶：宏觀上的統(tǒng)計、查詢、決策需求系統(tǒng)需求的資料來源，項目預2.客戶：項目小組要向客戶匯算技術

：技術、

方面的需求從各類系統(tǒng)相關者中識別出關鍵的人做領域其他來源：領域模型當前的組織、系統(tǒng)、狀態(tài)模型現有文檔需求模板庫、可重用需求庫等系統(tǒng)需求的資料來源向用戶

需求

表召開需求調研會深入重點崗位了解實際業(yè)務工作邊收集分析、邊整理、邊征求修改意見定期向各用戶層次分別匯報、演示需求提取的實際入手方法確定系統(tǒng)的邊界從多個角度

待解決的問題對確定需求優(yōu)先級很有幫助：多個角度下都被建議的需求應該具有高優(yōu)先級需求提取中注意的事項Three

kinds

of

requirements

三類需求：those

thatabsolu y

must

be

met絕對需要滿足的需求those

that

are

highly

desirable

but

notnecessary想要但并非必須的需求those

that

are

possible

but

could

be

eliminated可以接受但也可以排除的需求“我知道你相信你已經理解了你認為我所說的內容，但是我并不能肯定你已經認識到你所聽到的并不是我所想要的?！毙枨筇崛≈凶⒁獾氖马椥枨螳@取的主要4.3

Types

and

Characteristics

of

requirements需求類型和特征sThe

requirements

definition

and

specificationdescribe

everything

about

how

the

system

is

to

interactwith

i

vironment.

Included

are

the

following

kindsOfitems.需求定義和詳細說明文檔描述了系統(tǒng)如何與環(huán)境交互的所有事情。包括：Physical

environmentInterfacesUsers

and

human

factorsFunctionalityationDataResourcesSecurityQuality

assurancePhysical

environment物理環(huán)境Where

is

the

equipment

to

function?設備在哪運行？Is

there

one

location

or

several?在一個地方還是多個地方？Are

there

any

environment

restrictions,

such

astemperature,

humidity,

or

magnetic

interference?是否有環(huán)境的限制，如溫度、濕度或電磁干擾等？Interfaces

接口Is

the

input

coming

from

one

or

more

other

systems?有來自其它系統(tǒng)的輸入嗎？Is

the

output

going

to

one

or

more

other

systems?有到其它系統(tǒng)的輸出嗎？Is

there

a

prescribed

wayin

which

the

data

must

beformatted?Is

there

a

prescribed

medium

that

the

datamust

use?對數據

介質有規(guī)定嗎？Users

and

human

factors用戶與人的因素Who

will

use

the

system?誰使用系統(tǒng)？Will

there

be

several

types

of

users?會有多種用戶嗎？What

is

the

skill

level

of

each

type

of

user?各種用戶熟練程度？What

kind

of

training

will

be

required

for

end

type

of

user?各類用戶需受什么類型的培訓？How

easy

will

it

be

for

a

user

to

understand

and

use

thesystem?用戶理解、使用系統(tǒng)的難度？How

difficult

will

it

be

for

auser

to

misuse

the

system?用戶錯誤操作系統(tǒng)的可能性？Functionality功能性t?What

will

the

system

do?系統(tǒng)做什么？What

will

the

system系統(tǒng)什么時候做？Are

there

several

modes

of

operation?操作是否有多種模式？

Howandwhencanthesystembechangedorenhanced？何時及如何改變或擴充系統(tǒng)？Are

there

constraints

on

execution

speed,

responsetime,

or

throughput?執(zhí)行速度、響應時間或吞吐量是否有限制？ation文檔ation

is

required?How

much需要多少文檔？Should

it

beon-line,

in

book

format,

orboth?印刷形式，還是兩種都要？ationTo

what

audience

is

each

type

ofaddressed?文檔針對哪些讀者？Data數據Forbothinputandoutput,whatshouldtheformatofthedatabe?輸入、輸出數據的格式？Howoftenwilltheybereceivedorsent?接收、發(fā)送數據的頻率？Howaccuratemusttheybe?數據的準確性要求多高？Towhatdegreeofprecisionmustthecalculationsbemade?計算精度要求多高？Howmuchdataflowthroughthesystem?系統(tǒng)中有多少數據流？Mustanydataberetainedforanyperiodoftime?數據在任何時段都要保存嗎？Resources資源What

materials

nelor

other

resources

are

requiredto

build,

use and

maintain

the

system?構造、

和使用系統(tǒng)時，需要哪些材料

或其它資源。What

skills

must

the

developers

have?開發(fā)

應該具有怎樣的技能。How

much

physical

space

will

be

taken

up

by

the

system?系統(tǒng)占據多少物理空間？heating orairWhat

are

the

requirements

for

powerconditioning?動力、供暖或空調的需求？Is

there

a

prescribed

timetable

for

development?有規(guī)定的開發(fā)時間表嗎？Is

there

a

limit

on

the

amount

of

money

to

be

spent

ondevelopment

or

on

hardware

and

software?開發(fā)或

硬件上有無

的限制？Security安全性Must

access

to

the

system

or

to

information

be

controlled?需要控制對系統(tǒng)或信息的

嗎？How

will

one

user’s

data

be

isolated

from

others?如何

用戶之間的數據？How

will

user

programs

be

isolated

from

other

programs

andfrom

the

operating

system?用戶程序如何與其它程序和操作系統(tǒng)

？How

often

will

the

system

be

backed

up?系統(tǒng)多久備份一次？Must

the

backup

copies

be

stared

at

a

different

location?備份拷貝要保存到其他地方嗎？Should

precautions

be

taken

against

fire water

damage,

ortheft?要采取預防措施防止水災、火災或者

嗎？Quality

assurance質量保證What

are

the

requirements

for

reliability,

availability,

maintainability,

security,and

the

other

quality

attributes

introduced

in

chapter

1?第一章中介紹的系統(tǒng)的可靠性、可用性、可

性、安全性和其他屬是什么？How

must

the

characteristics

of

the

system

be

demonstrated

to

others?要向其他人展示系統(tǒng)的特征嗎？Must

the

system

detect

and

isolate

faults?系統(tǒng)必須監(jiān)測和

錯誤嗎？What

is

the

prescribed

me between

failures?規(guī)定的平均故障間隔時間是多少？Is

there

a um

time

allowed

for

restarting

the

system

after

a

failure?產生故障后重啟系統(tǒng)允許的最大時間是多少？How

can

the

system

incorporate

changes

to

the

design?系統(tǒng)是怎樣將變動和設計相結合的？Will

maintenance

merely

correct

errors

or

will

it

also

include

improving

the

system?是只修改錯誤還是也包括對改進系統(tǒng)？What

efficiency

measures

will

apply

to

resource

usage

and

response

time?使用什么效率測量方法測量資源使用和響應時間How

easy

should

it

be

to

move

the

system

from

one

location

to

another

or

from

onetype

of

computer

to

another?將系統(tǒng)從一個地方移到另一個地方或者從一種計算機移到另一種計算機上容易嗎？Characteristics

of

requirements需求的特征Are

they

correct?Are

they

consistent?Are

they

complete?Are

they

realistic?需求是正確的嗎？需求是一致的嗎？需求是完整的嗎？需求是現實的嗎？Does

each

describe

something

the

customerneeds?是否每個需求都描述了顧客要求的某件事？Are

they

verifiable?Are

they

traceable?需求是可驗證的嗎？需求是可追蹤的嗎？關于需求的完整性Requirement

is

Completed:

if

all

possible

states,

statechanges,

inputs,

products,

and

constraints

are

described

bysome

requirement.需求是完整的：如果某些需求描述了所有可能的狀態(tài)，以及狀態(tài)的變化、輸入、過程和約束。A

system

description

is

externally

complete:

if

thedescription

constrains

all

the

proper

ties

to

the

environmentdesired

by

the

customer.系統(tǒng)描述是外部完整的：如果描述包含的所有關系都與顧客想要的環(huán)境相關時。A

system

description

is

internally

complete:

if

there

are

noundefined

references

among

the

requirements.系統(tǒng)描述是

完整的：需求之間沒有未定義的

。4.4

需求分析方法需求分析方法由對的信息域和功能域的系統(tǒng)分析過程及其表示方法組成。目前存在許多需求分析方法，每一種分析方法都引入了的不同的記號和分析策略。它們具有以下的共性:支持信息域分析的機制功能表示的方法接口的定義問題分解的機制以及對抽象的支持必須理解并描述問題的信息域，根據這條準則應該建立數據模型；必須定義應完成的功能，這條準則要求建立功能模型；必須描述作為外部事件結果的行為，這條準則要求建立行為模型；必須對描述信息、功能和行為的模型進行分解，用層次的方式展示細節(jié).需求分析的任務Natural

language

may

not

bethe

precise

andunambiguous

medium

needed

for

expressing

thesystem’s

functionality

and

the

relationship

of

itsrelevant

parts.

Requirements

are

not

always

easilyseparated

according

to

the

system

elements

withwhich

they

deal.

Theuse

of

natural

languagecanadd

to

confusion

here.How

to

express

requirementsWe

have

investigated

many

ways

to

definerequirements

in

a

more

rigorous

andcontrolled

fashion.應用更嚴格、更受約束的方式來定義需求。需求的描述分為靜態(tài)描述和動態(tài)描述A

system

description

lists

the

system

entitiesor

objects,

their

attributes,

and

their

relationswith

each

other.

but

it

does

not

describe

howrelationships

change

with

time.

this

view

isstatic.Static

descriptions

of

requirements需求的靜態(tài)描述方法Indirect

reference

and

RecurrencerelationsExample: k

equations

in

n

variables(n元k個方程)F(0)=1;

F(1)=1;

F(n+1)=F(n)+F(n-1)Axiomatic

definition<condition><bool-term>::=::=<bool-term>

|

<bool-term>

or<condition><bool-factor>

|

<bool-factor>

and

<bool-term><bool-factor>::=<expr>

<relop>

<expr>

|(<condition>)<relop>::=<

|

<

|

=

|

>

|

>

|

<

><expr>::=<term>

|

<expr>

<addop>

<term>

|

<addop>

<expr><term>::=<factor>

|

<term>

<mpyop>

<factor><factor>::=<scaled-expr>

|

<primary><scaled-expr><primary><number><regname><integer><regchar><addop><digit>::=::=(<expr>)<scale>

|

<number>

<scale>::=

(<expr>)

<regname>

|

<number>

|

<func>

(<expr>)::=

<integer>

|

<integer>.

|

.<integer>

|

<integer>.<integer>::=

$

<regchar>

|

<regname>

<regchar>::=

<digit>

|

<digit>

<integer>::=

<digit>

|

<letter>

|

<underscore>::=

+

|

-0

|

1

|

2

|

3

|

4

|

5

|

6

|

7

|

8

|

9<func>::=abs

|

trunc<letter>::=A

|

a

|

B

|

b|

C

|

c

|

D

|

d

|

E

|

e

|.

.

.

|

Y<myop>|

y

|

Z

|::=z*

|

/

|

mod<scale>::=c

|

d

|

h|

i

|

l

|

P

|

p

|

q

|

t

|

v<underscore>::=_

(ASCII

character95)Expression

as

a

languageData ion

數據抽象Semester

recordSemester

typeSemester

dateGrade-pointaverageCompleted

hoursSemester

type(Fall,

Spring,

Summer)Address

informationephone

numberStreet

address

CityStatePostal

codeStudent

recordNameStudent

numberAddress

informationNumberof

semesters{Semester

record}Dynamic

descriptions

動態(tài)描述Decision

tables判定表High

standardizHigh

gradesOutside

activitieGood

recommeSend

rejection

lend

admission表的左端為條件和動作，表中的數據表示處于的狀態(tài)和要遵守的規(guī)則?！癟”表示條件為真，“F”表示條件 -”表示無所謂，“X”表示采取的動作。如果一個需求(數據流圖的加工)需要依賴于多個邏輯條件的取值，使用判定表來描述比較合適。判定表商店業(yè)務處理系統(tǒng)中“檢查發(fā)貨單”判定樹也是用來表達加工邏輯的一種工具。有時侯它比判定表更直觀。檢查發(fā)貨單金額>$500金額$500欠款>60天欠款60天發(fā)貨單不發(fā)出批準書發(fā)出批準書、欠款>60天發(fā)出批準書、發(fā)貨單及賒欠報告欠款60天發(fā)出批準書、發(fā)貨單判定樹Functional

descriptions

and

transition

d

agrams功能性描述與變遷圖f(Si,

Cj)

SkTable

4.2.

Transition

table.Current

stateInputNext

stateS10S2S11S1S20S2S21S1S30S1S31S3變遷表狀態(tài)遷移圖(簡稱為狀態(tài)圖)通過描繪系統(tǒng)的狀態(tài)及引起系統(tǒng)狀態(tài)轉換的事件，來表示系統(tǒng)的行為狀態(tài)：狀態(tài)是任何可以被觀察到的系統(tǒng)行為模式，規(guī)定了系統(tǒng)對事件的響應方式事件：在某個特定時刻發(fā)生的事情，它是對引起系統(tǒng)做動作或(和)從一個狀態(tài)轉換到另一個狀態(tài)的外界事件的抽象狀態(tài)遷移圖狀態(tài)轉換圖狀態(tài)遷移圖和與其等價的狀態(tài)轉換表示例柵欄圖Jackson

的有限狀態(tài)機4 Event

tables事件表Table

4.3.

Event

table.ModeEvent

1Event

2Event

3Event

4GraphicsAction

1Action

80XArchitectureXAction

2

followed

by

Action

3Actions

5

and

6

in

parallel0Native0Action

4Actions

1,

2

and

3Action

7Petri網，簡稱PNG

(Petri

Net

Graph)

最早是作為表達異步系統(tǒng)的控制規(guī)則的圖形表示法提出來的，現在已廣泛地應用于硬件與系統(tǒng)的開發(fā)中，它適用于描述與分析相互獨立、協(xié)同操作的處理系統(tǒng)，也就是并發(fā)執(zhí)行的處理系統(tǒng)。5 Petri

NetPetri網是一種有向圖，它有兩種結點：位置（

place）：符號為“○”，它用來表示系統(tǒng)的狀態(tài)。轉移（

transition

）：符號為“

”

或“︱”，它用來表示系統(tǒng)中的事件。圖中的有向邊表示對轉移的輸入，或由轉移的輸出：“→”表示事件發(fā)生的前提，即對轉移（事件）的輸入，“︱→”表示事件的結果，即由轉移（事件）的輸出。Petri

Net稱轉移的啟動為激發(fā)或開火（fire），它是轉移的輸出；只有當作為輸入的所有位置的條件都滿足時才標記

或稱令牌(token)，是表明系統(tǒng)當前處于什么狀態(tài)的標志5

Petri網處理兩個進程的同步問題Additional

notations

其他方法Hierarchical

techniques（Warnier

diagrams）Structured ysis

and

Design

Technique(SADT)Object-oriented

specifications面 象的規(guī)格說明層次方框圖:

用樹形結構的一系列多層次的矩形描述數據的層次結構層次技術Warnier

DiagramsWarnier

圖示例報紙專欄的數據層次結構○+IPO圖（input

,processing

,output)其他圖形工具改進的IPO圖其他圖形工具Douglas

Ross提出，由DeMarco推廣，由Ward和Mellor以及后來的Hatley和Pirbhai

構化分析方法的框架。結構化分析方法是一種建模技術。它建立的分析模型

。這種分析模型必須達到三個主要目標：(1)

描述用戶要求；(2)

建立(3)

定義設計的基礎；開發(fā)完成時必須確認的一組需求。在模型的是數據詞典，它描述了所有的在目標系統(tǒng)中使用的和生成的數據對象。圍繞著這個的有三種圖：實體 關系圖(ERD)描述數據對象及數據對象之間的關系；數據流圖(DFD)描述數據在系統(tǒng)中如何被傳送或變換，以及描述如何對數據流進行變換的功能（子功能）；狀態(tài)

遷移圖(STD)描述系統(tǒng)對外部事件如何響應，如何動作。（2）功能建模和數據流（3）行為建模（4）數據詞典數據建模數據模型包括三種互相關聯(lián)的信息：數據對象描述對象的屬性描述對象間相互連接的關系數據建模方法用來創(chuàng)建部分分析模型，但它也可以用于數據庫設計并支持其他的需求分析方法。1數據對象數據對象是需被目標系統(tǒng)所理解的復合信息的表示。所謂復合信息是具有若干不同特征或屬性的信息。數據對象可以是外部實體（如顯示器），事物（如報表或顯示），角色（如教師或學生），行為（如一個

呼叫）或事件（如單擊鼠標左鍵），組織單位（如院），地點（如室）或結構（如文件）。數據對象只封裝了數據，沒有包含作用于這些數據上的操作。這與面象開發(fā)方法中的類和對象不同。具有相同特征的數據對象組成的集合仍然稱為數據對象，其中的某一個對象叫做該數據對象的一個實例。2、屬性屬性定義了數據對象的特可用來：(1)

為數據對象的實例命名；描述這個實例；建立對另一個數據對象的另一個實例的。如學生數據對象的屬性可以有學號、出生年月、籍貫等。為了唯一地標識數據對象的某一個實例，定義數據對象中的一個屬性或幾個屬性為關鍵碼(key)，書寫為_id，例如在"學生"數據對象中用"學號"做關鍵碼，它可唯一地標識一個"學生"數據對象中的實例。3、關系各個數據對象的實例之間可以按多種不同的方式相連接。4、基數和參與性提供更進一步的有關數據對象關聯(lián)的信息。實例的關聯(lián)有三種：①

一對一

；②

一對多(1:m)；③

多對多(n:m)。這種實例的關聯(lián)稱為“基數”?；鶖当砻髁恕爸貜托浴薄?

―關系圖數據對象及其關系可用ERD表示。ERD最初是由PeterChen為關系數據庫提出來的，后來又經過了擴展。ERD的主要目的是表示數據對象及其關系。它包括的基本成分有數據對象、屬性、關系和各種類型符號。實體―關系圖的建立步驟(1)在捕獲需求的過程中，要求用戶列出應用或業(yè)務過程涉及到的所有“事物”。這些事物將來可能會演變?yōu)橐幌盗械妮斎?輸出數據對象以及生產和消費信息的外部實體。(2)一次考慮一個對象。分析和用戶共同確認這個對象與其他對象之間是否存在連接（在本階段不命名）。(3)

當存在連接時，分析

和用戶應創(chuàng)建一個或多個對象--關系對。(4)對每一個對象--關系對，它的基數和參與性。(5)迭代執(zhí)行步驟(2)～(4)，直到所有對象--關系對定義完成。在這個過程中發(fā)生遺漏是很正常的。在每次迭代時總會增加新的對象和關系。(6)(7)規(guī)范化并復審實體--關系圖。(8)重復執(zhí)行步驟(1)～(7)，直到數據建模完成。E-R圖中表示實體聯(lián)系的符號如下：在E-R圖中，每個方框表示實體型或屬性，方框之間的連線表示實體之間，或實體與屬性之間的聯(lián)系。出現在連線上的短豎線可以看成是“1”，而圓圈隱含表示“0”。例如，在教學管理中，一個教師可以教授零門、一門或多門課程，每位學生也需要學習幾門課程。因此，教學管理中涉及的對象（實體型）有學生、教師和課程。用E-R圖描述它們之間的聯(lián)系，得下圖。其中，學生與課程是多對多的聯(lián)系，而教師與課程的聯(lián)系是一對零或多。、專確定屬性。例如，學生具有學號、業(yè)（其它略）等屬性；課程具有課程號、課程名、學分、學時數等屬性；等教師具有職工號、屬性。此外，學生通過學號、分數與課程發(fā)生聯(lián)系。如此可得教學實體模型。教學實體模型數據規(guī)范化的目的：為減少數據冗余，避免出現過程，通常用“范式(normal

forms)”定義消除數據冗余的程度數據規(guī)范化每個屬性值都必須是原子值，即僅僅是一個簡單值而不含 結構，第一范式（1NF）第二范式滿足第一范式條件，而且每個非關鍵字屬性都由整個關鍵字決定(而不是由關鍵字的一部分來決定)第二范式（2NF）數據冗余：同一門課程由n個學生選修，“學分”就重復n-1次；同一個學生選修了m門課程，

和

就重復了m-1次。更新異常：若調整了某門課程的學分，數據表中所有行的

“學分”值都要更新，否則會出現同一門課程學分不同的情況。異常：假設要開設一門新的課程，暫時還沒有人選修。這樣，由于還沒有“學號”關鍵字，課程名稱和學分也無法記錄入數據庫。刪除異常：假設一批學生已經完成課程的選修，這些選修記錄就應該從數據庫表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。第二范式（2NF）的例子把選課關系表SelectCourse改為如下三個表：學生：Student(學號,

,

)；課程：Course(課程名稱,

學分)；選課關系：SelectCourse(學號,課程名稱,成績)。這樣的數據庫表是符合第二范式的，消除了數據冗余

更新異常、

異常和刪除異常。所有單關鍵字的數據庫表都符合第二范式

因為不可能存在組合關鍵字。第二范式（2NF）的例子第三范式符合第二范式的條件，且非主屬性相互獨立，即任何非主屬性間不存在函數依賴。假定學生關系表為Student(學號,,,所在學院,學院地點,學院)，關鍵字為單一關鍵字“學號”(學號)→(,,所在學院,學院地點,學院電話)這個數據庫是符合2NF的，但是不符合3NF，因為存在非關鍵字段“學院地點”、“學院”對非關鍵字段“所在學院”的函數依賴：(所在學院)→(學院地點,學院)第三范式（3NF）功能建模和數據流最初，結構化分析方法僅數據流建模。目標系統(tǒng)被表示成數據變換流程圖。系統(tǒng)的功能體現在核心的數據變換中。系統(tǒng)的輸入源于用方框表示的外部實體，這種輸入系統(tǒng)的數據變換，產生傳遞給外部實體的輸出。功能建模的思想就是用抽象模型的概念，按照數據傳遞、變換的關系，自頂向下逐層分解，直到找到滿足功能要求的所有可實現的為根據DeMarco

了數據流圖來表達系統(tǒng)內數據的運動情況，而數據流的變換則用結構化語言、判定表與判定樹來描述。1、數據流圖（Data

Flow

Diagrams）DFD的符號或數據的源點/終點或或變換數據的處理/加工/變換數據

（文件）數據流源點和終點源點和終點是系統(tǒng)之外的實體，可以是人、物或其他系統(tǒng)。源點和終點是為了幫助理解系統(tǒng)接口而引入的。加工/變換對數據進行處理的單元。在分層數據流圖中，要對加工進行

，以便于管理。加工也要選取適當的名字，以提高數據流圖的易讀性。DFD的符號數據流由一組數據項組成。例如，數據流“訂票單由住址航班號、日期始點終點等數據項組成；數據流“航班”由航班號、日期和等數據項組成數據流可以從加工流向加工，如“航班”、

“費用”；可以從源點流向加工，或從加工流向終點；可以從加工流向數據或從數據流向加工DFD的符號文件用來暫時 數據的。如果加工要讀文件，則數據流的方向是從文件到加工；如果加工要寫文件，則數據流的方向是從加工到文件；如果加工既要讀文件又要寫文件，則數據流的方向是雙向的DFD的符號旅行社旅客預定機票機票準備記帳DFDDFD的符號++AB⊕C有A或有B，但不能A、B同時存在，就有C采購部每天需要一張定貨報表通過放在倉庫中的CRT終端把事務報告給定貨系統(tǒng)。怎樣畫DFD：定貨系統(tǒng)的例子怎樣畫DFD：定貨系統(tǒng)的例子源點/終點采購員倉庫管理員數據流定貨報表零件 零件名稱定貨數量

目前價格主要供應者

次要供應者事務零件事務類型數量處理產生報表處理事務數據定貨信息（同定貨報表）庫存零件庫存量庫存量臨界值定貨系統(tǒng)的基本系統(tǒng)模型定貨系統(tǒng)的功能級數據流圖把處理事務的功能進一步分解后的數據流圖2、分層數據流圖為了表達數據處理過程的數據加工情況，用一個數據流圖是不夠的。稍為復雜的實際問題，在數據流圖上常常出現十幾個甚至幾十個加工。這樣的數據流圖看起來很不清楚。層次結構的數據流圖能很好地解決這一問題。按照系統(tǒng)的層次結構進行逐步分解，并以分層的數據流圖反映這種結構關系，能清楚地表達和容易理解整個系統(tǒng)。把基本系統(tǒng)模型加上源點和終點作為頂層數據流圖自頂向下逐層畫數據流圖的步驟分層的數據流圖分層的數據流圖分層的數據流圖畫數據流圖不是畫流程圖父圖和子圖的平衡問題局部文件的問題命名問題畫數據流圖需要注意的幾個問題12435763.13.23.33.43.63.5ACBYEXWVFDGHDFGH父圖和子圖的平衡問題12344.44.34.24.1AGCBFDEEHLFG1323.13.2考生成績錄取通知書考生準考證號通訊地址考生成績文件(數據

)總是局部于分層數據流圖的某一層或某幾層,所以數據流圖中引入的文件都是局部文件局部文件的問題12.132.242.3ABCABCDEG2FFED一個加工的分解最好不要超過9個子加工。超過9個時，可以用增加層次，減少子加工數的方法。分解在邏輯上應合

能硬性分割。也就是說，要根據問題的邏輯特性進行分解。在保證數據流的易理解的前提下，盡量減少分解層次。這樣可以減少層次的界面。分解要均勻。即在一張數據流圖中，不要有這樣的情況：有些加工已是基本加工，另一些加工還要分解好幾層，但絕對均勻不可能，不要相差太大。數據流命名名字應代表整個數據流（有時也會把現實環(huán)境中傳遞的一組數據中最重要的那個數據的名字作為數據流的名字）命名問題（數據流）考生成績分類后的考生成績錄取分類現實環(huán)境中，傳遞的一些表格、單據的名字可以直接作為數據流的名字。命名問題（數據流）車間調度全廠統(tǒng)計生產報表統(tǒng)計表日報表月報表不要使用空洞的、缺乏具體含義的名字控制流作為數據流。如果在為某個數據流命名時遇到

，可能是數據流圖分解不當，應考慮重新分解DFD命名問題（數據流）錄取分類取下一個考生成績加工（處理）命名頂層的加工名可以是項目的名字。不要使用空洞的、缺乏具體含義的名字。通常先為數據流命名，然后再為與之相關聯(lián)的處理命名。這樣命名比較容易，而且體現了人類

的“由表及里”的思考過程。如果在為某個加工命名時遇到

，可能是數據流圖分解不當，應考慮重新分解DFD。命名問題（處理）加工的名字最好由一個謂語動詞加上一個賓語組成。如“計算運費”、“準備機票

。也可以把賓語和謂語動詞顛倒書寫。如“運費計算”、“機票準備”。名字應該反映整個處理的功能，而不是它的一部分功能。通常名字中僅包括一個動詞，如果必須用兩個動詞才能描述整個處理的功能，則把這個處理再分解成兩個處理可能更恰當些。命名問題（處理）從數據流圖出發(fā)出結構從數據流圖出發(fā)出結構3

加工規(guī)格說明用來說明DFD中的數據加工的加工細節(jié)。加工規(guī)格說明描述了數據加工的輸入，實現加工的算法以及產生的輸出。另外，加工規(guī)格說明指明了加工（功能）的約束和限制，與加工相關的性能要求，以及影響加工的實現方式的設計約束。寫加工規(guī)格說明的主要目的是要表達"做什么"，而不是"怎樣做"。因此它應描述數據加工實現加工的策略而不是實現加工的細節(jié)。用于寫加工邏輯說明的工具結構化英語（Structured

English）判定表（Decision

Table）判定樹（Decision

Tree）是一種介于自然語言和形式化語言之間的語言。結構化英語的詞匯表由英語命令動詞；數據詞典中定義的名字；有限的自定義詞；控制結構CASE_OFIF_THEN_ELSEWHILE_DOREPEAT_UNTIL等組成。結構化英語語言的正文用基本控制結構進行分割，加工中的操作用自然語言短語來表示其基本控制結構有三種：簡單陳述句結構；重復結構：while do

或

repeat_until

結構；判定結構：if_then

或

case_of

結構；if

發(fā)貨單金額超過$500

thenif

欠款超過了60天then在償還欠款前不予批準else

（欠款未超期）發(fā)批準書，發(fā)貨單else

（發(fā)貨單金額未超過$500）if

欠款超過60天then發(fā)批準書，發(fā)貨單及賒欠報告else

（欠款未超期）發(fā)批準書，發(fā)貨單例：商店業(yè)務處理系統(tǒng)中“檢查發(fā)貨單”4

針對實時系統(tǒng)的Ward&Mellor擴展為適應實時系統(tǒng) 以下要求進行的擴展：(1)在時間連續(xù)的基礎上接收或產生數據流；(2)貫穿系統(tǒng)的控制信息和相關的控制處理；在多任務的情況下可能會遇到同一個加工的多個實例；系統(tǒng)狀態(tài)以及導致系統(tǒng)狀態(tài)遷移的機制。時間連續(xù)的數據流與普通數據流事件可以作為普通數據加工的輸入數據流，控制也可以接收普通的輸入數據流。5

Hatley和Pirbhai對結構化分析技術的擴展該擴展主要關注面向控制的規(guī)格說明，而不是擴充數據流圖的圖形符號。通過建立控制流圖(CFD)以區(qū)別于數據流圖(DFD)。在控制流圖中的加工與數據流圖中相同，但傳遞的是控制流而不是數據流。用數據流圖表示對數據和操作數據的加工；用控制流圖表示事件在加工之間如何流動，說明導致各個加工激活的外部事件。Ward

&

Pirbhai方法行為建模行為建模給出需求分析方法的所有操作原則，只在結構化分析方法的擴充版本才提供這種建模的符號。行為建模的工具：1、狀態(tài) 遷移圖Petri網控制規(guī)格說明（狀態(tài)

遷移圖(STD)

、加工激活表

）數據字典（DD）數據詞典精確地、嚴格地定義了每一個與系統(tǒng)相關的數據元素，并以字典式順序將它們組織起來，使得用戶和分析員對所有的輸入、輸出、

成分和中間計算有共同的理解。數據詞典表示每個數據對象和控制項的特性數據字典是對數據流圖中包含的所有元素的定義的集合，使得每個圖形元素都有確切解釋。數據字典與數據流圖共同構成系統(tǒng)的邏輯模型，數據子詞典與數據流圖配合，能清楚地表達數據處理的要求。詞條描述是對在數據流圖中每一個被命名的圖形元素的定義，內容有:圖形元素名字、別名或、分類、描述、定義、位置、其它等。定義絕大多數復雜事物的方法，都是用被定義的事物的成分的某種組合表示這個事物，這些組成成分又由更低層的成分的組合來定義。順序即以確定次序連接兩個或多個分量選擇即從兩個或多個可能的元素中選取一個重復即把指定的分量重復零次或多次可選即一個分量是可有可無的(重復零次或一次)符號含義舉例＋“被定義為與x=a＋bx由a和b組成或

x=[a,b]，

x由a或由b組成或

x=[a

|b]，

x由a或由b組成重復

x={a}，

x由0個或多個a組成重復

x=3{a}8，x由3到8個a組成可選

x

=(a)，在x中a可有可無[...

,

...][...|...]{

...

}m{...}n(...)“...”..基本數據元素

x=“a”，x是取值為a的元素連結符

x

=

1..9，x可取1到9中任一值數據流條目中出現的符號數據流是數據結構在系統(tǒng)內

的路徑。一個數據流詞條應有以下幾項內容：數據流名；說明：簡要介紹作用即它產生的原因和結果；數據流來源：來自何方；數據流去向：去向何處；數據流組成：數據結構；每個數據量的流通量：數據量，流通量；（1）數據流詞條描述數據流條目的例子數據流條目的例子戶名＋所號＋帳號＋

日＋性質＋(印密)＋1{存取行}50戶名＝2{字母}24所號＝“001”..“999”帳號＝“00000001”..“99999999”日

年＋月＋日

1”..“6”

注：“1”表示普通戶，“5”表示工資戶等印密＝“0”

注：印密在

上不顯示存取行＝日期＋（

）＋支出＋存入＋余額＋操作＋復核DFD中每個數據結構都是由數據元素構成的，數據元素是數據處理中最小的、不可再分的單位，它直接反映事物的某一特征，其描述需要以下信息：數據元素名；編碼類類型：數字（離散值，連續(xù)值）型）；長度；取值范圍；相關的數據元素及數據結構；（2）數據元素詞條描述數據元素條目描述在實際應用中，對數據流和數據元素的描述可以靈活地剪裁，數據流元素的描述也可以采用和數據流相似的方式。例如：名字（數據流名）：定貨報表別名：定貨信息描述（說明）：每天一次送給采購員的需要定貨的零件表定義（數據流組成）：定貨報表

零件

+零件名稱+定貨數量+目前價格+主要供應者+次要供應者位置（數據流去向）：輸出到名字：定貨數量別名：描述：某個零件一次定貨的數量定義：定貨數量=1{數字}5位置（相關的數據結構）：定貨報表定貨信息數據文件是數據結構保存的地方。本類詞條應有以下內容：數據文件名；簡述：存放的是什么數據；輸入數據；輸出數據；數據文件組成：數據結構；方式：順序

直接，關鍵碼；存取頻率；（3）數據文件詞條描述加工到后來就是一段程序，它的表達方式有判定表、判定樹、結構化英語等，在一個詞條中。主要內容有：全部描述有加工名；加工加工的層次；簡要描述：加工邏輯及功能簡述；輸入數據流；輸出數據流；加工邏輯：簡述加工程序，加工順序；（4）加工邏輯詞條描述對于數據處理系統(tǒng)來說，源點和匯點應比較少，否則就會缺少獨立性，人機界面太立性。復雜，這時應考慮減少以提高系這類詞條應包括：名稱：外部實體名；簡要描述：什么外部實體；有關數據流；數目；（5）源點及匯（終）點詞條描述分房標準文件住房文件住房文件房租文件調房咨詢退房查詢住戶情況、查詢房租統(tǒng)計數據流分析實例房管部門住戶檢查要求處理類型分配住房房租計算調房退房處理統(tǒng)計咨詢類別處理住房查詢房租查詢打印處理消去房租調房處理房租核計核對條件住房住房標準文件住房文件房租文件文件住房文件住房文件房租文件文件Object-oriented

specifications面 象的規(guī)格說明Each

entity

in

thesystem

isan

objectA

method

oroperation

is

an

action

thatcanbeperformed

directly

by

the

object

or

can

happen

totheobjectEncapsulation:

the

methods

form

a

protectiveboundary

around

an

objectClass

hierarchies

of

objec courage

inheritancePolymorphism: same

method

for

different

objects,each

with

different

behavior4.5

prototy

requirementsRapidprototy原型化需求buildsections

of

theproposedsystem

to

determine

the

necessity,desirability,orfeasibilityofrequirements.快速原型化構造了部分期望的系統(tǒng)來確定需求的必要性、愿望或可行性。A

prototypegives

us

the

opportunity

to“fine

tune”what

our

customers

wantor

whatwe

think

willworkbest

ina

design.原型給了我們“調整”顧客想要什么或者我們認為在設計中會最有效的東西的機會。

原型化方法是在研究需求分析階段的方法和技術中產生的，它主要針對傳統(tǒng)方法所的

。因此，也面向

開發(fā)的其它項目的特點和運行原型的目的不同，原型有三種不同的作用類型：探索型、實驗型、演化型。探索型：目的是要弄清對目標系統(tǒng)的要求，確定所希望的特性，并探討多種方案的可行性要針對開發(fā)目標模糊，用戶和開發(fā)者對項目都缺乏經驗的情況。之前，考核方案是實驗型：用于大規(guī)模開發(fā)否合適，規(guī)格說明是否可靠。演化型：目的不在于改進規(guī)格說明，而是將系統(tǒng)建造得易于變化，在