面向对象分析和设计讲座5.细化阶段

第5讲.细化阶段与领域模型内容提要细化阶段领域模型领域模型概念类关联属性系统顺序图契约9/28/202321.细化阶段1.1概述一般，细化阶段由两到四个迭代构成；每一个迭代持续的时间建议在两到六周之间该阶段的主要任务包括构建核心架构，解决高风险问题，完成绝大部分需求的定义，并估计总的时间和资源9/28/202341.2目标保证架构，需求和计划足够稳定，风险被充分规避确定和解决项目中所有与架构密切相关的风险从与架构密切相关的场景中确定一个基准体系架构产生一个达到产品级质量水准的演化性原型，也可以是一个或更多个探索型\抛弃型原型能够展示基准的体系架构以合理的价格和合适的时间支持系统需求

建立一个支持环境9/28/202351.3核心活动尽快定义和验证体系架构，并确定体系架构基线细化远景为构造阶段建立详细的迭代计划并建立基线细化开发用例并将其部署到开发环境中细化体系架构并选择组件9/28/202361.4定义用一句话表达细化构造核心体系架构，解决高风险，定义绝大部分需求，并估计总体计划和资源关键思想和实践实行短时间定量、风险驱动的迭代及早开始编程对架构的核心和风险部分进行适应性设计，实现和测试尽早，频繁，实际的测试基于来自测试，用户，开发者的反馈进行调整通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代举行一次9/28/202371.5对下一轮迭代进行计划风险技术复杂性其他因素覆盖性在早期迭代中，系统中主要的部分都有所涉及关键性具有高业务价值的功能在每个迭代前将用例和特征进行排序9/28/20238用例&迭代1Ausecaseorfeatureisoftentoocomplextocompleteinoneshortiteration.Therefore,differentpartsorscenariosmustbeallocatedtodifferentiterations.UseCaseProcessSale23...UseCaseProcessSaleUseCaseProcessSaleUseCaseProcessRentalsFeature:Logging9/28/20239案例1:POS应用-迭代1

对于NextGenPOS应用对ProcessSale用例实现其基本的、最关键的场景:enteringitems和receivingacashpayment为了支持迭代中的初始化需求必须实现StartUp用例在该阶段，并不处理那些复杂的和有趣的功能，而只是考虑容易实现的场景，并通过设计和实现来加以支持也不考虑外部服务的协同，比如计税器或者产品数据库不考虑应用复杂的计价规则9/28/202310案例2选课系统项目的目标是将以前的选课系统用新技术加以改造，使得老师和学生可以通过客户端在线访问9/28/202311问题描述问题TheoutdatedandlargelymanualstudentregistrationprocessatWylieCollege影响者Students,professors,andCollegeadministration.造成Aslowandcostlyprocesscombinedwithdissatisfiedstudentsandprofessors.成功的解决方案ImprovetheimageoftheCollege,attractmorestudents,andstreamlineadministrativeregistrationfunctions.9/28/202312产品定位描述ForWylieCollegestudents,professors,andthecourseregistrarWhoAttend,teach,oradministercollegecoursesTheCourseRegistrationSystemIsatoolThatEnablesonlinecourseregistrationandaccesstocourseandgradeinformationUnlikeTheexistingoutdatedmainframeregistrationsystemOurproductProvidesup-to-dateinformationonallcourses,registrations,teachers,andgradestoallusersfromanyPCconnectedviatheCollegeLANorinternet.9/28/2023139/28/202314PhaseNo.ofIterationsStartEndInceptionPhase1Week1Week8ElaborationPhase1Week8Week15ConstructionPhase3Week15Week31TransitionPhase2Week25Week329/28/202315PhaseIterationDescriptionAssociatedMilestonesRisksAddressedInceptionPhasePreliminaryIterationDefinesbusinessmodel,productrequirements,SoftwareDevelopmentPlan,andbusinesscase.BusinessCaseReviewClarifiesuserrequirementsupfront.DevelopsrealisticSoftwareDevelopmentPlansandscope.Determinesfeasibilityofprojectfromabusinesspointofview.9/28/202316E1迭代将对Release1.0中所有用例，Release2.0中的高风险用例进行分析和设计。通过开发架构原型验证Release1.0所需要的架构的可行性和性能Release1.0计划包含的特征:LogonCloseRegistrationRegisterforCoursesInterfacetoCourseCatalogDatabaseInterfacetoFinanceSystemMaintainStudentInformationMaintainProfessorInformation9/28/2023173.领域模型

