From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,8fe97ffc52e456cb,start X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1995-03-21 15:04:50 PST Newsgroups: comp.lang.ada Path: nntp.gmd.de!dearn!blekul11!ccsdec1.ufsia.ac.be!reks.uia.ac.be!idefix.CS.kuleuven.ac.be! Belgium.EU.net!EU.net!howland.reston.ans.net!gatech!newsfeed.pitt.edu!uunet!inews.intel.com!itnews.intel.com!chnews!ennews!enuxsa.eas.asu.edu!koehnema From: koehnema@enuxsa.eas.asu.edu (Harry Koehnemann) Subject: Help with notations for Tagged Types and Child Libraries Message-ID: Nntp-Posting-Host: enuxsa.eas.asu.edu Sender: news@ennews.eas.asu.edu (USENET News System) Organization: Arizona State University Date: Tue, 21 Mar 1995 23:04:50 GMT Date: 1995-03-21T23:04:50+00:00 List-Id: The world's full of design notations that represent class constructs. For example the following code: class Bank_Account { public: Deposit (int amount) { ... } private: int account_number; int balance; }; is drawn in a notation that shows the class name, operations, and data somthing like: ---------------- |Bank_Account | |--------------| |Deposit | |--------------| |Account_Number| |Balance | ---------------- Inheritance in such a notation is shown by drawing arrows from a child class to it's parent class. Symbols are added to represent aggregation, composition (composed_of vs. kind_of), and decomposition (subsystems). Ada95 OO extensions appear to map to this notation, but add a few interesting twists. Packages present the first problem for me. How are packages and child packages denoted/added to such a notation? They're not really subsystems - subsystem can be compsed of many packages, and are likely decomposed into many child units. Further, child packages support many purposes - decomposition, extensions, multiple interfaces, etc. Modeling packages as a container for OO is probably not appropriate as a general case. How is anyone modeling type extensions and inheritance in conjunction with child packages? A second problem occurs when a type extensions's interface is derived from one type, but it's implementation (the declaration in the private part) is derived from a different type. How does one denote a type with two derivations - one for the public interface and one for the implementation interface? Any references, comments, or suggestions would be appreciated. -- Harry Koehnemann Arizona State University hek@asu.edu Computer Science Department