Object Oriented Software Engineering approach to Develop Reusable System Components and Code

Walker H. Land Jr.,
Michael B. Kachmarik (MIS director at EJ F&S, IBM Alumni),
Feiqiao Wang
Zhen Tian
Junsheng Zhang

Binghamton University
Watson School of Engineering and Applied Science
CS Department
PO BOX 6000
Binghamton, New York 13902
Tel: (607) 777-4880
Fax: (607) 777-4822
Email: WLAND@Bingvmb.cc.Binghamton.edu


System development is a complex task and not well handled by the classical function decomposition approach. We apply the Object-Oriented Software Engineering (OOSE) approach of Jacobson to address this problem. While this methodology is one of the best object-oriented (OO) system modeling techniques, our experience has demonstrated that improvements or refinements are required in specific areas. These are: (1) explicit approaches are required to ensure that the requirement specifications are reflected in the use cases as early and as accurately as possible, and (2) universal OOSE metrics to measure OO code in addition to metrics to measure the quality of the analysis and design need to be better defined and developed. This position paper attempts to formulate these arguments in addition to covering additional aspects of OOSE formulation.

Keywords: Object-Oriented System Development, Analysis, Design and Coding metrics, Reuse, Problem Domain, Domain Engineering.

Workshop Goals: To participate and exchange ideas related to OOSE, domain engineering and code reuse. This exchange of techniques and success stories is evidence of increased OOSE and design code reuse.

Work Groups: Domain Engineering helps manage Change & other workshops.

1. Background

We have found system development is a complex task, and system designers do not "cope" very well with handling many requirements simultaneously. What is needed is a proven methodology to handle system complexity in an organized, incremental and managed way.

Historically, the typical approach is functional decomposition and this is not the answer for several reasons:

* Functional decomposition results in the artificial separation of functions and the data which they process, and in constraining the designer to "think" like the computer that organizes and processes the executable map file.

* It usually requires system software designers to redesign the system and cannot use much if any of the existing software.

The object oriented approach addresses these questions in that: (1) data and functions are encapsulated, which eliminates a significant part of the function decomposition ("overhead" code is used simply for data manipulation), (2) operational code may be reused by employing the concepts of inheritance and/or polymorphism and (3) by using the object oriented approach, the designer is not artificially constrained to "think" how the computer operates.

Several useful object oriented system design methods have been proposed and Jacobson [1] and Rumbaugh [2] are among the best. However, experience using Jacobson's use case approach has shown that Object Oriented Systems Design (OOSE) methodology (and other OO techniques as well) are missing both the tools and guidance in the early and critical systems development process. Furthermore, additional research and development work is needed in OOSE test in addition to development of object-oriented software metrics.

2. Position

The use case concept of Jacobson is one of the fundamental building blocks of object-oriented systems modeling. Leading methodologies are converging on some key concepts, and one of them is the use case [3]. For example, Booch [4], Wirfs-Brock [5], and Rumbaugh [6] are incorporating the use case concept in their approaches. (See comparison section for details). Furthermore, Rumbaugh [7] and Booch [4] have been recently working with Jacobson to incorporate their separate methods into a single Unified Model which not only contains a single set of modeling concepts but also a common notation. However, Jacobson's approach [1] is based on the concept of the use case which represents the end user/buyers view. This, in turn, implies that by using the use case concept, the system designer not only must interact with and understand the application requirements but also must focus on the (ease of) "usability" of the system. Why?; Because the system is architected using a series of models which are critically dependent on the information content in the use cases. That is, from these use cases are developed the analysis objects. By using these analysis objects, the designer may configure the system/subsystem structure and also formulate the interaction among the components of functionality. These objects and their interactions may then be used to: (1) develop encapsulated C++ classes, (2) implement inheritance and develop structure charts (using isomorphism) by using the design and implementation models. This mapping means that the dynamic behavior (as described in the use case) must be captured in the interaction diagrams of the design model, and these interaction diagrams along with the design blocks, comprising the design model, may be turned into the above mentioned C++ classes which constitute the implementation model, which we implement with C++. The above "rabbit trail" clearly shows that the use cases must capture the system functional requirements as early and as accurately as possible from the user/buyers perspective. This requires: (1) the existence of a system concept, (2) a clear understanding of what the system is to do, and (3) how the users are to interact with the system. However, very little if any mention is made about the following points: (1) how was the system concept created?, (2) how do we ensure that the requirement specifications are accurately and completely reflected in the use cases as early as possible?, (3)which parts of the organization will the system serve?, (4) what is the allocation of work to human or computer, and why?, and finally (5) how does the designer structure the use cases to ensure that they are complete, robust, and seamlessly flow into the object-oriented system code? Scalzo [8] recognized that some of these problems existed in automating portions of existing systems, and some of her ideas might be appropriate in the solution of this problem.

