需求工程-軟件建模與分析

1、1 問題分析的主要步驟（五步）？ (1) 在問題定義上達成共識； (2) 理解根本原因，分析問題背后的問題； (3) 確定相關人員和用戶； (4) 定義解決方案的界限； (5) 確定加在解決方案上的約束。2 魚骨圖主要用于定性分析，帕累托圖主要用于定量分析。3 魚骨圖、帕累托圖構建的主要步驟？ 魚骨圖 A 選擇問題 首先選擇一個具體的問題或者結果。在選擇問題時，要保證問題是專門的、定義嚴謹?shù)?、范圍相對較小的（對于大范圍的問題往往需要考慮將其分解成相對較小的問題），并且保證參與人員切實理解要分析的內容。對問題定義產(chǎn)生出來的問題一般都應該進行一次獨立的魚骨圖分析。 B 頭腦風暴 就導致問題的可能原

2、因進行頭腦風暴。將大家提出的意見記錄下來，確認后貼到魚骨圖上。 需要注意的是不要將原因和解決方案混為一談。在確定原因的分類前先進行頭腦風暴（一個人提，大家批），不然思考問題的范圍就會受到限制。支持者需要引導和鼓勵參與者參與其中。 C 確定問題類型 對頭腦風暴的結果進行整理，確定出主要的原因類型。一般來說，劃分出來的問題不要少于2類，不要超過6類（經(jīng)驗數(shù)值，僅供參考）。經(jīng)常使用的類型有：人、設備、材料、環(huán)境、方法、過程等。將這些類型補充到魚骨圖上。 D 分配原因 將頭腦風暴中得出的潛在原因放在魚骨圖上，并且確保每一項原因都歸于適當?shù)念悇e中。如果原因看起來可以放在多個類別中，就表示是多重原因造成的

3、問題。但如果多次出現(xiàn)多重原因，可能就以為著分類存在問題。該階段將形成最終的魚骨圖E 分析根本原因 對魚骨圖中羅列出來的所有潛在原因進行分析。分析出造成某一結果的最根本原因是什么？找出核心所在。 方法如下： 通過參與者之間的公開討論來分享看法和經(jīng)驗； 尋找重復的原因，或者與特定類有關的原因的數(shù)量； 使用檢查表收集資料、制造流程圖或者進行用戶調查， 通過帕累托分析法測試各種原因的相對強度； 投票（真理多數(shù)情況下掌握在多數(shù)人手里） 帕累托圖 在通過使用魚骨圖完成問題原因的定性描述后。仍然存在一個問題，就是根本原因的辨識需要有經(jīng)驗的決策者確定，或者根據(jù)人類固有經(jīng)驗（少數(shù)服從多數(shù)）確定。更好地方法是能夠

4、開展定量分析。帕累托分析可以幫助我們做出這樣的定量分析。帕累托分析應用就是根據(jù)魚骨圖分析的結果，通過收集相關統(tǒng)計資料，通過直方圖的方式顯示問題的相對頻度或者大小高低等定量結果。A 確定問題和相關原因 利用魚骨圖的結果。B 收集數(shù)據(jù) 有針對性第收集數(shù)據(jù)。例如上例中，我們可以抽取一些廢品，分析這些廢品產(chǎn)生的原因C 繪制直方圖4 上下文圖畫法步驟？ 在繪制上下文關系圖時應該采用以下步驟：1、首先用一個矩形表示系統(tǒng)，寫上系統(tǒng)的名稱，將整個系統(tǒng)看做一個黑盒子；2、然后找到該系統(tǒng)的所有Customer(客戶)，考慮這些Customer會發(fā)起什么事件，這些事件會引發(fā)Worker(內部工作人員)的什么工作，將

5、這些序列逐一表示出來；3、最后在看看系統(tǒng)的每個Worker還有沒有一些主動發(fā)起的事件。（Customer：也就是該主題域的客戶，它處于該主題域的外部。如，對于體檢業(yè)務子系統(tǒng)而言，體檢者顯然就是一類客戶，除此之外，客服中心、物資部門、財務部門的工作人員也是這個主題域的Customer。Worker：也就是該主題域的工作人員，它處于該主題域的內部。如，服務中心，體檢科室，綜合科的工作人員都是其Worker。關鍵要點在于“針對本主題域”而言。）5需求獲取的主要活動研究應用背景，建立初始的知識框架；根據(jù)獲取的需要，采用必要的獲取方法和技巧；先行確定獲取的內容和主題，設定場景；分析用戶的高（深）層目標，

6、理解用戶的意圖；進行涉眾分析，針對涉眾的特點開展工作。6需求協(xié)商的幾條法則的應用？差異問題協(xié)調法則：不同的業(yè)務層面（有時即使是相同業(yè)務層面）的用戶對同樣的概念或者流程有不同的認識和理解，會出現(xiàn)一些差異，在需求整理時應該將這些差異明確標識出來，并展示給用戶高層管理人員，由他們來確定如何消除這些差異，并將這些情況記錄。消除變更問題協(xié)調法則：上面法則提到的問題，從消除變更的角度考慮仍然存在問題。僅僅將差異標識并展示給高層并不能消除變更的可能，應該考慮這些差異形成背后的問題，應該從開發(fā)角度考慮如何消除這些差異，并提供給高層管理人員。要有主動性需求協(xié)商時機法則：不要在需求凍結前開展需求協(xié)商工作。需求協(xié)商

7、應該在需求獲取過程中不斷開展，出現(xiàn)就考慮消除。如果都等到凍結前，將所有矛盾集中體現(xiàn)對工作是非常不利的。實例：W公司開發(fā)的信息系統(tǒng)到了需求凍結前夕，A建立拿出厚厚一本需求協(xié)商底稿，分為重點差異協(xié)調部分，一般差異協(xié)調部分，已協(xié)調差異列表。結果用戶高層非常不滿，認為這些工作需要大量時間難以短期完成。7需求獲取的主要方法用戶訪談用戶調查文檔分析原型法（情節(jié)串聯(lián)板）模型驅動的方法8開放式話題與封閉式話題運用開放式話題優(yōu)點：讓被會見者感到自在；會見者可以收集被會見者使用的詞匯，這能反應他的教育、價值標準、態(tài)度和信念；提供豐富的細節(jié)；對沒采用的進一步的提問有啟迪作用；讓被會見者更感興趣；容許更多的自發(fā)性；會

