用例图详解：谁启动了用例？-业务与系统参与者分析

"本资源探讨了在UML用例图中如何确定启动用例的参与者，特别是当参与者可能不直接与系统进行物理交互时。它提到了业务参与者和系统参与者，以及业务用例和系统用例的区别。内容还强调了需求管理和用例在需求分析中的重要性，以及用例图在描述功能性需求中的作用。" 在UML(统一建模语言)中，用例图是一种关键工具，用于描绘系统与外部参与者之间的交互。有趣的问题在于，有时启动用例的参与者并非直接与系统互动的实体。在这种情况下，我们需要区分业务参与者和系统参与者。业务参与者指的是那些在业务流程中发挥作用，但可能不直接与系统交互的角色，而系统参与者则是与系统有实际交互的实体。 业务用例通常关注更广泛的操作流程，描述了业务环境下的需求，而系统用例则更具体，聚焦于系统需要执行的功能。如果未进行业务用例建模，识别业务参与者可能会变得困难。作者提出了一些判断标准，例如，实体是否主要传递信息，是否为用例提供重要语境，以及是否可能被自动化界面取代。 理解需求是软件开发的关键环节，需求应明确无误且易于沟通。需求管理包括寻找、记录、组织和跟踪需求的变化，以适应项目的动态发展。不充分的用户输入和不完整的需求是导致软件项目失败的常见原因。用例作为需求分析的核心，能帮助我们描述系统在实际场景中的行为。 FURPS+模型是评估需求质量的一种方式，涵盖了功能性、可用性、可靠性、性能、可支持性及其它辅助因素。用例不仅限于描述系统的行为，还强调了系统的质量属性。 用例的概念由Ivar Jacobson在1986年提出，后来Alistair Cockburn进一步发展了这一理论，提出了有效编写用例的方法。用例描述了一个参与者如何通过一系列事件与系统互动来实现特定目标。用例建模提供了一种结构化的视图，展示了参与者和他们可以参与的用例，这对于理解和驱动系统开发至关重要。 用例图以图形方式呈现参与者和用例的关系，其中参与者用人物图标表示，用例用椭圆表示。这种图解形式有助于简化复杂性，定义系统的功能结构，并为后续开发设定方向和约束。通过用例图，我们可以更清晰地了解系统的功能布局，以及各个参与者如何与其互动，从而更好地满足需求。