A Reuse Approach based on Object Orientation. Its Contributions in the Development of CASE Tools Henda Hadjami Ben Ghezala Farouk Kamoun Ecole Nationate des Sciences de 1’Informatique B.P. 275- Citc$ Mahrag&ne 1082 Tunis - Tunisia Tel: 216.1.780394 Fax 216.1.785659 e-mail:
[email protected]
Abstract The aim of this paper is to present an approach to facilitate reuse. This approach, which is based on an object oriented design method, describes a way of structuring components and reuse library. Two concepts, domain and theme, are introduced to allow a classification of components by the services that they offer and by application domain. The library itself is organized in three hierarchical levels -general, dedicated and personal-, where the reusable components are strored according to their degree of “interest” (general interest, by application type or particular). So, the libra~ is generic and could cluster various reusable component design components, types (specljication components, packages,.. .). The contributions of this approach in the development of CASE tools are also emphasized.
L
Introduction
One of the important problems of the software components reuse consists in their localization and retrieval from a three activities: large collection. In fact, the reuse implies to retrieve components, to understand and to use them. A way to reduce the effort of reusable components search, comprehension and adaptation, consists in developing a reuse strategy which defines a component classification, a component library structure and search and use mechanisms ~ 87]. Since the seventies, a lot of studies have dealt with this aspect, in particular, they have considered the reuse of code ~ 87] ~RI 87] [TAJ 84]. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying
is by permission
of the Association
(ENSI)
of Computing
Machinery.To copy otherwise, or to republish, requires a fee andlor specific permission. SSR ’95, Seattle, WA, USA @ 1995 ACM 0-89791 -739-1 /95/0004...$3.50
53
More recenfly, studies and experiences have shown that reuse ability at each deliverable (specification, design, ...) strongly depends on the components ability to behave as a generic solution to problems [CAS 92]. Nowadays, many reuse approaches are proposed and experimented in the object oriented domain PeA 91] [WAS 91] WY 89]. In particular, we mention the studies relating to the F-ORM approach which is based on the “role” concept used by the behavioral aspect of classes @eA 91] [CAS 93], or to approaches like BON [WAL 93] which introduce the notion of “cluster” in order to group reusable classes. Other works on the development of reuse environments are presented in ~RI 87] ~UR 87] [COX 90] [CAL 91] ~ 93]. We quote in particular the REBOOT project [SIN 92] which is developing a reuse approach based on a specific method with its supporting tools and a library of reusable components classified by facets [GRO 92]. From our point of view, we think that the reuse degree in a given organization of components and of the library depends strongly on the facility of component search ancl component quality. In fact, in the case of an unstructured library, the user could spend a long time in searching for a certain component which may not exist in the library. Likewise, when components are structured in clusters, the search ean be recursive (because a cluster can contain another), thus costly in time, and can’t guarantee a positive result because the component object of the search may be absent from the library. In this paper, we propose a reuse approach where the clustering of components is done according to the services supplied and to the application domain. In order to classifj~ the components which are judged reusable by the library administrator, our approach defines two concepts, “theme” and “domain”, which are characterized by their role or the fimctions that they achieve. Furthermore, our approach is based on the structuring of the library in three levels which depend on the genericity aud the quatity of storecl components. These levels are called “general level”, “dedicated level” and “personal level”. This approach has been integrated into the object oriented design methocl called MEMO [HAD 90] ~ 94a] elaborated within a
CASE tools development project PGL [HAD 94b]. The application of this approach in the framework of this project allowed to asses its advantages. In the sequel, we present the classification introduced in the method, then we describe the implementation of the library and its management. Finally, a performance evaluation of our approach is provided.
2. Classification components
of reusable
Thus, in order to classi~ reusable components, we have introduced two structuring concepts (theme and domain) into the object oriented method MEMO [HAD 90] &AD 94a] [HAD 94b]. To illustrate these concepts and to fix ideas, we first present our method MEMO. Fundamental
concepts of MEMO
MEMO is an object oriented design method that favors the reuse activity thanks to the structuring concepts that it introduces. The basic entity of MEMO is a class which representation of a group of similar objects.
is an abstract
In MEMO, we also find the well-known classes and objects:
relations between
instantiation instances.
creation
relation
enables
the
reflects the interaction
of class
inheritance relation reflects the fact that certain structures must not be defined from scratch but will inherit from already defined ones. - aggregation relation reflects the fact that a class can be composed of other classes. Two classes which are linked by such a relationship are called member classes. In fact, MEMO recognizes two types of aggregation: . the composition relation between two classes A and Et indicates that class A defines an attribute of class B. the reference relation between two classes A and B indicates that A defines a reference to an instance of B. This relation ensures polymorphism.
54
between instances
composition and reference relations Inheritance, represented on Fig. 1. by respectively links is-a, iscomposed-of, and reference, allow the reuse of already defined classes. (This figure illustrates the structuring entities introduced to organize components in MEMO and presented in the following paragraph). Further more, MEMO
Work on the object paradigm shows that object oriented techniques favor the reuse activities more than the procedural solutions [WAS 91]. In fact, basic features of the object oriented techniques appear to fhlllll the needs of the developer to reuse software. As a matter of fact, the encapsulation aptitude permits the ease of object incorporation in a new design. Mechanisms like genericity, inheritance and polymorphism convey also solutions to reusability.
2.1
- message flow at execution.
defines two models:
- the graph of inheritance and instantiation (GII) which models the static aspect of an application. It regroups in the same graph, classes and objects representing the application to develop, as well as relations of composition, reference, inheritance and instantiation. - The graph of message-flows between objects (MFO) which models the dynamic behavior of an application. It represents the interactions defined by the message-flow. In the following paragraph, we present the two structuring concepts domain and theme which are introduced in our method in order to facilitate reuse. 2.2
The structuring
entities
when structuring, we are interested in software components rather than in projects ~Y 89]. In fact, each component is recognizable by descriptors which must describe, among others, the services offered. In fact these services can represent a production chain of components whose role is precise and which can be linked to each other. The component role can be seen as a necessary task to achieve a certain fimction. To illustrate this. let’s give an example of the of the management function of a graph on screen. To achieve this function, we need tasks such as: manipulations of a drawing on a screen, managing the style of the drawing lines and characters and managing the data structure which is associated with a drawing. In reality, each of these tasks is achieved by calling on well defined components services such as the class which allows to draw a rectangular form, to move it on the screen and to modi@ its dimensions. Similar to classical decomposition methods subsystems (well-accepted by developers), following structuring entities:
of
systems
in
we define the
- The domain is a structuring entity similar to a subsystem. It regroups a certain number of components which relate to a certain concept like a system function. These components are themes. A domain is represented by a rectangular form annotated by the domain name ~ 94a] as indicated in fig. 1. which shows the GRAPH domain structure.
- The theme is a structuring entity whose study field is precise. It is similar to the classical module that achieves a specitlc task. The theme is composed of classes which are linked to each other thanks to the relations defined in the previous paragraph, Thus, the content of a theme represents an inheritance graph (GHI), A theme is represented by a dotted rectangular form with rounded corners and annotated by the theme name as indicated in fig. 1. where we can distinguish the themes DRAWING, REP-MEMORY and OPTIONS. This figure illustrates the example quoted above and represents the GRAPH domain which ensures the graph managing function on the screen. This domain regroups three themes defined as indicated below:
. the theme DRAWING models the graph appearance on the screen. the graph being composed of circles and/or rectangles. - the theme OPTIONS represents the options of styles which are adopted to draw a graph. In this example, the options cleat with character and line styles.
——— ——— ——— ——— ——— ——— ——— ——— ——.--——--.7-I
,m;
F~g.1. Structuration
of components ““ ““
This decomposition of a domain in themes seems logical since a domain describes a function which can be refined in order to provide more precise sub-functions. Each of these sub-fimctions corresponds to a theme. A reusable component may be a domain, a theme in a domain or a class in a theme. It is then important to be able to locate them easily and rapidly. This is possible if the descriptors relating to components are well defined. 2.3
Reusable component’s
- a theme is identified by: its name, its domain, the task that it performs and the lists, without redundancy, of authors and keywords of all the classes that compose the theme.
. a domain is identified by: its name, the fimction that it performs and the non redundant lists of authors and keywords of all the themes that compose the domain. By “services offered”, methods in the class. 2.4
- the theme REP-MEMORY models the representation of a graph in the memory. The B-Tree is the data structure chosen here.
L—— ——— ——.
- a class is identified by: its name, its theme, its domain, its author, the services that it offers and a key-word list.
descriptors
To improve and facilitate reuse activities, we attribute indexes to components. These indexes contain, on the one hand information which permits to retrieve a component by its position (such as the domain and the theme to which a class belongs), and on the other hand information which permits to retrieve a component by its logical description (like its role or its key-word list). Thus:
55
The ti”lizm”on
we mean by a class, a set of defined
of reusable components
After having defined the structuring of components and how to retrieve them, we focus, in this section, on the important activity of the reuse process: “how to use reusable components?”. To do this, we establish four utilization
rules as follows:
RI- A theme uses another theme by composition if composition and/or reference relations exist between the classes of the two themes. In this case, we say that the themes are members. In Fig. 1. themes REP-MEMORY and OPTIONS are members because the class info-shape of the first theme is composed of line and character classes of the second theme. R2- Likewise, a theme uses another theme by inheritance if there exists a class of the first theme which inherits fkom a class of the second one. In Fig. 1., the theme REP-MEMORY inherits from the theme DRAWING because the class info-shape which belongs to the first theme inherits from the circle and rectangle classes which belong to the DRA WING theme. R3- A domain uses another domain by inheritance
if there
exists at least two member themes, each belonging to a domain, which are linked by an inheritance relation. This is illustrated in Fig.2. which shows that in order to realize the A4CT domain whose role is to manage a Processes Conceptual Model [TAR 86] graph, two themes are defined: the theme GRAPHICAL REPRESENTATION to manage the model, and the theme TECHNICAL DOCUMENTATION to elaborate the model More specifically, the GRAPHICAL documentation. REPRESENTATION theme which belongs to the MCT domain inherits from the REP-MEMORY theme which belongs to the GRAPH generic domain (described previously). This is logical if we consider that the MCT model is a particular graph. Then, we say that the MCT domain inherits from the GRAPH domain.
1
~llr’+-
*E -—— I.——DRAW ——_—
—. f
!1
types of components, as well as the reuse of components. Moreover, the conceptual relations existing between components are preserved, In this way, the structure coherence is maintained.
I
We note also that domain and theme concepts could be generalized for any component form (objects, classes, object models, classical models, specifications, ...). and applied for any type of project.
IIIII
m!!!!
In this paragraph, components, their their retrieval and following section, which allow the components.
r--l1
[=----1
3. Design and management of the library of reusable components
,1
i
)
-—
[ GRAPHICAL REPRESENTATION -———————————————.
we have been particularly interested in organization, the indexes which allow the rules which allow their reuse. In the we are interested in the infrastructure storage and the management of those
~;
I TscHNICAL ~
;
DocUMENT _,
rxlz7--––––”–––––– ——————. F@2. Relations between structuring entities
R4- A domain uses another domain by composition there exist at least two member themes, each belonging a domain, which are linked by such a relation..
if to
simplfi the diagrams in figures 1 and 2 and to improve their risibility, we illustrate in Fig,3. only domains and themes and the relations which link them. To
Reusability may be considered according to two different perspectives [CAS 93] [GAL 92]: the “design-by-reuse” “. In the first case, an and the “ design-for-reuse application can be built using components extracted from the component’s data base. In the second case, the base is enriched with components that are sufficiently efficient and well defined to be reused in a new development. In order to allow developers to work in both directions, the component’s base, or reuse library, must be structured so as to allow access to components with certainty, reliability and speed.
,.
,... ,DtiwAGy&;@oRy~[Doc~~ ““e;
““”””’”,
:
I
3.1
GRAPH
I
