收藏 分享(赏)

软件工程基础之03 需求分析.ppt

上传人:ysd1539 文档编号:7190122 上传时间:2019-05-09 格式:PPT 页数:111 大小:3.32MB
下载 相关 举报
软件工程基础之03 需求分析.ppt_第1页
第1页 / 共111页
软件工程基础之03 需求分析.ppt_第2页
第2页 / 共111页
软件工程基础之03 需求分析.ppt_第3页
第3页 / 共111页
软件工程基础之03 需求分析.ppt_第4页
第4页 / 共111页
软件工程基础之03 需求分析.ppt_第5页
第5页 / 共111页
点击查看更多>>
资源描述

1、第三章 需求分析,需求分析的定义,需求分析的任务和步骤,需求分析的任务 建立分析模型 编写需求说明 需求分析的步骤 需求获取 需求提炼 需求描述(撰写需求规格说明书) 需求验证,需求分析的任务和步骤,需求分析的任务 建立分析模型 编写需求说明,准确地定义未来系统的目标,确定为了满足用户的需求系统必须做什么。,需求分析的任务和步骤,需求分析的任务 建立分析模型 编写需求说明,用需求规格说明书规范的形式准确地表达用户的需求。,第一步:需求获取,需求的类型,(1) 功能性需求:描述系统应该做什么,即为用户和其它系统完成的功能、提供的服务。 (2)非功能需求:必须遵循的标准,外部界面的细节,实现的约束

2、条件,质量属性等等。非功能需求限定了选择解决问题方案的范围,如运行平台、实现技术、编程语言和工具等。,?,将飞机订票系统中的以下方面做如下的划分,F代表“功能性”,NF代表“非功能性”,X代表“不应当是需求”。简要的说明功能性或非功能性需求的种类。对于不应当是需求的方面,说明其原因。 如何输入有关航班、乘客及订票信息。F:输入 什么信息要出现在机票和报告中。F:输出 如何计算乘机费用。 F:计算 什么信息必须存储在旅行社和其他人访问的数据库中。F:数据存储,例,举, 这个系统应该设计成可以处理常旅客计划。NF:可扩展性 这个系统在任何时候都必须是可用的。一周中只允许有2分钟宕机时间。 NF:有

3、效性 必须使用某排序算法根据离开时间对航班排序。X:这是一个设计问题,需求来源,用户目标,领域知识,投资者,组织环境,运行环境,需求获取技术,采访设定情景(用例)原型会议(用户、投资者、领域专家等)观察商业过程和工作流,需求诱导十原则,倾听,需求诱导十原则,2. 有准备的沟通,需求诱导十原则,3. 需要有人推动,需求诱导十原则,4. 最好当面沟通,需求诱导十原则,5. 记录所有决定,需求诱导十原则,6. 保持通力协作,需求诱导十原则,7. 聚焦并协调话题,需求诱导十原则,8. 采用图形表示,需求诱导十原则,9. 继续前进原则,一旦认可某件事情,继续前进; 如果不认可某件事情,继续前进; 如果某

4、项特性或功能不清晰,当时无法澄清,继续前进,需求诱导十原则,10. 谈判双赢原则,第二步:需求提炼 (需求分析),需求分析的核心在于建立分析模型。 需求分析采用多种形式描述需求,通过建立需求的多种视图,揭示出一些更深的问题。 需求分析还包括与客户的交流以澄清某些易混淆的问题,并明确哪些需求更为重要,其目的是确保所有风险承担者尽早地对项目达成共识并对将来的产品有个相同而清晰的认识。,分析建模,结构化分析模型 面向对象分析模型 分析模型描述工具 数据流图、数据字典和加工规约 控制流图、控制规约和状态变迁图 E-R图 用例图,对象-关系图,对象-行为图,其基本思想是用系统工程的思想和工程化的方法,根

