Messages

16

Automation Interface, Add-Ins and Tools / Re: Redefining an ArchiMate element does not work as expected?

« on: July 03, 2024, 05:38:32 pm »

Could it depend on where the MDG is located?
If the MDG is saved within the same model's Resources then maybe relaunching EA is not necessary, but with an MDG saved to the local disk I guess the relaunch is needed so that EA goes to the disk (/server) and brings in the MDG definition from the xml again.
Just a guess based on some thing I've been doing recently.
In any case, I'm with the rest of you - "Troubleshooting step 1 is to turn it off and on".

17

General Board / Re: Relationship directionality and verbs

« on: June 26, 2024, 07:20:00 pm »

Composite Aggregation a part can only belong to one whole at a certain moment in time. (and will be destroyed with the whole if not detached)
Shared Aggregation a part can belong to many wholes at the same time. When a whole is destroyed all parts remain.

This bit seems critical and is certainly very useful to me in understanding the difference.
Thankyou for these clarifications!

18

General Board / Re: Relationship directionality and verbs

« on: June 25, 2024, 09:03:56 pm »

Have slept on this and I think I'm overthinking it. I think.
The reason I'm having a hard time coming to a clear conclusion is because the problem I'm tackling at work has multiple viewpoints, from which Aggregation or Composition could variably make sense.
It relates heavily to my thread in a different sub-forum so I'll stop hijacking this one and I'll take the discussion over there to keep it all in once place.

https://sparxsystems.com/forums/smf/index.php/topic,48546.msg281535.html#new

19

General Board / Re: Relationship directionality and verbs

« on: June 25, 2024, 01:11:33 am »

With respect, I believe the composition relationship is not as you describe it.  You may be confusing the classifier with the instance.  You are correct in asserting that destroying (not deleting - more later) the Car classifier doesn't destroy the Wheel classifier.  However, at the instance level, if the wheel is attached to the car, it must be destroyed with the car (think "nuked")!  However, the wheel may be detached from the car (and therefore no longer participates in the composition) then it survives.

This is the essential difference between composite aggregation (aka "Composition") and shared aggregation (aka "Aggregation").  Aggregation is like Team membership, you can destroy the team without destroying the players.  Also, a player can be in more than one team at the same time whereas the wheel can only be on one car at a time.  The other distinguishing mechanism for which type of "holonymy is in play".

As I said, I treat every day as a school day. Looks like I need to go back to class, or at least wake up properly before posting.
I'd love to understand the philosophical aspects of all this a whole lot better. For one thing, the subtle difference between 'delete' and 'destroy' which I had never really understood properly.

*Could* you say that the 'car/wheel' Relationship can be described as both Aggregation AND Composition when considering either classifiers or instances? i.e.
> Aggregation in that there is not really any such thing as a 'car', that's just what you end up with by collecting (aggregating) enough bits and pieces (including, but not limited to, Wheels) together and attaching them in the right order. But any one of those pieces (e.g. 'Wheel' or 'Chassis') can exist perfectly well on its own without having to be 'Part of a Car'
> Composition in that once you destroy an instance of a Car, all of its constituent Parts (e.g. its 'wheel' instances) are also considered destroyed

At one point I thought I understood these concepts but now I'm not so sure...



Also major apologies for hijacking the thread, happy to continue this privately unless it is useful to other people too?!

20

Uml Process / Relationships between Design Abstraction Layers

« on: June 24, 2024, 07:26:46 pm »

I'm working up a SysML design ontology with the 'normal' abstraction layers for our industry: System > Functional > Logical > Physical.
By chance, I'll be broadly following an approach that was previously described in this paper [1] (though I only found the paper after I'd documented my own approach!).
I'll be using Blocks to represent structural entities at System level (i.e. 'The System'), as well as Blocks in each of the lower abstraction layers - e.g. maybe a "FunctionalBlock" classifier to represent a function called 'Routing Function' that routes data around the system. No shockers there.

I'm fairly sure of the SysML Relationships I want to use between the layers, but I wanted to canvas opinion on how to link structural Blocks in the System layer to those in the Function layer. There are many options with different implications. E.g:

- Aggregation (the system as an Aggregation of functions) - this implies that after destroying the system the functions remain, but I kind of like that in terms of building a catalogue of common definitions for functions that I can then use in multiple product designs...
- Composition (the system Composed of functions) - maybe makes more sense in that once the System is destroyed there is also no longer a group of Functions to do the things that it was previously doing...?!
- Allocation (Functions Allocated to a top-level 'System' definition) - seems a bit looser to me and possibly implies something a little bottom-up rather than top-down, which I'm not comfortable with. My Allocations will go down, not up (i.e. Allocating functionality onto lower-level components)
- Association - too weak for Structural definition
- Containment (the system Contains functions) - again, probably too weak for my liking... the means of decomposition wouldn't be implicit enough without further explanation of how the structural function layer is contained within the system layer


Would appreciate any thoughts!


