Package reformatting tool availability

Package reformatting tool availability

[Andy Askey]

Hello,

I have several Ada legacy packages that contain multiple types.  I
prefer that each type is in its own package/file for my Ada95
development effort.  Does anyone have (or know of) a script or other
tool that will turn a package with multiple types into multiple packages
with one type?

Thanx.
-- 
---------------------------------------------------
|                 Andy Askey                      |
|              Software Engineer                  |
|           Raytheon Systems Company              |
|   670 Discovery Drive, Huntsville, AL  35806    |
|   Phone: (256) 971-2367  Fax: (256) 971-2306    |
|        andrew_j_askey@res.raytheon.com          |
---------------------------------------------------

Re: Package reformatting tool availability

[Robert Dewar]

In article <37CFFA58.FFC67480@res.raytheon.com>,
  Andy Askey <askeya@res.raytheon.com> wrote:
> Hello,
>
> I have several Ada legacy packages that contain multiple
types.  I
> prefer that each type is in its own package/file for my Ada95
> development effort.  Does anyone have (or know of) a script or
other
> tool that will turn a package with multiple types into
multiple packages
> with one type?


I do not know of such a package, and it would be a bit of
a suprise if one existed, because the goal here is not a
generally desirable one. Insisting that each type be in its
own package as a general rule is definitely shooting yourself
in the foot.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Package reformatting tool availability

[Andy Askey]

Thanx for the info.  I noticed from the responses here (and others
emailed) that the everyone wanted to know why I would need this tool
since packages are meant to contain only related types and therefore
should not be broken up.  

Unfortunately the legacy Ada I have dealt with in the passed 7 years has
a different criteria for grouping types within packages.  It appears
that there is some rule of thumb that only about 30-50 types can be
placed in one package.  When more types are created, there is an obvious
need for another package.  I guess this makes it easier on the
developers.  Some discipline of thought must be that the number of
"with" statements increase complexity exponentially.  I missed this
course in school and must fall back on the "related types to a package"
philosophy.  Therefore, I have a need for this tool to bridge this
software philosophical chasm.

Actually, I figured out the requirements of what I need.  Maybe I'll get
bored some weekend and write a perl script break up packages based on
dependency relationships.  I'll post this if I do ... but then again,
football season just started.

Andy
-- 
---------------------------------------------------
|                 Andy Askey                      |
|              Software Engineer                  |
|           Raytheon Systems Company              |
|   670 Discovery Drive, Huntsville, AL  35806    |
|   Phone: (256) 971-2367  Fax: (256) 971-2306    |
|        andrew_j_askey@res.raytheon.com          |
---------------------------------------------------

Re: Package reformatting tool availability

[Robert Dewar]

In article <37D542F9.3C6C9F4D@res.raytheon.com>,
  Andy Askey <askeya@res.raytheon.com> wrote:
> Thanx for the info.  I noticed from the responses here (and
others
> emailed) that the everyone wanted to know why I would need
this tool
> since packages are meant to contain only related types and
therefore
> should not be broken up.

OK, a tool to break things up so only related types end up in
a given package makes MUCH more sense :-)


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Package reformatting tool availability

[Richard D Riehle]

In article <37D542F9.3C6C9F4D@res.raytheon.com>,
	Andy Askey <askeya@res.raytheon.com> wrote:

>a different criteria for grouping types within packages.  It appears
>that there is some rule of thumb that only about 30-50 types can be
>placed in one package.  When more types are created, there is an obvious
>need for another package.  

Yikes!!!!!!   Fifty types per package?  Therein lies a uparalleled
opportunity for keeping maintenance programmers secure in their jobs
for a very long time.   It reminds me of the COBOL programmer who 
creates a package Data_Division, the Fortran programmer with a 
package Common, or the Jovial/CMS-2 programmer with package Compool.

One of the problems with the Ada package is how it encourages such 
practices.  This reflects one of the benefits of C++ or Eiffel:  each 
C++ class is a type.  If I still understand object-oriented modeling, a
package should export one main type with appropriate operations on that
type. The structure of the type is hidden from a client of the package.
The package may also export some supplementary types such as enumeration
types, etc.  

Does this create too many packages?  What is too many?  Robert Dewar 
is fond of reminding us that Ada is designed to be more readable than
writeable. That is one of goals of encapsulation and information hiding,
isn't it? I thought Brad Balfour and Ed Seidiwitz long ago put the issue
of global Ada type packages to rest.

Also, with the advent of generic formal package parameters, child library
units, private child units, and the new renaming options, Ada 95 makes
it easy to design small packages that support the behavior of one type
In fact, used correctly, these features of Ada 95 put Ada ahead of some
other languages such as C++ where type <=> module <=> class.  

Brad.  Where are you when we need you?  :-)

Richard Riehle
http://www.adaworks.com

Re: Package reformatting tool availability

[Robert Dewar]

In article <7ree14$t3h@dfw-ixnews6.ix.netcom.com>,
  Richard D Riehle <laoXhai@ix.netcom.com> wrote:
> Yikes!!!!!!   Fifty types per package?  Therein lies a
uparalleled
> opportunity for keeping maintenance programmers secure in
their jobs
> for a very long time.


Hmmm! I don't like even *suggesting* that a simple numeric
criterion is appropriate.

Two is too many if the types are unrelated and would be better
off in separate packages.

Fifty or more may be fine if they are somehow a coherent set of
related types.


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Package reformatting tool availability

[Mark Lundquist]

Richard D Riehle wrote:

> In article <37D542F9.3C6C9F4D@res.raytheon.com>,
>         Andy Askey <askeya@res.raytheon.com> wrote:
>
> >a different criteria for grouping types within packages.  It appears
> >that there is some rule of thumb that only about 30-50 types can be
> >placed in one package.  When more types are created, there is an obvious
> >need for another package.
>