5、据用户至上的原则,自始自终按照结构化、模块化,自顶向下地对系统进行分析与设计。,由5个层次(主题层、对象类层、结构层、属性层和服务层)和5个活动(标识对象类、标识结构、定义主题、定义属性和定义服务)组成。,需求建模图形工具,第三步:需求规格说明书,需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规格说明书。 需求规格说明书的编制是为了使用户和软件开发者双方对该软件的初始规定有一个共同的理解,使之成为整个开发工作的基础。,软件需求规格说明的原则,从现实中分离功能,即描述要“做什么”而不是“怎样实现” 要求使用面向处理的规格说明语言(或称系统定义语言) 如果被开发软件只是一个大系统中的

6、一个元素,那么整个大系统也包括在规格说明的描述之中 规格说明必须包括系统运行环境 规格说明必须是一个认识模型 规格说明必须是可操作的 规格说明必须容许不完备性并允许扩充 规格说明必须局部化和松散耦合,软件需求规格说明的结构,IEEE标准为需求文档提出了以下结构,组织机构内部可以基于此标准扩展:,a. 需求文档的目的 b. 文档约定 c. 预期的读者和阅读建议 d. 产品范围 e. 参考文献,a. 产品前景 b. 产品功能与优先级 c. 用户特征 d. 运行环境 e. 设计与实现上的限制 f. 假设和依赖性,(2)综合描述,(1)引言,(3)需求描述,a. 功能需求 b. 数据需求:与功能有关的

7、数据定义和数据关系 c. 性能需求:响应时间、容量要求、用户数等 d. 外部接口:用户界面、软硬件接口、通信接口 e. 设计约束:软件支持环境、报表、数据命名等 f. 软件质量属性(可维护性、可靠性、可移植性、可用性、安全性等) g. 其他需求这一节是文档中最实质性的部分,由于在机构组织的实践中存在极大的变数,对这一节定义的标准结构可以进行增删。,(4)附录(词汇表、分析模型、待定问题列表),(5)索引,软件需求规格说明(SRS),第四步:需求验证,需求验证的重要性:如果在后续的开发或当系统投入使用时才发现需求文档中的错误,就会导致更大代价的返工。由需求问题而对系统做变更的成本比修改设计或代码

8、错误的成本要大的多。假设需求阶段引入1个错误的需求,设计时对这个需求需要510条设计实现,1条设计需要 510条程序,1条程序需要35种测试组合测试。,原始需求,正确的规格说明 错误的规格说明,正确的设计 错误的设计 对错误需求的设计,正确的编码 错误的编码 对错误设计的编码 对错误需求的编码,正确功能 测试到的错误 没有测试到的错误,一个错误的需求,纠正成本100元,10 纠正成本1000元,10,5,$100$50000!,对需求文档需执行以下类型的检查:(1)有效性检查 检查不同用户使用不同功能的有效性。(2)一致性检查在文档中,需求之间不应该冲突。(3)完备性检查需求文档应该包括所有用

9、户想要的功能和约束。(4)现实性检查检查保证能利用现有技术实现需求。,需求验证技术,(1)需求评审 由分析员、设计员、测试员、用户参与的正式或非正式的会议评审。正式会议要有严格的评审程序,要有会议记录,开发组根据缺陷建议修改需求说明并重审。(2)利用原型检验系统是否符合用户的真正需要(3)对每个需求编写概念性的测试用例。(4)编写用户手册。用浅显易懂的语言描述用户可见的功能。(5)自动的一致性分析。可用CASE工具检验需求模型的一致性。,软件需求工具,Rational RequisitePro 能够帮助项目团队改进项目目标的沟通,增强协作开发,降低项目风险,以及在部署前提高应用程序的质量。 T

10、elelogic DOORS 基于整个公司的需求管理系统,用来捕捉、链接、跟踪、分析及管理信息,以确保项目与特定的需求及标准保持一致。 Borland CaliberRM 基于Web 和用于协作的需求定义和管理工具,可以帮助分布式的开发团队平滑协作,从而加速交付应用系统。CaliberRM 辅助团队成员沟通,减少错误和提升项目质量。 Rational Rose 可用于UML建模分析,需求总在变化,需求变更管理,变更管理是将个人、团队和组织从现有状态转移/过渡到期望状态的结构化方法。它授权雇员接受并理解当前业务环境中的变更。在项目管理中,变更管理是指项目变更被引入和接受后的项目管理过程。 管理和