8、見者可以在沒有太多準備的情況下進行面談。缺點：提此類問題可能會產(chǎn)生太多不相干的細節(jié)；面談可能失控；開放式的回答會花費大量的時間才能獲得有用的信息量；可能會使會見者看上去沒有準備封閉式話題優(yōu)點：節(jié)省時間；切中要點；保持對面談的控制；快速探討大范圍問題；得到貼切的數(shù)據(jù)缺點：使得被會見者厭煩；得不到豐富的細節(jié)；出于上述原因，失去主要思想；不能建立和面談者的友好關系。 9用戶訪談時問題組織的三種方式及特點？金字塔結構如果會見者認為被會見者需要對話題進行預熱，可以采用金字塔結構，通過逐步的引導來使得被會見者打開話匣子。如果會見者發(fā)現(xiàn)自己事先對事實的確認存在較大偏差或者被會見者看上去不情愿討論這個話題，也

9、可以采用金字塔結構。當想結束討論這個話題的時候，使用金字塔結構的提問順序也是有用的。 漏斗結構漏斗結構為開始一場面談提供了一種容易而輕松的途徑。當被會見者對這個話題有情緒，并且需要自由表達這些情緒的時候，需要采用漏斗型提問順序?；蛘咴跁娬呤孪葘κ聦嵙私獠欢鄷r，也應該采用漏斗結構的問題組織方式。用這種方式組織面談能得出很多的詳細信息，以至于沒有必要使用長序列的受限制問題和調查問題。 菱形結構使用菱形結構的主要優(yōu)點是通過各種各樣的問題保持被會見者的興趣和注意力。一旦掌握了如何在正確的時間問正確的問題，就可以多樣地選擇問題的順序。 10市場調查和需求獲取在訪談與調查順序上有何不同?原因何在？一般來

10、說，在開展市場調查時，由于很難深入接觸到潛在的用戶。所以總是先調查，后訪談。而在需求獲取時，通常采用的策略是先訪談，后調查。 其實原因在于市場調查與需求獲取有不同的應用背景。一般市場調查通常用于驗證潛在客戶對產(chǎn)品的接受程度。而需求獲取的目標是要理解客戶需要解決的問題。 也就是說需求獲取時你往往還沒有產(chǎn)品，信息不夠充分，所以很難設計出有效的調查問卷。11采用原型方法的三個目的？明確并完善需求 原型作為一種需求工具，它是對部分系統(tǒng)的初步實現(xiàn)，因為我們尚沒有很好地了解該系統(tǒng)。研究設計選擇方案 原型作為一種設計工具，涉眾可以用它研究不同的用戶交互技術，優(yōu)化系統(tǒng)易用性，并評估可能的技術方案。發(fā)展為最終產(chǎn)

11、品 原型作為一種構造工具，是產(chǎn)品一個最初子集的完整功能實現(xiàn)。12用例描述方法13需求關系的根本任務是什么？ 需求分析是軟件需求中最核心的工作，需求建模是需求分析的主要手段。需求分析是軟件定義時期的最后一個階段，它的基本任務是準確地回答“系統(tǒng)必須做什么?”這個問題。需求分析的任務還不是確定系統(tǒng)怎樣完成它的工作，而僅僅是確定系統(tǒng)必須完成哪些工作，也就是對目標系統(tǒng)提出完整、準確、清晰、具體的要求。需求分析根本任務：建立分析模型，創(chuàng)建解決方案。14需求分析任務中分解策略主要包含那幾種？每種策略分別適合應用于那些系統(tǒng)的開發(fā) 1）業(yè)務流程為主線的分解策略；業(yè)務流程為主線的分解策略是目前比較流行的方法，主要

12、按照“業(yè)務”的角度考慮分解方法。此方法特別適合聯(lián)機事務處理系統(tǒng)、管理信息系統(tǒng)（MIS）。目標系統(tǒng)-主題域的分解依據(jù)是“目標決定范圍”；主題域-業(yè)務事件所做的是理清業(yè)務脈絡；業(yè)務事件-業(yè)務活動所做的是填充細節(jié)；業(yè)務活動-業(yè)務步驟所做的是細化和確認工作。2）程序結構為主線的分解策略； 方法是需求分析最常用的分解方法。當由于其過早進入程序結構，割裂了與問題域之間的聯(lián)系，從而容易導致對問題域研究的不足，降低了需求的質量。目前認為此種方法僅適合于問題域比較清晰，問題不算復雜的情況，例如工具軟件、嵌入式系統(tǒng)等。3）基于場景的分解策略； 對于決策支持系統(tǒng)、面向用戶的嵌入式系統(tǒng)等來說，決策場景、使用場景是主要

13、的線索。向上可以總結成一類相似的集合，再總結成一系列的關注點或者功能域，向下可以分解成具體的步驟或者操作任務。4）基于數(shù)據(jù)的分解策略等。 上述分解策略都是從“業(yè)務”角度來組織。但對于類似數(shù)據(jù)倉庫之類的數(shù)據(jù)類項目，業(yè)務線索并不是十分明顯，或者并不重要這是就需要以數(shù)據(jù)為主的分解策略。其中主題域仍然與“業(yè)務流程為主的分解策略”類似。而主題類是企業(yè)中的高層實體，主要由一組企業(yè)的邏輯數(shù)據(jù)類來表示，而企業(yè)的邏輯數(shù)據(jù)類在實現(xiàn)時又會對應于多個物理數(shù)據(jù)類。15 需求分析中分解與提煉的比較？ 分解是一種自頂向下的方法，當按照任何一種線索進行分解時。就會破壞其它線索的完整性。例如，如果以“業(yè)務”為線索，就會發(fā)現(xiàn)數(shù)據(jù)

14、需求分解后會出現(xiàn)相互交疊的情況，也就是在多個業(yè)務事件中都涉及相同的類。 此種情況出現(xiàn)時，可能會影響需求分析人員建立全面的理解，因此需要采用自底向上的方法進行提煉。例如將每個業(yè)務事件中的類進行提煉，抽取出共性的部分，建立針對整個系統(tǒng)的全局領域模型。16構建分析模型的目的？ 1將復雜的系統(tǒng)分解成為簡單的部分以及它們之間的聯(lián)系，確定本質特征2和用戶達成對信息內容的共同理解3分析的活動主要包括識別、定義和結構化，它的目的是獲取某個可以轉換為知識的事物的信息17分析模型的建模方法？模型 “模型是對事物的抽象，幫助人們在創(chuàng)建一個事物之前可以有更好的理解” 集中關注問題的計算特性（數(shù)據(jù)、功能、規(guī)則等等） “