[1] https://incose.onlinelibrary.wiley.com/doi/abs/10.1002/j.2334-5837.2017.00350.x

21

General Board / Re: Relationship directionality and verbs

« on: June 24, 2024, 06:43:11 pm »

It's not a SysML thing, I think it was related to UML in the past.  Also, when EA (and UML) had Composition Relationships (UML 1.x) as distinct from Associations (rather than as today, an Association with the ends marked with the appropriate holonymy marker), you could have EA draw them in weird ways - adding to the potential confusion.

Ah ok, I don't really have the history on EA (only used v9, 15 and 16) so I haven't experienced it from all angles. Thanks for the background!

Back to the issue of the implication that a car only consists of wheels, I acknowledge that I spoke somewhat incorrectly.  Why have I italicised somewhat?  The original UML point was that just as it was a consequence of the Composition relationship that when the holonym was destroyed, any currently attached meronyms would also be destroyed, it follows that when ALL the meronyms of a holonym are destroyed, the holonym is, ipso facto, destroyed (the essential difference between an aggregation and a composition).  The problem is that there may be more than one composition relationships that make up the holonym.  I should have been clearer.

No I think you were probably clear enough - again without decdes of experience in UML probably some of this has passed me by; 'every day is a school day'!
I agree with your point about Composition in the context of the wheel/car definition (deleting the car does not delete the wheels, and there will be other things that the car is composed of...).

