I

Object Oriented Analysis and Design:

What is it? How Does it Work? Why is it used?

by Michael J. Quillin

November 25, 2001

I. What is Object Oriented Computing?

Most new client/server application development tools emphasize object-oriented features. The introduction of the object-oriented approach in the 1970s marked a radical change in the methodology and approach of large-scale application development. "The old paradigm, Algorithmic Decomposition, offered a top-down methodical approach. Large and small-scale applications relied heavily on testing and debugging to meet the required specifications" (2). Object Oriented Design (OOD) fundamentally changed the way software designers and specification writers approached the problem of efficiently designing applications (2i).

OOD allows large-scale applications to be developed in independent modules. Object-oriented decomposition provides a method to decompose a complex arrangement by the primary objects apparent in the system (4i). "Once the objects are defined and the system functionality is assigned, major components of the software system are developed independently. The parallel development and testing of individual modules requires strict adherence to the specification interface requirements" (2).

The following is an example of how Object Oriented computing is a different way of looking at the world (1i).

Suppose you're at the dinner table, you would like some salt, and the salt shaker is inconveniently located at the other end of the table. You might say to your friend, "Please pass me the salt," and she would do so.

On the other hand, instead of saying just "Please pass me the salt," you could try, "Please remove your right hand from your wine glass, move it to the left until it contacts the salt shaker, grasp it, lift it from the table, move it in a natural arc in my direction, stop when it contacts my hand, wait until my hand has closed around it, and then release it." This would probably word as well, though it might also result in a quiet phone call from your friend to the local mental asylum.

This example illustrates the difference between procedural and object-oriented computing. The object-oriented way is to say "Pass the salt," and leave it up to the object to carry out the request any way it chooses. The procedural way is to specify each and every step of getting that shaker of salt into your hands. There are two key concepts in object-oriented computing: encapsulation and inheritance. The single most important principle of object oriented computing is that "objects are responsible for their own actions" (1i). If used properly, OOD improves the maintenance, reusability, and modifiability of the software.

Encapsulation

An object is a "black box" which receives and sends messages. A black box contains code and data. "Traditionally, code and data have been kept apart." In Object Oriented Programming, code and data are merged into a single indivisible thing -- an object. "A primary rule of object-oriented programming is this: as the user of an object, you should never need to peek inside the box (or object)" (3i). All communication is to be done via messages. The object to which a message is sent is called the receiver of the message. Messages define the interface to the object. Everything an object can do is represented by its message interface. Therefore, an object can be used without knowing exactly what is inside of it, and it becomes unnecessary to directly modify the object. "Providing access to an object only through its messages, while keeping the details private is called encapsulation" (2i). Encapsulation is important because parts of software must sometimes be changed or re-used.

Classes

An object is defined via its class which determines everything about an object. Objects are individual instances of a class. "For example, you may create an object called Spot from class Dog. The Dog class defines what it is to be a Dog object, and all the "dog-related" messages a Dog object can act upon" (2i). All object-oriented languages have some means to create object instances from a class definition.

More than one object can be created for a class. Elaborating on the above example, objects named Fido and Rover might also be created in class Dog. In a class, messages are defined that objects in the class understand. Again, using the above example, the Dog objects might understand messages such as Bark, Fetch, and Roll-over.

The action that a message carries out is called a method. It is the code that gets executed when the message is sent to a particular object.

Arguments are supplied as part of a message. "For example, the "fetch" message might contain an argument that says what to fetch or the "roll-over" message could contain one argument to say how fast, and a second argument to say how many times" (2i).

Inheritance

If there is already a class which can respond to many different messages, it is possible to make a new, similar class which adds just a couple more messages without having to re-write the entire class by creating a subclass. This new class inherits all the existing messages, and therefore, all the behavior of the original class. The original class is called the superclass of the new class.

Inheritance also promotes reuse. It is not necessary to start from scratch when writing a new program if the existing classes have similar behaviors to those needed in the new program. "For example, after creating the class Dog, you might make a subclass called Wolf, which defines some wolf-specific messages, such as hunt. Or it might make more sense to define a common class called Canis, of which both Dog and Wolf are subclasses" (2i).

There are almost two dozen major object-oriented programming languages in use today, but there are only a few leading commercial languages. These languages are: C++, SmallTalk, and JAVA.

Top OOA vs. Traditional Methods Conclusion Bibliography

II. Tools and approaches involved in OO Analysis and OO Design

Object-oriented decomposition is the concept upon which OOA and OOD are based. There are three main tools used in object-oriented analysis and design techniques (8):

- Class diagrams/templates.
- Object diagrams.
- Object state diagrams.

Class diagrams are used to model key abstractions in the problem domain and their relationships with each other. Object diagrams are used to model the interactions between objects, whereas object state diagrams model the dynamic behavior within a single object. An object state diagram shows all the possible states of an object and the allowed transition between the states (8).

Tools are only the means by which developers communicate requirements or the design of the system. How they actually apply these tools for OOA and OOD is also important (7i). Unlike the traditional waterfall approach, the overall approach to object-oriented analysis and design is highly integrative. "Stepwise refinement works when all requirements must be determined before design can start, however, and object-oriented developer may be required to do some preliminary analysis, designing the class and object structure, building a preliminary prototype, testing it with the user, and going back to analysis or design without being constrained" (8). Object-oriented systems are designed to be changed.

In object-oriented analysis, there are four key steps to be performed (6i):

1. Identifying objects and classes.

2. Identifying the object relationships.

3. Identifying the attributes.

4. Identifying services.

The first step involves identifying candidate objects and classes, which may be people, places, things, organizations, concepts, or events. Next, Object relationships are documented on object diagrams. The attributes and services of each class are then identified and documented in class templates.

