《UML大戰需求分析》閱讀隨筆(六)

2022-08-02 14:27:09 字數 1600 閱讀 1644

在我們做的**設計中分為系統設計和程式設計。程式設計是系統設計中模擬程式的執行邏輯,定義客戶機伺服器物件合作的框架的那個部分。程式和事務設計中,作者講述到程式和事務設計將系統設計製品放在一起,並作為系統設計過程的最終階段。

程式設計是系統設計的乙個內在的部分。圖形使用者介面(gui)和資料庫的設計體現出了乙個框架的前段和後端。而我們的程式設計就是填充在這框架中間的空缺,並將它轉換為可以交給程式設計師去進行開發的設計文件。那麼,怎麼樣的程式被稱為乙個好的程式呢。首先,乙個好的程式設計要保證類的內聚和耦合的良好平衡。就像之前所說的好的內聚意味著弱的耦合,反過來乙個號的耦合意味著弱內聚。所以我們要做的就是讓著兩者之間達到乙個好的平衡。作者接著就為我們講述了一系列方法來讓我們進一步不斷的做好,並且通過例項說明。在處理好內聚和耦合的平衡之後,我們就要設計客戶機與我們的伺服器之間的合作。為了資料和資料庫的互動,客戶機程式必須使用類似於sql語言的語句來儲存和修改資料。而sql可以用五種不同的形式出現並可以用於程式抽象的不同層次上。每乙個層次用相同的也有各自的優點。說老說去,也就是對資料的儲存之類的功能。觸發器,是一種特殊的儲存過程,他不能被呼叫。他在乙個資料庫表上發生的插入、更新或刪除等事件時將他們自己觸發。這就 以為這每個資料庫表可以最多有三個觸發器。在我們進行程式設計的時候,有了資料庫的出現我們的物件就自然而然的增加了不少,並且其合作互動也變得複雜了許多。而我們,就不能僅僅是依靠視窗導航圖了,而要擴充套件為更為完整的程式導航圖。為了實現乙個完整的程式導航圖,我們需要對uml的活**增加伺服器端的構造型。而且構造型必須考慮資料庫管理系統(dbms)模型或者甚至是特定的dbms的特性。除了講到程式設計,事務設計也是必不可少的。失誤是工作的乙個邏輯單位,它包含乙個或多個由使用者執行的sql語句。事務也是資料庫一致性的單位,資料庫的狀態在事務完成之後還是一致的。為了保證這個一致性,dbms的事務管理有兩個作用:資料庫回覆和併發控制。而事務又分為短事務和長事務。傳統的資料庫應用要求短事務,一些新的資料庫應用則用長事務來工作。

變化管理是整個專案管理的基本方面,變化請求必須記錄在案,每個變化對開發製品的影響都必須跟蹤,並且在變化實現之後要進行測試。關於測試呢一共分為系統服務測試和系統約束測試兩種。系統服務測試可以是基於非執行的或基於執行的。基於非執行的測試包括走查和檢查。而基於執行的測試可以是針對規格說明的測試或針對**的測試;系統約束的測試包括大量的完全不同的測試,它們關係到像使用者介面、資料庫、授權、效能等等。系統約束測試是與系統服務測試並行進行的,另外一些則是獨立完成的。測試和變化管理要求特定的文件,如測試計畫、測試用例文件、故障和改進文件等。測試需求在測試文件中表示,並且被連線到用例文件中的用例需求。請求變化一般要麼是故障要麼是改進。乙個變化管理工具用於變化請求的提交並儲存它的軌跡,就跟開發者對待它一樣。

總結這本書所講,首相讓我知道了乙個軟體專案的開發需要經歷的過程和過程中用到的輔助工具。還有對於專案規劃我們可以採用什麼樣的方法,並且對於軟體專案生命週期的認識和理解。然後作者用了好幾章的內容講需求,從需求的分析,需求的不斷變更,確定以及需求規格的說明。由此可以看出對於我們軟體工程師來說,需求對於我們來說是無時無刻不纏繞著我們的,對於需求的分析我們一定要熟知熟練。而後面的內容,作者則是根據我們開發軟體專案的時候不同領域,不同階段的東西給我們進行講解。總的來說,在讀這本書的時候,自己一直在學習新的不知道的東西。對我們軟體專案的開發有了乙個大致的理解,這對於我現在、以後做東西的完美性來說毫無疑問是乙個強大的理論基礎。

《UML大戰需求分析》閱讀隨筆(三)

一 需求中提到的各種業務概念 人物等,經過抽象後都可以視之為類。平時遇到的人 物,我們將遇到的都是具體的人 物,也就如程式中的物件,是乙個實實在在的東西。當我們分析需求的時候,設計模型的時候,我們就需要將之抽象,也就是最關鍵的一步 提煉。提煉出這個東西,我們所需要的部分。比如,在教室,主要存在兩類人...

UML大戰需求分析 閱讀筆記06

狀態機圖和活 在樣子比較相似,但狀態機圖是用來為物件的狀態及造成狀態改變的事件建模。我們大二學習uml統一建模語言狀態機圖模組時了解到,uml的狀態機圖主要用於建立物件類或物件的動態行為模型,描述系統中某乙個物件所經歷的各個狀態 引起狀態或活動轉移的事件,以及因狀態或活動轉移而伴隨的動作。但在以前的...

UML大戰需求分析 閱讀筆記04

讀 uml大戰需求分析 有感04 開發某系統的重要前提是 這個系統有誰在用?這些人通過這個系統能做什麼事?一般搞清楚這件事,再畫個業務流程圖,就能條例清楚的表達系統的需求了。作為乙個開發人員,不僅要懂得如何從使用者那裡獲取有用的資訊,還要懂得怎麼清晰地描述自己的想法,給客戶呈現出乙個結構完整 功能全...