软件工程知识点总结(2):需求分析(一)——用例建模
1 软件项目开发流程:
需求分析→概要设计→详细设计→编码实施→测试→产品提 交→维护
2 系统必须做什么?
获取用户需求,从用户角度考虑,用户需要系统必须完成哪些工作,也就是对目 标系统提出完整、准确、清晰、具体的要求。
提交的主要文档:软件需求规格说明书:以书面形式准确地描述软件需求。
( 结构化需求模型:数据流图、数据字典、状态图)
(面向对象需求模型:用例图、类图、顺序图等)
3 软件需求管理的过程:
(1) 需求确认:需求获取→需求分析→需求规格编写→需求验证
(2) 需求变更
4 需求的五个基本性质:必要的、无歧义的、可测试的、可测量的、可跟踪的
5 需求获取方式:自悟、访谈、小组会、快速建立软件原型
自悟特点:不用与用户交流,但对需求人员的要求太高,一般不现实。
访谈:(1) 正式访谈: 系统分析员将提出一些事先准备好的具体问题。
(2)非正式访谈:分析员将提出一些用户可以自由回答的开放性问题,以 鼓励被访问人员说出自己的想法。
(3)调查表:注意对客户分类:经过仔细考虑写出的书面回答可能比被访 者对问题的口头回答更准确。
(4)现场观察:用一段时间,完整旁观原始系统的使用情况,使用人员,在 此基础上与客户做进一步交流。
条件:(1)系统分析员能够正确提出问题;(2)被访谈人能够准确表达出需 求并被分析员准确捕捉。(3)谨防“完美蠕型”
小组会的优点:开发者与用户不分彼此,齐心协力,密切合作;及时讨论并求精; 有能导出规格说明的具体步骤。
6 快速建立软件原型是最准确、最有效、最强大的需求分析技术。快速原型就是快 速建立起来的旨在演示目标系统主要功能的可运行的程序;构建原型的要点是, 它应该实现用户看得见的功能,省略目标系统的“隐含”功能。
建模: 就是建立模型,通过对客观事物建立一种抽象的方法,用来表征事物并获 得对事物本身的理解,是对事物的一种无歧义的书面描述。
建模原则:现实世界能够映射到模型;模型能够描述现实世界;模型行为能够正 确反映现实世界方法。
最杰出的建模: 地图
7 UML (Unified Modeling Language 统一建模语言)为面向对象软件设计提供统 一的、标准的、可视化的建模语言。适用于描述以用例为驱动的软件设计的全过 程。
RUP(统一过程)是用例驱动的软件开发方法。
UML 不是一种程序设计语言,而是一种可视化的建模语言,比 C++、Java 这样 的程序设计语言抽象层次更高,适用于任何面向对象的程序设计语言。UML 不 是工具或知识库的规格说明,而是一种建模语言规格说明,是一种模型表示的标 准。UML 不是过程,也不是方法,但允许任何一种过程和方法使用它。
UML 视图分类分为三个视图域:结构分类、动态行为、模型管理。
面向对象分析(OOA)构造模型:
8 用例图是外部参与者所能观察到的系统功能的模型图。用例是参与者要实现的最 终目标。用例图还是软件测试人员进行测试的指导。
用例图的组成:参与者(活动者,Actor)、用例(Use Case)、关系(Relationship)
用例图是指由参与者(Actor)、用例(Use Case)以及它们之间的关系构成的 用于描述系统功能的静态视图
(1)用例间关系-泛化(继承) ——参与者之间的泛化:便于权限设置
——用例之间的泛化:子用例和父用例相似,但表现出更特别的行为;子用例将 继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可 以重载它。
父用例通常是抽象的。目的:支持系统的可扩展性、代码复用。
(2)用例间关系-包含(Include)
【箭头指向】:指向分解出来的功能用例。箭头出发的用例为基用例。包含用例 是必选的,如果缺少包含用例,基用例就不完整。
包含关系的代码表现:B 类的对象作为 A 类的数据成员存在——对象的组合
代码复用
包含的两种使用场景:(1)使用包含用例来封装一组跨越多个用例的相似动作, 以便被多个基用例复用。包含关系最典型的应用就是复用。(2)当某用例的事件 流过于复杂时,为了简化用例的描述,我们也可以把某一段事件流抽象成一个被 包含的用例。
(3)用例间关系-扩展 extend
【箭头指向】:指向基础用例。扩展用例是可选的,如果缺少扩展用例,不会影 响到基用例的完整性;扩展用例在一定条件下才会执行,并且其执行不会改变基 用例的行为。
用例图补充:“系统”。系统被看作是一个提供用例的黑盒子。描述该系统功能的 用例置于方框内,代表外部实体的行为置于方框外。
[有/无]条件条件:泛化:( 无 )条件发生、包含:( 无 )条件发生、 扩展:( 有 )条件发生
为 Actor 提供【直接/间接】服务:泛化中的子用例: 提供的是(直接)服务。 扩展用例: 提供的是(直接)服务。包含中的被包含用例: 提供的是(间接) 服务。
9 用例模型建模:
任务:获取需求,建立需求模型(用例模型:绘制用例图和编写用例文档)。
步骤:①确定系统的参与者②确定场景③确定系统用例④确定用例之间的关系⑤ 编写用例描述文档
①确定系统的参与者:参与者是指直接和系统交互的一类事物,参与者主要有 如下三类:
(1) 直接使用系统的人,如 图书管理员,普通读者等(角色);
(2) 与该系统相关的其他系统,如邮件系统;
(3) 自动发生的事件,如时间、温度等自动事件,如:库存管理系统要求每晚零 点执行一个数据汇总操作,此时时间就成为该操作的执行者。
②确定场景:考虑参与者用系统做什么?进一步描述场景。在系统中,按照某 个顺序执行了一系列相关的动作后,即可实现某种功能,把完成这一功能操作的 集合称为场景。一个场景就是描述软件使用者与系统之间的一系列交互活动,系 统具体执行的行为路径,即一次完成的事件流。从个体角度考虑
场景的获取方法:开发者与用户、客户进行交流来获取。
③确定系统用例:用例是对一组场景共同行为的抽象,是参与者最终要实现的 目的。重点在于参与者与系统之间的交互而不是系统内部的活动。
方法:从场景描述,理解系统需求,分析获取系统用例。
用例要点分析:
(1)可观测:用例是参与者与系统的交互,不是系统内部的活动,且一定是参与者主动发起的,最后结果一定要反馈给参与者。习惯说用例止于边界。
(2)结果值:每个用例都会对外界参与者产生一个有价值的结果。
(3)系统执行:结果值由系统所生成
(4)由参与者执行:用例的识别和定义都是从参与者角度出发,要以参与者的 视角获取和定义。
“由参与者执行”的两层含义:
①用例命名使用业务语言而非技术语言
②用例表达用户观点,而不是系统能提供的功能
补充:用例的粒度
用例定义原则:“用例是参与者所要实现的最终目标,并为参与者产生所需要的 价值”。
用例的粒度(用例的大小)可大可小,一般一个系统易控制在 20 个用例左右。 对复杂的系统可以划分为若干个子系统处理。用例是系统级的、抽象的描述,不 是细化的(是做什么,非怎样做)
④确定用例之间的关系:过于复杂的用例需要适当分解,以便分解功能、提高复 用性、可扩展性等。
包含:从多个用例中提取公共部分的功能,单独放到一个用例中,提高复用性。
扩展:将一个基用例中在某种特定情况下才激发的功能单独成为一个用例,以保 持基用例的完整(即一般情况都能处理)。
泛化:用例泛化一般作为抽象用例而存在,为了复用或者扩展而使用。
⑤根据需要可以细化用例
用例文档又称为用例规约或用例描述。用例文档是用于描述用例的文档,每一个 用例对应于一个用例文档。在用例文档中需要用文字的方式描述用例的执行过程, 即执行者与系统的交互过程 。
用例建模包括用例图的绘制和用例文档的编写。用例建模是软件需求分析到最终 实现的第一步,它从用户的角度来描述软件系统的功能,描述人们如何使用软件 系统。
用例描述组成内容:
用例名称:与用例图同,并写相应编号
简要说明/描述:简要描述功能
优先级:标识软件客户对该用例实现状况的期许(一般用 1~5 表示),数字越大, 优先级越高。
参与者(执行者):使用该用例的人或系统等。
前置条件:在用例启动时参与者和系统应置于什么状态。这个状态必须是系统可 以识别到的。如“参与者已成功登录”,不能是“参与者已打开电脑”。
后置条件:用例结束时系统应置于什么状态。即用例结束时的系统状态或持久数 据情况。
事件流:(文档中最重要的部分!!)描述如何通过交互传递由用例所承诺的价 值; 它是一个被严格流程化规范化的故事:用例开始(入口)——{用户发起请求—系 统校验请求—系统处理—系统反馈}——用例结束
事件流:
(1)基本流(没有异常/分支):做 835 汽车,胜利桥东下车;确认 615 汽车还 运营,坐 615 汽车到轨道交通 2 号线大北门站;从地铁出来后在门口吃点东西。
(2)扩展流(用户做出了另外的选择):如果不饿不想吃东西,也可以旁边星 巴克做一会儿。
(3)异常流(系统没有像预期那样反馈用户数据):如果 615 路汽车停运了, 就直接打车
基本事件流:没有任何分支、没有如果,只有顺序描述,预期会成功的路线。
①基本流必须完整,不能引用其他扩展流;
②使用主动语句,以执行者或者系统为主语;
③不涉及到界面细节;
④不使用专业术语,而是用业务语言
事件流描述示例:
1、在文本框中输入账号 管理员输入账号
2、用户点击提交按钮 用户向系统请求提交表单
3、系统将销售记录生成 SQL 并执行,写入数据库 系统记录销售
10 活动图是动态行为图,用于描述系统的工作流程或一个用例的内部行为。
活动图的作用:(1)描述系统业务工作过程(涉及多个用例) (2)对用例规约 建模(一个用例)(3) 对复杂算法建模
活动图的组成元素:1、初始节点和终点 2、活动节点 3、转换 4、决策与分支、 合并 5、分岔与汇合
1、初始节点和终点:初始节点表示活动的起点,用一个实心圆表示;终点表示 活动的终结点,用一个圆圈内加一个实心圆来表示活动终点.在活动图中,可能 包含多个活动终点。
2、活动节点:用来表示一个活动,一个活动表示一个或多个动作的集合。
活动:活动可分解,不是原子的,工作的完成需要一定的时间。 动作是原子的,不能被分解。如上“表达式”。
3、转换:当一个活动结束时,活动控制流就会传递给下一个活动节点,在活动 图中称之为“转换”,用一条带箭头的直线(或折线)来表示转换。
4、决策与分支、合并(类似程序流程图的判断框)
决策与分支:用菱形表示的,一个或多个离开转换。每个离开转换上都会有一个 监护条件,用来表示满足什么条件的时候执行该转换。
合并:指两条或多条控制路径汇合的情况。用菱形符号表示。
5、分岔与汇合 分岔:表示一个控制流被两个或多个控制流代替,经过分岔后,这些控制流是并 发进行的。
汇合与分岔相反,表示两个或多个控制流被一个控制流代替。
合并的各路分支选择哪条由决策条件决定,不同的条件会选择不同的决策分支, 分支之间是互斥的;
汇合的两个分支相当是两个线程,线程都要完成才能汇合,其所有分支必须完成 才行,没有条件。
活动图的其他组成元素: