《面向對象軟件工程》筆記
第一章 軟件和軟件工程

1、軟件的一種分類：定制軟件Custom Software、通用軟件Generic Software、嵌入式軟件Embeded Software。
2、軟件工程 定義：是在成本、時間及其他的約束條件下，通過對大型、高質量的軟件系統的系統化的開發與演進，從而解決客戶問題的過程。
3、軟件工程中IEEE/ACM道德公約的要點：
（1）與公共利益保持一致；
（2）在符合公共利益的前提下，最大限度地滿足客戶與雇主的需要；
（3）按可能的最高標準開發與維護產品；
（4）進行專業決策時保持誠信與自主；
（5）在管理中體現道德意識；
（6）在符合公共利益的前提下，提升職業的誠信和信譽；
（7）同事間公平相處、相互支持；
（8）參與終身學習。
4、相關人員，4種角色：用戶user、客戶customer/client、開發者developer、管理人員manager。
5、軟件質量的屬性：
（1）可用性usability；
（2）效率efficiency；
（3）可靠性reliability；
（4）可維護性maintainability；
（5）可重用性reuseability。
外部質量屬性external quality attribute
內部質量標準internal quality criteria：
（1）代碼注釋量；
（2）代碼的復雜性：用嵌套深度、分支數量以及所使用的復雜程序結構來衡量。
6、軟件工程項目 分類：
（1）進化型項目（它又分：糾錯性corrective項目、適應性adaptive項目、增強性enhancement項目、重建性re-engineering或完善性perfective項目）；
（2）零起點項目；
（3）在框架或已有構件的基礎上構造項目。
7、軟件項目中常見的活動
1）需求與規格說明
領域分析domain analysis：了解相關的背景信息，以便理解問題并做出明智的決定。
定義問題defining the problem：通過準確地確定需要解決的問題，限定系統的范圍。
需求收集requirement gathering：收集所有人對該軟件應該做什么的意見。
需求規格說明requirement specification：編寫一系列準確的結構定義該軟件應當做什么。
2）設計：如何利用現有技術實現需求的過程。
系統工程：確定哪些需求用硬件實現，哪些需求由軟件實現。（嵌入式和實時系統）
架構：即軟件體系結構，決定如何將軟件劃分成子系統。
詳細設計：確定構造每個子系統的詳細內容。
用戶界面設計：確定用戶與系統交互的詳細方式。
3）建模：創建表示領域或軟件的過程。
用例建模use case modelling：表示軟件用戶執行的一系列活動。
結構化建模structural modelling：表示領域或軟件中的類和對象。
動態和行為建模dynamic and behavioural modelling：表示系統可能出現的狀態、可能執行的活動以及構件之間如何交互。
4）程序設計：目標之一：使之自動化。
5）質量保證Quality Assurance
評審Review與審查Inspection：討論需求、設計或代碼是否令人滿意的正式會議。
測試Testing：系統地執行軟件，看其行為是否與預期相符的過程。
確認Validation與驗證Verification
6）部署Deployment：發布與安裝軟件。
7）過程管理
軟件的項目管理使軟件工程的組成部分。
8、困難與風險
（1）復雜性與大量的細節；
（2）技術的不確定性；
（3）需求的不確定性；
（4）軟件工程技術的不確定性；
（5）持續的變化；
（6）軟件設計退化：不斷地修改軟件所帶來的錯誤會使軟件退化；
（7）“政治”風險。

第二章 面向對象概述
太簡單，跳過。

