软件需求分析与设计-活动图、状态图和需求细化课件.ppt

1、软件需求分析与设计 活动图、状态图和需求细化2022-12-172软件分析与设计活动图、状态图和需求细化 UML活动图及其建模 UML状态机图和建模 更多的SSD和契约2022-12-173UML活动图及其建模 目标 通过实例和各种建模应用对UML活动图表示法进行介绍2022-12-174如何应用活动图 UML活动图提供了丰富的表示法来表示一系列活动，其中包括并行的活动 业务建模过程 数据流建模 数据流图DFD 并发编程和并行算法建模 统一过程的规程之一是业务建模（business Modeling）,其用途是理解和勾通“将要部署系统的组织结构和动态特征”2022-12-175基本的UML活动

2、图表示法Receive Video OrderFill OrderSend InvoiceDeliver OrderReceive PaymentClose OrderFulfillmentCustomer ServiceFinanceOrderInvoicestartAction.It does something.There is an automatic transition on its completion.A transition supports modeling of control flow.Fork.One incoming transition,and multiple

3、outgoing parallel transitions and/or object flows.Partitions.Show different parties involved in the processJoin.Multiple incoming transitions and/or object flows;one outgoing transition.The outgoing continuation does not happen until all the inputs arrive from all flows.Object Node.An object produce

4、d or used by actions.This allows us to model data flows or object flows.end of activity2022-12-176使用Game-Sarson表示法的经典DFD1Check Course AvailabilityCourses2Check Applicant QualificationApplicationsStudentsApplicantapplicationcourse dataapplicationapplicationstudent dataaccept/deny replyexternal actord

5、ata store,such as a DB,DB table,or filedata flowprocessDFD for Automated Course Registration System2022-12-177使用活动图表示法来表示数据流模型StudentRegistration SystemApplicationComplete ApplicationCheck Course AvailabilitydatastoreCoursesdatastoreApplicationsCheck Applicant QualificationdatastoreStudentsAccept/De

6、nyReply2022-12-178在另外一个图中展开活动Fill OrderDeliver Orderthe“rake”symbol(which represents a hierarchy)indicates this activity is expanded in a sub-activity diagram2022-12-179活动的扩展Deliver RegularDeliver Rush rush else Deliver OrderDecision:Any branch happens.Mutual exclusionMerge:Any input leads to contin

7、uation.This is in contrast to a join,in which case all the inputs have to arrive before it continues.2022-12-1710信号Receive Video OrderFill OrderSend InvoiceDeliver OrderReceive PaymentClose OrderAccept a signalResend InvoiceCancel requestCancel Order30 days since sent last invoice,and no payment rec

8、eivedA time signal2022-12-1711活动图建模准则 活动图通常对于涉及众多参与者的非常复杂的业务过程建模具有价值 对于简单的业务过程用例文本就够用了 在进行业务过程建模时，可以利用靶子（rake）符号和子活动图 尽量保持同一张图中所有动作节点的抽象水平2022-12-1712使用活动图对处理销售用例建模 cash payment Enter Cart ItemsCalculate Taxes and DiscountsCustomerCashierNextGen POSReceiptShop and Fill CartCartSubmit Authorization R

9、equest else Create ReceiptHand Over ItemsAuthorization ServiceAuthorize Payment2022-12-1713UML状态机图和建模 目标 通过例子和各种建模应用，介绍UML状态机图表示法2022-12-1714软件分析与设计-UML状态图和建模 UML状态图（state machine diagram）描述了某个对象的状态和感兴趣的事件以及对象响应该事件的行为 状态图显示了对象的生命周期 事件，是指一件值得注意的事情的发生 状态，是指对象在事件发生之间某种时刻所处的情形 转换，是两个状态之间的关系，它表明当某事件发生时，对

