The Design of Object-Oriented Software with Domain Architecture Reuse

Albert0 M. de Cima Claudia M. L. Werner Alessandro A. C. Cerqueira

COPPE/UFRJ - Federal University of Rio de Janeiro, Brazil

Abstract

This paper focuses the software reuse aspects when the object-oriented paradigm is used in the software development. The advantages and problems of reusable object-oriented software development are identified. A development environment for reusable object-oriented software is presented. This environment uses framcworks to construct domain models, in order to make possible the reuse of analysis information in future designs. Some basic implementation requirements for this environment, called DEROS (Design Environment for Reusable Object-oriented Software), are described.

1: Introduction

The main motivation for software rcuse is to increase the productivity and quality levels [l]. This increase of quality is a consequence of reusing components that have been previously documented, tested and approved, either by the development group, or the final users. The productivity increase is a result from the reduction of the development time, by not having to rebuild the system parts that already exist, the number of documents to be created and tests to be performed, and moreover, from the reduced necessity of modification of the system because of its quality. This productivity increase has also another consequence: the reduction of the software price.

Nowadays, software reuse has bcen cncouragcd by the object-oriented paradigm [2]. This is confirmed by results obtained in the empirical study performed by Lewis, in [3], where the productivity and final product's quality are shown to increase when the object-oriented paradigm is used in the software development (if compared to the structured paradigm).

However, as in the structured paradigm, the rcuse of an object-oriented software depends on thc crcation of methodologies and supporting environments, because the object-oriented paradigm, in spite of making rcusc casier, does not guarantee it. The object-oriented paradigm

depends on the use of adequate methods and the management of the available technical, economical and human resources. It also involves a developer's "new way of thinking".

This paper discusses the advantages and possible applications of the object-oriented paradigm to support software reuse. Such advantages can be viewed as motivations to define models and implement development environments which put these two paradigms together. On the basis of these arguments, an environment to the development of object-oriented software with reuse is presented.

This paper is divided in four sections, apart from this one. In the second section, the advantages and problems related to the application of the object-oriented paradigm to support software reuse, a general view about the emerging frameworks technology and some issues about object-oriented development models with reuse are discussed. In the third section, a model proposal for object-oriented software design with reuse is described. In the fourth section, some directives to the design of an environment that supports the proposed model are discussed. In the fifth section, conclusions are done.

2: Software Reuse and the Object-oriented Paradigm

In [3], a study that compares the results obtained in the structured and object-oriented software developments, either with or without reuse incentives, is described. According to this study, it was possible to conclude that:

a) The object-oriented paradigm promotes a greater productivity, although a meaningful part of these results occurred because of reuse aspects included in the paradigm.

b) Software reuse promotes a greater productivity, independently of the adopted paradigm.

178 0-8186-6632-3/94 $04.00 0 1994 IEEE

c) The differences between the paradigms became more meaningful when developers used the reuse directions.

d) The object-oriented paradigm has a particular affinity with the reuse process.

These facts are consequences of the object-oriented paradigm inherent features, which facilitate the solution of some technical and even management problems of reuse technologies. The most important examples of these features are:

Class inheritance, that can be used as a component classification scheme.

Composite objects, together with class inheritance, allowing the incremental composition of objects and the use of strategies for linking specification, design and code. Mechanisms for organizing arid composing

systems (and subsystems) into encapsulated entities allow the reuse of previous design decisions.

Generic classes and frameworks (collections of usually hierarchically related classes, that omit certain subclasses and object instantiations, which govern application- specific functionality [4] ) can be used in the construction of domain models, because of the paradigm's formal semantics.

Domain analysis activities, through the object-oriented paradigm, allow the construction of formal models for the domain knowledge, in the early phases of development. This knowledge can also be reused in the other phases through environments that, for example, perform automatic implementation operations.

The next subsection discusses the framework technology, its inherent problems and applications.

2.1: Frameworks and its inherent Design Problems

