UML在需求分析阶段的应用
合集下载
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
法实现或暂时无法实现的。
• 对于现阶段无法实现的或暂时无法实现的需求需要向用户解释清楚为 什么不能实现，并尽量给出一些变通的方案。
需求分析结果
序 号
用户需求
软件 功能 可以 需求 需求 实现
输入数据的过程尽量简洁，按键次数越少越好，最好
1
是自动实现或“一键”完成
否
--
--
2
能够处理吊运过程中的暂停情况
3
输入数据错误，可以进行修改
4
记录每次称量物料的重量和时间
5
记录每次称量物料的名称和操作工人
6百度文库
按月统计每种物料的重量
7
按月统计每个操作工人吊运货物的重量
是
是
否
否
--
--
是
是
是
是
是
是
是
是
是
是
是
是
需求分析结果（续）
序 号
用户需求
软件 功能 可以 需求 需求 实现
8
称重数据能够上传到数据库服务器中
是
是
是
在实际的系统开发过程中，用户的需求往往是很难捕捉 的，而且经常变动。甚至连用户自己也常常无法准确描述 自己的需求，他们的需求往往在看到软件产品后才逐步的 清晰起来。
因此在需求分析阶段更应该采用好的需求分析方法和技 术，以保证得到高质量的用户需求。
需求分析阶段
UML 的用例技术是一项得到业界公认的需求获取和 分析技术，结合适当的方法可以很好地获取和描述用 户的功能需求。
• 对 AutoWeight 系统的所有用例进行分析，结合前 面的用户需求可以找出下面的名词、动词和动词词 组。
• 名词可能成为领域模型中的类或类中的属性，动词和 动词词组可能成为类中的方法或类间的关联。
名词 & 动词
概念类分析
• “ 操作工人”：是一个候选的概念类，在物料的称重数据记录 中需要知道天车的操作工人是谁。
UML 在软件开发过程中的应用
一个软件开发过程包括多个阶段。 不同的软件开发过程划分软件开发阶段的方法各不相
同，各阶段的名称也不相同。 一般的软件开发过程都应该包括需求分析、系统设
计、系统实现、系统集成和交付、系统测试等几个阶 段。
需求分析阶段
需求分析阶段是开发过程中第一重要的阶段，如果不能准 确的理解客户需要什么，那么就无法构造出正确的系统。 如果不了解客户的领域及客户需要解决的问题，那么所有 的用例分析都无济于事。
在需求分析阶段还需要使用概念类图来建立领域模 型，使用顺序图来描述系统与外界的交互过程。在此 基础上明确系统的边界，确定系统的接口。
设计阶段
主要应用 UML 的设计类图来描述系统的静态结构。 使用合作图来描述系统中对象之间的交互关系。 使用状态图来描述单个对象的状态变化情况。
如果需要数据库设计，可以选择专门的设计工具来完 成——数据建模。
– 容量 : 系统中需要保存对象的数量。在 AutoWeight 系统中 , 每台计 算机最多管理 6 台天车 , 每台天车每天最多工作 50 次。这样系统中 每天最多需要保存 300 条数据 ,
– 每年需要保存的数据不超过 10 万条。
– 检索机制 : 为了便于检索需要给每一条数据一个唯一的编号。
系统设备连接图
称重仪表
数传电台 计算机
数据库服务器
操作工人
传感器
打印机
工作流程与原理
• 称重仪表负责采集物料的重量数据，再由操作员把物料编 号等信息输入仪表，并连同重量数据一起通过无线传输的 方式传送给地面负责接收数据的计算机。
• 计算机中有专用的软件系统，它负责接收和保存称重仪表 发送来的数据；能够打印每天的称重数据记录；能够按照 时间和物料的种类进行统计分析，打印报表。
– “ 仪表”—把称重数据发送给系统 – “ 车间主任”—查看物料的各种分类统计重量 – “ 操作员”—查看物料的称重记录 , 打印各种报表 – “ 数据库服务器”—得到称重数据
用例
• 系统用例
– 记录称重数据 – 打印称重记录 – 按照种类统计物料重量 – 按照操作员统计物料重量
用例模型图
执行者描述
实现阶段
主要应用 UML 的实现类图来描述系统的静态结构。 使用活动图、合作图来描述类中某些复杂方法的实
现。
集成阶段
在系统的集成阶段使用 UML 的构件图，根据构件图 正确的把每个程序单元集成到系统中。
在系统的交付阶段使用 UML 的配置图，根据配置图 把系统的硬件和软件部署到实际的用户环境中。
发送称重数据。
用例描述
• P107 图 7.5
非功能性需求分析—称重数据能够长期保存
系统中的重量数据以对象形式存在 , 数据的长期保存称为永久性机 制 。一般在系统实现 时 , 使用数据库来保 存 系统中的对象。
AutoWeight 系统的永久性机制主要包括以下几个方面 :
– 粒度 : 每个 对象 的 大小 。在 AutoWeight 系统中一 条数据 大约 是 200 个字节。
• 系统开发人员。负责开发 AutoWeight 软件系统的项目组 成员。
需求
• 操作工人
– 输入数据的过程尽量简洁，按键次数越少越好，最好是自动 实现或“一键”完成
– 能够处理吊运过程中的暂停情况 – 输入数据错误，可以进行修改
• 操作员
– 显示每次称量物料的记录，不能出现数据传输错误或丢失数 据的情况
天车的工作过程（续）
• 上面是一个基本的天车工作 流程，在天车的工作过程中 可能还 会 出现一些 特殊 情 况。
– 比如，在调运物料的过程 中，因为各种原因需要暂 时放下物料，天车去做其 它工作，等其它工作完成 后，再继续吊运物料。
天车开到 指定位置 吊装物料 吊起物料 天车开到 指定位置 放下物料 天车回到 初始位置
9
系统能够可靠长期运行
是
否
是
10
称重数据能够长期保存
是
否
是
11
显示每次称量物料的记录，不能出现数据传输错误或 丢失数据情况
部分是
否
部分是
12
打印各种统计报表
是
是
是
13
系统能够方便地启动和运行，维护简单。
是
否
是
14
系统有良好的可扩展性
是
否
是
提供模拟仪表，能够产生数据。方便系统的开发、
15
调试和安装。
是
Auto Weight 系统
AutoWeight 系统是一个自动称重系统。它能够对移 动天车运送的物料进行称重，然后把称量的重量和物 料的编号等信息传送给计算机，并由相应的软件系统 进行必要的计算、统计和报表打印。
AutoWeight 系统主要用于使用天车的工矿企业，它 能够对企业中的天车称重数据进行采集和处理。在一 般的工矿企业中，大而重的原料、半成品或产品往往 使用天车在车间内进行搬运和移动。
称重仪表的工作过程
– 通过传感器得到天车吊运物料的重量数据 – 重量数据显示到称重仪表屏幕上 – 仪表提供串行输出接口，可以把重量数据发送出去，数据的传输格
式符合 RS232 标准
• 称重仪表显示的是实时重量数据，在天车吊起、放下和吊运过程 中，由于受到重力加速度的影响，同一物料的重量在整个的吊运 过程中是不同的，例如当物料被吊起时其重量往往比物料被放下 时的重量大。因此对于同一物料的吊运，一般选择平稳吊运时的 重量作为物料的重量。
需求分析与描述
需求分析
• 首先需要对用户提出的需求进行分析，以此来确定其中要 实现系统的功能。然后进一步同用户进行更加深入的交 流，确定：
– 哪些需求是功能性需求，哪些需求是非功能性需求。 – 哪些需求属于软件系统的需求，哪些需求不属于软件系统
的需求。 – 明确哪些需求是现阶段可以实现的，哪些需求是现阶段无
操作员 : 负责软件管理和维护的人。 车间主任 : 负责查看系统的各种统计信息。 数据库服务器 : 局域网中的数据库服务器。 物理仪表 : 实际系统中的称重仪表 , 负责向计算机传
送称重数据。 模拟仪表 : 向计算机发送模拟的称重数据。 仪表 : 是物理仪表和模拟仪表的泛化 , 负责向计算机
非功能性需求分析—称重数据能够长期保存
– 数据更新 : 系统中的数据需要长期保存 , 每次只需增加数 据 , 不需要修改和删除。
– 可靠性 : 要求数据能够可靠地存储。
• 在此基础上 , 可以进行访问频率的分析。包括数据的创 建、读取、更新和删除的频率。这些分析是确定选择数据 存储工具的依据。
领域模型分析
• 操作工人。负责操作天车的技术工人。操作工人的主要工作 为操作天车，包括吊运物料，使用仪表输入物料编号等与物 料相关的数据。这些数据与重量数据一起通过称重仪表发送 给系统。
• 车间主任。一个车间生产的负责人，负责查看与系统相关的 工作，例如查看当日的称重记录，查看统计报表等。
• 操作员。负责使用计算机、打印机和 AutoWeight 软件系 统，并负责软件系统的运行和维护及打印报表。
• 为了打印报表方便，配备一台打印机。
天车的工作过程
• 在一般的工矿企业中，每台天车配备一名操作工人，负责开 动天车，搬运物料。每个车间有专门的调度人员，它们负责 指挥天车的工作。
• 天车搬运物料的工作过程如下：
– 天车操作工人把天车开到指定的地点 – 吊装物料 – 天车吊起物料 – 天车吊运物料运行 – 到达指定的地点，放下物料 – 天车回到指定地点，准备下一次工作
– 打印各种统计报表 – 系统能够方便地启动和运行，维护简单
需求（续）
• 车间主任
– 记录每次称量物料的重量和时间 – 记录每次称量物料的名称和操作工人 – 按月统计每种物料的重量 – 按月统计每个操作工人吊运货物的重量 – 称重数据能够上传到数据库服务器中 – 系统能够长期可靠的运行 – 称重数据能够长期保存
领域模型分析
在用例分析的同时，还需要进行领域分析，建立领域模型、 绘制系统顺序图，进一步描述系统的静态结构、行为和执 行的结果。
这里所说的领域指的是用户的业务领域，也就是需要解决 问题的领域，对领域知识的掌握与理解将直接关系到系统 开发的成败。
领域概念
• 领域概念是用来描述现实世界中某个问题的一些名词 和术语。建立领域模型的第一步是找出这些描述问题 的概念和术语。
是
是
用例模型
• 执行者？ • 用例？ • 系统边界？
执行者
• 下列涉众哪些是执行者？
– 操作工人 – 操作员 – 车间主任 – 开发人员
执行者
• 下列涉众哪些是执行者？
– 操作工人 – 操作员 – 车间主任 – 开发人员 – 称重仪表
• 物理仪表 • 模拟仪表
– 数据库服务器？？
用例
• 每个执行者的目标：
• 有的仪表允许操作工人在吊运过程中输入各种命令和数据，并能 够把输入的数据和重量数据同时发送出来。
用户需求
用户需求——涉众
• 操作工人。负责操作天车的技术工人。操作工人的主要工作 为操作天车，包括吊运物料，使用仪表输入物料编号等与物 料相关的数据。这些数据与重量数据一起通过称重仪表发送 给系统。
• 车间主任。一个车间生产的负责人，负责查看与系统相关的 工作，例如查看当日的称重记录，查看统计报表等。
• 操作员。负责使用计算机、打印机和 AutoWeight 软件系 统，并负责软件系统的运行和维护及打印报表。
• 系统开发人员。负责开发 AutoWeight 软件系统的项目组 成员。
用户需求——涉众
• 该系统还能够提供一个网络系统的接口，可以通过局域网 络把接收的数据上传到局域网中的数据库服务器中。
工作流程与原理（续）
• 系统的数据传输使用无线传输方式，使用数传电台来 传输数字信号。计算机通过串口来接收数据，数据传 输格式符合 RS232 标准。
• 如果网络条件许可，计算机可通过网络与局域网中的 数据库服务器相连。
实例分析
UML 在需求分析阶 段的应用
段的应用
课程内容
UML 在软件开发过程中的应用 Auto Weight 系统简介 用户需求 需求分析与描述 领域模型分析 工作流程分析
UML 在软件开发过程中的应用
在进行系统设计前，开发人员必须首先要充分理解所 要解决的问题，这就需要进行专门的需求分析。在进 行了需求分析之后，还必须进一步将分析产品转化为 设计产品，然后再根据设计产品进行实际的编制代码 工作，这些编制后的代码在经过必要的测试和详细的 部署之后，最终形成需要的目标系统。
测试阶段
在软件开发的不同阶段都需要进行测试。一般情况主 要强调三个点上的软件测试：单元测试、集成测试、 系统测试。
– 单元测试主要是根据系统的实现类图来测试已经实现 的程序单元。
– 集成测试主要根据系统的设计类图和构件图测试类和 包的接口。
– 系统测试主要是根据系统的用例图来测试系统是否正 确完成用户的要求。
• “ 输入数据”：不是一个候选的概念类，操作工人在仪表上输 入的数据，包括操作工人编号和物料的编号。这两个编号应 该是其它类的属性。
• 对于现阶段无法实现的或暂时无法实现的需求需要向用户解释清楚为 什么不能实现，并尽量给出一些变通的方案。
需求分析结果
序 号
用户需求
软件 功能 可以 需求 需求 实现
输入数据的过程尽量简洁，按键次数越少越好，最好
1
是自动实现或“一键”完成
否
--
--
2
能够处理吊运过程中的暂停情况
3
输入数据错误，可以进行修改
4
记录每次称量物料的重量和时间
5
记录每次称量物料的名称和操作工人
6百度文库
按月统计每种物料的重量
7
按月统计每个操作工人吊运货物的重量
是
是
否
否
--
--
是
是
是
是
是
是
是
是
是
是
是
是
需求分析结果（续）
序 号
用户需求
软件 功能 可以 需求 需求 实现
8
称重数据能够上传到数据库服务器中
是
是
是
在实际的系统开发过程中，用户的需求往往是很难捕捉 的，而且经常变动。甚至连用户自己也常常无法准确描述 自己的需求，他们的需求往往在看到软件产品后才逐步的 清晰起来。
因此在需求分析阶段更应该采用好的需求分析方法和技 术，以保证得到高质量的用户需求。
需求分析阶段
UML 的用例技术是一项得到业界公认的需求获取和 分析技术，结合适当的方法可以很好地获取和描述用 户的功能需求。
• 对 AutoWeight 系统的所有用例进行分析，结合前 面的用户需求可以找出下面的名词、动词和动词词 组。
• 名词可能成为领域模型中的类或类中的属性，动词和 动词词组可能成为类中的方法或类间的关联。
名词 & 动词
概念类分析
• “ 操作工人”：是一个候选的概念类，在物料的称重数据记录 中需要知道天车的操作工人是谁。
UML 在软件开发过程中的应用
一个软件开发过程包括多个阶段。 不同的软件开发过程划分软件开发阶段的方法各不相
同，各阶段的名称也不相同。 一般的软件开发过程都应该包括需求分析、系统设
计、系统实现、系统集成和交付、系统测试等几个阶 段。
需求分析阶段
需求分析阶段是开发过程中第一重要的阶段，如果不能准 确的理解客户需要什么，那么就无法构造出正确的系统。 如果不了解客户的领域及客户需要解决的问题，那么所有 的用例分析都无济于事。
在需求分析阶段还需要使用概念类图来建立领域模 型，使用顺序图来描述系统与外界的交互过程。在此 基础上明确系统的边界，确定系统的接口。
设计阶段
主要应用 UML 的设计类图来描述系统的静态结构。 使用合作图来描述系统中对象之间的交互关系。 使用状态图来描述单个对象的状态变化情况。
如果需要数据库设计，可以选择专门的设计工具来完 成——数据建模。
– 容量 : 系统中需要保存对象的数量。在 AutoWeight 系统中 , 每台计 算机最多管理 6 台天车 , 每台天车每天最多工作 50 次。这样系统中 每天最多需要保存 300 条数据 ,
– 每年需要保存的数据不超过 10 万条。
– 检索机制 : 为了便于检索需要给每一条数据一个唯一的编号。
系统设备连接图
称重仪表
数传电台 计算机
数据库服务器
操作工人
传感器
打印机
工作流程与原理
• 称重仪表负责采集物料的重量数据，再由操作员把物料编 号等信息输入仪表，并连同重量数据一起通过无线传输的 方式传送给地面负责接收数据的计算机。
• 计算机中有专用的软件系统，它负责接收和保存称重仪表 发送来的数据；能够打印每天的称重数据记录；能够按照 时间和物料的种类进行统计分析，打印报表。
– “ 仪表”—把称重数据发送给系统 – “ 车间主任”—查看物料的各种分类统计重量 – “ 操作员”—查看物料的称重记录 , 打印各种报表 – “ 数据库服务器”—得到称重数据
用例
• 系统用例
– 记录称重数据 – 打印称重记录 – 按照种类统计物料重量 – 按照操作员统计物料重量
用例模型图
执行者描述
实现阶段
主要应用 UML 的实现类图来描述系统的静态结构。 使用活动图、合作图来描述类中某些复杂方法的实
现。
集成阶段
在系统的集成阶段使用 UML 的构件图，根据构件图 正确的把每个程序单元集成到系统中。
在系统的交付阶段使用 UML 的配置图，根据配置图 把系统的硬件和软件部署到实际的用户环境中。
发送称重数据。
用例描述
• P107 图 7.5
非功能性需求分析—称重数据能够长期保存
系统中的重量数据以对象形式存在 , 数据的长期保存称为永久性机 制 。一般在系统实现 时 , 使用数据库来保 存 系统中的对象。
AutoWeight 系统的永久性机制主要包括以下几个方面 :
– 粒度 : 每个 对象 的 大小 。在 AutoWeight 系统中一 条数据 大约 是 200 个字节。
• 系统开发人员。负责开发 AutoWeight 软件系统的项目组 成员。
需求
• 操作工人
– 输入数据的过程尽量简洁，按键次数越少越好，最好是自动 实现或“一键”完成
– 能够处理吊运过程中的暂停情况 – 输入数据错误，可以进行修改
• 操作员
– 显示每次称量物料的记录，不能出现数据传输错误或丢失数 据的情况
天车的工作过程（续）
• 上面是一个基本的天车工作 流程，在天车的工作过程中 可能还 会 出现一些 特殊 情 况。
– 比如，在调运物料的过程 中，因为各种原因需要暂 时放下物料，天车去做其 它工作，等其它工作完成 后，再继续吊运物料。
天车开到 指定位置 吊装物料 吊起物料 天车开到 指定位置 放下物料 天车回到 初始位置
9
系统能够可靠长期运行
是
否
是
10
称重数据能够长期保存
是
否
是
11
显示每次称量物料的记录，不能出现数据传输错误或 丢失数据情况
部分是
否
部分是
12
打印各种统计报表
是
是
是
13
系统能够方便地启动和运行，维护简单。
是
否
是
14
系统有良好的可扩展性
是
否
是
提供模拟仪表，能够产生数据。方便系统的开发、
15
调试和安装。
是
Auto Weight 系统
AutoWeight 系统是一个自动称重系统。它能够对移 动天车运送的物料进行称重，然后把称量的重量和物 料的编号等信息传送给计算机，并由相应的软件系统 进行必要的计算、统计和报表打印。
AutoWeight 系统主要用于使用天车的工矿企业，它 能够对企业中的天车称重数据进行采集和处理。在一 般的工矿企业中，大而重的原料、半成品或产品往往 使用天车在车间内进行搬运和移动。
称重仪表的工作过程
– 通过传感器得到天车吊运物料的重量数据 – 重量数据显示到称重仪表屏幕上 – 仪表提供串行输出接口，可以把重量数据发送出去，数据的传输格
式符合 RS232 标准
• 称重仪表显示的是实时重量数据，在天车吊起、放下和吊运过程 中，由于受到重力加速度的影响，同一物料的重量在整个的吊运 过程中是不同的，例如当物料被吊起时其重量往往比物料被放下 时的重量大。因此对于同一物料的吊运，一般选择平稳吊运时的 重量作为物料的重量。
需求分析与描述
需求分析
• 首先需要对用户提出的需求进行分析，以此来确定其中要 实现系统的功能。然后进一步同用户进行更加深入的交 流，确定：
– 哪些需求是功能性需求，哪些需求是非功能性需求。 – 哪些需求属于软件系统的需求，哪些需求不属于软件系统
的需求。 – 明确哪些需求是现阶段可以实现的，哪些需求是现阶段无
操作员 : 负责软件管理和维护的人。 车间主任 : 负责查看系统的各种统计信息。 数据库服务器 : 局域网中的数据库服务器。 物理仪表 : 实际系统中的称重仪表 , 负责向计算机传
送称重数据。 模拟仪表 : 向计算机发送模拟的称重数据。 仪表 : 是物理仪表和模拟仪表的泛化 , 负责向计算机
非功能性需求分析—称重数据能够长期保存
– 数据更新 : 系统中的数据需要长期保存 , 每次只需增加数 据 , 不需要修改和删除。
– 可靠性 : 要求数据能够可靠地存储。
• 在此基础上 , 可以进行访问频率的分析。包括数据的创 建、读取、更新和删除的频率。这些分析是确定选择数据 存储工具的依据。
领域模型分析
• 操作工人。负责操作天车的技术工人。操作工人的主要工作 为操作天车，包括吊运物料，使用仪表输入物料编号等与物 料相关的数据。这些数据与重量数据一起通过称重仪表发送 给系统。
• 车间主任。一个车间生产的负责人，负责查看与系统相关的 工作，例如查看当日的称重记录，查看统计报表等。
• 操作员。负责使用计算机、打印机和 AutoWeight 软件系 统，并负责软件系统的运行和维护及打印报表。
• 为了打印报表方便，配备一台打印机。
天车的工作过程
• 在一般的工矿企业中，每台天车配备一名操作工人，负责开 动天车，搬运物料。每个车间有专门的调度人员，它们负责 指挥天车的工作。
• 天车搬运物料的工作过程如下：
– 天车操作工人把天车开到指定的地点 – 吊装物料 – 天车吊起物料 – 天车吊运物料运行 – 到达指定的地点，放下物料 – 天车回到指定地点，准备下一次工作
– 打印各种统计报表 – 系统能够方便地启动和运行，维护简单
需求（续）
• 车间主任
– 记录每次称量物料的重量和时间 – 记录每次称量物料的名称和操作工人 – 按月统计每种物料的重量 – 按月统计每个操作工人吊运货物的重量 – 称重数据能够上传到数据库服务器中 – 系统能够长期可靠的运行 – 称重数据能够长期保存
领域模型分析
在用例分析的同时，还需要进行领域分析，建立领域模型、 绘制系统顺序图，进一步描述系统的静态结构、行为和执 行的结果。
这里所说的领域指的是用户的业务领域，也就是需要解决 问题的领域，对领域知识的掌握与理解将直接关系到系统 开发的成败。
领域概念
• 领域概念是用来描述现实世界中某个问题的一些名词 和术语。建立领域模型的第一步是找出这些描述问题 的概念和术语。
是
是
用例模型
• 执行者？ • 用例？ • 系统边界？
执行者
• 下列涉众哪些是执行者？
– 操作工人 – 操作员 – 车间主任 – 开发人员
执行者
• 下列涉众哪些是执行者？
– 操作工人 – 操作员 – 车间主任 – 开发人员 – 称重仪表
• 物理仪表 • 模拟仪表
– 数据库服务器？？
用例
• 每个执行者的目标：
• 有的仪表允许操作工人在吊运过程中输入各种命令和数据，并能 够把输入的数据和重量数据同时发送出来。
用户需求
用户需求——涉众
• 操作工人。负责操作天车的技术工人。操作工人的主要工作 为操作天车，包括吊运物料，使用仪表输入物料编号等与物 料相关的数据。这些数据与重量数据一起通过称重仪表发送 给系统。
• 车间主任。一个车间生产的负责人，负责查看与系统相关的 工作，例如查看当日的称重记录，查看统计报表等。
• 操作员。负责使用计算机、打印机和 AutoWeight 软件系 统，并负责软件系统的运行和维护及打印报表。
• 系统开发人员。负责开发 AutoWeight 软件系统的项目组 成员。
用户需求——涉众
• 该系统还能够提供一个网络系统的接口，可以通过局域网 络把接收的数据上传到局域网中的数据库服务器中。
工作流程与原理（续）
• 系统的数据传输使用无线传输方式，使用数传电台来 传输数字信号。计算机通过串口来接收数据，数据传 输格式符合 RS232 标准。
• 如果网络条件许可，计算机可通过网络与局域网中的 数据库服务器相连。
实例分析
UML 在需求分析阶 段的应用
段的应用
课程内容
UML 在软件开发过程中的应用 Auto Weight 系统简介 用户需求 需求分析与描述 领域模型分析 工作流程分析
UML 在软件开发过程中的应用
在进行系统设计前，开发人员必须首先要充分理解所 要解决的问题，这就需要进行专门的需求分析。在进 行了需求分析之后，还必须进一步将分析产品转化为 设计产品，然后再根据设计产品进行实际的编制代码 工作，这些编制后的代码在经过必要的测试和详细的 部署之后，最终形成需要的目标系统。
测试阶段
在软件开发的不同阶段都需要进行测试。一般情况主 要强调三个点上的软件测试：单元测试、集成测试、 系统测试。
– 单元测试主要是根据系统的实现类图来测试已经实现 的程序单元。
– 集成测试主要根据系统的设计类图和构件图测试类和 包的接口。
– 系统测试主要是根据系统的用例图来测试系统是否正 确完成用户的要求。
• “ 输入数据”：不是一个候选的概念类，操作工人在仪表上输 入的数据，包括操作工人编号和物料的编号。这两个编号应 该是其它类的属性。