10、象从先前的状态转换到后来的状态2022-12-1715电话的状态机图off hookIdleActiveon hook Telephonestatetransitioneventinitial state2022-12-1716状态无关和状态依赖对象 如果一个对象对某事件的响应事件相同，则认为此对象对于该事件状态无关 对于所有事件，对象的相应总是相同的，则该对象是一个状态无关对象 状态依赖对象对事件的响应根据对象的状态或模式而不同 准则 为具有复杂行为的状态依赖对象建立状态图 一般业务系统通常只有少数几个复杂的状态依赖类，因此状态机建模意义不大 在过程控制、设备控制、协议处理和通讯等领域有更多

11、的状态依赖对象2022-12-1717对状态依赖对象建模 建模的两者方式 对复杂的事件交互对象建模 对操作协议和语言规范的合法序列建模 复杂的反应式对象 软件控制的物理设备 事务处理以及相关的业务对象 角色转换器 协议和合法序列 通讯协议 UI页面/窗口流和导航 UI控制器和会话 用例系统操作 单个UI窗口的事件处理2022-12-1718转换动作和监护表示法Idleon hookActivetransition actionguard conditionvalid subscriberoff hook/play dial tone2022-12-1719嵌套状态Idleoff hook/pl

12、ay dial toneon hookActivevalid subscriber PlayingDialToneDialingConnectingdigitdigitcompleteTalkingconnected2022-12-1720使用状态机进行Web页面导航建模2022-12-1721用例操作合法序列的状态机样例WatingForSaleEnteringItemsenterItemWaitingForPaymentmakeNewSalemakeCashPaymentendSaleAuthorizingPaymentmakeCheckPaymentmakeCreditPaymentau

13、thorizedProcess Sale2022-12-1722用例关联 目标 以文本和图形两种形式，使用包含（include）和扩展（extend）关联将用例联系在一起2022-12-1723用例关联 用例关联具有一些价值，但更重要的工作是编写用例文本 用例关联 包含关系 扩展关系 泛化关系2022-12-1724用例类型 具体用例 是由发起者发起，完成了参与者所期望的完整行为，它们通常是基本业务过程用例 抽象用例 永远不能被实例化；它是其他用例的子功能用例 基础用例 包含其他用例的用例，或者是被其他用例扩展或者泛化的用例 附加用例 被其他用例包含的用例、或者扩展、泛化其他用例的用例2022

14、-12-1725包含关系 当在两个或多个独立用例中存在重复，而您想避免这种冗余时，可以使用包含关系 包含关系的另外一个用途是描述异步事件的处理 用户可以在任何时候选择或分之到特定窗口、功能、Web页面或一组步骤 用例非常复杂并冗长，将其分解为子单元便于理解2022-12-1726UC1:处理销售主成功场景：主成功场景：1.顾客到某个POS终端为购买的产品或服务付费7、顾客支付，系统付款扩展：扩展：7b.用信用卡支付：包含“处理信用卡支付”用例7c.用支票支付：包含“处理支票支付”用例2022-12-1727UC2:处理租金扩展：扩展：6b.用信用卡支付：包含“处理信用卡支付”用例2022-12

15、-1728UC12:处理信用卡支付级别：子功能级别：子功能主成功场景：主成功场景：1.客户输入信息卡帐户信息2.系统向外部的支付授权服务系统发送支付授权请求3.系统接收到同意支付的信息，并通知收银员4.扩展：扩展：2a.系统与外部系统交互时检测到错误1.系统通知收银员发生错误2.收银员要求客户选择其他支付手段2022-12-1729UC1:FooBars主成功场景：主成功场景：1.扩展：扩展：a*.任何时候，客户都可以选择编辑个人信息：编辑个人信息b*.任何时候，客户都可以选择打印帮助：展现打印帮助2-11.客户取消：取消交易确认2022-12-1730用例模型中的用例包含关系NextGen

16、POSCashierCustomerHandle CashPaymentProcess RentalProcess SaleHandle CheckPaymentHandle ReturnsincludeincludeincludeincludeincludeincludeactorAccountingSystemactorCreditAuthorizationServiceManage Users.UML notation:the base use case points to the included use caseHandle CreditPayment2022-12-1731扩展关系