11、控制需求基线的过程 需求变更控制系统一个正式的文档,说明如何控制需求变更建立变更审批系统,需求变更处理流程,面向过程的分析方法,结构化分析方法,面向数据流进行需求分析的方法 结构化分析方法适合于数据处理类型软件的需求分析 具体来说,结构化分析方法就是用抽象模型的概念,按照软件内部数据传递、变换的关系,自顶向下逐层分解,直到找到满足功能要求的所有可实现的软件为止 结构化分析方法使用工具:数据流图,数据字典,实体联系图,状态变迁图,功能模型数据流图 (Data Flow Diagram),数据流图,数据流图中的主要图形元素,例:描述银行取款过程的数据流图,数据流与数据加工之间的关系,只有A或只有B

12、才有C,数据流图的层次结构,为了表达数据处理过程的数据加工情况,需要采用层次结构的数据流图。按照系统的层次结构进行逐步分解,并以分层的数据流图反映这种结构关系,能清楚地表达和容易理解整个系统,分层数据流图,在多层数据流图中,顶层流图仅包含一个加工,它代表被开发系统。它的输入流是该系统的输入数据,输出流是系统所输出数据,中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化,形成子图,底层流图是指其加工不需再做分解的数据流图,它处在最底层,顶层流图(商店业务处理系统),这个数据流图只是一个高层的系统逻辑模型,它反映了目标系统要实现的功能,商店业务系统数据流图 绘制步骤,首先确定系统的输入和

13、输出 根据商店业务,画出顶层数据流图,以反映最主要业务处理流程 经过分析,商店业务处理的主要功能应当有销售、采购、会计三大项。主要数据流输入的源点和输出终点是顾客和供应商。 然后从输入端开始,根据商店业务工作流程,画出数据流流经的各加工框,逐步画到输出端,得到第一层数据流图,第一层数据流图,第二层:加细每一个加工框 1.销售细化,2.采购细化,检查和修改数据流图的原则,数据流图上所有图形符号只限于前述四种基本图形元素 数据流图的主图必须包括前述四种基本元素,缺一不可 数据流图的主图上的数据流必须封闭在外部实体之间 每个加工至少有一个输入数据流和一个输出数据流 在数据流图中,需按层给加工框编号。

14、编号表明该加工所处层次及上下层的亲子关系 规定任何一个数据流子图必须与它上一层的一个加工对应,两者的输入数据流和输出数据流必须一致。此即父图与子图的平衡 图上每个元素都必须有名字 数据流图中不可夹带控制流 初画时可以忽略琐碎的细节,以集中精力于主要数据流,数据模型ER图 (Entity Relationship Diagram),实体-联系图(ERD),ER图 - 是用来建立数据模型的工具。 数据模型 - 是一种面向问题的数据模型,是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据,反映了用户的现实环境,而且与在软件系统中的实现方法无关。 数据模型中包含3种相互关联的信息:数据对象

15、(实体)、数据对象的属性及数据对象彼此间相互连接的关系。,(1) 数据对象,数据对象: 是必须由软件理解的复合信息的抽象。 复合信息: 是指具有一系列不同性质或属性的事物,仅有单个值的事物(例如,宽度)不是数据对象。 可以由一组属性来定义的实体都可以被认为是数据对象。如:外部实体、事物、行为、事件、角色、单位、地点或结构等。 数据对象彼此间是有关联的。,(2) 属 性,属性定义了数据对象的性质。 应该根据对所要解决的问题的理解,来确定特定数据对象的一组合适的属性。 如:学生具有学号、姓名、性别、年龄、专业等属性;课程具有课程号、课程名、学分、学时数等属性;教师具有职工号、姓名、年龄、职称等属性

