Application development with Object Oriented approach:
Basic Steps.

Instructor Jeff Zhuk

Taking the Object Oriented approach it's important to define the very basic steps for application analysis, design and development.

First Three Steps On The Way can be illustrated by the "Payroll" Project

1. Capture User Requirements into a set of Use Cases

2. Recognize Classes

3. Form Object Model Diagram defining relationship of the Classes

4. Draw line for presentation(client), server and database management layers

5. Recognize reusable services and shared data

6. Define the screens and user interface with Human-Computer Interface experts

7. Define the date and scope of first deliverable targeting to prove the basic concepts and to get feedback from the client on the very early stages of the development

8. Use Style Guidance while coding and review the code regularly (it also keeps proper communication level for a team)

9. Share first results with domain experts. Make corrections and outline the plan to finish the project and to tune the performance.

Back To School





1. Capture User Requirements


Interview domain experts to understand Business Rules and User Requirements.


Yvar Jacobson methodology can be used to capture User Requirements into a set of "Use Cases".


Each Use Case describes a scenario, a flow of events initiated by an "Actor".


An Actor represents anything that interacts with the system. Written description is complimented by Process Diagram.


This is a proven smooth way to come to an agreement with the customer and the users on what the system should do.





 Back To Basic Steps


2. Recognize Classes

Look for repeatable (means reusable in your application) objects complicated enough to deserve to be a new data type. Look also for repeatable behavior of the objects. If such objects can be grouped, such a group or set of objects can be considered as a possible class. A class is a new abstraction while an object is an instance of a class.

Objects that can be described as a simple character string or integer don't deserve to be classes. They are known data types.

There are many ways to identify classes. It is not science but art.

Classes/Responsibilities/Collaborators or CRC [Beck89] approach can be used to select classes. Any noun from user interview or written business requirements can be considered as a potential candidate for a class.

CRC cards

It's important to design classes looking at your application by the client's eyes.

Forget about implementation details at this time. Ask basic questions:


An example of class hierarchy for a PAYROLL system.

Employee is a base class.
All other classes are derived (inherited] from the Employee.
For example, Sales Person inherited from Hourly with all the Employee features


 Back To Basic Steps



3. Form Object Model Diagram defining relationship of the Classes

"The world is a process that never stops" (Heraclitus, Dynamic view of the world)
"The world is a composition of objects called atoms" (Democritus, OO philosopher)

Booch-Rumbaugh notations can be used