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

软件需求分析与设计

－活动图、状态图和需求细化软件需求分析与设计

－活动图、状态图和需求细化软件分析与设计－活动图、状态图和需求细化UML活动图及其建模UML状态机图和建模更多的SSD和契约9/20/20232软件分析与设计－活动图、状态图和需求细化UML活动图及其建模UML活动图及其建模目标通过实例和各种建模应用对UML活动图表示法进行介绍9/20/20233UML活动图及其建模目标8/6/20233如何应用活动图UML活动图提供了丰富的表示法来表示一系列活动，其中包括并行的活动业务建模过程数据流建模

数据流图DFD并发编程和并行算法建模

统一过程的规程之一是业务建模（businessModeling）,其用途是理解和勾通“将要部署系统的组织结构和动态特征”9/20/20234如何应用活动图UML活动图提供了丰富的表示法来表示一系列活动基本的UML活动图表示法ReceiveVideoOrderFillOrderSendInvoiceDeliverOrderReceivePaymentCloseOrderFulfillmentCustomerServiceFinanceOrderInvoicestartAction.Itdoessomething.Thereisanautomatictransitiononitscompletion.Atransitionsupportsmodelingofcontrolflow.Fork.Oneincomingtransition,andmultipleoutgoingparalleltransitionsand/orobjectflows.Partitions.ShowdifferentpartiesinvolvedintheprocessJoin.Multipleincomingtransitionsand/orobjectflows;oneoutgoingtransition.Theoutgoingcontinuationdoesnothappenuntilalltheinputsarrivefromallflows.ObjectNode.Anobjectproducedorusedbyactions.Thisallowsustomodeldataflowsorobjectflows.endofactivity9/20/20235基本的UML活动图表示法ReceiveVideoOrde使用Game-Sarson表示法的经典DFD1CheckCourseAvailabilityCourses2CheckApplicantQualificationApplicationsStudentsApplicantapplicationcoursedataapplicationapplicationstudentdataaccept/denyreplyexternalactordatastore,suchasaDB,DBtable,orfiledataflowprocessDFDforAutomatedCourseRegistrationSystem9/20/20236使用Game-Sarson表示法的经典DFD1CheckC使用活动图表示法来表示数据流模型StudentRegistrationSystemApplicationCompleteApplicationCheckCourseAvailability«datastore»Courses«datastore»ApplicationsCheckApplicantQualification«datastore»StudentsAccept/DenyReply9/20/20237使用活动图表示法来表示数据流模型StudentRegistr在另外一个图中展开活动FillOrderDeliverOrderthe“rake”symbol(whichrepresentsahierarchy)indicatesthisactivityisexpandedinasub-activitydiagram9/20/20238在另外一个图中展开活动FillOrderDeliverO活动的扩展DeliverRegularDeliverRush[rush][else]DeliverOrderDecision:Anybranchhappens.MutualexclusionMerge:Anyinputleadstocontinuation.Thisisincontrasttoajoin,inwhichcasealltheinputshavetoarrivebeforeitcontinues.9/20/20239活动的扩展DeliverRegularDeliverRu信号ReceiveVideoOrderFillOrderSendInvoiceDeliverOrderReceivePaymentCloseOrderAcceptasignalResendInvoiceCancelrequestCancelOrder30dayssincesentlastinvoice,andnopaymentreceivedAtimesignal9/20/202310信号ReceiveVideoOrderFillOrde活动图建模准则活动图通常对于涉及众多参与者的非常复杂的业务过程建模具有价值对于简单的业务过程用例文本就够用了在进行业务过程建模时，可以利用靶子（rake）符号和子活动图尽量保持同一张图中所有动作节点的抽象水平9/20/202311活动图建模准则活动图通常对于涉及众多参与者的非常复杂的业务过使用活动图对处理销售用例建模[cashpayment]EnterCartItemsCalculateTaxesandDiscountsCustomerCashierNextGenPOSReceiptShopandFillCartCartSubmitAuthorizationRequest[else]CreateReceiptHandOverItemsAuthorizationServiceAuthorizePayment9/20/202312使用活动图对处理销售用例建模[cashpayment]UML状态机图和建模目标通过例子和各种建模应用，介绍UML状态机图表示法9/20/202313UML状态机图和建模目标8/6/202313软件分析与设计-UML状态图和建模UML状态图（statemachinediagram）描述了某个对象的状态和感兴趣的事件以及对象响应该事件的行为状态图显示了对象的生命周期事件，是指一件值得注意的事情的发生状态，是指对象在事件发生之间某种时刻所处的情形转换，是两个状态之间的关系，它表明当某事件发生时，对象从先前的状态转换到后来的状态9/20/202314软件分析与设计-UML状态图和建模UML状态图（state电话的状态机图offhookIdleActiveonhookTelephonestatetransitioneventinitialstate9/20/202315电话的状态机图offhookIdleActiveonho状态无关和状态依赖对象如果一个对象对某事件的响应事件相同，则认为此对象对于该事件状态无关对于所有事件，对象的相应总是相同的，则该对象是一个状态无关对象状态依赖对象对事件的响应根据对象的状态或模式而不同准则为具有复杂行为的状态依赖对象建立状态图一般业务系统通常只有少数几个复杂的状态依赖类，因此状态机建模意义不大在过程控制、设备控制、协议处理和通讯等领域有更多的状态依赖对象9/20/202316状态无关和状态依赖对象如果一个对象对某事件的响应事件相同，则对状态依赖对象建模建模的两者方式对复杂的事件交互对象建模对操作协议和语言规范的合法序列建模复杂的反应式对象软件控制的物理设备事务处理以及相关的业务对象角色转换器协议和合法序列通讯协议UI页面/窗口流和导航UI控制器和会话用例系统操作单个UI窗口的事件处理9/20/202317对状态依赖对象建模建模的两者方式8/6/202317转换动作和监护表示法IdleonhookActivetransitionactionguardcondition[validsubscriber]offhook/playdialtone9/20/202318转换动作和监护表示法IdleonhookActivetra嵌套状态Idleoff