16、。,(3) 联 系,数据对象彼此之间相互连接的方式称为联系,也称为关系。 联系可分为以下3种类型:a. 一对一联系(11)如:一个部门有一个经理,而每个经理只在一个部门任职,则部门与经理的联系是一对一的。b. 一对多联系(1N)如:某校教师与课程之间存在一对多的联系“教”,即每位教师可以教多门课程,但是每门课程只能由一位教师来教。c. 多对多联系(MN)如:学生与课程间的联系(“学”)是多对多的,即一个学生可以学多门课程,而每门课程可以有多个学生来学。 联系也可能有属性。如:学生“学”某门课程所取得的成绩,既不是学生的属性也不是课程的属性。由于“成绩”既依赖于某名特定的学生又依赖于某门特定的课

17、程,所以它是学生与课程之间的联系“学”的属性。,(4) 实体-联系图的符号,ER图中包含了实体(即数据对象)、关系和属性等3种基本成分。 通常用矩形框代表实体;用连接相关实体的菱形框表示关系;用椭圆形或圆角矩形表示实体(或关系)的属性;并用直线把实体(或关系)与其属性连接起来。,某校教学管理ER图,举 例,数据字典(Data dictionary),数据字典中的每个数据条目有以下内容: 名字(别名) 数据类型 使用该数据条目的简要说明 数据条目的解释性说明 其他补充说明:取值范围、缺省值、设计约束等 以它作为输入流或输出流的转换的列表,数据字典例子,数据字典例子(续),订票单 名字: 订票单

18、数据类型: 航班日期 + 目的地 + 出发地 + 航班号 使用说明: 必须给出各个数据项 解释性说明: 无 缺省值: 出发地 = 填写本地 作为输出流的转换列表:无 作为输入流的转换列表:预定机票 ,数据字典5类数据,数据项: 数据流图中数据块的数据结构中的数据项说明 数据项描述数据项名,数据项含义说明,别名,数据类型,长度,取值 范围,取值含义,与其他数据项的逻辑关系 数据结构:数据流图中数据块的数据结构说明 数据结构描述数据结构名,含义说明,组成:数据项或数据结构 数据流: 数据流图中流线的说明 数据流描述数据流名,说明,数据流来源,数据流去向,组成:数据结 构,平均流量,高峰期流量 数据

19、存储:数据流图中数据块的存储特性说明 数据存储描述数据存储名,说明,编号,流入的数据流,流出的数据流 ,组成:数据结构,数据量,存取方式 处理过程:数据流图中功能块的说明 处理过程描述处理过程名,说明,输入:数据流,输出:数据流, 处理:简要说明,行为模型状态变迁图 (State Transition Diagram ),状态变迁图,通过描绘系统的状态及引起系统状态转换的事件,来表示系统的行为。此外,状态图还指明了作为特定事件的结果系统将做哪些动作(例如,处理数据)。,1) 状 态,状态是任何可以被观察到的系统行为模式,一个状态代表系统的一种行为模式。 状态规定了系统对事件的响应方式。 系统对

20、事件的响应,既可以是做一个(或一系列)动作,也可以是仅仅改变系统本身的状态,还可以是既改变状态又做动作。初态 (即初始状态)状态 终态 (即最终状态)中间状态,一张状态图中只能有一个初态,而终态则可以有0至多个。,2) 事 件,事件是在某个特定时刻发生的事情,它是对引起系统做动作或(和)从一个状态转换到另一个状态的外界事件的抽象。 例如,内部时钟表明某个规定的时间段已经过去,用户移动或点击鼠标等都是事件。 简而言之,事件就是引起系统做动作或(和)转换状态的控制信息。,3) 符 号,初态用实心圆表示,终态用一对同心圆(内圆为实心圆)表示。 中间状态用圆角矩形表示,可以用两条水平横线把它分成上、中

