信息系统分析课件

《信息系统分析课件》由会员分享，可在线阅读，更多相关《信息系统分析课件（193页珍藏版）》请在装配图网上搜索。

1、第六讲 信息系统分析Welcome to Information Resource Management and Development Lecture 6信息系统分析课件2案例：软件工程师毫无用处？ “软件工程师毫无用处，我宁愿雇佣雷达专家教会他如软件工程师毫无用处，我宁愿雇佣雷达专家教会他如何编程，也不愿意雇佣程序员来教会他雷达信号流程何编程，也不愿意雇佣程序员来教会他雷达信号流程”。这段措辞严厉的声明来自于一位大型政府项目的经理，他这段措辞严厉的声明来自于一位大型政府项目的经理，他所在的部门的电脑系统曾经错误地发出了所在的部门的电脑系统曾经错误地发出了ICBM导弹来袭的导弹来袭的警报。更

2、加令他不能忍受的是程序员拒绝对此错误的功能警报。更加令他不能忍受的是程序员拒绝对此错误的功能承担责任。承担责任。 程序员抱怨说这是由于系统说明不够全面造成的，而程序员抱怨说这是由于系统说明不够全面造成的，而并非自己的原因。这位经理意识到，需求文档没有指出特并非自己的原因。这位经理意识到，需求文档没有指出特定的环境回导致错误的警报，但他仍认为他所在部门的编定的环境回导致错误的警报，但他仍认为他所在部门的编程人员应该具备这样的基本知识的。程人员应该具备这样的基本知识的。“没有任何雷达专家没有任何雷达专家会犯如此基本的错误会犯如此基本的错误”，他坚持说。，他坚持说。3课堂讨论：课堂讨论：n如何理解项

3、目经理的抱怨？如何理解项目经理的抱怨？1.在一个项目需求调研过程中，系统分析人员发现在一个项目需求调研过程中，系统分析人员发现对用户进行简单的培训，他们做出的系统分析说对用户进行简单的培训，他们做出的系统分析说明要比系统分析人员更加准确，你觉得这样的现明要比系统分析人员更加准确，你觉得这样的现象正常吗？象正常吗？问题：我们如何发现并描述问题？信息系统分析课件5信息系统分析(内容)n第一节 系统分析的任务n第二节 面向对象分析方法第一节 系统分析的任务信息系统分析课件7什么是系统分析n 系统开发成功的关键是进行全面的系统分析与设计，以便理解商业组织需要从信息系统中获取什么。n系统分析是指理解并详

4、细的说明理解并详细的说明信息系统应该应该做什么做什么的过程。8什么是系统分析员n系统分析员是使用信息技术的商业专业人员商业专业人员，利用分析与设计技术解决业务问题。n分析员必须具有专业技能和程序设计方面的开发专长，也必须有十足的好奇心去探索事情是怎样完成的。n系统分析员经常被看作是问题的解决者 ，而不是程序员。9分析员要解决的典型问题n客户要昼夜随时订购产品，那么在不增加销售成本的前提下如何不间断的处理这些订单呢？n生产计划需要十分仔细的确定每周生产的每种产品的数量，那么如何估计影响生产的众多参数，然后可以让计划员在提交一个特定计划之前研究不同的方案呢？n通过跟踪购买模式和客户购买倾向，市场部

5、需要较好的预见客户需求。那么，如何收集和分析市场部门可用的一些关于客户行为的信息呢？n管理人员要不断地了解公司目前的财务状况，包括盈亏帐目、现金流转和股票市场预测，那么如何收集、分析和提交管理人员所需要的全部金融信息呢？10分析员解决问题的大致流程研究、理解问题核实解决问题的效益/成本确定解决问题的需求制定可能的解决方案（提供可选方案）监控结果是否达到预期结果实施解决方案决定哪个方案是最佳的，并进行推荐详细说明所选方案的细节11系统分析可能的困难n问题空间的理解问题空间的理解n系统分析员缺乏足够的对象系统的业务知识，在系统调查中无从下手n用户虽然精通业务知识，但是不善于把业务知识明确表达出来（

6、或者凭直观）n系统分析员与用户之间的交流的困难系统分析员与用户之间的交流的困难n系统分析员与用户的知识构成不同，经历不同，使得双方的交流十分困难n环境的变化环境的变化n在系统分析阶段，要完全确定系统模式是困难的。12分析员所需的技能n技术知识与技能n业务知识与技能n人的知识与技能n诚实与道德第二节 面向对象分析方法信息系统分析课件142.1 面向对象方法的基本概念n对象、类、属性和操作n封装、隐藏n消息n继承n多态n关系15面向对象的基本思想n从面向对象的角度来看，世界就是由对象组成的。n任何给定的商业功能都是由一整套共同工作的对象互相协作来完成的。n程序由一组实例对象互相通信完成特定功能。1

7、6面向对象分析与设计n对于结构化分析与设计和面向对象的分析与设计来说，信息系统开发的生命周期是相同的，都要经过规划、分析、设计和实施，所不同的是建立的模型和采用的建模技术。n结构化分析与设计注重对过程进行建模，面向对象的分析与设计则强调对事物和它们的交互建模。nUML是OO方法的标准建模语言172.2 UML概述n什么是UMLnUML可以做什么nUML包含哪些内容nUML工具软件181、UML是什么n统一建模语言 Unified Modeling LanguagenUML是一个通用的可视化建模语言Unified Modeling LanguageUnified Modeling Languag

8、e（统一建模语言）是对（统一建模语言）是对象管理组织象管理组织（OMGOMG）制定的一个制定的一个通用通用的、的、可视化可视化的的建建模语言模语言标准，可以用来标准，可以用来可视化可视化（visualizevisualize） 、描述描述（specifyspecify）、）、构造构造（constructconstruct）和）和文档化文档化（documentdocument）软件密集型系统的各种工件）软件密集型系统的各种工件（artifactsartifacts，又译制品），又译制品） 19UML的历史Booch methodOMTUnified Method 0.8OOSEOther met

