The Model Driven Software Network

Raise your level of abstraction

Before UML, we had OMT, Booch, Use Cases, Shlaer-Mellor etc. for capturing formal analysis models which could be shared with a team and the customers for review purposes. All of the different methods/notations were small but well defined. They could all be learned easily. Whether a particular team member had an aptitude for creating such models was another matter of course. The first three then merged to become UML while the last method was later repositioned as Executable UML. UML continued to evolve driven by committee. We now have a fantastically complex and flexible notation without all the ugly process and methodology issues!

How important is the simplicity of the original methods for allowing a team to create and validate an analysis model? How important is an accompanying methodology? Putting aside the needs of the designer to be able to create design models that can be elaborated or translated into object-oriented code. Have analysts lost more than they have gained with UML? Would a team ever use UML (or a Standard profile of UML) with a customer? Use cases maybe but a class diagram with OCL constraints?

Without a good analysis formalism is MDD cost effective? Do people think they can skip an analysis model and go from requirements to a design model to the code?

Views: 57

Reply to This

Replies to This Discussion

People use all sorts of shortcuts to jump directly to coding. It's human (developer) nature. Many developers just like to do analysis while coding.

If the currently accepted analysis methods are fantastically complex as you said, why bother?

I'm playing devil's advocate, of course.
Well in my case, I use Shlaer-Mellor OOA to my analysis models, not UML.

The problem with developers doing analysis while coding is that any analysis done is intertwined with design and implementation logic which hides any analysis decisions from those who should be making or validating those decisions.

RSS

Badge

Loading…

© 2018   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service