學生成績數據流程判定表

① 判斷表的例子

以學生的獎學金評定為例，說明判定表的應用。獎勵的目的在於鼓版勵學生的品學兼優，此處理權功能是要合理確定獎學金評定等級。決定受獎的條件為：成績優秀佔70%或50%以上，成績為中或中以下佔15%或20%以下，團結紀律為優良或一般者。獎勵方案為一等獎、二等獎、三等獎、鼓勵獎四種。因為受獎條件有些是相容的，相互組合的項較多。描述此學生獎勵政策的判定表如下圖所示：
由上圖可見，判定表將比較復雜的決策問題簡潔、明確、一目瞭然地描述出來，它是描述條件比較多的決策問題的有效工具。判定表或判定樹都是以圖形形式描述數據流的加工邏輯，它結構簡單，易懂易讀。尤其遇到組合條件的判定，利用判定表或判定樹可以使問題的描述清晰，而且便於直接映射到程序代碼。在表達一個加工邏輯時，判定數、判定表都是好的描述工具，根據需要可以交叉使用。

② 軟體測試方法的判定表

判定表的英文是decision table，是指一個表格，用於顯示條件和條件導致動作的集合。
定義回：判定表是分析和表答達多邏輯條件下執行不同操作的情況的工具。
判定表的優點：能夠將復雜的問題按照各種可能的情況全部列舉出來，簡明並避免遺漏。因此，利用判定表能夠設計出完整的測試用例集合。
在一些數據處理問題當中，某些操作的實施依賴於多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作。判定表很適合於處理這類問題

③ 跪求：什麼叫「流程圖中所用到的數據文件結構」謝謝謝謝~~~