9、hodsUML 0.9UML 1.01989-19941989-1994期间，期间，OOOO方法从不足方法从不足1010种增加到种增加到5050多种多种UML 1.1OOPSLA 95Web - June 96 UML partnerspublicfeedback 2004Final submission to OMG, Nov 97First submission to OMG, Jan 97OMG Acceptance, Nov 1997 Fall 1998UML 1.3UML2.0UML2.020UML的创始人nUML是由世界著名的面向对象技术专家G. Booch、J. Rumbaugh

10、 和 I. Jacobson发起，在Booch方法、OMT方法和OOSE方法的基础上，广泛征求意见，集众家之长，几经修改而完成的。nThree amigosBooch Rumbaugh Jacobson21UML的特点n统一了面向对象方法的表示n表示能力强大，可用于各种软件系统建模，以及其它系统建模，如商业系统n与开发过程无关n允许扩展n本身不设计特点语言的语法及规则，但可对应到各种OOP语言框架22UML和OOA、OODnUML既不是方法论，也不是一种开发过程，而是面向对象系统分析与设计的建模语言，是一种语言工具。n如同英语充当国际交流的工具一样nOOA&OOD是方法论，该方法论的实践过程中

11、需要使用UML的图符，使用时还必须遵循一定的原则及步骤。232、UML结构UML Structure构造块构造块building blocks公共机制公共机制common mechanisms构架构架architecture基本基本UML建模元素、关系和图建模元素、关系和图达到特定目标的公共达到特定目标的公共UML方法方法系统架构的系统架构的UML视图视图24构造块构造块构造块building blocks物件物件things关系关系relationships图图diagrams建模元素本身建模元素本身把物件联系在一起，关系说明两个或多个物件时如何语义相关的把物件联系在一起，关系说明两个或多个

12、物件时如何语义相关的UML模型的视图，它们展现物件的集合，模型的视图，它们展现物件的集合，“讲述关于软件系统的故事讲述关于软件系统的故事”，是，是我们可视化系统将做什么（分析级图）或者系统如何做（设计级图）的方法我们可视化系统将做什么（分析级图）或者系统如何做（设计级图）的方法25物件物件物件things结构物件结构物件行为物件行为物件分组物件分组物件注解物件注解物件UML模型中的名词，如类、接口、协作、用例、活动类、构件、节点模型中的名词，如类、接口、协作、用例、活动类、构件、节点UML模型的动词，如交互、状态机模型的动词，如交互、状态机包，它用于把语义上相关的建模元素分组为内聚的单元包，它

13、用于把语义上相关的建模元素分组为内聚的单元注解，它附加到模型以捕获特殊信息，同黄色便笺很相像注解，它附加到模型以捕获特殊信息，同黄色便笺很相像26关系关系关系relationships关联关联association依赖依赖dependency泛化泛化generalization实现实现realization描述对象之间的一组链接描述对象之间的一组链接对象的改变引起依赖对象的语义改变对象的改变引起依赖对象的语义改变一类元素是另一类元素的特化，泛化是相反一般的元素一类元素是另一类元素的特化，泛化是相反一般的元素类元之间的关系，一个类元说明一份契约，另一个类元保证实现该契约类元之间的关系，一个类元说

14、明一份契约，另一个类元保证实现该契约27图图图diagrams类图类图class diagrams对象图对象图object diagrams构件图构件图component diagrams部署图部署图deployment diagrams用例图用例图use case diagrams顺序图顺序图sequence diagrams协作图协作图collaboration diagrams状态图状态图statechart diagrams活动图活动图activity diagrams静态模型静态模型(系统结构系统结构)动态模型动态模型(系统行为系统行为)28公共机制公共机制公共机制common me

15、chanisms规格说明规格说明specifications修饰修饰adornments公共分类公共分类common divisions扩展机制扩展机制extensibility mechanisms29规格说明nUML模型至少具有两种维度：n图形维度：允许使用图和图标可视化模型n文本维度：由各种建模元素的规格说明所组成n规格说明n模型元素的特征和语义的文本描述模型的“肉”n形成了承载模型的语义背板（semantic backplane），赋予模型意义，各种图仅仅是该背板的视图或者可视化投影ndeath by diagram由于图形而死亡30修饰n修饰：图中建模元素上暴露的信息项以表现某个要点

16、n任何UML图仅是模型的视图，因此，只有在修饰增强了图的整体清晰性和可读性或者突出模型的某些重要特征时，你才应该表示那些修饰WindowWindow+size:Area#visibility:Boolean-xptr:XWindow+create:void+hide:void-attachXWindow:voidWindow31公共分类n公共分类描述认识世界的特殊方法n类元（Classifier）和实例n类元：一类事物的抽象概念；如bank accountn参与者、类、类元角色、构件、数据类型、接口、节点、信号、子系统、用例n实例：一类事物的特定实例；如my bank accountn接口（i

17、nterface）和实现n接口：说明事物行为的契约（做什么）n实现：事物是如何工作的特殊细节（如何做）32扩展机制n约束：允许对模型元素添加新的规则n构造型（stereotypes）：基于已有的建模元素引入新的建模元素n标记值：允许为模型元素添加新的特性，是带有相关值的关键字33架构n架构（Architecture）nThe organizational structure of a system, including its decomposition into parts, their connectivity, interaction mechanisms, and the guidin

18、g principles that inform the design of a systemn构架是一个系统的组织结构，包括系统分解成的各个部分、它们的连接性、交互机制和通知系统设计的向导规则nIEEE：在其环境中系统的高级概念344+1视图-1End-user FunctionalityProgrammers Software management PerformanceScalabilityThroughput System integratorsSystem topology Delivery, installationcommunicationSystem engineeringAn

