soft computing in object-oriented design

SOFT COMPUTING IN OBJECT-ORIENTED DESIGN

Luiz Fernando Capretz University of Aizu, Aizu-Wakamatsu, Fukushima, 965-80 { Japan

Abstract. Soft computing can have an impact on software engineering. The purpose of this paper is to

discuss how dierent levels of knowledge that a software designer has about the application domain can aect software development. Software life cycle issues which arise during the design of object-oriented software systems are discussed, related to the topic of application domain, and placed in the context of a general methodology for object-oriented design called MOOD.

1 The Role of the Knowledge about the Application Domain

in a familiar application domain. Of course, there are dierences in the approach to developing software systems if designers can apply their knowledge and skills acquired when software systems in a known domain have been developed before. Adelson and Soloway 4] claim that the experts explicitly construct high level abstractions of a software system whereas novices think about low level entities and their behavior within a software system. Therefore, the knowledge that designers have about an application domain aects the way software development is carried out. The experts tend to think in more abstract and high level terms following a top-down approach whereas the novices usually start thinking about low level abstractions of a software system and software development is thus predominantly bottom-up. A strictly top-down or bottom-up approach to software development is not quite appropriate for an object-oriented software development 5]. Instead, we propose a top-down or bottom-up approach to software development, depending on the knowledge that designers have about an application domain. This knowledge naturally determines the predominant approach to subsequent software development.

Like software engineering, soft computing is a collection of methodologies that ultimately aim to exploit the tolerance of imprecision and uncertainty to achieve tractability, robustness, and low cost solutions. Soft computing is aimed at accommodating the pervasive imprecision of the real world 1, 2]. Thus according to Zadeh 3], it is likely to play an increasingly important role in many applications areas, including software engineering. It is a fact that we live in a world that is pervasively imprecise, uncertain, with multiple application domains. Software system designers hardly ever solve a new problem from scratch. Instead, they try to identify similarities between the new application and previous applications and their solutions, in well-known application domains. By making suitable transformations from previous experience, designers attempt to solve the new problem. This process is referred to as solving by analogy, which is considered to be a natural way in which people learn. The successful use of analogy depends on recognizing the similarities between two problems and recalling the solution of the analogous problem. Therefore, it can be assumed that the knowledge designers have about an application domain increases the chance of reusing solutions from previous experience. However, many object-oriented methodologies do not take this human feature into account. When designers are developing software systems in an unfamiliar application domain they do not have the same knowledge and skills available to them as when they are developing software systems

2 Fuzzy Knowledge in the Design Process The object-oriented paradigm is expected to be at the forefront of new approaches to the design of complex software systems, so much so that it is bringing signi cant bene ts in the design and implementation of software systems. The rapid development of this paradigm during the past ten 1

years can be attributed to several important reaIf designers know the application domain, they sons which include: should start thinking about high level abstractions, whereas when designers do not know much about Better modelling of real-world applications. the application domain, they should start instantiating objects and trying to understand the Better structure for software systems based on low levelsome behavior of a software system. As software abstract data type concepts. development proceeds, designers may sometimes Possibility of software reuse during the design utilize a mixed approach to software development, switching between a top-down and a bottom-up apof software systems. proach as designers may explore options. However, Because of the perceived importance of an the predominant approach is determined by the deobject-oriented approach, several methodologies signers' knowledge about that application domain. have recently emerged 6, 7, 8] The steps proposed In broad terms, it might be concluded that everyby a general methodology for object-oriented design thing should be built top-down, except for the rst named MOOD 9] are shown in Figure 1. time. It is important to realize that identifying classes The top-down and bottom-up approaches have is not the same as identifying objects. Classes are a a signi cant eect on software reuse as well, bemeans of expressing static commonalities between cause a top-down approach applies reusability preobjects and templates to create them, whereas ob- dominantly in terms of generalization and specialjects will have a dynamic life in a running soft- ization of abstractions, whereas a bottom-up apware system. MOOD diagrams can express both proach uses reusability predominantly as aggregathe static and dynamic aspects of a design. On tion of components. Following an object-oriented one hand, the static design consists of class hierar- approach, reusability not only becomes easier as chy and composition diagrams. On the other hand, a consequence of the correspondence between realthe dynamic design is expanded with both object world entities and its software components, but it and operation diagrams which represent the overall will also become enhanced by mechanisms such as dynamic behavior of a software system. At rst, inheritance and composition which are vindicated the operations on individual objects are presented by MOOD and its supporting tools. in object diagrams and then these operations are Putting such arguments into an object-oriented combined to perform the functionality required for software development framework, and particularly the software system. relating them to MOOD, produces the following obThe steps emphasize design before implementaservations. If the application domain is known by tion and are independent of any programming lanthe designer then it is easier to start abstracting guage. The design process originates with an abclasses,