電大天堂形考作業一：
一、 填空題
1． 系統軟體 ， 應用軟體
2． 過程 ， 方法 ， 工具
3． 程序設計階段 ， 程序系統階段 ， 軟體工程階段
4． 計劃 ， 需求分析 ， 設計 ， 編碼 ， 測試 ， 運行維護
5． 項目管理過程 ， 配置管理過程 ， 質量管理過程
6． 瀑布模型，螺旋模型，風險分析
7． 結構化設計，結構化編程
8． 初始級，可重復級
9． 需求獲取
10． 系統分析員 ， 用戶 ， 軟體開發人員，軟體需求規格說明書
11． 數據流圖 ， 數據字典 ， 結構化語言 ， 判定表 ，判定樹
12． 判定樹，結構化語言
13． 參與者 ， 用例
14． 擴展關系 ， 包含關系 ，泛化關系
二、 單項選擇題
1．B 2．A 3．D 4．C 5．A
6．D 7．D 8．B 9．A 10．B
11．C 12．D 13．C 14．A 15．A
16．D 17．C 18．A 19．C 20．C
三、 簡答題
1． 軟體工程
軟體工程是用工程、科學和數學的原則與方法研製、維護計算機軟體的有關技術及管理方法。
2．軟體危機
軟體危機泛指在計算機軟體的開發、維護和使用過程中所遇到的一系列嚴重問題。
3．軟體危機有哪些表現，產生的原因有哪些？
軟體危機的表現：
從宏觀上說，軟體危機主要是指：
（1） 軟體的發展趕不上計算機硬體的發展
（2） 軟體的發展趕不上社會對於軟體需求的增長
從具體的軟體來說，軟體危機是指：
（1） 軟體往往不能按計劃、按預算、按時完成
（2） 已開發的軟體不能很好的使用，甚至很快就不用
軟體危機產生的原因：
（1） 軟體需求分析不充分
（2） 軟體開發的規范性不夠
（3） 軟體開發計劃的科學性不夠
（4） 缺少對於軟體的評測手段
4．數據字典
數據字典是對系統用到的所有數據項和結構的精確定義，以確保開發人員使用統一的數據定義。數據字典與數據流圖配合，能清楚地表達數據處理的要求。
5．與別的產品相比，軟體有哪些特徵？
（1） 軟體是一種邏輯實體，主要是人的腦力勞動的產物，軟體具有抽象性。
（2） 軟體具有復雜性。
（3） 軟體的維護具有長期性。
（4） 軟體具有高成本性。
6．試述軟體工程的基本原則
（1） 用分階段的生命周期計劃嚴格管理
（2） 堅持進行階段評審
（3） 實行嚴格的產品控制
（4） 採用現代程序設計技術
（5） 結果應能清楚地審查
（6） 結果應能清楚地審查
（7） 承認不斷改進軟體工程實踐的必要性
7．試述瀑布模型有何優缺點
優點：它在支持結構化軟體開發、控制軟體開發的復雜性、促進軟體開發工程化等方面起著顯著的作用。
缺點：首先，瀑布模型它要求在軟體開發的初始階段明確軟體系統的全部需求，在實際中做到這一點是很困難的，甚至是不現實的。其次，使用瀑布模型開發軟體，用戶和項目管理者要等很長時間才能得到一份軟體的最初版本，如果用戶對該軟體提出了較大的改進意見，將使整個項目蒙受巨大的損失。
8．優秀的需求說明書應該具備哪些特點？
（1）完整性。需求規格說明書不能遺漏任何必要的需求信息，對於當前不能確定的，則使用「帶確定」標示。
（2）無二義性。對所有需求說明的讀者都只能有一個明確統一的解釋。
（3）一致性。與其他軟體需求或高層（系統、業務）需求不相矛盾。
（4）可修改性。便於修改，並且在修改後維護需求的一致性、完整性和無二義性。
（5）可跟蹤性。在進一步產生和改變文檔編制時，可以方便的引證每一個需求。
9．結構化需求分析方法包含那些步驟？
（1）對現行系統的「物理環境」進行研究，獲得現行系統的具體模型。分析現行系統的輸入和輸出，系統中的數據如何流經整個系統的，劃出系統的數據流圖，用具體的模型來表示自己對現行系統的理解。
（2）抽象出與現行系統模型等價的邏輯模型。對具體模型進行抽象，提取其一般的，本質的因素，去掉那些非本質的因素，獲得反映系統本質的邏輯模型。
（3）建立目標系統的邏輯模型。要明確需要在現行系統上做哪些改變,根據新系統作要做的改變，參照現行系統邏輯模型，畫出新的數據流圖。
（4）補充目標系統的邏輯模型。確定目標系統的人機界面，補充一些尚未詳細考慮的細節問題
10．在畫系統的分層數據流圖時，需要注意哪些問題？
(1) 加工的編號方法。根據加工的編號，應該能知道該加工屬於哪一層，該加工的父圖以及時從父圖中的哪個加工分解得來的。
(2) 分解程度。應該使分解力求自然，使分解後各界面清晰，意義明確
(3) 父圖與子圖的平衡。子圖中的輸入輸出應該和父圖中相對應的加工的輸入輸出相一致，以保持數據流的平衡，保證加工過程的連續性和一致性。
(4) 文件的局部性。在只有文件成為兩個或多個加工的介面時，才出現在該層及下層數據流圖上。
11．用例模型
用於描述指定系統的用例，參與者和用例—參與者關聯關系的組合。
12．在建立系統的用例模型時，如何確定系統的參與者？
為了有效地發現參與者，必須回答以下幾個問題：
（1）誰是系統的主要用戶，即誰使用系統的主要功能；
（2）誰從系統獲得信息；
（3）誰向系統提供信息；
（4）誰來管理、維護系統，以保證系統的正常運行；
（5）系統需要與哪些其他的系統交互（包含其他的計算機系統或應用程序）；
（6）為了完成系統的功能，需要哪些硬體設備的支持。
13．為了使開發組織能夠嚴格控制軟體項目，需求變更應遵循哪些原則？
（1）仔細評估已建議的變更；
（2）挑選合適的人選對變更做出決定；
（3）變更應及時通知所有涉及的人員；
（4）項目要按一定的程序來採納需求變更。
四、 應用題
1．
（1）圖2中的「房租文件」和「交費文件」是局部文件，不必畫出。
（2）圖3中遺漏的數據流如下：
（a）從「住戶基本信息文件」到加工1.1的數據流；
（b）加工1.4輸出的數據流「分戶收費通知單」；
（c）加工1.6輸出的數據流「住房分配表」。
（3）加工2的子圖如下：

2．
參與者：管理員，讀者（員工）
用例：新書錄入，書籍查詢，借書登記，還書登記，催還。

