Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: r2 on May 03, 2018, 05:25:24 am
-
Hello all,
for my thesis I am about to model a System Architecture for a software intensive product with several views (requirements, use-cases, functional, technical, ...) and variants / deployments. What would be the better choice, UML or SysML?
Due to the fact that I need to place the same block/class/component several times onto the one technical and deployment diagram, what suits better in the long run considering a system architecture for a software intensive product. I am aware of such things as classes-instances-objects and so on (OOP is well known).
According to literature, UML is supposed to have some drawbacks when using it as system architecture language.
Thanks
-
I think that both are valid system modeling languages. However, if you are going to model controller firmware (or similar more hardware oriented things) I think that SysML would be the choice. I have never used a pure SysML tool (is there one?) but always used UML with a SysML profile. Specifically I borrowed quite a bit from what SysML offers and realized that in a MDG for EA. That had quite some advantages when it came to describing connections between different (hardware) components. I even used a lighter form for describing components of a large business system. IIRC SysML is an independent design. But it fathers and mothers likely were in tough with UML. And the fact that you can use UML profile to make it fit SysML still lets me think that UML is the more versatile base.
q.
P.S. Please don't mind that I voted to close your question on SO. This here is a forum and you can gather opinions as you like :-)
-
I mean there must be SysML for some reason (?) and as you pointed out the tooling is a SysML profile in a UML tool (like EA;). But what I actually want to avoid is a mixture of SysML/UML elements in one view resp. diagram (hard to achieve since SysML is an offspring of UML). There are some differences between a SysML::Block and UML::Class/UML::Component, SysML::Act and UML::Act (at least to my knowledge), in addition there are some SysML constructs like flow properties that are non existent in base UML. Since the Software Architecture is already done in UML, elaborating the System Architecture in UML would be the convenient way. But is it the better option in the long run? Unfortunately SysML 2.0 will take some time until release and can not taken into account for comparison.
-
If the system is software-only, then UML probably has everything you need. If there is a significant hardware aspect to it as well, then SysML constructs can be helpful as well. For example, specifying and designing the software for a medical device can be done well with UML. If you also want to model the hardware, then SysmML BDD's and IBD's add value beyond UML for modeling the hardware aspects of the system.
-
As said, I was happy with plain UML and setting up my own profile having borrowed from SysML (it was rather hardware oriented). I'd probably recommend that in most cases. Sticking to pure SysML (or pure UML) as bible isn't reasonable (except you have forced requirements for what ever reasons). I think the key is setting up a good profile for the domain you're working in.
q.
-
As said, I was happy with plain UML and setting up my own profile having borrowed from SysML (it was rather hardware oriented). I'd probably recommend that in most cases. Sticking to pure SysML (or pure UML) as bible isn't reasonable (except you have forced requirements for what ever reasons). I think the key is setting up a good profile for the domain you're working in.
Isn't reasonable if you know what you're doing. Where I see a lot of people going wrong is trying to get too fancy before they really understand what modelling really is.