A Model-Driven Approach to Analysis and Design
Steven Zeil
Abstract: This lecture addresses the overall strategic plan for moving from a vague understanding of what kind of software system we want to the design of the software components within it.
The focus will be on a series of models, each adding more detail to our understanding of the system structure.
1 Intro: Taking the Strategic View
A software development process is a structured series of activities that comprise the way in which an organization develops software projects.
You should already be familiar with the classic Waterfall model from the prerequisite course CS250 or 333.
Waterfall is hardly the only development process employed in software development, but the range of common process models is outside the scope of this course.
In this lecture, we are going to look at a broader strategy that can be fitted into a number of development processes and that supports the OOA&D paradigm.
1.1 General OO Analysis & Design
1.1.1 Analysis
Analysis is concerned with what the system should do. This is not so terribly different from the waterfall’s “Requirements Analysis”. But while traditional Requirements Analysis focuses on writing requirements to be fulfilled by the software system, OOA focuses on producing an understandable model of what that system should do.
In OOA we consider the process of analysis to be a model-building activity. The first model produced is a domain model, a model of the world (or, at least, the part of the world relevant to the anticipated system) as it is now, before we introduce our new system to it.
- A domain model may explain the behavior of existing software that we intend to replace, or it may describe purely manual actions carried out by the humans in the modeled world, or the behavior of machines and devices in that world, or a combination of all of these.
The next model to be developed, and the primary output of the analysis phase, is the analysis model. This is a model of how the world will interact with the software system that we envision. As such, it is our statement of just what the system will do when it is working.
- There’s a definite overlap in the purpose of a requirements document and an analysis model. Some people regard the analysis model as a kind of requirements specification, though in practice it is unlikely to be, in itself, in a form that customers or management would sign off on.
In OOA, both of these models will be expressed as a collection of related, interacting classes of objects.
If we believe the OO philosophy, we expect that the objects and interactions in the analysis model will be similar to those in the domain model. Our software structure should simulate the structure of the real world.
1.1.2 Design
Design is concerned with how we can get the system to do the things the analysis model says it should do.
Designs are expressed via a design model, which, like the earlier models, also is based upon the idea of related, interacting objects.
Again, if we believe in the OO philosophy, we would expect the objects and interactions in the design model to bear a close resemblance to those from the domain and analysis models. Hence we typically do not start building the design model from scratch so much as we evolve the analysis model into the design by adding detail, resolving conflicts, etc.
That doesn’t mean that there won’t be changes. The design model will typically need to
-
add details to existing classes that weren’t important in the more abstract view of the analysis mode but that are mportant to make the software actually work;
-
add new classes to represent underlying data structures that allow us to actually implement the desired behaviors of the simulated real-world classes;
-
resolve conflicts between the abstract view of how we would like things to work and the limitations of what we can actually accomplish via programming.
2 Building Models
OOA&D is largely viewed as a model-building activity. The primary models that we find are
-
domain model
-
analysis model
-
design model
and OOA&D emphasizes a smooth evolution from one to the other.
2.1 Domain Models
A domain model is a model of the application domain as it currently exists, before we began our new development project. The point of the domain model is to be sure the development team understands the world that the system will work in.
-
The domain model describes the world in terms of objects interacting with one another via messages.
-
We’ll see techniques for capturing this kind of idea shortly.
-
-
Not every project needs a domain model
If the team has done several projects already in this application domain, then they presumably already sahre a common understanding of the world in which the new software will reside.
(Fortunately, most companies work in a small number of application domains. If they hired you last month to develop software for analyzing seismic data for petroleum engineering, they are unlikely to ask you to develop a compiler or a word processor next month.)
Even if a document describing the domain model is desired, domain models tend to be highly reusable since the world around our software systems usually changes fairly slowly.
2.2 Analysis Models
An analysis model is a model of how the world will interact with the software system that we envision. As such, it is our statement of just what the system will do when it is working.
There is a real temptation to simply assume that the automated system will simply squat in the middle of the world, interacting with all the real world objects, sort of like this:
Or if you prefer,…
It’s Magic!
Poof! We have an analysis model!
Not wrong, per se, but it’s certainly not helpful.
Such an approach is fundamentally at odds with the OO philosophy
-
We should look to the real world to suggest how to decompose our system.
-
In this case, we have not decomposed it at all – just wrapped it up into a single black box.
- All the hard decisions still need to be made.
In essence we have not done any analysis at all here. This “model” isn’t wrong, per se, but it’s certainly not helpful. We’ve basically thrown away everything we’ve learned in the domain model about how objects really interact. We’re treating the new program as a simple box, with no knowledge of its internal structure, Essentially, we’ve just deferred all the hard questions to the upcoming design.
2.2.1 Evolving the Analysis Model
What we really hope for is an evolution from our domain model to our analysis model. The OO philosophy tells us that the classes and interactions of our domain model …
… should carry over into our analysis.
In essence, we hope to retain these classes, add more detail to our understanding of them, and to establish a boundary that tells us which of these classes and behaviors will be automated, which will remain entirely unautomated, and which will have some portion automated while other parts remain external.
The Boundary
… establish a boundary that tells us which of these classes and behaviors will
-
be automated
-
remain external
-
be a mixture of the two
The system, then, remains a collection of interacting objects rather than an unstructured black box.
There’s a definite overlap in the purpose of a requirements document and of an analysis model. Some will regard the analysis model as a kind of requirements specification. In some projects, though, a requirements document will still be required as something for customers or management to sign off on. But the analysis model is the basis from which the eventual requirements document is derived.
2.3 Design Models
Design is concerned with how we can get the system to do the things the analysis model says it should do.
Designs are expressed via a design model,
which, like the earlier models, also is based upon the idea of interacting objects. If we believe in the OO philosophy, we would expect the objects and messages in the design model to bear a close resemblance to those from the analysis model. Hence we typically do not start building the design model from scratch so much as we evolve the analysis model into the design by adding detail, resolving conflicts, etc.
Design Model: Agents
A common step in OOD is to separate the classes that, in the analysis model, are partially implemented and partially external, into an purely external class representing the original, real-world objects, and an agent class that implements the automatable functions that will now be performed by the new system.
Design Model: Agents (2)
Here we have created an agent for AccountHolders
Design Model: Interfaces
Then we can look closely at the lines (interactions) that cross the border from the outside world into the automated system.
What do we call an interaction between an external entity and an internal automated entity?
Design Model: Interfaces
That’s the definition of an “interface”, and so
- each of those crossing points is a portion of the user interface (or an interface with other automated systems).
2.3.1 MVC
A common organizing principle for such interfaces is to distinguish between
-
viewers that portray the contents of automated classes and
-
controllers that accept external signals (e.g., mouse clicks, keyboard data) and interpret those signals as instructions to automated classes and to viewers.
-
Such viewers and controllers should be implemented as separate classes from the model classes that were derived from the analysis model.
MVC Example
We then wind up with classes specifically devoted to managing the interface between the internal and external worlds.
- This is the Model-View-Controller pattern:
Model-View-Controller
The MVC pattern establishes specific requirements so that GUI changes have minmal impact on the rest of the system.
-
The model classes must not depend on (make use of the interface of) the view and controller classes.
-
The view classes must not depend on the controller classes
2.3.2 Adding Detail
The pictures I have shown emphasize our overall view of the system.
But it is important to remember that, as we make these transitions, we are, almost continuously, adding details to our model of the individual classes,
- filling in functions and attributes,
- solidifying the list of parameters to each function, and
- trying to nail down the required behaviors for those functions