在敏捷开发中，用例图和类图可以迭代地更新和细化，随着需求的变更和系统的发展，不断调整和完-CSDN博客

本文链接：https://blog.csdn.net/blog_programb/article/details/148352682

用例图

参与者：
- 患者：使用APP进行注册、登录、确认处方、取药等操作。
- 药师：处理处方，配置药品，进行煎制（若有要求）。
- 快递人员：派送药品，确认药品送达。
用例：
- 注册：患者扫描二维码，提供病历号获取基本信息完成注册。
- 登录：已注册患者登录系统，未注册患者被拒。
- 确认处方：患者登录后，查看医生开具处方，选择抓药药品、数量、煎制要求、取药方式（自行到店或送药上门），系统计算费用，患者支付后处方发送给药师。
- 处理处方：药师配置药品，按要求煎制（若有），设置处方状态为已完成。自行取药患者取药后确认取药。
- 药品派送：系统给快递人员发送配送信息，给送药上门患者发送收货验证码。
- 送药上门：快递人员送药，患者收货出示验证码，快递人员验证确认送达。

类图

主要类：
- 患者类：属性包括病历号、姓名、联系方式、收货地址等；方法有注册、登录、确认处方等。
- 药师类：属性可包含药师编号、姓名等；方法有处理处方、配置药品、煎制药品等。
- 快递人员类：属性有快递员编号、姓名等；方法有派送药品、确认送达等。
- 处方类：属性有处方编号、药品列表、数量、煎制要求、取药方式、费用等；方法可包括计算费用等。
- 系统类：负责协调各功能，属性可包含系统配置信息等；方法有验证登录、发送信息（给药师、快递人员、患者）等。

在绘制图形时，用例图中参与者用小人图标表示，用例用椭圆表示，参与者和用例之间用连线表示关联关系。类图中类用矩形表示，分为属性和方法两层（可根据规范细分），类与类之间根据关系（如关联、依赖等）用相应线条连接并标注关系类型。
图中的问题要求使用面向对象分析与设计方法开发一套线上抓药APP系统，并得到用例图和类图。

1. 用例图（图3-1）

用例图展示了系统的主要功能和用户（参与者）之间的交互。根据描述，主要的参与者包括“患者”和“药师”，主要用例包括：

患者
- 注册
- 登录
- 确认处方
- 选择取药方式（自行取药或送药上门）
- 支付费用
药师
- 处理处方
- 配置药品
- 标记处方完成

用例图示例：

+------------------+
|      患者        |
+------------------+
       |
       |---------------------+
       |                     |
  注册  |                     | 登录
       |                     |
       |---------------------+
       |
       |---------------------+
       |                     |
确认处方 |                     | 选择取药方式
       |                     |
       |---------------------+
       |
       |---------------------+
       |                     |
   支付费用 |                   |
       |                     |
       +---------------------+

+------------------+
|      药师        |
+------------------+
       |
       |---------------------+
       |                     |
  处理处方  |                   | 配置药品
       |                     |
       |---------------------+
       |
       |---------------------+
       |                     |
   标记处方完成 |               |
       |                     |
       +---------------------+

2. 类图（图3-2）

类图展示了系统中的主要类及其关系。根据描述，主要的类包括：

Patient（患者）
- 属性：姓名、联系方式、地址、病历号
- 方法：register(), login(), confirmPrescription(), chooseDeliveryMethod(), pay()
Pharmacist（药师）
- 属性：姓名、联系方式
- 方法：processPrescription(), prepareMedicine(), markPrescriptionCompleted()
Prescription（处方）
- 属性：处方ID、药品列表、数量、费用
- 方法：getMedicines(), getQuantity(), getCost()
Order（订单）
- 属性：订单ID、患者ID、处方ID、取药方式、状态
- 方法：createOrder(), updateStatus()

类图示例：

+------------------+
|      Patient     |
+------------------+
| - name           |
| - contactInfo    |
| - address        |
| - medicalRecord  |
+------------------+
| + register()     |
| + login()        |
| + confirmPrescription() |
| + chooseDeliveryMethod() |
| + pay()          |
+------------------+

+------------------+
|     Pharmacist   |
+------------------+
| - name           |
| - contactInfo    |
+------------------+
| + processPrescription() |
| + prepareMedicine()     |
| + markPrescriptionCompleted() |
+------------------+

+------------------+
|    Prescription  |
+------------------+
| - prescriptionID |
| - medicines      |
| - quantities      |
| - cost           |
+------------------+
| + getMedicines()  |
| + getQuantity()   |
| + getCost()       |
+------------------+

