The Shlaer-Meller (SM) method is aiming for near 100% code auto-generation.
Take a look
at www.projtech.com if you are interested. Its strict formalism makes it
possible since it has an analogy to the high level language compilers.
In summary, a system to be built is partitioned into domains that fall into
one of 4 domain layers: Application Domain, Service Domain, Software
Architecture Domain, and Implementation Domain. Each domain could be
composed of smaller subsystems if necessary.
During analysis, it goes through 3 phases.
1. Object Information Modeling (OIM) - define objects and their
2. State Modeling (SM) - Each active object's states are defined
(uses Moore state modeling)
3. Process Modeling - Action is defined for each state of an active object.
The action is non-interruptable and is executed when a state transition
During Recursive Design (RD), 2 major activities happen:
1. Target architecture is defined. For example, target implementation
such as Ada, Java, or C, single threaded or multi threaded, etc.
2. Once the architecture is defined, design rules are defined. The rules
how certain elements of the (meta) analysis model are translated into
architecture. Once this is done, a translator is written.
As you could see, in SM, analysis and design are two independent
processes, also they require totally different experties. Ideally, this
to a massive production of software applications.
Recently, I could do some experimentation with this method: I used Rose
for developing sample financial business objects, developed Software
- multi threaded, Java, in-memory persistent model, and wrote a translator
with RoseScript. GUI is the one that was written manually. I tried to make
code not look ugly. Admitted that I am not ready to discuss the
optimization aspect of it yet.
Using the same analysis model, I have another translator that generates
code (only for OIM at the moment - i.e. tagged types with attributes,
referential attributes, and (optionally) operation code skeletons).
I am preparing a draft for this experience. If anyone interested, email me
I will let you know when the draft is ready.
> From: W. Wesley Groleau x4923 <[log in to unmask]>
> To: [log in to unmask]
> Subject: Re: documenting checkable design intent in code
> Date: Tuesday, December 01, 1998 9:46 AM
> > Wouldn't you be better off capturing your design intent using a tool
> > (Rational Rose springs to mind, but there are plenty of others) and
> > controlling the code it generates.
> A tool would not necessarily support what Samuel is proposing--enforcing
> the shop's decision on a design paradigm--unless the tool "just happens"
> to implement the same decision.
> I haven't seen the code generated by Rose, but the documentation makes it
> obvious the tool is primarily aimed at C++ programmers. And I have seen
> the Ada code generated by other tools. All auto-generated code I've ever
> seen has been atrociously unreadable. The problem with such tools is
> you're enslaved by the tool, since the code is essentially unmaintainable
> without the tool.
> The only such tool I've actually used would _reduce_ productivity over
> manual techniques, simply because it only generates the calls. The
> programmers have to write all the actual logic, AND keep track of up to
> nine segments of code per compilation unit, with special marker comments
> and special file names, just to support the CASE tool assembling the
> pieces after each change! Thus, the code is essentially unmaintainable
> _with_ the tool!
> The same tool (that I used in the past) could not graphically represent
> two-part (spec & body) compilation units, so it put all 'with' statements
> on the package specs, not the bodies. (I think they may have eventually
> fixed that stupidity....)
> I have not had the opportunity in recent years to look at new
> in this area, so feel free to tell us that you've found a vendor of CASE
> tools that actually knows something about software engineering. (The
> vendor of the tool I mentioned also needs help with configuration
> control--they fixed a significant bug in one release, and reintroduced
> identical bug in the next release.)