17、 扩展 当用例文本不好修改时可以通过扩展用例解决 再创建扩展或附加用例，并且在其中描述 在何处和何种条件下该用例扩展某基础用例的行为2022-12-1732UC1:处理销售扩展点：扩展点：2a.VIP客户，步骤1。支付，步骤7主成功场景：1.顾客到某个POS收费口为购买的产品或服务付费。7.顾客付费，系统处理支付2022-12-1733UC1:处理增券支付触发：触发：客户想使用赠券支付扩展点扩展点：处理销售中的支付级别：级别：子功能主成功场景：主成功场景：1.客户将赠券交给收银员2.收银员输入赠券ID2022-12-1734扩展关系Process SaleExtension Points:Pa

18、ymentVIP CustomerextendPayment,if Customer presents a gift certificateUML notation:1.The extending use case points to the base use case.2.The condition and extension point can be shown on the line.Handle Gift Certificate Payment2022-12-1735领域模型的精化 目标 使用泛化、特化、关联类、时间间隔、组合和包等概念精化领域模型 确定在何时表示子类才具有价值2022

19、-12-1736领域模型的精化新概念分类列表分类示例有形对象CreditCard,Check事务CashPayment,CreditPayment,CheckPayment其他外部的计算机或者机电系统CreditAuthorizationService,CheckAuthorizationService抽象名称概念组织结构CheckAuthorizationService,CheckAuthorizationService金融、工作、合同、法律事务等的记录AccountsReceivable2022-12-1737UC1:处理销售扩展：扩展：7b.7b.信用卡支付：1.客户输入信用卡帐户信息信

20、用卡帐户信息2.系统向外部的支付授权系统支付授权系统发送支付授权请求支付授权请求，请求支付批准支付批准2a.系统侦测到与外部系统协作失败1.系统向收银员发送错误信号2.收银员要求客户使用其他支付手段3.系统接收到支付批准支付批准应答，并通知收银员3a.系统接收到拒绝支付应答拒绝支付应答：1.系统向收银员通知拒绝应答2.收银员要求客户使用其他支付手段4.系统记录此次信用卡支付信用卡支付的信息，其中包括支付批准信息5.系统显示信用卡支付签名输入机制6.收银员要求客户签名。客户签名。7c.支票支付1.客户填写支票支票，并且同驾驶证驾驶证一起交给收银员2.出纳员将驾驶证号码写在支票上，输入这些信息，请

21、求支票支付授权支票支付授权3.产生一个支票支付请求支票支付请求并且将她发送到外部的支票授权服务系统支票授权服务系统4.接收到支票支付批准应答并通知收银员5.系统记录此次支票支付支票支付的信息，包括支付批准信息2022-12-1738泛化特化层次体系CashPaymentCreditPaymentCheckPaymentPaymentsuperclass-more general conceptsubclass-more specialized conceptthese are conceptual classes,not software classes泛化（Generaliza）是在多个概念

22、中识别共性和定义超类（普遍概念）与子类（具体概念）关系的活动2022-12-1739使用独立箭头和共享箭头表示法的类层关系CashPaymentCreditPaymentCheckPaymentPaymentCashPaymentCreditPaymentCheckPaymentPayment2022-12-1740概念超类和子类定义：Payment类的层次结构CashPaymentCreditPaymentCheckPaymentPaymentamount:Money2022-12-1741集合关系的Venn图PaymentCashPaymentCreditPaymentCheckPayme

23、nt2022-12-1742子类的一致性CashPaymentCreditPaymentCheckPaymentPaymentamount:MoneySalePays-for11100原则：概念超类的定义必须100适用于子类。子类必须100与超类一致，包括属性和关联Is-a规则：子类是一种超类2022-12-1743合法的概念类划分，但在我们的领域有用吗MaleCustomerFemaleCustomerCustomerCorrect subclasses.But useful?2022-12-1744划分概念子类的动机 子类有额外的有意义的属性 子类有额外的有意义的关联 子类概念的操作、处理

