Download Ada-based support for abstraction, encapsulation and unit ... and more Study Guides, Projects, Research Computer science in PDF only on Docsity!
Abstraction,
Ada-based sup~rt
for
Encapsulation and Unit Hierarchy
Liang Xianzhong, Wang Zhenyu Wuhan Digital Engineering Institute P. O. kX 74223
Wuchangj Wuhan 430074
P. R. CHINA
Abstract
Ada packagea do have some features suitable for object-oriented development methodology such as abstraction, encapsulation, and limited polymorphism in the form of operator overloading, though Ada is not an object-oriented language. An object-oriented viewpoint is cmcial for effective use of Ada’s module facilities. This paper. based upon the features of the abstract data type, presents a set of techniques including + kiwis of abstract%u, their Utredeod emcupsskth to represent classes of V.object/ U.object, and sub unit to construct unit hierarchies, which aims at more precise and direct support for full object-oriented phikxwphy. The paper, with Ada-based examples given. also provides a basis of the techniques applied to object-oriented development
1. Introduction
Today’s Ada community generally accepts the proposition that an object- oriented development methodology is a requisite for effective Ada software developmental, 2], and that Ada, with adaptation of a varie~ of complementary software development methods into comprehensive% would support a complete lifecycle object-oriented development, which well accords with the idea of monolingual[3].
An Ada package is an object-oriented construct that lies mainly in the separation of the specification from ita implementation. As a programming unit, the construct provides such f ezduree as abstraction, encapmdation and limited polymorphism suitable for object-oriented development methodology. In order to extend a package in ita capability to a design unit, an Ada-based unit dcacription unified under the concept of abstract data type (or ADT for short) is preeented
inclw* mere perfeet^ specification,^ better
encapatdation of different abstraction different application of packagee), and the version of multiple implementation.
(reflecting on the control of
1991 ACM 0-89791-445-7/91/1000-01 16
with Ada.
On the other hand, Ada only provides partial support for object- oriented philosophy. Ada packages (or generic once ) can be identified with clrsea. However, there is no meehanism for one package to inherit the operations from other packages i. e. there is no hierarchy amo~ the units. so we can not incrementally build new units by inheriting the existing units that were designed to be reused. Baaed upon the above mentioned Ada-baaed unit, the unit hierarchies can be built with emphasis on overcoming the strongly typed constraint in Ada, so that some units may be subordinate to others, i. e. the subordinate unit inherits operations from others.
2. Abstraction and Encapsulation under AD’I’
In the most general sense, an abstraction is a
concise representation for a more complicated idea (or object ) ; information hiding is to make the implementation details for an abstraction secret, which are not e=encial to an umlerstancling or me purpoaea functionality. Since^ encapsulation^ of^ abstraction denotes object.% abstraction plays a mapr role in object-oriented philosophy[4].
According to the viewpoint of C. A. R. Hoare [5], ADT features deal eeaentially with the following three aspecta: l An abstract type defined by designers that models problem domain; l A set of operations that characterize the type through acting on ita variables;
l Concrete reprcaentation (or rep for short) for the type and implementation for those operations.
In Ada-like procedural language% abstraction and im information hiding in a unit reflect on the visibility and invisibility of the three above mentioned aspects from outside world respectively. Encapsulation will give a char boundary defining ecope of abstraction and information hiding.
A goad encapsulation should have the following desirable features: l A well-defined interface for abstraction useful to the understanding and applying of the unit; l A protected part for information hiding that implements the details of the purposed functionality provided by the unit.
From abstraction an ADT focuses on the abstract type with a set of operatiorw whose concrete rep and implementation are generally the details of the abstraction and are of locality, i. e, for the definite AD’T, the implementation changee as concrete rep does without affecting the use of the abstraction. Furthermore, different concrete repa that are uniqueness will determine the algorithm by which the operations are implemented.
FOUR KINDS OF ABSTRACTION
Classing the mentioned aspects into visible and invisible parta, we present four abstract types (including private- type) so as to introduce multiple abstraction in Ada-based unh Fig. 2.1 illustrates the idea that the higher the level of abstraction & the deeper its information Mdden (from the arrow to UP m-visible parlx and below it are invisible parts).
-f
+– IA~ (NAM.)
A&tract ~ t
-–– PAtmaeth
t
anaete Rep ~– vAtwncth
t
Impl-tatien –
Mommtkmmding
Fig. 2.1 Abstraction and Information Hiding
Four abstract types denoting multiple abstraction described as following: l Vis;ble-type : type ABST.T is visible: — — denoting Vabstraction
are
It means the abstract type, concrete rep and
operations are exported, while the implementation is hidden from the outside. Here the operations can act on either explicit or implicit variables of the type. l prhate-type: type ABSI.T is [limited] priw — —denoting P.abstraction It means the abstract type and operations are exported while the concrete rep and implementation are hidden. Here the operations traditionally act on explicit variables of the type. l invisible-type: type ABST-T is invisible — —denoting Labstraction It means operations are exported, while the abstract type, con&e@ rep and implementation are hidden. Here the operations can only act on an implkit variable of the type declared within the unit.
A virtual ADT will include a set of logic-related
operations and their implementation, objectively without an abstract type. For the purpose of unification, an abatract type and concrete rep are nominally built to make ADT perfect. The last abstraction is presented as following:
l nominal-type : typeABST.T^ is nominal
——denoting Nabstraction It means that operations are export@ while abstract type, concrete rep (nominally built ) and implementation are hidden. Here the operations will act on no variable of the type. Now we come to a conclusion that specific abstract types denote four ldnda of abstraction which will cover different application of Ada packag~ and that each of the Ada-baaed units has an abstract type. How multiple abstraction is encapsulated will be discumd later.
THREE-LEVEL ENCAPSULATION
As mentioned, four kinds of abstraction are denoted by four abstract types. In this section, three- level submoduk% cornpoaing an Ada-based unit (Fig.
- are presented to encapsulate different abstraction in order to obtain a unified description, arxl Example.2. 1 gives their frames.
r%mil
Fig. 2.2 Three-level encapsulation of Ada-baaed unit
l Specification aubmodule (SSM) An SSM is twsentially a ( generic) package specification aiming at the declaration of en abstract
V.OBJ)NX PASSED TO OPERATIONS
When an Ada-based unit exports an abstract type vgith a set of operations, and all of operations will act on an explicit variable of the abstract type as an argument declared from the outside world to characterize the type. From object-oriented viewpoint the abstract type denotes a class and the owtside variable is called a V.objeet. The encapsulation for claw on V.object is illustrated in Fig. 3.1.
unit in library l AbstractType &. Operations identified with class Daacript. l localized data in Pabst. or VAx4t. INTERFACE t
act m
Procedure call —
Fig. 3.1 Encapsulation for class on V-object
A V-object has key attributes that: l rnaybepassed asanargument toopwations, and l maybe a txmponent of a record or array
-- Exampk.3. 1 Ckitsaoa V.dijd and its app%utiea
-PERSON-Pi b--SMtheektmct t~denoteeaclas w PERSONb visible/priveW- -V.^ a^ P-atstmtkm eubtYP NAMEi3S2’iUNO(l..2O): 1-
Per9nhlxuic WPe Smc^ ie (him;^ inrOmMtiOn mbtyp At3E b INIEGERrange1..200: --> Mw_mq~ona _wfimtiouti procedw ~-ONE@ out PPRSON:N:NAM13SSEX:A:AGE): LKW=IWI@UktS (Rio outPESSON;N:NAME); fmctirmHOW.OLD(RinPESSON)returnAGE; rnx=kre DJSPLAY(lkiaPSRSON); endP-21; -––—- AppSadiononV-Objcct–––––– -- raxat P-M;...... Mere SAGE :^ AGE; sNmmN:PEssoN; –-->^ dedemenoutsktcW. w —-> m Vd)ject 9rl.oNa@HEtDoN,WMdO1l.Men&Y.M 30): DISPLAY6HUWN): SAGS: ==HOW-CSD6HEMXX0: -- V&ject SHELDGNhuwdand --peaedtoq%mtiomdderaitnthesshr: d;
A unit in V- or PA@raction may export an abstract type identified with a clam for V.objects to be cteclaretl with. The unit with clam on V-object is illustrated in Example-3. 1. In fact, a V-object is an abstract type’s variable passed as an argument to operations [2, 8]; the U-object to be discussed, an instance of Ada- baaed unit, is another object to which operations as mcasages
are sent.
U-OBJECT TO RECEIVE MESSAGES
In addtion to V-objects, there also exists an abstract type in a unit, where all of operations will implicitly act on a variable of the type declared within the unit to characterize the type through side effect& The operations’ side effect on the inside variable makes the unit denote an abstract state machine. From object- oriented viewpoint the unit may be seen as an object called U.object. On the other han having lost the meanings of procedure calls, the implicit action on the unit is just similar to sending messages (operations with side ef fact) to the unit (U.object). A U.object may receive, as well as send messages f rem/to outside world. Later, we shall see that when reusing the operations in an Ada-based unit hierarchy, a U.object receives messages sent by another U.object. A generic unit (treated as abstract state machine) served as a template will denote the class for U.objects to be instantiated with. Fig. 3. 2 shows the encapsulation of class or U-object.
Class or U-object l Class Description with messages l localized data in Labat. or V-abst. INTERFACE
- J messages from mewages to outside outside
Fig. 3, 2 Encapsulation for class or U.object
A U.object has key attributes that: l csnnetbe puwdssan argttment tooperatiow l receive mmnges through side effects of operations, and l may be components, includii types and program units
Generally, a unit in Labstraction (invisible-type with concrete rep hidden), having the hidden variable acted implicitly on, acts for a U-object and the generic for a class. Similarly, a unit in Vabstraction (visible- type with concrete rep exported ) may also have the exported variable acted implicitly on, where the unit is treated as an abstract state machine. But it should be recognized that the visible- type for U-object has lost absbct ineankge,^ fa~^ any^ variabl=^ of^ the^ type declared from the outside can not be acted on by the operations that only act, through side effect, on the declared variable within the unit. Example-3. 2, with a little (but key) modification from Example-3. 1, illustrates the class on U-object and
its application, and the variable implicitly acted or takes part in the concrete rep.
-- Exatnple.3. 2 Claas on U.cbjed aad ifs applioatim
g.mxie--genuieAda-ba9eduIdtasctas3ofu-0tlj@ B PERSON-P2i! -SM PEBSONk invkibk/visiie; – I- or V~ %&e NAhOl k SIRING(1..20): SEX l--
per90nJ9tuaic is(kf,m: infofmntial % Am b INTEUEarange1..200: --> Bdowe@mtiomimplicitb’ d on a variabtewithin ASM proeedumSEEONE(N:NAME;S:SEX;A:AGE): *u_NhNAME); funetbe HOW-OLDreturnAGE: tmxxdmeDISPLAY; eti P~NY2; -wti~ms--w mnemteS.K!3~N k tyjRFQtSGNbwoxd N :NAME;S :,SEX;A :AGE;
4
an implkit vatiable cadlrxotd; (^) actedon. hrollgbda ~.ow : PERSON; effect,byoperatiam & REawWGN; deckedh theSSM: endPSRSON-P2; -—----– mtim onu-&j@-------------- -- mqoWP~N-P2; ...... deelsm ~~ m b IXW PEI?SON92: --> mantiata a U-objeu; SMITH-AGE: Sh41’1H.AGE:...... km SMllH. SKI’.(XW (“B. &nith’, M 40) ; SMIYli. DISPLAY: -- U-obieotSMITH rawiva Inemlga; SMITH. SENAMS(”L SIIIMI”) : SMITILAQE: = SMftlL HOW.01.D;--> at fimtSMllH woivea -- HOW-OLDto producea mmltthen(indirectly) end --smdsmamge‘:=’ tooutside(SIMl?I-AGE);
Because an object- oriented paradigm is really demonstrated by sending messages to objects, compared with the V.object in Example-3. 1, the U.object has a more straightforward object-oriented significance than V.object, where V.object is passed as an argument to operations while the messages (operations with side effects) are sent to a U-object. An Ada-based unit, whether on V-object or on U-object, has more flexibiliw and less safety in V~bstraction than in PAXraction (on V-object) or in L&traction (on U-object ), because of the visible concrete rep (including implicit variable if it exists).
TASK IN ADA-BASED OBJECT
Task is the special object characterized by its entries. Unless being embedded, a task mm not exist as an individual compilation unit. Ada-based unit (unified by ADT) may embed a task type in the conrete rep to construct an Ada-based object (V.object or U-object). When involving a task type, the abstract type will be characterized by a set of operations manipulating the task object through entry call.
Four kinds of abstraction and their three- level encapsulation will still be suited for Ada- based unit with concrete rep involving task, for example, a BUFFER can be developed for concurrent application between CONSUMER and PRODUCER with a V. or U-object (Example-3. 3).
-- Exampk.3. 3 Task appears m concrta!e rep of MIT
p3ekageBuFFERPin -- A&-bawd ueitdenotaa U-objet
typeBUFFERiavi.db4e/iavidlde: ———-^ ~M ————
...... (^) vemienTNKWPH3t; proeaturePUr(x:inrIEM); (^) raaebedy~is --* poviJetoPRoDuCEILP; pfdurt PuT(x:in rlxM) b func?ionGEr returnrr13M: (^) w --* ~eto~: (^) BUFFmoBJ.PUT(X): --* mndezvoIsteBUFFER.GET; (^) --> celltmk?sentry; endBUwEa.P:...... –——–-– AsM—--—- endru’r; .. o... -w~~~ mdBUFFERP: eonemtaTASKBUFFERi ta5ktype BUFFERi em?yPuT(xinl’rEl@: -- it rendezvow fmm BUFFER-P. PUT: entry GET(X:out HEM); -. w rendezvousfrom BUFFER-P.GET: cadBUFFER; BUFFEROLU: SUFFER:-- impticitvariable; endTMKBWTER: d BUFFERR
Consistent with Ada, Ada- based unit in P~bstraction with concrete rep involving tssk type can only define similarly, if Labstraction, declared with assigned.
the abstract type as limited private, the unit is developed with a V- or the (hidden or exported) variables the abstract type can not be tested and
Ada-basedUnit Hierarchy
In order to support a full object- oriented philosophy with Ada, in addition to multiple abstraction and encapsulation,. unit hierarchies are also introduced, where some units are subordinate to others. h Ada-based unit may either denote a U.object (class in generic unit) or export an abstract type for V-objects, where the type, instead of the unit, denotes a class on V.objects. For the purpose of unification, the specific units: sub unit and supsr unit are presented to construct a unit hierarchy ( unlike Smalltalk: with its subtlass and superclaw[4]). A super unit, in higher levels of unit hierarchy, is an existing unit that was used to represent an abstraction-general and designed to be reused. The sub unit, in the lower levels. is such a unit that represents an abstraction-specific derived from super units, so the sub unit may be incrementally built from the abstraction-general defined in all of super units by adding some specific properties for the sub unit.
PR.E-BINDING
Polymorphical operations (or messages) are implemented by alternative methods, and will be bound to the methods when ready to use. Besides binding for PolylOF% ( needing redefining) — achieved through overloading operator, we shall mainly discuss how to bind Po1Y1OF% (directly inherited) to the method% where it is not necesary for Po1Y1OI% to be re-declared, like[8], in sub units with overloading. Pre-binding means that when reusing PoIylOPs (directly inherited) from an immediate super unit up to all i@ super units, the user of a sub unit should have such thought in advance, i. e. the operations (or messages ) will be bound to methods represented by super units. On the other hami pre- binding implies
how to overcome the strongly typed constraintin
Ada.
Pre-binding gives effect to binding operations to methods by two specific quotes super” and sub”. In the light of quoted entities during procedure call% the significance of the quotes is stated as following (Fig. 4.2) :
lV.objsct quoted bymb A ~OPEILkT(sub’ V.ORJ,. ..).
This means sub V-object is passed to the operation in super unis i, e. it is allowed that sub V-OBJ reuses OPERAT from the immediate up to all of super units;
lmrsssgequoted bysuper A+u.oBJ. supsr- Mso(... );
This means sub U-object receives super messages from one of super units, i.e. it ensures that sub ILOBJ wilt reuse MS(3 from the immediate up to ail of super units.
wham
AT Aktract ‘hm OP: Oerst&m
@)llluki-lsvel superUsits @)declsrsv-object @)pm V-OBJto wper OPERAT @ imtsntiatsUdject @send superMSGtou.oBJ
Fig. 4.2 pre-bind@ and its Si@fiG71tlCS
Pre- binding implies a non- determined process with specific significance, i. e. the reused operation OPERAT or MS(3 belongs to one of super units in the hierarchical chain frum the immediate up to all of super unim and it is searched along the chain to ensure that the super unit owning OPERAT or MS3 is the closest
to the sub unit. Pm-binding will fail unless one of super units in the chain declares the operation OPERAT or MSG. Example-4. 2 illustrates the pre- binding on both V-object and U-object (Example-4. 1).
-- J%ulnp?&l.4.2 Re-&s&ag * bOtAVxbjd UsaUabjed
--* x *m~l, *ll?AcnERP2:...
---W) **-;
dcchm S4GE : AGE; snElDoN:TE4cTls& .--->^ **v+ pn&lls?sMrrnb newmKHE%P3: -->iwtalltiatea u-obj@ w sErmNs@ELDON,%ll&lmLia@,M3QCOMKma): M(3S :- How.oLD@” SHsuxxO: -@tRliSaubv+etto OtxratknMdsllPu Unit RsNAME (sub” (^) ~. “M Ximdm@?) ; -———- SrArm sEratis(%OCtl smith”, M, 35,PHYsIcs): fs#rlW.wpx” RENAME(wnldysMI’JIi’): --@scMm6ssigcof,9qmunittowbU-objec$(SMITH); end:
Pre-binding through examples shows that: the entities sent/passed should fit into the destination, so @) sub V.obJects should be transformed to meet the strongly typed needs of super operations; @ super mesuages would be altered to fit into U.object (sub unit ). Here is another example of how a U.object (destination) has more straightforward object-oriented meanings than V-object. Because Ada is a. strongly typed language, pre- binding also implies another significance: during the creation of sub unit by reusing super ones, some preparations for binding process should be made in advance so as to pass sub V-object to super operations or send super messages to sub U.object. Something correqxding to pre- binding is done by the pre- transformer in a development system (see appendix). In fact, the implementation of PolylUOPs (redefined operations) will also deal with pre-binding. Suppose, for instance, PERSONYi (i = 1 ~
Exsmple4. 1; i = 2 + Example-3, 2) has
implemented DISPLAY in it, the DISPLAY in TEACHERPi (e. g. 4. 1) will be accomplished (by inheriting DISPLAY in super unit) .~s fdlaw@s
-.-.~ u- ----
pM&ebodgmAcIimMia pKeaue DIsPiAYb
w
ap” ts3rLAY; 9fowaxJssR aIi D13FLAY:. .. ... caJlE4tmtm
---–– ~ V** ..––.
~ bodymxlmt-Pl b
- D13FLAY(alb”TJ;->pbillsqamm 3HOwKOUsslt mdrsWLAY:. .. ... d mcHEfLPl;
Unit hierarchies together with pre-binding do the work to permit a sub unit to inherit operations from the
I ‘Y)
immediate up to all of super units, or allow those operations to be reused in the creation of sub units. Regardless of the detailed process, pre- binding with quotes may be considered somewhat dynamic within
the front-end of Ada-based description, for the quotea
(super - or sub” ) only specify the non-determined super reference (Appendixes state the idea of multiple unit hierarchies).
5. Conclusion
In thispaper, we present four abstract types and
three submoduks for abstraction and encapsulation superunit description and pre- binding for unit hierarchies, which are called Ada- based techniques. Ada-based units with those techniques will support a full object-oriented philosophy. Four kinda of abstraction together with three-level encapsulation and unit hierarchies will benifit object- oriented development with Ada as follows[9]: l unify designs for different application of package& l introduce the management and configuration of multiple implementations, l provide flexibility and safety for incremental subunit-building, and l provide reusability with Ada-based units.
We have developed an Ada-GOODS (Ada-based Graphical Object- Oriented Development System ) whose kernel ia based on the description reported h this paper. Those descriptions together with Ada may be considered as an Ada-based Program Design Language (PDL/ Ada) aiming at the support for full object- oriented philosophy from program- building up to system- building with the co- ordination of multiple developers.
6. References
[ 1 ] R. M. Ladden, ~!A^ ~rvey^ of^ issue^ to^ be
considered in development of an object-oriented development methodology for Ada “, ACM SIGSOFT SE Noti. Vol. 13, No. 3, 1988. [2] (3. Booth, Wbject-Oriented Development”, IEEE Trans. Vol. SE-12, No. 2, Feb. 1986. [3] Z. Wang (Wang Zhenyu), “Monolingual: One way towarda the Integrated software Development Environmentti, J. of Comput. Sci. & Technol. Apr. 1988. [4] L. J. Pinson and R. S. Wiener, An Introduction to Object-Oriented Progmmming and Smzdltalk, Addison-Wesley Publishing Company, Inc.
[5] M. Sherman, ~~AMethodology^ for^ Wogralllmhg Abstract Data Type in AdaH, ACM Ada Tech.
[6] D. C. Luckham, ~1~^ Ovetiew^ of^ ANNA,^ a specification language”, = SOFTWARE Mar. 1985, [7] A. L. Wolf, L. A. Clarke, J. C. Wileden, “Ada- based Support for Programm@- In-The-Large”, IEEE SOFTWARE Mar. 1985 [8] E. Sheidewik, Wbject-Oriented Programming in Smalltalk and Ada”, ACM 00PSLA%6 Proc. ,
[9] X. Liang (Liang Xianzhong), GRASIS: Graphical Ada-based Specification and Implementation Support for Object- Oriented Development, CSRDA (China Ship Research and Development Academy), Theaia of MSc (in Chinese), Mar.
About The Authors
Liang Xianahong received the BS degree in computer science from Dalian Maritime University, China, in 1982 and the MSc degree in software from China Ship Research and Development Academy, in 1988. He has been with Software Division of Research and Development at Wuhan Digital Engineering Institute since 1988 and currently holds the rank of software engineer. His research interests include programming support toola and environment, software development methodology. and operating system.
Wsng Zhenyu ia currentty a professor and head of Software Division of Research and Development at Wuhan Digital Engineering Institute. His research interests include Ada language and tools, software engnieering, algorithm analysis and related mathematical tools. He is the author of 80 articles in mathematics and computer science. Prof. Wang is a member of Chinese Computer Federation and European Association of Theoretical Computer Science.
lfa
3. An Overviewof Ada-GOODS
We have developed the software system called Ada-GOODS (Ada- bssed Graphical Object-Oriented Development System), on the basis of the Ada-baaed techniques reported in the paper.
SKETCH OF ADA-GOODS
The system is composed of five subsystems and a reusable Ada-bssed unit library shown as following:
I I^ I
fha--ciooml
GJSS GISS
Multiple Users User* view of Ada-GOODS
where, I (^) Graphical Interface Subsystem (GISS) (HSS is a set of full graphic representations from design to coding with a complete menu- driven proces&
I Development Subsystem 03SS)
IXS supports three aspects of Software development: Pm – Progmmming - In-The-Small:^ Program- building emphasizing the relationship between a programmer and machine; PITL – (^) ~~g- ~- The- Large: Svtem- building emphasizing the relationship between suppliers and consaunem of code; PITM- Programming- In- The- Many : co- ordination of collective development emphasizing the relationship between developers and projacts;
kddes Sy!lttiX and semantics in Ada, LfiS
includes new contents, and may be considered as an Ada-based Program Design Language (PDL/Ada) that supports full object-oriented philosophy.
lV Paradigm Subsystem (PSS) PSS ia the s~le of use of MS, a sort of world view attached to the Ada-baaed units.
v Transforming Subsystem (TX!3) ‘ISS, a two-way transformer, will transform Ada- baaed units into Ada packagea; when expected in Ada- GOODS TSS may be used together with Ada compiler, linker etc., and regarded as a compiler of graphic PDL/ Ada; also TSS transforms external aourcecode in Adainto Ada- bssed llnitSthrOU@ comprehending (understanding).
Vi Reusable Ada-bssed Unit Library (RULIB) Alongside development ( or historical development) under Ada-GOODS, RULIB handles and mSIM#W all of Ada-based units that were designed to be reused and it not only cO-*tea the collective activity participated in by a number of develope~ but also increases software productivity with reusability of units in the library. Here the reusability refers to the characteristics attached to Ada- based units such as instance vs genericity, ”dismantlement vs installation polymorphism and inheritance, etc.
CASE IN ADA-GOODS
Ada-GOODS, WI integrated development system emphasizes program- building with an object-oriented philosophy, and stresses system- building with reusabilityof Ada- based unita. Ada- GOODS considered as a CASE system includes:
l
l
.
presentationof a graphical Ada-baaed Program
Design Language (PDL/Ada), which provides a full set of description of development processes (DESIGN and CODING) support for Object- Oriented Development Methodology ( OODM ), by abstraction and encapsulation, polymorphism and inheritance integration of a set of software tools (TOOL Sl?l’), which provides the tool set of design, coding, editing and management, etc.