21、、下3个部分。上面部分为状态的名称,这部分是必须有的;中间部分为状态变量的名字和值,这部分是可选的;下面部分是活动表,这部分也是可选的。,3) 符 号,活动表的语法格式:事件名(参数表)/动作表达式其中,“事件名”可以是任何事件的名称。在活动表中经常使用下述3种标准事件:entry,exit和do。entry事件指定进入该状态的动作,exit事件指定退出该状态的动作,而do事件则指定在该状态下的动作。需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。,3) 符 号,状态图中两个状态之间带箭头的连线称为状态转换,箭头指明了转换方向。 状态变迁通常是由事件触发的,在这种情况下应在

22、表示状态转换的箭头线上标出触发转换的事件表达式;如果在箭头线上未标明事件,则表示在源状态的内部活动执行完之后自动触发转换。 事件表达式的语法:事件说明守卫条件动作表达式 事件说明的语法为:事件名(参数表) 守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件,则当且仅当事件发生且布尔表达式为真时,状态转换才发生。如果只有守卫条件没有事件说明,则只要守卫条件为真状态转换就发生。 动作表达式是一个过程表达式,当状态转换开始时执行该表达式。,面向过程的分析建模小结,面向对象的分析方法,面向对象的分析与设计语言UML,UML(Unified Modeling Language,统一建模语言)统一了

23、面向对象建模的基本概念、术语及其图形符号,为不同领域的人员提供一个交流的标准。 就像数据流图作为结构化分析的建模语言,模块结构图作为结构化总体设计的建模语言一样,UML是面向对象的系统分析与设计的建模语言,不要将它理解为一种方法论或是一种开发过程。,功能模型用例图 (Use case diagram),用例需求分析,用例需求分析方法采用一种面向对象的情景分析方法 用例是系统向用户提供一个有价值的结果的某项功能 从用户角度出发考虑的功能需求 所有的用例结合起来就构成了用例模型,用例视图,用例建模用于描述系统需求,把系统当作黑盒,从用户的角度,描述系统的场景。主要元素有以下几个: 参与者 用例 执

24、行关联,参与者(Actor),参与者:是指外部用户或外部实体在系统中扮演的角色 定义 是直接与系统相互作用的系统、子系统或类的外部实体的抽象。它是用户所扮演的角色,是系统的用户。每个参与者定义了一个角色集合。通常,一个参与者可以代表一个人、一个计算机子系统、硬件设备或者时间等角色。典型的参与者如销售部经理、销售员和结帐系统。 图形表示 用小人图符表示,用例(Use Case),定义 对一组动作序列的描述,系统通过执行这一组动作序列为参与者产生一个可观察的结果 用例特征 说明了系统具有的一种行为模式 说明了一个参与者与系统执行的一个相关的事件序列 提供了一种获取系统需求的方法 提供了一种与最终的

25、用户和领域专家进行沟通的方法 提供了一种测试系统的方法 图形表示 用椭圆形表示,执行关联,执行关联:Actor 执行Use Case的关系。 泛化:用例之间的继承关系,表示用例之间的场景共享;Actor之间的 继承关系,一般描述职责共享。 实现:用例与用例实现之间的实现关系。 扩展:由一个用例的扩展点可以扩展出另外一个用例。 包含:一个用例可以包含另外一个用例。,用例实例一:ATM系统用例图,用例实例二:图书借阅系统用例图,用例实例三:饮料销售机用例图,用例建模的过程,建立用例模型的顺序是: 确定谁会直接使用该系统。这些都是参与者(Actor)。 选取其中一个参与者。 定义该参与者希望系统做什