19、alysts/DesignersStructure 354+1视图-2nUse Case ViewnEnd-user: Functionalityn这些视图由用例视图所统一，它描述项目干系人（stakeholder）的需求；所有其他视图都是从用例视图派生而来，该视图把系统的基本需求捕获为用例并提供构造其他视图的基础nLogical View nAnalysts/Designers: Structuren系统功能和词汇；描述问题域的词汇，作为类和对象的集合。重点是展示对象和类是如何组成系统、实现所需系统行为的364+1视图-3nProcess View nSystem integrators:

20、Performance, Scalability, Throughputn系统性能、可伸缩性和吞吐量；建模在我们系统中的可执行线程和进程作为活动类。其实，它是逻辑视图面向进程的变体，包含所有相同的制品nImplementation ViewnProgrammers: Software Managementn系统组装和配置管理；对组成基于系统的物理代码的文件和构件进行建模。它同样展示出构件之间的依赖，展示一组构件的配置管理以定义系统的版本nDeployment View nSystem engineering: System Topology, Delivery, Installation, C

21、ommunicationn系统的拓扑结构、分布、移交和安装；建模把构件物理地部署到一组物理的、可计算节点上，如计算机和外设上。37总结：UML1.X结构UMLUML构造块构造块公共机制公共机制架构架构物件物件关系关系图图规格说明规格说明修饰修饰公共分类公共分类扩展机制扩展机制用例视图用例视图逻辑视图逻辑视图进程视图进程视图实现视图实现视图部署视图部署视图结构物件结构物件行为物件行为物件分组物件分组物件注解物件注解物件关联关联依赖依赖泛化泛化实现实现类图类图顺序图顺序图对象图对象图协作图协作图构件图构件图状态图状态图部署图部署图活动图活动图用例图用例图383、UML中的图对整个系统而言：n功能由

22、用例图描述。n静态结构由类图和对象图描述。n动态行为由状态图、顺序图、协作图和活动图描述。n物理架构则是由构件图和部署图描述。39用例图Use Case Diagramn用例图定义了系统的功能需求，它完全是从系统的外部观看系统功能，并不描述系统内部对功能的具体实现。是从外部执行者的角度来描述系统提供的功能。购买货品购买货品归还货品归还货品出租货品出租货品报废货品报废货品店员店员40类图Class Diagramn类图描述系统的静态结构，表示系统中的类以及类与类之间的关系。41对象图Object Diagramn对象图描述了一组对象以及它们之间的关系，表示类的对象实例。对象图是对类图一种实例化。

23、是系统某个时期可能存在的具体对象实例。aLoan2：借书记录借书记录借书日期借书日期=2006-04-16应还日期应还日期=2006-06-16还书日期还书日期=2006-06-10aItem3：图书图书序号序号=003状态状态=租出租出aReader：读者读者编号编号=042440101姓名姓名=张三张三aLoan1：借书记录借书记录借书日期借书日期=2006-04-16应还日期应还日期=2006-06-16还书日期还书日期=2006-05-8aItem2：图书图书序号序号=001状态状态=在库在库aItem1：图书图书流水号流水号=001状态状态=租出租出aTitle：图书品种：图书品种索

24、书号索书号=TP21108馆藏数量馆藏数量=3可借数量可借数量=242状态图StateChart Diagramn状态图表示一个状态机，强调对象行为的事件顺序。是对类的补充，展示此类对象可能的状态和发生某些事件时其状态的转移情况。在馆内在馆内状态=在馆借出归还淘汰图书购买图书正常正常状态=借出超过期限借出借出超期超期通知读者43活动图Activity Diagramn活动图反映系统中从一个活动到另一个活动的流程，强调对象间的控制流程。核对借书记录核对借书记录检查借出图书损坏情况检查借出图书损坏情况严重损坏严重损坏删除该图书删除该图书修改图书状态修改图书状态是是否否记录借书记录记录借书记录的还书

25、日期的还书日期44顺序图Sequence Diagram &协作图Collaboration Diagramn顺序图和协作图均表示一组对象之间的动态协作关系，其中顺序图反映对象之间发送消息的时间顺序，协作图反映收发消息的对象的结构组织。顺序图和协作图是同构的，即两者之间可以相互转换。45构件图Component Diagramn构件图描述程序代码的组织结构。构件以及它们之间的依赖关系，表示系统的静态实现视图。CourseCourseOfferingStudentProfessorCourse.dllPeople.dllCourseUserRegister.exeBilling.exeBilli

26、ngSystem46UML2.0中的构件图47部署图Deployment Diagramn部署图反映了系统中软件和硬件的物理架构，表示系统运行时的处理节点以及节点中构件的配置。瘦客瘦客户端户端Web服务器服务器(HP6000)应用应用服务器服务器(HP6000)数据库数据库服务器服务器(IBM7100)HTTPTCP/IPTCP/IP管理员管理员客户端客户端TCP/IP48UML2.0新增图n包图正式化n协作图（ Collaboration Diagram ）改名为通信图（Communication Diagram）n交互概览图（Interaction Overview Diagram）n复合

27、结构图（Composite Structure Diagram）n定时图/计时图（Timing Diagram）494、UML举例（HelloWorld）n在Web浏览器中，打印“Hello, World”的 Java applet程序：import java.awt.Graphics;class HelloWorld extends java.applet.Applet public void paint (Graphics g) g.drawString(“Hello, World”, 10,10); 50UML举例n在UML中，对这个applet的建模类图n类HelloWorld 用一个