Another possible approach is the Joint Application Development [JAD] workshop and is discussed in [9]. The JAD workshop participants are a group of project analysts, designers and domain experts. The OO methodology used in the JAD workshop has been extended during the last few years to cover use case front-end and to divide the analysis into Macro and Micro analysis, where the Macro analysis concerns building a domain object model and an application model based on use cases. The Micro analysis concerns the traditional OMT object, dynamic and functional models [9]. In addition, their experience has shown that the usual way of writing use cases "is not feasible" if the system requirement is to both support other external systems as well as an operator at the same time. They therefore isolated the graphical user interface (GUI) in such a way so that it operates on the same system interface as do the other external systems. Consequently, the operator becomes an indirect actor relative to their network management system, and a direct actor with respect to the GUI. The last point in their requirements analysis was to ensure that the original requirements from the concept phase were both updated and related to the use cases developed for the system.

Consequently, position 1 is: "We need to formulate an explicit approach to ensure, as early and accurately as possible, that the requirement specifications are reflected in the system use case descriptions. That is: we need a methodology to obtain a complete and unambiguous set of system design requirements before getting "too far" into the system design process. Our current methodology to address this problem is to begin with an approach containing components of [8] and [9], and then modify and upgrade for our class of problems.

Specifically, we need methods to ensure that:

* the relevant concepts and data are "engineered" into the design early and hence into the use cases,

* use cases are logically described rather than containing precise system performance steps,

* the most appropriate actions within the use case descriptions are chosen for automation processes,

* the system functionality is accurately modeled in the correct use case,

* the correct "granularity" of use cases is defined for a given application.

Consider testing: Testing of Object-Oriented (OO) system design is generally more complex than testing a functional decomposition developed system. Why? Because the results of properly designed reusable OO code are encapsulated classes which affects the behavior of these classes. There also exists the additional properties of inheritance and polymorphism which can further complicate the process. Jacobson [1] suggests that the designer should conduct tests based on the encapsulated state of the object and the interaction of its operations. Turner and Robson [10] call this state-based testing. Jacobson suggests that "unit" testing comprise specification, state-based, and structural testing. Specification testing verifies the "unit" input/output data. State-Based testing checks the class interactions/operations using monitoring of the changes of the object attributes which belong to the class. Structural testing validates the "paths" contained within the "unit", and is a difficult task because of the number of possible paths which could exist.

Jacobson also recommends integration and system testing [1]. Integration testing verifies that the different "units" are properly working together, and consists of testing blocks, service packages, use cases, subsystems and the entire system. System testing comprises testing the complete system under specific circumstances such as: (1) operation tests, (2) tests based on specific requirement specifications, (3) tests of user documentation, etc. We propose to use, modify and upgrade Jacobson's testing phase proposals, modified for our class of problems.

Next consider software metrics: Metrics, simply stated, measure the effectiveness of the testing process and where we are within that process. Two types of metrics are generally used: (1) process-related, and (2) product-related [1]. In OOSE examples of process-related metrics are: (1) total development time (transferable to man-months and/or dollars), (2) modification time of previous processes to correct faults found during testing, (3) average time to develop a use case, (4) estimates for future enhancements planned with respect to agreed work, etc. Examples of product related-metrics which may be appropriate to OOSE are: (1) total number of classes, (2) number of classes reused vs. number newly developed, (3) number, width, and height of structure charts, etc.