26、么,参与者希望系统做的每件事成为一个用例。 对每件事来说,何时参与者会使用系统,通常会发生什么,这就是用例的基本过程。 描述该用例的基本过程。 考虑一些可变情况,把他们创建为扩展用例。 复审不同用例的描述,找出其中的相同点,抽出相同点作为共同的用例。 重复步骤27找出每一个用例。,寻找参与者的问题,在获取用例前首先要确定系统的参与者,开发人员可以通过回答以下的问题来寻找系统的参与者。 (1)谁将使用该系统的主要功能? (2)谁将需要该系统的支持以完成其工作? (3)谁将需要维护、管理该系统,以及保持该系统处于工作状态? (4)系统需要处理哪些硬件设备? (5)与该系统交互的是什么系统? (6)

27、谁或什么系统对本系统产生的结果感兴趣?,寻找用例的问题,在识别用例的过程中,通过回答以下几个问题,系统分析者可以获得帮助。 (1)特定参与者希望系统提供什么功能? (2)系统是否存储和检索信息,如果是,由哪个参与者触发? (3)当系统改变状态时,是否通知参与者? (4)是否存在影响系统的外部事件?哪个参与者通知系统这些事件?,数据模型类图,类图,面向对象方法的三个最重要的技术是用例图、类图和交互模型。无论是面向对象的分析还是面向对象的设计和实现,类图都是最核心技术。它不仅能够表现信息的结构,还能够反映系统的行为。 事实上,软件开发不同时期的类图反映了不同层次上的抽象。在需求分析阶段,类图用于研

28、究领域的概念,主要反映实体类和界面类;在设计阶段,类图描述类与类之间的接口和控制;在实现阶段,类图描述系统中类的具体实现。,类,类是包含信息和影响信息行为的逻辑元素。类的符号是由三个格子的长方形组成,有时下面两个格子可以省略。 最顶部的格子包含类的名字,类的命名应尽量用应用领域中的术语,有明确的含义,以利于开发人员与用户的理解和交流。中间的格子说明类的属性。最下面的格子是类的操作行为。,类的获取是一个依赖于人的创造力的过程。实践中,寻找类有两种办法:一种是从用例的描述开始,检查用例描述中的每个名词。另一种是检查时序图中的对象,研究对象具有的共同属性和操作来发现类。 注意,并不是所有的类都能够从

29、工作流和交互图中找到。,属性,属性是与类相关联的信息,描述该类对象的共同特点。例如,“客户”类有“客户名”、“地址”、“电话”等属性。 常见的属性可见性有Public、Private和Protected三种,在UML类图中分别表示为“+”、“-”、“#”、“ ” + Public - 全局可见 - Private - 对所属类型以外的类型不可见 # Protected - 对所有者派生的类型可见 Package - 对同一包中的其他类型可见。,属性的类型可以是基本数据类型,例如整数、实数、布尔型、字符串型等,也可以是用户自定义的类型。一般它由所使用的程序设计语言确定。 约束特性则是用户对该属性

30、性质一个约束的说明。例如“只读”说明该属性是只读属性。,操作,操作是与类相关的行为,用于修改、检索类的属性或执行某些动作。操作通常也被称为功能,但是它们被约束在类的内部实现,只能作用到该类的对象上。,寻找类的操作比较简单,实际上,在创建交互图时,就在寻找类的操作。在识别类的操作时,下面几个问题有助于寻找类的操作: 1)有哪些类会与该类交互,包括该类本身? 2)该类接收哪些类(包括自己)发送的消息,收到消息之后进行什么处理? 3)该类向哪些类发送消息,消息的内容是什么,在发送消息之前该类需要做什么处理? 4)该类中需要哪些操作来维持自身属性的一致性、完整性,以及自身属性的更新? 5)系统是否需要

31、该类具有另外一些职责?,在类图中,描述类的操作分三个部分:操作名、返回类型和参数表。 在UML中描述操作的信息有五个部分:可见性 操作名 (参数表) : 返回类型 约束特性。,“客户”类中有“取客户地址”的操作,它在UML中表现形式如下: GetAddr(CustomerNo:String):String 其中“+” 表示该操作是公有操作,GetAddr是操作名,调用时需要参数“CustomerNo”,操作的返回类型也为字符串,约束特征被省略了。 常见的操作可见性有Public、Private和Protected三种,在UML类图中分别表示为“+”、“-”和“#”。,类间关系,类图中的基本关系

