I want to describe the fact that the 4 cars in the system can communicate with each other. The multiplicity is specified to be 4 when defining the block diagram. This is how it looks like as an IBD. Does this make sense or should 4 separate instances of cars be created and connected?
In short
This IBD tells that each of the 4 car is connected to exactly one other car. But according to your narrative, each car should be connected to the 3 other ones. So you should put a 3 multiplicity at teach end of the connector.
Some more explanations
According to SysML section 8.3.1.2:
An internal block diagram is based on the UML composite structure diagram, with restrictions and extensions as defined by SysML.
Among these SysML extensions there is section 8.2.1.2.9:
SysML defines a default multiplicity of 1 on each end of a connector. These multiplicities may be assumed if not shown on a diagram.
In absence of more specific rules, the connector is then to be understood as in UML for the composite structure:
For each instance playing a role in an internal structure, there will initially be as many links as indicated by the lower multiplicity of the opposite ends of Connectors attached to that role.
With your default 1 multiplicity, this would lead to an array connector pattern (see UML 2.5.1, fig 11.7 page 188) and de facto, you'd have 2 pair of connected cars.
With an explicit 3 multiplicity, your diagram would lead to a start connector pattern (see UML, fig.11.6 page 188). Note that in view of the self reference the multiplicity of 3 is sufficient.
Of course, you could alternatively simply draw 4 blocks and draw the 6 connections existing between them. It's explcit, does require less brainpower to grasp the spririt of the design, but on the other side, it also makes the diagram a little more cluttered.
Related
I tried to model a diagram similar to the UML Sequence Diagram with Archimate.
https://forum.archimatetool.com/index.php?topic=288.0 and http://www.hosiaisluoma.fi/ArchiMate-Cookbook.pdf chap. 2.9.6 say that this is possible by using data flow relationships between application components.
So I tried to create 2 application components and 2 request-response dataflows between them:
component A and component B
request 1 from A to B
repsonse 1 from B to A
request 2 from A to B
response 2 from B to A
This was neither possible with ADOIT nor with Archi. Sparx EA allowed to create it. I could not find if the specification allows it, but in my experiance Archi is very much alligned with the spec, while EA is not.
So my questions are:
Which tool / diagram is correct according to the spec?
Is there another possibility to create a diagram similar to the UML Sequence Diagram with Archimate?
Metamodel
The metamodel of Archimate is less formally defined as for example UML, but we can find some information.
The first thing to look at is the metamodel for the Application Layer
Here we see triggers / flows to relations from/to the elements
Application Service
Application Event
Applicaiton Internal Behavior Element
An Application Component however is an Application Internal Active Structure Element as we learn from a more detailed view on the same page
So this metamodel does not allow flow relations between Application Components
Relationship Matrix
But these are not all the allowed relationships in ArchiMate. On this page there is an additional matrix with all the allowed relationships.
If you look closely you see that there is an f in the cell that represents represent Application Component x Application Component. f stand for flow
Conclusion
YES flow relations between Application Components are allowed.
BUT..
You can't simulate sequence diagrams using ArchiMate flows. A critical factor in sequence diagrams is, well the sequence. There is no way in Archimate to specify that one flow is supposed to be happen before another flow.
Can I use bidirectional arrows in Process/Activity UML diagram? Any example?
I am preparing a process diagram with swimlanes. what I encountered that many processes are cross referencing across the swim lanes. Not a good as-is design. Just want to know is it ok to use bidirectional arrows to represent such process diagram? What are the disadvantages?
The UML specs is hard to digest here. Activities/actions are connected with ControlFlows (see p. 418 of the specs). A ControlFlow itself is an ActivityEdge (see p. 411):
An ActivityEdge is an abstract class for directed connections between two ActivityNodes.
There is no constraint (I could find) that forbids bi-directional use. All examples of ControlFlows are just directed with single arrow, though.
Using bi-directional flows will not let you specify guards/behavior easily as you can not detect which is for which direction. But if you have unconditional flow it should just be fine.
Edit On p. 22 it is stated
A DirectedRelationship represents a Relationship between a collection of source model elements and a collection of target model elements. A DirectedRelationship is said to be directed from the source elements to the target elements.
DirectedRelationship inherits from Relationship which inherits from Element. ActivityEdgein contrast inherits from RedefinableElement <- NamedElement <- Element. Likely they "mean" that ControlFlow has to be directed from source to target. But in fact it's not defined.
tl;dr It's up to you if you use only uni-directional connectors as shown in examples in the spec. But per definition it's not defined (sic!) and bi-directional connectors do not violate the specs.
I'm a little confused about difference between state machine diagram and activity diagram in this specific situation.
In a follow simple schema, can you distinguish between activity or state machine diagram? The symbols are present in both diagrams.
thanks
Mauro
I now can confirm that you can't tell. On p. 331 of the UML 2.5 spec you find an example of the receive event used in a SM. The very same symbol is used on p. 409 for an AD.
So the answer is: no, you can't tell which diagram type is being used from the above example.
And more generally (from the Annex on p. 683):
NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced.
No, sometimes (like in a given example) you can't tell based only on shapes. However
usually you know upfront which diagram it is so it's not a problem actually
the names will be different. States will have nouns while actions/activities as behaviours are named with verbs
especially on SM usually there are other elements that make it distinguishable: events triggering, action within states (entry/do/exit), actions run on transitions, SM specific elements like history
while signal receipt/send signals are allowed in SM they are hardly ever used
I need a tool (preferably online, but at that stage I don't care anymore) which allows me to modelize relationships (similar to BPMN) which can be represented as compound graphs (though most of the times, it will be a simpler nested graph). I can't seem to achieve my goal using BPMN formalism (swimlanes are the closest but they do not allow arbitrary nesting). I am thinking to reuse UML modelization tools but I don't know enough about UML to know if UML covers my use case.
Imagine an integrated circuit which is made of chips connected with wires. So three chips : A,B,C and Chip A -> Chip B, Chip C. Each chip has input ports and output ports, and some of the output ports of A are connected to the input ports of B, some are connected to those of C. Now Chip A itself can be considered as an integrated circuit, and as such can be decomposed in another graph : Chip A :: Chip A.1, Chip A.3 -> Chip A.2. Each Chip A.1 can also be decomposed etc. This is what is called a compound graph. Each node of a compound graph can have children which are themselves graphs.
I do know about the Harel's and UML's statecharts formalism, which allows for hierarchical graphs to describe hierarchical nested state machines (hence any nested graph can potentially be expressed with statechart formalism), though I do not know any online tool which allow to draw statechart. The question is whether UML has a mechanism or tools which allow to specify a compound graph, and if so, what is the nesting mechanism?
Level 1
-------
---|ChipA|---ChipB---
| |---ChipC---
|-----|
Zoom on Chip A
-----ChipA.1---ChipA.2---- (...linked to ChipB input port
|--ChipA.3-| |-- (...linked to ChipC input port
An example of compound graph from the litterature :
In response to your comment,
The question is whether UML has a mechanism or tools which allow to specify a compound graph, and if so, what is the nesting mechanism?
At the infrastructure level, it uses the Element::ownedElement association to represent containment. The Namespace::ownedMember associate subsets this association, as do the association between classes and their members, packages and nested packages, components and their contained items, and so on. All of these are conceptually compound graphs, but are not rendered in a similar way to you diagrams.
In terms of you 'Chip made up of chips', the CompositeStructures package in the UML superstructure ( section 9 of the 2.4.1 superstructure ) uses these association to create composites, or for a domain specific example built on top of UML then SysML is the UML dialect created for systems engineering.
A systems engineering block diagram consists of blocks created with ports and connectors; blocks can have internal structure of further network of blocks. The connectors carry flows, whic can be information, energy or matter.
An example block diagram for some plant shows the custom rendering used to show owned elements in the same diagram as their containers:
See http://www.omgsysml.org/ or http://sysmlforum.com/sysml-faq/ for further information.
Tools for sysml are listed on the http://sysml.tools/ site.
Start with the component diagram in UML.
Your chips can be treated as components, ports will be... well, ports ;-) but also you should define some sort of interfaces (functions offered/needed by those ports). As I understand it the arrow direction depicts some sort of dependency (so the chip at the end with arrowhead provides something and thus will have a provided interface while the other end will have a required interface and a proper connection between them).
If a specific port is realised with internal structure you'll use a delegation connector for that.
I am making a structural diagram in UML using classes and objects and wondered if I was doing it correctly.
Would the following (on the right) be the correct way to represent an object diagram of the left-hand side class diagram?
No. You are using a Generalization which is not the case. Either leave that out or use a stereotyped dependency <<instanceOf>>. Note that this is no standard as per UML specs. But those specs leave you the freedom to express is this way.
The class from which the object is instantiated is already shown in the name objectName::className.
From Annex A p. 683 of the UML 2.5 specs, which describes the organization of diagram types:
NOTE. This taxonomy provides a logical organization for the various major kinds of diagrams. However, it does not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the various kinds of diagram types are not strictly enforced.