OOAD讲义

提纲业务分析&系统分析—OOAD传统的功能分解与OOAD统一建模语言—UMLNtier系统的分析和设计如何建立企业信息系统OOAD沪西委托久隆开发系统沪西久隆信息使用USECASE图使用SEQUENCE图使用CLASS图使用UML表示USECASE叙述沪西同久隆签定合同，要求久隆开发出适合沪西需要的系统，方便企业的管理沪西委托久隆信息开发沪西请求久隆开发系统，久隆把系统交由软件部门负责，总监廖要求杨负责整个项目，杨制订项目计划，要求蒋负责项目的总体规划，分析师A负责业务分析，分析师B辅助A进行业务分析，杨要向廖汇报项目情况。廖兵廖斌蒋照平杨锋雷分析师A分析师B沪西使用SEQUENCE图廖杨蒋开发项目分析师A沪西分析师B请开发项目订项目计划请负责规划请负责业务分析请负责调研请报告情况使用类图廖请开发项目请开发项目请报告情况廖接受开发任务杨开发项目订项目计划请负责规划请负责业务分析请报告情况杨接受开发任务制订项目计划报告项目情况蒋进行项目规划分析师A进行业务分析分析师B进行项目调研廖接受开发任务使用OOP进行编程Publicclass廖{publicvoid接受开发任务（）}蒋接受开发任务制订项目计划报告项目情况Publicclass蒋{publicvoid接受开发任务（）publicvoid制订项目计划（）publicvoid报告项目情况（）}Publicclass蒋{publicvoid进行项目规划（）}Publicclass分析师A{publicvoid进行业务分析（）}Publicclass分析师B{publicvoid进行项目调研（）}向方法里填加内容廖请开发项目请报告情况请开发项目Publicclass廖{杨杨publicvoid接受开发任务（）{杨.接受开发任务（）;杨.报告项目情况（）;}}杨开发项目订项目计划请负责规划请负责业务分析请报告情况Publicclass杨{蒋蒋分析师A分析师Apublicvoid接受开发任务（）{this.制订项目计划（）蒋.进行项目规划（）;分析师A.进行业务分析（）;}}两段式开发以OOAD分析企业的业务流程以OOAD分析企业的系统流程企业信息系统以OOAD分析企业流程从企业流程导出系统流程以OOAD分析系统流程以OOP写组件找出企业流程业务分析找出企业的流程使用OOAD分析企业的流程医院看病病人Businessusecase1、明确我们要设计的范围，根据范围找出那些人或单位跟我们要设计的对象（如企业）打交道2、找出顾客的目标医院挂号看病检查拿药3、根据顾客的目标找出企业的流程病人挂号看病医院病人挂号人员护士医生4、转到企业内部，找出企业里谁来执行这些流程，以及他们之间的关系5、针对一个USECASE，叙述流程。看病护士医生病人挂完号后，到医生诊室门口进行排队，等候看病，护士负责进行分诊工作，当排到该病人看病时，护士通知该病人到某诊室看病，病人到该诊室就诊，医生为该病人进行诊断，诊断完成后告知诊断结果，同时记录诊断结果到病历，在过程中如果需要检查化验，则开检查化验单要求病人进行检查化验病人护士医生请等候要求看病就诊要求检查化验通知就诊诊断记录病历6、制作事件流图，表述该流程。7、继续进行其他USECASE的分析。挂号检查拿药8、企业内的人员通常使用MIS系统进行工作，那我们把焦点转道MIS系统。病人医院MIS护士医生9、确定使用MIS系统的各actor的目标。护士医生MIS分诊诊断挂号检查拿药10、依次分析各个系统流程。分诊诊断以分析诊断流程为例。进行USECASE叙述医生诊断医生把病人的姓名或病历号输入系统，系统查找病人的病历，并调出。医生询问病人症状，并进行检查，如果病人需要检查化验，则通过系统开检查化验申请单，要求病人检查。诊断完毕，医生把诊断结果记入病历，通过系统开处方，请病人去药房拿药。此时系统是一个黑箱，准备打开系统这个黑箱MIS病历处方申请单医生病历申请单请调出病历创建申请单创建处方处方追加病历病历调病历请调出病历追加病历病历调病历追加病历申请单创建申请单处方创建处方传统的功能分解DFDEROOADUSECASESEQUENCECLASS….分析师A：轮到病人就诊时，护士叫病人到诊室并且把病历递给医生，医生对病人进行检查分析师B：轮到病人就诊时，护士叫病人到诊室，并且要求医生给病人看病，把病例递给医生，医生对病人进行检查叙述方式的比较区别从OOAD的观点来说，分析师乙的观点是好的，他的着眼点是事件，分析师甲的着眼点是资料。从分析的观点来看，分析师乙的描述更稳定，因为就诊是稳定的，而资料（病历）是不稳定的，所以分析师乙的描述更易于实现系统的框架，系统的弹性空间大。二者的本质区别传统的功能分解方法，注重数据流OOAD注重事件流，资料只是作为事件的参数进行传递储户出纳递给存折和提款单数据流，没有表达顾客的目的储户出纳请办理提款（存折和提款单）事件流，表达出顾客的目的（银行提供的服务）稳定的业务规则1、用户的目标是稳定的。2、一些领域内的概念是稳定的。3、资料是不稳定的。我们去银行取钱、存钱，那么取钱、存钱针对的是帐户，帐户是稳定的，银行里永远都有的，不会改变。当然架构里还包括各种关系，那么我们要找出稳定的关系，如：取款人要求取款，“要求取款”这个事件是稳定的。领域里稳定的概念基础领域结构领域商业领域应用领域OO的精神ProgramToInterface现实中的例子计算机投影仪插座杯子笔……一个程序importjava.awt.*;classLine{Stringtest=Thisisatest;publicLine(){test=Thisisaline;}publicvoidDraw(){System.out.println(test);}};publicclassPattern_test2{publicLineline;publicPattern_test2(){line=newLine();}publicvoiddraw(){line.Draw();}publicstaticvoidmain(String[]args){Pattern_test2pa_test=newPattern_test2();pa_test.draw();}}问题如果要把Pattern_test2中的Line换做Circle会怎么样？类之间的相依性太高改进importjava.awt.*;abstractclassGraph{abstractpublicvoidDraw();}classLineextendsGraph{Stringtest=Thisisatest;publicLine(){test=Thisisaline;}publicvoidDraw(){System.out.println(test);}};abstractclassFactory{abstractpublicGraphcreate();}classLineFactoryextendsFactory{publicLinecreate(){returnnewLine();}}publicclassPattern_test2{publicGraphgph;publicPattern_test2(Factoryfac){gph=fac.create();}publicvoiddraw(){gph.Draw();}publicstaticvoidmain(String[]args){Pattern_test2pa_test=newPattern_test2(newLineFactory());pa_test.draw();}}Pattern---AbstractFactoryPattern_test2FactoryLineGraphCircleLineFactoryCircleFactory用户的需求适者生存---客户需要变化隐性知识---个人化的我们应该做的虚和实---弹性拥抱改变---运动是常态提升自己---技巧、知识内容UseCaseDiagramsUseCaseDiagramsUseCase图ScenarioDiagramsScenarioDiagrams协作图StateDiagramsStateDiagrams组件图ComponentDiagramsComponentDiagrams配置图StateDiagramsStateDiagrams对象图ScenarioDiagramsScenarioDiagrams状态图UseCaseDiagramsUseCaseDiagrams时序图StateDiagramsStateDiagrams类图活动图模型库USECASE描述使用者的目标叙述流程一般概念：–参与者–用例–关系病人去看病ACTOR与系统交互的人或系统。使用角色描述系统范围外的一切。参与者是主动的实体，它们的行为不是预先定义好的，它们可以被看作系统必须响应的事件来源。如何获取ACTOR谁使用系统功能（主要、辅助使用者）？系统需要与哪些系统交互？系统需要控制哪些硬件USECASE参与者为获得服务与系统的交互序列。使用用例描述系统内的一切。如何获取USECASE使用这个系统干什么？使用者需要系统提供哪些功能？使用者需要读、产生、删除、修改或存储系统中的信息有哪些。使用者是否需要把某些外部事件告知系统系统是否有哪些事件告知使用者。角色与用例之间的关系通信关系使用关系扩展关系角色一般化关系使用关系使用关系通常用于两个或多个用例共同的可复用功能。如果完成用例A所需要的参与者-系统交互可以在用例B中被描述，则用例A使用了用例B。扩展关系允许一个用例扩展另一个用例提供的功能。如果用例A能通过用例B的基本交互增加细节得到，则用例A扩展了用例B。这种扩展可以改变成增加用例功能。使用关系、扩展关系的区别在扩展情况下，执行者与待扩展的用例有联系，人们认为一个给定的执行者将执行基本用例及其所有的扩展。对于使用关系，通常执行者不会和公共用例相关联。当描述一般行为的变化时，采用扩展。当在两个或更多的用例中出现重复描述而又想避免这种重复时，采用使用用例图的注意事项不要建模角色与角色间的通信。不要在两个使用案例之间直接画箭头（除了使用和扩展关系）每个使用案例都应有角色启动。即应当有个从角色指向使用案例的箭头，除了使用和扩展关系。可以把数据库看成整个USECASE框图下面的层。USECASE的步骤1、明确我们要设计的范围，根据范围找出那些人或单位跟我们要设计的对象（如企业）打交道2、找出顾客的目标3、转到企业内部，找出企业里谁来执行这些流程，以及他们之间的关系4、确定我们要设计的对象5、针对要设计对象的各使用者，确定他们的目的。6、针对另一个USECASE进行分析7、导出系统的USECASE图SEQUENCE图对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互SEQUENCE图的符号用户对象一对象二服务请求服务请求返回的服务系统的响应CLASS图对象模型描述了对象、类及它们之间相互关系的静态数据结构•对象•类•属性•操作和方法•链•关联•限定•聚集•一般化与继承•元数据CLASS图的符号类名属性操作和方法对象链关联元数据实例化实例化描述一般化CLASS图的其他概念控制类实体类边界类类实用程序一个示例UserHomefindByPrimaryKeyfindByPrimaryKeyServletAccountUserAccountHomecheckdeposit示例中的问题网络的使用效率低数据库的锁定时间太长重用性低耦合性高封装性差如何解决UserHomefindByPrimaryKeyfindByPrimaryKeyUcoAccountUserAccountHomecheckdepositServletdeposit结论每个USECASE预设一个控制物件—facade模式fac