Page 322 -

chaPter 10 • object-oriented systems analysis and design Using Uml 289

Often overlooked in the development of a new system is that the further a project pro-
gresses, the costlier the changes are to the business requirements of a system. Changing the
design of a system using a CASE tool, or even on paper, during the analysis and design phases of
a project is easier, faster, and much less expensive than doing so during the development phase
of the project.
Unfortunately, some employers are shortsighted, believing that only when a programmer or
analyst is coding is that employee actually working. Some employers erroneously assume that
programmer productivity can be judged solely by the amount of code produced, without recog-
nizing that diagramming ultimately saves time and money that might otherwise be wasted if a
project is prototyped without proper planning.
An analogy to building a house is very apt in this situation. You do not want to live in a
structure built without planning, one in which rooms and features are randomly added without
regard to function or cost. You want a builder to build your agreed-upon design from blueprints
containing specifications that have been carefully reviewed by everyone concerned. As a member
of an analyst team so accurately observed, “Putting a project on paper before coding will wind
up costing less in the long run. It’s much cheaper to erase a diagram than it is to change coding.”
When business requirements change during the analysis phase, you may have to redraw
some UML diagrams. If the business requirements change during the development phase, how-
ever, a substantial amount of time and expense may be required to redesign, recode, and retest
the system. By confirming your analysis and design on paper (especially through the use of UML
diagrams) with users who are business area experts, you help to ensure that correct business
requirements will be met when the system is completed.

Summary

Object-oriented systems describe entities as objects. Objects are part of a general concept called classes, the
main unit of analysis in object-oriented analysis and design. When the object-oriented approach was first
introduced, advocates cited reusability of the objects as the main benefit of the approach. Although reus-
ability is the main goal, maintaining systems is also very important.
Analysts can use CRC cards to begin the process of object modeling in an informal way. Object Think
can be added to the CRC cards to assist the analyst in refining responsibilities into smaller and smaller tasks.
CRC sessions can be held with a group of analysts to determine classes and responsibilities interactively.
Unified Modeling Language (UML) provides a standardized set of tools to document the analysis and
design of a software system. UML is fundamentally based on an object-oriented technique known as use case
modeling. A use case model describes what a system does without describing how the system does it. A use
case model partitions system functionality into behaviors (called use cases) that are significant to the users of
the system (called actors). Different scenarios are created for each different set of conditions of a use case.
The main components of UML are things, relationships, and diagrams. Diagrams are related to one
another. Structural things are most common; they include classes, interfaces, use cases, and many other
elements that provide a way to create models. Structural things allow the user to describe relationships. Be-
havioral things describe how things work. Group things are used to define boundaries. Annotational things
permit the analyst to add notes to the diagrams.
Relationships are the glue that holds the things together. Structural relationships are used to tie the
things together in structural diagrams. Structural relationships include dependencies, aggregations, associa-
tions, and generalizations. Behavioral diagrams use the four basic types of behavioral relationships: com-
municates, includes, extends, and generalizes.
The toolset of UML is composed of UML diagrams. They include use case diagrams, activity dia-
grams, sequence diagrams, communication diagrams, class diagrams, and statechart diagrams. In addition
to using the diagrams, analysts can describe a use case by writing a use case scenario.
Using UML iteratively in analysis and design allows for greater understanding between a business
team and an IT team regarding the system requirements and the processes that need to occur in a system to
meet those requirements.

Keywords and Phrases

abstract class Ajax
activity diagram annotational thing
actor association
aggregation asynchronous message