第二部分-面向?qū)ο笙到y(tǒng)分析與設計課件

第二部分面向?qū)ο笙到y(tǒng)分析與設計

第八講主要內(nèi)容：從需求分析進入設計

交互圖的UML表示法

設計模式和GRASP

expertcreator

highcohesionlowcouplingcontroller第14章--FROMREQUIREMENTSTO

DESIGNINTHISITERATION迭代中從需求到設計到目前為止，我們在分析案例時強調(diào)了需求調(diào)查，領域的概念以及與系統(tǒng)有關的操作。按照UP指導，可能有10%的重要需求在初始階段調(diào)查，細化階段第一次迭代已稍微細致地進行了調(diào)查和分析。下來可以對這一部分需求轉(zhuǎn)入進行解決方案的設計。設計工作是借助于設計軟件對象間的協(xié)作來完成的。主要思想迭代地做正確的事情，所作的事情要正確。

（需求分析）（系統(tǒng)設計）以對象（object）來進行設計。

按對象設計的方案包括建立交互圖（interactiondiagrams）和設計類類圖（designclassdiagrams）應用職責分配（assigningresponsibilities）的原則和設計模式（designpatterns）來建立交互圖第15章--INTERACTIONDIAGRAM

NOTATION交互圖的表示法順序圖（SequenceDiagrams）和協(xié)作圖（CollaborationDiagrams）協(xié)作圖（CollaborationDiagrams）順序圖（SequenceDiagrams）交互圖（InteractionDiagrams）圖：15.1Collaborationdiagram

bamessage1()message2()message3()method1()…b.method2()…b.method3()…method1()method2()method3()圖：15.2Sequencediagram.

message1()message2()message3()協(xié)作圖的例子：makePayment說明：消息makePament被發(fā)送給一個Register的實例。沒有指出發(fā)送者。Register的實例發(fā)送makePament消息給一個Sale的實例。Sale的實例創(chuàng)建一個Payment的實例。圖：15.3Collaborationdiagram.

makePayment(cashTendered)1:makePayment(cashTendered)1.1:create(cashTendered)

圖：15.4Sequencediagram.

:RegisterAnactivationboxshowingthefocusofcontrol交互圖表示法的公共部分/1表示類（classes）和實例（instances）圖：15.5Classandinstances.

交互圖表示法的公共部分/2基本的消息表達式TheUMLhasastandardsyntaxformessageexpressions:

return:=message(parameter:parameterType):returnType

Typeinformationmaybeexcludedifobviousorunimportant.Forexample:

spec:=getProductSpect(id)

spec:=getProductSpect(id:ItemID)

spec:=getProductSpect(id:ItemID)

ProductSpecification

基本協(xié)作圖的基本表示法連接線（Link）消息（Messages）發(fā)給自身的消息（Messagesto“self”orThis）實例創(chuàng)建（CreationofInstances）消息編號順序（MessageNumberSequencing）條件消息（ConditionalMessages）互斥條件的路徑（MutuallyExclusiveConditionalPaths）迭代（IterationorLooping）發(fā)給對象集中對象的消息迭代（IterationOveraCollection(Multiobject)）發(fā)給類對象的消息（MessagestoClassObject）圖：15.6Linklines.

連接（Link）圖：15.7Messages.

消息（Messages）圖：15.8Messagesto"this."

發(fā)給自身的消息（Messagesto“self”orThis）圖：15.9Instancecreation.

實例創(chuàng)建（CreationofInstances）圖：15.10amorecomplexcaseisshown.

消息編號順序（MessageNumberSequencing）圖：

15.11Complexsequencenumbering.

消息編號順序（MessageNumberSequencing）圖：15.12Conditionalmessage.

條件消息（ConditionalMessages）圖：15.13Mutuallyexclusivemessages.互斥條件的路徑（MutuallyExclusiveConditionalPaths）圖：15.14Iteration.迭代（IterationorLooping）圖：

15.15Iterationoveramultiobject.

對象集的迭代（IterationOveraCollection(Multiobject)）圖：15.16Messagestoaclassobject(staticmethodinvocation).

類對象消息（MessagestoClassObject）順序圖的基本表示法連接線（Links）--順序圖不用連接符號消息（Messages）表示消息返回（IllustratingReturns）發(fā)給自身的消息（Messagesto“self”orThis）實例創(chuàng)建（CreationofInstances）對象生命線和對象銷毀（ObjectLifelinesandObjectDestruction）條件消息（ConditionalMessages）互斥條件消息（MutuallyExclusiveConditionalMessages）單一消息的迭代（IterationforSingleMessage）一組消息的迭代（IterationforaSeriesofMessages）發(fā)給對象集中對象的消息迭代（IterationOveraCollection(Multiobject)）發(fā)給類對象的消息（MessagestoClassObject）圖：15.17Messagesandfocusofcontrolwithactivationboxes.

消息（Messages）同步消息異步消息圖：15.18Showingreturns.表示消息返回（IllustratingReturns）消息返回圖：