28、矩形表示。n类HelloWorld 中给出了paint操作，在一个附属的note中说明了该操作的实现。51UML举例n前一个类图反映出“Hello World”这个applet基本部分，并没考虑别的事物。n按照代码，这个applet还涉及另外两个类，即Applet类 和Graphics类。依赖泛化52UML举例n如果考虑类库及Applet上的继承关系，可以得到另一个类图。53UML举例n为了管理大规模的类层次图，可以用包来组织类，如下图所示：54UML举例nHelloWorld的一个顺序图55UML举例n“HelloWorld”是一个applet，不能单独运行，通常是嵌入在Web页中。下面是H

29、elloWorld的构件图：565、UML建模工具nRational Rose 98、20002003（UML1.3）nRational Software Architect（UML2.0）nMicrosoft VisionPowerDesignernTogethern其它软件产品572.3 面向对象方法的优势面向对象方法有如下优势：n与人类思维方式一致n各阶段过渡平滑n可维护性高、易于重用n生命力强581、更接近人类思维方式n人认识世界从对象开始VVVVVVVVVVVV 转换鸿沟转换鸿沟现实世界现实世界逻辑模型逻辑模型数据模型？数据模型？功能模型？功能模型？59n顺应人类思维习惯，让软件开发

30、人员在解空间中直接模拟问题空间中的对象及其行为结构化方法：结构化方法：FindaReader(aReader);FindaBook(aBook );If (Validate(aReader) Lend(aReader, aBook); SaveaLoan();Else PrintErrorMsg(0);在计算机中模拟现实世界的事和物，使它们具有生命，主在计算机中模拟现实世界的事和物，使它们具有生命，主动完成操作动完成操作面向对象方法：面向对象方法：aReader.Find();aBook.Find();If(aReader.Validate() aBook.Lend(); aLoan.Inse

31、rt();Else aError.Show();计算机世界可以模拟现实世界602、生命周期各阶段过渡平滑n分析、设计、实施各阶段使用统一的模型VVVVVVVVVVVV模型转换鸿沟模型转换鸿沟数据流图数据流图模块结构图模块结构图设计模型设计模型分析模型分析模型61自始至终的对象模型n分析得到的是对象模型；n设计是在该对象模型的基础上不断精化完善，形成完整的类模型；n编程使用面向对象语言将设计出的类进行实现。n生命周期的这三个阶段之间的过渡是无缝的，减少了可能出现的偏差623、维护更加容易n面向对象的程序封装性、可读性更好Begin “Caller” Program Init x,y,z. Ope

32、n () Read. Compute. DO “Callee” with x,y,z Update () Close () End Main Program Procedure Callee Parameters x,y,z Compute. End ProcedureEnd Program谁写的？谁写的？为什么这样写为什么这样写？63n虽然结构化设计的模块图可以让我们掌握一个系统的总体结构，但众多的模块（包括函数）缺乏一个合理的组织，难以记忆和使用。n比如要操作一个字符串，需要使用strlen, substr, replace等字符串函数，类似函数很多，常常不知道该用哪一个，现在用一个Str

33、ing类来表示字符串对象，有效组织相关函数，这样的类比函数更易用。n对象是一个包含数据和操作的独立的整体，比模块的封装性更好，具有更高的重用性。对象是更好的抽象和封装644、更有生命力n对象是系统中相对最稳定的元素VVVVVVVVVVVV变化的世界变化的世界功能模型功能模型对象模型对象模型对象对象功能功能数据数据65稳定的对象模型n易变的是业务逻辑，最稳定的是业务中的对象。n比如医疗保险系统中，诸如账户、参保人、医院、病案、处方等实体对象往往是最持久的内容，基本上维持数年都不会轻易改变或消失。而具体的业务规则和操作流程却永远是不可预知的。n如果使用结构化方法，则某个改变更有可能涉及到多个模块，

34、从而打乱最初的设计。而面向对象方法更多的可能情况是修改某个类而已，不影响或少量影响其它类。66OOAD的步骤n建立用例模型，需求分析阶段n建立领域模型（寻找领域类及其关系），系统分析阶段n设计分层体系架构，设计阶段n分层设计静态模型（类图），设计阶段n设计动态模型（用例实现的交互图），设计阶段本章介绍1和2672.4 用例模型n什么是用例n用例的概念、目的n识别参与者n识别用例n绘制用例图n如何描述用例n用例分解，确定用例关系682.4.1 用例的概念n用例创始人雅各布森Ivar Jacobson认为：n用例（use case）是对于一组动作序列的描述，系统执行这些动作会对特定的参与者（act

35、or）产生可观测的、有价值的结果。n阿里斯代尔科克伯恩Alistair Cockburn：n强调用例是各种系统受益人（stakeholder）之间的一种行为契约（contract）。行为包括对象的活动、动作和对象之间的交互等。建立契约的目的是为了达成某种目标，因此每一个用例实际上都应代表一个用户目标，根据三个目标层次（概要层、用户目标层、子功能层）将用例进行分层，从而有效把握用例的粒度。69用例的意义n用例是对系统需求（主要是功能需求）的规范化的描述。n用例图及用例的事件流描述集中体现了系统责任n可以通过用例建立交互图。交互图就是用例的具体实现，即系统中的对象以及对象间协作是如何完成一个用例的

36、全部过程。nRUP是用例驱动的开发过程，从用例模型到分析模型和设计模型之间有一致性和可追踪性。 70用例建模的内容基于用例的需求获取过程：基于用例的需求获取过程：n1. 1. 获取原始需求获取原始需求n2. 2. 开发一个可以理解的需求开发一个可以理解的需求n识别参与者识别参与者n识别用例识别用例n构建用例图构建用例图n3 3 详细、完整地描述需求详细、完整地描述需求n书写用例规格说明书写用例规格说明n4 4 重构用例模型重构用例模型n识别用例间的关系识别用例间的关系n对用例进行组织和分包对用例进行组织和分包711、识别参与者参与者是系统之外与系统进行交互的任何事物任何事物。n使用系统的个人n

37、谁负责提供、使用或删除信息？n谁将使用某项功能？n系统所连接的外部硬件。n例如，控制建筑物中温度的通风系统不断地从传感器获取温度信息，传感器就是一个参与者。n与该系统进行通信的其他信息系统。1.例如为自动柜员机系统建模时，中央银行系统就是它的一个参与者。信用卡系统是销售系统中的一个参与者72区分参与者和外部实体n只有在执行系统功能时与信息系统进行实时交互的人员或其它系统才能被当作参与者n外部实体是指数据的来源和去向，提供数据的人员不一定会执行系统功能n新生入学手工填写个人信息，然后由教务人员统一将数据登记到学籍系统中，教务人员是参与者，学生只是外部实体。n如果学生直接通过Web方式提交个人信息

38、，则认为学生是参与者。 73区分主要参与者和次要参与者n主要参与者（primary actor）是从系统中直接获得可度量价值的用户。n次要参与者（secondary actor）的需求驱动了用例所表示的行为或功能，在用例中起辅助支持作用n用例分析的重点是要找到主要参与者。n比如，在图书馆的借/还书用例中，首先要考虑谁直接使用这一功能，谁频繁地和系统进行交互？图书管理人员是直接操作者，他们的需求和变化对于用例的影响最大。因此，图书管理员是主要参与者。 74事件事件触发触发源源操作操作输出输出目标目标读者检查库存书目书目查询请求读者提供书目供检索书籍列表 读者读者借书借书单读者登记借书记录书借书记

39、录读者通过事件表获得参与者：通过事件表获得参与者：参与者可以从参与者可以从“源源”得到启发，但得到启发，但“源源” 表示数据最初的提供表示数据最初的提供者，不一定对应功能的执行者。者，不一定对应功能的执行者。参与者举例75参与者的表示n在UML中，参与者使用小人符号：图书馆图书馆系统系统读者读者图书管理员图书管理员RSARSA中的中的建模符号建模符号76参与者的泛化n在某些情况下，参与者的角色可以有共性，或者说一般性，一种角色可以拥有另一种角色的全部行为。n比如在超市系统中，值班经理完全可以充当收银员这一角色，此外，值班经理还可以有退货、更改事务等权利。 772、识别用例n用例就是功能性需求功

40、能性需求。 n每个用例至少和一个参与者相关，用例名称要体现参与者希望系统提供的功能。78用例的UML图形表示购买商品Rose中的符号中的符号购买商品79区分用例和用例完成的步骤n不能混淆用例和用例所包含的步骤。n比如“借出图书”功能要经过验证读者信息、检查超出可借数量、保存借书记录、修改图书状态等步骤n在系统中这些步骤通常不作为单独的功能提供给参与者使用，它们只是一个用例所包含的事件流，或者是用例的子功能。n与结构化分析中提到的事件概念相同。80区分业务用例和系统用例n当针对整个业务领域建模时，需要使用业务用例n比如图书馆系统都有一项重要工作就是“整理书架”，图书都要放回到固定的位置上n信息系

41、统作为整个业务系统的一部分，只负责实现系统的部分功能，即有信息处理的那部分功能。 81n客户提出申请要求贷款，申请中包括期限、金额、用途和本人基本情况。银行收到申请后，置于“申请档案”中，以申请号标识。n某公司内部工作岗位的提供：不论何时，只要一有职位空缺，该地区的人力资源部领导就会通知该地区的所有员工并给其它地区的HR领导发送消息，邀请员工们提出申请。然后，其他地区HR领导将招聘信息贴在公告板上。所有对此感兴趣的员工都可以将申请发送到职位空缺的地区的HR领导那里。用例举例182用例举例2n在门诊挂号处只能挂当天的号，挂出的号可以退。n病人拿到挂号单后，到相应的科室进行就诊。医生根据挂号的顺序

42、号，依次给病人看病开处方。n病人拿处方去收款处交费，并拿到发票。n病人拿已经收费的处方去药房拿药。83图书馆系统的用例图842.4.2 用例的描述n用例图是对系统中的用例的高度概括和直观的表示，但没有细节。n一个用例就象一个故事，使用文字叙述对用例进行详细描述。n一个编写良好的用例应该具有很好的可读性，没有可读性的用例则一点儿用也没有。n用例最主要的内容是文本，而不是图表，用例建模的主要工作是书写用例规约，而不是画图。画图是为了更好的书写规约。n用例的描述可以有多种格式，从随意的语言描述到定义严格的用例模板，可根据实际情况选择。851、用例规格说明（模板）Use Case Specificat

43、ionn用例名称n主要参与者/次要参与者n简要描述n前置条件n后置条件n主事件流（主要成功场景/基本路径）n备选事件流（扩展路径/替代流程/异常事件流）n特殊要求/非功能性需求n发生频率862、用例与事件流（Flow of Activities）n用例描述的是一个系统做什么，可以通过用足够清晰的、外部人员很容易理解的文字描述一个事件流，来说明一个用例的行为。n事件流的描述包括：n用例何时开始和结束n用例何时与参与者交互n参与者与系统之间有什么对象或信息被交换n该行为的主事件流和备选事件流873、用例与场景（Scenarios）n用例描述的是一组动作序列，在复杂的系统中，用例细节可能存在多种不同

44、的情节，称为变体。n比如：购买商品的用例中收款可以是现金支付、信用卡支付或支票支付。针对每一种情况有不同的场景，一个场景就是一个具体的故事现场，重现一个参与者如何具体完成用例。n主成功场景：故事的主线，用例通常得到成功执行的典型场景。n扩展场景：失败场景，或因为一些特别条件而出现行为分支的步骤（包括失败和成功）884、用例的前置条件和后置条件n前置条件（pre-condition）：表述在系统允许用例开始以前，系统应确保为真的条件。这可为后续的编程人员提供帮助，从而确定在用例的实现代码中哪些条件无须再次检验。n如果前置条件不满足，用例无法被启动，比如“预定图书”用例的前置条件是读者已正确登录到

45、系统中。n后置条件（guarantee）：或称为成功保证。表述在用例结束时，系统将要保证的限定条件，一般都是在成功完成用例后成立。n一旦用例被成功地执行，可能会导致系统内部某些状态的改变，比如成功地“借出图书”会使图书状态改变等。n某些用例可能没有前置条件或后置条件，比如“查询书目” 。89用例的简要描述用例名：购买商品参与者：出纳员简要描述：顾客带着所要购买的商品来到收款处。收款员记录下商品信息并收款。付款完成后，顾客带着所购买的商品和收据离开。购买商品购买商品收款员收款员90对“取款”用例的非正式描述1）用户插入ATM卡并输入密码2）用户选择取款并输入取款数量3）系统吐出现金，并从账号余额

46、中扣除取款数91对“取款”用例的完整描述主参与者：信用卡用户目标： 用户使用信用卡从ATM机获取现金范围：银行ATM系统前置条件： 用户将信用卡插入ATM触发事件： 用户希望从ATM机上取现金主事件流：1）用户插入信用卡到ATM机2）ATM系统识别卡的ID和账号，并用主银行系统验证其有效性3）用户输入密码，ATM验证其有效性4）用户选择取款，并输入提取金额，该数额必须在502000之间，50的倍数5）ATM系统通知账户所在的主银行系统，传递账号和取款金额，并接受返回的确认信息和账户余额6）ATM系统发放现金、卡，并打印收据7）ATM将事务记入日志92对“取款”用例的完整描述（续）备选事件流：

47、2a：该卡不能在此ATM机上使用3a：密码不正确3b：用户没有及时输入密码4a：金额不是50的倍数，或不在指定范围5a：主机死机或网络瘫痪5b：账户余额不足发生频率： 一天1000次93“借出图书”的用例描述用例名称用例名称借出图书借出图书参与者参与者图书管理员（主要参与者），读者（次要参与者）假设假设图书馆是开架借阅，读者总是找到书后办理借书手续，因此，借书不需要验证库存，而且每本书都是可识别的。前置条件前置条件图书管理员已被识别和授权后置条件后置条件存储借书记录，更新库存数量，所借图书状态为出借主事件流主事件流1图书管理员将读者借书卡提供给系统；2系统验证读者身份和借书条件；3图书管理员将

48、读者所借图书输入系统；4系统记录借书信息，并且修改图书的状态和此种书的可借数量；5系统累加读者的借书数量；6重复3-5，直到图书管理员确认全部图书登记完毕；7系统打印借书清单，交易成功完成。备选事件流备选事件流2a非法读者 1系统提示读者身份错误，用例结束2b读者借书数已达限额 1系统提示读者已达结束限额，用例结束2c读者有过期未还书籍 1系统提示读者应归还的书籍列表和到期日，用例结束5a读者借书数已达限额 1系统提示，并要求结束输入 2图书管理员确认借书完成5b读者有该书的预定记录 1. 删除该书的预定信息945、用例描述的双列格式用例名称归还图书参与者图书管理员（主要参与者），读者（次要参

49、与者）假设因为每本书是可识别的，所以还书不需要验证读者前置条件图书管理员已被识别和授权后置条件修改借书记录，更新库存数量，修改图书状态为可借主事件流1图书管理员将图书提供给 系统；5图书管理员重复步骤1， 直到退出2系统根据借书记录验证图书信息；3系统提供借阅该书的读者信息；4系统修改借书记录，更新该书的图书状态及此种书的可借数量；95每个用例可绘制系统级顺序图n纯文本的用例描述直观性较差n使用UML中的顺序图可以图形化地表现出参与者和系统之间的交互96n进行用例描述时，往往会有冗余的情况出现，比如多个用例会共享一些子功能。n扩展扩展和包含包含关系就是用例模型中消除冗余的一种手段。n但忌讳使用

50、结构化的功能分解将用例分解成一些子用例、子子用例。n基本用例基本用例是包含常规会发生的最基本功能的用例，它是具有普遍性的，对于任何执行该功能的参与者来讲都是适合的。2.4.3 用例关系97用例关系n包含关系：经过封装后可以在各种不同的基本用例中复用的行为称为包含用例包含用例。n扩展关系：表达某些可选或只在特定条件下才执行的系统行为的用例，它们是对基本用例的扩展。称为扩展用例扩展用例。 n泛化关系：如果两个或更多用例在行为、结构和目的方面存在共性，可以使用泛化关系。父用例描述这些共有部分，子用例继承父用例并特殊化。 98n基本用例可以控制包含用例，并依赖于（使用）包含用例所得到的结果。n包含用例

51、是基本用例存在的必要条件n一个基本用例可以有多个包含用例，一个包含用例可以包含在若干基本用例中。包含关系可以嵌套，但超过三层的嵌套是难于理解的。 取款取款修改口修改口令令身份识身份识别别包含关系 预定图书 查询书目 读者 99 登 记 赔 偿 归 还 图 书 图 书 管 理 员 n扩展用例是可选的，它是否执行取决于在执行基本用例时所发生的事件（存在扩展点）。n扩展用例的缺失不影响对基本用例的理解。 打电话打电话来电显示来电显示三方通话三方通话扩展关系100n用一个新的、通常也是抽象的用例来描述多个用例的共有部分(父用例)，子用例继承父用例的所有结构、行为和关系，并含有自己特殊的部分。n父用例通

52、常是抽象抽象的，如果两个子用例都对同一父用例进行特殊化，则两个子用例是相互独立而且完整独立而且完整的，这一点与包含关系扩展关系不同。订购订购网上订购网上订购电话订购电话订购泛化关系（不推荐）101用例的粒度n通常用例图粒度较大n通过分解和细化，可以使粒度更小通过事件流描述：n寻找用例的共同点n寻找用例的扩展点切忌“画蛇添足”！1022.4.4 合理组织用例n对用例进行分包n让用例图能够更为清晰地表现出系统的业务逻辑关系和层次n对系统进行模块的分割，这将影响到今后的开发和系统的最终表现形式n常见的分包方式n按参与者分包，如读者包、图书管理员包n按主题分包，如毕设的题目管理包、成绩管理包n按开发团

53、队分包，A小组、B小组n按发布情况分包，第1次迭代包103错误的用例图举例n把步骤当用例n把系统活动当用例 会员 输入用户名 验证用户名和密码 会员 登录?查询订单建立数据库连接执行SQL语句104错误的用例图举例nEmail客户端（如：outlook express），A在北京发邮件给上海的B，系统提醒B你有“新邮件”，B收邮件收件人发件人发邮件收邮件邮件系统提醒新邮件105课堂练习：用例建模n完成完成“”的系统用例图，的系统用例图，注意用例的命名和用例间的关系的使用。注意用例的命名和用例间的关系的使用。n选择一个体现选择一个体现的用例，的用例，完成用例规格说明。完成用例规格说明。106“旅

54、店预定系统”初步用户需求107问题用例图1108问题用例图2109问题用例图31101. 不恰当的“时间”参与者时间时间：参与者，一种习惯用法，用于激活那：参与者，一种习惯用法，用于激活那些系统定期的、自动执行的用例些系统定期的、自动执行的用例“检查是否可以退定金检查是否可以退定金”的时候，时间仅仅的时候，时间仅仅是一个系统内部的判断条件，而不是参与者是一个系统内部的判断条件，而不是参与者1112. 无效的参与者泛化 参与者泛化参与者泛化：特殊参与者会继承泛化参与者所有的要素！：特殊参与者会继承泛化参与者所有的要素！ 参与者的重要性在一识别用例，如果泛化没有带来任何用例，则参与者的重要性在一识

55、别用例，如果泛化没有带来任何用例，则这样的方法没有任何意义这样的方法没有任何意义 在系统中如果两个参与者涉及相同的用例，则合并在系统中如果两个参与者涉及相同的用例，则合并1123. 错误的用例关系 依赖关系依赖关系：include, extend都是依赖关都是依赖关系系(dependency)的的构造型构造型(stereotype)，带箭头的虚线表示带箭头的虚线表示 扩展关系：扩展关系：“extend”关系的方关系的方向，子用例对主用例向，子用例对主用例的扩展的扩展1133. 错误的用例关系用例的顺序在活用例的顺序在活动图中表现动图中表现1143. 错误的用例关系1154. “其他”用例？“其

56、他其他”、“打印清单打印清单”用例和外围没有任何用例和外围没有任何有意义交互有意义交互，和其他，和其他用例也没有任何关系，用例也没有任何关系，这样的用例有意义吗？这样的用例有意义吗？“其他其他”用例用例又代表又代表什么呢？想说明什么什么呢？想说明什么样的功能需求？样的功能需求？1165.参与者和用例间的关系1176. 用例粒度太小118较为合理的用例图预订房间取消预订酒店前台打印预订清单时间查找房间退还定金计算总费用调整价格管理人员119用例名称：预定房间涉及的参与者：酒店前台描述：酒店前台人员根据旅客的入住请求，预定某个时间指定档次的房间，预定的同时旅客按规定须提交10%定金。 前置条件：前

57、台工作人员必须已经登录到这个系统后置条件：预定信息正确的记录到系统中正常事件流：1) 前台人员向系统提供需要预定房间的类型、时间和预定天数。2) 系统确认有相应档次的空闲房间，并计算出总费用和定金。3) 前台人员向系统提供旅客信息（姓名、地址、联系电话、证件号等）。4) 系统记录旅客信息。5) 前台人员确认已经交纳定金。6) 系统记录房间已经预定，工作完成。备选事件流：2a.没有指定类型的空闲房间,可以转到第一步或者取消预定，用例结束5a.顾客没有交纳定金，前台工作人员取消预定，用例结束。较为合理的用例规格说明1120n用例名称：取消预订n主要参与者：酒店前台n描述：酒店前台利用该用例来取消顾

