I am trying to model a software system using Sparx Enterprise Architect 13. In our system, the software components are divided into sub-components (nothing extraordinary).
I know precisely what interfaces the sub-components provide, require and how they are interconnected. So in my model, all the links are defined at sub-component level and not at a component level.
Now, I would be able to produce diagrams representing the big picture, whose elements would be the components and not the sub-components. The idea would be to drag my existing components into a diagram to be able to see the links between them, automatically populated from the links that I have already defined between sub-components.
I found no way to achieve this goal, and I have tried using the following EA element combinations:
components containing other components
packages containing components
packaging components containing components
components containing ports
Is there a way to do that in EA ?
Thank you :)
What I do is to actually use ports on components. An outer component
is set to be composite (note the lying 8 bottom right). When dbl-clicked it will open the composite diagram showing the inner structure like so (the layout must be arranged manually by enlarging the outer and positioning the inner):
Required/provided interfaces can and should be added to the ports as needed. And of course they can be shown and hidden in different diagrams as well.
They key to it all is the composite diagram (context in browser: Add/Composite) which in the end will create a navigable model.
Ports and interfaces can be created via context Structural Elements.
Note: To make an element composite you need to right-click in Project Browser | Add | Composite Structure Diagram. That goes for V13.5 and many other versions (it had been different in the past). And you never know in which place some EA developer will put that functionality in the next version :-/
Related
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!
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.
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.
EA supports this. See documentation of "Time aware models" here:
https://sparxsystems.com/enterprise_architect_user_guide/13.0/model_domains/time_aware_models.html
Allows maintaining separate versions of each package
I defined my software system using EA. I stayed mainly at the high level so far. The software interfaces between my components are represented as Structural Elements "Provided Interface" (the little purple bullets) and "Required Interface" (the little sockets).
Now, I would like to go a little bit further into the details, and define the API corresponding to each of these Provided Interfaces, ideally as a class diagram. It would be perfect if I were able to create a nested composite structure diagram for each of these Provided Interfaces, like for software components for example. But it seems that EA does not enable that.
What I do is that I create an Interface nested in my software component, then I link the Required Interface (the purple bullet) to my Interface (purple square) with a Dependency link. Then I can create a nested composite structure diagram in my Interface. But I doubt this is the optimal method.
Can someone tell me what is the "EA-approved" way of defining Required Interfaces ?
Thank you :)
You can directly select the Interface in the ProvidedInterface or RequiredInterface without needing to explicitly create a Realize or Dependency connector to the target interface.
You can do this as shown in the figures below:
One advantage of this is that you do not have to show the actual target interface on the same diagram as the components while still being able to navigate to them. This becomes handy when you have components that provide or require many interfaces (and you do not want to clutter your diagram). With this approach you can use the Find | Locate Classifier in Project Browser context menu and directly jump to the composite diagram.
In my Enterprise Architect model, I have nodes that contain devices that contain components that contain other components. That's how I organized the hierarchy in the Project Browser.
I would like to be able to drag one element of the model into a diagram (as a Link), and be able to see all the elements contained by this element without having to drag them individually. For example, dragging a device into a deployment diagram would display the node and all the components it contains.
This logic works when I drag a component onto a diagram: I am able to select what children elements (interfaces, ports, ...) I want to see on the diagram. But I did not find a way to do the same with this following containment hierarchy: node > device > component > subcomponent.
Is there a way to do so ?
Thank you :)
You can do it manually, of course. Dragging the outermost onto the diagram (as link) and enlarge it. Drag the inner ones onto the diagram somewhere outside the outer one (to avoid some dialog otherwise). Drag them inside the outer and arrange as needed.
Another way is to make the outer element composite (context/Add/Composite diagram or /New Diagram/Composite). On this composite diagram place the inner elements and arrange them. Save the diagram when done. Now you can create diagrams with the outer element which, once enlarged, can show the composite diagram inside. Just drag the composite diagram as Diagram Frame and eventually make it smaller. Then place it inside the enlarged outer component.
While in the first case you can show relations (like port delegation) this is not possible in the second one.
There is no way to automagically drop the nested structure except you come up with some very tricky add-in.
Is it possible to somehow organize my diagrams in Enterprise Architect? We're starting having too many of them, with each diagram containing many elements. Is creating a separate folder for each diagram the only solution to make the model easier to see through, or is there a more elegant layout for that?
In the first place, Model Views will help you to create distinct viewpoints representing your entities from different perspectives.
If you stick to the architecture principles of loose coupling and modularity, you should be able to split up very big diagrams into smaller ones. After all, their role is to give you an idea of how things are coupled and work together, but also to abstract from things that are not really relevant in the given context of the diagram. Diagrams are not meant to just visualize all elements in one big picture.
You can create package structures that are pretty complex and then use the model search. You can also put hyperlink elements for easier navigation between diagrams.
If you have to split up elements into different diagrams (which then go into different packages) EA will preserve their relationships and you can review them at any time using the traceability view.
I would also have a look at the EA options for composite diagrams. This should help you re-organise a Single System into a number of Composite Sub-Systems.
To start modeling an application architecture, you can use a perspective based approach or a view modeling perspectives approach to describe your system. For example use the 4+1 view based approach to collect your Logical, Development, NonFunctional and Requirements perspective. Organize it according the mentioned dimmensions or decompose each dimmension by the application modules and have a conceptual view to have a global view of your system.
To start with a model of an enteprise architecture use for example the togaf dimensions or zachman framework layers and dimmensions
You can use several packages to categorize your content.
I use to make a package diagram on top level which dynamically updates its contents depending on underlying packages (simply drag & drop the packages in the package diagram)
and the content (e.g. for activity diagrams) like entry or final can be saved in a common package.
Unfortunately there is no possibility yet (version 10 build 1004) to customize the packages e.g. with colors. So that a common packages could have a distinct color.
What I do to make Project Browser more organized is to create one package named "Diagram's elements" and drag all the diagram element there.
There's some good advice in this blog on the Sparx Systems (the EA publisher) website.
Since a single component could be manifested by multiple artifacts, I'd like to know how a component's multiple artifacts are represented in a component diagram. Or in other words if I have a component which is comprised by several files where the code of the whole component is implemented how can I draw the component diagram to make it clear the different files that comprise it?
Can I use a notation similar to a package where you can put the package symbol and inside the objects that the package contain? I mean, some sort of clickable component symbol where I double click and it opens showing the comprising files?
I use Enterprise Architect so examples using this will be even more helpful.
Regards!!
In Enterprise Architect, go to Component's properties (double click on the component box in the diagram) and go to files. That's the place to put the file list in Enterprise Architect.
Still, it's possible to model it in a way that a single file is represented as a separate component and thus "master" component is clickable so it is possible to navigate to another diagram, but when the model gets big and consists of many files it won't serve the purpose and it will get too complicated.
If for any reason, it is necessary to clearly mark the file list on the diagram, the note with textual description is sufficient.
Note that primarily a model (i.e. Component Diagram) is to show the parts of which the system is build and as opposite to the design, the file list is specific to the implementation.