24、、反映或使用的方式不同于其超类或其他子类，而这些方法是我们所关注的 子类概念表示了一个活动体，其行为与超类或者其他子类不同，而这些行为是我们所关注的2022-12-1745子类划分的实例概念子类划分的动机示例子类有额外的有意义的属性Payments不适用LibraryBook具有新的属性ISBN，是LoanabledResource的子类子类有额外的有意义的关联PaymentsCreditPayments和CreditCard类关联是Payments类的子类LibraryVideo类和Director类关联是LoanabledResource的子类子类概念的操作、处理、反应或使用的方式不同于其

25、超类或其他子类，而这些方法是我们所关注的Payments Payment的子类CreditPayment类的授权处理方式与其他的Payment子类都不相同LibrarySoftware在借出时需要押金，是LoanabledResource的子类子类概念表示了一个活动体，其行为与超类或者其他子类不同，而这些行为是我们所关注的Payments不适用Library不适用MarketResearchMaleHuman与FaleHuman的购物习惯不同是Human的子类2022-12-1746何时定义概念超类 潜在的概念子类表示的是相似概念的不同变体 子类满足100和Is-a规则 所有子类都具有相同的属

26、性，可以将其解析出来并在超类中表达 所有子类都具有相同的关联，可以将其解析出来并与超类关联2022-12-1747证明Payment子类的合理性CashPaymentCreditPaymentCheckPaymentPaymentamount:MoneyCheckIdentifies-credit-withPaid-with*each payment subclass is handled differentlyadditional associationssuperclass justified by common attributes and associationsSalePays-fo

27、rCreditCard11112022-12-1748证明AuthorizationService层次结构的合理性CreditAuthorizationServiceCheckAuthorizationServiceCheckPaymentAuthorizationServiceaddressnamephoneNumberadditional associationssuperclass justified by common attributes and associationsStoreAuthorizes-payments-of*AuthorizesCreditPaymentAuthor

28、izes*112022-12-1749外部服务事务的一个可能的类层次结构CreditPaymentApprovalReplyCheckPaymentApprovalReplyCreditPaymentApprovalRequestCheckPaymentApprovalRequestCreditPaymentDenialReplyCheckPaymentDenialReplyCheckPaymentAuthorizationReplyCreditPaymentAuthorizationReplyPaymentAuthorizationReplyPaymentAuthorizationReque

29、stPaymentAuthorizationTransactiondatetimeConcepts too fine grained?Useful to show this degree of partitioning?Each transaction is handled differently,so it is useful to partition them into discrete classes.2022-12-1750事务类层次结构的另一方案CreditPaymentApprovalRequestCheckPaymentApprovalRequestPaymentAuthoriz

30、ationReplyPaymentAuthorizationRequestPaymentAuthorizationTransactiondatetimeCreditPaymentApprovalReplyCheckPaymentApprovalReplyCreditPaymentDenialReplyCheckPaymentDenialReply2022-12-1751抽象类概念PaymentCashPaymentCreditPaymentCheckPaymentPaymentCashPaymentCreditPaymentCheckPaymentIf a Payment instance m

31、ayexist which is not a CashPayment,CreditPayment or CheckPayment,then Payment is not an abstract conceptual class.Payment is an abstract conceptual class.A Payment instance must conform to one of the subclasses:CashPayment,CreditPayment or CheckPayment.(a)(b)abstract conceptual class如果类C的每个成员也必须是某个子

32、类的成员，则C类被成为抽象概念类在领域模型中使用斜体字表示抽象类的名称，或用abstrator2022-12-1752抽象类表示法CashPaymentCreditPaymentCheckPaymentPaymentamount:Moneyabstract class indicated by italics在领域模型中使用斜体字表示抽象类的名称，或用abstrator2022-12-1753对变化的状态建模Paymentnot usefulthese subclasses are changing states of the superclassUnauthorizedPaymentAuth