58、客的预定，如果在指定时间内，则取消时需要返还顾客定金n前置条件：用户必须已经预订了某个房间n后置条件：系统将取消预定的房间恢复为空闲，并且定金已返还给顾客n正常事件流：n前台人员提供给系统顾客信息，比如顾客姓名或证件号码；n系统进行检查并返回该顾客的预订信息，包括顾客姓名、证件号码、联系电话、房间类型、预订时间、预订天数和总费用；n前台人员确认取消该预定；n系统取消该房间预订n备选事件流：2a.系统提示没有该顾客的预定信息。4a.当取消预订在六小时之内，系统提示需要退还顾客定金。 4a1. 系统提示返回金额； 4a2.前台人员确认已退还定金； 4a3.系统记录定金已退还。较为合理的用例规格说明

59、2121该系统用来记录商品销售信息和处理客户的支付。n记录完整的销售信息n从条形码中获得被购买的商品信息n当一次销售被提交给系统后，削减相应库存量n处理现金支付，记录实付款额，计算应还款额n处理信用卡支付/支票支付n出纳员要使用系统，必须登录进入系统POS系统的描述122参与者：出纳员（主）、顾客目标：完成一次商品销售和支付触发条件：顾客带着所要购买的商品来到一个POS机终端主事件流（主成功场景/基本路径）：n出纳员记录每项商品的信息n商品信息录入完毕后，系统计算商品价格总额n出纳员通知顾客商品总额n顾客支付现金，出纳员收取现金，计算找零并打印收据，系统记录交易情况n出纳员将收据交给顾客备选事