Consequently, position 2 is: Universal OOSE metrics for OO code are not well defined. Furthermore, universal metrics to measure the quality of the OOSE analysis and design have been proposed but not evaluated. This , we believe, is an important current topic for discussion and development.

The last point to mention is that our current approach uses isomorphism in the implementation phase in that we require as the "base line" one design block be mapped into one C++ class. Using this approach, we find that we can move easily from the design to the implementation models (This requirement does not mean that our base line approach cannot accommodate polymorphism.) The information contained in [11] depicts how one may successfully apply this isomorphic approach.

3. Comparison

We begin by discussing some other approaches associated with use Jacobson's use case methodology. Rumbaugh [2] suggests an approach of how the use case methodology can be introduced in his Object Modeling Technique (OMT). There, Rumbaugh emphasizes domain classes of OMT as being "equal to" the use case models of Jacobson when building the analysis model. However, use cases are more important than domain classes, according to Jacobson [3]. Rumbaugh also introduces a new association (adds) between use cases. This new association behaves similar to an instance aggregation. Jacobson, however, chooses not to introduce instance associations between use cases because he does not want to promote functional decomposition [3].

Booch's scenario concept [4] corresponds to a use case instance [3]. That is, a use case (in the use case model) is a class from which one may imagine essentially an infinite set of use case instances. An analogy might be the creation of essentially an infinite set of instances from a C++ class. However, the reader should note that Booch introduces this scenario concept informally, and then uses the interaction diagrams to explain object interaction for the scenario [3].

In the responsibility driven design of Wirfs-Brock, use cases are introduced to support system requirements, object design, and user-interface design [5]. There, she suggests different levels of use case descriptions to provide an informal way of mapping different levels of use case abstractions. She also suggests what might be called a semiformal way to describe the interaction between actors and use cases. Jacobson [3] states that he has used similar techniques on some projects where interfaces between subsystems had to be "fixed" early, and this process worked well for him. Jacobson further describes this process as that of defining use cases at several levels. The highest level would be the business scenario which then gets refined into a more precise description of the actor's system inputs and associated system response descriptions. Consequently, the dialogue between the system and the actor is captured. Jacobson states he has used the interaction diagram for the same purpose [3].

Using the Wirfs-Brock method, the system designers incorporate these system responses to formulate an object model where these object models may be further refined to include more detail of the interaction in user terms. Therefore, the user/clients still remain in the review process. Furthermore, these user-response descriptions form the basis for further detailing the object model with object responsibilities. So, these more detailed system response descriptions may also be used for designing the proper user interface.

Object Behavior Analysis (OBA), as described by Rubin and Goldberg [12], is an extension of use cases where the emphasis is primarily in the Object Oriented Analysis (OOA) arena. However, OBA has no explicit support for use case modeling. With OBA, the designer first identifies scenarios which correspond to Jacobson's use case instances [3]. The scenario is described with a script, and a script also describes how different roles interact by message sending to "act out" the scenario. Here, each message contains an associated action which the receiver role may take. This process is very similar to Jacobson's robustness analysis. However, Jacobson would first explicitly define use cases and then follow with a robustness analysis [3]. That is, he would first identify the different paths a particular use case instance would follow, and then introduce the robustness analysis to identify what he calls ideal objects needed to perform the instantiation of each use case. Consequently, Jacobson's ideal analysis objects correspond to Rubin and Goldberg's OBA roles. How does Jacobson define this robust object structure? He uses entity, interface, and control objects of the analysis model. Then, after the ideal analysis, the use cases are described in terms of ideal interacting objects by use of interaction diagrams. Therefore, every interaction diagram is given an identity in the same way that OBA identifies a script. So, in the same way one expresses an action taken by an object instance upon receiving a message, one may associate actions in each operation path of an interaction diagram [3].