33、orizedPaymentPaymentStatebetterUnauthorizedStateAuthorizedStatePaymentIs-in1*不要将概念X的状态建模为X的子类定义状态类层次结构，并将其与类X关联在领域模型中忽略概念的状态，而在状态图中加以反映2022-12-1754关联类：属性的不当使用addressmerchantIDnamephoneNumberAuthorizationServiceaddressmerchantIDnameStoreboth placements of merchantID are incorrect because there may be

34、 more than one merchantID在领域模型中，如果C可能同时有多个相同的属性A，则不要将属性A置于C之中，应该将属性A放在另一个类中然后将其与类C关联起来2022-12-1755对merchantID问题建模的首次使用addressnamephoneNumberAuthorizationServiceaddressnameStoremerchantIDServiceContractPurchases1.*a better model,but notyet as useful as possible3SellsAuthorizes-payments-via1.*2022-12-

35、1756一个关联类addressnamephoneNumberAuthorizationServiceaddressnameStoremerchantIDServiceContractan association class its attributes are related to the associationits lifetime is dependent on the association Authorizes-payments-via1.*在领域模型中增加关联类的可能线索有：有某个属性与关联相关关联类的实例具有依赖于关联的生命期两个概念之间有多对多关联，并且存在于关联自身相关的信

36、息2022-12-1757多个关联类salaryEmploymentEmploysCompanyPerson*dateOfIncarcerationJailTermIncarceratesJailPerson*Married-toPerson0.10.11a person may have employment with several companies2022-12-1758聚合关系和组合关系 在下列情形下，可以考虑组合关系 部分的生命期在组成的生命期限之内，部分的创建和删除依赖于整体 在物理或者逻辑组装上，整体部分关系很明确 组成的某些属性会传递给部分 对组成的操作可能传递给部分 识别和

37、显示组合关系的好处 有利于澄清部分对整体依赖的领域约束 有助于使用GRASP创建者模式时识别创建者 对整体的复制、拷贝这些操作可能传递给部分2022-12-1759POS应用中的聚合SalesLineItemSale1.*ProductDescriptionProductCatalog1.*112022-12-1760ProductPrices和时间间隔SaledateTime.SalesLineItemquantityProductDescriptiondescriptionitemID1.*Described-by*1ProductCatalog.ProductPriceactiveInt

38、erval:TimeIntervalprice:MoneyTimeIntervalstart:timeStampend:timeStamp1.*11Priced-by?1.*需要区别销售发生时的历史价格和当前价格2022-12-1761角色名称FlightCityFlies-to*destinationrole namedescribes the role of a city in the Flies-to associationPerson*parentCreates 42child1显示的角色名称并不是必需的当对象的角色并不清楚时，使用显示的角色名称是有效的2022-12-1762对人类角

39、色建模的两种方式StorePersonEmploys-to-handle-salescashierEmploys-to-managemanager*Manages4*workermanagerStoreCashierManagerEmploys*Employs*roles as conceptsManages 6*roles in associations111112022-12-1763导出属性dateTime/total.Salederived attribute在UML中，在元素名称的前面加”/”来表示导出元素要避免在图中显示导出元素，因为这些导出元素在没有增加新信息的情况下还会增加复杂

40、性2022-12-1764与多重性相关的导出属性SalesLineItem1.*Sale/quantityderivable from the actual multiplicity12022-12-1765受限关联ProductCatalogProductDescriptionitemIDContainsProductCatalogProductDescriptionContains1.*multiplicity reduced to 1(a)(b)qualifier111在关联中可能会用到限定词（qualifier）；基于限定词的值可以区分位于关联另一端的对象集合。具有限定词的关联是受限关

41、联2022-12-1766自反关联Person*parentCreates 42child概念到自身的关联成为自反关联（reflexive association）2022-12-1767使用包来组织领域模型：一个UML包DomainCore ElementsSales2022-12-1768在包内被引用的类SalesCore ElementsSaleCore Elements:RegisterCapturesStoreRegisterHas1.*1112022-12-1769包的依赖关系DomainCore ElementsSales如果一个包引用了由其他包所拥有的某元素，则存在一个依赖关系