60、件流：4a. 出纳员记录每项商品的信息顾客提供信用卡，请求信用卡授权服务机构验证信用卡，最后确认支付并记录支付信息 4a1. 信用卡支付请求被拒绝，要求顾客采用其它方式支付4b. 顾客出示证件和支票，请求支票授权服务机构验证支票，最后确认支付，出纳员记录支票信息 4a1. 支票支付请求被拒绝，要求顾客采用其它方式支付“购买商品”用例规格说明123n使用简单的语法，主语明确，语义易于理解 n明确指出“谁控制球”，也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制。 n从俯视的角度来编写，指出参与者的动作，以及系统的响应，也就是第三者的角度。n显示过程向前推移，也就是每一步都有前进

61、的感受。n显示执行者的意图而不是动作，否则不易理解用例的含义。不涉及界面细节，如按下XX按钮、输入x x键等。2.4.5 书写用例的准则124n包含合理的活动集，例如：挂号员提供挂号信息给系统，不用分别写各种信息。n使用“确认”、“验证”，而不是“检查是否”，“如果否则”等，条件分支采用扩展场景。例如：系统确认读者借书资格有效。 书写用例的准则1252.5 分析模型n面向对象分析的主要内容是：开发一系列模型，以描述系统逻辑结构，展示对象类如何组成系统，以及它们如何交互来体现系统行为。n分析模型主要包括：描述领域对象（静态结构）的类图，描述对象交互（动态交互）的交互图n类图（class diag