+------------------+
|       Order      |
+------------------+
| - orderID        |
| - patientID      |
| - prescriptionID |
| - deliveryMethod |
| - status         |
+------------------+
| + createOrder()  |
| + updateStatus() |
+------------------+

这些图展示了系统的主要功能和类之间的关系，帮助开发人员理解系统的设计和实现。

概念层面

用例图：从用户视角出发，用于描述系统功能，展示系统与外部参与者（如用户、其他系统等）之间的交互。它关注系统能为参与者做什么，强调系统的功能需求，是对系统功能的一种宏观抽象表示。
类图：是面向对象设计的核心，描述系统中类的结构，包括类的属性、方法，以及类与类之间的关系（如关联、继承、聚合等）。它侧重于系统的静态结构，是对系统内部实现结构的建模。

元素及表示方面

用例图：
- 参与者：用小人图形表示，代表与系统交互的外部实体，可以是人、组织或其他系统。例如在电商系统中，“顾客”“商家”就是参与者。
- 用例：用椭圆表示，代表系统提供的功能或服务。比如电商系统中“下单”“支付”就是用例。
- 关系：包括关联（参与者和用例之间的联系）、扩展（一个用例对另一个用例功能的扩展）、包含（一个用例包含另一个用例的功能）等，用带箭头的线段表示。
类图：
- 类：用矩形表示，一般分为三层，顶层是类名，中间层是属性，底层是方法。例如“学生”类，可能有“姓名”“学号”等属性，以及“获取成绩”等方法。
- 关系：
  - 关联：表示类与类之间的连接，用实线表示，可带多重性标记（如1对1、1对多等），如“教师”类和“学生”类之间存在关联。
  - 继承：用带空心三角箭头的实线表示，子类指向父类，如“本科生”类继承“学生”类。
  - 聚合/组合：聚合表示整体与部分的松散关系，用带空心菱形的实线表示；组合表示整体与部分的强关联关系，部分不能脱离整体存在，用实心菱形的实线表示，比如“班级”和“学生”可能是聚合关系，“汽车”和“轮胎”可能是组合关系。

用途和应用场景

用例图：在项目需求分析阶段使用，帮助需求分析师和用户沟通，明确系统功能需求，界定系统边界。例如在开发医院挂号系统时，通过用例图可以清晰展示患者挂号、医生查看预约等功能需求。
类图：主要用于系统设计阶段，帮助软件设计师规划系统的静态结构，为后续的编码实现提供蓝图。比如在开发一款管理软件时，类图可以指导程序员如何定义类、类的属性和方法以及类之间的交互关系。
用例图和类图是面向对象分析与设计（OOAD）中的两个重要工具，它们在软件开发过程中发挥着关键作用。以下是它们在实际开发中的应用：

用例图的应用

需求收集与分析：
- 用例图帮助开发团队理解系统的功能需求，通过识别参与者（用户或其他系统）和用例（系统功能），明确系统需要提供哪些功能。
沟通工具：
- 用例图作为开发团队与客户、利益相关者之间的沟通工具，帮助非技术人员理解系统的主要功能和用户交互。
系统设计：
- 用例图指导系统设计，帮助确定系统的主要组件和它们之间的关系，为后续的详细设计和实现提供基础。
测试计划：
- 用例图可以作为测试计划的基础，每个用例都可以转化为测试用例，确保系统功能按预期工作。
文档化：
- 用例图是系统文档的一部分，记录系统的功能需求和用户交互，为未来的维护和升级提供参考。

类图的应用

系统架构设计：
- 类图展示了系统的静态结构，包括类、接口、它们的属性和方法，以及类之间的关系（如继承、实现、关联等），帮助设计系统的架构。
详细设计：
- 类图指导详细设计阶段，开发人员可以根据类图设计数据库模式、编写代码、实现类和接口。
代码生成：
- 在某些开发环境中，类图可以直接用于生成部分代码，提高开发效率。
团队协作：
- 类图作为团队协作的工具，帮助团队成员理解系统的内部结构和设计决策，促进团队成员之间的沟通。
重构和维护：
- 类图在系统重构和维护过程中非常有用，帮助开发人员理解现有系统的结构，识别改进的机会。
文档化：
- 类图是系统文档的一部分，记录系统的静态结构，为未来的维护和升级提供参考。

结合使用

迭代开发：
- 在敏捷开发中，用例图和类图可以迭代地更新和细化，随着需求的变更和系统的发展，不断调整和完善。
模型驱动开发（MDD）：
- 在模型驱动开发中，用例图和类图是开发过程的核心，通过模型自动生成代码，减少手工编码的工作量，提高开发效率和代码质量。