42、2022-12-1770如何划分领域模型 将领域模型划分为包结构时，将满足下属条件的元素放在一起 在同一个主题领域，概念或目标密切相关的元素 在同一个类层次结构中的关系 参与同一个用例的元素 由很强的关联性的元素2022-12-1771POS领域概念包DomainCore/MiscPaymentsProductsSalesAuthorization Transactions2022-12-1772Core包Core/MiscRegisterManagerStoreaddressnameHouses1.*Employs1.*112022-12-1773Payment包PaymentsCheckA

43、ccountsReceivableCreditPaymentCheckPaymentCheckAuthorizationServiceCreditAuthorizationServiceAuthorized-byAuthorized-by*AuthorizationServiceaddressnamephoneNumberCore:StorePaymentamountEstablishes-credit-for 5Logs 4*CreditCardexpiryDatenumberDriversLicensenumber1.*Establishes-identity-for 5Paid-by C

44、ashPaymentamountTendered*Sales:CustomerAbused-by4IdentifiesAuthorization Transactions:PaymentAuthorizationReply-CheckPayments have CheckPaymentReplies-CreditPayments have CreditPaymentReplies111111111113Authorizes-payments-ofmerchantIDServiceContract12022-12-1774Products包Products1.*Core:StoreStocks*

45、Describes*Sales:SalesLineItemDescribed-by*Records-sale-of60.1ProductDescriptiondescriptionpriceitemIDProductCatalogItem111112022-12-1775Sale包SalesCashierCustomer1.*SalesLineItem/quantitySaledateisCompletetimeInitiates Core:RegisterRecords-sales-on5Captured-on4Core:Store3Logs-completed*11111111TaxLin

46、eItemdescriptionpercentageamount1.*12022-12-1776Authorization Transaction包Authorization TransactionsCreditPaymentApprovalRequestCheckPaymentApprovalRequestPaymentAuthorizationReplyPaymentAuthorizationRequestCreditPaymentApprovalReplyCheckPaymentApprovalReplyCreditPaymentDenialReplyCheckPaymentDenial

47、ReplyPaymentAuthorizationTransaction2022-12-1777SSD的公共开始部分enterItem(itemID,quantity):NextGenPOSSystem:CashierendSaleProcess Sale Scenariodescription,totaltotal with taxesmakeNewSaleactor:TaxCalculatortaxLineItems=getTaxes(sale)more items loop2022-12-1778信用卡支付SSDmakeCreditPayment(credNum,expiryDate)r

48、eply=requestApproval(request):CustomerpostReceivable(receivable):NextGenPOSSystemactor:CreditAuthorizationServiceactor:AccountspostSale(sale)2022-12-1779支票支付SSDmakeCheckPayment(driversLicenseNumber)reply=requestApproval(request):Cashier:NextGenPOSSystemactor:CheckAuthorizationService2022-12-1780契约CO

49、5:makeCreditPayment操作：makeCreditPyment(creditAccountNumber,expirDate)交叉引用：用例：ProcessSale前置条件：销售正在进行中，已经输入了所有的销售项目后置条件：l创建了CreditPayment的实例pmtl将pmt与Sale的当前实例Sale关联起来l创建了CreditCard的实例cc;并且cc.number=creditAccountNumber,cc.expiryDate=expriyDatel将cc与pmt关联起来l创建了CreditRequest的一个实例cprl将pmt与cpr关联起来l创建了receiv

50、ableEntry的实例rel将re与外部的AccountsReceivable关联起来l将Sale与Store关联起来2022-12-1781契约CO5:makeCreditPayment操作：makeCheckPayment(driversLicenceNumber)交叉引用：用例：Process Sale前置条件：销售正在进行中，已经输入了所有的销售项目后置条件：l创建了CheckPayment的实例pmtl将pmt于Sale的当前实例Sale关联起来l创建了DriversLicense的实例dl;并且cc.number=driverLicenseAccountNumberl将dl与pm