英文:
Is there an equivalent to use case inclusion and extension in Archimate model?
问题
我曾经使用 UML 用例,现在需要使用 Archimate 建模系统。
我需要建模系统的功能,我猜可以使用 Archimate 的业务层来完成。
在这个业务层中,一个服务可能对应一个用例。可以在一个服务中建模另一个服务:这可以看作是用例的包含。
但是在 Archimate 中是否有一种方法来建模类似用例扩展的东西?
英文:
I use to use UML use cases and I have to model a system using Archimate.
I need to model the features of the system, and I guess that I can do that using the business layer of Archimate.
In this business layer, a service seems may correspond to a use case. It is possible to model a service in a service: that could be seen as a use case inclusion.
But is there a way to model something like a use case extension in Archimate ?
答案1
得分: 1
以下是已翻译的内容:
在相关的UML和Archimate概念之间存在着微妙的语义差异,因此没有一对一的映射。
Archimate中的用例
UML用例是:
> 由主体执行的一组行为,产生对主体的参与者或其他利益相关者有价值的可观察结果。
在Archimate中最接近的概念是服务:
> 应用服务 代表明确定义的暴露的应用行为。 <br>(...) 应用服务应该从环境的角度来看是有意义的;它应该提供一个对其用户来说本身有用的行为单元。它有一个目的,说明了这个对环境的实用性。
但根据考虑的主体,这些服务也可以是业务服务:
> 业务服务 代表业务角色、业务参与者或业务协作向其环境公开的明确定义的行为。
这些服务向其环境公开行为,以实现某种目的,而不涉及内部细节。有关UML到Archimate的映射的更多信息,请查看此处。
包含和扩展
在UML中,包含和扩展是用例之间的关系:
> 包含是两个用例之间的DirectedRelationship,表示被包含的用例的行为(附加行为)被插入到包含用例的行为(包含用例)中。
> 扩展是从扩展用例(扩展)到扩展用例(扩展用例)的关系,指定了扩展用例中定义的行为如何以及何时插入到扩展用例中定义的行为中。
因为Archimate的元模型只允许直接关系之间的服务来模拟流程("触发/流向"),所以在Archimate中没有直接等效。
要在Archimate中建模包含和扩展,您需要展示行为的重复使用(当用例被发明时包含/扩展的初始目的)通过区分:
- 应用服务向外部环境公开行为,等效于真实用例
- 应用功能 对应于将组合以实现服务的内部行为(表示为多个服务的相同功能):
> 应用功能描述应用组件的内部行为。如果这个行为在外部公开,那么是通过一个或多个服务来实现的。应用功能抽象了它的实现方式。只规定了必要的行为。
因此,翻译的示例将显示相同的功能可以用于实现多个服务:
类似的原则可以用于扩展。
这不是很繁琐吗?
更复杂的Archimate等效有一些优点:它迫使区分直接暴露的行为(真实用例)和可重用的应用功能(主要用于功能分解而不是用户目标导向 - 这在用例建模中是不推荐的)。此外,它导致了不同抽象级别的更明显区分。
英文:
There is not a one-to-one mapping, as there are subtle semantic differences between the related UML and Archimate concepts.
Use cases in Archimate
UML Use cases are:
> a set of behaviors performed by that subject, which yields an observable result that is of value for Actors or other stakeholders of the subject.
The closest concept in Archimate is the service:
> An application service represents an explicitly defined exposed application behavior. <br>(...) An application service should be meaningful from the point of view of the environment; it should provide a unit of behavior that is, in itself, useful to its users. It has a purpose, which states this utility to the environment.
but it could also be business services, depending on the subject considered:
> A business service represents explicitly defined behavior that a business role, business actor, or business collaboration exposes to its environment.
These services expose behaviors to their environment, for a purpose, without internal details. More about UML to Archimate mapping here.
Inclusion and extension
In UML, inclusion and extensions are relationships between use-cases :
> Include is a DirectedRelationship between two UseCases, indicating that the behavior of the included UseCase (the addition) is inserted into the behavior of the including UseCase (the includingCase).
> An Extend is a relationship from an extending UseCase (the extension) to an extended UseCase (the extendedCase) that specifies how and when the behavior defined in the extending UseCase can be inserted into the behavior defined in the extended UseCase.
There is no direct equivalent in Archimate, because its meta model allows direct relationships between services only to model a flow ("triggers / flows to").
For modeling inclusion and extension in Archimate, you'd need to show the reuse of behaviors (the initial purpose of inclusion/extension when use cases were invented) by making a difference between:
-
Application services expose behavior to the external environment for a given purpose, equivalent to real use cases
-
Application functions correspond to internal behaviour that would be combined to realize a service (the same function being represented for several services):
> An application function describes the internal behavior of an application component. If this behavior is exposed externally, this is done through one or more services. An application function abstracts from the way it is implemented. Only the necessary behavior is specified.
So the translated example would show that same functions can be used to realise several services:
A similar principle could be used for extension.
Isn't this cumbersome?
The more complex Archimate equivalent has some advantages: it forces to make the difference between behaviors exposed directly (real use cases), and reusable application functions (pseudo use cases that mainly serve a functional decomposition without being user-goal oriented - something that is anyway not recommended in use-case modelling). Moreover it leads to a more visual differentiation between different levels of abstraction.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库,让每个人都能够通过互相帮助和分享经验来进步。
评论