OOAD (Object oriented analysis & design)
Scope:
As most of you already know, OOA (Object-oriented analysis) and OOD (Object-oriented design) are put together and called as OOAD. To keep the discussion short I won’t be writing anything on the history of OOAD. Instead, let’s try to understand what we do under OOAD.
Overview:
We have a requirements spec with us and we have to make progress towards developing the real system. We need to break this thing in to 2 steps:
1. OOA: To make sure we understand the system precisely, we need to think deep in each activity (use case), find out real-world objects/entities which are a part of that activity and model their interaction. More precisely, we find out objects which are part of the activity and how they interact with each other to meet their purpose. Object here does not mean java or c++ object. Instead, it means various parties that are playing part, for e.g. Account, Customer, Bank, Manager etc.
2. OOD: Once we have analysis model from step 1, we now need to go even deeper to decide java/c++ classes, attributes, methods and interaction among all these. We take the analysis model ahead, we start with that model.
More Detail:
Not very interesting so far, right? Not for me either. Let’s go through an example. Suppose we have to develop a system for students and courses. We need to register students for courses online. Requirements in use case format may have following use cases with titles:
a) Add Course.
b) Add Student under Course (I am assuming student cannot exist without a course, so this is together) – we will go through this use case below.
In OOA, we find what parties/objects are there, and we get following :
Student
Course
Admin (who adds course and students)
These are called domain objects (we create class diagrams for them for use later).
How does the process work for Add Student Under Course use case, we need to analyze that.
We know Admin will start the process, but he needs an online form to fill (UI), so we need Form object. Form is just a form. When it is filled and submitted, it will send all its information to another object. What is that object? We call it Controller (so we add another object to the list). Controller will get raw data (in the form of key=value pairs), it needs to make a Student/Course object from that raw data. Who should make those objects? We need another object for that which will provide this common service for the whole system. We call it ObjectManager (some people call it lifecycle object). After Controller has Student/Course objects it needs to give them to another Object which will persist them in the system. So we need ObjectPersistors.
This is how we find objects and once we have them, we create sequence diagrams to see how to interact with each other (I am not providing sequence diagrams):
Admin -> Form -> Controller ->
Controller -> ObjectManager (returns objects to controller)
Controller -> ObjectPersistor (persists)
Controller (send success/failure message) -> Form
Above is a very short example giving an idea what we do in the analysis. We have not covered error scenarios here, but we do cover those during analysis in real.
In OOD (step 2), we take the analysis model (class diagrams and sequence diagrams) and decide the actual java/c++/any- other-oo- language classes (that’s why everybody says, in design we decide HOW to do it). We decide the actual method names, parameters their types etc. For e.g., in above case we may decide to have a Controller.java, ObjectFactory. java and ObjectDAO.java classes.
I hope you get an idea here of what OOAD is about.