15、它是對系統(tǒng)進行思考和推理的一種方式。建模的目標是建立系統(tǒng)的一個表示，這個表示以精確一致的方式描述系統(tǒng)，使得系統(tǒng)的使用更加容易” 建模方法抽象分解投影抽象（Abstraction）一方面要求人們只關注重要的信息，忽略次要的內容通過強調本質的特征，就減少了問題的復雜性（例如學生模型）另一方面也要求人們將認知保留在適當?shù)膶哟?，屏蔽更深層次的細?jié)在問題的各元素之間推斷出更廣泛和更普遍的關系，幫助人們尋找解決方案分解（Decomposition / Partitioning）“分而治之” 將單個復雜和難以理解的問題分解成多個相對更容易的子問題，并掌握各子問題之間的聯(lián)系分解的方案往往還能提供問題的解決思路

16、投影（Projection）多視點方法 18實際的建模過程中要遵循的建模原則？ 在建模時，要注意考慮到計劃之外的變化：設計要文檔化，只有這樣，才能使不熟悉的新手也可以有效地利用設計的方案。用可視化的模型表達現(xiàn)實世界，有助于理解變化所代表的含義。 在實際的建模過程中要遵循以下建模原則：模型是用來溝通的；選擇創(chuàng)建什么模型對如何解決問題和如何形成解決方案具有深遠的影響。每種模型可以在不同的精度級別上表示；最好的模型是與現(xiàn)實相聯(lián)系的模型；單個模型往往不夠充分，對每個重要的系統(tǒng)最好用一組幾乎獨立的模型去處理。19需求建模的流程？ 先依據(jù)獲取的問題域信息建立初步的模型。然后分析用戶需求，對模型進行調整，得

17、到一個中間形式的模型形式。最后，對調整后的模型進行邏輯推理和驗證，如果符合預期的期望，那么它就是最終的解決方案模型。 20 常見的需求分析技術？ 結構化技術數(shù)據(jù)建模實體關系圖Entity Relationship Diagram過程建模數(shù)據(jù)流圖Data Flow Diagram上下文圖Context Diagram微規(guī)格說明Mini-Specification數(shù)據(jù)字典Data Dictionary行為建模狀態(tài)(轉換)圖/矩陣State (Transition) Diagram/Matrix過程/數(shù)據(jù)關系建模功能實體矩陣Function/Entity Matrix信息工程方法功能分解圖Funct

18、ion Decomposition Diagram過程依賴圖Process Dependency Diagram面向對象技術UML用例圖Use-Case Diagram類圖Class Diagram交互圖（順序圖/通信圖）Interaction（Sequence / Communication）Diagram活動圖Activity Diagram對象約束語言Object Constraint Language狀態(tài)圖State Chart Diagram正確認識UML（2）（3）（4）() UML的準確理解UML是一種語言（Language）實際上UML就是一種表示方法，它不是方法論。UML是一

19、種建模語言（Modeling Language）它不是編程語言，而是建模語言。它不僅包含軟件建模，而且可用于業(yè)務建模、流程建模等多種領域。UML是統(tǒng)一建模語言（Unified Modeling Language ）它是一種標準化的、統(tǒng)一的建模語言，OMG認可的工業(yè)標準，也是如IBM、SUN等大型公司認可的事實標準。(3) 為什么要使用UMLUML是一種統(tǒng)一的、標準化的建模語言，它為參與軟件設計和開發(fā)的各類人員提供統(tǒng)一的語言，使開發(fā)人員能夠基于共的模型來理解業(yè)務、需求，理解軟件及其架構如何構造的。(4) 如何使用UMLUML2.0標準中，共定義了13種不同的圖，這些圖的功能以及與UML1.0之間

20、的關系如下表圖名功能備注類圖描述類、類特性及類間關系UML1.0原有對象圖描述一個時間點上系統(tǒng)各個對象的一個快照UML1.0非正式圖復合結構圖描述類的運行時刻的分解UML2.0新增構件圖描述構件的結構和連接UML1.0原有部署圖描述在各個節(jié)點上的部署UML1.0原有包圖描述編譯時的層次結構UML1.0非正式圖用例圖描述用戶與系統(tǒng)如何交互UML1.0原有活動圖描述過程行為與并行行為UML1.0原有狀態(tài)圖描述事件如何改變對象生命周期UML1.0原有順序圖描述對象之間的交互、重點在于強調順序UML1.0原有通信圖描述對象之間的交互、重點在于連接UML1.0中的協(xié)作圖定時圖描述對象之間的交互、重點在于

21、定時UML2.0新增交互概觀圖是一種順序圖與活動圖的混合UML2.0新增如何使用UML-需求階段一般常采用的圖使用頻率圖名功能關注要點主體用例圖說明角色和使用場景之間的關系人活動圖說明業(yè)務流程，以及業(yè)務活動的步驟事順序圖描述對象之間的交互物類圖說明業(yè)務實體之間的關系，體現(xiàn)結構規(guī)則物輔助構件圖說明主題域劃分以及他們之間的服務接口接口部署圖描述系統(tǒng)的部署環(huán)境，體現(xiàn)設計約束設計約束22 結構化分析遵循的三條原則？結構化分析遵循的三條基本原則： 分解 抽象 映射23結構化分析模型的構成元素？ 數(shù)據(jù)字典(DD) 模型核心，包含了所有數(shù)據(jù)對象的描述的中心庫。E-R圖(ERD)表示數(shù)據(jù)對象以及相互的關系，用

22、于數(shù)據(jù)建模。數(shù)據(jù)流圖(DFD) 指明數(shù)據(jù)在系統(tǒng)中移動時如何被變換;描述對數(shù)據(jù)流進行變換的功能; DFD中每個功能的描述包含在加工規(guī)約(小說明)。用于功能建模。狀態(tài)變遷圖(STD) 指明作為外部事件的結果,系統(tǒng)將如何動作。用于行為建模。24結構化建模示例-建立計算機售書系統(tǒng)的邏輯模型 通過對現(xiàn)實環(huán)境的調查，獲得當前系統(tǒng)的物理模型。 （2 ） 去掉具體模型中的非本質因素：抽取現(xiàn)實系統(tǒng)的實質，抽象出當前系統(tǒng)的邏輯模型。 （3）分析當前系統(tǒng)與目標系統(tǒng)的差別，建立目標系 統(tǒng)的邏輯模型 。（4）對目標系統(tǒng)的邏輯模型進行細化、改進與優(yōu)化（5）需求分析的驗證25 數(shù)據(jù)流圖（DFD）第9章PPT 第20-69頁

