TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy

TEAM-ADA@LISTSERV.ACM.ORG

Options: Use Forum View

Use Monospaced Font
Show Text Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Content-Transfer-Encoding:
7bit
Sender:
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Subject:
From:
Kihup Boo <[log in to unmask]>
Date:
Tue, 1 Dec 1998 20:57:29 -0500
Content-Type:
text/plain; charset=ISO-8859-1
MIME-Version:
1.0
Reply-To:
Kihup Boo <[log in to unmask]>
Parts/Attachments:
text/plain (102 lines)
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
relationships
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
   occurs.

During Recursive Design (RD), 2 major activities happen:
1. Target architecture is defined. For example, target implementation
language
   such as Ada, Java, or C, single threaded or multi threaded, etc.
2. Once the architecture is defined, design rules are defined. The rules
define
   how certain elements of the (meta) analysis model are translated into
the target
   architecture. Once this is done, a translator is written.

As you could see, in SM, analysis and design are two independent
development
processes, also they require totally different experties. Ideally, this
would lead
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
Architecture
- 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
the generated
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
Ada95
code (only for OIM at the moment - i.e. tagged types with attributes,
accessors,
referential attributes, and (optionally) operation code skeletons).

I am preparing a draft for this experience. If anyone interested, email me
so
I will let you know when the draft is ready.

- Kihup


----------
> 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
then
> > 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
that
> 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
developments
> 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
the
> identical bug in the next release.)

ATOM RSS1 RSS2