According to Rebecca Wirfs-Brock and Ralph Johnson [5] , a framework is a high level design or application architecture and consists of a set of classes that are specifically designed to be refined and used as a group. This set of classes embodies an abstract design for a family of problems (or problem domain) and encourages the software reuse in a granularity which is larger than the one of classes [6]. This definition is very accurate when the framework is considercd a domain

modeling tool whose purpose is to support the analysis and reuse activities.

Designing a framework is itself a complex task. The designer must understand the possible design decisions and must organize them in a set of classes, developing a theory of the problem domain and expressing it with an object-oriented design model. Good frameworks are usually the result of many design iterations and a lot of hard work. Lack of generality in a framework shows up when it is actually used to build applications. So its weakness cannot be found until after it is designed and reused. Thus, iteration seems necessary [5].

A big problem to be faced during the design of a framework is that its designer must develop a solution that spans an entire problem domain and then implement that solution in an extensible and reusable manner 171. In other words, this designer must be able to perceive the best balanced point between generality and specialization of the framework to the required domain. Other framework construction inherent problem is of a technical nature, since most object-oriented programming languages do not provide direct support for either abstract classes or subsystems, it is not surprising that there is no good notation for describing frameworks [5] . Thus, the use of a powerful object-oriented language like Eiffel [8] is encouraged, because it allows the construction of frameworks by providing mechanisms for implementing abstract classes and their inherent behavior.

According to R. Johnson [6], there are two basic kinds of frameworks, if their specialization process is considered: the "white-box'' and the "black-box'' framew orks. The " white-box" framework is specialized by adding application specific subclasses to it. These subclasses inherit the generic features and behavior embodied in the framework, so the developer must understand the whole framework (all its classes attributes and methods) to be able to specialize it.

The "black-box'' framework also contains classes that embody the domain features and behavior, but these classes may only be accessed through their interface methods. So, the developer should only learn these interface methods to configure and use the framework in a specific application, where this framework will be an encapsulated component. This feature increases the "black-box'' framework reusability, but it also reduces the framework flexibility. For this reason, the "white-box'' framework is considered to be a good starting point for thc development of a domain model.

A "white-box'' framework ideally evolves to a "black-box'' framework, although i t is difficult to say how and if this process will actually happen. This process can take several iterations to be complcted, and sometimes

179

the framework life time (as any software product) ends before it occurs.

To illustrate the use of frameworks, a "white-box'' framework example is presented within the context of Software Development Environments (SDE) in section 3.1., as discussed by G.H.Travassos in [9].

3: A Model Proposal for Object-oriented Software Design with Reuse

Frameworks are important domain modeling tools, with potential applicability as reusable domain generic architectures. But, in order to improve this applicability, the development and reuse of frameworks must be embodied by a methodology which integrates them to the whole software development in a reliable and efficient way.

According to Booch [2], an object-oriented development model must embody an incremental and iterative process. Several proposals have been done as to adapt the traditional models to more evolutionary ones, some of these include software reuse activities [IO] [ I 11.

Based on [IO], we propose a model for object- oriented software design which encourages the reuse of frameworks. This model embodies the following stages:

domain design, specialization, evaluation & revision and implementation. The domain design stage aims the construction of frameworks. This stage considers a previous domain analysis activity.

Domain analysis is the knowledge identification and organization of some family of problems, in order to support the description and solution of these problems [12]. It is a complex task, because its products cannot be easily captured, organized and stored so as to be reused in a fast and reliable way. Framework allows the organization of some of these domain information, particularly the ones relevant to the design of an initial architecture for developing specific applications.

The proposed model promotes the development of two kinds of products: frameworks and specific applications. The domain design and specialization stages can be viewed as a supply activity and a demand activity [13], respectively. These stages are performed in a cooperative and independent way.

The development model also embodies stages for software evaluation and implementation. During these two stages, evaluation and implementation are performed over either frameworks or specific applications elements.

Environment for Software Design with Reuse

Subcnvironment for supporting frameworks creation . _ _ . . _ _ . . . . _ _ _ _ _ _ . _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ - - . -

Figure 1 - Model for object-oriented software design with class and framework reuse

In order to support the proposed model, an management, search and reuse of products) is needed. Considerations about such environment are made in section 4.

