Just stumbled across this page. I understand your reasoning for why you think swim lanes are irrelevant. But I think I could convince you there are plenty of cases where they certainly are relevant. It involves the distinction between operational modeling and functional modeling. Your example is a clear case of doing functional modeling, which actually involves design decisions about what the system DOES and HOW it does it. Less well understood is that before any system designer performs functional modeling, they ought to spend a large amount of time modeling how the customer base intends to USE the system, which can be (and is) orthogonal to what actions (functions) the system performs. When modeling strictly in the operational domain, TIME is the invariant parameter. You cannot change how quickly the clock ticks. Rather, you can only decide which activities are performed in what time-oriented sequence, or you can also decide which tasks I can perform in parallel with one another. The parallel construct (AND, AKA "Fork" in SysML) is the axiomatic genesis for why swim lanes are very necessary when optimizing system operations. A swim lane is executed by a specific actor. So one could say that actor "owns" that swim lane. That swim lane describes the sequence of activities they perform in some higher level activity. Being an aircraft flight control guy, I tend to use swim lanes to show how both PILOT and CO-PILOT swim lanes interact with the AIRCRAFT system swim lane. When it comes to parallel operations diagrams, the swim lane and the fork become one in the same thing, and you really cannot do an effective job of showing how multiple actors interact over time without the swim lane/fork concept. Cheers!
Indeed very interesting. I tried to apply it, regrettably I do not manage to see the same attriputes you set (Input port / Output Port / Part). I get only "On Port". Have you an additional profile defined to get that?
Brilliant take, Mike! I see swim lanes as mere baby food until the masses are fluent and comfortable digesting/sculpting modern diagrams/models exhibiting multi-dimensional properties and classes. Unfortunately, however, getting the masses up to speed is a “Don Quixote” battle!
Would you call pilots the babies who need baby food? Swim lanes have a very important relevance, most especially when modeling current and/or future customer operations of the system you have developed or are planning to develop. (See my reply above) IMHO, SysML has tried to turn everyone involved in systems development (including users) into software programmers. Not good. A larger framework (above the SysML implementation) is still required for understanding by the larger system community. I have lived my entire career solving this problem in commercial and military flight operations and design. And I can say without variation, the biggest problems arise when engineers (systems, hardware, and software) try to force the user communities into thinking, understanding, and using the same features that engineers use in their world. I tend to think I have a solution to this continued problem, which was the foundation for the ARO 4510 Model Based System Architecture course that I teach in the Aerospace Engineering Department at Cal Poly, Pomona. In this course I teach systems thinking and base it upon a tried and tested orthogonal engineering framework. And any/all tools (be they SysML or another relational database) can all implement this simpler framework if they so choose. Just my thoughts... No offense intended.
Just stumbled across this page. I understand your reasoning for why you think swim lanes are irrelevant. But I think I could convince you there are plenty of cases where they certainly are relevant. It involves the distinction between operational modeling and functional modeling. Your example is a clear case of doing functional modeling, which actually involves design decisions about what the system DOES and HOW it does it. Less well understood is that before any system designer performs functional modeling, they ought to spend a large amount of time modeling how the customer base intends to USE the system, which can be (and is) orthogonal to what actions (functions) the system performs.
When modeling strictly in the operational domain, TIME is the invariant parameter. You cannot change how quickly the clock ticks. Rather, you can only decide which activities are performed in what time-oriented sequence, or you can also decide which tasks I can perform in parallel with one another. The parallel construct (AND, AKA "Fork" in SysML) is the axiomatic genesis for why swim lanes are very necessary when optimizing system operations. A swim lane is executed by a specific actor. So one could say that actor "owns" that swim lane. That swim lane describes the sequence of activities they perform in some higher level activity. Being an aircraft flight control guy, I tend to use swim lanes to show how both PILOT and CO-PILOT swim lanes interact with the AIRCRAFT system swim lane. When it comes to parallel operations diagrams, the swim lane and the fork become one in the same thing, and you really cannot do an effective job of showing how multiple actors interact over time without the swim lane/fork concept.
Cheers!
Indeed very interesting. I tried to apply it, regrettably I do not manage to see the same attriputes you set (Input port / Output Port / Part). I get only "On Port". Have you an additional profile defined to get that?
Brilliant take, Mike! I see swim lanes as mere baby food until the masses are fluent and comfortable digesting/sculpting modern diagrams/models exhibiting multi-dimensional properties and classes. Unfortunately, however, getting the masses up to speed is a “Don Quixote” battle!
Would you call pilots the babies who need baby food? Swim lanes have a very important relevance, most especially when modeling current and/or future customer operations of the system you have developed or are planning to develop. (See my reply above) IMHO, SysML has tried to turn everyone involved in systems development (including users) into software programmers. Not good. A larger framework (above the SysML implementation) is still required for understanding by the larger system community. I have lived my entire career solving this problem in commercial and military flight operations and design. And I can say without variation, the biggest problems arise when engineers (systems, hardware, and software) try to force the user communities into thinking, understanding, and using the same features that engineers use in their world. I tend to think I have a solution to this continued problem, which was the foundation for the ARO 4510 Model Based System Architecture course that I teach in the Aerospace Engineering Department at Cal Poly, Pomona. In this course I teach systems thinking and base it upon a tried and tested orthogonal engineering framework. And any/all tools (be they SysML or another relational database) can all implement this simpler framework if they so choose. Just my thoughts... No offense intended.
@@SepheroTech No one is a bigger fan of swim lanes than me. It's like loving pepperoni pizza, but wishing the world would/could evolve to a supreme.