探討：

用面向對象等思想

使用UML

設計系統(2)丁旭

軟件開發部

合肥智同面向對象主要的軟件概念

----羅列封裝信息/實現隱藏狀態保持對象標識消息類繼承多態性一般性面向對象主要的軟件概念

----封裝封裝是將相關的概念組成一個單元，其后可以通過一個名稱來引用它子程序封裝子模塊封裝面相對象封裝是將表示狀態的操作和屬性包裝成一個對象類型，使得對狀態的訪問或修改只能通過封裝提供的接口進行。面向對象主要的軟件概念

----信息/實現隱藏信息/實現隱藏（information/implementationhiding）是使用封裝將某些信息或實現方式限制，在封裝結構內部，限制外部的可見性。你可以從對象的外部（“公共角度”）或對象的內部（“私有角度”）兩種不同的角度來看待封裝單元。好的封裝結果是對公共視角封閉大量的細節。這種封閉有兩種即信息隱藏和實現隱藏。優點設計決策局部化（限制了“修改波及”問題）；其表現形式減弱了信息的內容（對象外部的信息用戶不會受到任何特殊的內部信息格式的困擾）。面向對象主要的軟件概念

----其他狀態保持對象標識（對象句柄）消息消息構成：對象句柄、操作名稱、輸入參數、輸出參數消息類型：報告消息、詢問消息、祈使消息類繼承多態性動態綁定與多態性相關的：覆蓋（overriding）？、重載（overloading）？一般性泛化：模板類傳統設計中一些經驗

----封裝與共生性封裝是將相關的概念組成一個單元，其后可以通過一個名稱來引用它(封裝級別)子程序封裝子模塊封裝面相對象封裝是將表示狀態的操作和屬性包裝成一個對象類型，使得對狀態的訪問或修改只能通過封裝提供的接口進行。考查封裝設計（輸出、內聚、耦合）傳統設計中一些經驗

----封裝與共生性共生性（相依為命connascence）執行次序（位置）同步時差算法數值標識差異共生性（contranascence）如命名、多繼承等傳統設計中一些經驗

----封裝與共生性共生性與可維護性避免友員無約束繼承為了偶然的應用面向對象的設計一些原則

----包括面向對象的設計一些原則合理處理內聚類混合事例內聚混合領域內聚混合角色內聚衡量面向對象設計

---檢驗設計模型的健壯性狀態空間不變式輸入輸出范圍多態性方法的分布面向對象與傳統設計的異同相同之處??差異之處??LogicalDesignConceptualDesignScenariosPhysicalDesignComponents,UserInterface,and

PhysicalDatabaseObjectsandServices,UserInterface,and

LogicalDatabase面向對象的發展歷史60年代末:Simula6780年代初:Smalltalk1.歷史：90年代:OOP,OOD和

OOA獲得廣泛應用80年代中:OOP,OOD和

OOA

進入軟件開發實踐

C++,Booch方法,OOA/OOD,OOSE,OMT面向對象的發展歷史OOA/OOD(Objectoriented)的理論目標細胞硬件IC設計沒有直接關聯的設計面向對象的發展歷史OOA/OOD(Objectoriented)的理論目標細胞硬件IC設計菜籃軟體是否可以像硬體元件一樣的分開設計；大量製造；再加以拼湊而成？就像電子元件的積體線路(IC)一樣；製做出軟體的IC？SoftwareIC設計經驗

----個人經驗總結設計中最重要的環節？（成功關鍵）理解擁有共同交流語言和工作程序長時間討論交流流程靈活明確目標“Whenprojectsfail,it’srarelytechnical.”

JimJohnson,TheStandishGroup28%46%26%Succeeded

FailedChallenged設計經驗

----個人經驗總結分析順序（遞進迭代）了解領域分析方法分工、整合、討論交流明確目標基礎靜態框架確認功能完整確立流程正確總體分層（這比OO思想更為重要）OO分析設計經驗

----個人經驗總結不同問題領域方法過程差異應用領域事件為核心商業領域角色（組織、人員）相互關系屬性結構領域人機界面數據庫機器間通信基礎領域語義結構基礎設計經驗

----個人經驗總結OOD中容易入的誤區（避免方法？？）臭名昭著的繼承不慎重的使用多繼承隨意臨時性對以設計的類添加不對暴露接口的完整性等進行推敲隨意使用友元大量使用同組開發人員不易理解的技巧模型設計用例

----商業領域UML&CRC卡例子這是一個生產企業的ERP部分（某扎鋼廠）主要視圖關系設計用例

----商業領域UML&CRC卡例子組織視圖（角色非實際人員）設計用例

----商業領域UML&CRC卡例子資源視圖設計用例

----商業領域UML&CRC卡例子工作流視圖設計用例