environment which integrates the domain design and specification stages (supporting the construction, storage,

180

A diagram for the proposed design model is presented in figure 1. The following subsections discuss the model stages in more detail.

3.1: Domain Design

In the proposed model, the domain design result is the framework. Thus, the aim of domain design is to produce a description of candidate classes and their relationships, that can be used in the construction of a generic object-oriented model for applications belonging to the same domain. Five fundamental domain design activities are defined: common activities identification, entities identification, identification of relationships between entities, specification and association of the candidate classes and abstraction of generic classes to construct frameworks.

During this stage, reuse is supported by thc environment which is responsible for frameworks and generic classes creation (see figure 1). On the basis of each domain design activity, the developer can search for reusable information for the next activity. This information includes identifications, definitions and object-oriented elements that can be reused directly or indirectly (by adapting them).

The domain design activities are fairly conventional and known by the domain analysis researchers and professionals. To illustrate these activities, a simplified example is presented in Figure 2, within the software development environment (SDE) context. The following explanations help understand the example.

a) Common activities identification. The first domain design activity is to identify and dcscribe all important events, or activities, inside the domain. It is important to describe each activity in a simple and complete way, in order to provide the activities' essential idea to the development group.

In the figure 2(a) example, the identified activities are common to any kind of modern software development environment, independently of the methodology uscd (structured, object-oriented, etc.). Each methodology requires a different way of doing these activities and two or more of them can sometimes be merged, but thcy still exist.

b) Entities identification. This activity consists of identifying all important entities that belong to the application domain. Here, we must provide a simple and

accurate description of the entities importance inside the domain and their responsibilities. We have also to describe the existing specializations, aggregations and entities features (figure 2 (b)).

c) Identification of relationships between entities. During this activity, we must concentrate on the description of the entities' behavioral relationships. These relationships have cardinality and are associated to events or existing domain activities. The example of figure 2(c) shows the identification of some relationships in the SDE context.

d) Specification and association of candidate classes. During this activity, we must specify and associate candidate classes to be used in the system development. On the basis of the previous domain design activities results, we must emphasize those activities, entities and relationships that are vital to the construction of any system in the studied domain, and present their main features.

The set of candidate classes must be organized in a formal object-oriented way. Thus, the developer must be able to create either concrete classes (that are ready to be instanciated) or abstract classes (that just describe the behavior shared by a family of classes and should be specialized in subclasses) to represent the candidate classes. In figure 2(d), the class Environment is an abstract class, because at the moment of the framework creation we are not able to completely define its methods, since they represent the activities of the software dcvelopment paradigm to be adopted. Only the methods existcnce, its parameters and constraints can be established, reflecting a generic Environment behavior.

In order to exemplify a concrete candidate class, we can take the following assumption: if every SDE must have a text editor, we should include a class to represent this editor in the set of candidate classes of figure 2(d). This text editor could be represented by a concrete class, because all its features are the same in every SDE.

This domain design activity is critical, because there is not only one group of candidate classes that could be used to represent the problem domain and therefore, the developers should have enough experience to identify the most satisfactory one. It is usually necessary several iterations during the development process to discover the best group of candidate classes that represents the problem.

181

(a) Common activities identification (b) Entities identification

Software Development Activities: Software Development Entities: analysis: [description] Environment: [description] specification: ... [features: name: [description] design: ... version: [description] implemcntation: ... . . .]

