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).
Related
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>>.
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.
I'm learning DDD and Hexagonal architecture, I think I got the basics. However, there's one thing I'm not sure how to solve: how am I showing data to the user?
So, for example, I got a simple domain with a Worker entity with some functionality (some methods cause the entity to change) and a WorkerRepository so I can persist Workers. I got an application layer with some commands and command bus to manipulate the domain (like creating Workers and updating their work hours, persisting the changes), and an infrastructure layer which has the implementation of the WorkerRepository and a GUI application.
In this application I want to show all workers with some of their data, and be abe to modify them. How do I show the data?
I could give it a reference to the implementation of WorkerRepository.
I think it's not a good solution because this way I could insert new Workers in the repository skipping the command bus. I want all changes going through the command bus.
Okay then, I'd split the WorkerRepository into WorkerQueryRepository and WorkerCommandRepository (as per CQRS), and give reference only to the WorkerQueryRepository. It's still not a good solution because the repo gives back Worker entities which have methods that change them, and how are these changes will be persisted?
Should I create two type of Repositories? One would be used in the domain and application layer, and the other would be used only for providing data to the outside world. The second one wouldn't return full-fledged Worker entities, only WorkerDTOs containing only the data the GUI needs. This way, the GUI has no other way to change Workers, only through the command bus.
Is the third approach the right way? Or am I wrong forcing that the changes must go through the command bus?
Should I create two type of Repositories? One would be used in the domain and application layer, and the other would be used only for providing data to the outside world. The second one wouldn't return full-fledged Worker entities, only WorkerDTOs containing only the data the GUI needs.
That's the CQRS approach; it works pretty well.
Greg Young (2010)
CQRS is simply the creation of two objects where there was previously only one. The separation occurs based upon whether the methods are a command or a query (the same definition that is used by Meyer in Command and Query Separation, a command is any method that mutates state and a query is any method that returns a value).
The current term for the WorkerDTO you propose is "Projection". You'll often have more than one; that is to say, you can have a separate projection for each view of a worker in the GUI. (That has the neat side effect of making the view easier -- it doesn't need to think about the data that it is given, because the data is already formatted usefully).
Another way of thinking of this, is that you have a "write-only" representation (the aggregate) and "read-only" representations (the projections). In both cases, you are reading the current state from the book of record (via the repository), and then using that state to construct the representation you need.
As the read models don't need to be saved, you are probably better off thinking factory, rather than repository, on the read side. (In 2009, Greg Young used "provider", for this same reason.)
Once you've taken the first step of separating the two objects, you can start to address their different use cases independently.
For instance, if you need to scale out read performance, you have the option to replicate the book of record to a bunch of slave copies, and have your projection factory load from the slaves, instead of the master. Or to start exploring whether a different persistence store (key value store, graph database, full text indexer) is more appropriate. Udi Dahan reviews a number of these ideas in CQRS - but different (2015).
"read models don't need to be saved" Is not correct.
It is correct; but it isn't perhaps as clear and specific as it could be.
We don't need to create a durable representation of a read model, because all of the information that describes the variance between instances of the read model has already been captured by our writes.
We will often want to cache the read model (or a representation of it), so that we can amortize the work of creating the read model across many queries. And various trade offs may indicate that the cached representations should be stored durably.
But if a meteor comes along and destroys our cache of read models, we lose a work investment, but we don't lose information.
I'm planning my first architecture that uses DTOs. I'm now exploring how to map the modified client-side domain objects back to the DTOs that were originally retrieved from the data service. I must map back to the original object graph, instead of instantiating a new one, in order to use WCF Data Services Client Library's change tracking feature.
To put it in general terms, I need a tool that maps instances and (recursively) their sub-instances (collectively called the "source graph") to existing instances and (recursively) sub-instances (collectively called the "target graph") in a manner that is (nearly) 100% convention, rather than configuration, based.
The specific required functionality that I can think of is:
Replace single-valued properties within the target graph with their corresponding values from the source graph.
Synchronize collection pairs: elements that were added to a collection within the source graph should then be added to the corresponding collection within the target graph; elements removed from a collection within the source graph should then be removed from the corresponding collection within the target graph.
When it comes to mapping DTOs, it seems many people use AutoMapper. So I had assumed this task would be easy using that tool. Upon looking at the details, though, I have doubts it will fit my requirements. This indicates AutoMapper won't handle #1 so well. Equally so, this indicates AutoMapper won't help much with #2 either.
I don't want to try bending AutoMapper to my purposes if it will lead to a lot of configuration code. That would defeat the purpose of using a convention-based tool in the first place. So I'm wondering: what's a better tool for the job?
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.