【问题标题】:Abstract Use Case in Enterprise ArchitectEnterprise Architect 中的抽象用例
【发布时间】:2014-05-31 20:51:45
【问题描述】:

如何在 Enterprise Architect 10 中创建抽象用例?

编辑:

这是一个例子:

如何在 Enterprise Architect 中实现这一点?

将用例定型为“抽象”不会改变字体。

我不是在问如何手动更改字体。我期待如果一个用例被定型为“抽象”,那么它的标题字体会自动更改为斜体。但似乎并非如此。

【问题讨论】:

    标签: uml abstract use-case enterprise-architect


    【解决方案1】:
    1. 进入属性窗口(不是双击元素弹出的对话框,窗口默认位置在左下角)。

    2. 在“高级”部分中,将“抽象”设置为“真”。

    【讨论】:

    • 我们昨天讨论过的 RTFM 也可以工作,请参阅 sparxsystems.eu/resources/project-development-with-uml-and-ea/… 章节“专业化(泛化)”,脚注“[1] 选择元素并在窗口属性中将 Abstract 设置为 True 在部分高级”
    • 我已经用这个解决方案更新了我的答案,这比我最初提出的要好得多。由于我的有一些背景信息和(仍然有效的)脚本替代解决方案,我不会删除它,但我认为您应该将其标记为已接受的答案。
    • @Uffe 再次感谢,您的原始答案已将我指向此解决方案。
    【解决方案2】:

    无论元素的类型如何,“抽象性”在 EA 中都不会被表达为刻板印象,因此这也不适用于类。相反,元素的“属性”对话框中有一个“抽象”复选框。如果您打开课程的对话框,您会在“详细信息”页面上找到它。

    但是,用例的相同对话框不包括“抽象”复选框。但是,底层数据模型允许任何元素是抽象的,包括用例。

    撇开对抽象用例建模以回答实际问题的正确性与否,有两种方法可以在 EA 中实现抽象用例。两者都是“正确的”,因为它们会产生具有适当“抽象”属性集的用例,而不是对字体或类似内容进行纯粹的装饰性更改。

    以这两种方式抽象的用例将自动以斜体显示,可以在搜索和生成的报告等中区分。

    方法一:元素属性窗口

    在元素属性窗口(不是对话框,而是在元素菜单中打开的那个)中,您可以在高级分支下设置“抽象”属性。

    方法二:使用脚本

    这是一个 VB 脚本 sn-p,它使单个用例抽象化。

    if (theElement.Type = "UseCase") then
        theElement.Abstract = 1
        theElement.Update()
    end if
    

    如果您将其放在图表或对象浏览器脚本中,您可以轻松地将用例抽象化。您可能希望对其进行修改以使其成为切换而不是单向,但您明白了。

    如果您已经创建了许多具体的用例并希望将它们抽象化,这会很有用。

    【讨论】:

      【解决方案3】:

      在 UML 和 OOP 中都有可能,但没用,and 和样式

      如果您的客户坚持结构,您可以通过 extendsinclude 刻板印象来展示某些行为的变体。并且一些变体可以有一个注释,说明这种变体将永远不会真正实现。这在语义上等同于您的抽象用例。 ...而且这东西的无用性也是显而易见的。

      您可以直接设置 Abstrect 属性,如相邻答案所示。但这并没有增加实用性。

      更多不使用“抽象”的理由:

      • 抽象是什么意思?这意味着,这种结构本身永远不会实现,只会为其他具体结构提供一些共同特征。也就是说,它正在设置实现的方式,即你系统的内部构造。你不应该在 UC 图表上解决实现问题,它们只是设置你正在解决的任务的正式方式。你不应该混合设置任务和解决它。
      • 在技术方面,抽象是一种结构信息。用例图是一种行为图。不过,您可以使用从其他图表中借用的结构元素。例如,抽象类。但它是用于特殊用途,而不是标准用途。例如,您正在解决任务并且(唉!)由于许可证或政治原因,您已经严格设置了一些 SW/HW。这不好,但它可能发生。但如果是纯行为元素,则用例本身不能简单地说它是抽象的。
      • “抽象”是在某些语言中使用的词,但并非在所有 OOP 语言中都使用。您不应该在 UC 图表中设置语言。
      • 用例显示行为,将首先通过接口而不是通过类来实现。而且所有接口都已经是抽象的了。

      【讨论】:

      • “即,它正在设置实现方式,即系统的内部构造” - 可以使用相同的论点来反对 >ing 非抽象UC。 UC 是否可以独立使用无关紧要,它只是将较大的 UC 分解为较小的逻辑块的一种手段。任何对较低级别块的分解都会对实现造成一些限制。
      • 1. Includes 和 Extends 只是缩写的意思。有了它们,您无需在许多地方重复相同的信息。但我也不喜欢它们,因为它们可以表达认识。 2.“UC是否可以独立使用……” - 我写过一句话吗?对不起,我根本不明白这句话。 3.“任何分解到较低级别的块都会对实现造成一些限制”——当然,这是一种非常糟糕的风格。但要小心,朋友!谁说什么是低级?您可以制作最高级别的类图,设置手册的结构。
      • 实际上,您可以在 UC 图中设置语言,也可以在个别用例上设置语言。在我看来,这样做通常没有意义(实现语言是实现的一个方面,而不是分析的一个方面),但功能是存在的。
      • @Uffe 当然,你真的可以。这是“仅仅”非常糟糕的风格。谢谢指正。
      • 抽象用例是否有意义是所使用方法的一个方面,它不是文档语言 (UML) 中的通用常量。抽象用例的一个用例(!)可能是描述在实现中应遵循但不由任何组件直接实现的模式;在 EA 中,您可以从标记未实现用例的模型验证中排除此类抽象用例。是的,使用构造型或标记值可以达到相同的效果,但关键是抽象用例的概念不一定无效。
      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-05-20
      • 1970-01-01
      • 2011-08-05
      • 1970-01-01
      相关资源
      最近更新 更多