[description] tests: ... management: ... [features: ...I

[specializations:Intemal Tools

Tools:

Extemal Tools] Internal Tools: ... Extemal Tools: ... Tasks Assistant: ... Developer: ...

(c) Identification of relationships between entities

The existent relationships: - An environment has one or more integrated tools - A tool can be integrated to several environments - An environment may have an assistant - An assistant can be integrated to several environments

(d) Specification and association of candidate classes

(e) Abstraction of generic classes to construct frameworks

Fmvironmcnt

Vasion Life Cycle Methodology

Analis s S,2cation

Implemenbtion

Vasion Activity Documenlatio”

Impon Inlonrmtior~

Figure 2 - A simplified example of the domain design activities for the construction of a SDE framework (The notation used for description of classes in activities (d) and (e) is the one proposed by Coad and Yourdon [171).

182

e) Abstraction of generic classes to construct frameworks. During this activity, we must try to abstract some generic classes from the candidate classes, in order to improve the final framework reusability. Generic classes specify and implement those features that are shared by two or more candidate classes. The generic classes and the candidate classes are then grouped together to compose a new framework.

The final SDE framework is presented in figure 2(e), where the class Environment Frame is an example of a generic class. This framework is a "white-box" one and for this reason i t can evolve after being used, evaluated and implemented. This process will be supported by the iterative nature of the proposed development model.

3.2: Specialization

The aim of this stage is to spccify an application. To perform this task, the developer must search for an adequate reusable domain model, according to the application to be developed. This domain model is a framework constructed and stored during the Domain Design stage.

On the basis of this framework, the developer can search for previously developed specializations to verify if there is one that suits himher. Otherwise the developer must start a new specialization for the framework and use the components environment to search for independent reusable classes to compose the application.

According to [ 5 ] , a framework may bc spccializcd by:

1) Defining new (sub)classes that are needed; 2) Configuring the set of objects, by setting the

objects' parameters and connections.

In general, these kinds of specialization activities are inherent to the "white-box" and "black-box" frameworks respectively [6] (see section 2.1).

3.3: Evaluation and Revision

Each software element (frameworks and specific application classes) created in the previous stages is evaluated to measure its quality and reusability levels. Problems are identified and solutions are proposed. Thus an experienced professional is needed in order to perform this task.

In the case of frameworks, our major interest is to determine the right moment for evolving a "white-box" framework to a "black-box'' one, based on the domain

knowledge acquired by having experienced various specializations.

The evaluation results in the decision of including a framework or specific application in a repository for further reuse.

3.4: Implementation

During this stage, all the new developed classes must be implemented by using an object-oriented programming language. The code generated is also tested in this stage.

Because of the generic and abstract classes used as framework components, the programming language must support the features necessary to define these classes and implement them in an easy and reliable way.

4: DEROS - A Design Environment for Reusable Object-Oriented Software

In order to efficiently execute the several stages of the proposed model (see section 3), a supporting environment is needed.

The main requirements for such environment are: B to provide tools to support the activities of all

model stages; B to emphasize reuse throughout the design

process; B to supply an accurate schema to store and

catalog components, mechanisms for components' access, retrieval and understanding;

B to use the object-oriented technology; B to be a cooperative environment.

DEROS environment is built upon a hypertext system which organizes the domain knowledge and reusable components' information, allowing the reuse of high level elements. The DEROS architecture is composed by this hypertext system and several tools that together support the environment requirements and aid software developers during their tasks. Examples of such tools are:

a) Domain Architecture Constructor: guides the domain design process. Firstly, the domain activities, entities and relationships are identified and described in "informal" texts notes. The text notes are analyzed and hypertext links between them proposed to the user. Then, the object-oriented class constructor is used to construct the framework candidate classes (as figure 2 presents) on the basis of the identified domain features.

183

b) Object-Oriented Class Constructor: integrates a data flow editor and a language sensitive text editor. The candidate classes and relationships are represented in the data flow (as in figure 2(d)), while its descriptions, attributes and methods are defined using the text editor. DEROS is directed to use the Eiffel language [SI to implement the object-oriented generated classes, so the text editor is sensitive to this language. If a class represents some domain feature (activities, entities or relationships), a hypertext link between this class and the feature text note is constructed.

fiipenext Manager Repository

'I 1 1 . (An object-oriented

c) Specific Application Constructor. When a software engineer develops a specific application, he/she must specify some facet values that will be used to identify the

1

Object-Orientcd Class

CollSNCtOr

choose a framework is by navigating through the existing domains. Having found a framework, the specialization can be done by using the Object-Oriented Class Constructor.

Database)

Rcading and Authoring - Hiperbase .-

s y s t m

