即使用例不被视为面向对象，为什么我们在面向对象的分析和设计中使用用例图？答案

【问题标题】：Why do we use UseCase diagrams in object oriented analysis and design even if Usecases are not considered as Object oriented?即使用例不被视为面向对象，为什么我们在面向对象的分析和设计中使用用例图？
【发布时间】：2014-09-16 12:56:19
【问题描述】：

UML 符号说，用例是用来指出问题域中的功能需求的，它绝不会像Data Flow Diagrams 或实体关系图那样提供有关对象或类的信息。还有为什么我们在面向对象的分析和设计中使用用例图，即使用例不被认为是面向对象的。

【问题讨论】：

标签： oop object uml software-design

【解决方案1】：

用例图旨在阐明系统的主要功能，并强调将后者呈现为仅存在于唯一任务的黑盒子的视角；将承诺的服务交付给参与者.

此时我们并不真正关心 OOP，因为您可以明确地将用例图用于任何其他类型的分析。

UML只是一组可视化工具，可以统一表达系统的不同视角。如果您使用的是统一流程，它主张首先识别用例，然后将每个用例分解为协作实体（类），并通过利用 类在它们之间建立静态协作图工具箱。

【讨论】：

【解决方案2】：

面向对象是分析和设计方法，而用例是需求方法。并注意核心开发工作流程：

业务建模
要求
分析
设计

如果我们使用 UML 来完成这些工作，我们可能会：

业务用例+业务时序图
系统用例+系统用例规范
分析类图+分析序列图+分析状态机图
代码、数据库......

3.中的UML图可以用DFD/ER代替

【讨论】：

【解决方案3】：

Kirill Fakhroutdinov 的在线书籍uml-diagrams.org 将 UML 定义为

统一建模语言™ (UML®) 是一种标准的可视化建模语言，旨在用于

为业务和类似流程建模，

基于软件的系统的分析、设计和实施

UML 是业务分析师、软件架构师和开发人员的通用语言，用于描述、指定、设计和记录现有或新的业务流程、软件系统工件的结构和行为......

因此，语言需要文字来描述流程及其参与者（代码及其用户、代码存在的原因、它有什么用处、为什么有人应该为它花钱......）..

如果在您的设计中您不需要考虑用户和他们的需求（您已经设置了用户界面设计并且您只关注库代码），那么不要打扰，使用 UML 来描述部件您正在处理和使用对您（和您的队友）自然且有用的图表

一些相关文章：

【讨论】：

【解决方案4】：

如果很好的用例图主要用于与非技术人员交流，我想补充一点，在某些软件架构（如 Clean Architecture）中，用例表示为编排实体的实际对象（它们是相等的毕竟服务）。例如。给定用例“提交问题”，您可以为其创建以下定义：

提交问题用例

输入数据：

issue_id
问题描述
日期

输出数据：

与确认输入数据相同

初级课程

验证输入数据
使用输入数据创建新的问题实例
坚持新问题
返回确认数据

正如您在初级课程中看到的那样，在这个用例和一个名为“Issue”的实体对象之间甚至存在可检测的依赖关系。

这个 SubmitIssue 用例类的 Python 示例：

class SubmitIssue(UseCase):

    def __init__(issue_repo):
        self._repo = issue_repo

    def execute(self, input_data):
        #validate input data as needed
        #and apply branching logic if it is valid
        new_issue = Issue(input_data) #create new issue
        self._repo.add(new_issue) #persist new issue
        return self._generate_output_data(new_issue)

    @staticmethod
    def _generate_output_data(new_issue):
        #logic that returns the output data as specified
        #in the use case output data definition
        return output_data

问候。

【讨论】：