The UPROAR technique of Scalzo [8] addresses the requirement of obtaining user requirements and the analysis of collected information by the introduction of interview methods. These methods support the collection of information in the requirements phase of the design process. This approach, however, appears to be designed primarily for the purpose of identifying which components of an existing system may be usefully modified/automated. Some of the user interview template concepts may be useful in developing a methodology to accurately and explicitly reflect requirement specifications for use case descriptions for systems in the "concept" phase.

In chapter 16 of [1], Jacobson et. al. describe other object oriented modeling techniques and compare these techniques to his Object-Oriented Software Engineering (OOSE) approach. He describes the following metrologies in some detail: (1) OOA by Coad and Yourdon, (2) Object Oriented Design (OOD) by Booch, (3) Hierarchical Object-Oriented Design (HOOD) which was internally developed by the consortium comprising CISI Ingeniere, CRI A/S, and MetaSpace, (4) Object Modeling Technique (OMT) by Rumbaugh, and (5) Responsibility-Driven Design by Wirfs-Brock. The reader should consult [1] for details.

Finally, Rumbaugh [2], chapter 12, summarizes other software engineering approaches and compares them with his OMT. The reader should also consult that reference for details.


[1] I. Jacobson, M. Christerson, P. Jonsson, G. Overgaard, "Object Oriented Software Engineering, A Use Case Driven Approach", Addison-Wesley Publishing, 1994, ISBN 0-201-54435-0.

[2] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen, "Object Oriented Modeling and Design", Prentice Hall, Englewood, 1991, ISBN 0-13-629841-9.

[3] I. Jacobson and M. Christerson, "A Confused World of OOA and OOD", JOOP, Sept. 1995, pp. 15-20.

[4] G. Booch, "Scenarios, Report on Object Analysis and design", (3), pp. 3-6, 1994.

[5] R. Wirfs-Brock, "Designing Scenarios: Making the case for a use case framework", The Smalltalk Report (3),pp. 3, 1993.

[6] J. Rumbaugh, "Using use cases to Capture Requirements", Journal of Object-Oriented Programming (JOOP), (7), 5, 1994.

[7] J. Rumbaugh, "Notation Notes: Princ. for Choosing Notation", JOOP, May, 1996, pp. 11-14.

[8] Betsy Scalzo, "UPROAR- User Process Reveal Objects and Requirements", The Analytical Sciences Corp. Reston VA, 1995 OOPSLA Use Case Workshop, Austin, Texas.

[9] B. Loevnvig, "Experiences With Requirement Capturing, Specification and OO Requirements Analysis", OOPSLA95 Workshop on "Requirements Engineering: Use Cases and More", Austin, Texas.

[10] C.D. Turner and D.J. Robson, "The Testing of Object-Oriented Programs", Technical Report TR-13/92, Univ. of Durham, England.

[11] Michael B. Kachmarik, Feiqiao Wang, Zhen Tian, Junsheng Zhang, ACME Warehouse Management Inc. Case study of "ACME Warehouse Information Management System" (Binghamton University research paper) 1996.

[12] K. Rubin and A. Goldberg, "Object Behavior Analysis", Communications of the ACM, (35), 9, 1992, pp. 48-62.


Walker H. Land Jr. has over 30 years of industrial experience and 25 years of teaching experience. He retired from IBM in 1990, and since that time has been teaching in the Computer Science department at Binghamton University. While employed at IBM, his major activity was a systems analyst / engineer. He was responsible for research and development in the following areas: statistical and stochastic processing, Bayesian Inferencing, artificial intelligence and expert systems, coherent processing, neural networks, and guidance and location systems.

Since coming to Binghamton University he has been active in research and development of Object Oriented Reusable Software, architecting systems from requirement specifications through development of Object Oriented System Software using a series of models, dynamic neural networks, evolutionary programming, genetic algorithms, and genetic programming. He has been and is currently principle investigator on projects which exclusively use the object oriented paradigm for software development.