電大天堂形考作業二：
一、單項選擇題
1．C 2．A 3．B 4．D 5．A
6．B 7．C 8．A 9．D 10．B
二、填空題
1. 數據流圖
2. 過程抽象，數據抽象，控制抽象
3. 分解，抽象
4. 功能，邏輯，狀態
5. 耦合，內聚
6. 體系結構
7. 系統設計目標
8. 變換型數據流圖，事務型數據流圖
9. 詳細設計
10. 演算法設計、數據結構設計
11. 圖形工具、表格工具和語言工具
12. 數據結構
13. 結構沖突
三、判斷題
對 錯 錯 對 對
錯 對 錯 對 對
四、簡答題
1．結構化程序設計（SP）方法，最早是由E. W. Dijkstra在20世紀60年代中期提出的，它以下幾個基本要點：
第一，採用自頂向下、逐步求精的程序設計方法；
第二，使用順序、選擇及重復三種基本控制結構構造程序；
第三，主程序員的組織方式。開發程序的人員應採用以一個主程序員、一個後備程序員和一個程序管理員三人為核心，再加上一些專家等組成小組。
下圖所給出的是流程圖的五種基本控制結構

2．程序結構描述了整個程序的控制層次關系和各個部分的介面情況，而軟體過程則著重描述各個模塊的處理細節。
軟體過程必須提供精確的處理說明，包括事件的順序、正確的判定點、重復的操作直至數據的組織和結構等等。程序結構與軟體過程是有關系的。對每個模塊的處理必須指明該模塊所在的上下級環境。軟體過程遵從程序結構的主從關系，因此它也是層次化的。
3．信息隱蔽是指每個模塊的實現細節對於其它模塊來說是隱蔽的。就是說，模塊中所包含的信息（包括數據和過程）不允許其它不需要這些信息的模塊使用。
4．結構化方法總的指導原則是自頂向下、逐步求精。它的基本原則是功能的分解與抽象。逐步求精，也稱為自頂向下是指：不要求一步就編製成可執行的程序，而是分若干步進行。第一步編出的程序抽象程度最高，第二步編出的程序抽象程度有所降低，最後一步編出的程序即為可執行的程序。用這種方法編程，可使程序易讀、易寫、易調試、易維護，也易於保證程序的正確性及驗證其正確性。隨著軟體設計的逐步展開，程序結構中每一層模塊就體現了過程抽象某一層次上的一次細化。
5．軟體總體設計的主要任務是要建立軟體系統的體系結構，即軟體系統要劃分多少模塊，模塊之間的層次結構和調用關系是怎樣的。同時還要設計數據結構和資料庫結構、人機介面等。在概要設計階段需要完成的基本任務，有以下幾個方面：採用某種設計方法，將一個復雜的系統按功能劃分成模塊的層次結構；確定每個模塊的功能，建立與已確定的軟體需求的對應關系；確定模塊之間的調用關系；確定模塊之間的介面，即模塊之間的信息，設計介面的信息結構；評價模塊劃分的質量及導出模塊結構的規則。
五、應用題

電大天堂形考作業三：
一、單項選擇題
1．A 2．D 3．C 4．C 5．D
6．B 7．A 8．B 9．D 10．B
11．A 12．B 13．A 14．A 15．C
二、填空題
1. 操作
2. 信息繼承
3. 屬性，操作
4. 多繼承
5. 整體-部分
6. 多態性
7. 關聯、泛化、依賴和細化
8. 順序
9. 狀態
10. 用例視圖、邏輯視圖
11. 活動圖
三、判斷題
對 對 錯 對 錯
對 錯 錯 錯 錯
四、簡答題
1．對象是構成世界的一個獨立單元，它具有自己的靜態特徵和動態特徵。
類是具有相同屬性和操作的一組對象的集合，它為屬於該類的全部對象提供了統一的抽象描述，包括屬性和操作兩個部分。
消息是一個對象與另一個對象的通信單元，是要求某個對象執行類中定義的某個操作的規格說明。發送給一個對象的消息定義為一個操作名和一個實參數表(可能是空的)。
2．類之間的關系有：關聯；聚集；組成和泛化
關聯表示類與類之間的一種抽象關系，從說明層觀點看，關聯代表一種職責；
聚集關系表示類和類之間的整體和部分的關系；
組成關系是另外一種形式的聚集關系，部分對象僅屬於一個整體對象，且部分對象與整體對象共存亡；
泛化關系也稱繼承關系。
3．Coad和Yourdon對面向對象給出了一個定義：「面向對象 = 對象 + 類 + 繼承 + 消息通信」。
面向對象技術是一個非常實用的軟體開發方法，具有以下特點。第一，開發方法的唯一性，即方法是對軟體開發過程所有階段進行綜合考慮而得到的。二是從生存期的一個階段到下一個階段的高度連續性，即在一個階段所用到的部分與在下一個階段所使用的部分是銜接的，所使用的技術經過生存期每一階段後不改變。最後，把面向對象分析、面向對象設計和面向對象程序設計集成到生存期的相應階段。
4．用例模型用於系統需求的獲取，描述系統的功能需求。
用例模型的主要成分有用例、參與者和系統。系統被看作一個提供用例的黑盒，系統如何做、用例如何實現、內部如何工作，這些對用例模型都是不重要的。創建用例模型的工作包括：定義系統，尋找參與者和用例，描述用例，定義用例之間的關系，最後確認模型，用例模型由用例圖組成。
5．面向對象分析的一般步驟是：
1）獲取用戶對OO系統的需求，包括表示場景或者用例；建造需求模型。
2）為每個系統對象標識屬性和操作。
3）定義組織類的結構和層次。
4）建造對象-關系模型。
5）建造對象-行為模型。
6）使用用例/場景復審OO分析模型
五、應用題