hook

/

play

dial

toneon

hookActive[validsubscriber]PlayingDialToneDialingConnectingdigitdigitcompleteTalkingconnected9/20/202319嵌套状态Idleoffhook/playdialt使用状态机进行Web页面导航建模9/20/202320使用状态机进行Web页面导航建模8/6/202320用例操作合法序列的状态机样例WatingForSaleEnteringItemsenterItemWaitingForPaymentmakeNewSalemakeCashPaymentendSaleAuthorizingPaymentmakeCheckPaymentmakeCreditPaymentauthorizedProcessSale9/20/202321用例操作合法序列的状态机样例WatingForSaleEnt用例关联目标以文本和图形两种形式，使用包含（include）和扩展（extend）关联将用例联系在一起9/20/202322用例关联目标8/6/202322用例关联用例关联具有一些价值，但更重要的工作是编写用例文本用例关联包含关系扩展关系泛化关系9/20/202323用例关联用例关联具有一些价值，但更重要的工作是编写用例文本8用例类型具体用例是由发起者发起，完成了参与者所期望的完整行为，它们通常是基本业务过程用例抽象用例永远不能被实例化；它是其他用例的子功能用例基础用例包含其他用例的用例，或者是被其他用例扩展或者泛化的用例附加用例被其他用例包含的用例、或者扩展、泛化其他用例的用例9/20/202324用例类型具体用例8/6/202324包含关系当在两个或多个独立用例中存在重复，而您想避免这种冗余时，可以使用包含关系包含关系的另外一个用途是描述异步事件的处理用户可以在任何时候选择或分之到特定窗口、功能、Web页面或一组步骤用例非常复杂并冗长，将其分解为子单元便于理解

9/20/202325包含关系当在两个或多个独立用例中存在重复，而您想避免这种冗余UC1:处理销售…主成功场景： 1.顾客到某个POS终端为购买的产品或服务付费 … 7、顾客支付，系统付款扩展： 7b.用信用卡支付：包含“处理信用卡支付”用例 7c.用支票支付：包含“处理支票支付”用例9/20/202326UC1:处理销售…8/6/202326UC2:处理租金…扩展： 6b.用信用卡支付：包含“处理信用卡支付”用例