23、數(shù)據(jù)流圖（DFD：Data Flow Diagram）就是組織中信息運動的抽象，是信息邏輯系統(tǒng)模型的主要形式。這個模型不涉及硬件、軟件、數(shù)據(jù)結構與文件組織，它與對系統(tǒng)的物理描述無關，只是用一種圖形及與此相關的注釋來表示系統(tǒng)的邏輯功能，即所開發(fā)的系統(tǒng)在信息處理方面要做什么。由于圖形描述簡明、清晰，不涉及到技術細節(jié)，所描述的內容是面向用戶的，所以即使完全不懂信息技術的用戶單位的人員也容易理解。因此數(shù)據(jù)流圖是系統(tǒng)分析人員與用戶之間進行交流的有效手段，也是系統(tǒng)設計（即建立所開發(fā)的系統(tǒng)的物理模型）的主要依據(jù)之一。數(shù)據(jù)流圖脫離系統(tǒng)中的物理因素(如計算機等)，表達出系統(tǒng)對信息的加工情況。DFD可以描述原系統(tǒng)

24、/新系統(tǒng)/子系統(tǒng)。DFD是SA的主要工具，它簡單、直觀，用圖形、文字描述系統(tǒng)。它便于使用、便于交流、便于討論、便于形成共識，是計算機專業(yè)人員和用戶單位業(yè)務人員的共同語言。DFD由四種基本符號組成。如下圖所示。數(shù)據(jù)流圖的構成及基本元素外部項（外部實體）源點和終點(又稱端點)是系統(tǒng)外的實體，稱作外部項。它們存在于環(huán)境之中，與系統(tǒng)有信息交流，從源點到系統(tǒng)的信息叫系統(tǒng)的輸入；從系統(tǒng)到終點的信息稱系統(tǒng)的輸出。同一個端點可以是人或其它系統(tǒng)。在DFD中引入源點和終點是為了便于理解系統(tǒng)，所以不需要詳細描述它們。它們可有編號，以“S”開頭。外部實體外部實體是指處于待構建系統(tǒng)之外的人、組織、設備或者其他軟件系統(tǒng)，

25、它們不受系統(tǒng)的控制，開發(fā)者不能以任何方式操縱它們。需要進行建模的外部實體是那些和待構建的軟件系統(tǒng)之間存在著數(shù)據(jù)交互的外部實體，它們是待構建系統(tǒng)的數(shù)據(jù)源或者數(shù)據(jù)目的地所有的外部實體聯(lián)合起來構成了軟件系統(tǒng)的外部上下文環(huán)境 引入外部項是為了劃定系統(tǒng)的邊界，不需嚴格定義。但也要統(tǒng)一編號，而且要與數(shù)據(jù)字典中的編號相一致。源點和終點可以在多處出現(xiàn)，用特定符號表示重復的外部項。為了使DFD清楚易懂，我們對加工、數(shù)據(jù)流、文件的命名都力求簡單。至于加工的加工邏輯、數(shù)據(jù)流的數(shù)據(jù)結構等，將在數(shù)據(jù)字典中定義。數(shù)據(jù)字典和DFD一起來描述系統(tǒng)。 常見的外部項（外部實體）有：a)從待構建系統(tǒng)中獲取數(shù)據(jù)或者為其提供數(shù)據(jù)的組織

26、，如：供貨方，銷售方等。b)需要和待構建系統(tǒng)交互的個人，如：顧客，辦事員。c)需要和待構建系統(tǒng)交換數(shù)據(jù)的其他軟件系統(tǒng)。加工加工又稱處理亦稱變換，它表示對數(shù)據(jù)流的操作。加工的符號分成上、下兩部分，從上到下分別是標識部分和功能描述部分。標識部分用于標注加工編號，加工編號應具有唯一性，以標識加工，以“P”開頭。功能描述部分用來寫加工名。為使DFD清晰易讀，加工名應簡單，能概括地說明對數(shù)據(jù)的加工行為，其詳細描述在數(shù)據(jù)詞典中定義。加工要逐層分解，以求得分解后的加工功能簡單、易于理解。數(shù)據(jù)流數(shù)據(jù)流由一個或一組確定的數(shù)據(jù)項組成。 數(shù)據(jù)流名應能直觀地反映數(shù)據(jù)流的含義。如產(chǎn)量日報表、匯款單、錄取通知書、課程表等

27、。也可以用一組數(shù)據(jù)中的主要數(shù)據(jù)為數(shù)據(jù)流命名。例如“考生成績單由考生姓名、成績、通訊地址等數(shù)據(jù)組成，但成績是主要的，所以可用“考生成績”作為數(shù)據(jù)流的名字。 數(shù)據(jù)流應統(tǒng)一編號，編號要與數(shù)據(jù)字典一致。 數(shù)據(jù)流經(jīng)過一個加工后其數(shù)據(jù)結構/數(shù)據(jù)含義/數(shù)據(jù)的順序一定要有所變化，否則這個加工就沒有意義了。數(shù)據(jù)存儲（文件） 數(shù)據(jù)存儲是用來存貯數(shù)據(jù)的。在分層DFD中，數(shù)據(jù)存儲一般僅屬于某一層或某幾層，因此又稱數(shù)據(jù)存儲為局部文件。現(xiàn)對數(shù)據(jù)存儲符號說明如下：數(shù)據(jù)存儲名寫在開口的長方框內，應概要地說明文件中的主要數(shù)據(jù)。數(shù)據(jù)存儲上一定要有數(shù)據(jù)流。為便于說明和管理，數(shù)據(jù)存儲亦應編號，編號寫在文件符號左端小方格中，以“D”開

28、頭。為避免DFD中出現(xiàn)交叉線，同一數(shù)據(jù)存儲可在多處畫出。數(shù)據(jù)流圖的繪制步驟（1）確定所開發(fā)的系統(tǒng)的外部項（外部實體），即系統(tǒng)的數(shù)據(jù)來源和去處。（2）確定整個系統(tǒng)的輸出數(shù)據(jù)流和輸入數(shù)據(jù)流，把系統(tǒng)作為一個加工環(huán)節(jié)，畫出關聯(lián)圖。（3）確定系統(tǒng)的主要信息處理功能，按此將整個系統(tǒng)分解成幾個加工環(huán)節(jié)（子系統(tǒng)）確定每個加工的輸出與輸入數(shù)據(jù)流以及與這些加工有關的數(shù)據(jù)存儲。 （4）根據(jù)自頂向下，逐層分解的原則，對上層圖中全部或部分加工環(huán)節(jié)進行分解。（5）重復步驟（4），直到逐層分解結束。（6）對圖進行檢查和合理布局，主要檢查分解是否恰當、徹底，DFD中各層是否有遺漏、重復、沖突之處，各層DFD及同層DFD之間關

