PATHOS - A Paradigmatic Approach To High-level Object-oriented Software development Rakesh Agarwal and Patricia Lago Dip. Automatica e Informatica, Politecnico di Torino Corso Duca degli Abruzzi 24, 10129 Torino, Italy email:
[email protected]
Abstract
attributes and services. This makes analysis, design and code results more compact reducing redundancy [4] [5]. Further it packages problem-domain constructs, providing stability over changing requirements. Three advantages of OO programming languages are their support for encapsulation, reusability and extensibility [6]. Encapsulation is the strict enforcement of information hiding [7]. It helps in minimizing interdependencies among separately written modules by de ning strict external interface. The primary reason for requiring encapsulation is to make it possible to change (improve) the implementation of a module without having to change the module clients. Reusability is the process of using a part of the software other than that for which it was initially designed. Extensibility is the process of adding new functionalities to an already existing system. With all the bene ts existing in OO development we now enhance its power towards maintainability by applying the principles of PATHOS. It is an important fact of life that \what people think critically in uence their behavior". Images and paradigms are means of organizing thinking and thus means of providing behavior. It is impossible to understand the \real world" of software development without appreciating how the images held by developers in uence their behavior and the system they develop. Image is an idea or conception of past experiences that is stored within oneself. The behavior he/she exhibits depends on this image. Messages consist of information and the value of this message is determined by the amount of change it makes on the image. Paradigm is an accepted \model or pattern" that is interpreted and applied by di erent people. All software developers have an initial image of a software development process, which comes from their experiences. The holder of the images, that is, software professionals come across a series of messages which inform them about their lack of success and their incapabilities for changing the contents of the image. A Software Development Process (SDP) is based on the previous results which supply further information to the discipline. This creates an image which is accepted by the people of that discipline and thus in other words an accepted model or pattern. This image would thus guide actions in that discipline. Since any software application is not static, i.e. it always requires changes because of continuous problems raised by maintenance activities, it is clear that a process like software devel-
The growing complexity of information systems and the ensuring problems of their development, maintenance and management have highlighted the inadequacy of formal and informal methods for constructing such systems. These problems manifest themselves in the computer systems which are often unmanageable, unreliable, in exible and hence dicult to maintain. Users have often demanded for reliable computer systems because they realize that most failures are due to poor speci cation, and design. This has resulted in the emergence of a number of information systems methodologies together with associated computerized development environments in which the Object-Oriented (OO) approach is one of the most recent. OO is often used for promoting software development and its reuse. Languages like Smalltalk reduce not only development time but also the cost of maintenance, simplifying the creation of new systems and the reuse of old ones. Nevertheless OO is not a panacea i.e. e orts are to put in for its proper use. Thus we consider OO as a paradigm which provides a new image, a new way of conceptualizing the development life cycle. By the help of paradigms, software developers and users are supported in apprehending the development life cycle and means to organize the aspects of the life cycle into a comprehensive method. PATHOS (A Paradigmatic Approach To High-level Object-Oriented Software development) aims to demonstrate an approach to information system development that will lead not only to good information system creation, but also to explicitly represent the maintenance of the business knowledge so as to allow for its more e ective and active exploitation at run time.
1 Introduction
Compared to most industrial branches of industry, the development and manufacturing of software systems is young. Software maintenance is extremely expensive and much e ort is being devoted to reduce its costs. The PATHOS model proposed here will help us to understand the software development process, evaluate maintenance e orts and improve the management process itself. The OO development process is now being used to develop systems and one of the main purpose of OO development is to maintain the system more eciently and e ectively [1] [2] [3]. OO development applies inheritance to identify and capitalize on commonality of 1
a team in exploring a problem and in making a careful design. A lot of e ort is required to write code for reuse, but it is the e ort that plays o generously in the end. Time spent in making the design carefully helps to understand the problem more deeply. Subsequently the implementation goes faster because a lot about the problem has been learned. The time required for one cycle remains unchanged or even reduced.
opment really cannot be enclosed in a "box" i.e. image created by paradigm. The organizational structure and therefore the management of structuring techniques is important for software development which would be a part of the so created image. The OO development process through PATHOS would help us in focusing upon building structures [8] [9] which are capable of adapting the changing attributes in the dynamic environment. The paper is organized in the following way: section 2 compares the traditional and OO software life cycles. Section 3 de nes and explains images held by software developers. Section 4 discusses the process of PATHOS explaining its basic concepts. Section 5 discusses the software development life cycle where paradigmatic approach is applied to OO software development. Finally, section 6 draws out the basic conclusions and makes necessary requirements for the implementation of OO software development.
3 Image
Software system professionals generally hold a traditional image as an internal mental picture of software system development. This traditional image is a conception of what comprises software system development technology. The new ideas impact the images, which consist of information [11]. They can impact the software in four ways, as shown in gure 3. First the image may remain unchanged which is the case with majority of messages. Secondly the image may be changed in a consistent well-de ned manner. In the third case the impact results in the reorganization of the image. And nally a strong impulse exists to reject the information when an image may receive a message which signi cantly con icts with the image. Many economists have made observations linking conceptualization with behavior: Kenneth E. Boulding [11] says that \behavior depends on the image, and that image is built up as a result of past experiences of the processor of that image". The images consist not
2 Traditional and Object-Oriented Software Life Cycles Testing Requirement specification
Implementation
Design
Figure 1: Traditional Software Life Cycle
Message
Figure 1 and gure 2 show the life cycle comparising in the case of the traditional software and OO software [10]. Each step in the life cycle comprises of iterative process. Software is re ned when it is used as the basis for the de nition of other software. Software is tested when its behavior is determined either to conform to the speci cation of the software or not. Software is maintained when errors are found, corrected or is enhanced for reuse purposes. By looking at gure 2 we can easily understand that in OO software life cycle most of the overall time is spent on the design phase as compared to the time spent on the implementation and testing. This is used because the software is being designed for later reuse, maintenance and modi cation. OO programming tools by themselves do not guarantee reusable, maintenable, and extensible software. However, they help to support
New Image
Figure 3: E ect of Message upon the Image only of the fact components but also the value components that act to judge the fact components. Further the stability of an image depends upon the inherent consistency. If the components of the image seem to t together, the internal strain of the image is minimized. Thus images are a kind of value systems which constantly lter messages. Moreover, these value systems are shared by a group. This group does not merely share the ltering system; the group initiates messages which constantly impact lters. The image depends upon all the members of the group sharing it. A shared image is thus an organic entity whose growth and development is similar to that of complex organizations.
Testing Implementation
Message Effect Old Image
unchanged or defined change or reorganized or revolutioned
4 The Paradigm
Requirement specification
Paradigm is the formalisation of a speci c and successful image which is shared by members of a discipline. Since software developments are based on past achievements, paradigms are important. These achievements are received and acknowledged, thus supplying the foundation for further practice in a discipline. Thus paradigm is \an accepted model or pattern". There
Design
Figure 2: Object-Oriented Software Life Cycle 2
are two important characteristics: rst paradigms are suciently important to attract an enduring group of followers. Secondly, paradigms are suciently useful to motivate these practitioners to constantly employ them in disciplinary activities. Once a paradigm has been established, it may be replaced only if an alternate candidate is available. A new paradigm is accepted only if the old one has failed and the new paradigm appears to answer the anomalies inherent in the old. The theory of paradigm states that [12]:
(a) the media of information (b) the hierarchy of the information (c) the level of abstraction of information The gure 4 shows a typical life cycle of OO development implying the principles of paradigms [16] [17] [18] [19]. The three broad processes involved are de nition of technical activities, technical control activities and organizational control activities.
Managing an organizational structure is the most important aspect of managing software reliability.
Technical Activities
Corollary 1: The reliability of a software system is inversely related to the noise it contains. Corollary 2: An organizational structure regulates the ltering of noise as a system is developed. Corollary 3: The importance of managing organizational structures increases with the complexity of the system being built. Here the structure refers to the sum total of the interrelationships of all the people within an organization. Noise is any undesired disturbance in a system which the user does reasonably expect. The theory of paradigms suggests that process techniques, the focus of traditional image are marginal to successful software management. An organizational structure and therefore the management of structuring techniques is the cardinal factor. The development of software systems takes place in an environment characterized by dynamic, constantly changing attributes. The paradigmatic approach, by focusing upon organizational structures capable of adapting to these changing attributes fosters an organic methodology well suited to a dynamic environment. The paradigmatic approach is applied by concentrating upon the organizational structure and by selecting and managing techniques that provide the most e ective structures. The organizational structure can be controlled by software developers by selecting the most suitable techniques and by organizing them into a disciplined approach.
Find Classes/Objects Find Methods/Behavior Define Classes/Methods
Technical Control Activities
Logical Design Detailed Design
Organizing Control Activities
Implementation Testing
Figure 4: Model for Object-Oriented Software Development with PATHOS
5.1 De nition of Technical Activities
In this step the paradigmatic approach organizes the technical level activities necessary to develop a reliable software system. These activities operate in an environment characterized by relatively certain information. The paradigmatic approach speci es the technical activities into classes/objects. Each class/object is expected to translate input into output according to pre-speci ed plans and procedures. However this is the same as in the traditional approach, but paradigmatic approach places prime emphasis upon linking of the phases via structures which facilitate the communication of information both forward and backward through feedback. The following steps are to be performed in the technical level of the OO software development as organized by the paradigmatic approach: 1. Find the classes/objects that are needed in the system development. 2. Find methods and behavior associated with them. 3. De ne classes and methods.
5 A Paradigmatic Approach to Highlevel Object-oriented Software development(PATHOS)
The typical development process for OO systems is based on continuative, iterative elaboration of the details of the various classes, objects and their relationships rather than on the more traditional waterfall model. This approach relies heavily on identi cation of reusable classes and objects [13] [14] [15], as well as derivation of new classes from the existing ones. The production of a software system is basically the solving of a particular type of problems. The problem is expressed in terms of the user's expectations. The solution to a problem is an adaptable software system that really meets those expectations with cost constraints. The user problem is to be translated from a speci c problem statement into validated computer instructions. The three steps followed are:
5.1.1 Find Classes and Objects
In order to nd objects or classes it requires analysis of the application domain. For this it is wise to identify relationships among various object types and to de ne their common properties. In this process, it is essential to really think in an OO way so that the transformation from analysis to design is consistent. The analysis of objects includes the understanding of the behavior 3
PLANNING
ORGANIZING
STAFFING
COORDINATING
DIRECTING
WHAT Integration of techniques HOW MANY Integration of control Estimation of job WHAT HOW Size of staff Management plan Policy WHEN Statement of work Procedure Mythical man-month How Training alternatives Computer program develpoment Directives plan Quality assurance plan Configuration plan DEFINING Data management plan Work-breakdown structure Work packages Training plan WHO MEASURING Installation plan Generic structure Earned value measurement Operative plan WHEN Binary status accounting WHO Structure by phase CORRECTING Project organization plan Techniques employed Change schedules WHEN Change resources Development control plan Change budgets Works plan
Figure 5: Organizational Control Structure associated with each object. In order to achieve this a technique such as information modeling using paradigm can be a part of an OO analysis approach, but the goal is a set of class de nitions with a behavior de ned for every class. According to paradigmatic approach, determined classes and objects should be reliable and maintainable. Management must integrate organization searchinglearning-deciding, so that the development e ort progresses in a controlled manner from the conceptualization of the problem, which is the establishing of requirements, to the nal solution. In the context of organizational problem solving, there are three levels, the technical, the managerial and the institutional level. These levels di er in their focus of actions, in their need to process uncertain information, and in their environment.
expectation changes. In fact technical control can be de ned as the integration and direction of the technical tasks into goal-directed coordinated behavior. The goal is to integrate technical behavior to the extent that a reliable and maintainable software system is developed within the constraints of time and budgets. To accomplish this objective, technical control must maintain a historical record of the system evolution. The record will assist the technical control in monitoring the system progress and in controlling of the system development. Since a software system gives information, the history of these information must be managed as part of the technical control. Here an important function is the task of managing the documented information pertaining to the development of a system and it is a necessary task for technical control. PATHOS organizes the classes inherent in the technical control level into a disciplinary approach and suggests techniques to address these classes. These techniques are not selected only for their utility in exerting control but also because they help the system development e ort to the unpredictable changes that occur during the development life cycle.
5.1.2 Find Methods and Behavior
Along with the properties of classes it is also necessary to know their behaviors. Behavior is described by a set of methods. In other words it is a set of operations associated with the objects; those activities used to assign, modify or access the values of the object. Some methods can be easily identi ed in the system requirements stage but some may be apparent only during architectural or detailed design. There are many di erent ways of nding methods. However the right methods can only be found when the class relationships are fully identi ed.
5.2.1 Logical Design
As the classes are identi ed and their identi cations re ned, the developer must think about the use of these classes in a software system. Here the class re nement process will take place. The logical design phase must show the methods that are used in each class connected to the methods that use them. Also the use of a class by another class often includes the instantiation of an object in the \used" class.
5.1.3 De ne Classes and Methods
Method is a step by step algorithm executed in response to receiving a message. Here we de ne precisely the speci cation of the inputs and outputs for each method for each class. Now while de ning this a strict consideration of principles of encapsulation i.e. information hiding is to be taken into consideration. Further a clear de nition is required for the ways in which objects collaborate with other objects in order to discharge their responsibilities.
5.2.2 Detailed Design
Detailed design is the activity of completely specifying each program unit in terms of the conditions in which each unit expects to operate, the input data it expects to receive, the transformation it will perform on that data and the output that will be generated from these transformations. Detailed design proceeds from the logical design, using additional notations, appropriate to the implementation language and working any necessary re nements to the interface speci cation.
5.2 Technical Control Activities
Our goal is to manage software reliability i.e. to economically develop and maintain the software systems that operate as we aspect and can be changed when our 4
5.3 Organizing Control Activities
Organizational control level activities take place in the most open of the three environments described above i.e. one characterized by uid properties and signi cant information uncertainty. Therefore, the searching-learning-deciding operations that characterize organizational control must be operable in conditions of greatest uncertainty. Every organization has goals that it attempts to ful ll and in addressing these goals, the organization must make resources available to its components and must ensure that the output of these components is usable. In this context of goals, inputs, process, and outputs, organization needs information for which software system provides solutions. The organization must t the management of software reliability into this context of goal and resource contingencies if it is to solve its information problems. Organization control is facilitated through: Planning, Organizing, Stang, Coordinating, and Directing. Figure 5 shows the organizational control structure.
Items
Customer Requisition read
Shop
Link
write
Figure 6: Example of an inventory system using functional/data-oriented approach which the customers buy parts directly from the shop and each transaction is registered in the data system.
6.1 Functional Approach
In case of functional approach there is a di erence between operations and data. Operations are described in the form of programs, that is, functions or processes. Data are described as structures or variables in the programming languages with abstract or application related names as shown in gure 6. The operations and data are related by the function of read/write at a particular level. The function that performs the operation on data must know the internal structure of those data. In our example , di erent sparepart types might have di erent formats. The operation that performs this must know about this. In order to handle such di erences in data we need a number of conditional clauses. They have nothing to do with the requisition as such, but are only necessary because of the variation of data formats. Such programs are dicult to read. A change in underlying structure will immediately a ect operations using these data. A change of data structure may require changes of several functions and in a great many places. Every reference to the data must therefore be checked and updated, an extremely metriculous task. The spare parts of te pare parts of the shop can be kept in a list. However, if it is decided at a latter stage that they should be kept in a table, then this would a ect all the operations using the stored list.
5.3.1 Implementation
The implementation phase produces a code for each translated unit which, in turn, it translates to unit test. Each unit is converted from the meta-code noted in the detailed design phase into a machine readable high-level language. This language is compiled until it is error free and then it is translated into the unit test phase. The paradigmatic approach would concentrate upon two aspects of the implementation: 1. A technique is to be used to feedback to the detailed design information demonstrating noise free translations and providing a mapping between program language and code. 2. A technique should be used to change meta-code to a computer language and convert it into unit phase to be tested by the procedure and criteria developed in detailed design.
5.3.2 Testing
6.2 PATHOS Approach
For the engineer responsible for software testing, OO design means that entities of the system can be isolated and tested one at a time. Errors can easily be traced to a speci c entity. Entities can be shown to function independently before being plugged into the rest of the system. Additionally the paradigmatic approach would concentrate on a test plan and procedures document that partitions the testing into phases, and criteria for each phase. Further a technique or a set of techniques for linking the test results to speci c development phases should be used.
When the spare-part example is developed with PATHOS technique, the modeling is performed in terms of objects only as shown in the gure 7. Obviously, the object types di er as far as properties are concerned, however they are objects. In PATHOS model, all behaviors connected with a particular Item is placed in the object containing all the data about the Item. The object Customer Requisition does not know the internal structure of the data contained in Items or in Shop. It can only reach them via the operations of the objects. With the aid of inheritance it is possible to create several variants of Item objects, that have di erent internal data structures. All new object types have one thing in common, that they know the operation Requisition, a propety they have inherited from their shared parent, even though it is performed in di erent ways in di erent objects. It is obvious from gure 7 that the Customer Requisition object does not have to pay attention to what type of object is requisitioned, as Items all know the operation Requisition.
6 Comparision between functional data model and PATHOS model
There is a great di erence between the architecture of a system that has been developed with PATHOS approach and the one that has been developed with functional/data-oriented approach. To understand it clearly we will use an example of an inventory system in 5
Requisition Customer Requisition Customer
[6] R. E. Johnson and B. Foote. Designing reusable classes. Journal of Object-Oriented Programming, pages 22{35, June/July 1988. [7] G. Bruno, A. Castella, R. Agarwal, I. Pavesio, and M.P. Pescarmona. Introducing and practically using an object-oriented design automation/prototyping tool. In Third Symposium on Assessment of Quality Software Development Tools, pages 138{147, IEEE Computer Society, Washington, DC, June 7{9, 1994. [8] T. De Marco. Structured analysis and system speci cation. Prentice Hall, 1979. [9] D.E. Perry and G.E. Kaiser. Models of software development envirnoments. IEEE Transactions on Software Engineering, 17{3, pages 283{295, 1991. [10] P. H. Loy. A comparision of OO and structured development methods. ACM SIGSOFT Software Engineering Notes, 15:44{48, January 1990. [11] K. Boulding. The Image, Ann Arbour. University of Michigan Press, 1956. [12] M. G. Walker. Managing Software Reliability, The paradigmatic approach. North-Holland Series in Systems and Software. [13] J. Rumbaugh. Object-Oriented modelling and design. Prentice-Hall, Englewood Cli s, NJ, 1991. [14] G. Booch. Object oriented development. IEEE Transactions on Software Engineering, vol. 12, February 1986. [15] G. Booch. Software Engineering with Ada. Benjamin Cummings. [16] F. V. Assche, P. Layzell, and M. Anderson. A rulebased approach to the development of information systems. In proceedings of the rst European Conference on Information Technology for Organizational Systems - EURINFO, 1988. [17] G. Cutts. Strctured systems analysis and design methodology. In proceedings of the rst European Conference on Information Technology for Organizational Systems - EURINFO, 1988. [18] G. E. Krasner and S. T. Pope. A cookbook for using the model-view-controller, user interface paradigm in smalltalk-80. Journal of Object-Oriented Programming, pages 26{49, August/September 1988. [19] M. Chan and B. Henderson. Corporate OO development environment (ODE). ACM SIGSOFT Software Engineering Notes, 15, January 1990. [20] H. D. Rombach and V. R. Basili. Quantitative assessment of maintenance. In Conference on Software Maintenance, pages 21{24, Austin, Texas, September 1987.
Items knows of
Find Item
Shop
Figure 7: Example of an inventory system using PATHOS approach The important di erence between the two techniques lies in the level at which the relations can be modelled. In PATHOS approach the relations lies at a higher level of abstraction and thus they can be made closer to the life which is much comprehensible.
7 Conclusions
This work has underlined the need to enhance OO approach to support reusability and software quality. Thus several changes are required the development of organizations [20] which are as following: 1. The designer should consider reusability as part of design reviews instead of designing for a speci c application. 2. Applications of similar classes should be examined keeping the technical control in mind so that they can be generalized into reusable classes. 3. All components that are required in a reuse library should be validated and supported by controlling features of the organization. 4. The software development process and management techniques should be modi ed to give greater emphasis to reusability and to o er incentives to it.
References
[1] P. Coad and E. Yourdon. Object-Oriented Analysis. Yourdon Press computing series, 2nd edition, 1991. [2] P. Coad. Why use object-oriented development. Journal of Object-Oriented Programming, pages 60{61, October 1991. [3] A. I. Wasseman. Software development: Issues in reuse. Journal of Object-Oriented Programming, pages 55{55, May 1991. [4] Rakesh Agarwal, Giorgio Bruno, and Vibha Mittal. An expert object-oriented geographical information system. In Fourth International Computing Congress, pages 199{206, Hyderabad, India, December 15{18, 1993. [5] Rakesh Agarwal, Vibha Mittal, and Marco Pescarmona. A technique for integration of computer systems in management support. In Second European congress on systems science, pages 1468{1472, Prague, October 5{8, 1993. 6
