Introduction
Fundamental Basis of the OO Approach
Three Different Views of a System
Object-Oriented Analysis (Requirements Modeling)
Moving to Design
Introduction
The object-oriented (OO) approach views an information system as a collection of interacting objects that work together to accomplish tasks.
There are no process or programs; there are no data entities or files. The system consists of objects.
An object is a thing in the computer system that is capable of responding to messages. A classification or class represents a collection of similar objects. For example, a customer class consists of objects such as “John
Smith” or “Ricardo Ortega”. All objects share the same attributes such as
Last Name, First Name, Address, Date of Birth, Telephone Number and so on of an object class.
A data-entry form, a button or an input box on a form in a system are also object classes. Individual objects are created out of these object classes.
Similarly, a printer can be an object class and individual printers with varying properties can be objects. Thus object-oriented approach considers objects of the computer system as well as objects for which we capture data, that are required to accomplish tasks for an information system.
Object-oriented analysis defines all of the types of objects that do the work in the system and shows how the objects interact to complete tasks.
Object-oriented design defines all of the additional types of objects necessary to communicate with people and devices in the system and refines the definition of each type of object so it can be implemented with a specific language or environment.
Object-oriented programming consists of writing statements in a programming language to define what each type of object does.
1

The OO approach is promoted to have several benefits - among them naturalness and reuse are foremost. The approach is natural or intuitive, because people tend to think about the world in terms of tangible objects. It is less natural to think about complex procedures found in procedural programming languages.
Also, because the OO approach involves classes of objects such as customer or printer, and many systems in the organization use the same objects, these classes can be used over and over again whenever needed.
Many information systems developed today combine both traditional and
OO technology. Some integrated development environments (IDEs) also combine traditional OO technology in the same tool – for example, object– oriented programming is used for user-interface and procedural programming is used for the rest.
Fundamental Basis of the OO Approach
In the traditional approach to systems development, processes and data are considered separately. The models used to decompose a system are either process-centric (DFD) or data-centric (ERD). However, processes and data are so closely related that it is difficult to pick one or the other as the primary focus.
The OO methodology decomposes a problem by focusing on objects that contain both data and processes.
The object-oriented models for analyzing and designing a system have been developed by individuals over a time and there was no commonality.
In 1995, Rational Software brought together the leaders of the OO approaches (Grady Booch, Ivar Jacobson, and James Rumbaugh) to create a single approach termed as Unified Modeling Language or UML .
According to UML, the OO approach must be: (1) use-case driven, (2) architecture centric, and (3) iterative and incremental.
Use-Case Driven : This means that use cases are the primary modeling tool for defining the behavior of a system. A use case describes how the user interacts with a system to perform some activity; such as placing an
2

order, making a reservation, or searching for information. The use cases are used to identify and communicate the business requirements of the system to the programmers who develop the system.
Architecture Centric: This means that the underlying software architecture of the evolving system specification drives the specification, construction, and documentation of the system. The OO analysis and design approaches should support at least three separate but interrelated architectural view of a system: functional, static, and dynamic.
The functional view describes the external behavior of the system from the perspective of the user. The static view describes the structure of the system in terms of attributes, methods, classes, relationships, and messages . The dynamic view describes the internal behavior of the system in terms of messages passed between objects and state changes within an object.
Iterative and Incremental: This means that OO analysis and design using
UML emphasize iterative and incremental development that undergoes continuous testing and refinement throughout the life of a project. Each iteration of the system brings the system closer and closer to the real needs of the users.
UML does not dictate any formal approach to developing an information system, but its iterative nature is best suited to the phased development.
Figures below show the complexity of the SDLC phases and the iterative nature of the OO approach.
The same UML models or diagramming techniques are used throughout all phases of the SDLC; however, some diagrams are more emphasized in some phase than the others, and the diagrams gradually become more detailed as the analyst moves from the phases of inception to elaboration, and then from construction to transition.
3

The spiral model as an example iterative method
Phases and activities in the Unified Process lifecycle
The iterative, incremental waterfall
4

Three Different Views of a System
As it was mentioned, the OO analysis and design approach supports at least three separate but interrelated views of a system: functional, static, and dynamic.
The functional view describes the external behavior of the system from the perspective of the user. Use case and use-case diagrams are used to depict the functional view.
The static view describes the structure of the system in terms of attributes, methods, classes, relationships, and messages. CRC (class-responsibilitycollaboration) cards, class diagrams, and object diagrams are used to portray the static view of an evolving system.
The dynamic view describes the internal behavior of the system in terms of messages passed between objects and state changes within an object.
The dynamic view is represented by sequence diagrams, collaboration diagrams, and statechart diagrams.
These diagrams are developed in the analysis phase and refined in the design phase. Further diagrams are added as the system moves from analysis to design and from design to implementation. In the following, we only discuss some important diagrams used in the UML.
Object-Oriented Analysis (Requirements Modeling)
Five separate, but interrelated, object-oriented models or diagrams are used to understand the system requirements. They are:

the use-case diagram

class diagram,

the collaboration diagram,

the sequence diagram, and

the statechart diagram.
Below is an illustration showing how these diagrams are connected to each other. Each of these diagrams are discussed separately in different sections.
5

Integration of Four UML Diagrams
Moving to Design
Transition from analysis to design in OO methodology is not as simple as traditional method. First we add system-related information for various layers such as system architecture, user-interface, and data management.
Then we create packages for these layers. Package are developed by partitioning various diagrams discussed above such that the partitions shares some common business functionality.
6