Similarly, in object-oriented design, there are four key steps to be performed (6i):

1. Defining object life cycles.

2. Defining class relationships.

3. Defining service logic.

4. Completing class definitions.

The first step involves analyzing life cycle of each object and formalizing the life cycle in an object state diagram. Next, class relationships are defined in a class diagram. Each service that is provided by a class is defined including any logic that is necessary. Finally, the class and object diagrams are completed along with all class templates (8).

Top What is OO Computing Tools and Approaches Used in OOA Conclusion Bibliography

III. Object-Oriented Analysis vs. Traditional Methods

Before the introduction of Object Oriented Analysis and Design, most Information Systems professionals were taught that the classical waterfall development life cycle was the proper way to approach software engineering and that "top level decomposition of processes was a practical way of handling large software development projects" (8). These traditional methods built the foundation of modern software practices, and yet this foundation is being shaken by object oriented analysis and design.

Structured systems development began in the 1960s with the concept of systems development life cycle. In the 1970s, process-oriented structured methodologies were developed to promote a more effective analysis and design technique (9i). "The so-called structured revolution was based on computer program structures, with separate program steps (processes) and data" (8).

In the 1980s, planning and modeling of data began to play a more important role in development, resulting in data-oriented methodologies such as information engineering. "Although the data-oriented methodologies made better use of the powerful database models that were evolving, when it came to design, data methodologies still relied on process decomposition and simply mapped processes to data" (8).

Organizations continue to use traditional methods of software development, but they are coming to realize that these methods have shortcomings that include the following:

- The traditional waterfall approach to software development dictates the completion of the analysis pahase before design and likewise the completion of all design steps before construction. This assumption has an inherent risk of carrying forward incorrect or incomplete analysis into design and construction (8).
- Process decomposition can lead to unstable designs because the design is based on processes that often change as a result of new requirements, error corrections, new environments, or enhancements. Processes must be disassembled, changed, then reassembled, frequently with uncertain outcomes (8).
- Traditional software development methodologies suggest developing software from scratch rather than reusing existing code -- which is not surprising because process decomposition results in the separation of processes from data, making transportation and reuse of code extremely difficult (8).
- Because process decomposition is oriented to solving a specific business problem, the resulting answer (design) is unique, making it difficult to reuse a generic application (8).

These shortcomings have prompted developers to examine different ways of thinking about approaches to systems development. Object-oriented systems development is in the forefront of this shift in thinking.

Top-down structured design approaches development as a simple matter of algorithmic decomposition, where each module in a system denotes a major step in some overall process. In contrast, object-oriented decomposition is based on objects and not algorithms. Object-oriented analysis strives to describe what the system should do in terms of key objects in the problem domain while object oriented design strives to describe how the system will work using these objects.

OOA differs the most from Structured analysis. "Structured analysis maintains a process-oriented view of systems, providing a decomposition based on processes, whereas OOA decomposes the problem domain base on classification entities" (8).

Information engineering is closer to OOA because it provides a variety of tools for modeling of entities (namely, entity-relationship diagramming). The differences between OOA and information engineering lie in OOA's requirement for encapsulated operations. "Information engineering violates this rule because operations may access numerous entities and are not subordinated to one entity" (8).

Developers who are currently using structured analysis techniques usually discover that their experience in modeling requirements using data flow diagrams is irrelevant or worthwhile only in the context of modeling existing procedures. Those developers schooled in information engineering will find the road to object-oriented analysis much easier to follow. However, developers still need to alter their views from modeling disembodied processes to encapsulated services (8).

Object Oriented design is completely contrary to both structured methodologies and information engineering. "Both structured design and information engineering use function-oriented decomposition rules, resulting in a structure of procedure-oriented program modules that contain programs, subroutines, and functions with only procedural code" (8). OOD, by contrast, decomposes using object-oriented rules, resulting in collections of services encapsulated within objects. Structured design and information engineering do not support this. Therefore, developers schooled in either structured design or information engineering need a completely different set of skills and tools (4i).

Top What is OO Computing Tools and Approaches Used in OOA OOA vs. Traditional Methods Conclusion Bibliography

IV. Conclusion

Using Object Oriented Analysis and Design methods to develop real-time systems has the potential to produce safer, more reliable and maintainable code (4). Instead of using functional decomposition of the system, the OOA approach focuses on identifying objects and their activities (10). Using the object -oriented approach, system analysts model inforamtion systems by identifying a set of objects, along with their attributes and operations that manipulate the object data (6). Researchers in the object-oriented community assert that the OOA approach has many advantages in meeting the requirements of OOP (9).

V. Related Websites

There are many websites containing further information about Object Oriented Analysis and Design. Here are a few that might be useful for further study:

Object Oriented Analysis and Design Methods: wwwis.cs.utwente.nl:8080/dmrg/OODOC/oodoc/oo.html

Techniques for OO Analysis and Design: www.aw.com/cseng/titles/0-201-89542-0/techniques

Object Oriented System Development: http://g.oswego.edu/dl/oosdw3/

DBMS Object Analysis and Design: www.dbmsmag.com/9606d15.html

Object Oriented Analysis and Design with Applications: http://cseng.aw.com/book/0,3828,0805353402,00.html

The Root System Homepage: http://root.cern.ch/

Object Oriented Analysis: www.sei.cmu.edu/str/descriptions/ooanalysis.html

The Object Oriented Page: www.well.com/user/ritchie/oo.html

Use Cases in Object Oriented Analysis: www.efd.lth.se/~d87man/EXJOBB/UseCases_in_OOA.html

The BON Analysis and Design Method: www.eiffel.com/products/bon.html

Bibliography:

1. Ambler, Scott, Take an Object-Oriented Approach to Analysis, Computing Canada, July 21, 2000.