d) Evaluation and Revision Assistant: supports software quality evaluation, indicating metrics, providing evaluation instructions and guiding beginners in this activity. Each evaluation generates evaluation text notes that are linked to the component and included in the software documentation.

specific

e) Implementation Constructor: uses the application classes information, stored by the Hypertext System, to generate code in the Eiffel language. Thus, by integrating the Eiffel Environment [SI to DEROS, that code can be

Implementation

related domain and reusable framework. Another way to compiled, tested and executed.

Application Consmctor

DEROS - 6 r - - - - . . _ _ _ . _ _ _ _ . . _ _ _ _ _ _ _ _ _ _ _ _ _ _

Subcnvimnment for supporting framcworks cxation

4

Constnrctor

r -

I I Evaluation

and Revision Assistant Architecture

Constructor

f I I

Subenvimnmcnt for supponing specific sofiware design with muse of

framcworks a i d objcct-oriented classes - . _ _ _ _ - . . . . - - - - . . . . _ _ - - - - . . . . - - -

Figure 3 - Overview of the DEROS architecture

184

The integration of all these tools to the environment is provided by the hypertext system facilities. This hypertext system can be considered to be the heart of DEROS because it controls all information generated and required by the other tools.

4.1: Hypertext System

The DEROS Hypertext System is based on HyperCASE [14], being composed by an authoring (and reading) system, a hyperbase and a rcpository, whcre all the developed elements are stored.

Each software element developed (classes, text notes, etc.) is considered to be a hypertext node or a set of them. The reuse activities (classification, storage and retrieval) and configuration managcment are performed by the hyperbase, which also supports navigation among nodes and text analysis.

Figure 4 presents an overview of the hypertext structure, which is divided in the set of domain

architecture nodes (figure 4a) and the set of specific application nodes (figure 4b).

Nodes are typed. The basic types are: domain, activity, entity, relationship, candidate class, generic class, framework, specialization, specijic class, evaluation notes (comments and evaluations made during the evaluation & revision stage) and codified class (implementation using an object-oriented language).

The domain, activity, entity and relationship nodes are text notes (as the examples of figure 2 a-c), possibly having some trivial hypertext links. The candidate class, specific class and generic class nodes represent object- orientcd classes and they can be linked to other nodes either by trivial hypertext links or links that represent the object-oriented relationships. The shared feature node represents candidate classes' common methods and attributes that are included in a generic class. The framework and specialization nodes are a set of classes that compose a domain architecture and a specific application, respectively .

a) Domain architecture nodes b) Specific Application nodes with domain architecture reuse

_ _ - _ _

' Frameworks 3

? - - .-

Classes - _ -

Legend: a Hypertext Nodes - Automatic links _ _ - .

1 Reused Nodes . _ . . C- Semi-automatic links . . _ _ 4 Facets Node _ _ p Object-Oriented

relationship links

Figure 4 - Hypertext Structure Scheme

185