電大天堂形考作業四：
一、單項選擇題
1．C 2．B 3．D 4．B 5．A
6．C 7．D 8．D 9．B 10．C
11．B 12．D 13．A 14．A 15．C
16．A 17．B 18．A 19．D 20．A
21．D 22．C 23．A 24．B 25．D
26．A 27．C 28．A 29．D 30．A
二、填空題
1. 應用技術、管理和監督
2. 公司級、項目級、程序員級和應用級
3. 功能基線、分配基線和產品基線
4. 配置項
5. 配置項的選擇、配置項的命名和描述、配置項的存取
6. 基線
7. 技術上解決軟體質量問題的局限性、測試的局限性
8. 黑盒測試、白盒測試
9. 性能
10. 相一致
11. 軟體開發計劃
12. 已建立基線
13. 隱含
14. 軟體質量保證
15. 審查；復查和管理復審；測試
16. 軟體計劃、軟體設計、軟體編碼
17. 程序
18. 程序錯誤
19. 靜態、動態
20. 結構檢查、流圖分析、符號執行
21. 分析、非分析
22. 風險
23. 文件
24. 管理文檔、開發文檔和用戶文檔
25. 程序風格、書寫格式、注釋格式
三、判斷
對 錯 錯 錯 對
對 對 錯 錯 錯
對 對 錯 對 對
錯 對 對 錯 對
錯 錯 對 錯 對
錯 錯
四、簡答題
1. 需要。原因是a. 配置管理系統是組織內部信息交換的中心；b. 軟體配置管理將軟體生存期各開發階段末尾的特定點定義為基線，實行變更控制，貫穿整個軟體生存周期
2. 軟體測試就是根據軟體開發各階段的規格說明和程序的內部結構而精心設計一批測試用例，即輸入數據及其預期的輸出結果，並利用這些測試用例去運行程序，以發現程序錯誤的過程。
黑盒與白盒測試都是驗證程序正確性的一種辦法。黑盒測試不考慮程序內部結構，只對程序的外部介面進行測試；白盒測試考慮程序內部結構，按照程序內部的邏輯測試
3. 這段文字放在《用戶手冊》中比較合適。這段文字應該放在「出錯處理和恢復」部分。
4. 功能配置審核—驗證配置項的實際功效是與其軟體需求一致的。物理配置審核—確定配置項符合預期的物理特性，即特定的媒體形式。
5. 1. 人的因素。2. 軟體需求。3. 開發各個環節的銜接。4. 測試的局限性。5. 質量管理不夠重視。6. 軟體開發的非工程化和開發人員的傳統習慣。7. 開發沒有規范，標准。8. 技術上解決軟體質量問題的局限性。
6. 1. 用戶要求定義。2. 技術方法的應用。3. 提高軟體開發的工程能力。4. 軟體的復用。5. 發揮每個開發者的能力。6. 組織外部力量協作的方法。7. 排除無效勞動。8. 提高計劃和管理質量能力。
7. 注釋從其整體觀感和作用上可以分為兩種：高級注釋：說明程序功能並描述程序各組成部分相互關系；低級注釋：逐行解釋程序指令如何工作。

④ sql存儲過程判斷表有沒有數據

SQL SERVER中上面方法不行，參考sp_executesql ,類似如下