> One of the problems with the Ada package is how it encourages such
> practices.

I wouldn't agree that Ada "encourages" this.  Ada allows it.  So does C++.
You can define any number of classes is in a file, as many as you like
(similarly, a Java package can contain arbitrary class definitions).

While packages may seem to contain primitives in the same sense that classes
contain member functions, the C++ analogue of a package is not a class.  If
anything, the (poor) C++ analogue of an Ada package is the "file", as in
("header file" and "implementation file").  There is another aspect in which
the analogue of the Ada package is the C++ namespace.

>  This reflects one of the benefits of C++ or Eiffel:  each
> C++ class is a type.

That's more of a definition than a statement, so I'm not getting what the
benefits are...

>  If I still understand object-oriented modeling, a
> package should export one main type with appropriate operations on that
> type. The structure of the type is hidden from a client of the package.
> The package may also export some supplementary types such as enumeration
> types, etc.
>
> Does this create too many packages?  What is too many?  Robert Dewar
> is fond of reminding us that Ada is designed to be more readable than
> writeable. That is one of goals of encapsulation and information hiding,
> isn't it?

Actually, I would say not.  The goals of encapsulation have to do with
abstraction (and whether abstraction leads to greater readability is sort of
in the eye of the beholder, and it involves lifecycle considerations too).
Readability is the goal of clean syntax.

> I thought Brad Balfour and Ed Seidiwitz long ago put the issue
> of global Ada type packages to rest.
>
> Also, with the advent of generic formal package parameters, child library
> units, private child units, and the new renaming options, Ada 95 makes
> it easy to design small packages that support the behavior of one type
> In fact, used correctly, these features of Ada 95 put Ada ahead of some
> other languages such as C++ where type <=> module <=> class.
>

 I'd say Ada95 is ahead even without considering those features, but...:-)

Are you saying that Ada's separation of typing and modularity is a weakness
(as you seemed to be  saying earlier), but that this weakness is overcome by
the correct use of certain other features?

I believe that the conflation of type and module into one construct is a
mistake -- unfortunately, that's the "idea package" in which most of us
(myself included) first encountered OO, thanks to Alan Kay and Adele
Goldberg.  At the time, this idea was a great experiment (not the only great
experiment of the Smalltalk environment, of course -- the other was the
window-mouse MMI paradigm).  And paradoxically, it was necessary that OO hit
the streets in the radicalized, class-oriented form, because the computing
community really did need to have its collective brain washed in order to
understand and accept the value of the underlying, true OO concepts
(encapsulation, inheritance, polymorphism, and for all but the most
extreme "purist", genericity).  But the attempt to fundamentally define and
forumulate OO in terms of the class construct is moribund.

I've been wanting to write an article about the myth of "pure OO" and the
brokenness of class-centered OO... just haven't been able to make the time
to do it.  Plus, I don't know if the world is ready... :-) :-)


--

Mark Lundquist
Senior Software Engineer
Rational Software
Development Solutions Business Unit
UNIX Suites Group
Aloha, OR, USA

Re: Package reformatting tool availability

[Robert Dewar]

In article <37CFFA58.FFC67480@res.raytheon.com>,
  Andy Askey <askeya@res.raytheon.com> wrote:
> Hello,
>
> I have several Ada legacy packages that contain multiple
types.  I
> prefer that each type is in its own package/file for my Ada95
> development effort.  Does anyone have (or know of) a script or
other
> tool that will turn a package with multiple types into
multiple packages
> with one type?


Actually this is FAR more than a simple script can do, and
indeed is not generally possible.

Certainly if you have completely unrelated types in a single
package with completely separate primitive operations, then
the package should be split, but this is not the normal case.
THe normal case is that you have multiple types in a single
package is that they are related, and for example, you have
operations that are primitive in more than one type.

Asking how to break such packages into separate pieces so that
there is only one type per package is like asking how to steer
a car with the special proviso that you are not allowed to touch
the steering wheel. The ability in Ada to have multiple types
per package is one of the powerful features of the language, and
it is quite difficult to do without if the program you are
working with takes advantage of this feature.



Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

Re: Package reformatting tool availability

[Pierre Dissaux]

Andy Askey wrote:
> 
> Hello,
> 
> I have several Ada legacy packages that contain multiple types.  I
> prefer that each type is in its own package/file for my Ada95
> development effort.  Does anyone have (or know of) a script or other
> tool that will turn a package with multiple types into multiple packages
> with one type?
> 
> Thanx.

You could use Ada2HOOD reverse engineering utility in order to re-design
your application.

You will get a non-terminal HOOD module that is the image of your
current composite package.
It will be then possible to create lower level modules and dispatch
types and related subprograms into each of them.
This second step is not automatic, but can be performed in a graphic
editor, if you can use a HOOD tool.
Ada code may be re-generated with the new packages organization.

Benefits of this approach is that you can work at design level, and
justify creation of each "class" by proper documentation.



HOOD (Hierarchical Object Oriented Design Method) was defined to fit
software design process requirements for European Space Agency projects.
It now also used for avionics, transport, and similar applications.
HOOD4 (the last version of the method) is very close to Ada95.

Ada2HOOD is freeware developed by TNI to help reengineering Ada software
with a HOOD approach. Current version suffers from some limitations but
it may be extended easily. It produces HOOD Standard Interchange Format
(SIF) files from Ada packages. These SIF files may be loaded into any
HOOD tool (and of course into STOOD, developed by TNI, but this one is
not a freeware).

To know more about HOOD/Ada design approach:
- participate to the 3rd "Workshop on Methods and Tools for Ada95" (next
week) http://workshopada.enst-bretagne.fr
- visit our web site: http://www.tni.fr/


Pierre Dissaux
TNI