62、ram）：描述了构成一类对象特征的状态和行为（）n交互图（interaction diagram）：描述对象之间的交互行为（）（）n每个用例的实现会涉及一组对象的交互126分析模型与用例模型用例：外观用例：外观类图：内部结构类图：内部结构交互图：内部行为交互图：内部行为127如何开始？ 发现领域对象，定义概念类发现领域对象，定义概念类 识别对象的属性识别对象的属性 识别对象的关系，包括建立类的泛化关系、识别对象的关系，包括建立类的泛化关系、对象的关联关系对象的关联关系 建立交互图建立交互图 系统的功能流程比较复杂时：使用活动图系统的功能流程比较复杂时：使用活动图1.1.对象的状态变化较多时：使

63、用状态图对象的状态变化较多时：使用状态图1282.5.1 定义概念类n有两种方法用来识别领域中的概念，从而确定概念类n从用例描述中获取候选概念n摘取用例的详细文档中的名词（术语或名词短语），然后进行分析n通过不同类别发现候选概念1291、Wirfs-Brock名词短语策略 n阅读理解需求文档（或用例说明）；n反复阅读，筛选出名词或名词短语，建立初始对象清单（候选对象）；n将候选对象分成三类，即显而易见的对象、明显无意义的对象和不确定类别的对象；n舍弃明显无意义的名词或短语；n小组讨论不确定类别的对象，直到将它们都合并或调整到其它两类。130阅读需求说明或用例描述1图书管理员将读者借书卡提供给系