nding commonalities between them, and stract model of the application and culminates with building the class hierarchies. The use of the class a design model ready to be implemented. The path hierarchy diagrams, as recommended by MOOD, connecting these two models is not a straight line, is likely to be more appropriate for this task. On but rather an iterative re nement process. In the the other hand, if the designer wants to start a decourse of building an object-oriented software syssign by instantiating some objects, then the object tem, the steps involved in the design of the necessary classes and objects are almost certain to be diagrams and operation diagrams are the most appropriate to represent the abstractions. repeated many times. Therefore, the design of an object-oriented softThe implication of such observations on tools ware system can be seen at two dierent layers of which automate software development, and particabstraction. There is an upper generic layer which ularly tools supporting MOOD, is of much releshows the static description of a software system vance. The designer should be aided by a whole and a lower level layer which consists of objects and range of tools. However, which tool is most helpshows the behavior of a software system. The up- ful depends on the level of knowledge that the deper layer can represent the set of classes from which signer has about the software system being develany software system may be constructed, while the oped and on the application domain as well. Therelower layer depicts the actual objects and potential fore, all tools should be available to the designer object interactions required in a particular software at any time during software development. The desystem. The design of each layer may be carried out signer picks up those tools which will help deal with simultaneously. Nevertheless, a set of fuzzy rules to the concepts manipulated at that moment, such as map the above steps are still not well-de ned at this classes or object behavior. By using a variety of tools, the designer is able to decide which of them seminal stage. 2

Figure 1: The Steps for Object-Oriented Design

3

is the most appropriate for each task. Therefore, References a CASE environment should allow both bottom-up and top-down approaches to object-oriented soft- 1] T. Terano, K. Asai and M. Sugeno \Fuzzy Sysware development. tems Theory and Its Applications," Academic Press, San Diego, CA, 1992. 2] T. Takagi and M. Sugeno \Fuzzy Identi cation 3 Final Considerations of Systems and its Application to Modeling and Control," IEEE Transactions on Systems, Man This paper has aimed at enlarging the horizons and Cybernetics, 11, 116{132, 1985. of research on soft computing beyond its traditional areas. This work has been prompted by the lack of 3] L. A. Zadeh, \Soft Computing and Fuzzy entries in the literature concerning fuzzy systems Logic," IEEE Software, 11(6), 48{56, 1994. and object-oriented design 10], and the perceived importance that both areas can play during soft- 4] B. Adelson and S. Soloway, \The Role of Domain Experience in Software Design," IEEE ware development. Transactions on Software Engineering, 11(11), It has been argued in previous sections that the 1351{1360, 1985. designer can use MOOD to represent a software system by using only a xed set of diagrams. Class 5] L. F. Capretz and P. A. Lee, \Reusability and hierarchy diagrams are graphical notations depictLife Cycle Issues within an Object-Oriented ing how classes are arranged hierarchically. Object Methodology," in Proceedings of TOOLS diagrams and operation diagrams are used to repUSA'92 - Technology of Object-Oriented Lanresent the behavior of a software system. During guages and Systems, Santa Barbara, CA, pp. object-oriented software development, these two de139{150, Prentice-Hall, Englewood Clis, NJ, sign sub-phases can become blurred and iterative, 1992. and therefore the boundary between them becomes even more indistinct. Hence, the importance of in- 6] G. Booch, \Object-Oriented Design with Appliterrelated tools. cations," Benjamin/Cummings, Redwood City, As the design phase strongly depends on the CA, 1991. knowledge that designers have about the application domain, this experience will guide designers to 7] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy and W. Lorensen, \Object-Oriented use the most appropriate tool. During the static deModeling and Design," Prentice Hall, Englesign, the most abstract aspects of a software system wood Clis, NJ, 1991. are picked up, therefore a class hierarchy diagram editor is more likely to be used. On the other hand, 8] R. Wirfs - Brock, B. Wilkerson and L. Wiener, in the dynamic design, the behavior of the software \Designing Object-Oriented Software," Prensystem is understood in more detail and the use of tice Hall, Englewood Clis, NJ, 1990. an object diagram editor and an operation diagram editor are more suitable. 9] L. F. Capretz and P. A. Lee, \Object-Oriented The guiding principle of soft computing is to exDesign: Guidelines and Techniques," Journal ploit the tolerance for imprecision, uncertainty and of Information and Software Technology, 35(4), ambiguity to achieve low cost solutions. Although 195{206, 1993. soft computing and software engineering is still in its initial stages of merge and natural evolution, it is 10] D. Dubois, H. Prade and S. Sessa, \Recent Literature," Fuzzy Sets and Systems, 61(1), 115{ rapidly growing in importance and are expected to 127, 1994. be a fruitful software research branch in the years ahead. Both are likely to produce essential tools for the speci cation, design and implementation of high quality object-oriented software systems, as it has been suggested in this paper.

4