Since I have not yet completely understood the correct usage of port and interface symbols in component diagrams, a few questions:
I.
Imagine a piece of software which wants to use a very special remote logger service over network (TCP). The messages may be some XML. So the logger exposes an interface which specifies things like handshake, XML structure, XML elements etc. so that the logger will accept a message.
a) Am I right that this interface may be called "ILoggerProtocol", the port may be named after the service it provides ("logging")?
b) So the component in my application implements that interface so that it generates a compliant message for the server?
c) Now an interesting thing: for the communication, there is an additional library "Networking" which provides simple TCP stuff, so it does the TCP connect, sends messages, handles errors etc. Do I need this class when I only want to emphasise the way from the generated messages to the server? Is then MY port the TCP interface?
d) And when I want to draw the complete picture, how can I add the Networking component to the diagram correctly, pointing out that ILoggerProtocol is used AND that it goes over TCP through the Networking component?
II. Ports inside my application: now there are two libraries where one just uses the other; basically, in C/C++, it would #include the other's header file:
e) Is that the correct diagram?
f) Do I need ports here? If yes, what would they actually represent in reality? What names would you give them?
g) Or are the lollipops just sufficient without the port symbols?
III. concerning lollipops:
h) are those two notations basically the same and interchangeable? I have found the name "assembly" for the combined version, so maybe there is a difference...
A short answer first (trying to rip up the rest later): a port is an embedded element which allows to group a number of interfaces. The best I can come up for an example is a complex socket (the port) which bundles things like power supply, communication lines, you name it (the interfaces).
Now for the details.
a) Yes, that's correct. You would usually use a <<delegate>> stereotyped association to show that the outer interface is used(/realized if it's a lollipop) somewhere inside.
b) No. This is a required interface. It is used inside but implemented outside (where the lollipop resides).
c&d) I'd use a <<use>> from MyApplication towards Networking to show that. Normally you would not go into too much detail (unless it is essential). Obvious things like TCP are clearly pictured with the <<use>>
e) You can(/should) use <<include>> or <<use>> instead.
f&g) see the general answer above
h) Yes. The first is a flexible notation of the second.
P.S. Just looking over this once again and I notice that in the top picture the inner directed association should be pointing the other direction and be stereotyped <<delegate>>.
Related
I can't find what are the differences between the ports on these interfaces. What's the difference in action?
The symbols in the ports (squares) are obviously customer specific. The rest is an excerpt of a composite structure diagram. Four simple ports are shown, that offer (ball symbol) or use (socket symbol) a certain interface. So far so good. However, the connectors cannot connect the interface symbols (the balls and sockets). They must connect the ports (the squares). For simple ports (i.e. offering or using only one interface) it is an option to show the ball and socket symbol on the connector, as is done here. Another option is to show the connector connected to the interface symbols. In this case, there would be no ball and socket symbol on the connector. These are three visualizations of the same model. I usually only use a normal line between ports.
One of the projects I am working on uses flow ports to model data flow between classes. We now started to model dynamic behavior using activity diagrams and state charts and are looking for a way to express that the data used in an activity diagram has been received on a specific port. Bascially, we want to create a connector between a flow port and e.g. an activity parameter node.
I think modelling data flow with ports is quite common especially in System Engineering, and there should be ways to link the data to activities. I can think of two some ways:
Connect the port to a property (or part) and use a ReadStructuralFeatureAction to get the value
Connect the port to a property (or part) and add an operation to the class which is called with a CallOperation
Create an attribute with the same name as the port and provide an operation that is called with a CallOperation action
The first option would be ok, but our modelling tool Rhapsody 8.1 seems to not support ReadStructuralFeatureActions. The other two approaches have the drawback that there is no direct connector between the port and the activity in the model and it is not visually obvious, so I would like to have a better alternative.
I am wondering if there anybody knows of better approaches to achieve this, e.g. using SysML (1.3).
The connections between the static and the dynamic views in UML and SysML are "hidden" in the less visible part of the model. I guess the reason is that the designers of UML wanted to separate these. So there are no graphical or otherwise very explicit connections.
Instead, the connections are quite natural, so you can just use it. Examples are the guards, triggers or actions on transitions in state charts or activity diagrams. This ReadStructuralFeatureAction is implemented implicitely by using the static element directly. You can modell them directly there. So they occur next to the edge that represents the state transition or control flow. A futher way is to use Receive Actions and set the property of the reception to an event or an triggered Operation. By using Send Actions you can trigger Events in the same structural element or others. When doing so in Rhapsody you need to specify the target Port and the target part.
Neither in UML/SysML or Rhapsody it is foreseen that you want to know via which port the call came or the attribute was changed, when you offer the interface of the Class/Block. But you can realize this by using full ports and implement the intended behaviour (which sould be distinctive - otherwise it would not be needed to know the source). So each full port has a state chart or activity and passes internal signals or events the object of your class. For calling operations from actions there are two ways, the more hidden one by just calling from the actions (or state on enter or leave) and the more visible one by using call operations.
The visibility of these connections have been changed in recent UML or SysML versions. So this will change significantly when updating to later Rhapsody versions; although I would really recommend to update to the latest Rhapsody version, as it brings better sysML support, far less bugs, a few new features and better usability.
How can I route a "signal" though a Software Composition without having to copy it (with some code)?
Use-case: The SW-Composition has some RPorts where the data has to be modified and then provided on some PPorts. But for some RPorts/PPorts combination the data does not need to be touched and therefore "simply routed" from RPort to PPort.
The idea would be to simply connect the RPortPrototype with the PPortPrototype with a DelegationSwConnector. But as per specification this is not possible.
Any idea how to do this without the need of "copy-code"?
If I understand correctly that your P- and R- ports are on the composition itself (that is, they are outer ports), you can use the pass-through connector (PassThroughSwConnector model element) for your use case. It's a child element of compositions, so you add a PassThroughSwConnector to your CompositionSwComponentType, and use it to connect your two ports directly.
Note that this will be impossible if there's another path between the two ports via assembly connectors. That would create a loop consisting of pass-through and assembly connectors, which is explicitly forbidden in the specification.
Software Compositions are only a structural grouping. Before generating the Rte, you have to run a tool that creates an "EcuExtract" (see System Template) which flattens the model. So, the input for the Rte is one big root composition that contains atomic components only and no further compositions. Therefore, there will be no "copy node" and data is alway passed through.
However, (with some limitations) it is possible that in the Ecu Extract the port of the root composition has a different type then the port of the component which will lead to data conversion (e.g. rescaling the data or picking an element out of a structure).
Can I use directed named association on component diagram to show fact that "sys A" sends data to "sys B"?
Example:
No, you should use general purpose dependency instead, with optional title.
However, the title is not very common in this context. Better use some other diagrams (sequence for example) to show the communication details (e.g. open connection, send data, close connection, etc).
If there is a well defined interface between those systems, you can indicate that as well like this:
Association is used between two classes to show that their instances are potentially connected (again, not for data flow indication).
In UML 2.0 the concept behind association is vague, read this article: http://www.uml-diagrams.org/uml-core.html (search for "Semantic Relationship"). Association denotes a "semantic relationship" between two components, and I think it wouldn't be appropriate for data flow.
I think that even dependency isn't appropriate for data flows: maybe the client depends from the supplier, maybe the opposite is true... so the arrow can be very confusing.
The lollipop notation is the best, IMHO: it shows clearly that there is a component providing an interface, and another one requiring it. You can use stereotypes on the interface to show the type of communication/data transfer, and labels to make clear what data is transferred.
The book "Documenting Software Architectures" adopts another style, using prevalently associations: see p.145. It's similar to your initial proposal, but with explicit roles and without arrows. I think isn't a really satisfactory solution, without stereotypes...
If sys A sends information to sys B and you're not interested in how exactly the transmission takes place, then that is a classic application of the Information Flow connector.
A Dependency would in this case say that sys A needs (is dependent on) sys B for something. An Information Flow often (but not always) goes in the opposite direction of a Dependency, since it is typically the receiver that needs the sender.
There are many different ways of showing these types of relationships, and the best one depends on the situation. If your focus is on the type of information being transmitted, then Information Flow is the best fit. If your focus is on the way the transmission takes place, something with an Interface, possibly an Assembly, is better.
EA actually allows you to specify an Information Flow over an Assembly, so you could even combine the two. It's all down to what exactly you want to express.
Ball and socket notation is legal UML 2.0, but I cannot find a way to force EA to draw it on the diagram. It refuses to allow dependency between socket and the ball. Is there any way to make it happen, as in diagram below (little ms paint magic):
Also, a side question, can you make the ball or socket appear on the other side of the element?
There are two different ways of showing the ball and socket in EA.
With the one you've used, you've drawn connectors from your Consumer and Producer classes to the IProducer interface (a dependency and a realization, respectively).
You've then switched on display of Dependent and Realized interfaces on your classes.
Doing it this way means the balls and sockets are fixed. You cannot select them (the class gets selected instead), you cannot move them wrt their parent classes, and they cannot be endpoints for connectors.
The other way is to use Expose Interface.
With this method, you don't draw any connectors from your classes to the interface. Instead, you use Expose Interface to create an embedded element, which has the interface as its classifier, in each class.
These exposed interfaces, being elements in their own right, behave the way you want them to: you can move them around the perimeter of their respective classes, and you can draw connectors between them.
In the example, note the absence of any connectors to the IProducer interface element.
In order to expose the interfaces, there are two ways to go about it. You can select Expose Interface in the diagram toolbox, but note that that's only available in the Component toolbox - not the Class toolbox. That's what I've done with the Producer in this example.
The other way is to right-click the class and select New Element -> Port. This creates a port, which you can give any name. Then you right-click the port and select New Element -> Provided / Required Interface.
Either way brings up the Exposed Interface dialog, which allows you to select the interface element that should be exposed by using the ellipsis button (...) and browsing the project tree for interfaces.
Using a port may seem a bit cumbersome but it is, strictly speaking, more correct UML. Note also that a single port can expose several interfaces, both provided and required, allowing you to group interfaces which form some sort of logical unit. It might be that you have several interfaces which form one service and so go together, but that the class provides and requires several services.
This (to me) makes more sense when you're discussing not individual classes but rather components, and I generally use realization/dependency whan I'm modelling classes, and ports and exposed interfaces when I'm modelling components.
In EA ball and socket connections can (only) be drawn between ports. Use the "assembly" connector type.
It is right that ball and socket are legal UML 2.0 notation but they are not UML element, they depict element relations. So I guess that depending of the tool you use it will (or will not ) allow you to create a dependency between them. According to UML specification, a UML dependency should be create between, at least, two NamedElements.