UML9787030444677邹盛荣08需求分析---201509

UML面向对象需求分析与建模教程第8章需求分析邹盛荣当当网:目录8.1确定客户需要什么18.2需求分析方法8.3需求分析路线图328.4分析案例48.1确定客户需要什么•分析？分而析之？合理吗•整体论•系统论•复杂网络的必要性•分析阶段主要考虑所要解决的问题，可用UML的逻辑视图和动态视图来描述，类图描述系统的静态结构，协作图、状态图、序列图、活动图和状态图描述系统的动态特征•在分析阶段，只为问题领域的类建模，不定义软件系统的解决方案的细节：如用户接口的类、数据库等。-7-分析模型与用例模型用例：外观类/协作：内部机理-8-从用例开始分析迭代•UP方法中最重要的思想就是迭代，而迭代的基础就是用例•从用例开始分析基本思路–根据用例图和用例文档来确认需求定义是可靠的、一致的–用例分级：根据风险、重要性以及项目组的能力确定用例以及用例相关路径的优先级8.2需求分析方法•面向对象分析的目的是对客观世界的系统进行建模。•分析模型有三种用途：用来明确问题需求；为用户和开发人员提供明确需求；为用户和开发人员提供一个协商的基础，作为后继的设计和实现的框架。•4+1视图方法•“4+1”视图是对逻辑架构进行描述，最早由PhilippeKruchten提出，他在1995年的《IEEESoftware》上发表了题为《The4+1ViewModelofArchitecture》（架构的4+1视图模型）的论文，引起了业界的极大关注，并最终被RUP采纳，现在已经成为架构设计的结构标准。•逻辑视图、开发视图主要是用来描述系统的静态结构，而处理视图、物理视图主要描述系统的动态结构。并非每个系统都必须把5个视图都画出来，它们各有侧重点，例如信息管理系统（MIS）系统侧重于逻辑视图、开发视图，而实时控制系统则侧重于处理视图、物理视图。-12-构架：4+1视图(fromRUP)ProcessViewDeploymentViewLogicalViewUse-CaseViewImplementationViewEnd-userFunctionalityProgrammersSoftwaremanagementPerformanceScalabilityThroughputSystemintegratorsSystemtopologyDelivery,installationcommunicationSystemengineeringAnalysts/DesignersStructure（1）用例视图。用例视图强调从系统的外部参与者看到的或需要的系统功能。用例是系统的一个功能单元，可以认为用例是参与者与系统之间的一次交互。（2）逻辑视图。逻辑视图从系统的静态结构和动态行为角度显示如何实现系统的功能。它主要是为设计和开发人员准备的，主要关注系统内部的具体实现。（3）组件视图。组件视图显示代码组件的组织结构。组件是封装良好的、定义了接口的代码模块。使用组件视图的主要是开发人员。（4）并发视图。并发视图显示系统的并发性，解决在并发系统中存在的通信和同步问题。（5）配置视图。配置视图显示系统的具体部署。部署是指将系统配置到硬件设备上。帮助建模者定义类:•z有没有一定要存储或分析的信息如果存在需要存储分析或处理的信息那么•该信息有可能就是一个类这里讲的信息可以是概念该概念总在系统中出现•或事件或事务它发生在某一时刻•z有没有外部系统如果有外部系统可以看作类该类可以是本系统所包含的类•也可以是本系统与之交互的类•z有没有模版类库组件等如果手头上有这些东西它们通常应作为类模版•类库组件可以来自原来的工程或别人赠送或从厂家购买的•z系统中有被控制的设备吗凡是与系统相连的任何设备都要有对应的类通过这•些类控制设备•z有无需要表示的组织机构在计算机系统中表示组织机构通常用类特别是构建•商务模型时用得更多•z系统中有哪些角色这些角色也可以看成类比如用户系统操作员客户等•类图的建模分析步骤•（1）寻找出需求中的名词(候选对象)。•（2）合并含义相同的名词，排除范围以外的名词，并寻找隐含的名词。•（3）去掉只能作为类属性的名词。•（4）剩下的名词就是要找的分析类（候选类)。•（5）根据常识、问题域、系统责任确定该类有那些属性。•（6）补充该类动态属性，如状态、对象间联系（如聚合、关联）等属性•（7）从需求中的动词、功能或系统责任中寻找类的操作（候选操作）。•（8）从状态转换，流程跟踪、系统管理等方面补充类的操作。•（9）对所寻找的操作进行合并、筛选。•（10）对所寻找的操作在类间进行合理分配（职责分配）。形成每个类候选操作。•（11）补充每个类的的分析文档，为类的进一步设计打下基础。•类的识别方法•对软件开发进行分析建模，依据的是原始需求资料，而原始需求是由文字描述而成，•说的更白一点，就是由名词、动词、形容词等等按照一定的规则组合而成，名词一般被识•别成类或属性，动词一般被识别成操作，形容词一般被识别成性能属性。•一个名词被识别成属性还是类，与该软件业务有很大的关系，通常如果一个名词有另•外的名词作为附属，或有一个动词受此名词的支配，那么该名词就是类，其次要寻找隐含•在字里行间的名词，合并含义相同的名词。•一般来讲，参与业务活动的人、组织机构、系统管理的设备都是类，需要长期保存的•事件也是类，业务运转的表单、票据都是类，另外还有一些为了业务运转而附加的类。•这些寻找出来的待定类，经过反复整理、筛选，最后形成候选类。•寻找属性时，•一般要从类的实例--对象来着手，并从以下几个方面进行考虑：•1、按一般常识这个对象有那些属性。•2、在当前问题域该对象有那些属性。•3、根据系统责任，这个对象应该有那些属性。•4、为了实现某些功能，对象需要增加那些属性。•5、对象有那些区别的状态。•6、对象整体和部分属性设置。•寻找操作要从类的实例--对象来着手，并从以下几个方面进行考虑：•1、从需求中的功能，寻找对象的操作。•2、系统行为推迟到设计阶段。•3、暂不考虑对象中读、写属性这样的操作。•4、根据系统责任，这个对象应该有那些操作。•5、分析对象的状态转换，寻找操作。•6、追踪流程，寻找操作。•7、类本身要使用那些操作来维护信息更新以及信息的一致性和完整性。•下面以“银行网络系统”为例，用面向对象方法进行开发。•银行网络系统问题陈述：设计支持银行网络的软件，银行网络包括人工出纳站和分行共享的自动出纳机。每个分理处用分理处计算机来保存各自的帐户，处理??通信，出纳站录入帐户和事务数据；自动出纳机与分行计算机通信，分行计算机与拨款分理处结帐，自动出纳机与用户接口接受现金卡，与分行计算机通信完成事务，发放现金，打印收据；系统需要记录保管和安全措施；系统必须正确处理同一帐户的并发访问；每个分处理为自己的计算机准备软件，银行网络费用根据顾客和现金卡的数目分摊给各分理处。•1.确定类•构造对象模型的第一步是标出来自问题域的相关的对象类，对象包括物理实体和概念。所有类在应用中都必须有意义，在问题陈述中，并非所有类都是明显给出的。有些是隐含在问题域或一般知识中的。•查找问题陈述中的所有名词，产生如下的暂定类:•软件银行网络出纳员自动出纳机分行•分处理分处理计算机帐户事务出纳站•事务数据分行计算机现金卡用户现金•收据系统顾客费用帐户数据•访问安全措施记录保管•根据下列标准，去掉不必要的类和不正确的类。•（1）冗余类：若两个类表述了同一个信息，保留最富有描述能力的类。如用户和顾客就是重复的描述，因为顾客最富有描述性，因此保留它。•（2）不相干的类：除掉与问题没有关系或根本无关的类。例如，摊派费用超出了银行网络的范围。•（3）模糊类：类必须是确定的，有些暂定类边界定义模糊或范围太广，如记录保管就模糊类，它是事务中的一部分。•（4）属性：某些名词描述的是其他对象的属性，则从暂定类中删除。如果某一性质的独立性很重要，就应该把他归属到类，而不把它作为属性。•（5）操作：如果问题陈述中的名词有动作含义，则描述的操作就不是类。但是具有自身性质而且需要独立存在的操作应该描述成类。如我们只构造电话模型，拨号就是动态模型的一部分而不是类，但在电话拨号系统中，拨号是一个重要的类，它日期、时间、受话地点等属性。•状态图的建模分析步骤•（1）首先要确定进行系统控制的对象，可以从分析的顺序图中寻找。•（2）确定对象的起始状态和结束状态•（3）在对象的整个生命周期寻找有意义的控制状态•（4）寻找状态之间的转换•（5）补充引起转换的事件•（6）UML建模工具画状态图•（7）补充必要的文档•活动图建模的步骤•（1）在采集的原始需求中选择重点流程•（2）首先要确定要设计的活动图是针对业务流程还是用例。•（3）其次要设计活动过程的起点和终点。•（4）确定活动图所有执行对象。•（5）确定活动节点，并根据执行对象进行活动分组。•（a）如果对用例建活动图，则把角色所发出的每一个动作变为活动节点。•（b）如果对业务流程建活动图，则把每一个流程步骤(或片段)变为活动节点。•（6）确定活动节点之间转移。•（7）处理在活动节点之间的分支和合并。•（8）处理在活动节点之间的分叉和汇合•（9）用UML建模工具进行活动图建模。•（10）编写必要的补充文档。•顺序图的建模分析步骤•(1)完成用例图的分析。•(2)对每个用例，识别出参与基本事件流的对象(包括接口、子系统、角色等)。•(3)识别出这些对象是主动对象还是被动对象。•(4)识别出这些对象发出的消息是同步消息还是异步消息。•(5)从主动对象开始向接收对象发消息。•(6)接收对象再调用自己的服务为主动对象返回结果。•(7)如果接收对象需要再调用其他对象的服务，需要向其他对象再发消息。•(8)如此反复，最后返回给主动对象有意义的结果。•(9)用UML建模工具绘出顺序图。•(10)给顺序图补充必要的说明文档。•协作图的建模分析步骤•1.完成用例图的分析•2.对每个用例，识别出参与基本事件流的对象(包括接口、子系统、角•色等)•3.识别出对象间的连接关系•4.识别出这些对象发出的消息顺序•5.从主动对象开始向接收对象发消息•6.接收对象再调用自己的服务为主动对象返回结果•7.如果接收对象需要再调用其他对象的服务，需要向其他对象再发消•息•8.如此反复，最后返回给主动对象有意义的结果•9.用UML建模工具绘出协作图•10.给通信图补充必要的说明文档8.3路线图分析:1,类抽取实体类功能模型(用例的剧本)类图（名词抽取法）动态模型(状态图、活动图)2,用例的细化和实现协作图、顺序图a.引言a.1目的a.2文档约定a.3预期的读者和阅读建议a.4产品的范围a.5参考文献d.系统特性d.1说明和优先级d.2激励/响应序列d.3功能需求b.综合描述b.1产品的前景b.2产品的功能b.3用户类和特征b.4运行环境b.5设计和实现上的限制b.6假设和依赖e.其它非功能需求e.1性能需求e.2安全设施需求e.3安全性需求e.4软件质量属性e.5业务规则e.6用户文档c.外部接口需求c.1用户界面c.2硬件接口c.3软件接口c.4通信接口f.其它需求附录A:词汇表附录B:分析模型附录C:待确定问题的列表8.4分析案例普通员工:User系统数据库1:登录2:填写请假条3:添加成功4:查询5:返回结果:管理员系统数据库1:登录2:添加员工信息3:添加成功4:员工信息查询5:返回:公司领导系统数据库1:登录2:请假条批示3:批示成功4:员工请假查询5:返回结果开始登录系统注销登录结束1登录出错管理员普通员工公司领导员工信息添加与修改员工查询请假条填写个人请假查询请假条批示员工请假查询结束2Thankyou!