32、包括:关联关系,聚合关系,组合关系,依赖关系,泛化关系等。,关联关系,关联是一种结构化的关系,指一种对象和另一种对象有联系。给定有关联的两个类,可以从一个类的对象得到另一个类的对象,关联有两元关系和多元关系。,聚合关系,聚合关系指的是整体与部分的关系。通常在定义一个整体类后,再去分析这个整体类的组成结构,从而找出一些组成类,该整体类和组成类之间就形成了聚合关系。在聚合关系中,类A是类B的一部分,但是类A可以独立存在,在UML中,聚合关系用带空心菱形的直线表示。,组合关系,组合关系也表示类之间整体和部分的关系,但是组合关系中部分和整体具有统一的生存期。一旦整体对象不存在,部分对象也将不存在,部分

33、对象与整体对象之间具有共生死的关系。在组合关系中,类A包含类B,而且可以控制类B的生命周期。类A控制类B的生命周期意味着类B的存在依赖于类A。在UML中,组合关系用带实心菱形的直线表示。,依赖关系,依赖关系是一种使用关系,特定事物的改变有可能会影响到使用该事物的事物,反之不成立,在我们想显示一个事物使用另一个事物时使用依赖关系。通常情况下,依赖关系体现在某个类的方法使用另一个类作为参数。在UML中也可以在其它的事物之间使用依赖关系,如节点之间的关系。依赖关系用带箭头的虚线表示,由依赖的一方指向被依赖的一方。,泛化关系,泛化也就是继承关系,也称为“is-a-kind-of”关系,泛化关系描述了超

34、类与子类之间的关系,超类又叫做基类,子类又叫做派生类。在UML中,泛化关系用带空心三角形的直线来表示。,类的分类,类的版型可以将类进行分类,并且有助于理解每个类的责任,例如,Form版型的类负责向用户显示信息和接收用户信息,不同版型的类具有不同的职责。 分析过程中,可以根据功能将类分为实体类、边界类和控制类。,边界类位于系统与外界的交界处,包括所有的窗体、报表、系统硬件接口、与其它系统的接口。 实体类实体类保存要存入永久存储体的信息。实体类通常在事件流或交互图中,是对用户最有意义的类。 控制类控制类负责协调其它类的工作。每个用例中至少应该有一个控制类,它控制用例中的事件顺序。一般地,控制类接收

35、的消息并不多,而发出的消息比较多,因为它更多地是向其它类委托责任。,注意,不要试图使用所有的符号。从简单的开始,例如,类、关联、属性和继承等概念。在UML中,有些符号仅适用于特殊的场合,只有当需要时才使用。 根据项目所处的开发阶段,用正确的观点来画类图。如果处于分析阶段,应画概念层类图;在设计阶段,应画说明层类图;当考察某个特定的实现技术时,则应画实现层类图。,分析类图,设计类图,行为模型 活动图、时序图、状态图等,时序图,时序图展示了几个对象之间的动态协作关系,主要用来显示对象之间发送消息的顺序,还显示对象之间的交互,即系统执行某一特定时间点所发生的事。,购买饮料时序图,对象,生命线,消息,活动图,活动图用来描述执行工作流程中涉及的活动,展示了连续的活动流,网购活动图(泳道图),用户,仓库管理员,销售员,状态图,状态图是对类描述的补充,它说明该类的对象所有可能的状态以及哪些事件将导致状态的改变。 它是一个类对象所可能经历的所有历程的模型图,ATM状态图,

展开阅读全文
相关资源
猜你喜欢
相关搜索
资源标签

当前位置:首页 > 企业管理 > 管理学资料

本站链接:文库   一言   我酷   合作


客服QQ:2549714901微博号:道客多多官方知乎号:道客多多

经营许可证编号: 粤ICP备2021046453号世界地图

道客多多©版权所有2020-2025营业执照举报