29、系是否合理，及命名、編號是否確切、合理等，對錯誤與不當之處進行修改。（7）和用戶進行交流，在用戶完全理解數(shù)據(jù)圖的內容的基礎上征求用戶的意見。 數(shù)據(jù)流圖繪制規(guī)則(1)過程是對數(shù)據(jù)的處理，必須有輸入，也必須有輸出，而且輸入數(shù)據(jù)集和輸出數(shù)據(jù)集應該存在差異。 (2)數(shù)據(jù)流是必須和過程產(chǎn)生關聯(lián)的，它要么是過程的數(shù)據(jù)輸入，要么是過程的數(shù)據(jù)輸出。(3) DFD當中所有的對象都應該有一個可以唯一標識自己的名稱。過程使用動詞外部實體、數(shù)據(jù)流和數(shù)據(jù)存儲使用名詞數(shù)據(jù)流圖繪制過程繪制數(shù)據(jù)流圖的主要原則 （1）明確系統(tǒng)邊界。 （2）自頂向下逐層擴展。（3）合理布局。（4）數(shù)據(jù)流圖繪制過程，就是系統(tǒng)的邏輯模型的形成過程，

30、必須始終與用戶密切接觸，詳細討論，不斷修改，也要和其他系統(tǒng)建設者共同商討一求一致意見。數(shù)據(jù)流圖應用示例-銀行取款系統(tǒng) 簡單銀行取款應用描述(1）儲戶將填好的取款單、存折交銀行，銀行做如下處理： 審核并查對帳目，將不合格的存折、取款單退回儲戶，合格的存折、取款單送取款處理。 處理取款修改帳目，將存折、利息單、結算清單及現(xiàn)金交儲戶，同時將取款單存檔。畫出銀行取款處理數(shù)據(jù)流圖。第一步，畫出關聯(lián)數(shù)據(jù)流圖。注意，現(xiàn)金是實物，不能作為數(shù)據(jù)流。第二步，逐層分解加工，畫出下層DFD。數(shù)據(jù)流圖應用示例-圖書預定系統(tǒng)圖書預訂系統(tǒng)：書店向顧客發(fā)放訂單，顧客將所填訂單交由系統(tǒng)處理，系統(tǒng)首先依據(jù)圖書目錄對訂單進行檢查并

31、對合格訂單進行處理，處理過程中根據(jù)顧客情況和訂單數(shù)目將訂單分為優(yōu)先訂單與正常訂單兩種，隨時處理優(yōu)先訂單，定期處理正常訂單。最后系統(tǒng)根據(jù)所處理的訂單匯總，并按出版社要求發(fā)給出版社。 畫出圖書預定系統(tǒng)的各層數(shù)據(jù)流圖。第一步，畫出關聯(lián)數(shù)據(jù)流圖。 第二步，逐層分解加工，畫出下層DFD。注意到根據(jù)題意，當繪出系統(tǒng)頂層圖后并不能將所有加工分解成基本加工，還要進行二層圖分解。并在分解加工過程中逐步充實進數(shù)據(jù)存儲。見圖。 數(shù)據(jù)流圖的作用前面說過，系統(tǒng)分析的主要任務是建立新系統(tǒng)的邏輯模型。具體地講主要是畫出新系統(tǒng)的DFD，編寫定義DFD的數(shù)據(jù)詞典。 建立新系統(tǒng)的DFD是一項十分重要的工作。因為建立的DFD是系統(tǒng)

32、開發(fā)乃至系統(tǒng)維護的依據(jù)，是系統(tǒng)的重要文檔之一。系統(tǒng)分析員要在詳細調查中，在與用戶的反復交流中修改DFD，力求新建DFD是正確的、準確的。DFD的層級結構 依據(jù)所含過程的不同抽象程度，DFD可以在不同的抽象層次上進行系統(tǒng)的描述 一個比較抽象的過程可以被展開為一個子過程更加具體的DFD圖DFD的層次結構上下文圖0層圖N層圖（N0）關于上下文圖將整個系統(tǒng)看做是一個過程，這個過程實現(xiàn)系統(tǒng)的所有功能 ，是系統(tǒng)功能的最高抽象 上下文圖中存在且僅存在一個過程，表示整個系統(tǒng)。這個單一的過程通常編號為0 上下文圖中需要表示出所有和系統(tǒng)交互的外部實體，并描述交互的數(shù)據(jù)流，包括系統(tǒng)輸入和系統(tǒng)輸出 上下文圖中不會出現(xiàn)

33、數(shù)據(jù)存儲實例 它非常適合于描述系統(tǒng)的應用環(huán)境、定義系統(tǒng)的邊界 關于0層圖位于上下文圖下面一層，是上下文圖中單一過程的細節(jié)描述，是對該單一過程的第一次功能分解 是整個系統(tǒng)的功能概圖 0層圖應該被描述的簡潔、清晰，需求工程師要根據(jù)系統(tǒng)的復雜度掌握0層圖中過程的抽象程度關于N層圖對0層圖的過程分解產(chǎn)生的子圖稱為1層圖，對N層圖的過程分解后產(chǎn)生的子圖稱為N+1層圖（N0） ，過程分解是可以持續(xù)進行的，直至最終產(chǎn)生的子圖都是原始DFD圖原始DFD圖可以進一步展開為微規(guī)格說明數(shù)據(jù)字典在低于0層圖的子圖上通常不顯示外部實體 層次結構的構建建立步驟創(chuàng)建上下文圖 發(fā)現(xiàn)并建立DFD片斷 根據(jù)DFD片斷組合產(chǎn)生0層

34、圖；對0層圖的過程進行功能分解，產(chǎn)生N層圖 創(chuàng)建上下文圖 在需求獲取階段獲得的業(yè)務需求以及業(yè)務需求所決定的項目前景與范圍可以用來幫助建立系統(tǒng)的上下文圖。發(fā)現(xiàn)并建立DFD片段DFD片斷是系統(tǒng)對某個事件的響應過程的DFD描述，它是為系統(tǒng)中發(fā)生的重要事件創(chuàng)建的。它將系統(tǒng)對事件的處理看做是一個單一的過程，重點描述這個單一過程與事件外界（包括系統(tǒng)內其他部分和系統(tǒng)外的外部實體）的數(shù)據(jù)流交互。產(chǎn)生0層圖往往需要多次調整DFD片段的整合結果才能得出對DFD圖（尤其是0層圖）質量的判定有下面幾個準則：1、沒有語法錯誤，遵守前述的各項規(guī)則。2、具有良好的語義，過程的功能設置要高內聚、低耦合。3、保持數(shù)據(jù)一致性，過

35、程的輸入流要足以產(chǎn)生數(shù)據(jù)輸出。同時過程的輸出流是在充分利用輸入數(shù)據(jù)的基礎上產(chǎn)生的，不存在輸入數(shù)據(jù)的浪費。4、控制復雜度，不要一次在圖中顯示太多的信息。一般情況下，一個圖中的過程數(shù)量最好控制在59（人腦的最佳信息處理量）個。而且圖中的數(shù)據(jù)流數(shù)量越少越好，越簡潔越好（接口最小化）。功能分解產(chǎn)生N層圖功能分解是一個拆分功能的描述，將單個復雜的過程變?yōu)槎鄠€更加具體、更加精確和更加細節(jié)的過程。 在功能分解過程當中，最重要的是要保證分解過程的平衡性（Balance） ，它要求DFD子圖的輸入流、輸出流必須和父過程的輸入流、輸出流保持一致 。在分解產(chǎn)生的子圖為下述情景之一時，可以判定其為原始DFD圖，此時應

