During my first years in software engineering, I was introduced to "modular programming". Next, I was introduced to "egoless programming", and then structured design and analysis. While I was working in an environment that was evolving "modular programming" to "structured analysis and design", there was another path that was evolving "modular programming" to "object-oriented analysis and design". Sometime in the late 80's, C++ was born, and arguments began in the real-time community as to whether C++ could be used for embedded systems.
One aerospace company wanted facts. "Will C++ support real-time embedded systems or not?" I was hired for their "Research and Technology Center" to build an ECM system using C++, and evaluate it. I designed and implemented a "white world" ECM system using C++, but it didn't feel right. Being a professional, I like to take pride in my creations, and it wasn't there, and I knew something was wrong. After I expressed my concerns to my director, he sent me to an OOPSLA conference.
At the OOPSLA conference, I met other embedded software engineers who were in the same dilema that I was in. After many discussions with O-O technology experts, and my fellow embedded software technology experts, I realized that we were suffering from years of "Procedural Indoctrination" (my term for the problem), and the cure was to forget everything I have learned about structured analysis and design.
Well, I didn't really forget about structured analysis and design, because sub-conciously, I created the high level logical architecture based on my experience using structured analysis and design techniques. But that was good, because I used object-oriented analysis and design to do the detailed design, and actually created an ECM class library that I later evolved into an Avionics Class Library that was specialized for use on several projects at the parent company.
I began using what I call the "Rumbaugh Methodology". I found it in "Object-Oriented Modeling and Design" by James Rumbaugh, et.al. It offers several views of a system architecture. I also tried using "Object-Oriented Design" and "Object-Oriented Analysis", both by Coad/Yourdon, but they seemed to be lacking something. For an ADA implementation, it was mandated that I use Booch "Object-Oriented Design", so I did. It was better than nothing.
The current management mantra is UML. The Unified Modeling Language has been heavily marketed, and it has the big three names associated with it, so it wins. UML supports some good design views, but I feel that it is still falls short of merging structured concepts with object-oriented concepts. I use UML when my management or customer encourages it, but if I am responsible for the design, I enforce good text backup documentation before the point and click begins. UML and the tools that support it are all well and good, but only software engineers can think and create the design.
There seems to be something about human behavior, that when they have to write, they seem to think about what they are going to write.