declare @sql nvarchar(2000)
declare @cou int
declare @id varchar(20)
set @id='1'
set @sql='select @count=count(*) from emp where id=@id'
exec sp_executesql @sql, N'@count int out,@id varchar(20)', @cou out
,@id
print @cou

⑤ 求寫一個存儲過程通過判斷表中2列值相同而更新數據

update tb set ContractStatus='完成' where BillAmountContract=ContractAmount

⑥ 數據流圖和數據流程圖的區別

數據流程圖是以圖形的方式表達在問題中信息的變換和傳遞過程。它把系統看成是由數據流聯系的各種概念的組合，用分解及抽象手段來控制需求分析的復雜性，採用分層的數據流程圖來表示一個復雜的系統。 很多資料上，數據流程圖也叫數據流圖，都指DFD：Data Flow Diagram。 需要注意的是數據流圖和程序設計中的程序流程圖（Flow Chat）是不同的，數據流圖關心的是企業業務系統中的數據處理加工的客觀過程，並不關心未來電子化處理的加工過程；數據流圖中流動的只是數據，並沒有控制過程，但在程序流程圖當中，必須有控制邏輯。 結構化分析是面向數據流開展需求分析工作的一種有效方法。一般採用自頂向下，逐層分解的演義分析法來定義系統的需求，即先把分析對象抽象成一個系統，然後自頂向下的逐層分解，將復雜的系統分解成簡單的、能夠清楚地被理解和表達的若干個子系統，如圖1（逐層分解的數據流程圖）所示。這樣就可以分別理解系統的每個細節、前後順序和相互關系，找出各部分之間的數據介面。在結構化分析方法所採用的工具有數據流程圖（DFD）、數據字典（DD）、結構化語言、判定樹、判定表等。 數據字典（Data dictionary）是一種用戶可以訪問的記錄資料庫和應用程序元數據的目錄。主動數據字典是指在對資料庫或應用程序結構進行修改時，其內容可以由DBMS自動更新的數據字典。被動數據字典是指修改時必須手工更新其內容的數據字典。

⑦ 數據驅動測試的判定表驅動分析方法

前面因果圖方法中已經用到了判定表.判定表（Decision Table）是分析和表達多邏輯條件下執行不同操作的情況下的工具.在程序設計發展的初期，判定表就已被當作編寫程序的輔助工具了.由於它可以把復雜的邏輯關系和多種條件組合的情況表達得既具體又明確.
判定表通常由四個部分組成.
條件樁（Condition Stub）：列出了問題得所有條件.通常認為列出得條件的次序無關緊要.
動作樁（Action Stub）：列出了問題規定可能採取的操作.這些操作的排列順序沒有約束.
條件項（Condition Entry）：列出針對它左列條件的取值.在所有可能情況下的真假值.
動作項（Action Entry）：列出在條件項的各種取值情況下應該採取的動作.
規則：任何一個條件組合的特定取值及其相應要執行的操作.在判定表中貫穿條件項和動作項的一列就是一條規則.顯然，判定表中列出多少組條件取值，也就有多少條規則，既條件項和動作項有多少列.
判定表的建立步驟：（根據軟體規格說明）
①確定規則的個數.假如有n個條件.每個條件有兩個取值（0,1），故有2n 種規則.
②列出所有的條件樁和動作樁.
③填入條件項.
④填入動作項.等到初始判定表.
⑤簡化.合並相似規則（相同動作）.
B. Beizer 指出了適合使用判定表設計測試用例的條件：
①規格說明以判定表形式給出，或很容易轉換成判定表.
②條件的排列順序不會也不影響執行哪些操作.
③規則的排列順序不會也不影響執行哪些操作.
④每當某一規則的條件已經滿足，並確定要執行的操作後，不必檢驗別的規則.
⑤如果某一規則得到滿足要執行多個操作，這些操作的執行順序無關緊要.

⑧ oracle資料庫判斷表（由存儲過程創建）的存在

你不是已經drop table又重新創建了，有什麼問題嗎？
你的思路是對的，要創建前應該先判斷，專如果存在就刪掉重建屬，不存在的話就直接創建。
只是，可以稍微簡化一下代碼，比如那兩個select，不需要用execute immediate的方式。對於dml語句，可以直接執行，比如select count(*) into vCount from user_tables where table_name =vTname，而創建語句直接放到if判斷裡面，這樣顯得結構上更緊湊和邏輯性。