9/20/202327UC2:处理租金…8/6/202327UC12:处理信用卡支付…级别：子功能主成功场景： 1.客户输入信息卡帐户信息 2.系统向外部的支付授权服务系统发送支付授权请求 3.系统接收到同意支付的信息，并通知收银员 4….扩展： 2a.系统与外部系统交互时检测到错误 1.系统通知收银员发生错误 2.收银员要求客户选择其他支付手段

9/20/202328UC12:处理信用卡支付…8/6/202328UC1:FooBars…主成功场景： 1….扩展： a*.任何时候，客户都可以选择编辑个人信息：编辑个人信息 b*.任何时候，客户都可以选择打印帮助：展现打印帮助

2-11.客户取消：取消交易确认

9/20/202329UC1:FooBars…8/6/202329用例模型中的用例包含关系NextGenPOSCashierCustomerHandleCashPaymentProcessRentalProcessSaleHandleCheckPaymentHandleReturns«include»«include»«include»«include»«include»«include»«actor»AccountingSystem«actor»CreditAuthorizationServiceManageUsers...UMLnotation:thebaseusecasepointstotheincludedusecaseHandleCreditPayment9/20/202330用例模型中的用例包含关系NextGenPOSCashier扩展关系扩展当用例文本不好修改时可以通过扩展用例解决再创建扩展或附加用例，并且在其中描述在何处和何种条件下该用例扩展某基础用例的行为9/20/202331扩展关系扩展8/6/202331UC1:处理销售…扩展点： 2a.VIP客户，步骤1。支付，步骤7主成功场景： 1.顾客到某个POS收费口为购买的产品或服务付费。 … 7.顾客付费，系统处理支付

9/20/202332UC1:处理销售…8/6/202332UC1:处理增券支付…触发：客户想使用赠券支付扩展点：处理销售中的支付级别：子功能主成功场景：1.客户将赠券交给收银员2.收银员输入赠券ID…

