I think you makes a critical point in this segment about modeling robust software systems, Leon. That is: The sequence of building your models should be based on the relative stability of each model, starting with the most stable one first. This produces a structure/organization to the models, and your resulting software system, that is most resilient to (the inevitable) change. Good work bringing this critical, if subtle, point forward!
Excellent explanation of why the domain-class-state hierarchy has much better longevity than the (still depressingly popular) top-down functional decomposition strategy. Thanks, Leon.
Thanks Chris! Yeah, I realized to my horror that functional decomp was making an uninformed comeback and couldn't help myself. And really nice to hear from you as well!
In this module, Leon introduces a subtle, but EXTREMELY IMPORTANT issue: model stability. Instability is indeed a demon, one which can cause such defects and cost overruns that a project may collapse. When I present this idea to students, I ask them: "You're planning to take some vacation road trips around a US state that you've never visited before. What do you need?" The best answer is "a map". Why? Because the static terrain and the location of cities and the roads relating them don't change much over decades. Your dynamic road trips, on the other hand, may get changed a dozen times. Indeed, without a map, even the feasibility of those road trips is hard to figure. Classes in a model are constrained by the reality of the domain being modeled. That reality is surprisingly concise and stable - at least it is if you're smart enough to understand the domain properly! Dynamic behavior is constrained by functional requirements, which derive from business needs and human imagination (along with resource availability etc.) So functions can be as numerous as possible journeys and they can be as volatile as your vacation journey plans. (If you prefer a different analogy: try doing chemistry without understanding the domain of atomic elements!)
I think you makes a critical point in this segment about modeling robust software systems, Leon. That is: The sequence of building your models should be based on the relative stability of each model, starting with the most stable one first. This produces a structure/organization to the models, and your resulting software system, that is most resilient to (the inevitable) change. Good work bringing this critical, if subtle, point forward!
@@michaellee3356 Thanks!
Fantastic video series!
@@jonatanpalmquist2202 Thanks!
Excellent explanation of why the domain-class-state hierarchy has much better longevity than the (still depressingly popular) top-down functional decomposition strategy. Thanks, Leon.
Thanks Chris! Yeah, I realized to my horror that functional decomp was making an uninformed comeback and couldn't help myself. And really nice to hear from you as well!
In this module, Leon introduces a subtle, but EXTREMELY IMPORTANT issue: model stability. Instability is indeed a demon, one which can cause such defects and cost overruns that a project may collapse.
When I present this idea to students, I ask them: "You're planning to take some vacation road trips around a US state that you've never visited before. What do you need?"
The best answer is "a map". Why? Because the static terrain and the location of cities and the roads relating them don't change much over decades. Your dynamic road trips, on the other hand, may get changed a dozen times. Indeed, without a map, even the feasibility of those road trips is hard to figure.
Classes in a model are constrained by the reality of the domain being modeled. That reality is surprisingly concise and stable - at least it is if you're smart enough to understand the domain properly!
Dynamic behavior is constrained by functional requirements, which derive from business needs and human imagination (along with resource availability etc.) So functions can be as numerous as possible journeys and they can be as volatile as your vacation journey plans.
(If you prefer a different analogy: try doing chemistry without understanding the domain of atomic elements!)
@@Meilir1 Thanks, Meilir - Spot on as always!
@@modelintegration This is great stuff, Leon. I'm impressed.
Great Video! Thanks for sharing!
@@brianMoberley Thanks, Brian. And I just bought your book AI Assisted MBSE on my kindle. Looking good so far, highly relevant topic, and great work!