第三章 基于重用技術進行軟件開發
重用resue是成功軟件開發的一個關鍵。
框架framework技術促進了重用。
框架：可重用的軟件子系統，實現了能被許多應用程序使用的重要功能。也即實現了一般問題的通用解決方案。
客戶機-服務器體系結構（C-S）
1、重用類型：
（1）重用專家經驗；
（2）重用標準的設計與算法；
（3）重用類庫或程序，或者重用語言和操作系統中內置的強大命令；
（4）重用框架；
（5）重用完整的應用程序。
商業成品Commercial Off-The-Shelf,COTS
粘合代碼glue
2、將可重用性與重用引入軟件工程
（1）鼓勵重用，打破惡性循環；
（2）使發現可重用構件成為可能。
3、框架的關鍵原則：完成不同的但有相關性任務的應用程序往往有相似的設計－－特別是構件的交互模式往往是非常相似的。
（1）區別框架與其他種類軟件子系統的關鍵：框架從本質上講是不完全的incomplete。它缺少的部件叫插槽slot。應用程序開發人員用適應于特定應用程序的方式填充這些插槽，使框架適應他的需要。
（2）框架通常也有鉤子hook：像插槽，不同之處在于鉤子代表了應用框架時開發人員能夠提供的可選功能。
（3）使用框架的開發人員不僅填充插槽合鉤子，還使用框架提供的服務。
（4）框架的類型：框架可以是水平的，也可以是垂直的。水平框架提供大多數應用程序能夠使用的一般功能。垂直框架也稱應用框架application framework，提供一些功能來簡化特殊種類應用程序的開發。
（5）垂直框架會有更完整的實現，并且可能有較少的插槽和鉤子。應用程序通常只用到框架服務的一個子集。
4、面向對象框架：框架由類庫組成，提供的服務集合是API，它由公有類中所有公有方法public method的集合定義。面向對象框架中的一些類應該是抽象的。為了在新的應用環境中使用框架，開發者創建具體類來擴展這些抽象類。抽象類中的抽象方法就是插槽，具體子類創建具體方法時將填充它們。
5、軟件體系結構software architecture：是軟件工程的一個分支，涉及如何組織與連接一系列軟件模塊使其能夠在一起工作。
分布式系統distributed system：計算由不同的程序執行，這些程序一般運行在不同的硬件上，合作完成系統的任務。
瘦客戶機thin-client系統：客戶機被做得盡可能小，絕大部分工作由服務器完成。優點：容易通過網絡下載客戶機程序并且啟動它。
胖客戶機fat-client系統：絕大部分工作由服務器完成。優點：服務器可以更小或能處理更多的客戶機。
客戶機/服務器體系結構的優點：
（1）計算工作可以被分散到不同的機器上；
（2）客戶機具有遠程訪問服務器的功能；
（3）客戶機和服務器可以分別設計；
（4）所有數據集中保存在服務器中，這樣保持數據的可靠性更容易；
（5）信息可以被多用戶同時訪問；
（6）相互競爭的客戶機可以與同一個服務器通信。
6、設計服務器必須提供的功能：
（1）服務器必須初始化自己；
（2）為了客戶機能夠連接，它必須開始監聽；
（3）它必須處理源自客戶機的事件；
（4）它可能被要求停止監聽；
（5）它必須在需要時干凈地終止。
7、設計客戶機時必須提供的功能：
（1）客戶機必須初始化自己以便與服務器進行通信；
（2）執行一些工作：決定初始化一個到服務器的連接，向服務器發送消息；
（3）它必須處理源自服務器的事件；
（5）它必須干凈地終止。
客戶機－服務器天生就是并發的。這些并發一般需要使用能夠并行執行的多線程控制來實現。
8、開發CS系統時的任務：
（1）客戶機和服務器執行的基本工作，也就是計算、存儲數據等；
（2）工作如何分配－－瘦客戶機、胖客戶機還是介于兩者之間；
（3）為了完成主要活動，需要消息的細節，即通信協議；
（4）當客戶機和服務器啟動，處理連接、發送和接收消息、終止時所要發生的事情；
9、JAVA中建立連接
在兩個應用程序中建立TCP/IP連接的包java.net，類socket是這個包中的核心元素，這個類封裝了關于每個連接的信息。
為了交換信息，服務器和客戶機都必須有Socket實例。
（1）建立連接前，服務器必須開始對一個端口進行監聽。它使用ServerSocket類來做這件事，如下：
ServerSocket serversocket = new ServerSocket(port);
（2）客戶機為了連接到服務器，使用如下語句來傳遞服務器的主機名和端口號：
Socket clientSocket = new Socket(host,port);
（3）為了使連接能被接受，服務器必須有一個線程使用嵌在循環中的如下語句對連接進行持續監聽：
Socket clientSocket = serverSocket.accept();
（4）如通信發生故障，會拋出IOException異常；一旦建立了連接，信息交換就開始了。
對稱（symmetric）的連接，指客戶機和服務器使用同樣的方式相互進行通信。
（5）都使用InputStream的實例來接收信息，使用OutputStream的實例來發送消息，實例按 如下方式創建：
output=clientSocket.getOutputStream();
input=clientSocket.getInputStream();
InputStream和OutputStream僅處理由字節組成的信息。要處理更復雜的數據，需要把它們 轉換為一個字節流。Java提供了一系列的過濾器filter，可以把原始字節轉換為其它形式。
如：DataOutputStream和DataInputStream允許對Java基本類型的直接傳輸；而 ObjectOutputStream和ObjectInputStream允許交換Java對象。
（6）為了發送對象，Java使用了串行化（serialization）的方法。通過該技術，每個對象 被ObjectOutputStream轉化為二進制形式來傳輸，被ObjectInputStream接收到時進行重構 。大多數對象均可串行化，要求是它們是實現了java.io.Serializable接口的類。
如下方式包裝二進制流：
output=new objectOutputStream(clientSocket.getOutputStream());
發送對象：
output.writeObject(msg);
為接收對象，要創建一個對象輸入流：
input=new ObjectInputStream(clientSocket.getInputStream());
在一個循環中安排如下語句：
msg=input.readObject();
10、OCSF（Object Client-Server Framework）對象客戶機-服務器框架
OCSF包含了三個類：一個用于實現客戶機，另兩個實現服務器。
（1）AbstractClient: openConnection, sendToServer, closeConnection,? connectionClosed, connectionException,connectionEstablished,? handleMessageFromServer.
（2）AbstractServer: listen, stopListening, close, sendToAllClinets,? getClientConnections, clientConnected, clientException, serverStarted,? serverStopped, listeningException, serverClosed, handleMessageFromClient.
（3）ConnectionToClient: sendToClient, close, setInfo, getInfo.

