we prefer to model packages as classes with stereotype
<pl/sql package>.
you may also model the package specification as an interface with stereotype <pl/sql spec> and the body as the class with stereotype <pl/sql body>.
its up to your intention if this makes sense or not.
to reverse engineer we are using a little custom written java class, which reads the packages metainformation from the data dictionary and dumps this in files in "pseudojava code".
e,g.
class mypackage {
lastname varchar2(255);
firstname varchar2(225);
String get_name_4_person( String pName )
}
EA can read this like any "normal" java code, since it only needs the class structure :-)
(but this may change in future versions ? )
very nice to document exisitng oracle code
records are modeled as inner classes
besides this, we make extensive usage of oracle object types and object views in our programms which are modeled as classes too.
we are modeling rights and roles as association classes,
synonyms are modeled as qualified associations.
use collaboration diagramms to visualize dependencies
and programm dynamics (add notes to show where grants and synonyms are needed)
if views or tables are used (modeled as classes as well and therefor visible in this diagramms) show the sql statements in notes
this gives you much more information about your database programms then everything else.
hope this helps
kind regards
peter