9/20/202333UC1:处理增券支付…8/6/202333扩展关系ProcessSaleExtensionPoints:PaymentVIPCustomer«extend»Payment,ifCustomerpresentsagiftcertificateUMLnotation:1.Theextendingusecasepointstothebaseusecase.2.Theconditionandextensionpointcanbeshownontheline.HandleGiftCertificatePayment9/20/202334扩展关系ProcessSaleExtensionPoin领域模型的精化目标使用泛化、特化、关联类、时间间隔、组合和包等概念精化领域模型确定在何时表示子类才具有价值9/20/202335领域模型的精化目标8/6/202335领域模型的精化－新概念分类列表分类示例有形对象CreditCard,Check事务CashPayment,CreditPayment,CheckPayment其他外部的计算机或者机电系统CreditAuthorizationService,CheckAuthorizationService抽象名称概念组织结构CheckAuthorizationService,CheckAuthorizationService金融、工作、合同、法律事务等的记录AccountsReceivable9/20/202336领域模型的精化－新概念分类列表分类示例有形对象CreditCUC1:处理销售…扩展： 7b.信用卡支付： 1.客户输入信用卡帐户信息 2.系统向外部的支付授权系统发送支付授权请求，请求支付批准 2a.系统侦测到与外部系统协作失败 1.系统向收银员发送错误信号 2.收银员要求客户使用其他支付手段 3.系统接收到支付批准应答，并通知收银员 3a.系统接收到拒绝支付应答： 1.系统向收银员通知拒绝应答 2.收银员要求客户使用其他支付手段 4.系统记录此次信用卡支付的信息，其中包括支付批准信息 5.系统显示信用卡支付签名输入机制 6.收银员要求客户签名。客户签名。 7c.支票支付 1.客户填写支票，并且同驾驶证一起交给收银员 2.出纳员将驾驶证号码写在支票上，输入这些信息，请求支票支付授权 3.产生一个支票支付请求并且将她发送到外部的支票授权服务系统 4.接收到支票支付批准应答并通知收银员 5.系统记录此次支票支付的信息，包括支付批准信息9/20/202337UC1:处理销售…8/6/202337泛化－特化层次体系CashPaymentCreditPaymentCheckPaymentPaymentsuperclass-moregeneralconceptsubclass-morespecializedconcepttheseareconceptualclasses,notsoftwareclasses泛化（Generaliza）是在多个概念中识别共性和定义超类（普遍概念）与子类（具体概念）关系的活动9/20/202338泛化－特化层次体系CashPaymentCreditPaym使用独立箭头和共享箭头表示法的类层关系CashPaymentCreditPaymentCheckPaymentPaymentCashPaymentCreditPaymentCheckPaymentPayment9/20/202339使用独立箭头和共享箭头表示法的类层关系CashPayment概念超类和子类定义：Payment类的层次结构CashPaymentCreditPaymentCheckPaymentPaymentamount:Money9/20/202340概念超类和子类定义：Payment类的层次结构CashPay集合关系的Venn图PaymentCashPaymentCreditPaymentCheckPayment9/20/202341集合关系的Venn图PaymentCashPaymentCr子类的一致性CashPaymentCreditPaymentCheckPaymentPaymentamount:MoneySalePays-for11100％原则：概念超类的定义必须100％适用于子类。子类必须100％与超类一致，包括属性和关联Is-a规则：子类是一种超类9/20/202342子类的一致性CashPaymentCreditPayment合法的概念类划分，但在我们的领域有用吗MaleCustomerFemaleCustomerCustomerCorrectsubclasses.Butuseful?9/20/202343合法的概念类划分，但在我们的领域有用吗MaleCustome划分概念子类的动机子类有额外的有意义的属性子类有额外的有意义的关联子类概念的操作、处理、反映或使用的方式不同于其超类或其他子类，而这些方法是我们所关注的子类概念表示了一个活动体，其行为与超类或者其他子类不同，而这些行为是我们所关注的9/20/202344划分概念子类的动机子类有额外的有意义的属性8/6/20234子类划分的实例概念子类划分的动机示例子类有额外的有意义的属性Payments－不适用Library－Book具有新的属性ISBN，是LoanabledResource的子类子类有额外的有意义的关联Payments－CreditPayments和CreditCard类关联是Payments类的子类Library－Video类和Director类关联是LoanabledResource的子类子类概念的操作、处理、反应或使用的方式不同于其超类或其他子类，而这些方法是我们所关注的Payments－Payment的子类CreditPayment类的授权处理方式与其他的Payment子类都不相同Library－Software在借出时需要押金，是LoanabledResource的子类子类概念表示了一个活动体，其行为与超类或者其他子类不同，而这些行为是我们所关注的Payments－不适用Library－不适用MarketResearch－MaleHuman与FaleHuman的购物习惯不同是Human的子类9/20/202345子类划分的实例概念子类划分的动机示例子类有额外的有意义的属性何时定义概念超类潜在的概念子类表示的是相似概念的不同变体子类满足100％和Is-a规则所有子类都具有相同的属性，可以将其解析出来并在超类中表达所有子类都具有相同的关联，可以将其解析出来并与超类关联9/20/202346何时定义概念超类潜在的概念子类表示的是相似概念的不同变体8/证明Payment子类的合理性CashPaymentCreditPaymentCheckPaymentPaymentamount:MoneyCheckIdentifies-credit-withPaid-with*eachpaymentsubclassishandleddifferentlyadditionalassociationssuperclassjustifiedbycommonattributesandassociationsSalePays-forCreditCard11119/20/202347证明Payment子类的合理性CashPaymentCred证明AuthorizationService层次结构的合理性CreditAuthorizationServiceCheckAuthorizationServiceCheckPaymentAuthorizationServiceaddressnamephoneNumberadditionalassociationssuperclassjustifiedbycommonattributesandassociationsStoreAuthorizes-payments-of*AuthorizesCreditPaymentAuthorizes***119/20/202348证明AuthorizationService层次结构的合理性外部服务事务的一个可能的类层次结构CreditPaymentApprovalReplyCheckPaymentApprovalReplyCreditPaymentApprovalRequestCheckPaymentApprovalRequestCreditPaymentDenialReplyCheckPaymentDenialReplyCheckPaymentAuthorizationReplyCreditPaymentAuthorizationReplyPaymentAuthorizationReplyPaymentAuthorizationRequestPaymentAuthorizationTransactiondatetimeConceptstoofinegrained?Usefultoshowthisdegreeofpartitioning?Eachtransactionishandleddifferently,soitisusefultopartitionthemintodiscreteclasses.9/20/202349外部服务事务的一个可能的类层次结构CreditPayment事务类层次结构的另一方案CreditPaymentApprovalRequestCheckPaymentApprovalRequestPaymentAuthorizationReplyPaymentAuthorizationRequestPaymentAuthorizationTransactiondatetimeCreditPaymentApprovalReplyCheckPaymentApprovalReplyCreditPaymentDenialReplyCheckPaymentDenialReply9/20/202350事务类层次结构的另一方案CreditPaymentAppro抽象类概念PaymentCashPaymentCreditPaymentCheckPaymentPaymentCashPaymentCreditPaymentCheckPaymentIfaPaymentinstancemayexistwhichisnotaCashPayment,CreditPaymentorCheckPayment,thenPaymentisnotanabstractconceptualclass.Paymentisanabstractconceptualclass.APaymentinstancemustconformtooneofthesubclasses:CashPayment,CreditPaymentorCheckPayment.(a)(b)abstractconceptualclass如果类C的每个成员也必须是某个子类的成员，则C类被成为抽象概念类在领域模型中使用斜体字表示抽象类的名称，或用{abstrator}9/20/202351抽象类概念PaymentCashPaymentCreditP抽象类表示法CashPaymentCreditPaymentCheckPaymentPaymentamount:Moneyabstractclassindicatedbyitalics在领域模型中使用斜体字表示抽象类的名称，或用{abstrator}9/20/202352抽象类表示法CashPaymentCreditPayment对变化的状态建模PaymentnotusefulthesesubclassesarechangingstatesofthesuperclassUnauthorizedPaymentAuthorizedPaymentPaymentStatebetterUnauthorizedStateAuthorizedStatePaymentIs-in1*不要将概念X的状态建模为X的子类定义状态类层次结构，并将其与类X关联在领域模型中忽略概念的状态，而在状态图中加以反映9/20/202353对变化的状态建模Paymentnotusefulthese关联类：属性的不当使用addressmerchantIDnamephoneNumberAuthorizationServiceaddressmerchantIDnameStorebothplacementsofmerchantIDareincorrectbecausetheremaybemorethanonemerchantID在领域模型中，如果C可能同时有多个相同的属性A，则不要将属性A置于C之中，应该将属性A放在另一个类中然后将其与类C关联起来9/20/202354关联类：属性的不当使用addressmerchantIDna对merchantID问题建模的首次使用addressnamephoneNumberAuthorizationServiceaddressnameStoremerchantIDServiceContractPurchases1..**abettermodel,butnotyetasusefulaspossible3SellsAuthorizes-payments-via1..**9/20/202355对merchantID问题建模的首次使用addressnam一个关联类addressnamephoneNumberAuthorizationServiceaddressnameStoremerchantIDServiceContractanassociationclassitsattributesarerelatedtotheassociationitslifetimeisdependentontheassociationAuthorizes-payments-via1..**在领域模型中增加关联类的可能线索有：有某个属性与关联相关关联类的实例具有依赖于关联的生命期两个概念之间有多对多关联，并且存在于关联自身相关的信息9/20/202356一个关联类addressnamephoneNumberAut多个关联类salaryEmploymentEmploysCompanyPerson**dateOfIncarcerationJailTermIncarceratesJailPerson*Married-toPerson0..10..11apersonmayhaveemploymentwithseveralcompanies9/20/202357多个关联类salaryEmploymentEmploysCo聚合关系和组合关系在下列情形下，可以考虑组合关系部分的生命期在组成的生命期限之内，部分的创建和删除依赖于整体在物理或者逻辑组装上，整体－部分关系很明确组成的某些属性会传递给部分对组成的操作可能传递给部分识别和显示组合关系的好处有利于澄清部分对整体依赖的领域约束有助于使用GRASP创建者模式时识别创建者对整体的复制、拷贝这些操作可能传递给部分9/20/202358聚合关系和组合关系在下列情形下，可以考虑组合关系8/6/20POS应用中的聚合SalesLineItemSale1..*ProductDescriptionProductCatalog1..*119/20/202359POS应用中的聚合SalesLineItemSale1..*ProductPrices和时间间隔SaledateTime...SalesLineItemquantityProductDescriptiondescriptionitemID1..*Described-by*1ProductCatalog...ProductPriceactiveInterval:TimeIntervalprice:MoneyTimeIntervalstart:timeStampend:timeStamp1..*11Priced-by?1..**需要区别销售发生时的历史价格和当前价格9/20/202360ProductPrices和时间间隔SaledateTime角色名称FlightCityFlies-to*destinationrolenamedescribestheroleofacityintheFlies-toassociationPerson*parentCreates42child1显示的角色名称并不是必需的－当对象的角色并不清楚时，使用显示的角色名称是有效的9/20/202361角色名称FlightCityFlies-to*destina对人类角色建模的两种方式StorePersonEmploys-to-handle-salescashierEmploys-to-managemanager**Manages4*workermanagerStoreCashierManagerEmploys*Employs*rolesasconceptsManages6*rolesinassociations111119/20/202362对人类角色建模的两种方式StorePersonEmploys导出属性dateTime/total...Salederivedattribute在UML中，在元素名称的前面加”/”来表示导出元素要避免在图中显示导出元素，因为这些导出元素在没有增加新信息的情况下还会增加复杂性9/20/202363导出属性dateTime/total...Salederiv与多重性相关的导出属性SalesLineItem1..*Sale/quantityderivablefromtheactualmultiplicity19/20/202364与多重性相关的导出属性SalesLineItem1..*Sa受限关联ProductCatalogProductDescriptionitemIDContainsProductCatalogProductDescriptionContains1..*multiplicityreducedto1(a)(b)qualifier111在关联中可能会用到限定词（qualifier）；基于限定词的值可以区分位于关联另一端的对象集合。具有限定词的关联是受限关联9/20/202365受限关联ProductCatalogProductDescr自反关联Person*parentCreates42child概念到自身的关联成为自反关联（reflexiveassociation）9/20/202366自反关联Person*parentCreates42chi使用包来组织领域模型：一个UML包DomainCoreElementsSales9/20/202367使用包来组织领域模型：一个UML包DomainCoreEl在包内被引用的类SalesCoreElementsSaleCoreElements::RegisterCapturesStoreRegisterHas1..*1119/20/202368在包内被引用的类SalesCoreElementsSale包的依赖关系DomainCoreElementsSales如果一个包引用了由其他包所拥有的某元素，则存在一个依赖关系9/20/202369包的依赖关系DomainCoreElementsSales如何划分领域模型将领域模型划分为包结构时，将满足下属条件的元素放在一起在同一个主题领域，概念或目标密切相关的元素在同一个类层次结构中的关系参与同一个用例的元素由很强的关联性的元素9/20/202370如何划分领域模型将领域模型划分为包结构时，将满足下属条件的元POS领域概念包DomainCore/MiscPaymentsProductsSalesAuthorizationTransactions9/20/202371POS领域概念包DomainCore/MiscPaymentCore包Core/MiscRegisterManagerStoreaddressnameHouses1..*Employs1..*119/20/202372Core包Core/MiscRegisterManagerSPayment包PaymentsCheckAccountsReceivableCreditPaymentCheckPaymentCheckAuthorizationServiceCreditAuthorizationServiceAuthorized-byAuthorized-by***AuthorizationServiceaddressnamephoneNumberCore::StorePaymentamountEstablishes-credit-for5Logs4*CreditCardexpiryDatenumberDriversLicensenumber1..*Establishes-identity-for5Paid-byCashPaymentamountTendered*Sales::CustomerAbused-by4IdentifiesAuthorizationTransactions::PaymentAuthorizationReply-CheckPaymentshaveCheckPaymentReplies-CreditPaymentshaveCreditPaymentReplies111111111113Authorizes-payments-ofmerchantIDServiceContract19/20/202373Payment包PaymentsCheckAccountsRProducts包Products1..*Core::StoreStocks*Describes*Sales::SalesLineItemDescribed-by*Records-sale-of60..1ProductDescriptiondescriptionpriceitemIDProductCatalogItem111119/20/202374Products包Products1..*Core::StoSale包SalesCashierCustomer1..*SalesLineItem/quantitySaledateisCompletetimeInitiatesCore::RegisterRecords-sales-on5Captured-on4Core::Store3Logs-completed*11111111TaxLineItemdescriptionpercentageamount1..*19/20/202375Sale