The domain, framework, specialization and classes (i.e. candidate, generic and specific) nodes have a set of associated facets, described in a facets node, according to their type. This integrates the faceted classification scheme, proposed by Prieto-Diaz [ 151, with hypertext features, as proposed in the CAOS environment [16]. Thus, users can search for components either by using the facets or navigating through nodes. For example, a software engineer can search for a reusable domain model (i.e. a framework) as a starting point to the specification of an application by establishing some facets values and letting the system compare these with the existing domain model facets.

The authoring system supplies the other DEROS elements with interface primitives (graphics, buttons, menus, e.g.) and also creates, semi-automatically (by asking for the user confirmation), links between semantically related nodes, after performing an informal text analysis. Examples of this kind of links are presented in figure 4.

The authoring and reading system provides hypertext visions according to the different kinds of users. Visions can control the user access, specifying the components this user can modify and the ones that he can only read.

All hypertext components are actually stored in a database (i.e. the repository). This guarantees that the environment's elements are actually integrated.

5: Conclusions

The DEROS environment is a project under development at COPPEKJFRJ. One of our software reuse research group aims is to evaluate the use of frameworks in domain analysis formalization, in ordcr to improve the reuse of higher level components.

The adoption of the object-oriented paradigm alone does not guarantee software reuse. It is also necessary to develop supporting tools and an adequate development methodology, besides providing some management incentives, to implement a reuse strategy.

The use of a development model and a support environment, like the one proposed in this paper, can stimulate the introduction of softwarc reuse and the object-oriented paradigm at the same time, without any serious impacts.

The SDE example used is a simplified view of the SDE framework constructed by G.H.Travassos, in the context of the TABA Workstation [9]. It scrvcd as a starting point to the establishment of gcncral requirements to the construction of frameworks.

The use of frameworks within the tool integration model of the TABA Workstation [9] indicates that frameworks are a promising reuse technology which must be further researched. Our contribution has been to present frameworks as the basis for developing domain model architectures and to propose a design model with reuse and a corresponding support environment.

Acknowledgements

We are grateful to Jlilio k i t e and the conference reviewers whose critical readings and helpful comments helped improve the earlier version of this paper.

References

[ l ] Tracz. W.; Sojware Reuse: Motivations and Inhibitors; Software Reuse Emerging Technology (ed.) Will Tracz; 1988.

[2] Booch, G.; Object Oriented Design With Applications; Benjamin/Cu"ings, Redwood City, CA; 1991.

[3] Lewis, An Empirical Study of the Object-Oriented Paradigm and So@are Reuse; ECOOP/OOPSLA91, ACM; 1991.

141 Lea, D.; Champeaux, D.; Object Oriented software Reuse Technical Opportunities; 6* Annual Workshop on Software Reuse; New York; Nov 1993.

[SI Wirfs-Brock, R.J.; Johnson, R.E. ; Surveying Current Research in Object-Oriented Design; Communications of the ACM, 33 (9); Sep 1990.

[6] Johnson, R.E. ; Foote, B.; Designing Reusable Classes, Journal of Object-oriented Programming, 1 (2); Jun/Jul 1988.

[7] Wirfs-Brock, A. et al; PANEL: Designing Reusable Designs - Experiences Designing Object-Oriented Frameworks; ECOOP/OOPSLA90. ACM; 1990.

[8] ISE - Interactive Software Engineering Inc.; Eiffel: The User Guide Version 2.3, Appendix A, An Introduction to Eiffel, Oct 1990.

[9] Travassos, G.H.; The Tool Integration Model of the TABA Workstation; Doctor of Science Thesis; COPPE/UFRJ; (in Portuguese); Mar 1994.

[lo] Gossain, S. Anderson, B.; An Iterative-Design Model for Reusable Object-Oriented software; ECOOP/OOPSLA90, ACM; 1990.

[ I l l Gomaa, H. et al; A Knowledge-Based Approach to Generating Target System Specifications from a Domain Model; IFIP Congress, Madrid, Spain, 1992.

[ 121 Pricto-Diaz, R. and Arango, G. Domain Analysis Concepts and Research Directions; Domain Analysis and Software

186

System Modeling, (ed.) R.Prieto-Diaz and G.Arango; IEEE Computer Society Press Tutorial, 1991.

[13] Moore, J.M. and Bailin, S.C. Domain Analysis: Framework for Reuse, Domain Analysis and Software System Modeling, (ed.) R.Prieto-Diaz and G.Arango; IEEE Computer Society Press Tutorial, 1991.

[14] Cybulski, J.L. A Hypertext Based Sofiware Engineering Environment, IEEE Software, 9(2), Mar 1992.

[ 151 Rieto-Diaz, R.; Classification of Reusable Modules; IEEE software 4(1): 6-16; 1987.

[16] Wemer, C.M.L.; Mattos, F.A.; An Environmenf for the Development based on the Composition of Applications; Proceedings of the VI Simgsio Brasileiro de Engenharia de Software; Gramado; RS; pp 243-257; (in portuguese); Nov 1992.

[17] Coad, P. ; Yourdon, E. Object-Oriented Analysis, 2nd. Edition, Prentice Hall, 1991.

187