ANALY5E5.PDF

(229 KB) Pobierz
27
Object-oriented analysis
F
ocused initially on the implementation aspects of software construction, the object-
oriented method quickly expanded to cover the totality of the software lifecycle. Of
particular interest has been the application of O-O ideas to the modeling of software
systems, or even of non-software systems and issues. This use of object technology to
present
problems
rather than solutions is known as object-oriented analysis.
In the past few years, many books have appeared on the topic and many specific
methods of object-oriented analysis have been proposed. The bibliography section lists
some of the best-known books, and Web addresses for some of the best-known methods.
Most of the concepts introduced in the preceding chapters are directly relevant to
object-oriented analysis. Here we will briefly review what make object-oriented
analysis
special among other object-oriented topics, and what makes
object-oriented
analysis
different from other analysis methods.
Two points of terminology to avoid imagining differences where none exist. First,
you will encounter, as a synonym for “analysis”, the term
system modeling,
or just
modeling.
Second, the computing science community tends to use the word
specification
where information modeling folks talk about analysis; in particular, computing scientists
have devoted considerable efforts to devising methods and languages for
formal
specification
using mathematical techniques for purposes of system modeling. The goals
are the same, although the techniques may differ. In the past few years the two
communities — information modelers and formal specifiers — have been paying more
attention to each other’s contributions.
27.1 THE GOALS OF ANALYSIS
To understand analysis issues we must be aware of the roles of analysis in software
development and define requirements on an analysis method.
Tasks
By devoting time to analysis and producing analysis documents we pursue seven goals:
904
O BJEC T-O RIENTED A NALY SIS §27.1
Goals of performing analysis
A1 • To understand the problem or problems that the eventual software
system, if any, should solve.
A2 • To prompt relevant questions about the problem and the system.
A3 • To provide a basis for answering questions about specific properties of
the problem and system.
A4 • To decide what the system should do.
A5 • To decide what the system should not do.
A6 • To ascertain that the system will satisfy the needs of its users, and
define acceptance criteria (especially when the system is developed for
an outside customer under a contractual relationship).
A7 • To provide a basis for the development of the system.
If analysis is being applied to a non-software system, or independently of a decision
to build a software system,
A1, A2
and
A3
may be the only relevant goals.
For a software system, the list assumes that analysis follows a stage of
feasibility
study
which has resulted in a decision to build a system. If, as sometimes happens, the two
stages are merged into one (not an absurd proposition, since you may need an in-depth
analysis to determine whether a satisfactory result is conceivable), the list needs another
item: A0, deciding whether to build a system.
Although related, the goals listed are distinct, prompting us in the rest of this chapter
to look for a set of complementary techniques; what is good for one of the goals may be
irrelevant to another.
Goals
A2
and
A3
are the least well covered in the analysis literature and deserve all
the emphasis they can get. One of the primary benefits of an analysis process,
independently of any document that it produces in the end, is that it leads you to ask the
relevant questions (A2): what is the maximum acceptable temperature? What are the
recognized categories of employees? How are bonds handled differently from stocks? By
providing you with a framework, which you will have to fill using input from people
competent in the application domain, an analysis method will help spot and remove
obscurities and ambiguities which can be fatal to a development. Nothing is worse than
discovering, at the last stage of implementation, that the marketing and engineering
departments of the client company have irreconcilable views of what equipment
maintenance means, that one of these views was taken by default, and that no one cared
to check what the actual order giver had in mind. As to
A3,
a good analysis document will
be the place to which everyone constantly goes back if delicate questions or conflicting
interpretations arise during the development process.
Requirements
The practical requirements on the analysis process and supporting notations follow from
the above list of goals:
§27.1 TH E GOALS OF A NALY SIS
905
• There must be a way to let non-software people contribute input to the analysis,
examine the results and discuss them (A1,
A2).
• The analysis must also have a form that is directly usable by software developers (A7).
• The approach must
scale up
(A1).
• The analysis notation must be able to express precise properties unambiguously (A3).
• It must enable readers to get a quick glimpse of the overall organization of a system
or subsystem (A1,
A7)
Scaling up (the third point) means catering to systems that are complex, large or both
— the ones for which you most need analysis. The method should enable you to describe
the high-level structure of the problem or system, and to organize the description over
several layers of abstraction, so that you can at any time focus on as big or as small a part
of the system as you wish, while retaining the overall picture. Here, of course, the
structuring and abstracting facilities of object technology will be precious.
Scaling up also means that the criteria of extendibility and reusability, which have
guided much of our earlier discussions, are just as applicable to analysis as they are to
software design and implementation. Systems change, requiring their descriptions to
follow; and systems are similar to previous systems, prompting us to use
libraries
of
specification elements to build their specifications, just as we use libraries of software
components to build their implementations.
The clouds and the precipice
It is not easy to reconcile the last two requirements of the above list. The conflict, already
discussed in the context of abstract data types, has plagued analysis methods and
specification languages as long as they have existed. How do you “express precise
properties unambiguously” without saying too much? How do you provide readable
broad-brush structural descriptions without risking vagueness?
The analyst walks on a mountain path. On your left is the mountain top, deep
ensconced in clouds; this is the realm of the fuzzy. But you must also stay away, on your
right, from the precipice of overspecification, to which you might be perilously drawn if
your attempts to be precise tempt you to say too much, especially by giving out
implementation
details instead of external properties of the system.
The risk of overspecification is ever present in the minds of people interested in
analysis. (It is said that, to gain the upper hand in a debate in this field, you should try
“Approach
X is nice, but isn’t it a tad implementation-oriented
?” The poor author of X,
reputation lost, career shattered, will not dare show up in a software gathering for the
next twenty years.) To avoid this pitfall, analysis methods have tended to err on the side
of the clouds, relying on formalisms that do a good job of capturing overall structures,
often through cloud-like graphical notations, but are quite limited when it comes to
expressing the
semantic
properties of systems as required to address goal
A2
(answering
precise questions).
906
O BJEC T-O RIENTED A NALY SIS §27.2
Many of the traditional analysis methods fit this description. Their success comes
from their ability to list the components of a system and describe their relations
graphically, making them the software equivalent of the
block diagrams
of other
engineering disciplines. But they are not too good at capturing the semantics. For software
projects this carries a risk: believing that you have completed a successful analysis when
all you have really done is to define the major components and their relations, leaving out
many deeper properties of the specification that may turn out to be critical.
Later in this chapter we will study ideas for reconciling the goals of structural
description and semantic precision.
27.2 THE CHANGING NATURE OF ANALYSIS
Although the object-oriented analysis literature hardly mentions this point, the most
significant contribution of object technology to analysis is not technical but
organizational. Object technology does not just provide new ways of doing analysis; it
affects the very nature of the task and its role in the software process.
This change follows from the method’s emphasis on reusability. If instead of
assuming that every new project must start from scratch, considering the customer’s
requirements as the Gospel, we bring into the picture the presence of a regularly growing
repertory of software components, some obtained (or obtainable) from the outside and
some developed as a result of in-house projects, the process becomes different: not the
execution of an order from above, but a
negotiation.
Customer
A
(Compromise)
Requirements
analysis as a
negotiation
Developer
B
The figure suggests this process: the customer starts with a requirement at
A;
you
counter with a proposal at
B,
covering perhaps only part of the requirements, or a slightly
different form of the requirements, but based for a large part on existing reusable
components and hence achievable at significantly less cost and sooner. The customer may
initially find the sacrifice of functionality too large; this opens a haggling phase which
should eventually lead to an acceptable compromise.
The haggling has always been there, of course. The customer’s requirements were
the Gospel only in some descriptions of the “software process” in the software engineering
literature, presenting an ideal view for pedagogical purposes, and perhaps in some
government contracts. In most normal situations, the developers had some freedom to
discuss requirements. But with the advent of object technology this officious phenomenon
becomes an official part of the software development process, and gains new prominence
with the development of reusable libraries.
§27.3 TH E CONTRIBUTIO N OF O BJECT TECHNOLOGY
907
27.3 THE CONTRIBUTION OF OBJECT TECHNOLOGY
Object technology also affects, of course, the techniques of analysis.
Here the most important thing to learn is that we have almost nothing to learn. The
framework defined in the preceding chapters has more than enough to get us started with
modeling. “More than enough” actually means too much: the notation includes an
operational
part, made of two components which we do not need for analysis:
• Instructions (assignments, loops, procedure calls,
…)
and all that goes with them.
• Routine bodies of the
do
form (but we do need
deferred
routines to specify
operations without giving out their implementation).
If we ignore these imperative elements, we have a powerful system modeling
method and notation. In particular:
•
Classes
will enable us to organize our system descriptions around object types, in
the broad sense of the word “object” defined in preceding chapters (covering not just
physical objects but also important concepts of the application domain).
• The
ADT
approach — the idea of characterizing objects by the applicable operations
and their properties — yields clear, abstract, evolutionary specifications.
• To capture inter-component relations, the two basic mechanisms of “client” and
inheritance are appropriate. The
client
relation, in particular, covers such
information modeling concepts as “part of”, association and aggregation.
• As we saw in the discussion of objects, the distinction between
reference
and
expanded
clients corresponds to the two basic kinds of modeling association.
•
Inheritance
— single, multiple and repeated — addresses classification. Even such
seemingly specialized inheritance mechanisms as renaming will be precious to
model analysis concepts.
•
Assertions
are essential to capture what was called above the
semantics
of systems:
properties other than structural. Design by Contract is a powerful guide to analysis.
•
Libraries
of reusable classes will provide us — especially through their higher-level
deferred classes — with ready-made specification elements.
This does not necessarily mean that the approach seen so far covers all the needs of
system analysis (a question that will be discussed further below); but it certainly provides
the right basis. The following example will provide some evidence.
27.4 PROGRAMMING A TV STATION
Let us see concretely how to apply the O-O concepts that we know to pure modeling.
The example involves organizing the schedule of a television station. Because it is
drawn from a familiar application area, we can start it (although we most likely could not
complete it) without the benefit of input from “domain experts”, future users etc.; we can
just, for the analysis exercise, rely on every layperson’s understanding of TV.
Although the effort may be the prelude to the construction of a computerized system
to manage the station’s programming automatically, this possibility is neither certain nor
relevant here; we are just interested in modeling.

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika:

Zgłoś jeśli naruszono regulamin