Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: aljazjelen on July 21, 2021, 01:29:13 am
-
Hi everyone,
Basically I am stuck on how to properly model "variant handling" in the terms of one functionality being implemented in several different ways, where the elements (needed to implement the function) do not affect the meaning of the function itself. Enough talking, picture attached :)
https://imgur.com/a/8ycLrCl (https://imgur.com/a/8ycLrCl)
- Firstly, my thought would be to model elements like "GetData", "ProcessData", "React" as actions? That would however inherently mean to model myFunction (of each variant) as an Activity. Would you suggest otherwise?
- Secondly, my idea is to have a generic function structures. As you see, both variants have same structure, however the implementation (realization) differs. Is there any proper way to model a function once and then reuse its structure completely? For example to model "myFunction" once and then create "variants", to which I could allocate elements which are needed for realization.
- Another point, as seen in example the same Component is implementing "GetData" of variant 1 and variant 2. This is however not the case for other actions. My end-goal is to have an SQL querry which would return all dependencies if I use specific component or not.
Any help would be appreciated! :)
Thank you!
-
bump :)
-
I think the answer is: it's complicated. My customer does have a team struggling with variants since years and has not come to any conclusion yet.
q.
-
Part of the answer lies in the modelling notation you intend to choose and part of it is what programming language you intend to implement for example;
In UML and OO language you could have a use case and several use case realizations that implement the same thing differently with different objects (with attributes and operations) that behave polymorphically which are deployed as components on to Nodes. This is classic object orientation using abstract class with multiple inherited classes for polymorphic behaviour. There are design patterns you can look up.
In ArchiMate you could have an application service that is realised by different application functions and components.
Hope that helps.
-
Thank you both for answers! :)
@Sunshine I would need to use SysML as basis. Objects we are dealing with, are not only SW components but also HW elements.
As far as my minor knowledge goes, polymorphism is used in inheritence approach of SW Classes. So I dont see it applicable to HW elements. Or did you mean to model a Parent HW element, from where each conseuqent Child HW element originates from? So basically to try to "transfer polymorphism" to HW itself.
I am not sure whether I managed to explain my concern.
Best regards!
-
Yes you are right polymorphism can be realised by inheritance in software but there are other mechanisms you can use too if you programming language doesn't support it.
SysML and the HW puts some context to your problem. I used to be an electronic engineer may years ago but moved into software engineering as it paid more. I have come across a few techniques but without knowing more can't help. What I can tell you is that polymorphism is possible in HW but using mechanisms other than inheritance. The bad news for you is that the company I designed those mechanisms for have intellectual property rights over those designs, plus I don't have access to them anymore as I've left the company.
-
Yes you are right polymorphism can be realised by inheritance in software but there are other mechanisms you can use too if you programming language doesn't support it.
SysML and the HW put some context to your problem. I used to be an electronic engineer may years ago but moved into software engineering as it paid more. I have come across a few techniques but without knowing more can't help. What I can tell you is that polymorphism is possible in HW but using mechanisms other than inheritance. The bad news for you is that the company I designed those mechanisms for have intellectual property rights over those designs, plus I don't have access to them anymore as I've left the company.
(my emphasis)
Many of us took the same route! An engineering degree was a great course for teaching us to think, but computing paid more...
Paolo
-
...
Many of us took the same route! An engineering degree was a great course for teaching us to think, but computing paid more...
Paolo
Indeed there are a lot of folk in IT now from various engineering disciplines. Can't complain its been fun and paid the bills at the same time.
-
...
Many of us took the same route! An engineering degree was a great course for teaching us to think, but computing paid more...
Paolo
Indeed there are a lot of folk in IT now from various engineering disciplines. Can't complain it's been fun and paid the bills at the same time.
And from my view allows us to treat Software Development as an "Engineering discipline", not an "artistic endeavour".[1]
Paolo
[1] This is, of course, not to say that such engineered software can't be a "work of art", but that is consequent on the good engineering.