总之，用例图和类图是软件开发过程中不可或缺的工具，它们帮助开发团队理解需求、设计系统、编写代码、测试和维护系统，确保软件开发的质量和效率。
在敏捷开发中，迭代更新是一种常见的做法，它允许团队在开发过程中不断适应变化的需求和反馈。用例图和类图作为重要的设计工具，在敏捷开发中也需要进行相应的迭代更新。以下是具体的步骤和方法：

1. 初始建模

在敏捷开发的初期，团队应该创建一个基本的用例图和类图，以捕捉系统的主要功能和结构。这些图不需要非常详细，但应该足够清晰，以便团队成员理解系统的基本需求和设计。

2. 迭代计划

在每个迭代周期（如两周或一个月）开始时，团队应该根据产品待办事项列表（Product Backlog）选择将在当前迭代中实现的功能。然后，团队应该更新用例图和类图，以反映这些功能。

3. 更新用例图

添加新用例：如果新的功能需求被识别，应该添加新的用例到用例图中。
修改现有用例：如果现有功能需要修改或扩展，应该更新相应的用例。
删除过时用例：如果某些功能不再需要，应该从用例图中删除相应的用例。

4. 更新类图

添加新类：如果新的功能需要新的类来实现，应该在类图中添加这些类。
修改现有类：如果现有类需要修改以支持新功能，应该更新类图。
删除过时类：如果某些类不再需要，应该从类图中删除这些类。
更新类之间的关系：如果类之间的关系发生变化（如新增关联、修改继承关系等），应该更新类图以反映这些变化。

5. 持续沟通和反馈

团队讨论：在更新用例图和类图后，团队应该进行讨论，确保所有成员都理解更新的内容。
客户反馈：在可能的情况下，应该向客户展示更新的用例图和类图，获取他们的反馈，并根据反馈进行调整。

6. 持续集成

代码与模型同步：随着类图的更新，开发人员应该相应地更新代码，确保代码与模型保持一致。
模型驱动开发：在某些情况下，可以使用工具自动从类图生成代码，或者从代码生成类图，以保持模型和代码的同步。

7. 文档化和回顾

文档化：在每个迭代结束时，应该更新文档，记录用例图和类图的当前状态。
回顾：在迭代回顾会议中，团队应该回顾用例图和类图的更新过程，讨论哪些做得好，哪些需要改进。

通过这种方式，用例图和类图可以在敏捷开发中不断迭代更新，以适应不断变化的需求和反馈，同时保持团队对系统设计的理解。
以下是根据用例图识别系统边界的方法：

依据参与者判断

明确外部实体：参与者是处于系统外部，与系统进行交互的人、组织或其他系统。那些在图中以小人或特定图标表示的参与者，其所处位置就在系统边界之外。例如在电商系统用例图中，顾客、商家、物流合作伙伴等参与者，他们与系统交互但不属于系统内部，由此可确定系统边界在他们之外。
分析交互关系：参与者与用例之间通过关联关系相连，这种关联点就体现了系统与外界的交互接口。系统边界就是围绕这些交互点，将系统内部的用例（功能）与外部参与者分隔开来。比如在银行储蓄系统中，储户作为参与者与“存款”“取款”等用例交互，这些交互的界限就勾勒出了系统边界。

从用例角度确定

梳理用例范围：用例是系统提供的功能或服务。只关注系统内部所包含的用例，用例所涵盖的功能范畴就是系统内部的功能领域，其外部就是系统边界。例如在图书管理系统中，“图书借阅”“图书归还”“图书信息查询”等用例，这些用例集合的外部边界就是系统边界。
排除外部功能：如果存在一些功能在图中是由外部参与者自身执行，而不是系统提供的功能（即不属于系统内的用例），那么这些功能区域就在系统边界之外。比如在在线教育系统中，学生自主制定学习计划这一行为，若未作为系统的用例，那就属于系统边界外学生自身的活动。

综合整体判断

检查遗漏情况：确保用例图中涵盖了系统所有主要功能对应的用例，避免出现因用例缺失而导致系统边界界定不准确的情况。同时，检查参与者与用例的关联是否完整合理，若存在不合理的交互，可能影响系统边界判断。
结合业务背景：将用例图与实际业务场景相结合，从业务逻辑上判断哪些属于系统内部处理范畴，哪些属于外部范畴。比如在酒店预订系统中，结合酒店运营的业务逻辑，判断诸如客户在线选房（系统功能）与客户线下与酒店协商特殊服务（系统外协商行为）等，从而准确界定系统边界。