软件需求分析与建模-(1)

“图书销售：售书处理”用例分析
售书员
销售图书
售书处理
《包含》
收书款
浏览图书销售信息
打印图书销售报表
收款员
销售图书的过程用例图
图书销售管理::销售图书::售书处理
编号：03-05-01 参与者：售书员，收款员 所在包：图书销售管理::销售图书 说明：售书员在“图书销售管理”中的“销售图书”中选择“售书
概念类主要来源于业务领域中的客观实体、 系统与外界的交互处理和对系统要素的控 制三个方面。
概念类面向用户需求，一般不考虑性能要 求，具有突出业务领域、突出概念性及大 粒度的特征。
概念类的类型
UML把概念类分为实体类、边界类和控制 类三种类型，并表示成为下图所示的两种 形式。
形式1：
形式2：
实体类
实体
（2） 概念性： 第一，面向业务领域，反映业务概念； 第二，在较宏观和抽象的层次进行分析工
作，一般不过多涉及具体细节； 第三，不涉及系统的实现环境。
（3） 一致性:软件需求所确定逻辑模型应该 具有逻辑一致性，它要纠正需求模型中存在 的冗余及错误。
软件需求的主要工作
（1）用例分析 用例分析包括提取用例涉及的概念类，确
例如，“售书界面”用来抽象地描述售 书员与书店系统的交互处理，见图。
售书员
售书界面
控制类（Control Class）是表示系统对 其它对象实施协调处理、逻辑运算的抽象 要素。
例如，在书店系统中，“出售图书”就属 于控制类，见下图。
售书
售书界面
出售图书
架存图书 售出图书
第一步： 用例分析
1．概述 用例分析是指从概念层次上对一个 用例的分析及分析的结果。 用例分析的结果有两种图： 1）用例分析类图表示用例概念类结 构； 2）用例分析协作图表示各概念类之 间动态交互信息。
边界类 边界
控制类 控制
书目
书单
书款
实体类（Entity Class）是系统表示客观实体 的抽象要素。
例如，书店中的“书目”、 “书单”、“书 款”等。
实体类一般对应着在业务领域中的客观事物， 或者是具有较稳定信息内容的系统元素。
实体类来源于业务分析中所确定的实体，实 体字典是确定实体类的依据。
边界类（Boundary Class）是描述系统 与参与者之间交互的抽象要素。边界类只 是对系统与参与者之间交互的抽象建模， 并不表示交互的具体内容及交互界面的具 体形式。
2 属性的命名
（1） 使用名词或带定语的名词。像“姓 名”，“学生姓名”，“型号”，“产品 型号”，“商品条形码”等。
（2） 尽量使用问题域中规范、通用的词 语，避免使用没有明确含义或自定义的词 语。
2） 属性的类型 属性的类型是指属性值的类型，一般有 数字型、字符型、逻辑型、日期型等。在 软件需求阶段一般不需要确定属性的类型。
在软件需求分析中，通过对需求模型中 的每一个用例的分析，得到了对应于需 求模型中用例的用例分析结果。用例分 析与用例之间存在一一对应的跟踪关系， 可以从用例分析追踪到用例（见下图）。
需求模型 用例
《跟踪》
逻辑模型
用例分析
用例分析类图 用例分析协作图
用例分析类图（UseCase Analysis Class Diagram）用来描述一个用例中 的概念类之间的关系所呈现出的静态 结构。
售书员与系统的交互界面
存放“查询”、“浏览”产生的“出库 单信息” 接收售书员的查询条件
把出库单信息从数据库中删除
把所有出库单显示给售书员
根据输入的表单编号以详细表单的形式 显示相应出库单 以详细表单的形式显示选定的出库单
售书员与系统的交互界面
售书员与子系统的交互界面
售书员与子系统的交互界面
C-2-02 C-1-03 C-3-06 C-3-07 C-3-08 C-3-09
C-3-10 C-2-03 C-2-04 C-2-05
查询架存界面 删除架存界面 打印架存界面 书库图书 上架图书信息 上架图书 架存图书 接收上架信息 图书上架
查询上架图书
售书员与子系统的交互界面 售书员与子系统的交互界面
售书员与子系统的交互界面 库存中的图书的基本信息 待上架图书的基本信息
每次上架图书的基本信息 架存中的图书的基本信息
者持书单又回到售书员处，把已交款后的书单交给售书员。 售书员扫描书单号，并按“售出图书”键。 ** 售书员给图书上盖章，并把图书交给读者，售书结束。
1、 提取概念类 边界类：售书界面 实体类：书目，架存图书，待售图书，售出图书 控制类：产生待售图书，开书单，出售书单
售书界面 产生待售图书 开书单 出售图书 书目 架存图书 待售图书 售出图书
7:书单
:售书员
图书信息
:售书界面
:产生待售图书 :待售图书
:开书单
4:图书信息
8:待售图书
10:售出图书
:打印进程
9:减架存数量
:架存图书
:出售图书
:售出图书
图 “售书处理”的用例分析交互图
第二步：概念类分析
1．属性的概念 一般讲，属性表示实体的特性或特征。 在OO方法中，属性用来表示对象的静 态特性。 例如，对象“人”的属性有：姓名、 性别、出生年月、家庭住址、电话、体 重、身高、血型、爱好、职业、毕业院 校、专业等。
用例分析类图抽象地描述各概念类 之间的关系，不涉及过多的细节。
下图是对 “售书处理”用例进行分 析所得到的用例分析类图。
“售书处理”的用例分析类图
“售书处理”的用例分析类图 书目
Fra Baidu bibliotek
售书员
售书界面
产生待售图书 待售图书
开书单
打印进程
架存图书
出售图书
售出图书
用例分析协作图描述为了 实现用例的过程，参与者与系统 以及系统中的各概念类之间所交 互的消息。
接收待上架图书的书号和册数 提交上架信息到数据库中，同时增 加数据库中的架存数目 按查询条件把满足条件的上架图书 信息显示给售书员
C-2-06 C-2-07 C-2-08 C-1-04 C-1-05 C-1-06 C-1-07 C-3-11 C-3-12
C-3-13
查询架存图书 打印架存报表
按查询条件把满足条件的架存图书 信息显示给售书员
把盘架信息提交到打印机进行打印
C-3-14
C-3-15 C-3-16 C-2-09 C-1-08 C-1-09 C-3-17 C-3-18 C-3-19
C-3-20
清空盘架单 盘架查询界面 盘架单信息 接收盘架查询 浏览盘架单 显示盘架单 定位盘架单
删除盘架单 报损界面 报损图书信息
把盘架单屏幕清空，以便售书员重 新输入数据 售书员与系统的交互界面
图 “售书处理”的概念类
2、 用例分析类图
“售书处理”的用例分析类图 书目
售书员
售书界面
产生待售图书 待售图书
开书单
打印进程
架存图书
出售图书
售出图书
图 “售书处理”的用例分析类图
3、 用例分析交互图
“售书处理”的用例分析交互图
：书目 3:取书目信息
1:书号及册数 2:书号及册数
5:待售图书
6:待售图书
图书的基本信息
出库图书
出库图书的基本信息
出库图书信息
待出库图书的基本信息
条目编号 C-2-01 C-3-01 C-3-02 C-3-03
C-3-04 C-3-05 Q-1-01 C-1-01 C-1-02
查询出库界面 出库单信息 接收出库查询 删除出库单 浏览出库单 定位出库单
显示出库单 图书销售界面 图书上架界面 查询上架界面
概念类字典由概念类目录和概念类条目两 部分构成。
1．概念类目录
书店信息销售管理系统概念类目录见表6-1。 目录中列出了书店信息销售管理系统逻辑模型中 的概念类。概念类条目编号的规则是： 第1位表示该概念类的顶层逻辑包，用字母表示。 其中，A表示计划订购，B表示书库管理，C表示 图书销售，D表示事务处理，Q表示公用概念类。 第2位是概念类的类型。其中，1表示实体类，2 表示边界类，3表示控制类。 后两位是顺序号。例如，C-2-01表示“售书界面” 属于“图书销售”逻辑包中界面类的第一个概念 类。
把架存信息提交到打印机进行打印
删除架存图书
把架存信息从数据库中删除
盘架界面
售书员与系统的交互界面
盘架图书信息
待盘架的图书的基本信息
盘架图书
每次盘架图书的基本信息
接收待盘架图书 信息 保存盘架单
接收待盘架图书的书号、数量 保存盘架单到数据库中
提交盘架单 打印盘架单
提交盘架单到数据库中，信息一但 提交就不能进行修改
概念类名
表1 概念类字典目录
说
明
出库单界面
售书员与系统的交互界面
接收出库图书信 息
保存出库单
接收待出库图书的书号和册数 保存出库单到数据库中
提交出库单 打印出库单
提交出库单到数据库中，信息一但提 交就不能进行修改
把出库单信息提交到打印机进行打印
清空出库单 书目
把出库单屏幕清空，以便售书员重新 输入数据
软件需求分析
软件需求的含义及特点
软件需求（Software Requirements）是在 业务需求分析和用户需求分析的基础上，从抽 象的概念层次上确定系统的要素、构成和结构， 得出系统的逻辑模型，并为系统设计提供依据。
特点：
（1） 内在性:站在系统内部的角度，分析软 件系统的要素、构成和结构。
如果一个类中因属性项目过多，使得类过于庞大，可 以根据这些属性的相关性，把一个类分成多个类，以 简化类的规模。
几个概念的属性：
“书目”：书号、书名、作者、 出版社、单价、出版日期、图书类 别。
“售书界面”：图书书号，图书 信息。
“产生待售图书”：没有属性。
第四步、概念类字典化
概 念 类 字 典 （ Conception Class Dictionary）用来记录软件需求中提取的概 念类，并对概念类进行说明。
② 边界类。可以根据边界类所承担的交互信息项 目来确定边界类的属性。例如，对于“收款界面” 边界类，输入的信息是“待售书号”和“书款信 息”，输出的信息是“收款图书信息”和“已收 款提示”，我们就可以把这四项信息项目作为 “收款界面”的属性。
③ 控制类。控制类一般没有属性。
（6） 属性和类的转化。 如果一个类的某一属性项过于复杂，说明这个属性包 容的内涵很丰富，属性本身就表示一个复杂的事物实 体，可以把这个属性作为一个类来看待。
通过整个消息的传递来实 现用例的过程。下图是对应于上 图的用例分析协作图。
“售书处理”的用例分析协作图
“售书处理”的用例分析协作图
:书目 3:取书目信息
1:书号及册数 2:书号及册数
5:待售图书
6:待售图书
7:书单
:售书员
图书信息
:售书界面
:产生待售图书
:待售图书
:开书单
4:图书信息
8:待售图书
10:售出图书
处理”选项将启动此项过程。 1．售书员把读者所要购买图书的“书号”用条形码扫描仪输入
进系统。 系统在屏幕上给出该图书的“书名”、“作者”、“出版社”、
“单价”、“出版日期”、“架存册数”等信息； 2．售书员输入图书册数。 如果图书册数大于当前图书架存数，系统在屏幕上给出提示，并
告诉修改册数。 ** 重复前两步，直到把该读者所要购买的所有图书输入系统。 3．系统打印出该读者的三联购书书单。 **读者持书单到收款台交款。 4．收款员扫描书单号，收款员界面显示该读者购书信息。 5．收款员把读者给的书款数额输入系统，并按收款确认键。 ** 收款员给书单上盖章，并自己留存一联，其它两联给读者。读
定概念类之间的关系，以及绘制用例分析类 图和用例分析交互图三项工作。 （2）概念类分析
概念类分析（Conception Class Analysis） 是对所提取的各概念类的职责、属性、关系 和特殊需求所进行的分析。
概念类（Conception Class）是在概念 层次上，对系统的抽象要素的一种称谓。
:打印进程
9:减架存数量
:架存图书
:出售图书
:售出图书
用例分析一般需要经过三个步骤：
●第一步，提取用例的概念类。包括实 体类，边界类，控制类。
●第二步，确定用例中概念类之间的关 系，并绘制用例分析类图。概念类之间有 关联关系、泛化关系和依赖关系，其中主 要是关联关系。
●第三步，分析参与者与用例所交互的 信息，以及用例中各概念类之间所交互的 信息，并得出用例分析交互图。
3、属性分析
属性分析的一般途径： （1） 从常理上看，概念类所表示的事 物有哪些静态特性； （2） 在业务领域中概念类所具有的属 性； （3） 系统要求概念类应具有的属性； （4） 概念类需要记录和保存的信息；
（5） 不同类型概念类的属性。
① 实体类。实体类属性可以直接根据事物本身的 性质来确定。例如，对于“图书”属性，就可以 通过对图书性质的分析来确定。