36、該停止持續(xù)的功能分解活動：所有過程都已經(jīng)被簡化為一個選擇、計算或者數(shù)據(jù)庫操作；所有數(shù)據(jù)存儲都僅僅表示了一個單獨的數(shù)據(jù)實體；用戶已經(jīng)不關心比子圖更為細節(jié)的內容，或者子圖的描述已經(jīng)詳細的足以支持后續(xù)的開發(fā)活動；每一個數(shù)據(jù)流都已經(jīng)不需要進行更詳細的切分，以展示對不同數(shù)據(jù)的不同處理方式；每一個業(yè)務表單、事務、計算機的屏幕顯示（computer on-line display）和業(yè)務報表都已經(jīng)被表示為一個單獨的數(shù)據(jù)流；系統(tǒng)的每一個最低層菜單選項都能在子圖中找到獨立的過程。 層次結構的建立-示例使用DFD描述常見的電梯控制系統(tǒng)。一個控制系統(tǒng)控制多個電梯。每個電梯被置于一個相應甬道之中，在卷揚電機的作用下在

37、甬道內做上下運動。甬道內安裝有多個傳感器，通常每個電梯?？奎c一個，用來感應電梯的實時位置。電梯內部和建筑的每個電梯停靠層都設置有指示器，用來告知用戶的電梯實時位置和運動狀況。電梯內和建筑的每個電梯?？繉佣荚O有按鈕，用戶可以通過這些按鈕提出服務申請并進出電梯?？刂葡到y(tǒng)調度用戶的申請，讓電梯以最有效的方式滿足用戶的服務要求。層次結構的建立-建立DFD片斷 層次結構的建立- 建立0層圖DFD驗證驗證DFD的語法 確保DFD中不會發(fā)生語法錯誤 驗證DFD的結構 驗證DFD層次結構之間的一致性 驗證DFD層次結構說明的完備性 驗證DFD的語義 確保DFD所說明內容的正確性和準確性 26 數(shù)據(jù)字典 數(shù)據(jù)字

38、典的提出背景：雖然數(shù)據(jù)流圖能夠形象、清晰地描述數(shù)據(jù)在系統(tǒng)中流動、加工、存儲的情況，但數(shù)據(jù)流圖中的許多構成元素，如數(shù)據(jù)流、數(shù)據(jù)存儲、加工，僅依靠名稱并不能反映其本質含義，因此必須對這些構成元素進行嚴格的定義。作為對數(shù)據(jù)流圖的補充，數(shù)據(jù)字典(DD，Data Dictionary)能夠準確地定義數(shù)據(jù)流圖中各組成成分的具體含義，二者共同構成了系統(tǒng)的邏輯模型。數(shù)據(jù)字典是一個儲存庫，包含軟件使用和產(chǎn)生的所有數(shù)據(jù)對象的描述，其中也包括DFD當中數(shù)據(jù)流和數(shù)據(jù)存儲的定義。有組織地列出DFD中的涉及的所有數(shù)據(jù)元素（數(shù)據(jù)流、數(shù)據(jù)存儲），并定義每個數(shù)據(jù)元素的名稱別名使用地點使用方法使用范圍描述 單位/格式名稱數(shù)據(jù)元素

39、的原始名稱別名數(shù)據(jù)元素的其他名稱使用地點會使用該數(shù)據(jù)元素的過程使用方法該數(shù)據(jù)元素扮演的角色（輸入流、輸出流或者數(shù)據(jù)存儲等）使用范圍該數(shù)據(jù)元素存在的范圍描述對數(shù)據(jù)元素內容的描述單位/格式數(shù)據(jù)元素的數(shù)據(jù)類型，可能事先設置的取值數(shù)據(jù)字典中的基本元素和含義符號含義示例=包含，由構成Name=first_name+last_name+指明序列結構()內容可選Phone_No.=(Area_No.)+Local_No.內容多選一Number=0|1|2|3|4|5|6|7|8|9|分割內部的多個選項nm循環(huán),最少n次,最多m次Area_No=3Number4數(shù)據(jù)存儲的標識符(關鍵字)Student=ID+

40、Name+.*注釋Area_No=3Number4*區(qū)號為3到4位數(shù)字數(shù)據(jù)字典中的條目及說明格式數(shù)據(jù)字典是關于數(shù)據(jù)流圖中各種成分詳細定義的信息集合，可將其按照說明對象的類型劃分為四類條目，分別為數(shù)據(jù)流條目、數(shù)據(jù)項條目、數(shù)據(jù)文件條目和數(shù)據(jù)加工條目。數(shù)據(jù)字典的任務是: 對于數(shù)據(jù)流圖中出現(xiàn)的所有被命名的圖形元素在字典中作為一個詞條加以定義，使得每一個圖形元素的名字都有一個確切的解釋。(1)數(shù)據(jù)流條目數(shù)據(jù)流在數(shù)據(jù)流圖中主要用于說明數(shù)據(jù)結構在系統(tǒng)中的作用和流動方向，因此數(shù)據(jù)流也被稱作“流動的數(shù)據(jù)結構”。數(shù)據(jù)字典中數(shù)據(jù)流條目應包括以下幾項主要內容：數(shù)據(jù)流名稱、數(shù)據(jù)流別名、說明、數(shù)據(jù)流來源、數(shù)據(jù)流流向、數(shù)據(jù)

