问题
I am working at modelling a software system using Sparx Enterprise Architect 13. This system contains different versions of software components. We typically add services and/or APIs when we release a new version of a software component.
Currently, to reflect the fact that component ServiceV1 exposes an interface A and ServiceV2 exposes interfaces A (the same as ServiceV1) and B, I make ServiceV2 extend ServiceV1. But that is not straightforward:
- the generalization link is not available in diagrams between components, so I have to use Advanced > Parent...
- it lacks flexibility, because I cannot override interface A with a newer version of the interface
Is there a better way to do so? What is the standard way of maintaining several versions of the same component?
Thank you!
回答1:
I don't think this is standardized by some standards body, but I would recommend to introduce two levels of abstraction: the unversioned component level and the versioned component level.
- On the unversioned component level, you have just a single element in the project repository for each component (not for each component version).
- On the versioned component level, you have a single element in the project repository for each version of each component.
Each versioned component, e.g. MyComponentV2 has a ≪trace≫ dependency to the unversioned one, e.g. MyComponent.
To prevent unnecessary design work, you may decide to draw relationships between different components only between versioned component elements, not between unversioned component elements, or only vice versa. But this depends on the needs of your organization.
When you create a new version of a component, you copy the most recent version of the component (MyComponentV2) with all its connections, including the ≪trace≫-dependency to the unversioned component (MyComponent) and give it the right name (MyComponentV3).
I have applied this in a large project.
回答2:
Actually there is no standard for modeling such a scenario. At best you can have conventions - which may differ from domain to domain. However, here's how I would model it:
ServiceV2 has a <<trace>> relation to ServiceV1. UML 2.5.1 says on p. 682:
«Trace» | Abstraction | Specifies a trace relationship between model elements or sets of model elements that represent the same concept in different models. Traces are mainly used for tracking requirements and changes across models. As model changes can occur in both directions, the directionality of the dependency can often be ignored. The mapping specifies the relationship between the two, but it is rarely computable and is usually informal.
So that should mean in this context ServiceV2 is created using ServiceV1 (I formerly used <<derive>> here since it seemed logical. But actually the UML semantic is defined differently; see p. 680 of UML 2.5.1). You could well invent your own stereotype here and explain it in the domain context (e.g. <<version of>>).
You would probably create a copy of ServiceV1 or model it manually as new element (you don't do that on a mass scenario, do you?). Here I added provided interfaces that both realize the common interface A. The quick linker does not offer those relations. You need to either go the clumsy Ctrl-I way or you grab the realization from the toolbox.
The <<derive>> dependency is not offered directly (unless you have your own MDG and defined it in QL or toolbox). So you create a dependency and choose derive from the stereotype menu.
This is a broad field and versioning is not as simple as just adding a numbering schema. In any case if you create a new component it will be something different. So the <<derive>> is probably the best option here.
N.B.: EA uses lower case <<trace>> while UML uses <<Trace>>. Just noticed that. EA used lower case ever since. Some relict since from UML 2.5 on OMG changed it to upper case first char. Worth a bug report?
来源：https://stackoverflow.com/questions/56879858/how-can-i-version-software-components-in-sparx-enterprise-architect-ea