第四章 需求工程
1、領域分析：了解問題的背景，以便于用戶交流并作出更明智的決策。
將領域分析的文檔分為以下幾個小節：
（1）引言：為領域命名，并說明進行分析的動機；
（2）術語表：描述領域中所有術語的含義；
（3）領域的基本知識：包括科學原理、業務過程、分析技術以及各種技術的工作原理；
（4）客戶與用戶；
（5）環境：描述使用的設備與系統；
（6）當前執行的任務和規程：制作一個列表描述各種人員工作時所進行的活動；
（7）競爭性軟件：描述可以幫助用戶與客戶的可用軟件，包括已經使用的軟件和市場上銷 售的軟件；
（8）不同領域與機構之間的相似性：了解通用性與特殊性有助于創建出具有更好的可重用 性或更寬的銷售市場的軟件。
注意：不要寫過多的詳細信息，重復原始資料是一種浪費。領域分析應該只包含對已找到信 息的簡要總結，以及幫助他人查找這些信息的參考。
沒有堅實的領域分析，任何重大的軟件項目都不應當進行。
2、軟件項目的起始點：
（1）從頭開發的新軟件——零起點開發（green field development）；
（2）逐步改進一個現有的系統。
在深入分析詳細需求之前，最好盡可能早地定義問題和范圍。
3、需求：是關于系統將要完成什么工作的一段描述語句，它們必須經過所有相關人員的認 可，其目的是徹底地解決客戶的問題。
需求的類型：
（1）功能性需求：描述系統應該做什么，即為用戶或其它系統提供的服務。包括：系統中 的用戶需要了解的該系統可以完成的所有事情；涉及與本系統有接口的其它系統的所有事情 ；不應該包括需求怎樣實現的細節。進一步分：輸入、輸出、存儲、計算、定時與同步。
（2）非功能性需求：是開發過程中必須遵守的約束。它們限制可以使用的資源和軟件質量 的各個方面，即限制了決策的自由度。
非功能性需求最重要的事情之一就是使它們是可驗證的。驗證工作通常是測量系統的各個方 面，觀察測量結果是否與需求相一致。
將各種非功能性需求劃分為若干組：
（1）第一組：五個質量屬性：可用性、效率、可靠性、可維護性、可重用性。
（2）第二組：約束了系統的環境與技術：平臺、使用的技術、使用的開發過程、成本與交 付日期。
4、需求收集與分析技術
收集技術：
（1）觀察；
（2）面談；
（3）頭腦風暴：是一組人員收集信息的有效方法，做法是人們圍著桌子坐下來討論一些主 題，目的是產生新的想法；
（4）原型化：原型是一段程序，它被快速地實現且僅包含一小部分完整系統預計實現的功 能，目的是使軟件工程師較早地獲得用戶對其設計思想的反饋，從而完成需求收集。有：
??? （4.1）紙面原型（paper prototype）：是該系統的一系列圖片，它們被順序地展示給 客戶和用戶，解釋系統運行時發生的情況。優點：原型容易建立，對于并行開發較為理想。
??? （4.2）快速原型化（rapid prototyping）：用編程語言建立對系統用戶界面的模擬。 優點：可以快速地創建代碼顯示用戶界面的重要部分。缺點：不適于創建復雜系統的最終版 本，效率低并且限制創建健壯靈活的設計能力。
（5）非正式用例分析（informal use case analysis）
用例分析是一種系統的方法，用來分析用戶在你正在開發的系統上所能做的事情。
用例分析的第一步是確定將要使用本系統功能的用戶類型，他們被稱為參與者actor，每個 參與者需要使用系統做不同的事情。
5、需求文檔的類型
需要生成幾個需求文檔，每個文檔描述系統的不同部分或是不同的詳細程度。使它們之間互補。
大型系統的需求文檔通常是按照層次結構安排。頂級文檔描述整個系統、各個子系統以及子系統之間的交互方式。還有獨立的文檔描述每個子系統。
確定需求文檔的類型及詳細程度：
（1）系統的大小；
（2）與其它系統接口的需要；
（3）目標讀者；
（4）開發合同的簽訂；
（5）需求收集的階段；
（6）領域與技術的經驗水平；
（7）需求存在缺陷所導致的代價。
需求定義（Requirement Definition）一般指包含較少細節的高層文檔。
需求規格說明（Requirement Specification）指更詳細、更精確的文檔。
6、需求評審
需求評審可能要經歷多輪改進和反復的評審。
評審過程的最高階段通常是召開由所有相關人員參加的正式需求評審會議。每個獨立的需求

都應該仔細評審。需求應該是：
（1）效益大于開發成本；
（2）對解決當前的問題是重要的；
（3）使用清晰一致的表示方法表達；
（4）沒有歧義；
（5）邏輯上一致；
（6）使系統有足夠的質量；
（7）現實地對待可用資源；
（8）是可驗證的；
（9）可唯一識別；
（10）不對系統設計做超前約束；
（11）文檔應該足夠完整；
（12）文檔應該有合理的組織結構；
（13）推理應當清晰；
（14）文檔應該被所有相關人員認可；
7、管理變化的需求
可預計的變化：
（1）業務過程的變化；
（2）技術變化；
（3）對問題有了更深入的理解；
8、領域和需求分析中的困難與風險
（1）對領域或實際問題缺少理解和發送誤解；
（2）需求可能變化很快，導致需求“波動”；
（3）試圖完成的工作太多；
（4）協調有沖突的需求可能是困難的；
（5）準確地陳述需求是困難的。

?

轉載于:https://www.cnblogs.com/yangjin-55/archive/2006/10/26/2787103.html

總結

以上是生活随笔為你收集整理的《面向对象软件工程》笔记（一）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。