41、流組成和數(shù)據(jù)流量等。數(shù)據(jù)流詞條的描述示例:數(shù)據(jù)流名：發(fā)票說明：用作學生已付書款的依據(jù)數(shù)據(jù)流來源：來自加工“審查并開發(fā)票” 數(shù)據(jù)流去向：流向加工“開領書單”。數(shù)據(jù)流組成：學號+姓名+書號+單價總價+書費合計 數(shù)據(jù)流詞條的描述示例2： 工資系統(tǒng)中的出勤表數(shù)據(jù)流在數(shù)據(jù)字典中的條目描述為:數(shù)據(jù)流名稱：出勤表數(shù)據(jù)流別名：無說明：由人事部門每月月底上報的職工考勤統(tǒng)計數(shù)字數(shù)據(jù)流來源：人事部門數(shù)據(jù)流流向：加工1.1.1(統(tǒng)計出勤、請假及曠工時數(shù))數(shù)據(jù)流組成：出勤表 = 年份+月份+職工號+出勤時數(shù)+病假時數(shù)+事假時數(shù)+曠工時數(shù)數(shù)據(jù)流量：1份/月 (2)數(shù)據(jù)項條目 數(shù)據(jù)流圖中每個數(shù)據(jù)結構都是由若干個數(shù)據(jù)項構成的

42、，數(shù)據(jù)項是加工中的最小單位，不可再分。數(shù)據(jù)字典的數(shù)據(jù)項條目中應包含的主要內容有：數(shù)據(jù)項名稱、數(shù)據(jù)項別名、說明、類型、長度、取值范圍及含義等。 例如：出勤表中的職工號數(shù)據(jù)項在數(shù)據(jù)字典中的條目描述為 數(shù)據(jù)項名稱：職工號 數(shù)據(jù)項別名：employee_no 說明：本單位職工的惟一標識 類型：字符串 長度：6 取值范圍及含義：12位(00.99)為部門編號：36位(XX0001.XX9999)為人員編號 (3)數(shù)據(jù)文件條目 數(shù)據(jù)文件是數(shù)據(jù)流圖中數(shù)據(jù)結構的載體。數(shù)據(jù)字典的數(shù)據(jù)文件條目中應包含的主要內容有：數(shù)據(jù)文件名稱、說明、數(shù)據(jù)文件組成、組織方式、存取方式、存取頻率等。 例如：工資系統(tǒng)中的職工工資檔案文

43、件在數(shù)據(jù)字典中的條目描述為 數(shù)據(jù)文件名稱：工資檔案 說明：單位職工的基本工資、各項津貼及補貼信息 數(shù)據(jù)文件組成：職工號+國家工資+國家津貼+職務津貼+職齡津貼+交通補貼+部門補貼+ 其他補貼 組織方式：按職工號從小到大排列 存取方式：順序存取頻率：1次/月(4)數(shù)據(jù)加工條目 在數(shù)據(jù)流圖中只簡單給出了每個加工的名稱，在數(shù)據(jù)字典中通過數(shù)據(jù)加工條目主要是要說明每個加工是用來“做什么”的。數(shù)據(jù)字典的數(shù)據(jù)加工條目中應包含的主要內容有： 數(shù)據(jù)加工名稱、加工編號、說明、輸入數(shù)據(jù)流、輸出數(shù)據(jù)流、加工邏輯等。 例如：工資系統(tǒng)中的計算應發(fā)工資這個加工在數(shù)據(jù)字典中的條目描述為 數(shù)據(jù)加工名稱：計算應發(fā)工資 加工編號：

44、1.2 27 ERD建模示例 簡單情況下ERD建模（1）從描述信息中辨識實體 可以重點關注描述信息中的名詞，看系統(tǒng)是否需要收集其相關的特征（2）確定實體的標識符 （3）建立實體間關系判斷各個關系的建立是否會產(chǎn)生新的關聯(lián)實體或者影響已有的實體特性 （4）添加詳細的描述信息 實體的詳細屬性和關系的基數(shù) 簡單情況下ERD建模-示例研討班在每個學年開始的時候開設，然后持續(xù)一個學年。每個研討班針對一個或幾個研究方向。每個研討班由一位或幾位教師主持。在研討班開設之后，學生可以根據(jù)主持教師（的姓名）和研討班的方向來選擇和參加某個研討班。所有的學生必須且只能參加一個研討班的學習。研討班時常會開展活動，由教師來

45、決定活動的時間、地點、主題和做報告的學生（的姓名）。每次活動時，由一位或多位同學圍繞活動主題做學習報告，交流自己對新技術的學習心得。每個學生一次活動最多只能作一個報告，但每個學生至少會在一次活動中做一個報告。教師對每份活動中的學生報告進行一次點評和指導，提出建議和意見。 復雜情況下ERD建模發(fā)現(xiàn)系統(tǒng)的概念域 指那些在系統(tǒng)業(yè)務中非常重要的概念，如果沒有這個概念，組織就可能不會存在或者業(yè)務發(fā)生重大變化 不能遺漏那些對業(yè)務有重大影響的概念，同時概念域的發(fā)現(xiàn)也不要太細節(jié) 每一個概念域都會以星型發(fā)散的方式擴展為多個邏輯實體 建立對概念域的描述 展開概念域 簡單情況下的ERD建?；蛘哌M一步細分子域合并概念

46、域的局部數(shù)據(jù)模型消除冗余和沖突 28 結構化范型與面向對象范型的區(qū)別？ 結構化范型（Structured Paradigm）基于如下的思想進行開發(fā)活動：一個系統(tǒng)應該被劃分為兩個部分：數(shù)據(jù)（使用數(shù)據(jù)/持久化模型建模）和功能（使用過程模型建模）。簡言之，結構化方法，數(shù)據(jù)將和設計模型中以及系統(tǒng)實現(xiàn)中（也就是程序中）的行為分離。 范型（Paradigm）：做事情的整體策略或觀點，是一套特定的思想集合。面向對象范型（Object-oriented Paradigm）不是將系統(tǒng)定義為兩個分離的部分（數(shù)據(jù)和功能），而是需要把系統(tǒng)定義為一組正在交互的對象。對象可以完成一些事情（對象具有功能），對象也知道一些事

