OBJECT-ORIENTED ANALYSIS
KEY CONCEPTS, BENEFITS AND CRITICISMS
Terri Thomason
942720
MIS 488 Systems Analysis
Prof.
Vicki Sauter
November 29, 1999
The term "object-oriented" is not new in the area of systems development, having its origins in the 1960s with the Simula programming language. It was then that the concepts of objects and classes were introduced, and the Simula developers had the same concern today's developers have -- how to describe complex systems in simple terms [14 ]. While this language was used in different applications, object-oriented programming did not begin to gain popularity until the 1980s. With this popularity came a need for the entire development cycle to be object-oriented and it began to be applied to the analysis process. Following are definitions of key concepts, an explanation of object-oriented analysis and how it differs from the traditional analysis process, and benefits as well as criticisms of the object-oriented analysis process.
Key Concepts
Integral to the understanding of object-oriented analysis is the concept of an object. Grady Booch, one of the leading proponents of this type of analysis, defines an object as "something you can do things to." [1, p.516] There are examples of objects in everyday life, from a book to an automobile to a bird to a cat. Objects have state or condition in which the object can exist, behavior or how an object acts or reacts, and identity or what distinguishes it from all other objects. [19] State is defined by variables and behaviors are defined by methods. Defining an object as it relates to software means that an object is a software bundle of variables and related methods. [23] Making it even simpler, an object has characteristics through its state, knows how to perform actions and is responsible for its own actions through its methods. [6] Finally, object have the ability of hiding information from other objects and this is called encapsulation.[19, 22, 17] If one objects interacts with another (this interaction is conducted through messages), it is only important for the first object to interact with the methods or state variables it needs. For example, it is not important for an automobile purchaser to know the inventory cost of an automobile but it is important for the purchaser to know the purchase price. Encapsulation allows you to hide the inventory cost but allows access to the purchase price.
Objects are grouped into classes, another important concept in the understanding object-oriented development. A class can be defined as a blueprint or prototype that defines the variables and methods common to all objects of a certain kind. [22] Classes simply group objects that share characteristics together. Additional objects or instances can be created from this upper level or parent class. These instances inherit the common characteristics of the class and also have the new characteristics of the instance. For example, a motor vehicle class can be defined having the state or characteristics of four wheels, color, doors and having the behaviors or methods of moving, breaking, shifting gears. A new object or instance of motor vehicle called truck can be introduced that inherits all the characteristics of the motor vehicle class but to which the state of truck bed and behavior of hauling can be added. [17]
The concepts of abstraction, hierarchy, persistence and polymorphism are also important to the understanding of object-oriented analysis. Abstraction encourages an analyst to think of objects in the most abstract form first to isolate common characteristics. Through additional iterations of the abstraction process, the analyst is able to establish the unique characteristics of an object that distinguishes it from all other objects. Hierarchy refers to the ordering or ranking of abstractions. Through this rank ordering, class structure starts with the highest level or superclass and subclasses follow thereafter in order. Polymorphism refers to the ability of objects to respond differently when receiving the same message. This allows the analyst to create a superclass of objects that share common features but allow the lower level object to respond differently because of the unique characteristics of the specific object (see example 1). Finally, persistence refers to the permanent nature of an object. An object will continue to exist over time and after it is needed by a particular system. [1, 19, 24, 12, 17]
Why are these concepts important? The concepts promote an understanding of object-oriented analysis as well as establishes an understanding of what benefits could be achieved through the use of this approach. To summarize:
Object-oriented Analysis and Traditional Methods: Explanation and Comparison
Object-oriented analysis examines system requirements from the perspective of classes and objects found in the specified domain. [1] It focuses on what the system is supposed to do rather than how it will be done and looks at the behavior of the system independent of its domain. [16 p. 493, 13 p. 435] Object-oriented analysis looks at the real-world environment in which a system will operate, with this environment consisting of people and things interacting to create some result. [18] The people and things are first analyzed in the most abstract form and these abstractions become the class. The abstraction is analyzed and reanalyzed in multiple iterations until all objects are uniquely identified. Object characteristics and their behaviors are then analyzed to establish the various states an object can have and to define the methods the object will use to create action. This analyzation effort will identify the objects that will need to be created and supported as well as the methods and the messages used by the objects to cause actions. This can then used to develop the programming for the system. [15, 11]
A simple analysis of a restaurant can be performed to provide an example of the object-oriented analysis process. What is supposed to happen in the restaurant system is a diner is served food. Using serving the diner food as a focal point and the restaurant as the specified domain for the system, the analyst begins the abstraction process to determine the initial class objects and may define these objects as diner, hostess, server and chef. The interactions between these objects are next analyzed to determine the behaviors of the objects in order to define the methods and messages as well as the different states or values for the characteristics the objects may have. An initial list of these behaviors with associated methods and state variables is:
Bear in mind, this is the highest level analysis or abstraction and the abstraction process will continue until all object are uniquely identified. For example, another abstraction may identify the need to define a table with the state of availability so the hostess can determine the appropriate table location to seat the diner. (See example 2 for additional examples as well as tracing this example to the key concepts defined above.) Once the entire analysis is complete, you have the components necessary to develop the system.
How does this differ from traditional analysis methods? In the traditional method, the focus is on business processes and the data needed to support the process. For example, in analyzing the diner's request for a table the analyst would detail the process beginning with the diner walking up to the hostess, requesting a table, telling the hostess how many is in the party, providing information on the smoking preference, etc. Data stores would be created to detail information on the number in the party and smoking preference to pass as inputs to the next process of seating the diner which results in the output of a table. Traditional methods describe the system in terms of inputs, outputs and data flows -- starting with a structured analysis and developing procedural programs. [16, 5] Object-oriented analysis shifts the focus to an effort to combine processes and data into objects to deemphasize the focus on procedures. The object knows how to accomplish a task or behavior; therefore, it is not important to the analysis effort to focus on the processes associated with the behavior, shifting the focus from how to what a system is supposed to do. Object-oriented analysis models the concepts of behavioral and interaction within a system rather than the processes and procedures. [6, 16 p.493, 13 p.435, 18]
Benefits of Object-Oriented Analysis
Object-oriented development is not a new technology but it has not had widespread use and is still maturing. Object-oriented analysis starts you on a path that can lead to benefits not only in the analysis process but in subsequent development phases. Proponents of the object-oriented approach list the benefits as an easier way to promote the understanding of a system, reusability of models and programming, modifiability and reduced costs associated with change, and reduced development risk. These benefits lead to a superior method of analyzing business processes and requirements. Finally, because the contemporary view of development is from the object-oriented perspective, object-oriented analysis allows you to take advantage of the contemporary programming languages, operating systems and associated tools. [1 p.215, 16 p.493, 12, 2 p.11]
Objects are said to replicate what humans see in real life and, therefore, appeals to human cognition. The object-oriented paradigm views the world as composed of objects with well-defined properties, with objects replicating things in an environment. [19] It is easier to promote a user's understanding when the user is presented with objects describing things found in the normal course of conducting business. For example, it is much easier for accountants to view a system when entities such as customers, checks, invoices and receipts are used. The user can, therefore, better visualize the concepts of the system and assist the analyst in describing the system by focusing on what is to be accomplished rather than focusing on procedures. [12, 16 p.493]
Reusability is a desired goal of all development and is based on the reluctance of reinventing something when it has already been invented. Object-oriented development supports this, especially in the concept of abstraction. [3] Abstraction supports continual iterations of analysis until unique objects are found in a class hierarchy. These unique objects inherit characteristics from the higher level classes and this allows you to reuse information from the previously defined classes, eliminating the need to reinvent it. Class structure leads to the development of class libraries that allow the sharing of models and programming throughout a system. The development process can be simplified, from analysis to requirements to implementation, through the use of the building blocks of classes and objects. [12, 18, 3]
The use of objects makes it easier to change and modify systems. For example, the year 2000 (Y2K) problem may have been eliminated by identifying a date object within a system and accessing this object when you needed to date an operation. If the date object had the state variables of month, day and year with each defined as two-character variables, the only change that would be necessary to correct the Y2K problem was to change the year state variable of only the date object. No need to examine multiply lines of code or to use significant resources to locate all the processes using a date functionality and the appearance of it in a procedural program. Modification of systems can also be accomplished through adding methods or state variables to objects. Because encapsulation isolates unnecessary methods and messages from other objects, you can add this type of information to an object to allow it to interact with another object. Theoretically, you are changing the system without having an effect on the existing object interactions. [12, 3]
The risks associated with the development process are reduced by providing a methodology that promotes understanding of a system, making information easy to use and reuse throughout a system, and developing a system that is easier to modify and change making the maintenance process easier. It helps to reduce the complexity of the analysis and development process.
Criticisms of Object-Oriented Analysis
While the proponents of object-oriented analysis detail the benefits discussed above, critics have maintained that it is not the solution to all problems. Criticisms of object-orientation include lack of standardization, the costly nature of adopting this paradigm, problems associated with the concept of reusability, and the applicability of adopting it for legacy systems.
Most objected-oriented methods appeal to intuition rather than formal definitions but they are still useful. [7] This, however, leads to one of the traditional criticisms of object-oriented analysis -- the lack of standardization. [16] This criticism may be somewhat abated through the adoption of the Unified Modeling Language (UML) by the Object Management Group (OMG) in November 1997. [10] UML was developed by three of the leading proponents of object-oriented development, Grady Booch, James Rumbaugh and Ivar Jacobson, and provides a language for modelling systems. [7] The OMG is an organization whose mission is to introduce standardization to object software [20]; therefore, this adoption represented standardization in the analysis process.
Changing from a traditional development model to an object-oriented approach is costly and should not be dismissed lightly. This change requires the infamous paradigm shift, meaning you have to completely change your way of thinking and change your business processes as well as invest in training in order to ensure the staff is ready to accommodate the changes. This requires an investment in not only money but time. [1 p. 216, 16 p.494] It also must be kept in mind that software developers who have used traditional methods for a long period of time tend to think in terms of process and, therefore, may find it difficult to change. [9] The investment, however, may return dividends in the long run. A study comparing the data flow diagram method to the object-oriented analysis method showed that there was a longer learning curve associated with object-oriented analysis but, once learned, the object-oriented analysts performed better than the data flow diagram subjects in analyzing a system. [21]
Critics of object oriented development contend reusability is very difficult to employ in both new development and the continual development of systems. When developing new systems, several developers may be working on a project studying class libraries to find the common objects, or the objects themselves may be in development and not available for use, making it difficult to share the components throughout the new system. [4] In using classes and objects in future development efforts, you cannot assume classes are automatically reusable. Instead, inheritance is dependent on a set of rules. It is important to remember, however, that no method eliminates all problems associated with reusability and no method can entirely eliminate all concerns. [10]
Finally, there is some question as the appropriateness of applying object-oriented techniques to legacy software. Object-oriented methodology starts with the object and this object drives the definition of further needs. With legacy system, the data and its associated model already exists. You also have analysts steeped in traditional methodology more comfortable building the data model first. [8] The good news is that once an analyst uses an object-oriented approach he is resistant to going back to traditional methods. [15, 8]
Conclusion
Should businesses adopt object-oriented analysis? There is no clear-cut answer to this because it is dependent upon business needs, and the willingness of the business to make the investment necessary to adopt this methodology. In order to adopt this methodology, the business should invest in training for all individuals involved in the analysis process and slowly integrate the process by using it in low-risk projects first to allow the analysts to learn from their mistakes. Successful adoption of this methodology lies in commitment, training, and experience. [1, 8]
References