Wednesday, December 21, 2011
Associative Reality
Aggregation (white diamonds), composition (black diamonds), simple associations, directed associations, and ownership(containers) are steak and potatoes of object oriented structures and our favorite modeling language, UML. I recently worked with a client that used composition for parts of a configuration rather than aggregation which seems logical given the reuse of parts between configurations. This was SysML, but the standard used the common UML concepts and meaning. The customer used composition for configuration relationships because the concept itself was light weight, i.e. the car configuration was a configuration of car, not a true car.
You might say an illusion owns elephant, thus when the illusion dissipates, so does the elephant. Or for you dessert rats, the water in the mirage is gone when the mirage is gone. In a car, the parts are created and destroyed like arms and legs, but when we stop creating a model of car, it ceases to own the responsibility for those parts. Another model of car may be composed of the same radio, but they are not shared nor does deleting one car model destroy the other's parts.
It may be that we are always struggling to pin our hopes and dreams on our ability to control our destiny through these concepts when they are the wrong hopes. Take for instance, directionality of relationship. This is pure software isolation, not system engineering. What if I know your name, but you do not know mine... yet? Is that bidirectional? Does an engine know the transmission it is connected to and vis versa? Yet both have effects on each other via linkage.
Aggregate/composite/owns are software terms and perhaps not as applicable to the real world. It would be interesting if we dug into the haggis of software concepts to find why and where these terms originated. They certainly loose their shine when applied to systems engineering.
Sunday, May 22, 2011
Moon Buggy
Was watching Moon Machines on the Science Channel today. Here is a great quote from Alex Kosmala, Flight Software Developer, MIT Instrumentation Laboratory:
There were no specs. We made it up. And its always amazing to me, why was I allowed to program something that hadn't even been specified, that would be critical in assuring the success of the whole Apollo space program. I couldn't believe it. But, that's the way it was. We made it up as we went along.
Saturday, March 26, 2011
UML helps you prevent your brain from exploding
Yep, UML helps you keep your head. Just take an actor in a use case diagram. Why is it a stick figure? Perhaps because we are not artists. Imagine having to draw whistler's mother everry time we're representing a user. Go ahead, we'll wait for you to imagine how hard this would be.
What about class diagrams? Think about it for a second, based on how hard it is to imagine a couple thousand lines per class of spaghetti (just 100 lines lasagna if you are good programmer). A class diagram symbol is just a symbol. At most we define name, attribute and method signatures. We do this for good reason. To add more detail implies we actually can absorb, understand, and remember the complete program.
The facts are, we are sloppy and lazy. We can't keep more than a few things in our heads at one time. Sure we match patterns, but not thousands of lines of Java at the same time. We think linearly. We also are not savants with photographic memories.
Sorry, no idiot savant here. We need a crutch. That's UML.
Developed by nerds, not artists, UML is a cartoon of symbols, not a detaied 3d representation. UML is ugly and unimaginative. Ugly is good. You don't buy ugly a new car from irrational imaginings of a good time. Ugly is functional.
People complain that UML is confusing. Sure, that's true, but only if you don't understand UML, or objects, or in fact have the ability to abstract life and the world. UML is just a language of symbols. You need to learn to read and write before the alphabet is really useful.
Ok, enough. Go learn. We'll be waiting.
What about class diagrams? Think about it for a second, based on how hard it is to imagine a couple thousand lines per class of spaghetti (just 100 lines lasagna if you are good programmer). A class diagram symbol is just a symbol. At most we define name, attribute and method signatures. We do this for good reason. To add more detail implies we actually can absorb, understand, and remember the complete program.
The facts are, we are sloppy and lazy. We can't keep more than a few things in our heads at one time. Sure we match patterns, but not thousands of lines of Java at the same time. We think linearly. We also are not savants with photographic memories.
Sorry, no idiot savant here. We need a crutch. That's UML.
Developed by nerds, not artists, UML is a cartoon of symbols, not a detaied 3d representation. UML is ugly and unimaginative. Ugly is good. You don't buy ugly a new car from irrational imaginings of a good time. Ugly is functional.
People complain that UML is confusing. Sure, that's true, but only if you don't understand UML, or objects, or in fact have the ability to abstract life and the world. UML is just a language of symbols. You need to learn to read and write before the alphabet is really useful.
Ok, enough. Go learn. We'll be waiting.
Tuesday, March 15, 2011
Proof of Life
Avoid addressing problems, issues, events, or constructs that are not proven to exist in the real world. This is like "proof of life" used in hostage negotiation. Here you should not proceed until there is proof that the need either exists or there is a commitment to existence.
Proof of life or existence of a concept in the real world should be confirmed before allowing a concept to be added to the process or metadata. Simply, there are things we imagine that might exist that do not exist in reality. Imagination and antidotal-based evidence lead us to create scenarios that are not realistic. We need to limit effort based on impossible or rare edge cases.
Dealing with edge cases and error conditions is important. How exceptions are dealt with can be designed so that the effort is applied at the exception, rather than designing expensive infrastructure to solve a problem that may never occur.
We hate failure and that is why we come up with many scenarios that may only be imagined. If something might happen, we believe it actually does happen. The difficulty is proof that will satisfy a critic. The best case is that without proof, we cannot assume it is necessary to address or that we address with a lower level of effort. Those things that have definitive proof have priority.
It is important that our primary modeling tool is UML-based with UPDM, SysML and other standards. These give us all the building blocks and levels of abstraction so that we avoid reinventing the wheel. We also have one place to look for what we have proved to exist and even what does not. Unlike cowboy-agility where we erase the whiteboard on every iteration, we have a history that gets smarter after each iteration. Don't be afraid to document an activity and add metadata to classify it as 'do not implement.'
Address primary use cases and important edge cases, but should not attempt to address those that cannot be proved. There may be guidance for addressing such unknowns and ensure that efforts are reviewed to ensure success.
A good test of "Proof of Life" is a repeatable and complete test. If you can create a test, then it is at least possible to show the exception in practice. This works well for software, but also applies to your development process and any automation and metadata of the process.
Proof of life or existence of a concept in the real world should be confirmed before allowing a concept to be added to the process or metadata. Simply, there are things we imagine that might exist that do not exist in reality. Imagination and antidotal-based evidence lead us to create scenarios that are not realistic. We need to limit effort based on impossible or rare edge cases.
Dealing with edge cases and error conditions is important. How exceptions are dealt with can be designed so that the effort is applied at the exception, rather than designing expensive infrastructure to solve a problem that may never occur.
We hate failure and that is why we come up with many scenarios that may only be imagined. If something might happen, we believe it actually does happen. The difficulty is proof that will satisfy a critic. The best case is that without proof, we cannot assume it is necessary to address or that we address with a lower level of effort. Those things that have definitive proof have priority.
It is important that our primary modeling tool is UML-based with UPDM, SysML and other standards. These give us all the building blocks and levels of abstraction so that we avoid reinventing the wheel. We also have one place to look for what we have proved to exist and even what does not. Unlike cowboy-agility where we erase the whiteboard on every iteration, we have a history that gets smarter after each iteration. Don't be afraid to document an activity and add metadata to classify it as 'do not implement.'
Address primary use cases and important edge cases, but should not attempt to address those that cannot be proved. There may be guidance for addressing such unknowns and ensure that efforts are reviewed to ensure success.
A good test of "Proof of Life" is a repeatable and complete test. If you can create a test, then it is at least possible to show the exception in practice. This works well for software, but also applies to your development process and any automation and metadata of the process.
Subscribe to:
Posts (Atom)