47、情（對象有數(shù)據(jù)）。29 抽象類與具體類在表示上有何區(qū)別？ 引入抽象類是為了實現(xiàn)類的公共行為。 抽象類與具體類的區(qū)別在于：可以從具體類中實例化（創(chuàng)建）對象，但不能從抽象類中實例化對象。意味著軟件需要實例化教授或者研究員對象，但不需要創(chuàng)建教師對象。當創(chuàng)建一個類實現(xiàn)多個類的共同特征時，就可以建立抽象類。 30UML 多重指示器的含義？ 指示器含義0.1零或1個1僅1個0.*零或多個1.*1或多個n僅n個（n1）0.n零到n個（n1）1.n1到n個（n1）31 高內聚、低耦合含義？ 耦合 耦合表示兩個項目，如類與方法之間如何相互關聯(lián)的一種方法。當一個類依賴另外一個類時，則稱其為耦合的。當一個類與另外一

48、個類交互，但不知道這個類的實現(xiàn)細節(jié)時，則稱其為松散耦合的。當一個類依賴于實現(xiàn)（即它可以直接訪問別的類的數(shù)據(jù)屬性）是，則稱其為高度耦合的。 當兩個類高度耦合時，一個發(fā)生了變化往往需要另一個也跟著變化。高度耦合是巨大的維護負擔存在的主要原因。 松散耦合用起來通常都很好，但高度耦合用起來通常問題較多。內聚 一般情況下，應該定義高度內聚的類和方法。 當且僅當只完成一件事情的方法是高內聚的。高內聚的類通常僅表示一種類型的對象。在大學系統(tǒng)中，我們一般不定義職員類，而是將教授，研究員，實驗員分別加以定義。目的就是要增加內聚性。32 需求獲取及分析階段的成果及相互關系圖？ 面向對象建模是面向對象方法學在需求分

49、析中的應用，也稱為面向對象分析。所謂面向對象方法學的觀點就是將系統(tǒng)看作是一系列相互作用的對象的集合。每個對象具有獨立的職責，完成獨立的任務，對象之間通過消息機制相互協(xié)作，共同實現(xiàn)系統(tǒng)的目標。 需求獲取關注了解用戶和他們的使用需求，分析關注理解要構建的內容。面向對象分析技術，如用例模型，類建模，順序圖，活動圖以及用戶界面原型等都被用來消除需求和系統(tǒng)設計之間的差異。33 需求獲取與需求分析的主要區(qū)別？ 分析的目的在于理解將要構建的內容，這與需求獲取相似。需求獲取確定用戶要構建的內容。區(qū)別在于需求獲取將重點放在理解用戶和他們使用系統(tǒng)的潛在要求，而分析的重點在于理解系統(tǒng)本身34 針對每個業(yè)務事件、報表

50、進行領域類圖的構建時主要包括那三個步驟？ 針對每個業(yè)務事件、報表進行領域類圖的構建時，主要包括三個步驟： （1）識別出業(yè)務實體； （2）確定業(yè)務實體之間的關系； （3）定義業(yè)務實體的關鍵屬性。35 業(yè)務實體分析的產(chǎn)物？ 業(yè)務實體分析（構建）的產(chǎn)物一般采用兩種模型：（1）類圖：類圖是面向對象分析和設計方法引入的，使UML規(guī)范的一部 分。它在語義上比傳統(tǒng)的E/R模型強。更加適合于領域建模；（2）E/R圖：E/R模型也稱實體關系圖，與數(shù)據(jù)庫結合更緊密。但在領域建模方面，在語義上沒有類圖豐富。36 如何從用戶給出的具體實例抽象出業(yè)務模型？ 假定哈爾濱的王一要給北京的張三買一件禮物。為此，王一登陸到電子

51、商務網(wǎng)站，通過電子商務網(wǎng)站將其送給張三。電子商務網(wǎng)站是通過其簽約的北京某禮品店來完成該任務。在整個禮品傳遞的過程中，各個實體的關聯(lián)關系如下圖所示： 實際情況要比上述場景復雜得多。電子商務網(wǎng)站要能夠接受很多人的訂貨，簽約的禮品店有很多，以將禮物送給不同人地方的人。對上述場景進行抽象?？梢缘玫揭韵碌某橄髨鼍?。對象是類的一個實例或者出現(xiàn)。類描述了具有相同特性（屬性）和行為（操作）、關系類別以及語義的一組對象。王一是一個對象，它是“訂貨人”類的一個對象。北京海淀禮品店是一個對象它是“禮品店”類的一個對象。北京張三是一個對象，它是“收貨人”類的一個對象。電子商務網(wǎng)站不應該成為一個類，因為它除了送禮以外，

52、還要干別的事情，用一個類難以包含，不適應高內聚，低耦合的要求。業(yè)務模型的抽象過程37 CRC模型的概念？ CRC（類職責協(xié)作卡）模型CRC是Class、 Responsibility和 Collaborator三者的縮寫。CRC卡是一種被劃分為三個部分的標準索引卡，一部分指出卡片表示的類名，一部分列出類的職責，一部分列出與該類一起協(xié)作履行職責的其他類名基于CRC可以建立一種索引卡片，被稱為CRC卡，每個卡片代表了一個被發(fā)現(xiàn)的候選對象 形式可能是多種多樣的，卡片、紙張、黑板等等都可以作為CRC卡的介質載體 CRC卡簡潔方便，可以隨時被移動、修改或者丟棄，所以它特別適合于在復雜的系統(tǒng)當中進行對象的發(fā)現(xiàn)和設計思想的挖掘 ，即進行復雜情況下的面向對象分析與設計 。CRC模型是一組相關的CRC 卡的集合,用于對系統(tǒng)整體或部分建模。38 理解業(yè)務規(guī)則？ 業(yè)務規(guī)則實際上是（業(yè)務）系統(tǒng)必須滿足的運行原則和策略。 業(yè)務規(guī)則獲取的方式： 業(yè)務規(guī)則通常關注訪問控制的問題例如允許教授輸入和修改參加其討 論班的學生的成績，但不允許輸入和修改別的討論班的學生的成績。 業(yè)務規(guī)則也常常與業(yè)務計算有關-例如，如何把學生在某個討論班中得到 的百分制成績，