----商業領域UML&CRC卡例子什么是CRC卡？從UseCase里找對象及其行為了。為了要確定這些對象和其行為能為使用者提供完整而滿意的服務，應采用簡單易懂的方式來表示對象及其關系，然后由使用者來檢驗，以確保這些對象能正確執行UseCase，讓使用者心滿意足。此時，CRC表示法就可派上用場了。CRC表示法很簡單，但很有效，使用者可迅速看出各類別的服務項目，以及類別間的合作關系。CRC設計用例

----商業領域UML&CRC卡例子簡單介紹CRC表示法

CRC是「類別」（class），「責任」（responsibility）及「輔助者」（collaborator）三者的簡稱，這些資料常呈現在一張卡片上，如下由于使用者是應用領域的專家(domainexpert)，必須由其來檢驗對象及其關系，才能確保軟件的正確性。所以UseCase和CRC皆是簡單明了的工具，極適合做計算機人員與使用者的溝通工具，系統分析人員可藉之提升需求分析(requirementsanalysis)的品質。設計用例

----商業領域UML&CRC卡例子CRC例子這說明：計算機系統這個對象能提供兩項服務（即兩個責任），提供第一項服務時，必須請求「密碼」對象的協助。提供第二項服務時，需要「密碼」及「柜員機」兩個對象之協助。CRC設計經驗

----UseCase與CRC結合使用實例當一位顧客向本公司下訂單時，他心中對公司的觀點是：這公司會處理這訂單，并迅速告知最快出貨日期。這是一個「公司」的UseCase，代表著顧客將訂單送到公司時，一直到他獲知正確出貨日期為止的一連串事件（或訊息傳遞）。如果您已有許多傳統系統分析經驗，就請先看下圖的作業流程（workflow）吧。開始下定單信用查詢安排出貨日期通知顧客結束信用合格是否設計經驗

----UseCase與CRC結合使用實例Step1：確定UseCase的參與者首先描述這個「公司」的UseCase。1.1把公司當成黑箱，亦即把公司看成一個封裝（encapsulate）完整的對象。1.2把計算機系統自「公司」對象中獨立出來。使得「計算機系統」成為這UseCase的一個參與者（participactor或actor）。1.3這UseCase的目的是滿足顧客的需求。于是「顧客」是這UseCase的參與者。1.4信用查詢時，需銀行的協助，于是「銀行」也是參與者。1.5將各參與者以圖表示之：設計經驗

----UseCase與CRC結合使用實例Step2：敘述這些參與者的互動（interaction）情形公司的UseCase：接訂單正常過程1.客戶送來訂單。2.向銀行查詢客戶的信用度。3.銀行告知客戶信用度。4.向計算機系統查詢客戶的信用度。5.計算機系統送來客戶的信用度。6.把訂單傳給計算機系統，請求安排出貨日期。7.計算機傳回訂單。8.告知客戶已接受其訂單。特別過程如果客戶的信用度不合乎要求，則通知客戶，告知不接受其訂單。以圖形表示之：設計經驗

----UseCase與CRC結合使用實例Step3：打開（openup）公司黑箱設計經驗

----UseCase與CRC結合使用實例Step4：繪制公司UseCase的CRC圖Step5：采排演練，檢驗CRC卡設計經驗

----UseCase與CRC結合使用實例Step6：計算機系統的UseCase6.1把數據庫系統獨立于計算機系統之外，成為參與者(actor)。6.2CASE1：查核信用度。參與者為：會計部及數據庫系統。CASE2：排定出貨日期。參與者為：銷售部及數據庫系統。6.3將各參與者表示如圖設計經驗

----UseCase與CRC結合使用實例Step7：CASE1－查核信用度正常過程1.在屏幕上選取「信用查核」項目。2.計算機要求輸入顧客基本資料。3.輸入顧客基本資料。4..計算機要求數據庫系統找出顧客的采購歷史資料。5.數據庫傳回顧客的歷史資料。6.計算機查核后，將結果傳回給會計部。特殊過程如果數據庫找不到顧客的歷史資料，就傳回“歷史資料不詳”，并由計算機將這訊息傳送回會計部如下圖設計經驗

----UseCase與CRC結合使用實例接下來，打開「計算機系統」黑箱，若發現只需一個對象－Credit_Evaluator來負責與會計部和資料庫溝通即足夠，就能圖標如下：設計經驗

----UseCase與CRC結合使用實例接著，下先將Step4的「會計部」CRC卡修正，并制作一張新的CRC卡如下：設計經驗

----UseCase與CRC結合使用實例再繪制Credit_Evaluator及數據庫系統CRC卡，如下圖：這Credit_Evaluator及數據庫系統兩對象，擔任了Step4中「計算機系統」對象的前兩項責任－查核信用度及告知信用度。亦即「計算機系統」對象將這兩項責任委托Credit_Evaluator對象執行之。而Credit_Evaluator再委托數據庫系統來協助之。最后，依循Step5的步驟，將這個UseCase采排一番，看看是否正確。開發模式

