How do you do it?
There is a variety of techniques for
creating a model, depending on the situation you're in: interviewing a
prospective user, modelling a business, re-engineering an existing system.
There is a battery of techniques for progressing from the blank paper towards
something meaningful: scenarios and storyboards, rich pictures, grammatical
analysis …. Different analysts have their own favourites, and the various
techniques have strengths in different areas of work. One of the strengths of object
oriented analysis is that we lay equal emphasis on dynamic and static views
and their inter-relationship (as opposed to purely functional or entity-relational
All methods have it in common that you are making
a gradual approach from a fuzzy to a clear picture. (One of the requirements
of a modelling language is therefore that it should be good at representing
whatever you know at any stage along this approach — unlike a programming
language, which only has to represent the end product of your labours.)
One of the benefits of modelling in a formal language
is that you can know when you've got a consistent picture. How does this
work? We use a technique that forms part of Catalysis.
Static relationships are modelled with
attributes and associations. By 'static relationships', we mean any that
could be formulated as read-only queries: What is this Customer's account
number? Who does this Employee report to? Who owns this bed?
Dynamic relationships are modelled with use-cases.
By 'dynamic relationships', we mean those that entail a change in static
relationships: opening a new account; transferring an Employee to a different
division; selling a bed to a Customer.
Use-cases and associations
An important property of a use-case is what it achieves.
For use-cases with a definite start and end, we can describe this with
a goal or post-condition. (In Catalysis, the idea of use-case is extended
to cover all procedures, tasks, events and operations, inside or outside
the software, and whether they actually use the software or not: anything
that happens is called an 'action.')
For example, selling something always achieves
a tranfer of ownership from the vendor to the purchaser, together with
a transfer of money in the opposite direction. This achievement is what
makes it a sale rather than anything else; how it is achieved —
by what sequence of steps or with what intermediate agencies — is less
general: credit-card sales, mail-order sales, over-the-counter sales are
all subtypes of the basic idea of sale.
We can draw instance diagrams ('snapshots') to
illustrate the change of static relationships achieved by a use-case. The
nature of the changes tells us what attributes or associations we need.
The query, 'Who owns this thing?' is one that is altered by a sale; so
we invent an 'owner' association and use it in an instance diagram —
in fact, a pair of diagrams, drawn one on top of the other, that show a
If we want to include the effect of a sale on the
customer's pocket -- well, let's have an attribute called 'pocket' that
represents a quantity of money; and the vendor will have a till. Every
sale entails a complementary change of their contents, and we can show
those on the snapshots too.
Once we've drawn the snapshots, we can adjust
our class diagram to make sure it includes the associations and attributes
we've been using.
Notice how the description of the action tells
us what objects and associations we need. In some modeling techniques,
there is no particular relationship between the static and dynamic parts
of the model: in this technique, the need for associations is dictated
by the need to describe the actions. (It's analogous to the need for variables
and types in a program: they're there to provide the information manipulated
by the procedures.)
State-charts, associations and use-cases
We'veseen how thinking about a use-case's achievements can tell us what objects
and associations we need; but we can go the other way too, by asking "what
can change this association or attribute?" A particularly effective technique
is to draw statecharts. (In Catalysis, we use them descriptively, with
no implication of any particular implementation.) For example, we
might ask our retailing clients about the lifecycle of things they sell.
The answer might be that a Thing is ordered, eventually is received and
goes into stock, will be displayed on the shelf, and can either be sold
or lost. Each of the transitions in the statechart is interpreted as an
action (use-case): we can document it in a diagram with an ellipse,
write its postcondition, and illustrate the effect with a before/after
snapshot; and hence perhaps derive some more associations.
The modeling cycle
This diagram sums up the analysis cycle
we've described. When modeling, you may find objects and use-cases through
a variety of techniques. There is no constraint on the order in which you
find them; but whenever you find use-cases, you describe their effects
and thereby find objects with their attributes and associations; and whenever
you find objects, you ask what can happen to them (perhaps with the help
of statecharts), and thereby find use-cases. Eventually, you come to a
steady state in which you're discovering no new elements in the model;
and at that point, you know your model is self-consistent. Along the way,
you've had to ask a lot of questions about the domain (which might not
have been asked in any method that demands less connection between the
different views of the model).
In object-oriented design philosophy, the aim is to build software
as a simulation of the world in which it works. If the structure of the
software mirrors the structure of the domain, then it's easy to trace
in requirements (which are expressed in terms of the clients' domain)
to the necessary changes in the software. Again, software
requirements management should make explicit the refinements of any SRS
(software requirement specification).
One thing you can do with your model, then, is to press the 'generate
code' button on your modeling tool, and create a working prototype of the
But it isn't always possible to stick to this ideal in practice. The
demands of performance, distribution, and separation of concerns make it
necessary to apply a variety of patterns that entail rearrangements and
extra classes. For that reason, it's worth keeping a domain model separate
from your software. What we can do is to keep the overall structure equivalent
to the domain model at a certain level, with independent local transformations
where necessary. Documenting the model and the transformations, however
curtly, helps maintainers understand the software and make changes that
cohere with the original spirit of the design, and so helps prolong its
complete solutions for requirements engineering
(consultancy, courses, workshops, mentoring, seminars, development)