Thanks for the continuous flow of guidance and advice, I can hardly catch up. With respect to traceability I'm currently struggling with EAs way of handling AllocateActivityPartitions in SysML. I know there are some pitfalls around allocating usage (Action -> Part) and definition (Activity -> Block) and the potential to mess this up. But EA seems to have chosen not to show any of the graphical allocation with partitions in the Traceability window (Cameo might differ). Could you elaborate on the usage of different stereotypes on the AllocateActivityPartition, the difference between assigning a Classifier and the 'Represents'-property, how to select a part to be represented for usage-level allocation (I failed to do so), and how to navigate a relation that's modelled by placing elements in Partitions? Is SysML or EA enforcing ownership of Activities->Partitions->Actions? If yes, then you probably shouldn't move the AllocationPartitions into a separate package - what is then a good way to clean up and structure your model? Then I struggle with navigating from definition to usage, e.g. why can't I see every invocation (action) of an Activity in its Traceability view? I only discovered 'Find in all diagrams' as an indirect way. Do you have an opinion in the callBehavior vs callOperation debate? Which of Operations, Activities, Actions (if any) would you propose to transport Functional Requirements from Problem to Solution Domain, which likely is a separate model? I'd also aprecciate a deep dive into the semantic meaning of Action vs Activity. Is it valid to think of them analogous to e.g. a function definition and calling other functions in the body of the function? When is it advisable to use only opaque Actions without a relation to an Activitiy or Operation and what would be the analogy to functions here? Not yet defined? Or the called function is declared but not defined in scope? Anyway, thanks a lot for your great work!
First off, THANK YOU!! What a great post filled with challenges! I see at least 7 questions in your post, which guide me to even more questions, such as "When to turn SysML modeling data into Analytics (questions on data)?", "How to extract or abstract intelligence from model-driven data?", and many more. Summary of questions: 1) How to navigate a relation that's modeled by placing elements in Partitions? 2) Is SysML or EA enforcing ownership of Activities->Partitions->Actions? 3) Why can't I see every invocation (action) of an Activity in its Traceability view? 4) Do you have an opinion in the callBehavior vs callOperation debate? 5) Which of Operations, Activities, Actions (if any) would you propose to transport Functional Requirements from Problem to Solution Domain, which likely is a separate model? 6) Is it valid to think of them analogous to e.g. a function definition and calling other functions in the body of the function? 7) When is it advisable to use only opaque Actions without a relation to an Activity or Operation and what would be the analogy to functions here? Not yet defined? Or the called function is declared but not defined in scope? Conclusion I have been trying to get to the topic of SysML since early 2024. This is an Advanced Topic for CASE Engineers. So much in fact, that we pushed it to a Members Only approach in the Online Courses we are creating for 2025. Let me see what we can put together for this UA-cam channel and I will keep you posted. The plan was to start with "The Introduction to SysML", but we may produce a video, in advance, to the "introduction" video to tackle these questions. I am not sure what industry you are in, but our use case may be around ML, AI, and Robotics (an area I have been working in). Thanks again for the post! Happy Modeling
It seems the main process diagram is not fully compliant with BPMN in few aspects (in fact there are two separate processes on customer and company side, lack of messages instead of flows, and process continauation on customer side)
Thank you for the post. I would agree with that, and there is a lot missing from this demo model to be able to effectively compile. The point of the video was around using traceability to find such issues. Again, thank you for the observation and feedback.
Yikes, voice audio is out of sync with video due to new recording equipment. Sorry about that 😶. We are resolving for future videos 😄
Thanks for the continuous flow of guidance and advice, I can hardly catch up.
With respect to traceability I'm currently struggling with EAs way of handling AllocateActivityPartitions in SysML.
I know there are some pitfalls around allocating usage (Action -> Part) and definition (Activity -> Block) and the potential to mess this up. But EA seems to have chosen not to show any of the graphical allocation with partitions in the Traceability window (Cameo might differ).
Could you elaborate on the usage of different stereotypes on the AllocateActivityPartition, the difference between assigning a Classifier and the 'Represents'-property, how to select a part to be represented for usage-level allocation (I failed to do so), and how to navigate a relation that's modelled by placing elements in Partitions?
Is SysML or EA enforcing ownership of Activities->Partitions->Actions? If yes, then you probably shouldn't move the AllocationPartitions into a separate package - what is then a good way to clean up and structure your model?
Then I struggle with navigating from definition to usage, e.g. why can't I see every invocation (action) of an Activity in its Traceability view? I only discovered 'Find in all diagrams' as an indirect way.
Do you have an opinion in the callBehavior vs callOperation debate? Which of Operations, Activities, Actions (if any) would you propose to transport Functional Requirements from Problem to Solution Domain, which likely is a separate model?
I'd also aprecciate a deep dive into the semantic meaning of Action vs Activity. Is it valid to think of them analogous to e.g. a function definition and calling other functions in the body of the function? When is it advisable to use only opaque Actions without a relation to an Activitiy or Operation and what would be the analogy to functions here? Not yet defined? Or the called function is declared but not defined in scope?
Anyway, thanks a lot for your great work!
First off, THANK YOU!! What a great post filled with challenges!
I see at least 7 questions in your post, which guide me to even more questions, such as "When to turn SysML modeling data into Analytics (questions on data)?", "How to extract or abstract intelligence from model-driven data?", and many more.
Summary of questions:
1) How to navigate a relation that's modeled by placing elements in Partitions?
2) Is SysML or EA enforcing ownership of Activities->Partitions->Actions?
3) Why can't I see every invocation (action) of an Activity in its Traceability view?
4) Do you have an opinion in the callBehavior vs callOperation debate?
5) Which of Operations, Activities, Actions (if any) would you propose to transport Functional Requirements from Problem to Solution Domain, which likely is a separate model?
6) Is it valid to think of them analogous to e.g. a function definition and calling other functions in the body of the function?
7) When is it advisable to use only opaque Actions without a relation to an Activity or Operation and what would be the analogy to functions here? Not yet defined? Or the called function is declared but not defined in scope?
Conclusion
I have been trying to get to the topic of SysML since early 2024. This is an Advanced Topic for CASE Engineers. So much in fact, that we pushed it to a Members Only approach in the Online Courses we are creating for 2025. Let me see what we can put together for this UA-cam channel and I will keep you posted.
The plan was to start with "The Introduction to SysML", but we may produce a video, in advance, to the "introduction" video to tackle these questions. I am not sure what industry you are in, but our use case may be around ML, AI, and Robotics (an area I have been working in).
Thanks again for the post!
Happy Modeling
It seems the main process diagram is not fully compliant with BPMN in few aspects (in fact there are two separate processes on customer and company side, lack of messages instead of flows, and process continauation on customer side)
Thank you for the post. I would agree with that, and there is a lot missing from this demo model to be able to effectively compile. The point of the video was around using traceability to find such issues. Again, thank you for the observation and feedback.