----介紹開發模式（Paradigm）開發模式又稱為范型、范例、風范或模式(Pattern);開發模式定義了特定問題和應用的開發過程中將遵循的步驟；確定將用于表示問題和解的那些成分的類型；利用這些成分表示與問題解決有關的抽象；直接得到問題的結構;設計模式

----概念設計模式（Paradigm）設計模式提供了設計不同系統、不同應用時經常發生的問題的解決方案，向編程人員提供特定問題的可依據的方法藍圖。設計模式（DesignPatterns）

----目錄模式的本原模式的發展歷程用設計模式提高軟件開發生產力重構與設計模式設計模式（DesignPatterns）

----模式的本原簡單地說，模式是一個出現在世界上的實物，同時也是一條規則，告訴你應該如何創建一個實物、應該在何時創建。它既是過程，也是實物；既是對當前實物的描述，也是對創建實物的過程的描述。——C.Alexander，《建筑的永恒之道》ChristopherAlexander《建筑的永恒之道》（TheTimelessWayofBuilding）是一本建筑學專著。這本書，與《建筑模式語言》（APatternLanguage）、《城市設計的新理論》（ANewTheoryofUrbanDesign）等書一起，描述了一種全新的、充滿生機的建筑方法--基于模式（Pattern）的建筑方法。該書的作者ChristopherAlexander出生于奧地利的首都維也納，在英國的牛津和奇切斯特長大。早年，他在劍橋學習，受到了數學和建筑學方面的良好教育。后來，他到了美國，在哈佛拿到了建筑學博士的學位。1963年，他開始在加州大學伯克利分校擔任建筑學教授以及環境結構學院的院長。正是在伯克利的那段時間里，Alexander教授寫出了他的傳世之作，并在建筑學界引起了強烈的反響。設計模式（DesignPatterns）

----什么是模式？模式：反復出現，可交叉構筑大的系統的基本元素、基本規律設計模式（DesignPatterns）

----模式的定義模式是描述特定場景（context）、特定約束（force）下以具有無名特質的方式解決特定問題（problem）之方案（solution）的專用語言。設計模式（DesignPatterns）

----建筑學中的模式ChristopherAlexander教授的“三步曲”研究模式的理論——《建筑的永恒之道》第一個完整的模式語言——《建筑模式語言》理性地用模式來指導建筑過程——《俄勒岡實驗》設計模式（DesignPatterns）

----軟件科學中的模式管理模式——DonS.Olson,CarolL.Stimmel,TheManagerPool分析模式——MartinFowler,AnalysisPatterns設計模式實現模式——JamesCoplien,AdvancedC++;ScottMeyers,EffectiveC++重構模式——MartinFowler,Refactoring……設計模式（DesignPatterns）

----設計模式“三步曲”了解設計模式——AlanShalloway,JamesTrott，《設計模式精解》系統學習設計模式——GangofFour，《設計模式》用設計模式靈活解決實際問題——JohnVlissides,PatternHatching設計模式（DesignPatterns）

----用設計模式提高軟件開發生產力我們需要這樣一種語言：它讓我們高效地交流、討論那些常見的、重復出現的設計概念，并在這些概念上建立起我們的系統。 不要僅僅把模式當作解決方案，而要把它們當作設計的詞匯，這些詞匯可以根據一定的規則組合起來形成句子（也就是系統設計）。——BrandonGoldfedder，《模式之樂》設計模式（DesignPatterns）

----Singleton模式//Singleton.javapublicclassSingleton{ privatestaticSingleton_instance=null; privateSingleton(){}

publicstaticSingletongetInstance() { if(null==_instance) _instance=newSingleton(); return_instance; }}保存全類唯一的實例對客戶隱藏構造子客戶只能從此處獲得實例設計模式（DesignPatterns）

----Singleton模式這個模式的核心是什么？精致的solution或者巧妙的trick？C.Alexander：“每個模式是一個有三個部分的規則，它表達一定的關聯、一個問題和一個解決方式之間的關系。”

Force（約束）ProblemSolution設計模式（DesignPatterns）

----Singleton模式

Singleton模式的核心問題（Problem）：幾個不同的客戶對象需要引用同樣的對象，你希望確保自己擁有的這種對象不超過一個。解決方案（Solution）：用某種技巧保證該類最多只有一個實例。約束（Force）：不能直接用于多線程環境。如果需要提供線程安全性，則Java不能實現，C++亦需要借助Double-CheckedLocking模式才能實現。設計模式（

DesignPatterns）

----用設計模式提高軟件開發生產力用模式包容