15.19Messagesto"this."發(fā)給自身的消息（Messagesto“self”orThis）圖：15.20Instancecreationandobjectlifelines.

實例創(chuàng)建（CreationofInstances）圖：15.21Objectdestruction

對象生命線和對象銷毀（ObjectLifelinesandObjectDestruction）圖：15.22Aconditionalmessage.

條件消息（ConditionalMessages）圖：15.23Mutuallyexclusiveconditionalmessages互斥條件消息（MutuallyExclusiveConditionalMessages）圖：15.24Iterationforonemessage.單一消息的迭代（IterationforSingleMessage）圖：15.25Iterationforasequenceof

一組消息的迭代（IterationforaSeriesofMessages）圖：15.26Iterationoveramultiobject

對象集的迭代（IterationOveraCollection(Multiobject)）圖：15.27Invokingclassorstaticmethods類對象消息（MessagestoClassObject）第16章--GRASP:DESIGNINGOBJECTSWITHRESPONSIBILITIESGRASP:設計具有職責的對象職責（Responsibility）和方法（Methods）UML定義職責(Responsibility)為“一個類型的契約或義務(acontractorobligationofaclassifier)”

。方法(Method)用來實現(xiàn)（履行）職責。一個職責可能要許多類和方法(method)來實現(xiàn)，也可能只要很少方法來實現(xiàn)，這是由職責的粒度(granularity)來決定的。職責（Responsibility）可分成兩類：“知道”型職責（knowing）“做”型職責（doing）“知道”私有的封裝數(shù)據(jù)“知道”相關聯(lián)的對象“知道”能夠派生或計算出的事物“做”自身的一些事情。如創(chuàng)建一個對象或進行一次計算。“做”其它對象的初始化操作?？刂坪蛥f(xié)調(diào)其它對象的活動。職責（Responsibility）和交互圖（InteractionDiagrams）：在UML制品（artifacts）中，通常是在建立交互圖的語境來考慮對象的職責分配，通過方法來實現(xiàn)職責。圖：16.1Responsibilitiesandmethodsarerelated.

創(chuàng)建Payments的職責用makePament(cashTendered)消息引用。意味著我們應該給Sale類設計一個方法makePament(cashTendered)實現(xiàn)創(chuàng)建Payments的職責。圖：16.2Softwareclassesillustratemethodnames.

UML對軟件類的表示法Saledate:Datetime:TimemakePayment(cashTendered)設計模式（Patterns）富有經(jīng)驗的面向?qū)ο蠹夹g(shù)專家（或其它軟件開發(fā)人員）為解決某些問題而設計的解決方案，可作為通用原則(GeneralPrinciples)和慣用法(Idioms)，用于指導軟件設計。如果將這些原則和慣用法以一種結(jié)構(gòu)化的形式加以描述，給出問題和解決方案，然后起一個名字。這就是設計模式(Patterns)。例如：模式名：信息專家（InformationExpert）問題：為了獲取某些信息，分配職責給對象的基本原則是什么？解決方案：將職責分配給信息專家--含有滿足職責所需信息的類。設計模式是一些針對特定問題的成功的解決方案GRASP：分配職責通用原則的模式

GRASP作為設計模式來描述對象設計和職責分配的基本原則。GRASP模式：InformationExpertCreator

HighCohesionLowCouplingControllerGeneralResponsibilityAssignmentSoftwarePattern信息專家（InformationExpert）模式名：信息專家（或?qū)＜遥┙鉀Q的問題：為了獲取某些信息，分配職責給對象的基本原則是什么？解決方案：將職責分配給信息專家--含有滿足職責所需信息的類。圖：12.9Apartialdomainmodel.我們指望從領域模型找出知道銷售總金額有關信息的專家，這個專家可能是Sale假設，某些類需要知道一次銷售(Sale)的總金額。我們將這個職責分配給誰？圖：16.3AssociationsofSale.

圖：16.4Partialinteractionandclassdiagrams.

我們按領域模型的Sale概念類設計一個軟件類Sale，將分配給對象:Sale的職責，實現(xiàn)為類Sale的一個方法getTotal()。我們按InformationExpert模式，給對象:Sale分配一個取得總金額的職責getTotal()。圖：16.5CalculatingtheSaletotal

按領域模型的SalesLineItem概念類設計一個軟件類SalesLineItem，將分配給對象:SalesLineItem的職責實現(xiàn)為類SalesLineItem的方法getSubtotal()。為了得到每個銷售項的子金額，按InformationExpert模式，給對象:SalesLineItem分配職責getSubtotal()。圖：16.6CalculatingtheSaletotal.

按領域模型的ProductSpecification概念類設計一個軟件類ProductSpecification，將分配給對象:ProductSpecification的職責實現(xiàn)為類ProductSpecification的一個方法getPrice()。為了得到產(chǎn)品價格，按InformationExpert模式，給對象:ProductSpecification，分配一個取得商品價格的職責getPrice()。結(jié)