In SysML, (I don't use it yet), is the source (origin) the meronym (part)  or is it the holonym (whole)?  In our modelling, the meronym is always the origin and the holonym the destination. The semantics we use require that the naming be origin to destination.  So while I agree that composes into is a bit clunky - it is consistent with the requirements we have.

Agreed. I would also say that the Part/meronym is the source/origin and that the whole/holonym is the target (consistent with SysML spec definitions,although I'm struggling to find a specific section reference in there - but it will be the same definition as in UML).

22

General Board / Re: Relationship directionality and verbs

« on: June 21, 2024, 05:25:34 pm »

we use:
Wheel composes into Car.  Car is composed of Wheel. However, I don't like the second.  One could use Car includes Wheel (removing the implication that a car consists ONLY of wheels).

Interesting. I don't think there is anything in the SysML spec to suggest that a Composition Relationship is restrictive to *only* those Elements that partake in that Relationship. I don't think the English language implies that either. If anything , 'composes into' sounds very clunky to me (doesn't really make sense in English). But I'd probably never read it that way round - the Relationship is directed, with a source and target, so I would *always* read it as "A Car is Composed of Wheels (as well as potentially other things too that are not described by this Relationship".

23

Automation Interface, Add-Ins and Tools / Re: Controlling the name and order of the toolbox in a View Specification

« on: June 20, 2024, 10:12:37 pm »

Good to know that I didn't miss a major benefit of View Specifications.
...
And just like you with tell them: use diagram X in location Y to communicate Z

No, you didn't miss anything, sounds like we're very much on the same page!

24

Automation Interface, Add-Ins and Tools / Re: Controlling the name and order of the toolbox in a View Specification

« on: June 20, 2024, 06:51:31 pm »

I understand that, but we have always defined toolboxes for that purpose. It seems like view specifications and toolboxes are two ways to reach the same goal.

They're definitely similar, and I've read various threads on this forum that come to that conclusion.
The only difference from my persepective is that with the View Specification I can add custom diagram types to the 'New Diagram' dialogue, with a limited set of tools available when using that diagram (in the toolbox and in the quicklinker, using the stereotyped relationships and metaconstraints in my profile). Then we can tell our engineers 'We need a [diagramtype] diagram to communicate [some meaning]', rather than 'we need a BDD to communicated [some meaning]', and then all projects will deliver the same diagram with the same type of content to communicate that same meaning.

I agree we could achieve this with only the MDG profile and its toolboxes, but that would rely on the engineers knowing 'a little bit' more than they currently do about MBSE delivery.

In any case, I'm not planning to define many View Specifications, as there are limitations (e.g. the 'toolbox ordering' issue described here) and I would hope that the engineers don't need them as they become more familiar with MBSE and our internal engineering/delivery processes.



...also worth noting that this is the first time I've used View Specifications so if they turn out to be of limited value in practice then I'll probably abandon them and rely on the profile itself, as you suggested.

25

Automation Interface, Add-Ins and Tools / Re: Controlling the name and order of the toolbox in a View Specification

« on: June 20, 2024, 05:45:43 pm »

I've never really felt the need for view specifications.
What make you want to use them?

For me, it will make the MDG Technology more accessible to our engineers who are still becoming familiar with MBSE. I want to create views, tools etc that are maybe a little 'more' prescriptive than would be normal, so that it is more intuitive for people to build a model using terminology from our industry rather than having to immediately learn the entire SysML spec by heart. it's maybe not ideal, but my intention is that our engineers will gradually pick up the SysML side of it while also adding value to the model by doing work. So the View Specifications will allow me to give a user the tools they need for a particular task without distractions from things they don't understand.

In the long run, or if we had a team of seasoned MBSE engineers, I agree that the effort required to specify, produce and manage View Specifications may negate any benefit you would gain from them. It's useful for us in the transition period though.

If an MDG Technology contains exactly one toolbox definition, any view specifications will take the order and grouping of the items in that toolbox for any view specifications that are defined within the technology.

Thanks, this is useful to know (and I guess fairly obvious on reflection). My MGD Tech has several toolboxes though (rightly or wrongly) so I guess I'm stuck with the alphabetical groupings in the ViewSpec. Like I said, not the end of the world - the tools are all available in the right places, our engineers will just need to learn the alphabet

26

Automation Interface, Add-Ins and Tools / Re: Controlling the name and order of the toolbox in a View Specification

« on: June 19, 2024, 09:06:33 pm »

Apologies for resurrecting an old topic but I have this exact same problem (build 1628).
In my profile's toolboxes the Elements/Relationships are ordered in a particular way, but when the ViewSpecification Exposes those Elements/Relationships they are all just lumped into one toolbox in alphabetical order. The View Specification doesn't seem to be able to Expose the toolbox itself either, which is a shame.

It's not the most significant problem in the world (all the tools are available in the View, just in a funny order) but if there is a way to achieve this I would greatly appreciate knowing please

27

Uml Process / Re: Modeling Calls between operations

« on: June 18, 2024, 06:20:08 pm »

There are a few ways to model behavior. Sequence diagram and Activity diagrams are the suited for this.

I don't think it's a good idea to try and mix structure and behavior aspects into one diagram...

ownership in EA is not expressed in diagrams at all, unless you create a nesting connector yourself

(slightly off-topic...)
Really good points. I often find that Allocate is useful here too.
Stakeholders/Managers etc often want the 'everything-on-one-page' view, but as Systems Engineers we still need to educate that SysML serves a particular purpose, and 'bending the rules' is sometimes useful but often just adds confusion. It's one of the big benefits and also big pitfalls of EA - it's super flexible and lets you bend the rules a bit, but we do have to be careful that what we end up with is still correct and meaningful (especially when we need the model to do even basic things for us like checking traceability, consistency, design queries, simulations....)

28

Uml Process / Re: Modeling Calls between operations

« on: June 14, 2024, 05:45:52 pm »

I assume you are using a Sequence Diagram. In which case it doesn't really make sense to represent Operations as lifelines. Lifelines are intended to be typed by a Classifer, and I think the UML spec is restrictive that those classifiers do not (cannot) include Operation as a classifier for the lifeline. That semantic distinction is probably why SysML tools (like EA) don't support what you are trying to show (Operations as lifelines) and is probably why you're struggling to get it to represent that way.

One solution could be to model your Operations as Classes (Blocks) and then you will be able to have lifelines that represent your Operations. You'd need some kind of Relationship between your 'Operation' pseudo-Block and the actual Block that owns the associated Operation... but it probably also depends on exactly what you are trying to communicate, who you are communicating to and how bothered they are about syntax & semantics.

29

General Board / Re: EA 17 Beta install removed my EA 16

« on: June 07, 2024, 05:40:39 pm »

Seem to recall it is possible to have multiple installations if you install in different folders.

Will do some more investigation.

Henrik

Yes.
I have 15.2 in [C:\Program Files (x86)] and 16.1 in [C:\ProgramFiles].

30

General Board / Re: Do you model separate blocks when creating interfaces in SysML?

« on: May 16, 2024, 06:32:25 pm »

PDC, so if I understand your response correctly, that means then that blocks own properties representing the data items that are transmitted/received. So for example a block owns a property called Gasoline, typed by something like Liquid. It owns another property called Water also typed by Liquid. As we create the ports and connections, we relate the ItemProperties to the Properties of the owning blocks and that is what makes it clear to the reader where the information is going.

FlowProperties are owned by an InterfaceBlock.
FlowProperties are typed by a Classifier.
The Blocks in the design have Ports that are typed by the InterfaceBlock.

So one way (probably not the only way) to model our gasoline scenario could be: 'InterfaceBlock1' owns an incoming Flowproperty called 'gas-in' which is typed by a Classifer 'Gasoline'. And the Classifier 'Gasoline' may be a Generalization of another Classifier 'Liquid' (purely to support definition of other subtypes of liquid). Then there are multiple Blocks that have Ports, and the Ports are typed by 'InterfaceBlock1'. The Ports are connected (on an IBD) by InformationFlows, for which we use the 'Information Items Conveyed' context menu to add Information Items typed by the 'Gasoline' classifier.

All of that produces an IBD consistent with the Distiller one in your latest post (saves me working out how to upload screenshots )
It looks like the Distiller example uses Blocks ('H2O', 'Heat', 'Residue' & 'Fluid') to type the Ports, rather than InterfaceBlocks. This seems kind of a little naughty to me but there may be good reasons for doing so that I'm not aware of.