OOAD
Object-oriented analysis (OOA), design (OOD), and programming (OOP) are related but distinct. OOA is concerned with developing an object model of the application domain.
So, for example, you take the problem statement, generate a set of features and (possibly) use cases,[2] tease out the objects and some of the methods within those objects
that you’ll need to satisfy the use case, and you put together an architecture of how the solution will hang together. That’s object-oriented analysis.
OOD is concerned with developing an object-oriented system model to satisfy requirements. You take the objects generated from your OOA, figure out whether to use inheritance,
aggregation, composition, abstract classes, interfaces, and so on, in order to create a coherent and efficient model, draw the class diagrams, flesh out the details of what
each attribute is and what each method does, and describe the interfaces. That’s the design.
Some people like object-oriented analysis, design, and programming[3] and some people don’t.[4]
OOA allows you to take a problem model and re-cast it in terms of objects and classes, and OOD allows you to take your analyzed requirements and connect the dots between
the objects you’ve proposed and fill in the details with respect to object attributes and methods. But how do you really do all this?
Well, here is a proposed process from that starts to fill in some of the details.[5] We’ll figure out the rest as we go along:
Write (or receive) the problem statement: Use this to generate an initial set of features.
Create the feature list: The feature list is the set of program features that you derive from the problem statement; it contains your initial set of requirements. The feature
list may be a set of user stories. To help generate the feature list, you can put together a set of scenarios, narrative descriptions of how the user will walk through using
the program to accomplish a task. A scenario should be technology agnostic and should be explicitly from the user’s perspective. It’s not how the program works; it’s about
what the user wants to accomplish and how the user gets the task done. It can also talk about what the user knows. User stories are very brief and high level. Scenarios are
longer and provide more detail. A user story might generate several scenarios.
Write up use cases[6]: This helps refine the features, dig out new requirements, and expose problems with the features you just created. Use cases are more specific descriptions
of how a user accomplishes a task using the program; they describe how the user interacts with the system. Use cases “. . . capture the goal of an action, the trigger event
that starts a process, and then describe each step of the process including inputs, outputs, errors and exceptions. Use cases are often written in the form of an actor or user
performing an action followed by the expected system response and alternative outcomes.[7]” Each scenario or user story might create several use cases.
Break the problem into subsystems or modules or whatever you want to call them as long as they’re smaller, self-contained bits usually related to functionality.
Map your features, subsystems, and use cases to domain objects; create abstractions.
Identify the program’s objects, methods, and algorithms.
Implement this iteration.
Test the iteration.
If you’ve not finished the feature list and you still have time and/or money left, go back to step 4 and do another iteration, otherwise . . .
Do final acceptance testing and release.
Note that this process leaves out a lot of details, like the length of an iteration. How many features end up in an iteration? How and when do we add new features to the
feature list? How exactly do we identify objects and operations? How do we abstract objects into classes? Where do we fix bugs that are found in testing? Do we do reviews of
code and other project work products?
Leaving out steps here is okay. We’re mostly concerned with the analysis and design elements of the process. We’ll discuss ideas on the rest of the process in this chapter,
and some of the answers are also in Chapter 3 on project management.
How do the preceding process steps fit into the software development life cycle? Well, I’m glad you asked. Recall that the basic development life cycle has four steps:
Requirements gathering and analysis
Design
Implementation and testing
Release, maintenance, and evolution
We can easily assign the previous ten steps into four buckets, as follows:
Requirements Gathering and Analysis
Problem statement
Feature list creation
Use case generation
Design
Break up the problem.
Map features and use cases to domain objects.
Identify objects, methods, and algorithms.
Implementation and Testing
Implement this iteration.
Test the iteration.
If you’ve not finished with the feature list or out of time, go back to step 4, otherwise . . .
Release/Maintenance/Evolution
Do final acceptance testing and release.
Once again we can ignore the details of each process step for now. These details really depend on the process methodology you choose for your development project.
The description of the process just given uses an iterative methodology and can easily be fitted into an agile process or a more traditional staged release process.
📌 A use case is a simply a story about how your system works.