（第9章）3.1目标依据迭代需求，确定相关的概念类创建初步的领域模型为模型建立适当的属性与关联9/28/2023193.2什么是领域模型领域模型是对真实世界中概念类的表示，而不是软件对象的表示。它不是用来描述软件类、软件架构领域层或有职责软件对象的一组图。领域模型用一套类图来表示，这些类没有操作。它可以显示：领域对象或者概念类概念类之间的关联概念类的属性9/28/202320可视化字典9/28/2023219/28/202322避免瀑布思维倾向，为完成详尽或“正确”的领域模型而进行大量建模工作。这些方式都应避免，并且这种过量的建模工作反而会导致分析停滞，这种调查几乎不会有什么回报。9/28/2023233.3为什么需要领域模型它是一种可视化语言，传达了真实世界中的概念或者该领域中的概念类9/28/2023243.4概念类概念类可以由符号，内涵和它的外延来表示符号-代表概念类的词或者图像内涵-概念类的定义外延-概念类应用的例子集合9/28/202325Saledatetime概念符号“sale表示购买交易的事件，具有日期和时间”概念内涵sale-1sale-3sale-2sale-4概念外延9/28/202326领域模型和分解分而治之-处理复杂性的手段面向对象方法与结构化分析方法的核心区别在于：是由概念类（对象）分解的而不是功能分解的9/28/202327销售领域的概念类StoreRegisterSale9/28/202328识别概念类在我们所关心的领域，我们的目标是针对感兴趣或者有意义的概念类建立领域模型只针对目前正在设计的场景指南:对领域模型而言，建立较多的细粒度的概念类要比粗略的建模来得好可以有没有属性的概念类或者仅仅担任行为角色的概念类9/28/202329识别概念类的策略重用和修改现有模型采用概念类类别列表确定名词9/28/202330采用概念类类别列表某些公共类别例如物理的或者实际的对象地点组织…SeePP.104概念类种类例子Recordsoffinance,work,contracts,legalmattersReceipt,Ledger(分类帐),ExploymentContract,MaintenaceLogFinancialinstrumentsandservicesLineOfCreditStockManuals,documents,referencepapers,booksDailyPriceChangeList,RepairManual9/28/202331通过名词识别找到概念类为了找到问题域中的公共词汇，可以考虑从需求文档中以及开发团队成员的知识中来找词汇。注意力要放在下列方面:业务对象真实世界中的对象事件9/28/202332在一个存货管理的系统中，我们将关注库存中的物品以及它们的存储位置在该系统中一个事件就是将货品放到仓库中。对于每一次运货，系统必须记住搬运的时间，谁接收了货品，什么货品，每一种的数量有多少9/28/202333对销售领域的备选概念类对于ProcessSale的简化情形RegisterProductSpecificationItemSalesLineItemStoreCashierSaleCustomerPaymentManagerProductCatalog9/28/202334报表对象—是否相关?收据是一次销售的报告。但是它显示的信息实际上已经存在了，这是我们可以排除它的理由。但是收据又有特殊的作用，在我们退货时，我们需要收据作为凭据因此，是否需要将依据你考虑的是哪一个用例来定9/28/2023353.5领域建模指南采用概念类目录列表和从需求中采用名词识别法将所有的备选概念类列出在那些需要将关系信息保存的地方添加关联依据信息需求添加必要的属性9/28/202336地图制作策略采用实际地名将无关的特征去掉不要添加不存在的东西9/28/202337属性还是概念类?一个通常会犯的错误如果我们不是将概念类X仅仅看作是实际生活中的数字或者文字，X就可能是概念类，而不是属性如果有疑问，可以将它列为概念类9/28/202338类似的概念类在我们的生活中经常用相近的概念来表示同一件事情选哪一个?9/28/202339POST从某种角度上看，是一个面向实现的概念，所以它不合适，但是它有助于我们之间的交流Register是各种终端的抽象，无论是POST还是人手工.所以它的选择依据于….你的选择9/28/202340非现实世界的建模许多事物是人工的，也就是说，它们是被造出来的为了对它们建模，我们需要更多的抽象例如电信:Message,Connection,Port,Dialog,Route,Protocol中间件:Service,Transaction9/28/202341说明性或者描述性概念类为什么?真实的世界软件世界例子在一个商店中,每一个商品都有价格,描述和其他属性如果我们为每一个商品创建一个包含所有信息的对象不必要的冗余删除商品对象意味着丢失所有信息9/28/202342创建单独的说明性或者描述性类9/28/202343描述性概念类建模指南无论目前是否存在实际的商品或者服务实例，总是存在商品或者服务的描述如果把信息和删除的东西不正确的关联起来，删除这些东西后就会丢失这些信息通过描述性概念类减少了冗余信息或者复制的信息9/28/202344描述性类可以加在商品产品服务…9/28/202345取消某个航班并不丢失航班信息9/28/2023463.6UML&领域模型UML是用来表示各种基本图的语言.UML可以用于核心或者概念视图描述视图实现视图9/28/2023479/28/202348与类相关的术语概念类软件类设计类实现类类9/28/202349降低表示鸿沟PaymentamountSaledatetimePays-forPaymentamount:MoneygetBalance():MoneySaledate:DatestartTime:TimegetTotal():Money...Pays-forUPDomainModelStakeholder'sviewofthenoteworthyconceptsinthedomain.UPDesignModelTheobject-orienteddeveloperhastakeninspirationfromtherealworlddomainincreatingsoftwareclasses.Therefore,therepresentationalgapbetweenhowstakeholdersconceivethedomain,anditsrepresentationinsoftware,hasbeenlowered.1111inspiresobjectsandnamesin9/28/202350例子NextGenPOS初步的领域模型9/28/2023513.7领域模型&UP初始化阶段一般不建议构造领域模型领域模型主要是在细化阶段的迭代中构建的，此时我们需要理解重要的概念，并把某些在设计中映射为软件类9/28/202352业务对象模型vs.领域类业务对象模型-描述整个业务的企业模型，用以支持业务过程重组或者再工程领域模型只是业务对象模型的一个子集9/28/2023539/28/2023543.8连接:增加关联3.8.1目标在领域模型中识别关联区别那些必须知道的关联和仅仅为了理解的关联9/28/2023563.8.2什么是关联?关联时类型（更精确地说，是这些类的实例）之间的关系，表示有意义和值得关注的连接9/28/2023573.8.3何时表示关联世界万物都是相关的如果我们有n个类，将会有n(n-1)个关联我们只添加那些:如果存在需要保持一段时间的关系，将这种语义表示为关联（“需要记住”的关联）可以从常见关联列表中派生的关联9/28/2023583.8.4UML表示法SaleRegisterRecords-current411associationnamemultiplicity-阅读方向箭头-没有其他含义，只是表示阅读关联标记的方向-通常省略9/28/202359关联的方向关联可以是单向的，也可以是双向的给定一个订单，我们可以找到与该订单相关的客户，相反如果给定一个客户，不能够找到订单OrderCustomer*19/28/202360角色关联的每一端称为一个角色对象类对象类限定符关联对象类多重性角色名：类限定符角色名：类多重性关联名nameMultiplicityexpressionnavigability9/28/202361多重性多重性Multiplicity定义了类A有多少实例可以和类B的一个实例关联9/28/202362zeroormore;"many"oneormoreoneto40exactly5TTTT*1..*1..405T3,5,8exactly3,5,or89/28/202363多重性的指标是在特定的时刻（而不是在某个时间跨度内）有效关联的实例数量。如何定义多重性的值?ItemStoreStocks41or0..1*9/28/202364命名关联9/28/2023653.8.5常见关联表常见关联表PhysicalpartofLogicalpartofMemberof……高优先级的关联AisaphysicalorlogicalpartofBAisphysicallyorlogicallycontainedin/onBAisrecordedinB9/28/2023663.8.6关联指南关注那些需要保持一段时间的关联发现概念类比发现关联更重要太多的关联将会使领域模型变得混乱，而找出这些关联需要消耗太多时间，效益却不大避免显示冗余的或者可派生的关联9/28/202367关联需要多详细?确定概念类比找到关联更重要.

领域模型构建时，主要的时间要花在确定概念类上，而不是找关联上9/28/202368关联和实现在领域建模时，关联只是针对现实领域从纯概念角度看有意义的关系并不需要实现Or我们后面可以发现在领域建模时丢失，而需要实现的关联9/28/202369NextGenPOS领域模型中的关联在商店中需要记住的关系RegisterRecordsSaleSalePaid-byPaymentProductCatalogRecordsProductSpecification运用关联类别检查表AisaphysicalpartofB:Register-CashDrawerAisalogicalpartofB:SalesLineItem-Sale……9/28/202370POS的部分模型Emphasizeneed-to-knowassociations,butaddchoicecomprehension-onlyassociationstoenrichcriticalunderstandingofthedomain.9/28/2023713.9领域建模:添加属性3