64、统；2系统验证读者身份和借书条件；3图书管理员将读者所借图书输入系统；4系统记录借书信息，并且修改图书的状态和此种书的可借数量；5系统修改读者的可用限额；6重复3-5，直到图书管理员确认全部图书登记完毕；7系统打印借书清单，交易成功完成。131图书馆系统的对象名词类别名词类别概念类列表概念类列表显而易见的对象读者 借书卡 图书 借书信息 借书清单明显无意义的对象读者身份不确定类别的对象借书条件 图书状态 可借数量 可用限额图书状态总是和具体的图书联系在一起，不是一个独立的对象。同理，借书数量、可用限额是读者属性。可借数量是某个图书品种的特性，每本图书归属于一个图书品种，图书品种是一个隐含概念借

65、书条件是一种规则，可以作为对象吗？132阅读用例描述用例名：购买商品参与者：出纳员描述：顾客带着所要购买的商品来到收款处。出纳员记录下商品信息并收款。付款完成后，顾客带着所购买的商品和收据离开。133阅读用例规格说明用例名称：预定房间涉及的参与者：酒店前台正常事件流：1) 前台人员向系统提供需要预定房间的类型、时间和预定天数。2) 系统确认有相应档次的空闲房间，并计算出总费用和定金。3) 前台人员向系统提供旅客信息（姓名、地址、联系电话、证件号等）。4) 系统记录旅客信息。5) 前台人员确认已经交纳定金。6) 系统记录房间已经预定，工作完成。1342、不同类别的概念n人员：系统需要保存或管理其

66、信息的人员（如录象商店的会员、图书馆的读者），或在系统中中扮演一定角色的人员（如录象商店的职员、论文评阅教师）。n组织：在系统中发挥一定作用的组织机构（如录象商店的连锁店，医疗保险系统中的医院，学校中的系）。n物品：需要由系统管理的各种物品（如录象商店的商品、图书），包括无形事物（如学校的一门课程、毕设题目）。n设备：在系统中被使用或由系统进行监控的设备、仪器等，系统运行中的硬件设备（如打印机）除外。n事件：需要由系统长期记忆的事件（如在自动柜员机上的每次取款事件、每次借书事件）。135不同类别的概念（续）n规格说明：系统中关于对象的规格信息的描述。n如图书品种，每种图书有一个唯一的馆藏号，同时该图书还包含一些描述信息，如书号、价格、作者、出版社等，多本图书对象共用这些规格说明。这是一种经过了抽象的概念，应该识别为概念类。n业务规则或政策：系统中经常使用的业务规则或政策的文字描述。n业务规则通常会在用例文档之外以其它条款说明。如图书馆系统中，对不同违规行为指定不同的罚款金额，商店对不同顾客或产品有不同的折扣策略等。如果这些规则无法并入到其他对象中，则可以作为概念类建立。n通常规则可能仅