Students Notes

OBJECT-ORIENTED SYSTEMS ANALYSIS & DESIGN
Instructors Manual

Copyright 2009 Pearson Education, Inc. Publishing as Prentice Hall
1

O OB BJ JE EC CT T- -O OR RI IE EN NT TE ED D S SY YS ST TE EM MS S A AN NA AL LY YS SI IS S & & D DE ES SI IG GN N

T Ta ab bl le e o of f C Co on nt te en nt ts s
C Ch ha ap pt te er r 1 1. . I In nf fo or rm ma at ti io on n S Sy ys st te em ms s. .
O Overview ................................................................................................................ 8
O Objectives .............................................................................................................. 8
O Outline.................................................................................................................... 8
O Review Questions & Answers .............................................................................. 11
O Research Projects & Teamwork ........................................................................... 12
O Discussion Notes ................................................................................................. 13
O Next: The Concept of Object Orientation. ............................................................ 13
C Ch ha ap pt te er r 2 2. . T Th he e C Co on nc ce ep pt t o of f O Ob bj je ec ct t O Or ri ie en nt ta at ti io on n. .
O Overview .............................................................................................................. 15
O Objectives ............................................................................................................ 15
O Outline.................................................................................................................. 15
O Next: Methodology. .............................................................................................. 21
C Ch ha ap pt te er r 3 3. . M Me et th ho od do ol lo og gy y. .
O Overview .............................................................................................................. 23
O Objectives ............................................................................................................ 23
O Outline.................................................................................................................. 23
O Next: Gathering Requirements. ............................................................................ 31
OBJECT-ORIENTED SYSTEM ANALYSIS & DESIGN
Instructors Manual

2

C Ch ha ap pt te er r 4 4. . G Ga at th he er ri in ng g R Re eq qu ui ir re em me en nt ts s. .
O Overview .............................................................................................................. 32
O Objectives ............................................................................................................ 32
O Outline.................................................................................................................. 32
O Examples. ............................................................................................................ 38
O Next: Domain Analysis ......................................................................................... 43
C Ch ha ap pt te er r 5 5. . D Do om ma ai in n A An na al ly ys si is s. .
O Overview .............................................................................................................. 44
O Objectives ............................................................................................................ 44
O Outline.................................................................................................................. 44
O Examples. ............................................................................................................ 53
O Next: Behavioral Modeling II Use Cases: The Basics ....................................... 56
C Ch ha ap pt te er r 6 6. . B Be eh ha av vi io or ra al l M Mo od de el li in ng g I I U Us se e C Ca as se es s: : T Th he e B Ba as si ic cs s. .
O Overview .............................................................................................................. 58
O Objectives ............................................................................................................ 58
O Outline.................................................................................................................. 58
O Next: Behavioral Modeling II Developing Use Cases ........................................ 65
C Ch ha ap pt te er r 7 7. . B Be eh ha av vi io or ra al l M Mo od de el li in ng g I II I D De ev ve el lo op pi in ng g U Us se e C Ca as se es s. .
O Overview .............................................................................................................. 67
O Objectives ............................................................................................................ 67
O Outline.................................................................................................................. 67
Instructors Manual

3

O Examples ............................................................................................................. 72
O Next: Structural Modeling ..................................................................................... 79
C Ch ha ap pt te er r 8 8. . S St tr ru uc ct tu ur ra al l M Mo od de el li in ng g. .
O Overview .............................................................................................................. 80
O Objectives ............................................................................................................ 80
O Outline.................................................................................................................. 80
O Examples. ............................................................................................................ 88
O Next: Dynamic Modeling ...................................................................................... 92
C Ch ha ap pt te er r 9 9. . D Dy yn na am mi ic c M Mo od de el li in ng g. .
O Overview .............................................................................................................. 93
O Objectives ............................................................................................................ 93
O Outline.................................................................................................................. 93
O Next: The Design Challenge ............................................................................. 101
C Ch ha ap pt te er r 1 10 0. . T Th he e D De es si ig gn n C Ch ha al ll le en ng ge e. .
O Overview ............................................................................................................ 102
O Objectives .......................................................................................................... 102
O Outline................................................................................................................ 102
O Review Questions & Answers ............................................................................ 104
O Research Projects & Teamwork ......................................................................... 104
O Discussion Notes ............................................................................................... 106
O Next: Application Design I: Flow & Control......................................................... 107
Instructors Manual

4

C Ch ha ap pt te er r 1 11 1. . A Ap pp pl li ic ca at ti io on n D De es si ig gn n I I: : F Fl lo ow w & & C Co on nt tr ro ol l. .
O Overview ............................................................................................................ 109
O Objectives .......................................................................................................... 109
O Outline................................................................................................................ 109
O Examples. .......................................................................................................... 114
O Next: Application Design II: The User Interface ................................................. 117
C Ch ha ap pt te er r 1 12 2. . A Ap pp pl li ic ca at ti io on n D De es si ig gn n I II I: : T Th he e U Us se er r I In nt te er rf fa ac ce e. .
O Overview ............................................................................................................ 118
O Objectives .......................................................................................................... 118
O Outline................................................................................................................ 118
O Next: Application Design III: Database & Persistence. ....................................... 121
C Ch ha ap pt te er r 1 13 3. . A Ap pp pl li ic ca at ti io on n D De es si ig gn n I II II I: : D Da at ta ab ba as se e & & P Pe er rs si is st te en nc ce e. .
O Overview ............................................................................................................ 122
O Objectives .......................................................................................................... 122
O Outline................................................................................................................ 122
O Examples. .......................................................................................................... 128
O Next: Patterns .................................................................................................... 130
C Ch ha ap pt te er r 1 14 4. . P Pa at tt te er rn ns s. .
O Overview ............................................................................................................ 131
O Objectives .......................................................................................................... 131
O Outline................................................................................................................ 131
Instructors Manual

5

O Next: Components & Reuse............................................................................... 134
C Ch ha ap pt te er r 1 15 5. . C Co om mp po on ne en nt ts s & & R Re eu us se e. .
O Overview ............................................................................................................ 135
O Objectives .......................................................................................................... 135
O Outline................................................................................................................ 135
O Next: Architecture .............................................................................................. 139
C Ch ha ap pt te er r 1 16 6. . A Ar rc ch hi it te ec ct tu ur re e. .
O Overview ............................................................................................................ 140
O Objectives .......................................................................................................... 140
O Outline................................................................................................................ 140
ONext: Implementation .......................................................................................... 148
C Ch ha ap pt te er r 1 17 7. . I Im mp pl le em me en nt ta at ti io on n. .
O Overview ............................................................................................................ 149
O Objectives .......................................................................................................... 149
O Outline................................................................................................................ 149
Instructors Manual

6

1
11.
.. I IN NF FO OR RM MA AT TI IO ON N S SY YS ST TE EM MS S
I I. . O Ov ve er rv vi ie ew w
Information systems are systems that process data into information. An information system can be
viewed from various perspectives: its goals, its processes or its components, i.e., applications,
information technology, people and procedures.
Information systems are also products and, like other products, they must satisfy their consumers
and must be developed by following a methodology that assures the best possible quality and the
best possible use of resources.
I II I. . C Ch ha ap pt te er r O Ob bj je ec ct ti iv ve es s
Define information, system, information systems, and information technology.
Learn about the building blocks of information technology.
Understand the difference between information systems and software applications.
Learn about the business of making information systems.
Describe information systems as infrastructure.
Learn about the enterprise of making information systems.
I II II I. . C Ch ha ap pt te er r O Ou ut tl li in ne e
INFORMATION & ITS COMPONENTS
Information is a set of data organized in a way that conveys knowledge or enables its recipient to
execute a set of actions to reach an objective. Information has three main constituents: data, goal
and logic. If any of one these elements are missing, then data does not become information.
The relationship between data and information is hierarchical: what is information at one level
can become data at a higher level that strives for a larger meaning.
SYSTEM & ITS COMPONENTS
A system is an assembly of interrelated elements or components that together make the system a
distinct whole. The components of a system must have a formal structure and the system as a
whole must have a recognizable identity. Therefore, a monolithic entity is not a system; neither is
an entity without a distinct identity.
A system may consist of other systems or it may be a subsystem of a larger system. As a result,
the relationship between systems can become hierarchical.
INFORMATION SYSTEMS
Information systems consist of applications, information technology, people, processes and
procedures. An information system is an open system that processes data into information
according to a set of clear and unambiguous logical assumptions.
Features that an information system inherits from information and systems constrain each other.
An archive stores data systematically, but it does not produce information; therefore an archive is
not an information system by itself (even though it is very likely to be a part of information
technology).
Instructors Manual

7

INFORMATION TECHNOLOGY
Information is virtual and, consequently, needs a medium with physical presence to make it
tangible. This vehicle is provided by information technology, a collection of methods, tools,
material and know-how that support an information system.
Information technology is not one entity, but a set of interrelated components:
Know-how is the knowledge and the skill required to do something correctly. Without know-
how, other components of technology are wasted.
Method is a systematic way of reaching an objective. Methods function as guideline to people
with know-how to accomplish a task. In turn, new experiences must refine existing methods.
Materials are frequently seen as the only components of technology, perhaps because they are
tangible whereas know-how and methods are not. But even though no technological revolution
is possible without them (consider paper and printing), they constitute only one side of the
technology triangle. (Consider, again, paper and printing: paper, lead and wine press were
available to Europeans long before Johannes Gutenberg invented moveable type printing in the
15
th
century.)
THE BUILDING BLOCKS OF INFORMATION TECHNOLOGY
Information technology is composed of one or more processing units and three systems:
The Processing Unit
The Communication System.
The Data Management System.
The Control System.
Information automation, largely the gift of computer technology, is the application of information
logic by a device that executes a program.
INFORMATION SYSTEMS & APPLICATIONS
An application is a set of one or more programs that performs a specific task. At the early stages of
the software revolution, when automation requirements were modest, applications were seen as
independent entities and were created as monoliths. As the complexity of software products has
become overwhelming, however, applications must be viewed and developed as integral parts of
information systems. Fortunately, the technology to build systems instead of monoliths is now
mostly mature.
INFORMATION SYSTEMS AS PRODUCTS
The increasing complexity of information systems is driving software development out of in-house
shops and into companies that specialize in the various fields of software development. As a result,
to be successful, software must be conceived as a product, designed as a product and marketed as a
product.
At the same time, information systems are turning from tools of business, trade and administration
into an integral part of the enterprise. Today, information is becoming an asset equal in importance
to others such as expertise, organization, equipment, property, labor, and capital. Information, like
other assets, must be managed, stored, bought and sold (and is, sometimes, stolen). Managing
information systems has evolved to a level of complexity that it now requires a functional division
of its own within most organizations.
Instructors Manual

8

THE BUSINESS OF MAKING INFORMATION SYSTEMS
Production of information systems and/or their components is increasingly becoming a business in
its own right. Today, we can distinguish several sectors in the software industry:
System Software: operating systems, utilities and other basic components of information
technologies.
Software Components: parts that are assembled and combined by their buyers to create
complete systems and applications.
Software Contractors: build custom software for enterprises that need very specialized
solutions.
ERP: Enterprise Resource Planning software products aim at satisfying the enterprise-wide
information needs of a corporation within a unified system.
Mass Market Software: general-purpose products that are targeted at end-users.
INFORMATION SYSTEMS AS INFRASTRUCTURE
Infrastructural information systems are a set of systems and applications that support the basic
functions of an enterprise. They can be classified into several broad categories including:
Transaction Processing Systems (TPS): record and process data about the routine activities of an
enterprise.
Business-to-Business (B2B) Systems: allow businesses to conduct transactions or exchange of
information online.
Business-to-Consumer (B2C) Systems: allow consumers to buy products and services directly
from businesses online. Both B2B and B2C are often called e-commerce.
Business Intelligence (BI) Systems: a set of subsystems and applications that allow the
management to analyze operational and market data, create models, make forecasts and test
business decisions virtually. Whereas previous systems provide tactical advantages, BI must
provide a strategic view.
Artificial Intelligence (AI) & Robotics: enable machines to automatically perform tasks that
otherwise would require human intelligence, solve complex problems by using non-
mathematical algorithms, simulate real or imaginary environments, and provide expert opinion
by using available information, heuristic, and inference. AI is used in a vast and expanding
array of products: robotics, forecasting, virtual reality (games and simulations) and expert
systems.
THE ENTERPRISE OF MAKING INFORMATION SYSTEMS
Software is a product and software development must follow the discipline of product
development. Products are not developed in the exact same manner, but certain general guidelines
apply to all.
The first is to identify requirements. Requirements describe the objectives of the product. But
they are not the same as product specifications. A finished product has two sets of features: one set
satisfies business requirements, while the second set make the first set possible. A bicycle must
have two wheels and be light (requirements), but the wheels must be sturdy enough not to bend.
By using spokes (a solution feature) the requirements are met, but spokes are not part of
requirements.
Instructors Manual

9

Product development must follow a methodology, a set of practices, procedures, rules and
techniques. Methodology results from abstracting and organizing experience within a theoretical
framework. In simpler times, when demands on software were modest, methodology did not play a
role. The ever-increasing complexity of information systems, however, makes methodology
indispensable.
The development of any product by a team under time and financial constraints is in need of
project management: planning, monitoring and controlling the course of the development process
and the resources used by that process. Project management has general principles, practices and
guidelines, but must be adapted to the goal of the project, to the resources available to a specific
project, and to the methodology used to achieve the goal.
In product development, it is prudent to distinguish between problem space and solution space.
Problem space is the source of requirements; it is the environment in which the final product must
work and solve problems. The solution space, on the other hand, contains issues that are related to
the product (solution) itself, not the problems addressed by the product. In problems space, we
analyze business problems and their related concepts; in solution space we design the product.
The two spaces, however, overlap and affect each other.

THE LONG HISTORY OF DATA MANAGEMENT SYSTEMS
Data management systems have been as varied as the information technologies that they have
served. In the remains of Persepolis, the capital of the ancient Persian empire (todays Iran),
archeologists have discovered thousands of cuneiform clay tablets detailing wages paid to workers
building royal palaces around 500 B.C. And in Mesopotamia, security for contracts and records of
financial transactions was provided by covering the tablets with a clay envelope on which the
parties made an impression of their personal seals.
Clay or stone tablets are, of course, not easy to work with. Therefore, the search for materials
suitable for data management systems has been an ongoing enterprise in all civilizations in need of
efficient data management. Egyptians introduced papyrus (made from the stem of a plant that
grows around the Nile delta) which was later adopted by the ancient Greeks and Romans. Until the
spread of paper, parchment (writing material made from animal skins) was also used for writing
(though its high cost usually precluded its use for mundane tasks such as everyday bookkeeping).
Thus far, the longest-running success belongs to paper that was invented by the Chinese around
200 B.C., but did not make its way to Europe until a thousand years later. (And Europeans did not
make paper until the 11
th
or 12
th
century.) Paper is flexible, light and can be made from material
(rags or wood, for example) widely available and is therefore relatively cheap.
Modern digital databases are stored on magnetic material and laser disks (even though, for a while,
paper punch cards were the only choice).
Many good, absorbing and, sometimes, amusing accounts of the history of writing material are
available. What concerns us in this chapter is the relationship of material to data management
systems and, consequently, to information systems. Organizing data indexing and cross-
indexing is a core function of any data management system. The changes in storage material
have also resulted in changes to the capacity and the organizing capabilities of data management
systems.
O Automation: the assembly line moved instead of workers.
O Continuous Flow: the line did not stop.
O Division of Labor: each worker was trained for a specific operation.
Instructors Manual

10

O Interchangeable Parts: the parts were standard, not customized.
Modern manufacturing has streamlined Fords methodology, but has not replaced it.
V VI II I. . N Ne ex xt t: : T Th he e O Ob bj je ec ct t- -O Or ri ie en nt te ed d C Co on nc ce ep pt t. .
All information systems consist of similar components both virtual and physical but,
throughout history, these components have taken an astounding array of shapes and forms.
Software is the soul of automated and modern information systems: it embodies the logic that
converts data into information, connects the virtual to the physical, and manages the interaction
between components.
What then are the building blocks of software? Like a building, the information system has an
architecture, a certain arrangement of horizontal and vertical layers that are, in turn, constructed in
a certain way from various units.
At this point in time, the finest that both the technology and the theory offer is object orientation:
object-oriented architecture and object-oriented development. At the foundation of this approach
lies one seemingly simple concept: constructing software from objects is the best answer to the
challenge of complexity, both in the process of development and in the final product itself. The
real world, as complex as it is, is made of objects and their interactions. Clearly, a virtual world
can learn greatly from the real world.
Thus, learning how to develop software must start with understanding objects a task that we
will undertake in the next chapter.
Instructors Manual

11

2
22.
.. T TH HE E C CO ON NC CE EP PT T O OF F O OB BJ JE EC CT T O OR RI IE EN NT TA AT TI IO ON N
An object-oriented information system consists of objects, and an object-oriented approach to
software development model objects, their relationships and their interactions. This chapter
presents the basic concepts that apply to objects.
I II I. . C Ch ha ap pt te er r O Ob bj je ec ct ti iv ve es s. .
Learn about object and its identity, attributes, operations, and state.
Learn about classes, superclasses, subclasses & class hierarchy.
Understand virtual objects.
Describe encapsulation, information hiding, and object interface.
Understand aggregate and composite objects.
Understand inheritance and polymorphism.
Learn about origins of object-oriented technology.
Describe object-oriented modeling & the Unified Modeling Language (UML).
I II II I. . C Ch ha ap pt te er r O Ou ut tl li in ne e. .
OBJECT.
Before we can proceed with object-oriented analysis and design, we must understand what objects
are. An object is a thing, an entity with clear boundaries and a unique identity. If a thing is
intelligible or perceptible by the mind, it is an object, regardless of whether it is tangible or
intangible.
IDENTITY
Objects have a unique identity even if they are cloned. The identity of an object is what
distinguishes it from all other entities and objects. This identity is unique and unchanging, even if
everything else about the object changes.
ATTRIBUTES & OPERATIONS
We associate objects with their characteristics and, often, with what they do. Properties that make
an object what it is are called attributes, and what they are called operations. Attributes are paired
with values that quantify or qualify them.
STATE
Objects change or, to put it somewhat differently, the values that their attributes hold, are changed.
A child becomes a grown woman, a sapling grows into a mighty oak, and an ugly duckling
becomes a swan. Sometimes even the attributes themselves (or our selective perceptions of them)
change.
Instructors Manual

12

State is our perception of the condition of an object at a certain stage of its life. State is based on
the values that an objects attributes hold, but since our perception of an object is selective, its
state can be simultaneously described in many ways: a car may be luxury and moving at the
same time.
CLASSES
Classes are concepts that result from classification, and, in our everyday lives, we are in constant
process of classification. Classification is to define, rightly or wrongly, what attributes a set of
objects share. It results from two related mental processes: abstraction that selects the set of
attributes that we find relevant or significant, and generalization that broadens the reach selected
attributes to more than one object.
An instance is a member or manifestation of a class. Therefore, when we intend to imply the
relevance of a class to an object, we call the object an instance of that class: John Doe is an
instance of the class Human, and Spotty is an instance of Dog.
SUPERCLASSES, SUBCLASSES & CLASS HIERARCHY
Some classes are more abstract or generalized than others and some are less. The more abstract
classes are called superclasses that own a set of less abstract subclasses. The relationship among
superclasses and subclasses is called class hierarchy: the superclass is the parent; its subclasses
are children to their parent and siblings to each other.
VIRTUAL OBJECTS
Objects that constitute an information system are called virtual objects. They are generally similar
to real-world objects with one significant difference: in a virtual world, classes are both abstracts
of objects and templates for creating them. In a banking system, a new bank account is created
from a class from which all other accounts are created as well.
Virtual classes fall into two broad categories: business or entity classes that reflect business
concepts, and utility classes that manage the responsibilities of the information system and do not,
usually, have counterparts in the real world.
ENCAPSULATION & INFORMATION HIDING
Objects, real or virtual, are encapsulated. That is, attributes and the operations of an object exist
within a capsule, an enclosed area or a black box, that divides their living space into two:
public, exposed to the outside world, and private, known only to the object itself.
Information hiding is a result (and an advantage) of encapsulation: how an object does something,
and the data that it holds, are concealed within the object, secure from abuse or misuse.
OBJECT INTERFACE
Since outside entities cannot interfere with the internal workings of an object as a result of
encapsulation and information hiding, they must work with its interface: operations that the object
provides to the public. These public operations are also called responsibilities since by exposing
an interface, the object promises to perform certain services.
An interface, however, is more than services that it provides. An interface is equal parts form and
content.
AGGREGATE & COMPOSITE OBJECTS
Whether the fact is relevant to us or not, almost all objects are made up of other objects. When this
whole-part relationship is significant to us, we define it as an aggregation relationship: classrooms
Instructors Manual

13

consist of students and teachers, cars are made up of engines, wheels, etc., and living organisms
are composed of cells.
Composition is a strict form of aggregation in which the part belongs to one, and only one, whole.
Whereas a student may participate in many classes, a cell can belong to one living organism only
(even if, like blood cells, it can be transferred).
INHERITANCE & POLYMORPHISM
Like DNA and genetics in the living world, inheritance is a mechanism by which virtual objects
that belong to a subclass inherit the characteristics of the superclass. How this is done in actuality
is within the realm of specific technologies, but all mechanisms of virtual inheritance have one
important feature in common: whereas inheritance in the real world is cast in stone when a living
organism is born, virtual inheritance is live and ongoing. If the superclass learns to do something
better, so do all the instances of the subclass.
Polymorphism is a result of specialization, and is closely tied to inheritance: all mammals move,
but while the deer move on four legs, humans walk on two legs, monkeys swing from tree to tree,
and bats fly.
ORIGINS OF OBJECT-ORIENTED TECHNOLOGY
In the early days, computer programs treated data and processes as separate entities. With the
emergence of more powerful computers and the increasing complexity of information systems, a
technology that could handle the complexity by adopting an object-oriented approach became both
a necessity and a possibility.
The adoption of object-oriented technology has been a gradual process, but has now gained a
critical mass and has established itself in the absolute majority of development shops.
OBJECT-ORIENTED MODELING & THE UNIFIED MODELING LANGUAGE (UML)
Object-oriented technology will yield the maximum profit only with object-oriented analysis and
design. But such an approach requires modeling tools that generally lagged behind object-oriented
technology. The Unified Modeling Language is a language, which provides the primitives (or
the basic elements) for building object-oriented conceptual (analysis) and concrete (design)
models.
UML is not a specific product, or process, or methodology, but a notational system that allows
analysts, designers and developers to adopt its diagrams to the task at hand, detailed or general,
conceptual or concrete. UML has been adopted by a de facto standard body (OGM) and has been
implemented in a large number of modeling tools, many of which are capable of round-
engineering between the code and the models.
VIRTUAL DEFINITIONS
Like many other words, virtual has come a long way from its roots. We still use the term
virtue in a sense that is closest to its Latin ancestor: moral excellence and goodness (though, no
longer, as a result of manly valor.)
For information systems, including the software versions, the term has more recent meanings. In
order of relevance, these definitions are: O something that mirrors a concept, O something that
simulates a real thing, and O something that is practically, essentially or effectively so, but not in
(absolute) fact. None, however, is limited to information systems, software or otherwise.
Instructors Manual

14

Recently, the prefix e (with or without a hyphen) has taken over many, but not all, functions of
virtual: e-commerce, e-mail, e-cash, e-business. And when the context is rather cultural, the
prefix cyber is more common: cyberspace, cyber-community, etc.
C CO ON NC CE EP PT TS S
It seems a paradox that grasping the ideas of abstraction, encapsulation and generalization appear
so elusive, so formidable, to many newcomers to object orientation. After all, human beings are
very good at this sort of thing: from a very early age, we start abstracting, encapsulating and
generalizing our experiences and observations into concepts, and we continue to do so day in
and day out as long as we have our wits about us. To be more exact, we cannot function without
concepts.
As toddlers, we may become fascinated with the magic of an open fire and be left with blisters on
our fingertips. After a few encounters, if we are not especially dim, we form a concept about fire,
even though we might not have a name for it. We learn that a fire has certain things about it that
makes it a kin to other fires that we have experienced: it glows from blue to yellow to red, it rises
upward, it radiates heat, and it dances a beautiful dance but, if we touch it, it burns our fingers.
More or less in parallel, we abstract the attributes and the behavior of fire, package these
abstractions into a container a capsule, if you will and generalize the collection into Fire. We
realize that encapsulated within a fire is the power to burn. How it burns we do not know, but we
do accept that it would burn us just the same.
From then on, the concept shapes our perception of the world and our interactions with it. When
we come across an object, we try to classify it: with minimal conscious effort, we process the data
we receive from the object and we test this data against the our growing inventory of concepts. If
the object passes the mental test, if we conclude that this thing is an instance of fire, we decide to
resist the temptation to test it physically.
In time, we get a name for the concept we have developed. The name is normally given to us by
other people, or we may develop one ourselves. (Children are not hesitant in creating words from
thin air. The need to name concepts appears to be intrinsic to all instances of Human.)
By assigning a symbol to a concept name is just one type of symbol we formally turn a
concept into a class. What is more, the symbol empowers us to communicate the concept to others
and permit others to share with us concepts that we have not experienced or formed personally.
We even go further and assign symbols to symbols: the printed words we read are symbols for the
spoken words.
Not all concepts are potential classes: good and bad, are judgments that must be applied to a
concept or an object, is and was are verbs, and long and short are values. Nevertheless,
they are all abstracted and generalized.
In turn, not all potential classes are generalized from tangible objects: customer is a role; a car
accident is an event (even though it would have very tangible results); friendship is a
relationship; time may be money but it is an intangible; calling a man successful is a
judgment; a trial produces a judgment but is a process.
We are so comfortable, so possessed, with abstraction and generalization that we have to put some
extra effort into the reverse process; namely, to convey that we mean an instance and not the
concept. We add an article (I ate the apple), we modify the concept with an adjective (Ill wear
my good suit), enhance it with the context and description (That chair the one with the high
back is more comfortable), or if it is worth our while, we label it with a name or number that
we hope will be unique (and often, to our dismay, is not: No, I did not visit the Eiffel Tower: the
conference was in Paris, Texas, not Paris, France). We are, by nature, object-oriented.
Instructors Manual

15

WHY, THEN, THE PARADOX?
It appears that we are better at generalizing from objects than at dissecting concepts into their
building blocks. When we need to clarify a concept that is new to another person, we usually
resort to analogies rather than analysis: a sea is like a pond but much bigger!
Doing something naturally (or at least effortlessly) does not mean that we can describe it
efficiently or apply it to another domain, i.e., the virtual world of information automation. We
have to learn it by trial and error, even though it is not an alien artifact. We need experience.
Regardless of how we try to keep them separate, system analysis and design are intertwined:
the goal of analyzing one system is, usually, to find or construct the building blocks, behaviors
and rules that will result in another system. We have one eye towards one, the other eye
towards the other. Keeping our balance while juggling the two is not easy.
Symbols are representations of concepts, not the concepts themselves. We pass them around as
black boxes with labels. By reading the labels, we think we know what is inside. In analysis,
we have to open the boxes and certify the results. We are not used to this close inspection. We
receive contents which might be contrary to our preconceptions, and we pass on boxes that
could be contrary to the receivers preconceptions.
Even armed with experience and theory, we might make the mistake that we are to model the
real world. Instead, we should know that we are modeling how people perceive the world. We
are forming concepts about concepts.
Every methodology or theory brings forth a torrent of new or redefined terms that are likely to
overwhelm us. Sometimes a new terminology is mostly a marketing tool; sometimes it serves
to distinguish professionals from laymen; at other times it is the result of genuinely new
methods and new technologies. The most disconcerting are those terms that are deceptively
familiar. For example, UML provides a mechanism to extend its notation with stereotypes.
We might have been told (or should have been told) not to stereotype people. Now we have to
open a new compartment in our minds besides the old one. Stereotyping people is harmful;
stereotyping in UML is helpful.
CONCEPT, RED IN TOOTH AND CLAW
A prehistoric man ventures forth to find badly-needed food for his clan. By chance, he comes
across a tiger an old, decrepit, helpless tiger. He bashes the tiger on the head with his club, kills
it and drags the body to his clans shelter. All are overjoyed: so much meat and such a beautiful
pelt! The man becomes a hero and, in time, an elder of the clan. At nights, next to the camp fire, he
never tires of telling the story of how the tiger, which looks so ferocious and so awesome, is really
an easy prey: it can be dispatched with a few bumps on the head. And the clan never tires of
hearing him.
Years later and like always, a group of men from the clan go out on the same mission. In their
search, they come across a tiger. And they know what it is: a creature that looks terrifying but is
really more defenseless than a pup. They exchange knowing smiles and set out to finish the job.
Except that this tiger is young and in top shape. The hunting group, or what remains of it, is
unpleasantly surprised.
A defective concept can be indeed dangerous. Lacking from these prehistoric mens concept of
Tiger were attributes to specify the state of the tiger: Old and Decrepit as opposed to Young and
Ferocious.
Instructors Manual

16

V VI II I. . N Ne ex xt t: : M Me et th ho od do ol lo og gy y
In introducing information systems, we repeatedly emphasized that software is a product and, as
such, its development requires a methodology that minimizes the risks of failure, maximizes the
quality of the product, and makes the best possible use of time, money and other resources. We
also presented some examples from research (Edison) and manufacturing (Ford) fields.
Information system development, however, is neither laboratory research nor assembly-line
manufacturing. In the relatively short lifetime of software development, various methods,
guidelines and methodologies have been put forward: rapid development, waterfall, lifecycle,
agile, et cetera. None have proved universally popular or eminently successful, and the rapid
change of technology and the economics of development (such as outsourcing) have pulled the rug
from under many of their underlying arguments.
In the next chapter, we shall discuss methodology. We shall also argue that an iterative and object-
oriented approach, combined with modeling, offers the best hope for software development
projects.
Instructors Manual

17

3
33.
.. M ME ET TH HO OD DO OL LO OG GY Y
What is methodology and why is it needed? This chapter starts with exploring the answers. It then
presents an overview of the most common concepts in software development methodologies. The
discussion is followed by a brief summary of project management concepts and tools.
Learn about methodology, its fundamental concepts and its building blocks.
Describe benefits and risks of methodology.
Understand what software development methodologies address.
Learn about the most common concepts in software development methodologies.
Describe modeling concepts and software development.
Understand project management concepts and tools.
METHODOLOGY, ITS FUNDAMENTAL CONCEPTS & ITS BUILDING BLOCKS
Methodology is a systematized interpretation of the past experience, and often new ideas for
improving on the past, that provides a set of methods, rules, procedures and tools to achieve a
goal. The need for methodology is not limited to the journey from the problem to the solution.
Depending on the complexity of the problem or the solution, various challenges call for
methodology: understanding the problem domain or the context in which the problem occurs and
the solution must work, creating the solution domain which contains elements that can be
unrelated to the problem but must be built to support the solution, assuring quality which means
making certain that the product works as expected, selecting among multiple solutions for the
same problem, selecting from multiple methodologies for the same solution, coping with
available resources and different contexts, and preparing for the consequences of the solution.
One methodology usually does not cover every aspect of development. A methodology may
address the stages of the development but be silent on the responsibilities and the organization of
developers. Another may address quality assurance but not modeling the requirements on which
the quality depends. Therefore, development often depends on employing methodologies in
parallel. When the theoretical frameworks of parallel methodologies prove to be incompatible, we
would have to resolve the resulting conflicts by bending or modifying one methodology or the
other.
In fields such as software development, methodology and technology are closely related and move
each other forward. The two, however, should not be confused: multiple methodologies often
target the same technology and the same methodology is sometimes applied to different
technologies.
BENEFITS & RISKS OF METHODOLOGY
If methodology is well-chosen, it can O offer a well-rounded approach to development because
any methodology, unlike private experience, is open to public scrutiny and public discussion on its
weakness and strengths, O standardize the development process and thereby make the
communication among participants in the development more effective and more reliable, and
Instructors Manual

18

O increase productivity and quality by promoting and fostering those personal traits that are
most favorable to the task at hand.
Unfortunately, no methodology is ideal or ever will be. Existing methodologies often overlook the
size of the project, the available resources or the context in which development must take place.
Most are too complex and target very large or complex projects. Some are more flexible and can
be adapted to the context (an undertaking that incurs its own costs and risks) and some are less
inflexible.
Nevertheless, undertaking a project without a methodology is much riskier than adopting a
methodology that might be less than ideal.
WHAT SOFTWARE DEVELOPMENT METHODOLOGIES ADDRESS
Software development consists of a wide spectrum of activities that individual methodologies
cover selectively and from different viewpoints. These activities can be broadly classified as the
following: O gathering requirements, O feasibility study,O domain analysis, O system
analysis,O design,O implementation,O quality assurance and testing, O deployment and training,
and O maintenance.
Whether these activities take place sequentially, iteratively, in parallel (when possible) or even
without a clear pattern, depends on the methodology. What is more, a methodology may not
recognize a certain activity as a distinct entity. Some methodologies, consciously and explicitly,
cover only one activity or a selected set.
THE MOST COMMON CONCEPTS IN SOFTWARE DEVELOPMENT METHODOLOGIES
There are too many software development methodologies for a meaningful summary. Certain
concepts, however, recur through most of them.
Ad hoc is an approach to development without an overall theoretical framework. What
distinguishes an ad hoc approach from a formal methodology is that the general flow of the
process is not defined by an overall philosophy, even though it might borrow individual tools,
methods, techniques and procedures from formal methodologies. Ad hoc relies heavily on the
ingenuity and the experience of developers in improvising and communicating.
System Development Life Cycle (SDLC) methodologies view development primarily as a project
management challenge, rather a technical one. The classic SDLC methodology is the Waterfall
Model that specified a set of sequential phases for software development: feasibility study, system
analysis, design, et cetera.
Prototyping proceeds on the basis of creating a working model of the essential features of the
final product for testing and verification of requirements. There are two types of prototyping:
incremental or evolutionary in which the same prototype is refined successively to arrive at the
final product, and the throwaway that discards the prototype after verification of its features.
In Incremental or Iterative approach, the product is built through successive versions that are
refined and expanded with each iteration. The Spiral Model combines the lifecycle approach with
prototyping and iteration. The result is a complicated approach that has nevertheless been very
popular with government projects since its focus is on risk management.
Rapid Application Development (RAD) is selecting techniques, methods, practices and
procedures that would result in faster development and shorter schedules. Nevertheless, the formal
RAD methodology has its own characteristics and guidelines. It views development as four distinct
phases: requirements planning, design (which includes prototyping if necessary), implementation
and maintenance (including enhancements).
Instructors Manual

19

Agile methodologies form a distinct but diverse category. Their common goal is being adaptive
rather than predictive. Furthermore, they generally (but not universally) consider upfront
documentation, upfront modeling, and upfront design as a waste of time. Extreme
Programming (or XP) is the best-known agile method.
The Capability Maturity Model (CMM) aims to measure the maturity of software development
process within an organization. For CMM, an organization fits into one of the five maturity models:
O initial (or ad hoc), where the organization lacks a stable environment and relies on the
capabilities of the individuals O repeatable where the organization has adopted project
management principles O defined where the workflow has been shaped into an engineering
process, O managed where product and process quality are quantitatively predictable and
O optimizing where the focus of organization is continuous process improvement.
Like CMM, ISO-9000-3, developed by the International Standards Organization, focuses on the
quality of the organization, not the product. Unlike CMM, an organization can belong to only one
of the two categories: those that pass its criteria, and those that fail them. It also requires yearly
certification.
Object-oriented development is not directly concerned with the organization of the project but
on the product itself, from conceptual to physical. It has three requirements: O an object-oriented
technology, O an object-oriented analysis and design, and O a project plan that is friendly to an
object-oriented approach. Object-oriented development covers most of the activities that we
described above, but is highly iterative. An expanded object-oriented development also includes
the following concepts: component-based development, architectural design, learning from
patterns, and a model-driven approach.
MODELING CONCEPTS & SOFTWARE DEVELOPMENT
As a methodology, modeling is the systematic representation of the relevant features of a product
or a system from particular viewpoints. Modeling is a super-methodology since the methods,
techniques and practices of modeling can be adapted and inherited by most other methodologies,
even if these methodologies are otherwise incompatible.
Modeling is not a single concept but refers to a set of interrelated concepts. An individual model
is an artifact, and modeling can mean individual techniques, methods or practices. Modeling
often uses a language composed of specialized notations and, last but not least, it is a
methodology that can have numerous implementations.
Software modeling is shaped by four interweaved factors: O how the real world is viewed, O how
software is defined, O the process of development, and O the modeling language. These factors,
are interweaved: a change in one factor can have a domino effect on others and the whole.
PROJECT MANAGEMENT CONCEPTS & TOOLS
Project management is the methodology for coping with risk by ensuring that O the goal of the
project is feasible, O the project has a realistic plan for reaching its goal, O we can track how the
project is proceeding, and O we can correct the course of the project if it deviates from the plan.
There is no single methodology for managing projects, but many overlapping and complementary
methodologies compete with each other.
We can define the project as a collection of related tasks that must be completed in a particular
order and within a certain timeframe to achieve a specific goal. The goal of a project must be
verifiable and the scope of the project defines the boundaries of the goal.
A projects lifetime is finite: it is not a continuous undertaking but has a beginning and an end. A
projects lifecycle is composed of five umbrella phases that in turn cover other steps or
Instructors Manual

20

activities: O scope the project, O develop the project plan, O launch the plan, O monitor the
projects progress, and O bring the project to a conclusion.
One major challenge in applying project management to software development is that a project
plan is sequential in concept, whereas software development is iterative in practice.
Organizations, including the organization of projects, tend to be more or less hierarchical and
vertical. On the other hand, development of new things, especially software development, tends to
be iterative and horizontal.
V VI I. . D Di is sc cu us ss si io on n N No ot te es s
GIFT HORSE OR NOT: LOOK IN THE MOUTH!
The following story, mocking the Scholastic approach to truth, has been quoted repeatedly:
In 1432, the brethren [in the seminary or the monastery] got into a serious quarrel among
themselves over the number of teeth in the mouth of a horse. For thirteen days the argument
raged without ceasing. All the ancient books and chronicles were fetched out, but no
mention of this subject was found.
At the beginning of the fourteenth day, a youthful friar asked his superiors for permission to
add a word. To the wonderment and the vexation of debaters, he beseeched them to commit
the indignity of looking into the open mouth of a horse and find answer to their
questionings.
Upon hearing this, the brethren were annoyed beyond anger. Joining in a mighty uproar,
they flew upon him, kicked his behind and quickly threw him out. For, they said, surely
Satan has tempted this novice to declare unholy and unheard-of ways of finding truth
contrary to all the teachings of the fathers.
After many more days of raging strife, the dove of peace descended on the assembly and, as
one voice, they declared the problem to be an everlasting mystery because of the unfortunate
lack of historical and theological evidence, and recorded their conclusion as such.
This story, which sounds like a Renaissance exaggeration, aims to prove the idiocy of medieval
way of thinking. The lesson, however, applies to any period, anywhere: methodology can lead you
astray badly. The brethren were simply following the most reputable methodology of their time:
learn from Authorities.
Considering that the learned men of medieval times seldom dared to venture outside their own
immediate locality and had little chance for observation or experimentation, the methodology is
not as irrational as it appears. The fact is, however, that Medieval Europe was not as closed-
minded as the Renaissance wanted it to appear.
THAT EXTRA BEDROOM!
Imagine that an architect is hired to design a three-bedroom house and a contractor is hired to build
it. After all parties agree on cost and time estimates, the client decides that three bedrooms are not
enough and decides to ask for a fourth one. Even though the actual construction has yet to start, the
impact of this requested change on the project is not negligible: the blueprints must be redrawn,
the extra cost must be incorporated into the budget, and the schedule must be revised.
Furthermore, imagine that the client had assumed that a three-bedroom house would, as a rule,
qualify for two bathrooms instead one. But the architect, mindful of the budget constraints
imposed by the client, had decided to forego the second bathroom. Again, to correct the
miscommunication, the architect must literally go back to the drawing board and the arrangements
with the contractor must be renegotiated.
Instructors Manual

21

Now imagine that changes are requested after the construction has begun: satisfying the new
requests would be either impossible or would cost the client dearly.
Throughout the book, we emphasize the importance of upfront analysis and modeling for
preventing the project from starting on the wrong foot.
CONTINUOUS PROJECTS?
A project is limited in time and its organization is ordered around a goal. On the other hand,
continuous enterprises, such as corporations, factories and government agencies are often
organized along functional lines: accounting, sales, production, human resources, etc.
In many cases, however, this distinction proves to be more conceptual than actual. A construction
company that specializes in the development of tract housing usually employs both organizational
approaches in its operations: each contract has to be organized as a project, but most of the
elements that constitute the individual projects belong to the continuous (functional) structure of
the enterprise.
Matrix organization is the term applied to an enterprises that combines (or try to combine) the
vertical properties of a hierarchical but continuous organization with the horizontal and goal-
oriented but time-limited organization of a project.
This organizational approach was successfully employed by NASA in the Apollo program and,
since then, has had its share of supporters and detractors, each group armed with their own arsenal
of arguments and anecdotes. But it is safe to say that some businesses are bound to benefit more
from the matrix approach than others. A movie studios lifeline consists of a series of movies
each of which must be organized as a project with a distinct beginning and an end. On the other
hand, it is difficult to see how a meat-packing factory can benefit from becoming a continuous
project (except when changes to its mode of operation are in order).
V VI II II I. . N Ne ex xt t: : G Ga at th he er ri in ng g R Re eq qu ui ir re em me en nt ts s. .
When we undertake to create a new product, we must first understand clearly what the product
must do. If we dont, we might end up with an excellent and sophisticated but utterly useless
product.
It would have been ideal if would could simply ask what the product must do and receive clear,
comprehensive and well-organized answers. Gathering requirements, however, is a long, arduous,
unglamorous and sometimes thankless task. We must become clever detectives that use charm,
cunning and insight to discover what is really required. And this is just the beginning: we must
organize, track and classify requirements in a manner that is comprehensible both upstream, to
clients, and downstream, to developers. In the next chapter, we will explore the challenge of
gathering requirements.

Instructors Manual

22

4
44.
.. G GA AT TH HE ER RI IN NG G R RE EQ QU UI IR RE EM ME EN NT TS S
Requirements identify the objectives that the information system must help its users to achieve.
Gathering requirements is an ongoing process that provides system development with features and
rules that it must implement to satisfy its objectives. The reliability and the correctness of
requirements are dependent on their sources, on the techniques that we employ to elicit and verify
them, and on their effective management.
Define requirements and explain the difference between Requirements discovery vs.
requirements gathering.
Classify requirements and learn about techniques for eliciting requirements.
Learn about different sources of requirements.
Learn about tasks that help managing requirements.
Learn about Walden Hospital Case History. This case history will be used throughout the rest
of this book as the main source of examples and models.
DEFINE REQUIREMENTS
Businesses build information systems to do something for them. Requirements express those
features of a product that enable its users to achieve specific objectives. Requirements are
whatever a product does and whatever a product has that its users need in order to reach their
goals.
REQUIREMENTS DISCOVERY VERSUS REQUIREMENTS GATHERING
Requirements discovery is a finite phase in the development process. It identifies the scope and the
major objectives of the product. A requirement gathering is an ongoing activity throughout most of
the project that defines what is needed to achieve the objectives identified by the discovery of
requirements.
CLASSIFYING REQUIREMENTS
Requirements are classified into two broad categories: functional (or behavioral) and non-
functional.
Functional requirements specify the behavior of the system and the constraints on that behavior.
They specify how the mission of the system is to be accomplished by achieving tactical goals.
Functional requirements are captured through use case modeling that will be discussed in later
chapters.
Non-functional requirements specify non-behavioral properties of the system and the
constraints on those properties.
Instructors Manual

23

TECHNIQUES FOR ELICITING REQUIREMENTS
Techniques for eliciting requirements have varying degrees of effectiveness and must be wielded
differently depending on the situation:
Interview is most flexible and direct tool for eliciting requirements. It also more prone to
misunderstanding and failure than any other technique.
Questionnaires are the second choice for requirements elicitation and the first choice for
requirements verification. The structure of questionnaires as elicitation tools are generally the
same as in interviews, but the flow is inflexible. As a verification tool, questionnaires are the
most traceable.
Elicitation workshops are the most powerful but also the most expensive tool for requirements
elicitation. Since they are very expensive, you must select participants carefully and help them
to help the workshop.
Field trips and observation provide valuable requirements where workflow is rich in action and
interaction. But you must be aware that the value of observing a workflow also depends on the
goal of the observation.
Models can be used to verify requirements. These models need not be formal blueprints for the
construction of the system, but can be any drawing or word-chart that the stakeholders can
understand. Mock-ups are one such modeling technique; they are approximations of the
systems user interface to elicit comments and requirements.
SOURCES OF REQUIREMENTS
The relevance and the reliability of the requirements are strongly influenced by their sources:
Sponsors are those who launch the project and decide its fate. They also set the scope and the
major goals of the product.
Domain experts are those who are the most knowledgeable about the areas of business activity
within the project scope. Domain experts may come from inside the enterprise or from outside.
Stakeholders are those whose interests are affected by the operation of the system. An
stakeholder may or may not use the system, but how the system operates would affect his or
her interests.
Users are those who directly interact with the system. They can be classified into two groups:
principals who participate in the business process, and operators who act as assistants to the
principals and usually perform a routine job. The analyst must consult both the principals and
the operators for user interface requirements
Legacy application and existing documents are a rich source of requirements and business rules, but
they must be evaluated with vigorously.
MANAGING REQUIREMENTS
Managing requirements is as crucial to system development as gathering requirement itself. To
manage requirements effectively, certain tasks must be performed conscientiously and accurately:
Document & update requirements.
Document sources.
Separate requirements into distinct units.
Uniquely identify each requirement.
Instructors Manual

24

Verify requirements & document verifications.
Prioritize requirements.
Classify requirements meaningfully.
WALDEN HOSPITAL CASE HISTORY
Walden Hospital, a once thriving medical center, has fallen on hard times. A new management
takes over and, to turn around the fortunes of the hospital, hires a business consultant to analyze
the problems and to draw a recovery plan. Among other things, the analyst makes a strong
recommendation for deploying an enterprise-wide information system to cut costs, streamline
operations and gain a competitive edge. (This case history will be used throughout the rest of this
book as the main source of examples and models.)
V VI II I. . D Di is sc cu us ss si io on n N No ot te es s
VIRTUAL DEFINITIONS
Asking questions out of context is certain to elicit wrong or irrelevant answers. The most
misleading terms and concepts are those that sound familiar or their meaning in one area overlaps
with their interpretation in another one. Take the concept of interview itself. What is an
interview? It is obviously not a technical term: television and radio programs are constantly
interviewing celebrities, politicians, persons-on-the-street, scientists, etc; employers interview job
applicants, police interviews suspects. If you ask a reporter about the purpose of an interview, the
responses can range from a humble entertainment to a lofty preserving history, but it is
unlikely that the answer would be gathering requirements.
If, however, you open a book on system analysis and design (such as this one) and start reading the
chapter on gathering requirements (such as this chapter), you would search for answers that would
make sense within the context of requirements gathering. For example: O When should we resort
to interviews instead of questionnaires? (In a TV program on a movie star, questionnaires would
not generate high ratings.) O Should we keep the text of the interview word-for-word, or should
we edit and reorganize it to relate to the projects objectives? O Should we ask an interviewee
about topics that are important to gathering requirements but are not within his or her area of
expertise? (Read short answers on the right.)
We should be able to learn about interviewing techniques by watching master reporters at work.
But the purpose of an interview decides both its format and its content. We are after discovering
and defining requirements, not entertainment, nor preserving history. (Confessions, though, are
sometimes useful.)
THE BATTLEFIELD TRIP
The vice president of purchasing & inventory of a manufacturing company asked us to help him
streamline and automate his operation. We met a few times, we talked, and we took notes. We then
decided that it was time for a direct observation of the workflow.
The VP introduced us to an employee who was responsible for acquiring and organizing a certain
part of the paper flow. She politely and pleasantly acknowledged our presence and our purpose
and the VP left us to conduct his daily business.
After a fruitful hour or so, a well-dressed man, red in face and in temper, descended on us. Who
are you and what are doing here wasting the time of my employee, he sneered. Not knowing the
man but suspecting that we have done something wrong, we mumbled half an explanation and a
fuller apology. You must go, was all the reply that we received.
Instructors Manual

25

We beat an undignified retreat to the other end of the hall and, still shocked, approached another
employee with whom we were on more friendly terms. In response to our inquiries, she told us
that the angry man was the VP of finance and hated the first VP passionately. He had probably
known, she ventured a guess, who we were and what we were doing there.
Less than a week later we were notified that our services were not needed for the moment
because unfortunately the first VP was no longer with the company. (A check for services
rendered was enclosed.)
Apparently, he had taken one misstep too many including the fact that he had not gone through
proper channels to authorize our field trip. We had become a collateral damage in the crossfire.
THE COST OF FAILING REQUIREMENTS
The widespread use of information systems by a vast variety of enterprises might lead one to
believe that developing information systems is a tried and true endeavor, results in products that
reasonably meet customer needs and are reasonably completed in time and within budget. Nothing
is further from the truth.
Latest available statistics paint a disturbing picture. The Standish Group, an advisor on risk
management for IT projects, maintains that over 30 percent of IT projects are canceled before they
are completed and more than 50 percent will cost over 198 percent of their original estimates.
According to the same source, the average success rate for IT projects is only around 20 to 30
percent based on the most optimistic estimate.
Other surveys cite various numbers for canceled projects, cost overruns and schedule overruns.
But no survey presents a uplifting view. No doubt, part of the problem is due to the complexity of
information technology and its rapid pace of change. And yet, there must be more to it.
According to the Standish Groups study on the root causes of the failure rate, three factors take a
heavy toll:
- Lack of user input:13%.
- Incomplete requirements and specifications: 12%.
- Changing requirements and specifications: 12%.
Other factors include unrealistic time frames (4%), inadequate staffing and resources (6%), and
inadequate technology skills (7%). However, the study shows that at least one third of
development projects fail for reasons directly related to requirements gathering, requirements
documentation, and requirements management.
On the other hand, the same study found that the three following factors were the most important
to the success of IT projects:
- User involvement: 16%.
- Clear statement of the requirements: 14%.
- Executive management support: 12%.
Unfortunately, shortcomings and errors in gathering requirements are costly and difficult to fix.
Most often, requirement errors are not detected on time; rather, they trickle down to the later
phases of development, where the time and the effort required to discover and solve them is 5 to
200 times more, depending on when the errors are noticed: design, implementation, testing or
maintenance:
[Leffingwell 2000, 7]
Instructors Manual

26

Relative Costs of Correcting Requirement Errors
Requirements
Gathering
Design Implementation Testing Maintenance
1-2 5 10 20-50 200
HUNTING REQUIREMENTS
Some enterprises seem to be locked in perpetual civil wars: a war between higher-ups and lower-
downs; turf wars; guerrilla campaigns by employees who are fearful of losing authority or job to a
new information system or to business reengineering. (They are not always wrong: any new
technology changes the power balance to some degree, and information technology has had an
earth-shaking impact.). The battles may not be apparent at first glance to the untrained eye.
Nonetheless, they are wars by other means. At best, the cooperation would be indifferent; at worst,
it will be spotty or misleading.
The decision to continue working under such battlefield conditions is an ethical and a practical
one. If you conclude that you can do some good (for yourself and/or the business) by staying, then
you should become hunters rather than gatherers. You do not have to employ unethical methods,
but must be inventive enough to get what is necessary to fulfill your mission. The Russian folk tale
below illustrates the point to some excess:
Three soldiers, discharged from the army, are making their way back home when they come across
a village. It is near dusk and the villagers are gathered in the public square before going home to
their suppers. The soldiers, starving after their long trek, go to each villager and ask for food. But
the villagers are wary of strangers and reluctant to part from their scarce supplies. So their
pleadings go unheeded.
At last, one of the soldiers calls out: All right! We dont want your food. But give us a pot and
some utensils and we will cook ourselves a tasty stone soup. Stone soup? Intrigued, the villagers
bring a big pot and even make them a fire. The soldiers ceremoniously select, argue over, and
wash some stones and drop them into the pot. When the water comes to boil, one of them tastes
the soup and declares that it is almost ready, but only, only, if they had some cabbage, it would
be really perfect. Villagers, becoming curiouser and curiouser, bring them some excellent cabbage.
Then the second soldier tastes the soup and states that some potatoes would do wonders. The
villagers bring them potatoes. And so they go down the list with onions, meat, butter, salt, et
cetera. At long last, they throw away the stones, inform villagers that soup is ready and, as a way
of giving thanks for the pot, invite them to partake of it. Villagers accept the invitation, and all
agree that this stone soup is indeed very tasty.
V VI II I: : E Ex xa am mp pl le es s
O A TEMPLATE FOR REQUIREMENTS GATHERING QUESTIONNAIRES
The following is a template for gathering requirements through questionnaires. You can modify it
to fit the needs of your project. At the minimum, the template also requires the following: the
name of the organization, project title, name of the respondent, and the date.
Template for Requirements Gathering Questionnaire
Title of the Questionnaire
Purpose.
A short explanation of what the questionnaire hopes to achieve.
Assumptions.
Define assumptions that relate to the entire questionnaire. Include references to previous interviews or questionnaires, if
Instructors Manual

27

applicable. Do not include assumptions that relate to one section or one question.
Terms & Definitions.
A definition of terms and acronyms that you have used in the questionnaire. Note that if definitions are in doubt, they must
become questions.
1. Section 1: Title.
If the number of questions is large, organize them by subjects into sections. Altogether, however, try to avoid large
questionnaires unless you expect the responses to be very short.
Background & Assumptions.
Explain the assumptions that relate to all questions in this section only.
1.2. Q: Question 1
If there are assumptions that relate to this question only, explain them before the question itself, preferably in declarative
format.
A: Answer 1
Some answers, such as yes/no, a set of values, or multiple choices, can be structured. Questions that belong to
this category are easier to answer, but leave a space for comments so that the respondent can qualify the answers.

1.n. Q: Question n
A: Answer n
Comments:
Any comment that the respondent may have on the subjects discussed in this section.

1. Section n: Title.
Background & Assumptions.
n.1. Q Question 1
A: Answer 1

O A TEMPLATE FOR REQUIREMENTS VERIFICATION QUESTIONNAIRES
The general format for questionnaires aimed at verifying requirements can be similar to the
template in Appendix A for gathering requirements. There is one crucial difference, however:
requirement definition must be stated as a declarative statement, not as a question. The respondent
is asked to accept or reject the definition, and to provide an explanation if necessary.
Template for Requirements Verification Questionnaire
Section 1: Title
ID Requirement True/False Comment
001 Requirement definition. For example:
The patient must have an
appointment before receiving a
medical service.
E E
For example, the respondent may comment that:
For an emergency patient, appointment is recorded
along with the treatment.
The result is that you must qualify the rule.

003 Requirement definition.
E E

Section n: Title
ID Definition True/False Comment
065 Requirement definition.
E E

Instructors Manual

28

Note that a questionnaire does not have to be in a rigid tabular format. The above is just an
example that illustrates the basic fields. You should come up with a format that does not look like
cells in a prison complex. For example, the reformatted question line below feels less confining,
event though it consumes more space:
001 Requirement: Requirement definition
Priority:
Low: E Medium: E High: E
True:
E
False:
E
Comments:

The ID of a requirement must stay the same during its lifetime. The moment that a
requirement is discovered, you must assign a unique ID to it. This ID must not imply any meaning
whatsoever. The order of requirements in a questionnaire need not follow the order of IDs, and if a
requirement is removed, its ID must not be reused.
O IEEE TEMPLATE FOR SOFTWARE REQUIREMENTS SPECIFICATIONS
Most large enterprises have documentation standards that you must follow if you work for them or
with them. But there are also certain domestic or international bodies that are reputable enough to
suggest standards. that are taken seriously by a wide section of the industry. The Institute for
Electrical and Electronics Engineers (IEEE, pronounced I-Triple-E) is such a body. In 1993, IEEE
published a documentation standard for software engineers:
IEEE Std 830-1984, "Guide to Software Requirements Specifications," IEEE Standards
Collection: Software Engineering. Piscataway, NJ: The Institute of Electrical and
Electronics Engineers, 1993.
This suggested guideline has become very popular in computer science and MIS courses because it
is not bound to any specific project or enterprise. IEEEs interpretation of requirements is rather
general: business requirements, rules, and user interface, hardware and software platforms
anything and everything that is required for an information system projects.
A search on the Web will provide you with a wide variety of examples and commentary related to
the IEEE 830 standard. In this appendix, we present a high-level outline of the standard.
Remember that any standard for documentation can only be a guideline: you cannot, and you
should not, begin from the first page and try to fill in every section and subsection until you reach
the last topic:
O Your software requirements specifications (SRS) may not be one document, and often is not.
The volume and the variety of the documentation might burst open any binding (or
permanently injure the person who tries to carry the document).
O Composing an SRS document is an iterative task: it is built gradually, usually in parallel by
different persons and groups.
O It is very likely that any predefined template would not fit the specific needs of your project.
You may need new sections and subsections for requirements that the project or the
enterprise finds especially important, even if the guidelines do not have predefined places
for them. Alternately, you may not need some topics. (However, when you settle on a
format, it is a good practice to leave the headings in place with a short comment on why it is
not needed.)
Instructors Manual

29

IEEE SRS Template
1. Introduction.
Topics under the introduction section provide an overview of the contents of the document.
1.1. Purpose.
Identifies the purpose of the document and its audience.
1.2. Scope.
Outlines what the product (software and hardware) is, what it will do, what it will not do (if necessary) and
the business domains that it will serve. (This topic must be very high-level: avoid any detail.)
1.3. Definitions, Acronyms & Abbreviations.
Provides a definition of terms, acronyms and abbreviations. If necessary, this section can refer to other
sources (business documents, for example), or a glossary included in the SRS.
1.4. References.
Documents referenced anywhere in the SRS, including title, author, date, etc. Like the previous topic, this
topic may simply point towards a REFERENCE section at the end of the SRS.
1.5. Overview.
An overview of the content and the organization of the SRS.
2. Overall Description.
Topics under this section provide a summary of the requirements that the product must satisfy and restrictions that
it must observe (for example, legal constraints). Topics in this section must serve as a background to the next
section, SPECIFIC REQUIREMENTS. Therefore, they must avoid detail.
2.1 Product Perspective.
Places the product in perspective with other products that it must work with, hardware or software including,
but not limited to, operating system, user interfaces, hardware interfaces, hardware requirements, software
requirements, communication protocols, backup, recovery, support functions, etc.
2.2 Product Functions.
A summary of the major functions of the product. The summary should be organized in a manner
comprehensible to the target audience.
2.3 User Characteristics.
A general description of target users, their expected level of expertise and the necessary training.
2.4 Constraints.
A general description of factors that would limit the functionality of the product, including regulatory
requirements, safety regulations, hardware and software limitations, reliability, et cetera.
2.5 Assumptions & Dependencies.
A list of assumption on which the validity of requirements depends, including hardware and software brands
expected by the product, plan of deployment, etc.

2.6 Priority of Requirements.
Describes what set of requirements are to be given priority and what requirements are slated for the future.
3. Specific Requirements.
This section specifies each requirement in detail. The statements must be unambiguous, clear, and consistent
enough for developers to design and build the system to exact specifications. Each requirements must be written in a
Instructors Manual

30

manner that a simple yes/no answer can verify it. (In intermediate questionnaires, however, the verifiers must be
able to qualify their answers with an explanation, as we illustrated in earlier this chapter.)
Depending on the target audience and the purpose, this section may be organized by user class, features, etc.
3.1 External Interface.
Provides detailed requirements on the products interfaces:
3.1.1 User Interfaces.
3.1.2 Hardware Interfaces.
3.1.3 Software Interfaces.
3.1.4 Communication Interfaces.
3.2 Functional Requirements.
Provides detailed requirements on functional features of the product.
3.3 Performance Requirements.
Provides detailed performance requirements. Performance requirements must be stated in measurable terms.
For example:
The number of users who can simultaneously use the system.
The speed (range) of transactions.
The quantity of transactions by a user class.
3.4 Design Constraints.
Specifies constraints imposed by standards, hardware limitations, development tools, et cetera.
3.5 Software System Attributes.
Specifies attributes that we described earlier under non-functional category. These requirement must be
stated in a manner that is verifiable. You may also have to qualify or cross-reference them by priority, since
requirements in this section may affect each other negatively.
3.5.1 Reliability.
3.5.2 Availability.
3.5.3 Security.
3.5.4 Maintainability.
3.5.5 Portability.
The above is not an exhaustive list. You may specify other features such as correctness, flexibility,
reusability, testability, etc.
3.6 Other Requirements.
Provides a detailed listing of requirements that do not fall into subsections above. If the entries in this
subsection grow large in number, you should categorize them.
4. Appendices.
Any document or glossary referenced in the SRS.
4. Index.
Provides an index to the document. Rely on your word processor for indexing, otherwise the pace and the volume of
changes to the SRC will exhaust you and make the index unreliable.
Note that all templates are merely suggestions. They must serve the project, not the other way around.
Instructors Manual

31

I IX X. . N Ne ex xt t: : D Do om ma ai in n A An na al ly ys si is s
Requirements gathering and analysis are intertwined activities. After the major features of the
product are defined and verified, we continue gathering requirements by starting domain analysis.
While requirements identify the features of the product, domain analysis places those feature in the
context of business domains. It discovers and defines business concepts that are relevant to the
information system or will affect the product when it is functional.
We will learn about problem space, the space where business problems reside, and the solution
space (or system space) where issues exclusive to the product must be resolved. We will also
explore the distinctions between requirements, problems, solutions as methods, and solutions as
products (and why such distinctions matter).
The results of domain analysis are a set of concepts: processes, functions, roles, business rules and
formulas. These concepts are then refined and developed into the building blocks and artifacts of
system analysis.
We will argue that an enterprise-wide information system needs well-rounded and multi-polar
concepts that go beyond the boundaries of individual domains, even if the system appears to the
members of each domain as a customized tool for its exclusive purposes.
Instructors Manual

32

5
55.
.. D DO OM MA AI IN N A AN NA AL LY YS SI IS S
Domain analysis identifies business concepts that will be refined into the building blocks of an
analysis model for the information system. Domain definition sets the boundaries of domain
analysis and a domain dictionary organizes its findings.
Understand the three components of problem solving and be able to distinguish between
Problem space vs. solution space.
Learn the difference between requirements vs. product specifications.
Understand domain definition and domain scope.
Identifying domain concepts for analysis and modeling.
Learn how to create domain dictionaries and domain catalogs.
Identifying and organizing business rules.
The mission of domain analysis is to explore, define, organize and verify this set of concepts:
processes, rules, people, objects existing or planned, across the enterprise or limited to a more
modest scope.
Domain analysis itself, however, requires an understanding of the concepts that relate to the nature
of problem solving. It also requires its own context, provided by domain definition.
THE THREE COMPONENTS OF PROBLEM SOLVING
Developing an information system is building a solution in answer to a problem, an opportunity or
a desire. While problem solving is often viewed as having a pair of components the problem
and the solution in reality it consists of three elements: the problem, the solution-as-method and
the solution-as-answer. Requirements, in the strict sense of the word, express the features that the
solution-as-answer must have. It remains to us to discover or verify the first two components.
PROBLEM SPACE VERSUS SOLUTION SPACE
The problem, the method (or the process) for solving the problem and the answer to the problem
operate in two distinct, but dialectically related spaces: the problem space and the solution space.
To build the solution, we must discover the concepts within the problem space (or the problem
domain). But the two spheres interact and affect each other. Therefore, we must also understand
how the solution will operate within the domain that gave rise to the problem in the first place.
REQUIREMENTS VERSUS PRODUCT SPECIFICATIONS
Products (or solutions-as-answer) are not the same as requirements. Requirements are the features
that a product must have, while many products can satisfy the same requirements. The factors that
decide in favor of one product against other are many: technology, preferences, cost, experience,
time, resources, etc. Without a comprehensive domain analysis, a product may satisfy all
requirements but fail nevertheless.
Instructors Manual

33

DOMAIN DEFINITION AND DOMAIN SCOPE
In search for business concepts, a well-defined and finite context is required so that domain
analysis would not spin out of control. Domain analysis identifies the boundaries of business
domains. A business domain is an sphere of related business activities that have shared rules and
concepts and are organized to achieve a goal or set of goals.
By identifying the scope of domains their major functions domain definition also provides a
framework for partitioning a complex system into conceptual subsystems.
IDENTIFYING DOMAIN CONCEPTS FOR ANALYSIS AND MODELING
Domain analysis is the process of discovering and organizing domain concepts. But domain
analysis for building an information system is not concerned with just any concept, and certainly
not with all concepts.
First, if necessary, it must analyze the requirements to distinguish them from accidental or
intentional product specification. Second, it must identify problems that these requirements are
supposed to solve. Third, it must identify the concepts within the problem. Last, but not at least, it
must discover concepts that may not be apparent by the requirements or the analysis of the
problem, but will affect the product nevertheless.
If the information system goes across domains, or will at some point, then concepts must be
expanded as well. An advantage of domain analysis is that it permits an application to be local
while the perspective of the whole system can remain enterprise-wide.
DOMAIN DICTIONARIES AND DOMAIN CATALOG
The findings of domain analysis must be organized as a dictionary. This dictionary, or its subsets,
allows the business stakeholders to verify the concepts and provides the development team with
building blocks for modeling.
Domain catalog is a consolidation of business documents (or references to them) that supports the
domain dictionary. It serves as an authority for settling issues related to the definition of domain
concepts.
IDENTIFYING AND ORGANIZING BUSINESS RULES
Business rules are a set of business concepts that do not readily fit within one model. As the name
signifies, business rules are the guidelines and rules under which a business must operate,
regardless of technology.
OPPORTUNITIES, DESIRES OR PROBLEMS?
Problems, problem domain, solutions, solution domain: throughout this book, and throughout the
literature on the subject, the impression is given that solving problems is what software
development is all about. Sometimes many times actually the driving force is a perception of
opportunity, the idea that, instead of fulfilling an existing demand, a product can sell in the
marketplace by creating a demand.
Many products are built hoping that the consumers would share the same perceptions of
problems as the creators. Edsel, the car that the Ford Motor Company introduced in 1957 and
failed badly in the marketplace, is often cited as a classic example. (In the U.S., late-night TV and
cable channels are saturated with products that solve problems that you never imagined you had.)
Instructors Manual

34

And yet, fashion designer do it all the time and the success rate for some is very high. Nor the
creation of computer games was driven by any specific problem, unless having too much time
on your hands is considered one.
In fact, many problems are not perceived until the solution is possible. Before word processors on
personal computers, there were typewriters, and everybody thought they were a marvelous
invention. Of course, the admirers were aware of many problems: the inconvenience of making
corrections to mistyped words, the severe limitation of typefaces even after IBM introduced its
electric models in 1961, limited number of legible copies using carbon paper, et cetera. But no
business ever thought of throwing away the typewriters and firing the typists. The idea that
affordable and convenient computers can solve the problems of typewriters was not even a gleam
in any businesss eyes.
Most celebrated architectural monuments, and many gaudy ones, were conceived in answer to a
desire: grandeur, beauty, faith, power, and what not. It would be a stretch to re-designate these
desires as problems.
Nevertheless, like others, we will continue to use the term problem. First, the process is the
same. Second, it reminds us that we have to find a solution and implement it as close to the
original vision as we can.
ISNT IT SIMPLER TO START FROM THE PROBLEM?
Whether the answer to the question above is positive or negative, starting from the problem is
usually not an option. No matter what lies behind the way human beings think, when we want a
new product or service, we commonly express the desire as requirements, not as problems: we
want a train that travels two hundred miles an hour, we want batteries that power our flashlights
for twenty-four hours, we want an application that enables us to sell books online, and so on and
so forth.
A problem (or an opportunity) is always the trigger for undertaking a project to build a new
product or service, but rarely do we formulate requirements as problems: existing trains run only
sixty miles an hour, none of the batteries in the market power our flashlights for more than two
hours, our applications do not sell books online, even though these problems lie behind the
requirements.
However, when we do have a product or service, the pattern is reversed. Now we complain about
the problem and demand a fix: this light bulb is burned out (get a new one), the engine heats up
fast (fix the cooling system), the service in this restaurant is too slow (we will never come back),
the application crashes when the customer selects more than ten books (find what is causing it and
fix the bug).
You might still think that the world would be a better place if people just gave us the problem and
left us alone to figure out the solution. Even then, you must place the problem in its context
(where), conceive the features of the product (what), and analyze how we can build a solution that
would work in that context. And, since features of the product are not handed to you, you might go
terribly wrong.
Imagine a bank asking you to solve a problem: its customer cannot conduct banking activities
twenty-four hours a days, seven days a week. You might come up with a solution: hire three
shifts of employees to work twenty-four hours a day (plus an enticing overtime rate for weekends
and holidays). It is questionable that any bank would accept such a solution nowadays. However,
if the bank expresses its wishes as we want an automated system that would serve our customers
twenty-four hours a day, every day, then at least one inappropriate solution is out the way.
[Leffingwell 2000, 33]
Instructors Manual

35

Repairmen need only to worry about fixing problems. Designers of products, services and systems
must satisfy requirement.
DICTIONARY TRAPS
There are two set of traps in the landscape of domain concepts:
O One Term, Multiple Concepts
The same label in the dictionary, can mean more than one thing. Appointment can be both a
process (a likely use case, the subject of the next chapter) and an object (a likely class): as a
process, it describes a series of steps grouped under a concept, while as an object, it signifies an
entry in a schedule, be it virtual or otherwise.
For the business domain, i.e. the hospital, this distinction is not crucial. For us, for our information
system, it is. We must distinguish, firmly, between the various types of domain concepts: for
modeling an information system, a process is very different from an object.
O Search for Perfection.
In tracking concepts, we can follow the wrong scent and lose the trail. Creating the domain
dictionary is the task of successive refinements. It is a tool and not an end unto itself. At each
phase of analysis, it must be good enough for that phase. It never needs to be perfect ever.
WHAT IS IN A NAME?
A well, according to the dictionary, is a deep hole or shaft sunk into the earth to obtain water, oil,
gas or brine. The oil company that had engaged us to set up an information system for its
operation unreservedly agreed with this definition of a well (or a variation of it, to be exact.) The
system was deployed successfully. It stayed online until, a few years later, a more successful and
aggressive company decided to buy our client out, for an attractive price. They asked us if we
could convert the data to a format acceptable to their information system. Sure, we replied, no
problem, and got to work.
Almost immediately we found a problem: the definition of well the most basic unit of
production for an oil company. They both considered it to be a deep hole in the ground. For the
first company, however, a well was any hole that produced petroleum. For the new owners, the
concept was more sophisticated: depending on a number of factors, a well could have multiple side
shafts to produce more at the same time. And they were keeping track of the production separately
for each side shaft and combined for all the connected ones. A well, for them, was not just one
hole.
A solution (a compromise) was found, and the data was converted eventually. It took longer and
was more expensive than predicted, but nobody could have prevented the problem.
THE LITTLE ENGINE THAT COULD?
Automated tools for managing business rules are appearing rapidly, but this very fact is a sign that
although the need is felt and the demand is rising, the products are not as mature or as easy to use
as one would like. Otherwise, a few of them would have dominated the market, as has happened
with most other modeling and development tools.
Any tool that is not integrated in a development environment would have difficulty gaining
acceptance: time and money are always in short supply. And developers are always wary of (real
or imagined) detours. A promising category of tools aims to integrate a rules engine with the
system and its services. The basic architecture of these tools can be described as follows: a
business rules authoring tool allows storing the rules and their metadata in a repository, which then
Instructors Manual

36

is used by an application through a rules evaluation engine. If these tools show their effectiveness
in the field a couple of success stories are not enough then software development would
have taken a great leap forward.
What about modeling? Unfortunately, as of now, UML does not have a standard model for
business rules. We may resort to stereotypes extension mechanisms to come up with our
own models. (Some have tried.) But lacking a standard means loss of productivity: the model has
to employ a private language that others have to learn and decode.
The decision to use (or not to use) a CASE tool is never about whether it is perfect or not. No tool
would ever be perfect for every situation, no matter what the vendors claim. One may give you
integrity at the price of flexibility. Another may do the reverse. The decision should be decided by
the best compromise: what the tool gives and what the tool takes away.
VERIFY THE VERIFICATION
Years ago, at the heyday of fourth-generation languages, we were working with a cosmetics firm
to develop a system for product tracking, from the inception of the idea to the market introduction.
A legacy system allowed the company to keep a list of products with a minimal amount of data
such as description, date of introduction and price. Since the company had thousands of products,
we were required to transfer the data from the legacy database to the new database to save labor
and prevent data-entry errors.
After a preliminary effort at gathering requirements, we presented the domain experts with a set of
business rules. Among them was one rule that stated: Each product is identified by a unique
SKU. (A Stock Keeping Unit or SKU is an ID, numeric or alphanumeric, of a particular product
that allows it to be tracked for inventory purposes. Sometimes companies build meaning into the
SKU. For example CA-TP-03-05 may mean toothpaste number 3 made at the facilities in
California, batch number 5.) Everybody agreed that this was a right and just definition.
We then decided to walk through the process we were not aware of use cases back then and
attend product development meetings to see things for ourselves. The staff were very helpful and
answered questions to the best of their abilities (which is certainly not the case everywhere).
Lacking an automated system for the task, the company was using printed forms to track product
development. The forms were very useful in understanding the workflow and the attributes of
products under development. But after a few rounds of meetings and leafing through forms that
were actually used, we noticed a curious thing: the SKU was never recorded as a single ID, but as
a series of numbers. If the space around the dotted line was short, yellow stickers where used.
We questioned the fact and got a very cheerful oh, that! answer. It turned out, however, that a
couple of things had gone wrong.
First, the legacy system had reserved only a two-byte integer (up to 32,767) for the SKU. This
number should have been enough, but the business had decided to reserve each set of numbers
within the range for a specific meaning (purchased or built, domestic or imported, lipstick,
cologne, et cetera). As a result, they had run out of numbers fast. To compensate for shortage of
numbers, they had resorted to reusing numbers that were supposedly unique (the legacy
application did not prevent duplicates). And to compensate for the duplication, they had added the
last two digits of the year to the SKU in documents to make the number unique.
Second, what the SKU identified was not in any case one product, but one base product or a
product group. If a lipstick was packaged in a container that came in different colors, then the SKU
identified the lipstick, and additional numbers were used to differentiate between colors.
Instructors Manual

37

The employees had shown real ingenuity in getting out of the box into which an outdated system
had forced them. They felt so at ease with their solution that it never crossed their minds that
something was not quite right. So they kept alive the myth that the legacy application was
representing a valid business rule.
D DO OM MA AI IN N D DE EF FI IN NI IT TI IO ON N: : R RI IS SK KS S & & L LI IM MI IT TS S
O A formal or time-consuming domain definition is not always necessary
For an enterprise-wide or complex information system, domain definition is essential but, if an
application has a limited and well-defined scope, we should not waste our efforts on discovering
irrelevant knowledge. This guideline, however, applies only to domain definition, not to domain
analysis: we must still identify and verify domain concepts and rules, regardless of how limited the
scope might be.
O The organization of a business does not necessarily correspond to preconceptions about
business domains
The bigger and the older a business is, the more likely it is that its organization is shaped by many
forces besides a purely rational arrangement of goals, workflow and people. These forces
include traditions, geography, legal requirements, experiments and personal preferences, among
others.
We have to do our bests to see the essence behind variations on the same theme. For example, a
company might organize its sales force in autonomous geographic divisions. Another might prefer
a unified sales management. For an information system, such administrative divisions do not
necessarily signal different domains. Unless what the divisions do are significantly different, the
differences should be reflected in class attributes, security constraints and application interface
not in the conceptual framework of the system
In the end, however, it is the information system that must work for the business, not the other way
around.
O The same business can be mapped into different domains by different analysts
Defining domains is a dialogue between us and the world outside us. The domains or sub-domains
that we arrive at as a result of this dialogue depend not only on objective reality, but also on our
predispositions, our experiences, our goals. Comparing the maps of various ERP vendors for the
same industry sectors illustrates the point. In one domain definition, Product Maintenance may
be combined with Sales, while in a second one its functions may be mapped to Customer
Management, and in a third definition it might stand by itself.
D DO OM MA AI IN N D DI IC CT TI IO ON NA AR RY Y: : E EX XP PA AN NS SI IO ON N & & T TR RA AN NS SF FO OR RM MA AT TI IO ON N
The example of domain dictionary in this chapter is one size fits all, which of course is not true:
it will break down under the weight of added complexity for each type. Besides, it might become
too long. So, depending on the complexity of the project and the length of the dictionary (which
may not be apparent at first), we can take one of the approaches below (or devise our own):
O Separate entries by type into mini-dictionaries
Advantages: it is easier to find related concepts.
Disadvantages: the reader has to know the type to find the entry. While this may be easy for an
analyst or a programmer, it might confuse non-technical stakeholders who have the final vote on
whether a business concept is correctly defined or not.
Instructors Manual

38

O Combine a simplified dictionary name, perhaps type and a very short description
with more elaborate mini-dictionaries
Advantages: the reader can find all concepts in one place in alphabetical order and needs to refer to
specialized mini-dictionaries for elaboration.
Disadvantages: takes more effort to create and maintain. It results in the duplication of definitions
between the dictionary and the mini-dictionaries which then must be kept in sync.
O A merger of the two: keep simple concepts in the system dictionary and develop mini-
dictionaries for more complex concepts.
Advantages: no duplication and flexible formats.
Disadvantages: a more arbitrary organization and, consequently, perhaps more confusing..
None of these approaches are perfect. The choice, again, depends. To illustrate tools and methods
as prominently as we can, we have taken the third approach. Preliminary domain dictionary is only
a start. As concepts develop towards an object-oriented model, we need to reorganize them.
And then there are CASE tools for gathering requirements. The jury is still out on whether these
tools can rise to the challenge of the passage from the blizzard of gathering requirements to the
more genteel surroundings of formal modeling. (They will, at some point.) But if you are using a
CASE tool, by choice or under duress, then no selection has to be made.
DOMAIN ANALYSIS: TAKE CAUTION!
O Merging various views of the same concept into a satisfactory whole cannot take place all at once.
An abstraction is always an approximation. Finding the right definition(s) is both horizontal and
vertical: it arrives by going across domains and sub-domains one by one, and through the
recursions of the modeling and the development process.
O An enterprise-wide domain analysis needs enterprise commitment and planning.
In reality, oftentimes it is the short-range goals that get priority. )Putting out immediate fires is not
always without justification.) Therefore, domain analysis is frequently a case of "best effort." If an
enterprise is vast if it is made up of many domains it might be beyond the scope of a single
project to correctly formulate concepts for the entire enterprise. Within the restrictions enforced by
the project restrictions of manpower, budget, time and leadership we should discover the
reaches of a concept as far as we can and design the solution in a flexible manner.
O External forces can unravel the most successful domain analysis.
Market forces, mergers and acquisitions can put an end to a business culture in short order and
scatter most of its concepts to the four winds. While this is no excuse for doing a poor job of
domain analysis, it is a reminder that, to the best of our abilities, we should expect the unexpected
in developing an information system. This is an oxymoron, but unfortunately true. In practical
terms, it means a maxim that is simple to say and difficult to do: the design of an information
system must provide for change.
DOMAIN ANALYSIS AND REUSE
In many discussions on domain analysis, you will encounter the term reuse. Some writers argue
that reuse is the primary benefit of domain analysis:
Domain analysis is an activity within domain engineering and is the process by which
information used in developing systems in a domain is identified, captured, and organized with
the purpose of making it reusable when creating new systems. [emphasis added.]
Instructors Manual

39

In the context of software development, reuse is overwhelmingly associated with components
that can plugged into various systems and applications with common functionality without having
to create the same capabilities each time. The component may be small: nowadays all development
tools offer a wide variety of components for building forms and managing data. Or it may large: as
we mentioned, vendors of ERP (Enterprise Resource Planning) software reuse subsystems to
create customized packages for diverse industries.
In the context of domain analysis, reuse applies not to cloning of identical components, but to
one instance of a concepts implementation. We need a couple of examples from the real world to
make this distinction clear.
A tire is a component of a car. Once a certain type of tire has been designed, tested and approved,
the manufacturing process instantiates as many copies as the business hopes to sell. From then
on, each tires life is independent of other instances, even though they are exact replicas and share
the same capabilities and defects. Leaving aside the differences between manufacturing and
software reproduction for the moment, a tire and a library of visual controls embody the same idea
of reuse.
No so with designing a mess hall for a military barracks. Can the hall be reused for breakfast,
lunch and dinner? Should we be able to reuse it for speeches and ceremonies? Is it big enough to
be reused by all personnel? Should we install vending machines so that people may reuse it at
irregular hours? The idea of reuse through domain analysis resembles the mess hall more than
the tire.
To be more accurate, multi-use is a better term in this context. Then why it is not used? The
answer applies to almost every term in software development: software industry selects terms as
much for its business appeal as for the expression of the concept behind it if not sometimes
more.
In the late 1990s, reuse was popular. Some time before that, integrated applications were the
rage. Some time after that, enterprise-wide became the all-purpose remedy. And when the
Internet started to become a mass medium, one company, perhaps tongue-in-cheek, advertised that
its computer displays were Web-ready. (Of course they were.)
V VI II I: : E Ex xa am mp pl le es s
O WALDEN MEDICAL CENTERS DOMAIN DEFINITIONS
Table below is a complete listing of domain definitions for Walden Medical Center. While this
decomposition of the hospitals activities is very solid, two analysts might parse the same business
differently. Compare our list of domains with that of SAP, a top supplier of enterprise-wide
software systems: http://www.sap.com/solutions/industry/healthcare/. SAPs solution is also
shaped by the fact that it has reused subsystems developed separately and shared with other
packages that have been customized for different industries.
Walden Medical Center
Domain Definitions
Version 1.0 July 19, 2006
Domain Scope Outline
Patient Management:

All activities that directly come into contact with patients fall within this domain,
including:
Referrals
Scheduling
Registration, Admissions
Instructors Manual

40

Treatments
Patient Relationship Management
Medical Records
Management:
Digital Lab Library,
Treatment Reports
Prescriptions
Doctors Notes
Test Reports
Drug Inventory &
Purchasing:
Pharmaceutical Inventory
Drug Supply Chain
Supplies Inventory &
Purchasing:
Inventory Management
Supply Chain Management.
(Note: this domain is very similar to the one above. Perhaps technically they can be
combined, but the rules and the domain managers are different.)
Medical & Lab Technology:
Medical Equipment Purchasing
Medical Equipment Inventory
Medical Equipment Maintenance
House Services:
Laundry
Cleaning
Food Preparation & Diets
Fixed Asset Management:
Inventory of Fixed Assets
Purchasing
Repair & Spare Parts
Environmental Health:
Waste Management
Occupational Safety
Environmental Training
Regulations Compliance
Transportation:
External Transport
Internal Transport
Scheduling
Transport Maintenance
Human Resources:
Personnel Administration
Payroll (managed by Accounting)
Time Management
Employee Development
Accounting:
In addition to items that nominally fall under other domains (like Payroll):
Accounts Payable,
Accounts Receivable
General Ledger
Tax Accounting
Outside Services & Contracts
Legal:
Corporate
Financial
Tax
Malpractice Suits
Legal Document Library
Corporate Finance:
Cash Management
Debt Management
Investments
Loans
Instructors Manual

41

Business Intelligence &
Decision Support System:
Stakeholder Relationship Management
Performance Measurement
Patient Relationship Analysis
Supply Chain Analysis
Revenue & Cost Analysis
Risk Analysis
Planning
O DOMAIN DICTIONARY FOR WALDENS PATIENT MANAGEMENT
Table below is the complete listing of the preliminary domain dictionary for Walden Hospitals Patient Management domain. A more
mature dictionary would be larger and would take into account how other domains view the same concepts.

Patient Management: Domain Dictionary
Version 1.0 August 15, 2006
Name Type Description
Admission
Process
Hospitalization of a patient. Hospital resources (bed, operating room & doctors)
must be available and scheduled for an admission. Arranged by the appointment
clerk.
Appointment Process
Scheduling of a patient to receive medical service(s). Performed by the
appointment clerk.
Appointment Object
The scheduled date and time for providing a medical service to a patient.
Appointment Clerk Role
Makes appointments for the patient.
Billing Clerk
Role
Produces individual patient bills on request; records payments; resolves billing
issues.
Doctor
Role
Provides a specialized level of medical services to the patient: diagnosis,
procedures and operations, prescriptions and monitoring of medical conditions.
Emergency Medical
Worker
Role
Refers the patient to the emergency room. Performs emergency medical services
before emergency room.
ID Card
Object
Is issued to patient as part of registration. Identifies patient to the hospital staff
for both medical and non-medical purposes.
Lab Technician
Role
Performs a test medical service: X-ray, blood test, MRI, etc.
Medical Record
Object
A document, in paper or electronic form, which records the results of a medical
service.
Medical Record
Management
Process
The process of creating, archiving and using medical records.
Medical Service Object
Any service of medical nature provided by medical staff to a patient: diagnosis,
prescription, administration of drugs, lab tests, etc.
Medical Service Function
The act of providing a medical service to the patient by medical staff.
Medical Service Cost Object
The cost of a medical service provided to the patient.
Medical Service Cost
Tracking
Process
Recording of the cost of a medical service. Is performed by the provider of the
service (medical staff) or assistants.
Instructors Manual

42

Name Type Description
Medical Staff Role
Any person who provides a medical service to a patient: a doctor, a nurse, a lab
technician, or an emergency medical worker.
Nurse
Role
Helps the doctor in providing medical services. Administers drugs and monitors
the patient.
Outside Hospital
Role
Refers patient for an appointment and medical service.
Patient Object
Any person who receives a medical service from the medical staff.
Patient Bill Object
An invoice in electronic or paper form which identifies the paid and the unpaid
costs incurred by the patient in receiving medical services.
Patient Billing Process
The action which produces a patient bill. Performed by the billing clerk.
Primary Care
Physician
Role
Refers the patient to the hospital to receive medical services.
Referral
Process
The act of referring a patient to the hospital for an appointment.
Referral Source Role
A primary care physician, an emergency medical worker or an outside hospital
that refers a patient for an appointment to receive a medical service. Patient
himself or herself can be a referral source.
Registration Process
Carried out before a set of medical services are performed. The process gathers
new or changed personal and insurance information for a new or an existing
patient. A hospital ID card may be issued as part of this process. Performed by
the registration clerk.
Registration Clerk Role
Performs registration.

V VI II II I. . N Ne ex xt t: : B Be eh ha av vi io or ra al l M Mo od de el li in ng g
Domain analysis paves the way from gathering requirements to an object-oriented analysis and
modeling. In turn, system analysis feeds back into domain analysis by demanding richer and more
refined definitions for concepts and scopes.
Instructors Manual

43

Use cases are the first step towards conceptual modeling. A set of related use cases provide the
behavioral model of a system. The boundaries of the system or the subsystem depicted by use
cases are defined by domain definition. The starting point of use cases are the concepts discovered
through domain analysis primarily, but not limited to, those categorized as processes.
In the next chapter we discuss how domain concepts are transformed into use cases and the basic
properties of use case modeling.

Domain analysis feeds conceptual
modeling, but is also updated and
refined through that modeling.
Instructors Manual

44

6
66.
.. B BE EH HA AV VI IO OR RA AL L M MO OD DE EL LI IN NG G I I U US SE E C CA AS SE ES S: : T TH HE E B BA AS SI IC CS S
Use case modeling represents the behavior of a system. A use case details the interaction of entities outside a
system, called actors, with the system to achieve a specific goal by following a set of steps called a scenario.
Use case modeling is the first step for transforming domain concepts into models for building a solution. A
use case is a textual narrative that details how one or more entities called actors interact with a system to
achieve a result that is primarily of value to one of them, the primary actor.
Describe what the use case modeling is and is not.
Describe the four components of a use case and the basic elements of use case diagram.
Learn about various flows in the narrative of a use case.
Understand how to transform concepts from domain analysis into use cases.
Identifying prominent actors and major use cases.
Learn about the context diagram.
I II I. . C Ch ha ap pt te er r O Ou ut tl li in ne e
WHAT THE USE CASE MODELING IS AND IS NOT
Use case modeling is a set of use cases that, together, describe the behavior of a system. A use
case is a unit of this model. It can also be defined as a contract between entities that have a stake in
the outcome of a use case, i.e., stakeholders, and the system.
Use cases do not model the internal workings of the system. They describe what the system does
but not how. They are not effective tools for capturing non-functional requirements. They are not
derived from successive divisions of a systems functions (functional decomposition). And they
are not inherently object-oriented.
THE FOUR COMPONENTS OF A USE CASE
A use case is a textual narrative, but it must have four well-defined components to qualify as a use
case: O a goal as the successful outcome of the use case, O stakeholders whose interests are
affected by the outcome, including actor(s) who interact with the system to achieve the goal, O a
system that provides the required services for the actors, and O a step-by-step scenario that guides
both the actor(s) and the system towards the finish line.
THE BASIC ELEMENTS OF USE CASE DIAGRAM
Use case diagram is a meta-model, an abstraction of use cases. In its basic form, it displays the
boundaries of the system, the name of the use cases, and the actors who interact with each use
case.
VARIOUS FLOWS IN THE NARRATIVE OF A USE CASE
The narrative of a use case is made up of one or more flows: O normal flow is the best-case
scenario that results in the successful completion of the use case; O alternate flow that is present
only if conditional steps are needed; O sub-flows if steps in the normal flow contain sub-steps;
O Exceptions that describe what may prevent the completion of one step or the entire use case.
Instructors Manual

45

HOW TO TRANSFORM CONCEPTS FROM DOMAIN ANALYSIS INTO USE CASES?
Domain analysis discovers and defines business concepts within the context of the problem space.
Use case modeling channels, transforms and expands these concepts into a model of system
behavior.
IDENTIFYING PROMINENT ACTORS
Domain analysis discovers entities that perform the same functions within the enterprise. These
entities are classified as role and are the prime candidates for designation as actors in use case
modeling. They qualify as actors if they interact with the information system that we plan to build.
IDENTIFYING MAJOR USE CASES
We arrive at major use cases by analyzing domain concepts marked as process or function.
But the conversion ratio is not one-to-one. A use case has features four required components
that a function or a process may lack. Sometimes we have to break up a process into more than one
use case; at other times we might have to combine pieces of multiple processes or functions to
arrive at one use case. Other domain concepts, such as objects or business rules might find their
way into use cases if the context requires it.
THE CONTEXT DIAGRAM
Context diagram describes the interaction of outside entities with a system, or subsystem, as a
whole. It is simple: it does not elaborate on the system behavior as use cases do. And it must be
kept simple to serve its purpose: verification of functions that the system provides and for whom it
provides.
Use cases are not natural phenomena. They are human artifacts and are shaped by human choices
and predispositions. A use case is a model in words, not a mathematical formula; nor it is an
engineering sketch. Hard as we may try, it would remain soft on the edges.
When we discuss use cases, we should remind ourselves of what Humpty Dumpty said in Through
the Looking Glass: When I use words, it means just what I choose it to mean neither more nor
less.
In keeping with this attitude, there is nothing about use cases that is not disputed. In the physical
implementation of an information system, different sides may agree to disagree: I like it this way
is often tolerated. Not so when use cases are involved. It is a flexible tool and an appropriate
subject for endless arguments.
THE SILENT ACTORS: ASSUMPTIONS
No matter how exact, a use case leaves some points to assumptions, cultural or otherwise. These
assumptions drive requirements gathering as well. In the latest version of Checkout Groceries,
somebody noticed that alcoholic beverages need special handling. And somebody else did not. In a
different cultural context, perhaps where alcoholic beverages are banned or are not sold in
supermarkets, obviously nobody would parse the use case for this purpose and find it wanting.
Assumptions are both a boon and an impediment. Without them, if such a thing is possible, the use
case becomes absurd with trivia. Try explaining grocery shopping to a Martian who does not need
food and is recharged by cosmic rays. At other times, we might leave out a crucial piece because
we might assume wrongly that everybody shares our assumptions.
Another example from the same use case: in many places, customers can pay by personal checks,
but here the possibility is not spelled out. Is it a simple oversight, is it because this particular
Instructors Manual

46

supermarket has decided against it, or is it because the analyst comes from a country where checks
are not trustworthy? Whatever the answer, the analyst must ask the relevant stakeholders to review
use cases for thoroughness and accuracy, often more than once, individually or together.
Judiciously, the analyst should view the world like a Martian but describe it like an earthling.
THE ORIGINS OF USE CASE MODELING
The concept of use case was introduced in 1986 by Ivar Jacobson, but the origins of it go further
back, to 1967 when he was working with a team at the Swedish firm Ericsson. There he introduced
a set of modeling concepts for the development of large telecommunication switching systems. As
Jacobson himself explains it:
The main concepts were signals and blocks. A real-time system is an open system
communicating with its environment by signals aloneThis view presents the system in a
very abstract way as a black box. A less abstract view on a lower level models the system
as a set of interconnected blocks. Blocks are modules which can be implemented in hardware
or software or any combination of both. [Emphasis added.] A block communicates with its
environment only through signals Hence the system can now be viewed as a set of
interconnected blocks jointly offering the functions of the system
Building on these concepts, he and his team developed a switching system that came online 1971.
(Its successors were eventually implemented in more than eighty countries.) The same view of
systems was also the basis of many object-oriented ideas that he continued to develop in later
years.
Use case modeling has proven itself to be one of those concepts that are brilliantly simple,
effective and enduring. (We are not using the term brilliant carelessly.) Its most attractive, and
essential, features is that it is independent of technology, which means that it will not become
obsolete in a blink of an ever-shifting technological eye.
MODELING, NOT DOCUMENTATION
Mention documentation to most software developers and watch them cringe. Documentation is
often seen as paper pushing a futile and pointless waste of time that is outdated before it is
event finished. At best, it is regarded as the bureaucratic equivalent to a traffic cop stopping you
and asking for your drivers license and your cars registration when you are trying to get to the
hospital as soon as possible.
What is sad is that they are right more often than not. Bureaucrats do love paper, and lots of it.
They take joy in long, leisurely walks along paper trails. Paper is tangible; paper is security; paper
is proof of a job done.
Inevitably, across this book, we talk about documents and documentation because they are the
most commonly accepted terms for recording language on paper (or on virtual paper), but they are
really models, or building blocks and raw material for models.
We may be able to build a shack without a model, but even a modest house worth its price needs
models, let alone a skyscraper. (Perhaps that is why many software applications remind one of a
ramshackle house.)
Requirements gathering provides specification for the product and raw material for modeling.
Domain analysis turns this raw material into modeling building blocks. And use cases are models
word models, but real models nevertheless. Done correctly, they can be as good a model as a
roadmap. In fact, they are roadmaps in words.
Instructors Manual

47

Developers would now bemoan the futile, pointless, bureaucratic demands for modeling. What is
sad is that, at least in some cases, they might be right.
UNCOVERING HIDDEN ACTORS
Grammatical objects in a sentence are good candidates for role-type domain concepts and, later,
actors. Sometimes, however, both the domain scope and the domain dictionary fail to identify who
exactly performs a function. In such cases, we have to read between the lines and then pursue the
matter. For example, in Waldens Patient Management domain scope, Patient Billing might
have been described as follows:
Regular patient billing is done on a monthly cycle. However, billing for a particular patient
may be done on demand. Sources of payment are the insurance company and/or the patient
(credit card, cash or subscription). If the amount is small, usually for co-payments, the patient
is asked to pay before or after the service to save billing costs. Charity cases are not billed.
Who produces the statements? We have to ask because it is impossible to infer the role from the
document. The answer may be Billing Clerk or Accounting Clerk. If we persist about the other
duties of this actor, we may also find out that this clerk also records payments and resolves billing
issues.
USE CASE DEFINITION(S)
It seems that an entirely well-rounded, or commonly accepted, definition of a use case does not
exist. As we shall argue below, this lack of a strict definition directly results from the nature of use
cases, not from any human failure.
The following example is from Ivar Jacobson, to whom we are indebted for the very (great) idea of
use cases:
A use case is a specific way of using the system by performing some part of the functionality.
Each use case constitutes a complete course of events initiated by an actor and it specifies the
interaction that takes place between an actor and the system. A use case is thus a special
sequence of related transactions performed by an actor and the system in a dialog. [Jacobson
1992, 159]
And from the same book:
A use case is a particular form or pattern or exemplar of usage, a scenario that begins with
some user of the system initiating some transaction or sequence of interrelated events. [Larry
L. Constantine in Jacobson 1992, viii.]
In a later book, with we find the definition changed to a more concise one:
A use case is a sequence of transactions in a system whose task is to yield a result of
measurable value to an individual actor of the system. [Jacobson 1995, 105]
In a still later one (with Jacobson as coauthor), the definition is has a slightly different tilt:
A use case is a description of a set of sequences of actions, including variants, that a system
performs to yield an observable result of value to an actor. [Booch 1999, 222]
Another writer has a different take on the definition:
A use case captures a contract [emphasis added] between the stakeholders of a system about
its behavior. The use case describes the systems behavior under various condition as the
system responds to a request from one of the stakeholders, called the primary actor.
[Cockburn 2001]
Instructors Manual

48

The quotations can go on, and we can add a few variations from this very book.
The definitions, however, they are not so much incompatible as they are after a subtle goal:
pinning down a concept that must be viewed from different angles to be grasped.
Even though use cases are written in a linear narrative, what they represent has more than one
dimension. We can define the use case as a flow in time. We can see it as an structure that contains
time. We can view it as a set of transactions that do take place in time, but are atomized like
Instructors Manual

49

clauses in a contract. We can focus on the goal and the implications of reaching the goal. We can
concentrate on actors and how they weave in and out of the play. Or we can gaze on the system
the black box to gauge its actions and reactions.
Since no one definition can satisfy all views, and then more than one is needed.
ARE USE CASES USEFUL?
Do we really need use cases? No doubt this book believes so, or we would not have written this
chapter. But do we really truly need them? After all, textbooks are notorious for talking long on
subjects that in the real world would elicit short, derisive, dismissive laughter. We know that use
cases take too much time. For a really large project it makes sense. But for a small project? How
many chefs and waiters are needed for an intimate dinner for two?
Why should we spend so much time to tell the clients what they already know their jobs? Let
the users tell us what they want in simple stories so we can start designing right away. If there are
obstacles we dont deny that there would be then a knowledgeable client representative who
is embedded with the development team would clarify things.
A really useful question is: who is asking the question? Programmers are not made from the same
mold and do not come from the same tribe, but from the moment that somebody tried to create
order out of the chaos of software development, somebody else, usually a programmer, protested.
The same objections were made against early structured analysis that are now made against object-
oriented analysis. To summarize: irrelevant at best, a waste of time at worst.
Often, when object orientation is praised we are all object-oriented now! it is a praise for
the technology, for the languages, the libraries and the coding tools, not for the objected-oriented
development. (How the technology is used in practice is another story.)
Use case modeling is just one tool in the modeling toolbox. Depending on the project, it can be
more important or less important. The question really truly is: is modeling useful? It is a legitimate
question because the objective of software development is the software, not the model.
The answer lies not in purely logical and theoretical arguments, but in the decades-long experience
of system development, of its failures and its successes.
The technology provides new capabilities and expectations for creating ever-more complex
systems. Analysis methods and modeling tools are constantly refined to better answer the
challenge. They are not perfect, nor will they ever be. Modeling concepts and tools, including
UML and UML-based tools have blind spots. They must also continuously play catch-up with new
technologies and new requirements. Some tools are better than others for some tasks rather than
others. But ad hoc would not do, even if the technology is object-oriented. Ad hoc under any other
newly-coined seductive name is still ad hoc.
What happens in real world is often this: development starts without any worthy attempt at
gathering requirements or at modeling. It might be the professionals who convince the business
that it is better-cheaper-shorter without analysis, or the business is blissfully unaware of the need
for it, or the business thinks that it can cut corners without serious consequences. So the project
stumbles on, is revised constantly at great expense, realizes some part of the vision (vague as the
vision was to start with) and stops, either due to exhaustion of the business or the exhaustion of the
budget. And sometimes it does not stop, but just fades away.
Hard to believe, but in many development efforts it is the application that becomes the tool for
gathering requirements not its end product: Lets write the program and show them; we can
change it later.
Instructors Manual

50

This has become the normal state of affairs so much so that any intrusion of a methodology
seems abnormal, if not an abomination. That is why use cases are downgraded to really big
projects like building colonies on Moon or cutting a trans-Atlantic tunnel.
Small projects? Nobody will force you, in the privacy of your home, to follow a methodology. A
tool shed or a sand castle do not need engineering drawings. Some small projects are indeed
successful without formal analysis and modeling. The catch is that in an enterprise, applications
may start small but they rarely stay small. In a real business you will find many well-intentioned
time bombs ticking away quietly:
Fast-and-dirty programs that were supposed to be of short duration and application but are
now being promoted, like a personal address book that aspires to become a company-wide
contact manager.
Applications that for years miraculously do their work or their users believe that they do
but now have to be opened up: for integration, for change, or simply because they suddenly
and mysteriously stop working. No one can suggest a reliable strategy for dealing with them
because they are truly black boxes: we cannot see anything inside them. The original
programmers are gone; the original business people are gone. The application now resembles
an alien artifact.
Countless spreadsheets hiding programs that can cost the business millions if they go wrong.
Nobody can trace their origins or explain their workings but somebody wants to incorporate
them into an enterprise-wide system. Financial and statistical analysts spew forth such
handiworks at an alarming rate with impressive and ingenious formulas. Then mere mortals
have to search cell to cell, spreadsheet to spreadsheet, directory to directory to extract the
wisdom that is so well-concealed.
When the time comes to unravel these mystery applications, we must resort to archaeology (called
reverse engineering) and archaeology is appropriate for lost civilizations, but very expensive for
information systems.
An information system, even a small one, is either complex to start with or will become complex
over time. An information system without blueprints is defective, even if it works. Use cases
provide one set of these blueprints. Developing software is about software, not about models.
Neither are cars, airplanes, drugs, bicycles, television sets, buildings and countless other products.
But does anybody make them without some type of modeling?
So, at last, are use cases really useful? Yes. Without a doubt. Most of the time.
V VI II II I. . N Ne ex xt t: : D De ev ve el lo op pi in ng g U Us se e C Ca as se es s
This chapter illustrated how we can discover major actors and use cases. Initial use case are very
short and more or less free-format, but use cases have to be structured to become truly useful as
models. They must also contain enough detail to guide development.

Instructors Manual

51

In the next chapter we will first develop base use cases. They are called base because they will
form the basis for a variety of analysis and design artifacts. We will first give a more formal
organization to the use case by structuring it into a template. The template would make a use case
both easier to understand and easier to write by establishing what is required of it as a model.
Along with this structuring, we will expand the flows and discover actors that are hidden behind
prominent actors.
Once we have our developed the base use cases, we need to consolidate and reorganize them. We
will observe that by analyzing expanded use cases, we can discover new use cases that are
associated with the major ones. We will also discuss how to remove redundancy by refactoring
common functionality among various use cases. Even though both actors and use case are
themselves abstractions, it might become necessary to abstract them even further through
generalization.
Finally, we need to elaborate use cases beyond their basic structure. Documents derived from such
an elaboration extend the logical thread of use cases into details that are required for the later
activities of development.

Instructors Manual

52

7
77.
.. B BE EH HA AV VI IO OR RA AL L M MO OD DE EL LI IN NG G I I D DE EV VE EL LO OP PI IN NG G U US SE E C CA AS SE ES S
By defining the behavior that the users expect from the information system, use cases form the
foundation of conceptual modeling. To serve as such a foundation, use cases must be fully
developed, rigorously structured, and precisely refined into the building blocks of a reliable
behavioral model. Use case templates provide the tool for structuring the flow and the attributes of
use cases, and use case diagram creates a visual index for the model. To be effective as a
behavioral model of the system, use cases must be formalized and expanded. An unstructured
textual narrative is prone to misunderstanding and cannot guarantee that the use case has all the
required elements. For use cases to work as guidelines to development, they must be structured.
Learn about structuring & developing use cases through templates.
Understand generalizing actors.
Describe extending use cases as well as reusing use cases.
Understand use case generalization.
Learn how to create Use case diagram.
Learn how to divide and join use cases.
Learn about activity diagrams.
Describe a framework for development and deployment.
Learn about use case supplements.
STRUCTURING & DEVELOPING USE CASES THROUGH TEMPLATES
A formal template ensures that O a use case has the necessary building blocks and O it can
communicate its scenario and attributes clearly. Use case template is composed of a set of fields,
one for each building block: name of the use case (its goals), a summary, primary actor, supporting
actors, stakeholders, state of the system before the use case can start and after it completes, flow of
events in discrete steps, et cetera.
GENERALIZING ACTORS
An actor is an abstraction of real users. Customer generalizes selected attributes of real people
who purchase goods and/or services from a business. But even these abstract entities may need to
be generalized further if they share the same role with other actors in a use case: in conducting the
affairs of an airplane, Chief Pilot (the captain) and Assistant Pilot have distinct roles, but when
one of them has the controls and actually flies the plane, it is one primary actor, Pilot, who follows
the script of a Fly Boeing 747 use case.
Sometimes, however, we end up with generalized actors through a reverse process: specialization.
Through expanding use cases and gathering requirements, we may find that an existing role is
appropriate for certain use cases, but not others: during pre-flight check of the airplane, Pilot is not
enough; Chief Pilot is needed to read off the checklist and Assistant Pilot is needed to check off
the items.
Instructors Manual

53

EXTENDING USE CASES
When developing use cases, we may discover that some functionality has been left out: we
expected the customer to pay by cash, but we find out that the business accepts credit cards as
well. Instead of rewriting the use case, we can create an extending use case and add a
conditional step to the base use case that branches to the new one if the customer decides to pay
by credit card.
This type of dependency is called an extend relationship and adds flexibility to maintaining use
cases. The catch is that the normal outcome of the base use case must not depend on the success or
failure of the extending use case.
REUSING USE CASES
To reach its goal, a use case may need to call on the services of another independent use case,
either because the latter already exists, or it qualifies as a full-fledged use case by itself and cannot
be merged with the first one. This type of dependency is called an include relationship, and allows
a use case to remain concise and focused without relinquishing any of its function.
The include dependency does not have the limitation of extend relationship: it may be used
conditionally or unconditionally, but it adds to the burden of maintenance, because changing one
use case may affect many others.
USE CASE GENERALIZATION
If two or more use cases achieve the same goal through different means but share most activities,
we may consider abstracting their common feature into a generalized super-use case (also called
the parent.) The children use cases are then recomposed to show where they inherit features from
the parent, where they override (or specialize) them, or when they add new features.
Since use case generalization is maintenance-intensive, we may instead consider other techniques
such as include, extend and refactoring.
USE CASE DIAGRAM
Use case diagram is a visual meta-model: it does not model the use case itself, but the associations
between actors, use cases and the system. It also depicts extend and include relationships
between use cases and provide us with a visual table of contents.
DIVIDING AND JOINING USE CASES
A use case is defined by one primary actor, one useful goal and one system. In other words, if a
use case has more than one strong candidate for primary actor, or aims at more than one
(complete) useful goal, or models the behavior of more than one system or subsystem, it must be
broken into more than one use case.
There are, however, other reasons for dividing use cases or joining them wholly or partially: A use
case may become too complex to understand and manage, or the discovery of common
functionality among multiple use cases may require that reusable use cases be created. The
mechanisms of extend and include are then used to relate separated or recombined use cases
back together.
A use case may be divided vertically by consolidating parallel steps within a use case into another
use case, or horizontally by taking out a set of steps. Refactoring is a special case of horizontal
division in which a set of steps common to multiple use cases are extracted and joined.
Instructors Manual

54

ACTIVITY DIAGRAM
Activity diagram is a general-purpose diagram for visualizing and verifying a logical flow. For a
use case with a complicate alternate flow, activity diagram is a very helpful tool. Its simplicity
especially facilitates communications between development stakeholders.
A FRAMEWORK FOR DEVELOPMENT AND DEPLOYMENT
The main mission of use case modeling is to model the systems behavior from a conceptual
viewpoint. Its impact, however, goes far beyond that. Use cases provide a framework for
discovering business objects, designing user interface, incremental development, user
documentation and application help, test case definition and training.
USE CASE SUPPLEMENTS
A use case should not go into a level of detail that would blunt the thrust of its narrative. However,
the more we gather requirements, and the closer we come to implementation, the more we need
containers for organizing details. By creating supplemental documents, we can keep the relatively
simple framework of use cases and, at the same time, satisfy the need for elaboration.
THE CHRISTMAS TREE TEMPTATION
Use case is an effective tool in doing business with complexity. But like any effective tool, it is a
double-edged sword: it can be used, abused and misused. Instead of handling complexity, it can
become a dark agent of it.
The use case method offers great flexibility for adopting to very different needs and contexts. And
herein lies the temptation. A use case may seem like a convenient container to store every tidbit of
information that might become handy along the way. And for every additional ornament, you are
likely to find support in a voice of authority sent forth from books, articles and Web forums: this
item is a must; that set of icons adds so much clarity to your use cases; and if you distinguish
your use cases by adding a dash of color, you have distinguished yourself among your peers. At
some point the weight of embellishments may cause the branches of this Christmas tree to break or
the tree to tumble.
It is quite legitimate to adopt use cases to solve problems at hand. It is not wise to let them lose
their purpose.
V VI II I. . E Ex xa am mp pl le es s
WALDEN USE CASES
O O R Re eg gi is st te er r P Pa at ti ie en nt t. .
Register Patient has most of fields that a use case might have. In other words, it is a typical use
case (as far as use case can be typical).
Use Case: Register Patient
ID: 140
Scope: Patient Management
Priority: 1/5
Summary:
Registration ensures that a patients most current personal and insurance data is available to
the hospital before any medical service.
Registration also provides the patient with a hospital ID card.
Primary Actor: Registration Clerk
Instructors Manual

55

Supporting Actors:
Stakeholders:
Patient: needs the service provided by the hospital.
Medical Staff: need to ID the patient to provide medical services.
Accounting: needs to have the insurance plan.
Generalization:
Include:
144: Issue Hospital Card
145: Verify Insurance Plan
Extend:
Precondition: The reception clerk has verified that the patient has an appointment but needs to register.
Trigger: The reception clerk directs the patient to registration clerk.
Normal Flow:
1. The registration clerk enters or updates patients personal data.
2. The registration clerk enters or updates insurance information. (Include: 145 - Verify Insurance
Plan.)
3. The registration clerk issues hospital card for the patient. (Include: 144 - Issue Hospital Card.)
Sub Flows:
1.1 The registration clerk enters the Social Security Number of the new patient.
1.2 The registration clerk enters or updates patients address.
1.3 The registration clerk enters or updates patients phone number.
1.4 The registration clerk enters or updates the name, the address and the phone number of the
patients closest relative.
Alternate Flow/
Exceptions:
1.a The patient is not new and personal data has not changed. Registration clerk does not update
personal data by default.
2.a The patient is not new and insurance data has not changed. Registration clerk does not update
the insurance data by default.
3.a The patient is not new and has a hospital ID card. No new ID card is issued.
Post-Condition: The patient is registered and is provided with a hospital ID card.
Open Issues:
I.1 If the patient has no health insurance, what should be done?
I.2 How the (future) subscription plans are to be handled?
I.3 How emergency room cases are to be handled?
I.4 How charity cases are to be handled?
Source:
Interview with M. Miller, Director of Patient Management.
Notes from patient records in accounting. (Title: Notes on Personal & Insurance Data on
Patients.)
Author: J.W. Carroll
Revision & Date: 1.0 10/01/2004
O O R Re ec ce ei iv ve e P Pa at ti ie en nt t. .
This use case is a good example of use cases that do not appear at the initial stage and are
discovered through iteration and a close reading of other use cases. In this instance, the analyst
noticed that no activity connects appointment with registration and/or medical services.
Receive is a weak verb that we advised against. Admit Patient could have made a better
name for the use case, except that it would have been confusing since admission means
hospitalization to the hospital. The context is never less important than the rules.
Use Case: Receive Patient
ID: 130
Priority: 2/5
Summary: When the patient arrives at the hospital for a medical service, the reception clerk verifies that the
Instructors Manual

56

appointment is correct. The reception clerk also ensures that the patient is registered before a medical
service is performed.
Primary Actor: Reception Clerk
Supporting Actors: Registration Clerk
Stakeholders:
Patient: needs the service provided by the hospital.
Medical Staff: need to perform medical service.
Generalization:
Include:
140: Register Patient
Extend:
Precondition: The patient has an appointment for a medical service.
Trigger: The patient arrives at the hospital and is directed to the reception desk.
Normal Flow:
1. Patient informs reception clerk of the appointment.
2. Reception clerk verifies that the appointment exists.
3. Reception clerk verifies that patient has been registered and registration is valid.
4. Reception clerks directs patient to the appropriate medical service.
Sub Flows:
Alternate Flow/
Exceptions:
3.a Patient is new. Reception clerk directs the patient to registration. (Include: 140 - Register
Patient.)
3.b Patient is not new but personal or insurance data has changed. Reception clerk directs the
patient to registration. (Include: 140 - Register Patient.)
3.c Patient has lost the hospital ID card. Reception clerk directs the patient to registration. (Include:
140 - Register Patient.)
Post-Condition: The patient is directed to the medical service.
Open Issues:
I.1 What if the patient does not have an appointment but it is an emergency?
O O V Ve er ri if fy y I In ns su ur ra an nc ce e P Pl la an n. .
This use case illustrates two concepts:
O The role of the supporting actor (Health Insurance Provider) in helping the primary actor.
O How a use case can use the services of another system outside its scope: supporting actor in
this use case is actually an independent system by itself.
Use Case: Verify Insurance Plan
ID: 145
Priority: 3/5
Summary:
The registration clerk verifies the patients health insurance plan.
Primary Actor: Registration Clerk
Supporting Actors:
Health Insurance Provider
Stakeholders:
Hospital: needs to receive payment for its services.
Health Insurance Provider: will pay for medical services.
Patient: wants to receive medical services.
Generalization:
Include:
Extend:
Precondition: Hospital needs valid health insurance plan for the patient.
Trigger:
Normal Flow:
1. Registration clerk asks the patient for health insurance card.
Instructors Manual

57

2. Registration clerk sends data to the health insurance provider.
3. Health insurance provider verifies that the insurance plan is valid.
Sub Flows:
Alternate Flow/
Exceptions:

Post-Condition: Patient health insurance plan is verified.
O O M Ma ak ke e A Ap pp po oi in nt tm me en nt t. .
Make Appointment is a use case without a precondition. The hospitals information system does
not need to be prepared for an appointment, because patient referral is outside its scope.
Use Case: Make Appointment
ID: 120
Priority: 1/5
Summary: A referral source decides that a patient needs a medical service from the hospital and calls the hospital
for an appointment. The appointment clerk records the referral source, personal and contact
information about the patient and makes an appointment.
Primary Actor: Appointment Clerk
Supporting Actors:
Stakeholders:
Referral Source: wants to make an appointment for the patient.
Patient: needs the appointment to receive medical service.
Medical Staff: must perform the medical service specified by the appointment.
Generalization:
Include:
Extend:
141: Create Patient.
Precondition:
Trigger: The referral source calls the hospital for an appointment.
Normal Flow:
1. Appointment clerk verifies that the needed medical service is provided by the hospital.
2. Appointment clerk records patients personal and contact data.
3. Appointment clerk records information about the referral source.
4. Appointment clerk consults hospitals schedule to find a free slot for the required medical
service.
5. Appointment clerk verifies that the patient is available for the appointment.
Loop 1: Repeat steps 4-5 until hospitals schedule matches patients availability.
6. Appointment clerk makes the appointment.
Loop 2: Repeat steps 4-6 for each appointment.
Sub Flows:
Alternate Flow/
Exceptions:
2.a Patient is not on file. Create new patient. (Extend: 141 - Create Patient.)
Post-Condition: An appointment is made for the patient to receive a medical service.
O O R Re ef fe er r P Pa at ti ie en nt t. .
In this use case, the primary actor, Referral Source, and the supporting actor, Clerical Staff, are
generalized actors which were discussed under Actor Generalization. Refer Patient is also a
good example of use cases that are not automated, but are necessary to make the business flow
clear.
Use Case: Refer Patient
ID: 100
Scope: Medical Services Outside Walden Medical Center
Priority: n/a
Instructors Manual

58

Summary: A referral source (a doctor, etc.) decides that a person requires the attention of the medical services of
the hospital. The referral source refers the patient to the hospital for an appointment.
Primary Actor: Referral Source
Supporting Actors:
Clerical Staff
Stakeholders:
Patient: needs a medical service.
Hospital: offers medical service to the patient.
Generalization:
Include:
Extend:
Precondition: A patient suffers from a medical condition.
Trigger: Referral source examines the patient.
Normal Flow:
1. Referral source decides that the patient needs the attention of a medical service.
2. Referral source verifies that the hospital offers the required service.
3. Referral source refers the patient to the hospital for an appointment to receive medical
service(s).
Sub Flows:
Alternate Flow/
Exceptions:
3.a Referral source is the primary care physician (PCP) or an outside hospital:
Referral source sends required information and documents, including medical history, to the
hospital.
Referral source makes an appointment for the patient or instructs the patient to call the
hospital for an appointment.
3.b Referral source is the emergency medical worker (paramedic). The emergency medical worker
brings the patient to the emergency room. The appointment is done on an emergency basis.
Post-Condition: The patient is referred to the hospital for an appointment.
Open Issues:
I.1 Can a patient refer himself or herself to the hospital? If yes, what information is required?
O O R Re es so ol lv ve e P Pa at ti ie en nt t B Bi il ll li in ng g I Is ss su ue e. .
This use case illustrates actor generalization, but even though the primary actor (Hospital Clerk)
is generalized, the child actors keep their identity: the Non-Behavioral Requirements field states
that only Billing Clerk may accept cash payment, although Billing Clerk is not listed as an
actor.
Use Case: Resolve Patient Billing Issue
ID: 190
Priority: 3/5
Summary: Patient contacts the hospital to resolve a billing issue. Hospital clerk attempts to solve the issue.
Primary Actor: Hospital Clerk
Supporting Actors:
Stakeholders:
Accounting: wants to resolve billing issues and get paid if necessary.
Patient: wants to resolve billing issues and pay if required.
Generalization:
Include:
160: Print Patient Statement
Extend:
162: Apply Cash Payment
164: Charge Credit Card
166: Apply Payment by Check
Precondition: The hospital has charged a medical service to patient.
Trigger: The patient contacts the hospital with a billing issue.
Normal Flow:
1. Hospital clerk retrieves billing activities for the patient.
2. Hospital clerk identifies the billing item(s) that the patient is interested in.
Instructors Manual

59

3. Hospital clerk informs the patient of the status of the item.
4. Hospital clerk researches the issue.
5. Hospital clerk makes adjusting entries to resolve the issue.
6. Hospital clerk applies payment.
7. A new statement for the patient is issued. (Include: 160 - Print Patient Statement.)
Sub Flows:
Alternate Flow/
Exceptions:
5.a No adjustment is required. Hospital clerk does not make adjustments.
5.b The entry in the billing activity does not belong to the patient. Hospital clerk removes the item.
5.c The amount of the billing item is incorrect. Hospital clerk adjusts the amount.
6.a No payment is offered or required. Hospital clerk does not apply any payment.
6.b Patient pays by cash. Hospital clerk applies the amount to the patients account. (Extend: 162 -
Apply Cash Payment.)
6.c Patient pays by credit card. Hospital clerk charges the credit card and applies the payment to the
patients account. (Extend: 164 - Charge Credit Card.)
6.d Patient pays by check. Hospital clerk applies the check to the patients account. (Extend: 166 -
Apply Payment by Check.)
7.a No adjustments are made or the patient does not ask for a new statement. Hospital clerk does
not print a new statement.
Post-Condition: Billing issue is resolved.
Non-Behavioral
Requirements:
r.1 Only Billing Clerk may accept cash payment.
O O V Ve er ri if fy y C Cr re ed di it t C Ca ar rd d. .
The template for an extending use case is slightly different from the template for normal use
cases. It has three extra fields that identify the base use case. But it lacks the primary actor,
because the primary actor must be the same as for the base.

Extending Use Case:

Verify Credit Card
ID: 142

Base Use Case:

Register Patient

Base Use Case ID:

140

Extension Point:

The patient wants to pay the entire bill or the co-payments by a credit card.
Priority: 5/5
Summary: Registration clerk verifies the patients credit card for payments.
Supporting Actors:
Bank
Stakeholders:
Accounting: wants to get paid for medical services.
Patient: wants to pay for medical services.
Bank: must pay if credit card is charged.
Precondition: System needs valid credit card information for the patient.
Normal Flow:
1. Registration clerk enters credit card information for verification.
2. Registration Clerk transmits credit card information to the credit bureau of the bank.
3. Bank verifies credit card.
Sub Flows:
Alternate Flow/
Exceptions:

Post-Condition: Credit card is verified.
Instructors Manual

60

O O G Ge en ne er ra al li iz ze ed d M Ma ak ke e A Ap pp po oi in nt tm me en nt t. .
The template for a generalized use case is not very different from a normal template, except that
the name label identifies it as an abstract use case. It is very likely that the primary actor for a
generalized use case is a generalized actor as well.

Abstract Use Case:

Make Appointment
ID: 118
Priority: N/A
Summary:
An appointment is made for a patient to receive a medical service from the hospital.
Primary Actor: Appointment Agent
Supporting Actors:
Stakeholders:
Generalization:
Include:
Extend:
Precondition: Patient needs to receive a medical service from the hospital.
Trigger:
Normal Flow:
1. Appointment agent records patients personal and contact data.
2. Appointment agent records information about the referral source.
3. Appointment agent consults hospitals schedule to find a free slot for the required medical
service.
4. Appointment agent verifies that the patient is available for the appointment.
5. Appointment agent makes the appointment.
Sub Flows:
Alternate Flow/
Exceptions:

O O M Ma ak ke e A Ap pp po oi in nt tm me en nt t B By y R Re ef fe er rr ra al l S So ou ur rc ce e. .
This is a special case of the generalized Make Appointment. In a specialized use case such as
this, the relation of core entries to those in the parent must be specified: New, Inherited, or
Specialized.
Use Case: Make Appointment By Referral Source
ID: 122
Priority: [Future]
Summary:
A referral source makes an appointment for a patient who needs a medical service from
the hospital.
Primary Actor: Referral Source
(S: UC 118)
Supporting Actors:
Stakeholders:
Instructors Manual

61

(I: UC 118)

Generalization:

118: Make Appointment
Include:
Extend:
Precondition: Patient needs to receive a medical service from the hospital.
(I: UC 118)
Trigger: Referral source selects Walden Medical Center to provide medical service to the patient.
Normal Flow:
1. Referral source records patients contact data.
(S: Normal Step 1, UC 118)
2. Referral source consults hospitals schedule to find a free slot for the required medical
service.
(I: Normal Step 3, UC 118)
3. Referral source verifies that the patient is available for the appointment.
(I: Loop 1, UC 118)
4. Referral source makes the appointment.
(I: Loop 2, UC 118)
Sub Flows:
Alternate Flow/
Exceptions:

(I: UC 118)
Non-Behavioral
Requirements:
R.1 Referral source may only select from old patients which belong to the referral source.
(N)

V VI II II I. . N Ne ex xt t: : S St tr ru uc ct tu ur ra al l M Mo od de el li in ng g
The behavior of the system flows from its components, their relationships and their interactions
with each other and with the world outside the system.
Systems behavior is modeled by use cases. However, use case modeling, by design, has little to
say about the components of the system and none about its internal structure and workings. To
arrive at a structural blueprint for the system and its components, we must engage in a conceptual
reverse engineering: what kind of components, with what attributes and methods, with what kind
of architecture, are necessary to create a system whose behavior we have modeled and demand.
In an object-oriented framework, we have one preconception: the basic building blocks of
information systems are objects. An object is created from a mold called class. To make objects
we have to make classes, and this is the starting point of the next chapter: discovering classes that
are called entity classes from business (domain) concepts and use cases.
Instructors Manual

62

8
88.
.. S ST TR RU UC CT TU UR RA AL L M MO OD DE EL LI IN NG G
Behavioral modeling is the starting point for modeling software, but any system must rely on a
structure that supports that behavior. This chapter explores how to arrive at classes, the basic
building blocks of an object-oriented information system, and their relationships. It also introduces
class diagram, the most widely used tool in modeling for object-oriented development. Even the
most dynamic system has a structure and this structure must be modeled before it is constructed. A
structural model, however, is not meaningful in isolation: ultimately, it must support the behavior
of the system and the dynamic interaction among its building blocks to achieve that behavior.
Describe structural modeling within the context of a conceptual information system.
Understand classes as building blocks of structural modeling and objects as units of
information systems.
Learn about basic object-oriented concepts in the context of structural modeling.
Learn how to discover class candidates by parsing use cases.
Understand how to elaborate and define classes by specifying and expanding their
responsibilities.
Describe class relationships.
Learn how to create Class diagram.
STRUCTURAL MODELING WITHIN THE CONTEXT OF A CONCEPTUAL INFORMATION
SYSTEM
The structure modeling of an information system is, in essence, similar to structure modeling of
any other system: it must show the building blocks of the structure and their interrelationships.
And, like others, its view may be conceptual, logical or physical, its scope may be any relevant or
selected range, and its building blocks may be simple or complex.
CLASSES AS BUILDING BLOCKS OF STRUCTURAL MODELING AND OBJECTS AS UNITS OF
INFORMATION SYSTEMS
A structural model is distinguished from another structural model by O the nature of its building
blocks (or units) and O how the units are connected. The structural model of information systems
is composed of classes and their interrelationships. At runtime, when the information system is
actually created, classes are instantiated into objects that function as the units of the information
system. In other words, classes act both as units of modeling and as templates for units of the
information system.
BASIC OBJECT-ORIENTED CONCEPTS IN THE CONTEXT OF STRUCTURAL MODELING
Classes and objects are black boxes: their outside is visible while their inside is not. This
characteristic is achieved through encapsulation, the enclosing of data and processes within one
Instructors Manual

63

single unit. Information hiding, which follows encapsulation, ensures that the inner entities and the
workings of the object are concealed (and safe) from outside entities.
Encapsulation results in two spaces: public (the outside) and private (the inside). What the object
offers to the public is called its interface. The interface is both the services that an object provides
and form that these services take. Since, in an information system, the only reason for an objects
existence is the services that it offers to other entities, the interface of the object is characterized as
a contract or a binding agreement.
Under this contract, an object assumes certain responsibilities. The responsibilities fall into two
categories: what the object knows, or attributes, and what the object does, or operations. A
class defines the responsibilities and its instances, the objects, carry them out.
Even though an object is a building block of an information system, it might be composed of other
objects. Such objects are called composite objects. A collection object is a composite object that is
made up of objects instantiated from the same class. Composite objects may belong to a hierarchy:
a component of a composite object may itself be a composite object.
DISCOVERING CLASS CANDIDATES BY PARSING USE CASES
For all practical purposes, a class is objects responsibilities. And the best starting point for
discovering responsibilities are the use cases. In very broad terms, use cases specify what a class
must know and what a class must do.
To discover class candidates, we O identify nouns that serve as grammatical objects, O search for
grammatical objects hidden in verbs that have both transitive and intransitive forms, O discard
obvious misfits, O outline the general responsibilities of the candidates by analyzing its
relationships with other nouns and sometimes verbs within the flow of the use case, and finally O
consolidate our findings in a preliminary list of candidates and their responsibilities.
In this process, we intentionally avoid including details and, instead, outline the responsibilities
only in broad terms. (Even if use cases do offer details which they usually should not and do
not we must disregard them for the moment.)
ELABORATING AND DEFINING CLASSES BY SPECIFYING AND EXPANDING THEIR
RESPONSIBILITIES
To create solid building blocks for the structure of an information system, discovery of class
candidates and their general responsibilities is required but is not enough. We must also O confirm
that the tentative responsibilities do belong to the class and O specify the exact nature of those
responsibilities. In the process, we often discover new classes that must collaborate with original
class to fulfill some of its responsibilities.
When the responsibilities are reasonably specified in detail, you might have to delegate some of
them to other classes, new or existing. The more important a class is to the enterprise, the higher is
the likelihood that it would be overwhelmed with too many responsibilities.
CLASS RELATIONSHIPS
To build an structural model we must identify its building blocks, but to complete the task we must
also define how its constituent units relate to each other.
Association is a relationship that defines the connection between objects of one class with the
objects of another class in semantic that is, word-based terms: a Patient is covered by an
InsurancePolicy, A Customer pays by a CreditCard, an Author is the writer of a Book, and so
on.
Instructors Manual

64

Multiplicity is the quantitative association between instances of one class with instance of another
class: 1 patient can have only 1 nationality, 1 customer can purchase up to 100 books, 1 student
must register for at least 6 credits per semester but cannot enroll in more than 18, etc.
Constraints are rules that apply to associations: a fulltime student must take at least 12 credits per
semester, a patient can be issued many hospital cards but only one card can be valid at any given
time.
Aggregation represents a whole-part relationship: a school class is an aggregate of many
students and one teacher. Composition is a strong form of aggregation in which the parts
exclusively belong to the composite object and do not live beyond its lifecycle: the accounting
department of a company disappears the moment that the company goes out of business. A
collection object is a special kind of aggregate or composite in which all parts are instances of the
same class.
Generalization is a relationship in which one class is the more abstract expression of the properties
of a set of classes: a Tree class embodies properties common to Oak, Birch, and Cedar classes.
Conversely, specialization is a relationship in which a class is the less abstract expression of
another class: a Rose is a Flower but the Flower class does not express the specific features of a
Rose that sets it apart from other flowers. The result of generalization is a superclass (or a
parent), while specialization arrives as subclasses (or children).
CLASS DIAGRAM
Class diagram is the indispensable tool for modeling class relationships. Elements of class diagram
are few and simple but can model a wide variety of actual relationships. No single class diagram
can model all classes and all their relationships for even a small system. Therefore, to represent the
structure of a system, we need to create a set of class diagrams, each with a recognizable focus and
purpose.
RENEGOTIATING THE CONTRACT
We said that the interface of an object is a contract, but when change becomes inescapable, any
contract has to be renegotiated. Depending on the nature of the change and its timing, the task
can be easy and swift, or complicated and long. For example, high-definition television (HDTV)
appeared in 1980s. Everybody was impressed by its quality, but nobody was able to rush HDTV
sets to the market and make a fortune. Among the reasons: there were many proposed standards
and no TV station was broadcasting high-definition signals. It was only in 1997, after many years
of research and negotiations, that the U.S. Federal Communications Commission released a
standard for HDTV and established a timetable for broadcasters to start transmitting high-
definition signals. (The time-table, as it turned out, was too optimistic.)
Within the new contract, two obligations were placed on TV makers and broadcasters: until
HDTV becomes pervasive, new sets have to carry adaptors for the old standard (NTSC) and TV
stations must transmit signals in both standards.
Both ideas multiple interfaces and adaptors to cope with inevitable change are not strangers
to software development.
Adaptors operate outside a unit, exactly like a voltage adaptor that changes one current to other. In
software industry, they are also called wrappers, because an object (or larger components) are
enveloped within a layer that, on the outside, conforms to another standard.
Instructors Manual

65

Multiple interfaces, however, are features of the object itself. Objects with multiple interfaces are
either conceived that way from the start or are retrofitted when the necessity arises. (We will
discuss multiple interfaces later.)
COLLECTION CLASSES: IS IT TOO EARLY?
Collection classes are mostly discovered (or defined) through the design process that models the
logical workings of the information system (the system space), not in conceptual modeling (the
area where concepts from the business domain and the system space overlap). After all, they are
usually not persisted: they have no data that the business needs to keep. Unlike an Address
object that must be saved for future use, Addresses (plural) disappears without a trace when the
application is turned off: its business value is wholly dependent on the set of addresses that it
organizes and represents.
We shall discover new collection classes through design. However, it is incorrect to assume that
every collection class must be a design artifact. In a theater (for plays, not movies) all seats might
look alike and might be located in the same hall. But the concept of Orchestra, a collection object
composed of seats, is undoubtedly a business concept: tickets to the orchestra section are sold at a
higher price.
A business concept is not necessarily one that the business has a name for it. The only requirement
is that it should apply to business. In a hospitals manual information system, the clerk might use a
separate piece of paper for recording all the addresses that belong to the same patient. It might not
have a name that the domain experts can tell you, and if you ask them about collection objects
they would most likely give you a stare and scratch their heads.
Not that every time you find a set of sibling objects you need to create a collection class at
least not for the conceptual model. We shall see later that the same issues that we have handled
through collection objects can be solved through operations without requiring a collection object.
To summarize: if a business concept specifies or strongly implies a collection object with or
without a formal name then define a collection class. If not, then leave it for later.
DELEGATING WITHOUT EXPOSING
The mechanisms of delegation and collaboration are crucial to the construction of an object-
oriented system. Without them, the entire advantage of object-orientation disappears: objects
would become too complex, and reusing components would become impossible. However, our
discussion above may convey the impression that delegation works only if the collaborating object
is exposed i.e., directly made accessible to the public through the interface of the delegating
object: InsurancePolicy and CreditCard through Patient, for example. This is indeed not the
case.
A car exposes both the brake assembly through the Brake pedal and the engine through
the Gas pedal, among others. Even though these two mechanisms work at cross purposes, the Car
object makes no effort to prevent you from pushing them at the same time. There are legitimate
reasons for this behavior: if you plan to drive the car up a very steep hill from a stationary position,
it is sensible to give the engine enough velocity to climb before you let it move. Or you can do it to
show off: when you release the brake, the car flies down the road and the tires make an impressive
screeching sound. In both cases, whether out of necessity or not, you can damage the brake and/or
the engine.
We have to make an information system as resistant to damage as possible. Frequently, an object
must not be exposed directly. (The reasons are many and varied.) In such a case, we can hide the
object and collaborate with it at the same time. For example, we can add a verifyInsurance
Instructors Manual

66

operation to the Patient class that passes our request to the verify operation of InsurancePolicy
and returns the result. This way, the verify operation is still available, while attributes of
InsurancePolicy remain hidden to the users of Patient and must be managed separately.
C CR RC C C Ca ar rd ds s
CRC cards have been a popular device for an incremental approach to defining classes. CRC
stands for Class, Responsibilities & Collaborators. It is a index card that in its simplest form has
the name of the class, a short description, one column for responsibilities, and a second column for
collaborating classes.
The general idea behind CRC cards is the same that we have been following in this chapter:
gradually elaborate the responsibilities of the class and find its collaborators through
brainstorming, analysis and gathering of requirements.
Needless to say, many authors have found the basic, informal, format inadequate and have added
spaces for detailed attributes and operations, associations, generalization, specialization, and so on.
(Since a 3x5 inch index card has limited space, the back of the card has been drafted into the
service as well.)

CRC cards were first proposed in 1989 as a method to teach object-oriented approach. At the time,
object-oriented languages were few, object-oriented modeling tools were non-existent, laptop
computers were still a luxury, and PDAs were yet to arrive. Therefore, an efficient, simple and
creative way to impart object-oriented concepts was very welcome.
Things have certainly changed: object-oriented modeling tools are not only becoming flexible
enough to accommodate repeated changes, but modeling itself is becoming an integral part of
development tools. The separation between modeling, design and coding is becoming increasingly
narrower. You may use modeling tools to make drafts and alter the models as many times as
necessary.
Still, if you think better with a pen than with a keyboard and a mouse, CRC cards can prove
valuable. The fact is any small piece of paper, with a line in the middle, can work as a CRC card.
The idea behind the card define classes by discovering and elaborating its responsibilities and
collaborators is as solid and as relevant as it was in 1989, regardless of whether it is on an index
card or not.
CODE MANAGEMENT
Even though we are far from implementation, you have to start organizing the code that results
from modeling. As we mentioned under Deliverables, it is likely that the development tools at
Instructors Manual

67

your disposal would forward-engineer your class models into code skeletons, and backward-
engineer them when you open an existing project.
Any serious software development involves at least one team, and sometimes several. Since the
communication among team members, and among the teams, is not always face-to-face (or in
real-time), the danger that one developer may undo the work of another by coincidence is quite
real and, often, quite wasteful and expensive.
Code repositories allow the team to manage and streamline access to development artifacts.
Through implementation of security policies and enforcement of processes commonly known as
check-in and check-out, the team or the project leader can ensure that changes are not
destructive and are carried out rationally.
Unfortunately, the clients are not always very enlightened about such tools and you may find it
difficult to convince them that the expenditure is justified. Fortunately, however, more and more
development tools, especially enterprise versions, come with free copies of code repository
application. If they do not, try your best to sell the idea to the management. The price in purchase
and training is a pittance compared to the waste that would result from lost productivity.
V V. . E Ex xa am mp pl le es s
O WALDENS PATIENT MANAGEMENT CLASS CANDIDATES
The table below is the full listing of class candidates for Waldens Patient Management
subsystem. We have not included the generalized use case for appointment (nor its children) or the
Track Medical Service use case which was not explored in the chapter on DEVELOPING USE CASES.
(See Appendix B below.) However, we have listed included and extending use cases that
were mentioned in the previous chapter but were not presented in detail.
The list of Waldens class candidates is an example and, as such, it is an incomplete version: in a
real project for an enterprise-wide information system, our exploration of use cases cannot be
limited to the Patient Management domain. But a real enterprise-wide project is also incremental and
iterative, and it is usually entrusted to multiple teams. So you may consider the results acceptable
for one team and/or one juncture in the process of development.
Instructors Manual

68

Patient Management
Preliminary Class Candidates
Class Responsibilities Use Cases
Appointment
Make appointment for patient.
Know appointment.
Cancel appointment.
Know referral source.
Track appointment.
100: Refer Patient
130: Receive Patient
Adjusting Entry
(Adjustment)
Adjust accounts receivables for
patient.
Know adjustment.
Know method of payment.
190: Resolve Patient Billing Issue
Billing Activity (Billing
Item)
Knows a charge or a payment to
patients account.
Cash Payment
Knows cash payment to patient
account.
Check Payment
Knows check payment to patient
account.
Credit Card
Knows patient credit card.
Verifies patient credit card.
142: Verify Credit Card
Credit Card Payment
Knows credit card payment to
patient account.
Health Insurance Plan
Knows patients health insurance
plan.
Verifies patients health
insurance plan.
Outside Hospital
Knows the identity of hospital as
a referral source.
100: Refer Patient
Hospital ID Card
Issues hospital card. 130: Receive Patient
Medical Service
Knows medical service. 100: Refer Patient
141: Create Patient
Paramedic
(Emergency Medical
Worker)
Knows the identity of the
paramedic as referral source.
100: Refer Patient
Patient
Knows patients personal data.
Knows patients contact data.
Knows patients appointments.
Knows patients insurance data.
Knows patients financial data.
Knows patients referral source.
Knows patient next of kin.
Issues hospital card.
100: Refer Patient
Patient Next of Kin
Knows next of kin contact data. 140: Register Patient
Patient Statement
(Bill)
Knows patient open (unpaid)
billing items.
Knows paid items from the last
statement.
160: Print Patient Statement
Instructors Manual

69

Prints billing statement.
PCP (Primary Care
Physician)
Knows the identity of primary
care physician as the referral
source.
100: Refer Patient
Payment
Knows the payment credited to
patients account.
Referral Source
Knows the referral source. 120: Make Appointment
Hospital Schedule
Knows appointments.
Knows openings for medical
services.
O O W WA AL LD DE EN N S S T TR RA AC CK K M ME ED DI IC CA AL L S SE ER RV VI IC CE E U US SE E C CA AS SE E
The normal flow of the use case is very simple. It delegates its responsibilities to two other use
cases that it includes: Record Medical Service and Record Service Expense. The real work is done
through the children of included use cases, but there is one good reason for this use case to exist:
both Record Medical Service and Record Service Expense must take place within the same general
timeframe. When a service is provided, both medical and financial records must be updated.
Patient Management
Use Case: Track Medical Service
ID: 200
Priority: 1/5
Summary: The medical staff performs a medical service for a patient. After providing the service, the medical
staff records the results, patient info and charges.
Primary Actor: Medical Staff
Supporting Actors:
Stakeholders:
Patient: needs a medical service.
Hospital: offers medical service to the patient and must be paid.
Generalization:
Include:
210: Record Medical Service.
250: Record Service Expense.
Extend:
Precondition: Patient has an appointment and is registered.
Trigger: The reception clerk sends the patient to receive medical service.
Normal Flow:
1. Medical staff provides the service to the patient.
2. Medical staff records the results of the service. (Include 210: Record Medical Service.)
3. Medical staff records the charges for the service (Include 250: Record Service Expense.)
Sub Flows:
Alternate Flow/
Exceptions:

Post-Condition: Medical history and patient billing is updated for the service.
There are also good reasons as to why the two main steps in the normal flow are delegated to
independent use cases:
Both Record Medical Service and Record Service Expense have equally simple normal flows.
But each is a generalization of many child use cases. Removing their identity as
independent use cases would also remove the clarity of modeling that generalization provides.
Instructors Manual

70

In theory, the provider of the medical service also records the results and the charges. In
practice, however, the chances are that medical staff would deputize some other actor to do the
clerical work. (After ten hours in the operating room, a doctor cannot be expected to fill
complicated forms in their entirety.) The independence of the two use cases would allow the
hospital to be flexible in how the actual clerical work is assigned.
In concept, and almost certainly in user interface, the use cases belong to Patient
Management, but the inner workings of Record Service Expense would tie it to Accounting
and would have to be designed and implemented accordingly.
This table details one of the included use cases, Record Medical Service. Since it is a generalized
use case, only common steps are listed.
Patient Management
Use Case: Record Medical Service
ID: 210
Priority: 1/5
Summary: After providing a medical service, the medical staff records the results of the service, information
about the location, time and the provider of the service, and the patient ID.
Primary Actor: Medical Staff
Supporting Actors:
Stakeholders:
Patient: needs an up-to-date medical history.
Hospital: must keep track of medical services.
Generalization:
Include:
Extend:
Precondition: Patient has received a medical service.
Trigger: The medical service is completed.
Normal Flow:
1. Medical staff records the patient ID.
2. Medical staff records the ID of the medical staff.
3. Medical staff records the code for the service.
4. Medical staff records the facility in which the service was provided.
5. Medical staff records the results of the service in detail.
6. Medical staff records the results of the service in summary.
7. Medical staff records date and time.
Sub Flows:
Alternate Flow/
Exceptions:
5.a. The service does not have details. Medical staff does not enter details.
Post-Condition: Patients medical history is updated with the results of the service.
Step 4 is the one that will be expanded through the child use cases: Record Prescription, Record
Diagnosis, Record X-Ray, et cetera. However, as we mentioned in the chapter on DEVELOPING USE
CASES, generalizations looks good on a use case diagram, but is difficult to understand and maintain
in the textual flow of actual use cases. If you want to avoid the labor of maintaining use case
children, you can employ a different method: use the alternate flow and delegate the task to a set of
extend or include use cases. This method, of course, has its own shortcomings: the clarity of
kinship between the parent and the children, and among sibling use cases is lost.
Instructors Manual

71

V VI I. . N Ne ex xt t: : D Dy yn na am mi ic c M Mo od de el li in ng g
The behavioral model represents what the users of an information system expect from it. The
conceptual model of the structure shows the building blocks and their interrelationships that the
system requires satisfying that behavior. An information system, however, is a dynamic system:
we must also model how the building blocks interact and how they change through interaction.
Use cases describe how a system behaves. They mostly disregard the identity of specific building
blocks and the specific changes that the behavior of the system produces. Dynamic modeling
represents how the identifiable units of the structure interact with each other and with the outside
world and the changes that result from the interactions.
Instructors Manual

72

9
99.
.. D DY YN NA AM MI IC C M MO OD DE EL LI IN NG G. .
Modeling actions and interactions of a systems components to satisfy its behavioral requirements
is the subject of this chapter. Virtual objects interact by exchanging messages that must follow
strict rules and carry enough information to make a response possible. And since, oftentimes,
entities that engage in an interaction change as a result of their participation, we will also discuss
how to analyze and model changes that have significant consequences for the correct operation of
the system.
D De es sc cr ri ib be e D Dy yn na am mi ic c m mo od de el li in ng g a an nd d i it ts s r re el la at ti io on ns sh hi ip p w wi it th h b be eh ha av vi io or ra al l a an nd d s st tr ru uc ct tu ur ra al l m mo od de el li in ng g. .
S Sh ho ow w h ho ow w o ob bj je ec ct ts s i in nt te er ra ac ct t b by y e ex xc ch ha an ng gi in ng g m me es ss sa ag ge es s. .
D De ef fi in ne e T Th he e r ro ol le e o of f p pa ar ra am me et te er rs s a an nd d r re et tu ur rn n v va al lu ue es s i in n e ex xc ch ha an ng gi in ng g m me es ss sa ag ge es s. .
D De es sc cr ri ib be e m me et th ho od ds s a an nd d t th he ei ir r r re el la at ti io on ns sh hi ip ps s w wi it th h o op pe er ra at ti io on ns s. .
D De es sc cr ri ib be e e ev ve en nt ts s a an nd d t th he ei ir r i im mp po or rt ta an nc ce e i in n d dy yn na am mi ic c m mo od de el li in ng g. .
L Le ea ar rn n a ab bo ou ut t S Se eq qu ue en nc ce e a an nd d C Co ol ll la ab bo or ra at ti io on n d di ia ag gr ra am ms s. .
L Le ea ar rn n a ab bo ou ut t S St ta at te ec ch ha ar rt t a an nd d A Ac ct ti iv vi it ty y d di ia ag gr ra am ms s. .
DYNAMIC MODELING AND ITS RELATIONSHIP WITH BEHAVIORAL AND STRUCTURAL
MODELING
Dynamic modeling represents how the structure of a system and its components act and interact to
satisfy its behavioral requirements. Whereas behavioral and structural models represent abstract
units, dynamic modeling is concerned with actual objects (and components).
Dynamic modeling is not a straightforward combination of structure and behavior. It demands new
decisions and often leads back to refinements in both behavioral and structural models.
OBJECTS INTERACT BY EXCHANGING MESSAGES
In a virtual system, a message is equivalent to an action in the real world. And interaction in a
virtual world consists of exchanging messages.
Messages are instruments of communications that carry instructions and information necessary to
carry out those instructions, in the expectation that that the recipients will carry out the intended
action.
THE ROLE OF PARAMETERS AND RETURN VALUES IN EXCHANGING MESSAGES
Parameters (or arguments) are the types of data that an object requires to perform a certain task.
While the object responsible for an operation defines the types (and provides the containers or
variables) for the data, the sender of the message the object that requests the action must
provide the values.
Instructors Manual

73

The values that the message carries to its recipient must agree in both type and in order with those
that are defined and expected by the operation. (The recipient might supply a default value for a
parameter, but the order must preserved by indicating where a value is not supplied because a
default value exists.)
After the recipient object has carried out an operation, it might send a return result to the sender
of the message. In this case, it is the recipient of the original message that must provide a
container.
METHODS AND THEIR RELATIONSHIPS WITH OPERATIONS
An operation defines what the objects instantiated from a class must do, but not how they are
expected to do it. It is the method that implements the actual steps required to carry out a task.
Conceptual modeling usually ignores how operations are implemented, but the distinction between
operations and methods must be understood long before we actually attend to the latter.
First, instances of two classes may have the same exact operation, but they can implement it very
differently even if the classes are related.
Second, even instances of the same class may not carry out the same operation in the same way if
their states are different. (And this is very important to dynamic modeling, conceptual or
otherwise.)
Finally, attributes of an object, usually private, are exposed to the outside world through accessor
operations. This type of operations conforms to a syntax different from normal operations and are
not usually declared on the interface of a class. The task of methods that implement such
operations is to guard private data from unauthorized access or actions and retain the control of the
variable in the hands of the object.
EVENTS AND THEIR IMPORTANCE IN DYNAMIC MODELING
Events are occurrences that interrupt the existing condition of one or more objects. Events are
basically are three types.
The first type is call events, those that invoke an operation. When an object sends a message to
another object, the recipient of the message views the arrival of the message as an event to which it
must respond. As such, call events are the other side of the coin to messages. Moreover, such
events are usually both targeted (directed to a specific object) and synchronous (the event and the
response to it work within the same phase or timeframe).
The second type is signal events. They are anonymous, meaning that they are not directed to a
specific object, but will be received by any object that catches them. (Call events may be
compared to receiving a personal telephone call, while signal events are like buying newspapers
or tuning to a radio station to learn about events.) Furthermore, signal events are usually
asynchronous, meaning that the action that results in the event may not occur in the same phase
or timeframe that the event occurs.
Time events are like signal events: disruptive, asynchronous, and anonymous. The important
difference is that they are triggered by the passage of time, not by any prior action.
From the viewpoint of object-orientation, all the types above could be significant (or change)
events if they change the state of an object (or a system).
Instructors Manual

74

SEQUENCE DIAGRAM
Sequence diagram represents the interaction between objects, or between actors and objects
ordered in time. A sequence diagram is composed of a timeline, objects that interact across this
timeline, and the messages that they exchange
A sequence diagram is basically a space-time matrix for interactions. Two axes contain the
diagram. The vertical axis is timeline, or a chronology of events. The horizontal access identifies
the space and the actions that take place within the space. Movement on the timeline axis is one
way, but bidirectional on the space axis.
Each column in the sequence diagram identifies an instance of an actor or a class. Each row is a
messages sent or received by the entities in the column.
The scope of a sequence diagram (and other dynamic models as well), is a matter of choice and
judgment. You may use it to model a use case, part of a use case, interaction among components
or between subsystems.
COLLABORATION DIAGRAM
Collaboration diagram focuses on the organization of objects that must cooperate, by exchanging
messages, to satisfy a certain behavior. Collaboration diagram is goal-oriented and, as a result,
must show only those objects that cooperate in achieving a certain behavior.
The main value of collaboration diagram is that it presents a clear picture of what an object expects
from another. Therefore, a set of collaboration diagrams for the behavior of the system and its
components would contribute greatly to the refinement of class responsibilities.
STATECHART DIAGRAM
Like living objects in the real world, a virtual object is born and changes during its lifetime. Like
living objects, it might also cease to exist. Statechart diagram models the milestones in the life of
an object when its state is changed by a significant event.
Statechart diagram is the only dynamic model that illustrates the milestones in the lifetime of one
class of objects in its entirety.
ACTIVITY DIAGRAM
Activity diagram provides an effective tool for modeling the logical flow of actions. Activity
diagram is another view of the same scenario that the sequence diagram illustrates, but while
sequence diagram focuses on the exchange of messages between objects and object lifetimes,
activity diagram is concerned with the logical flow of activities. And where sequence diagram is a
basically a sequential presentation of actions activity diagram can efficiently portray parallel
activities.
We introduced activity diagram under use-case modeling, but it has two very useful tools that we
left out for later: Swimlane, a vertical partition on the activity diagram that organizes
responsibilities for actions, and Synchronization bar where parallel actions (or forks) merge
back.
With these tools, activity diagram can be employed as a workflow diagram to model actions
across enterprise.

Instructors Manual

75

V VI II II I. . D Di is sc cu us ss si io on n N No ot te es s
SIMULATION & MODELING
Simulation is a kind of dynamic modeling in which one system closely mimics the behavior of
another system in real, slowed, accelerated or customized time. The first system, the simulator, is
usually virtual but not always: many models of the solar system have been constructed from
tangible objects and wind tunnels are used to simulate the effects of velocity on automobiles and
airplanes. The second system is usually real but not always: simulating internet traffic concerns
a virtual system.
Simulations serve several different but frequently overlapping purposes:
Games. Simulations, of course, have been immensely popular and successful as games: sports,
undoubtedly, but also flight simulation and even construction of complete cities or
civilizations.
Instruction. Simulations have become indispensable tools for teaching skills that demand quick
thinking and a high degree of handeye coordination. Again, flight simulation (this time more
rigorous and detailed than in games) is the most prominent example, but learning many other
tasks can, and do, benefit from simulations.
Education. Close to instruction, but the purpose here is learning about, not learning to do.
From planetary motions to ecosystems and ancient civilizations, simulations can impart
knowledge with an immediacy that no other tool can match.
Demonstration. Simulations have become a stock-in-trade in architecture, especially for large
or prestige project.
Prediction. There are many serious human endeavors that can fail with grave consequences if
they are not helped by reliable simulators: from designing new medicine and maintaining
nuclear weapons to predicting weather patterns and robotic missions to Mars.
Testing. While predictive simulators mimic an entire system itself, testing simulations imitate
the effects of interaction with the outside world on an actual system (whether real or virtual).
A good simulation may be considered the ultimate dynamic model. Then why dont we discard
UML diagrams and its ilk and build simulations instead? It would have been great if we could. In
fact, software industry does employ simulations for specific purposes. (See below.) But, for
software development in the strict sense of the term, simulation would be either overkill or
misapplied.
First and foremost, a software simulator is a complete and usually complex system by itself, and
we need models to build a system especially if the system is complex. An absurd cycle results
if we build a simulator to build a simulator (and so on).
Second, if we have a piece of software that behaves like another piece of software, then there is no
need for the second software. (Is there?)
Third, developing any kind of simulation is usually a very expensive undertaking. A simulator
makes sense only when it is for repeated use (or when there is no other way to do the job).
Last, but not least, no simulation provides us with useful blueprints for building an entity. Even
a city-construction game (such as Cim City) supplies us with components, not plans: it is we who
must come up with plans. (The game is our plans and their consequences.)
As we mentioned, however, two types of simulations have proved very useful in software
development: testing and demo. Automated testing tools simulate the effects of interaction of the
Instructors Manual

76

target system with the outside word, while demo software mimic the outside looks and the
behavior of the system.
All of the above does not mean that dynamic modeling (in general) should not borrow a few pages
from simulation. Current UML tools are effective and sensible (if applied judiciously and
correctly), but they cannot be accused of being exiting or riveting.
ON EVENTS
One definition of event is interruption. As interruptions, events are critical to both the
computer technology and software. The central processing unit (CPU) is an interruption-handling
engine, while a significant number of components that communicate with the CPU keyboard,
mouse, communication ports, network cards, etc., are interrupters. CPU does not devote any
time or resources to interrupters unless it is notified by an event: a key pressed, a mouse moved or
clicked, a packet received by a network card.
Any software worthy of consideration is as event-driven as its technological underpinning. In
addition to operating systems, most applications and games (especially games) are designed
around events and event-handlers.
Despite this significance, the meager attention and respect that events receive from the theory of
object orientation is rather surprising. (Practical books, on languages and development
environments, do much better. They have to.) Most theoretical books completely disregard them.
Those that do mention events devote few pages to discussing them, and those discussions often
have an aura of an afterthought. At best, they are considered the junior partner to other aspects of
object orientation such as encapsulation, inheritance, etc. At worst, events are presented as
counterparts for operations.
One reason may be that events, or event-driven languages, predate object-oriented ones. The very
popular Visual Basic was an event-driven language before it started to acquire object-oriented
trappings. (Events started life long before Visual Basic, though, at the time that mainframes
roamed the earth.) But the fact is that without events, object methodology is a vehicle without
fuel: an object might have all the desired properties and methods, but the only way it can move is
by applying a one-to-one outside force for each action. Without events, objects become so tightly
coupled, so closely tied together, that any misstep by one object can bring down the whole
structure. Each object would have to know about all the other objects that are to provide it with a
service and actively seek their attributes and methods: the mailman would never deliver your mail
to your door; you would always have to pick it up from the post office. Let us illustrate the point
with an example.
A clock is frequently introduced as a fitting illustration of object-oriented theory as we did. No
matter how the clock functions internally, its interface is what matters. It has two methods:
getTime and setTime. If it is an alarm clock, then it has also one event, alarm, and a related
method, setAlarm.
Clocks have been around for a long time and their precision has increased enormously. But their
usefulness without this single event is severely limited. Imagine the public square in a medium-
sized European town some centuries ago, with an ornate (and expensive) clock on the bell-tower
of the local church. The monks devoutly keep the clock running and adjust it when necessary. The
towns residents rely on the clock for their religious, secular and civic activities. (Watches, when
available, are still too expensive.) Every hour, the clock informs them of the time, and the
residents decide what to do with this information.
They may reside around the church, or a few neighborhoods further. They can go on with their
daily lives without actively seeking time, confident that the bells would toll on time.
Instructors Manual

77

Now imagine the town, with the same duties and needs, but without the bell event. They can
adopt different techniques, but these would go from absurd (everybody should live in the same
neighborhood as the clock, with a window overlooking it) to inconvenient (one person watching
the clock for the exact time and then ringing the church bells).
Events are what mostly bewilder pre-object-oriented programmers. In a language without events,
the programmer lays out a menu and waits for an input (that is really an event, but only for the
operating system). When the input arrives, the logic checks for every possible entry (right or
wrong) and takes action accordingly. The programmer is like a person who needs to be informed
of the time, but the clock has no alarm. So he has kept his gaze more or less fixed on its face.
Without events, objects may still be objects, but they cannot behave as objects.

V V. . N Ne ex xt t: : D De es si ig gn n
This chapter closes the section on analysis, but not on the models that are used for analysis and
conceptual modeling. In design, the next section, we will see how the same tools are expanded or
used from a different point of view to construct a logical model of the system. In other words, we
start moving from what to how.
Analysis, however, does not end at a certain point. First and foremost, the behavioral model of
the system retains its position as the guideline for all development: every model at every step must
serve to satisfy the required system behavior. Use cases will be reinterpreted (through sequence
diagrams, for example), but they will continue to identify the objectives of the system.
Second, the same way that various types of conceptual modeling behavioral, structural and
dynamic refined each other as they were developed, logical modeling refines and changes
conceptual modeling. To put it another way, how we build the system will affect what is built. As
we argued under DOMAIN ANALYSIS, problem space and solution space are organically intertwined.
Design, or concrete modeling, discusses the solution-as-method, or the way the product is built.
(Again, see DOMAIN ANALYSIS chapter for the difference between solution-as method and solution-
as-answer.) Any complex system needs two features to succeed in its mission: agile and reliable
components and an efficient organization of those components.
1
110
00.
.. T TH HE E D DE ES SI IG GN N C CH HA AL LL LE EN NG GE E. .
Design is the concrete modeling of the solution. This chapter provides the foundations on which
the later discussions on design are built. It also explains why design is fundamentally different
from analysis and how we should move from conceptual modeling to concrete modeling. Design is
a model-driven activity that must, eventually, produce engineering blueprints for actually building
the product. Our approach to design is object-oriented, component-based and architectural.
This approach views the product as a system composed of objects, both coarse-grained and fine-
grained, and holds that the design process must start from an overall view that is refined through
roundtrips and iterations, not through successive decomposition of the features.
Learn about design & its place in the development process.
Understand how to move from analysis to design.
Instructors Manual

78

Understand the difference between logical design and physical design.
Learn the significance of domain analysis to design.
Learn about design objects.
Describe stereotyping & other UML extension mechanisms.
Learn about packaging as a UML mechanism for managing the complexity of models.
DESIGN & ITS PLACE IN THE DEVELOPMENT PROCESS
Design is the path between the concept of a product and the building of the product itself. While
analysis studies the product from the viewpoint of the problem domain what it can do to solve a
problem, satisfy a desire or take advantage of an opportunity design does the same thing from
the view of the solution: what the product must be to satisfy requirements. In short, design is about
how, whereas analysis is about what and where.
Like object-oriented analysis, design starts its voyage of discovery by going from outside in, and
refines its views from inside out if new objects are discovered or required.
MOVING FROM ANALYSIS TO DESIGN
Analysis and design are not phases divided by clearly-defined lines. They are activities that
overlap the transition between the two occurs only incrementally. Design objects objects that
serve the product are discovered by starting from analysis artifacts.
Essentially, design uses the same modeling tools as analysis, but turns its focus from the problem
space to the solution space. There are two exceptions: use cases that are used by design but not
created for it, and component diagrams that are primarily for use by design.
LOGICAL DESIGN VS. PHYSICAL DESIGN
Since design is about modeling the product, it is also called concrete modeling. Concrete
modeling is composed of two activities: logical modeling that represents the solution but avoids
references to specific technologies, and physical modeling that maps logical models unto specific
technology or technologies. The detailed physical models are comparable to engineering
blueprints in construction or manufacturing.
We must not conclude that since logical design avoids specific technologies it is technology-
agnostic. Logical design must take into account a technological paradigm while disregarding
technologies as products.
A problem may have no solution and, therefore, lack a meaningful logical design. But if there is a
solution (or more than one solution), it is likely than one logical design can be mapped into
multiple physical designs.
THE SIGNIFICANCE OF DOMAIN ANALYSIS TO DESIGN
Simple requirements gathering might overlook factors that are not directly related to the problems
that the product must solve. A sound and extensive domain analysis is critical to the success of
design, since a product might satisfy all stated features but fail in the context in which it must
operate.
DESIGN OBJECTS
Analysis discovers objects that belong to the problem space. Design must define objects that are
necessary for the product to operate. While analysis objects, called entity objects in object-
Instructors Manual

79

oriented terminology, must be persisted because the business must know their states across a
period of time, design objects are usually (but not always) stateless: they vanish if the system is
shut down or the application is closed.
One characteristic of design objects is their variety. In essentials, design classes fall into three
major categories but, depending on the available or the selected technology, the requirements of
the application and the designers decisions or preferences, they might be further refined into
subclasses:
Control. These classes control the flow of the application, direct the sequencing of events,
manage the interaction of other objects and frequently enforce such business rules that go
beyond the domain of a specific class but relate to a specific use case or go across use cases.
Control classes are not directly involved in the interaction between the application and the
outside world, but delegate these tasks to boundary classes.
Boundary. Boundary classes control the interaction between the system or application and
entities outside the system such as human actors (user interface), communications and
persistence (databases, files, etc.).
Utility. These helper classes offer services (such as calculations) that are usually independent
of the applications flow and do not go beyond its boundaries.
As we said, these superclasses might be refined into subclasses such as Lifecycle classes that
manage entity classes, Web Page and Form classes that manage the interaction with the users, and
Dataset that functions as a data carrier. (There are, however, no standards for doing so. Therefore,
you must follow your own judgment or example that have become de facto standards.)
STEREOTYPING & OTHER UML EXTENSION MECHANISMS
UML modeling notations are few and simple. To allow creating richer models both in content and
in form, UML provides a set of extension mechanisms:
Stereotyping: extends the vocabulary of UML by creating specialized building blocks for
modeling. For example, you can specialize the UML class symbol by labeling it as Control
and adding an identifying icon. You may then use the label to identify all control classes or
use the icon as a substitute for the standard box. Every UML notation can be stereotyped.
Notes: specify comments that express requirements, observations, reviews and explanations.
Notes should be used sparingly and, if long comments or documentation is necessary, they can
serve as references to other documents or hold embedded links.
Adornments: are textual and graphical items that show details about modeling elements.
Contrary to the low expectations that the term inspires, adornments are often essential to
understanding the model, for they include things like multiplicity (quantitative relationship
between instances of classes), the nature of class associations and the direction of the
association.
Tagged Values: Allow us to add new properties to modeling elements, such as version number.
Note that these tagged values are metadata about the modeling elements and not what they
symbolize (such as an entity class.)
Constraints: specify a condition that must be true for a relationship between modeling
elements to be correct. For example, one department may have many employees but only one
manager (a subset, a type of constraint).
Instructors Manual

80

PACKAGING, A UML MECHANISM FOR MANAGING THE COMPLEXITY OF MODELS
Design increases the complexity of models exponentially. The most common approach to
resolving this issue is called chunking: breaking down a large model into pieces that can be
grasped more easily. The mechanism provided by UML for this purpose is packaging. A package is
a general-purpose mechanism in modeling tools for grouping related items within a hierarchical
structure.
A package can contain any number of items: use cases, use case diagrams, class diagrams,
components, other packages, etc. Depending on the circumstances and choice, packages can be
organized functionally or based on some other criteria such as the type of the model.
A package and the elements within the package can belong to one, and only one, package even
though packages can expose their elements to other packages that may then import such public
elements. Nevertheless, the life of a package element is dependent on the life of its owner: if the
owner is removed, all its owned elements disappear as well.
Packaging should not be done early and should not be done often. Only when you have clear
picture of how you want to organize your models you should attempt packaging, for
repackaging is not easy.
V V. . D Di is sc cu us ss si io on n N No ot te es s. .
ON RE-PACKAGING
To create UML models, you may use a pencil and a sheet of paper. To use packaging, on the other
hand, you must rely on CASE tools. Herein lies the rub. CASE tools vary widely on how they
implement the mechanism of packaging. One tool might permit you to package classes, but not use
cases. Another follows UML guidelines strictly and destroys every element within the package if
you destroy the package.
CASE tools will improve by time. An issue that is more significant than various implementations,
however, is how the idea of packaging itself has been formulated.
If we look over the packaging idea more closely, we see that packages are really databases of
analysis and design artifacts. And since they are databases, the question becomes what kind of
architecture lies behind the database. Databases have been around for quite some time, almost
from the moment that computers were outfitted with storage devices. Different theories and
technologies for organizing data are not fresh subjects.
Packaging, as envisioned by UML, relies on a hierarchical database management scheme in which
lower-level entities belong to a higher-level one, and only to one higher-level entity. Before
relational databases matured, this model for organizing data (along with the network model) was
used extensively. The directory (or folder, or file) structure in todays popular operating systems is
modeled on this concept.
Databases, however, are not just for storing data somewhere, but also for retrieving them in a
convenient and efficient manner. The directory/subdirectory structure of operating systems
notwithstanding, a hierarchical database is not a very friendly or effective scheme for using data.
(Even the operating system companies, such as Microsoft, are promising alternate structures for
their storage systems.)
As we develop our system depending on the context and the phase of the development we
need to repackage the same artifacts in different ways: for the client, for the developer, for the
implementation, by a certain relationship and then by another type of relationship, by priority, et
cetera. Our needs would have been best served by a relational model that can repackage entities
Instructors Manual

81

on the fly, not a fixed scheme of hierarchical ownership. (See the chapter on persistence and
database in this section for a discussion of relational model.)
UML clearly recognizes the need for satisfying different views that are needed during the lifecycle
of a project. It has tried to address the issue through extensions (stereotypes) for importing
elements from one package into another, and through applying object-oriented concepts such as
visibility (public, private and protected element) to the packaged artifacts. But the basic scheme,
namely the hierarchical model, severely undercuts its good intentions.
For a programming platform, hierarchical organization makes sense. We do not, however, have to
repackage actual classes and components (as opposed to their models) to use their functionality.
For modeling artifacts that have to be presented in numerous views, this arrangement is more of a
handicap.
For the moment, we have to live with it, especially if we are using a CASE tool. Or we can remedy
the shortcomings by the thoughtful use of other available tools: let the CASE tool do what it does
best and use a word processor or another application for repackaging.
V VI I. . N Ne ex xt t: : A Ap pp pl li ic ca at ti io on n D De es si ig gn n. .
An application is an encapsulated object, meaning that a boundary separates its inside where
their structure resides and their functionality originates from its outside where they interact with
the outside world. But the prominence of two features make an applications stand out from other
objects: O a set of identifiable goals that, together, define a mission, and O a more or less
complex flow that allows the achievement of such a mission. All objects have a behavior
(operations) and/or attributes, but applications must accomplish something useful.
Instructors Manual

82

If this description reminds you of use cases, you are absolutely correct:
An application is the realization of a set of use cases whose goals, in combination, define a
mission.
In using a word processor, you might encounter many use cases: open document, close document,
create paragraphs and pages, etc. What distinguishes a word processor application from its use
cases is the significance of its ultimate goal: word processing in its totality.

Applications are widely different both in their structure and their missions: word processing,
monitoring and running nuclear reactors, guiding spaceships, accounting, managing patients so
on and so forth. They share, however, certain characteristics: they have a boundary with the
outside world (in which user interface and persistence are most prominent), and they must have a
structure that controls the flow of interactions with the outside world towards the achievement of
their goals. In the next chapter, we start application design by exploring this flow.

Instructors Manual

83

1
111
11.
.. A AP PP PL LI IC CA AT TI IO ON N D DE ES SI IG GN N I I: : F FL LO OW W & & C CO ON NT TR RO OL L
The flow of an application is decided by entities that are known as control objects. This chapter
explores the concepts that lie behind these objects and illustrates the concepts by applying them to
the scenario of Walden Hospital.
Understand control classes & their role in the flow of applications.
Learn how to use analysis models for design
Describe the characteristics of flow objects.
Learn how to apply structural modeling to design.
Describe lifecycle objects and .dataset as a utility objects.
Describe application control & security.
Learn about design requirements for defining methods & messages.
Understand construction & destruction of objects.
Define the control flow of Web applications.
CONTROL CLASSES & THEIR ROLE IN THE FLOW OF APPLICATIONS
Objects that control the flow of the application, direct the sequencing of events, manage the
interaction among objects and encapsulate the behavior specified by use cases are called control
objects.
The central concept behind control objects is a rule that flows from object-oriented design: divide
and conquer. By distributing the responsibilities of the solution among control and flow objects,
user-interface, persistence and entity object can remain focused on their own responsibilities.
BUILDING ON ANALYSIS MODELS
Design focuses on the product that solves the problem, but it is not a sudden break with analysis.
On the contrary, design is an evolution from a conceptual solution to a concrete one. The same
evolutionary path is followed by individual building blocks of design as well. Concrete modeling
revisits use cases from the viewpoint of design and develops its artifacts by expanding structural
and dynamic models of analysis.
CHARACTERISTICS OF FLOW OBJECTS
Flow objects enforce the workflow and the sequencing of events as specified by behavioral
modeling, as described by use cases, and by dynamic models. To enforce the workflow, flow
objects must intercept most messages exchanged between objects to ensure that the interaction
between them follows the correct sequence or scenario.
Besides command and control, flow objects provide other objects with services that they
cannot find for themselves. The services that the flow object provides are usually not its own, but
are delegated to other entity and design objects.
Instructors Manual

84

Without flow objects, boundary and entity objects would have to assume responsibilities that
would reduce their flexibility and increase their complexity.
APPLYING STRUCTURAL MODELING TO DESIGN
The ultimate mission of concrete modeling is to produce blueprints for building the information
system and its components. This task involves both the refinement of entity classes that originate
from the problem domain and the definition of design classes that serve the solution.
Design classes are not abstractions of objects that have counterparts in the problem domain.
Therefore, to define their responsibilities, we must parse dynamic models, such as sequence
diagrams, that identify services that the solution requires. In other words, we can define design
classes by studying the needs that we discover when we re-integrate the flow of use cases with
classes from analysis.
LIFECYCLE OBJECTS
Lifecycle classes are responsible for managing a set of other objects, especially when a large
number of entity classes are involved. They create, organize, track and destroy other objects, often
instances of entity classes.
Lifecycle objects help both the management of complexity and reuse. Lifecycle classes have
similar missions; therefore, they have similar attributes and operations as well: they are
collections, responsible for managing multiple objects, from a few to thousands; They provide a
set of navigational operations such as first, next, previous and last that allow outside entities to
browse among objects within the collection; they expose individual objects upon request; they
provide lists of objects in their care; they often provide operations such as search or find to select
subsets that satisfy specific criteria.
DATASET, A UTILITY OBJECTS
Besides control and flow, the internal workings of an application require a wide range of utility
objects. One such object is dataset that, depending on technology, is also called resultset,
recordset or simply list.
Dataset is a general-purpose utility object that carries data between objects within an application. It
is a collection object in which the objects are organized as rows and columns, similar to
spreadsheets. Each cell within this tabular format is a primitive object that exposes a single
piece of data of a certain type. This data type is the same for all members of the column. The exact
variety of data types depends on the technology and language, but they fall in general categories
of string (text), number, Boolean or object (or rather, the address of an object).
APPLICATION CONTROL & SECURITY
The control of an application is composed of control objects for individual use cases, plus objects
that control application-level flow, including security enforcement objects.
Security and user privileges are usually decided when the user logs into the application and are
communicated to individual control objects as the need arises.
DESIGN REQUIREMENTS FOR DEFINING METHODS & MESSAGES
Messages are how objects interact within an object-oriented context. Methods are implementations
of an objects public services. To ask an object to perform a service, another object must send it a
message that corresponds both in substance and in form to the method that provides the service.
To arrive at blueprints for building methods, we must progressively refine messages into detailed
logical and physical models. For concrete modeling, parameters within a method must be clearly
Instructors Manual

85

specified: methods cannot rely on guesswork. We must also define the data type for each
parameter. Furthermore, concrete modeling of methods requires not only the specification of
substance, but also of the form.
Methods implement not only operations, but also provide access to attributes. Such methods are
called accessor methods and are usually defined in pairs, one for reading the value of the attribute
and the other setting it. By removing one, we can make an attribute read-only or write-only.
CONSTRUCTION & DESTRUCTION OF OBJECTS
Objects do not create themselves: each object must be instantiated by another object. In most
object-oriented languages, an object may implement constructor methods that allows the entity
that instantiates the object to provide it with information that it needs from inception to provide
any service. Constructors are like other methods and can be even overloaded, but they have the
same name as the class and cannot be accessed after the object has been instantiated.
Destruction of objects often does not require explicit actions: when other objects no longer refer to
an object, it is automatically destroyed by the runtime environment. Sometimes, however, you
need to destroy objects explicitly.
THE CONTROL FLOW OF WEB APPLICATIONS
The state of an application is a snapshot of the application in time. By keeping state, an
application knows what the user has been doing, where in the workflow is the user now, and
what actions are allowed or possible from this point on.
The Web, however, is a stateless environment: a Web server does not keep track of the identity
or the actions of the users after responding to individual messages. A Web application, therefore,
must recreate the state every single time that it receives a message from the Web.
The mechanisms by which Web developers keep the state of an application is varied. In essence,
the Web application recreates the state each time it receives a message from the client by
analyzing a marker which it has transmitted to the client in the previous exchange. The most
common form of such a marker is a small text file called cookie that encodes the necessary data
for building the state. Another method is to encode the state data inside the URL (Uniform
Resource Locator), also known as link, that is clicked by the user to send a message to the Web
server.
CHEATING ON RETURN VALUES
Most languages allow you to cheat and bypass the restriction that an operation can return only a
single item.
To understand how this is done, you must clearly comprehend a concept that we have repeatedly
tried to convey: a data item and its container are not the same thing. Age is a container, or a variable,
while 25 (Years) is a value. In software, values are always contained within a container. Values
may be transferred from one container to another, but they are never free-floating. Conversely, the
value inside a container is subject to change. (That is why the containers are called variables.)
Now, when you send a message to an object to carry out a certain operation, you match the
operations parameters with values provided by the message. But since values cannot be free-
floating, one has to ask: where are the containers? The containers are provided by the object that
receives the message. And because the parameters of the operation are really variables (and public
ones, at that), there is nothing to prevent the object from replacing their contents with other values.
When the operation is done, the sender of the message can examine the parameters for new values.
Instructors Manual

86

The rules and the syntax for this method of exchanging values are dependent on the language. The
basic concept, however, is that a parameter can be one of the three types: IN, OUT, or INOUT. An IN
parameter accepts only values that are incoming, an OUT parameters is reserved for outgoing values,
and an INOUT parameter is used both ways.
It is important to remember that even though an object may return values through parameters,
those values are never called return values. Return Value, as we have described, remains one
and only one item.
In general, however, it is better to keep the exchange between the sender and the receiver of the
message as clear and as simple as possible (when possible: sometimes it is not).
If you find that you wish an operation could return two items, you might have made a mistake:
either you must define more than one operation, or the type of your return value is not up to the
task (For example you might have specified the return value as Fruit, whereas it should have been
Fruit Tray.)
MAPPING MAKE APPOINTMENT TO DESIGN SEQUENCE
Figure below shows steps 3-6 of the design sequence diagram for the Make Appointment use case.
The diagram is not, in any way, a detailed design model. In fact, it hides many objects by using
placeholders such as Appointment UI or Persistence, or by ignoring the details of delegation (such
as creating the actual appointment by the Patient object. The diagram, however, does illustrate that
even a simple use case usually expands into numerous design steps.

Instructors Manual

87

Below, we place all three diagrams in the context of the use case for Make Appointment to
provide a picture of what may take place when we move analysis models towards design.
O Appointment clerk verifies that the needed medical service is provided by the hospital.
Before any interaction specified in the use case can take place, the flow object, Appointment
Agent, must provide the appointment clerk with the user interface; therefore, it instantiates
Appointment UI .The use case, quite appropriately, takes the user interface for granted
because it generally avoids the how of the solution. Concrete modeling, on the other hand,
must specify the exact sequence of events that must be implemented in the solution.
O Appointment clerk records patients personal and contact data.
2.A. Patient is not on file. Create new patient. (Extend: 141 - Create Patient.)
The flow object has two equally important missions: control the sequence of events and
marshal services for the objects that need them. Neither mission means that the flow object
must act as a prison guard. For example, in this step, the user interface requests not just a list,
but an actual collection of patients (Patient Mgr). Having delivered the Patient Mgr instance
to the user interface, Appointment Agent retires from intervening between the two. From this
point on, Appointment UI and Patient Mgr interact directly. (This is an example. As the
designer, you may decide to keep Appointment Agent involved.)
Instructors Manual

88

There are two differences between the use case and the design sequence diagram. The first one
relates to sequencing while the second is structural:
In the use case, the appointment clerk enters new patient information separately from
entering the referral source. In design, however, both actions are combined into one (see
step 3 below), which is a more efficient approach than forcing the user to update various
pieces of the patient profile twice. Such adjustments are common in successive iterations
of development. The only warning is that such adjustments must not alter the essential
workflow as envisioned by the use case.
What happened to the extending use case, Create Patient, specified by the use case? We
should make one point clear: there is no rule that states one use case, one flow object:
Control classes often encapsulate control related to a specific use case, implying that a
control object would be created when the use case starts and that the control object
would be terminated when the use case ends. However, there are exception where a
control object participates in more than one use case realization, where several control
objects (of different control classes) participate in one use case realization, and where a
use-case realization does not require any control object at all.
Create Patient does not appear to have a flow that requires a dedicated object. It does have
another kind of control object: Patient Mgr, a lifecycle object. Many extending use cases are
similar. If, however, we decide to turn Create Patient from an extend type to an include
type to be reused by multiple use cases then we should consider defining a dedicated
flow class.
O Appointment clerk records information about the referral source.
At the conclusion of the previous step, Patient Mgr returned an instance of the Patient class to
the user interface. Regardless of whether the instance is a new patient or an existing one, the
Appointment UI has a direct handle on the Patient object. Therefore, it no longer has a need
for the mediation of Patient Mgr and communicates directly with Patient.
In design, this step combines all data entry and updates that were broken up into two steps by
the use case.
O Appointment clerk consults hospitals schedule to find a free slot for the required
medical service.
The interaction in this step is similar to one in the first step: the user interface must display a
list and, therefore, an instance of the general-purpose class, Dataset, is sufficient for its
purposes.
O Appointment clerk verifies that the patient is available for the appointment.
Since this step of the use case takes place outside the system domain, no design object is
involved. It is noted on the sequence diagram simply as a clarifier of the flow. It does,
however, mean that the user interface would allow the user to repeatedly enter appointments
without returning to the beginning of the use case.
O Appointment clerk makes the appointment.
The user interface asks the Patient object to make an appointment. Although making
appointments is one of the services of the Patient class, the actual service is delegated to
[Jacobson 1999, 188]
Instructors Manual

89

Appointment. Managing appointments requires a lifecycle object of its own, similar to Patient
Mgr. (See LIFECYCLE OBJECT topic earlier in this chapter.)
In the last step, as well as in the earlier ones, we have not explored the details of how the user
interface communicates with the user. Nor have we specified the various components of
Persistence. Attempting to render all design details in one model is counterproductive.
BASIC DATA TYPES
Table below presents the most basic logical data types. Their number, however, is not
representative of physical data types that, depending on the development platform and/or the
database are much more numerous. For example, the number data type is usually sub-typed into
long integer, short integer, double, decimal, currency, et cetera. Some platforms do not support the
Boolean type per se.
Basic Data Types
Data Type Description
String
A string of characters, any character.
Date
A date. A variable of this type would not accept anything but dates (or a combination of date
and time).
Number
A number, and only a number. This type has the highest number of variations in different
languages.
Boolean
Accepts one of two values: true or false, yes or no, on or off, etc.
Complex
The most language-dependent of all data types, it accepts a structure that contains a set of
values.
Object
Holds an object (or rather the address of an object).
Variant
A container of the variant type can hold any of the above data types (but only one at a time).
Most popular with scripting languages, languages that are designed to perform limited or
specialized tasks.
V VI II I. . N Ne ex xt t: : T Th he e U Us se er r I In nt te er rf fa ac ce e
Like an object, an application has an inside and an outside. On the inside are control and utility
objects that support the dynamic behavior of the application on the outside. Objects that interact
with the outside world are called boundary objects. Without boundary objects, an application
would become a closed system, an entity without a useful function.
User interface objects are the best-known of boundary objects. The prominence of the user
interface is to be expected, as it is what the users of an information system see and with which they
interact. As we shall in the next chapter, however, user interface is more than what is readily
visible.
Instructors Manual

90

1
112
22.
.. A AP PP PL LI IC CA AT TI IO ON N D DE ES SI IG GN N I II I: : T TH HE E U US SE ER R I IN NT TE ER RF FA AC CE E
The user interface is where the interaction between the user and the application takes place. It is
the boundary between the problem domain and the solution domain. The components of the user
interface, its language and the requirements for its design are discussed in this chapter.
I II I. . C Ch ha ap pt te er r T To op pi ic cs s
Describe the user interface layer & its responsibilities.
Learn about the language of graphical user interface (GUI).
Understand visual metaphors & their roles in the design of user interface.
Understand the significance of patterns, consistency & aesthetics in UI design.
Learn how to Map messages, parameters & attributes to the user interface.
Lean about modeling for UI: navigation diagram, storyboarding, simulation & prototyping.
THE USER INTERFACE LAYER & ITS RESPONSIBILITIES
The user interface is where the interaction between the application and its human users takes place.
User interface is an interface like any other, but with two distinct responsibilities:
User interface is responsible for translating real-world messages into virtual ones and virtual
messages into real ones.
User interface must guide the users through the steps necessary to accomplish meaningful
tasks.
THE LANGUAGE OF GRAPHICAL USER INTERFACE (GUI)
Any kind of communication, including that between the user and the application, is based on a
language and any language consists of symbols and syntax or the rules for organizing symbols.
The sender and the receiver of a message must agree both on the meaning of symbols and how
they are organized.
The language of the user interface is predominately visual and metaphors constitute the majority
of the symbols in its vocabulary. A metaphor is simply a symbol or an expression that represents
something beyond its literal or immediate meaning.
VISUAL METAPHORS & THEIR ROLES IN THE DESIGN OF USER INTERFACE
Software applications belong to a virtual world but they must rely on real-world metaphors to
communicate with real-world users. The metaphors of the graphical user interface constitute an
ever-growing set: buttons, menus, text boxes, scrollbars, dropdowns, sliders, gauges, icons, tree
views, et cetera. Some metaphors are easy to understand while some need textual explanations.
THE SIGNIFICANCE OF PATTERNS, CONSISTENCY & AESTHETICS IN UI DESIGN
The design of the user interface often consists of solving similar problems. A pattern is the core
of the solution to a problem that occurs repeatedly in an environment.
Instructors Manual

91

The user interface is composed of visual controls that are metaphors. Therefore, the UI designer
must rely on what the user already knows or is reasonably expected to know. Consistency in the
user interface is achieved when the user can predict what kinds of actions produce what kinds of
results. Consistency and predictability of expectations are essential both to the vocabulary and the
syntax of the user interface. Users cannot learn everything from scratch every time they work with
a new application.
The aesthetics of the user interface must be a functional aesthetic. The issues faced by user
interface designers are more similar to those that industrial and graphic designers must solve than
to challenges that artists and fashion designers must confront. In industrial design, function comes
first, beauty second.
MAPPING MESSAGES, PARAMETERS & ATTRIBUTES TO THE USER INTERFACE
The user interface is the concrete realization of messages passed between the actors and the
system. UI design must map messages, their parameters and their return values into UI metaphors.
Therefore, the discovery and the modeling of the application flow, discussed in the previous
chapter, is essential to the correct design of the user interface. We should be aware, however, that
the same flow and the same set of messages can translate into different user interfaces, depending
on the designer or client preferences, the platform, the development tools, and so on.
MODELING FOR UI: NAVIGATION DIAGRAM, STORYBOARDING, SIMULATION &
PROTOTYPING
The user interface requires models that are intelligible to owners and users as well as to analysts,
designers and developers. As classes and objects, the visual building blocks of the application are
no different from entity or control classes and objects, and they can be modeled with the same
UML tools: class, sequence, activity, statechart and other diagrams. Features that are specific to UI
design are layout and navigation. None of the UIs distinctive features can be effectively modeled
with a single tool or a single diagram.
Navigation specifies the sequence of user actions across multiple containers to achieve a goal.
Navigation diagram is an adaptation of statechart diagram that shows what forms or Web pages
are displayed in response to application events. We may use all the extension mechanisms of UML
to make this diagram more suitable for presenting the flow of the user interface.
Storyboarding is to use a sequence of static pictures or drawings to narrate a story. The basics of
storyboarding are straightforward: a set of frames, connected by navigation lines, tells a story or
scenes from a story. The frames can be simple or elaborate, and the same frame can be used to
narrate the same story from a different viewpoint or under different conditions. Storyboarding is a
cost-effective and flexible modeling technique that can be used not only in design, but throughout
the development process.
Prototyping is the creation of a working model for testing and verification of requirements. There
are conflicting definitions of prototyping and conflicting opinions on how useful it is. In an object-
oriented and component-based approach, Prototyping represents an iterative process in which not
the whole application but relatively independent units of it are prototyped and tested. As new
units, or subsystems, are developed, the old units are refurbished and retrofitted to fit within the
evolving structure.
V V. . N Ne ex xt t: : P Pe er rs si is st te en nc ce e & & D Da at ta ab ba as se e
The user interface is only one of the boundaries of the application. The other important boundary
is persistence that is responsible for communication with the database. The database management
Instructors Manual

92

system (DBMS), a major component of the information system, is in charge organizing data,
insuring its integrity, safeguarding its security and making it available to applications.
In the next chapter, we explore the concepts of data and data management, and how to map the
object space to the data space.
1
113
33.
.. A AP PP PL LI IC CA AT TI IO ON N D DE ES SI IG GN N I II II I: : D DA AT TA AB BA AS SE E & & P PE ER RS SI IS ST TE EN NC CE E. .
Database is a major component of the information system. This chapter examines the concepts of
data management and database management systems, database design and the mapping of objects
to the database. It concludes by discussing the persistence layer, a set of design objects that are
responsible for communication between the application and the database.
Learn about data, data management & Database management systems
Understand the relational model & its major components.
Describe database mechanisms that safeguard data integrity.
Learn about encapsulating data management: views, stored procedures & triggers.
Learn the concept & the rules of data normalization.
Describe intersection tables & the issues they address.
Learn about Lookup tables.
Learn the entity-relation diagram (ERD) and Mapping objects to a relational database.
Understand persistence layer & serialization.
DATA & DATA MANAGEMENT
Data are abstract values, but they can be classified in relation to each other and to their contexts.
Data can be quantitative or qualitative, discrete or continuous, categorical or non-categorical,
ordinal or nominal, structured or unstructured, independent or dependent (or derived). An
automated information system can process only quantitative and discrete data. This means that
qualitative or continuous data must be associated with values that are quantitative and discrete
before they can be processed by such a system.
Data management is a crucial subsystem of most information systems. Its main task is storing and
organizing data in a manner that satisfies the needs of the information system as a whole and the
applications individually.
DATABASE MANAGEMENT SYSTEMS
A database is an organized collection of data and a database management system (DBMS) is a
system that administers such a collection for the information system. In the very least, a DBMS
must be able to carry out the following operations: create new entries in the database, retrieve (find
and read) data as required by the applications, update (change) existing entries, and delete
unwanted data.
Instructors Manual

93

An advanced DBMS, however, must do more than these basic operations: it must present an
interface that encapsulates (hides) its internal structure, it must offer a high level language for data
management, and it must safeguard the integrity and the security of data.
THE RELATIONAL MODEL & ITS MAJOR COMPONENTS
The most successful DBMS model in present day information systems in the relational model that
was introduced before object-oriented technologies. A relational DBMS, by hiding the physical
structure of data, presents a logical view of the database organization and provides the basis for
using a high-level language for database management.
DATABASE MECHANISMS THAT SAFEGUARD DATA INTEGRITY
In the context of data management, data integrity is about consistency, correctness and accuracy. A
relational DBMS protects data integrity at four levels: column (or attribute), row (or entity), inter-
table and procedural.
SQL
SQL is the primary language for communication with relational DBMSs. It allows the designer to
create tables, enables users and applications to perform CRUD (create, retrieve, update and delete)
operations, permits database administrators to specify security and privileges, coordinates multi-
user operations, and provides the designers with tools to ensure data integrity.
ENCAPSULATING DATA MANAGEMENT: VIEWS, STORED PROCEDURES & TRIGGERS
Encapsulation and information hiding are the hallmarks of an object-oriented approach: an entity
must offer its services through a public interface but keep its inner workings private. The
advantage of the relational model over its predecessors exposing a logical view of data instead
of physical one serves object-orientation well, but is not sufficient. Data management is not
merely about data organization and maintenance, but also about data security, data integrity,
enforcing business rules and providing data-related services for various applications of the
information system.
Three mechanisms in modern database management systems provide tools that we can employ to
encapsulate data services, to enforce business rules and to protect data security and integrity:
views, stored procedure and triggers.
THE CONCEPT & THE RULES OF DATA NORMALIZATION
Data normalization is a set of guidelines, techniques and concepts to fine-tune a relational database
by establishing logical relationships among attributes and tables and by removing redundancies
that impede effective data management and harm data integrity. They are several normalized
forms that a table can belong to, three of which are essential for a well-designed schema (as the
structural model of a database is called).
Normalization, however, should not be applied blindly. Several factors, including logical
considerations, technological constraints and performance issues may require the designer to de-
normalize certain attributes or tables.
INTERSECTION TABLES & THE ISSUES THEY ADDRESS
An intersection table represents the relationship between two different entities. In an object-
oriented space, objects can have many-to-many relationships with each other regardless of
whether they are instances of the same class (self-referencing) or not. In the relational model, this
is not possible.
Instructors Manual

94

In a relational database, many-to-many relationships must be converted to one-to-many
relationships through intersection tables. In an intersection table, the primary key is usually
composed of foreign keys, provided by entities whose relationship is embodied in the table.
Besides, the number of non-key attributes are often limited.
A self-referencing relationship occurs when two or more entities of the same kind are related. If
the relationship is one-to-one or one-to-many, the issue can be resolved by establishing a foreign
key from the primary key of the same table. Still, the intersection table is the preferred method.
LOOKUP TABLES
A lookup table defines and, often, describes a set of valid values for a given attribute. Rows in a
lookup table do not correspond to entities (or objects), but represent a range of values for a single
attribute in another table, enforced through a foreign key. Lookup tables also can provide
descriptions for categorical data items that are meaningless without descriptions. Optionally, they
can be maintained by users.
THE ENTITY-RELATION DIAGRAM (ERD)
The entity-relation diagram is the primary tool for modeling a relational database. As the name
implies, an ERD presents the properties of entities and the inter-relationships. Unlike UML
diagrams, however, ERD does not have a unified notation. UML, fortunately, provides an efficient
mechanism that can be used to depict ERP and many other diagrams: stereotyping, or the
specialization of modeling elements. Through stereotyping, class diagrams can model the schema
of a database: attributes, tables, primary and foreign keys, multiplicity, relationships and stored
procedures.
MAPPING TO RELATIONAL DATABASES
Mapping objects to a relational database is the application or relational and normalization rules to
classes and their relationships. The process of analyzing and designing an object-oriented
information system should result in classes that already have the essential structural format that we
need for mapping to an RDBMS: attributes that are fused with an entity. What remains is, mostly,
converting the relationships among classes association, multiplicity, inheritance, aggregation
and composition into primary-foreign key pairs or, where it is warranted, into intersection
tables.
PERSISTENCE LAYER & SERIALIZATION
Database management systems are complex subsystems of the information system.
Communication with them requires specialized knowledge of the DBMS and the schema, or the
structure, of the database. Persistence layer is a set of components that manages the interaction
between the application and the DBMS. In a well-designed application, only boundary object that
are specialized for handling persistence should be allowed to communicate with the database.
Persistence saving the state of objects requires serialization, encoding data into a sequential
stream. This stream can then be communicated to the database or to other clients, and can be de-
serialized later to reconstruct objects. A serialized stream can take many formats, including XML
which is fast becoming the standard and can manage both structured and unstructured data.
V V. . D Di is sc cu us ss si io on n N No ot te es s. .
ANOTHER TOPIC, ANOTHER DOMAIN
The striving to find exact terms for concepts must be an inborn human quality, but since we are
not all the same individual, we might mean different things by the same term or might mean the
Instructors Manual

95

same thing by different terms. Therefore, we must learn to find our way out of the confusion by
relying on understanding the context in which a term is used.
We stated that the relational model discarded the term field in favor of attribute or column,
and record in favor of tuple or row (though very few texts actually use tuple.) These
discarded terms, however, are very popular in the industry, both in products and among
practitioners.
Even across the same discipline or academic subject, the same term can have distinctly different
meanings. One of them is domain. We discussed the problem domain and the solution
domain extensively. In this context, domain means an area of activity where the same rules
apply. In the context of Internet, a domain is a sequence of words or characters that identifies a
specific computer or network on the Internet.
In database design, however, domain is a set of valid values for a given attribute. For example,
only numbers 1 through 12 are valid for a Month column (or January, February, etc., if the
column is not numeric.) Or the Gender field (notice how we are committing a transgression against
the relational terminology), can have only one of two values, Male or Female. In a relational
database, the domain of an attribute may be defined by a column in another table ( or The
Foreign Key).
DEFINITIONS OF DATA
To get an overall picture of how the term data is defined, we searched the Web. As expected, the
search yielded a vast amount of literature (including, of course, a great amount of unrelated
documents). By itself, however, such Web searches provide valuable lessons in challenges posed
to data management by what is conventionally called unstructured data. (Among other thing, our
search also brought back a definition for Data, a cybernetic android from the TV series Star Trek:
The Next Generation.)
The following is a selection of what we found:
A collection of facts from which conclusions may be drawn.
1

A datum is a statement accepted at face value (a "given").Data is the plural of datum. A large
class of practically important statements are measurements or observations of a variable. Such
statements may comprise numbers, words, or images.
2

A representation of facts, concepts, or instructions in a formalized manner suitable for
communication, interpretation, or processing by humans or by automatic means.
3

Binary (digital) representations of atomic facts, text, graphics, bit-mapped images, sound,
analog or digital live-video segments. Data is the raw material of a system supplied by data
producers and is used by information consumers to create information.
4

Documented information or evidence of any kind.
5

Factual information used as a basis for reasoning, discussion, or calculation; often refers to
quantitative information.
6

A representation of facts or concepts in an organized manner in order that it may be stored,
communicated, interpreted, or processed by automated means.
7

General term used to denote facts, numbers, letters, and symbols. The basic elements of
information; usually but not always expressed in numerical form.
8

Instructors Manual

96

The sources for the preceding definitions are listed below. As usual, Web is a moving target: by
the time you read this, the links might, or might not be, there:
1. http://www.cogsci.princeton.edu/cgi-bin/webwn.
2. http://en.wikipedia.org/wiki/Data.
3. http://eliteral.com/glossary/decision-support-systems-glossary.php.
4. http://www.cdc.gov/tobacco/evaluation_manual/glossary.html.
5. http://www.ssqi.com/Library/glossary.html.
6. http://www.utmb.edu/is/security/glossary.htm.
7. http://www.reson.com/Gloss-d.htm.
CODDS TWELVE RULES
In 1985, in the trade journal Computerworld, E.F. Codd published twelve rules with which a
database management system must comply to be truly relational. Relational DBMSs are now very
mature and have new issues, such as unstructured and streaming data, to worry about. Reading
Codds rules, however, is still enlightening as they define points that are at the core of data
management.
1. The Information Rule. All data must be presented only at the logical level and in exactly one
way, as values in tables.
2. Guaranteed Access Rule. Any item of data must be accessible without ambiguity by a
combination of table name, the primary key of the row and the column (attribute) name.
3. Systematic Treatment of Null Values. Any cell (the cross-section of row and column), except
those that are part of the primary key, must be able to represent a missing value, or null,
independent of the attributes data type. Null is different from empty or zero, in that it
indicates that the information is missing.
4. Dynamic Online Catalog Based on the Relational Model. The structure of the database and the
metadata (characteristics of attributes), must be accessible through the same tools that manage
the data. In other words, a database must be self-describing. Databases implement this rule
through system tables that hold metadata.
5. Comprehensive Data Sublanguage Rule. The database can support multiple languages for
various purposes, but at least one language must support the following items: data definition,
view definition, data manipulation, constraints, privileges and authorization, and transaction
processing. Though Codd did not specify an specific language, the role of comprehensive
data sublanguage is fulfilled by SQL.
6. View Updating Rule. A view or virtual table is a selected set of attributes (columns) from
various tables that appear as one table to the user or application. This rule stipulates that
updating a view should be indistinguishable from updating actual tables. Contrary to Codds
wishes, however, this not often possible.
7. High-Level Insert, Update, and Delete. Database operation must not be limited to single rows,
but must allow the user to insert, update and delete, as well as read, rows that belong to a
logical set.
8. Physical Data Independence. Changes to the physical organization and the location of the
database must not change the logical view presented to the databases users.
9. Logical Data Independence. How a user views data should not change when the logical
structure (tables structure) of the database changes. This rule is particularly difficult to satisfy.
Most databases rely on strong ties between the user view of the data and the actual structure of
the underlying tables.
[Groff 1999, 61-64]
Instructors Manual

97

10. Integrity Independence. Integrity constraints must be definable in the primary database
sublanguage (SQL in practice), and the database must be able to store them independent from
any application.
11. Distribution Independence. The logical view should remain isolated from the physical
distribution of the database.
12. Non-Subversion Rule. Low-level and administrative tools must not be able to bypass
constraints imposed by the higher-level database language.
V VI II I. .N Ne ex xt t: : P Pa at tt te er rn ns s
A good grounding in theory and methodology is the necessary starting point for building solutions.
Developing effective solutions, however, also requires experience, both in general and in the
particulars of the problem at hand. When we encounter a problem for which we must devise a
solutions, it is possible that somebody else has experienced something similar before.
Patterns are how we can learn from other peoples experience. A pattern is not a recipe that can be
followed uncritically, or a general-purpose theory from which specific solutions can be derived,
but the core of the solution to a problem that is encountered repeatedly. In simple terms, patterns
help us to build wheels without reinventing them.
Instructors Manual

98

1
114
44.
.. P PA AT TT TE ER RN NS S
A pattern provides the core of the solution to a problem. Pattern is the core of the solution to a
problem that occurs repeatedly in an environment. Patterns are neither methodologies nor recipes.
This chapter discusses patterns in general and presents examples that apply to different activities
of software development. Patterns are presented as ready-made solutions. If the context that
underlies the pattern is not properly understood or the context changes, the proposed solution
might instead create more problems.
I II I. . C Ch ha ap pt te er r T To op pi ic cs s
Describe concepts of pattern & pattern language.
Learn about design patterns.
Describe analysis patterns.
Learn how to model patterns.
Understand the anti-patterns.
CONCEPTS OF PATTERN & PATTERN LANGUAGE
Methodologies paint the development process in broad brushstrokes and stay clear of specific
problems. Recipes or cookbooks, on the other hand, are about very specific problems.
Like use cases, patterns must be described in an essentially literary form. No standard format for
defining patterns exists. Any pattern template, however, should reflect a set of ideas that are
essential to the proper understanding of the pattern:
Patterns must be used only with a thorough understanding of the problem, the context and the
consequences of applying the pattern.
DESIGN PATTERNS
Any activity in software development can benefit from patterns, but the most well-known and
elaborated are design patterns. Design patterns are usually classified based on the type of the
problems that they address. They include creational, structural, behavioral, data access and
architectural patterns.
ANALYSIS PATTERNS
Design patterns appeared first and are the most popular. Like any other activity which involves
solving problems, however, analysis can also benefit from the application of patterns.
MODELING PATTERNS
Modeling pattern relate neither to the problem domain nor to the solution-as-answer, but to
modeling that is a component of methodology or solution-as-method.
ANTI-PATTERNS
Whereas patterns consist of problem-solution pairs, an anti-pattern is a pair of two solutions: the
first solution the one that leads to failure is called the problematic solution; the second is
Instructors Manual

99

referred to as the refactored solution. The refactored solution is a commonly occurring method
in which the [anti-pattern] can be resolved and reengineered to prevent failure and increase the
chances of success.
V. D Di is sc cu us ss si io on n N No ot te es s
PATTERNS WITH NINE LIVES
Ever since communities larger than small villages appeared in other words, with the emergence
of civilization the search for large indoor spaces has been ongoing. The intentions have been
many: religious ceremonies, display of the royal might, sports, et cetera. The challenge, however,
has been the same: how to support a sizeable ceiling. The first pattern to spread was the column
solution, as the magnificent Egyptian and Greek monuments demonstrate. But the column solution
has drawbacks: columns take up space, break the line of the vision, and need sturdy and expensive
material such as stone that must be laboriously cut and, sometimes, transported at great distances.
The popularity of the dome pattern started around early Roman times but spread rapidly in the
Roman Empire and in the Middle East. (The origins of large domes is still a matter of dispute
among the historians.) Dome needs a more sophisticated design but requires less expensive
material and provides an unobstructed view.
Columns, of course, did not disappear: they remained in use, sometimes as mostly decorative
elements and sometimes in combination with dome. Modern architecture relies on columns to
support massive skyscrapers, which prove that some patterns can outlast profound technological
changes.
V VI II I. . N Ne ex xt t: : C Co om mp po on ne en nt ts s & & R Re eu us se e
Patterns allow you to reuse prior experience. Patterns, however, are not prefabricated parts that
you can assemble into a product by following steps from a manual: you might thoroughly study
the Dome pattern for constructing large spaces but if you want to build such a space, you must
adapt the principles of the pattern to the particulars of your specific project.
To reuse ready-made solutions, we must turn to inheritance and components, which we will
discuss in the next chapter.
Instructors Manual

100

1
115
55.
.. C CO OM MP PO ON NE EN NT TS S & & R RE EU US SE E
The concept of reuse covers a vast territory, from patterns that provide us with the successful
results of the past experience, to readymade building blocks that often do not require us to know
anything about their internal workings. Two of the major reuse concepts, components and
inheritance, are discussed in this chapter.
Describe areas of Reuse.
Understand implementation and interface inheritance.
Learn about emulating Inheritance by Composition.
Define components and the modeling Components.
Learn about component-Based Development (CBD).
AREAS OF REUSE
Reuse, where possible, has two major benefits: it makes the product less costly because the same
solution does not have to be reinvented repeatedly, and it makes the product more reliable since a
reusable element is tested in different contexts.
Reuse is not limited to one aspect of the development or the product. Components are the most
reliable and effective mechanism for reuse since they provide black boxes that can be assembled
with no change. Patterns encapsulate experience in solving problems and, consequently, can be
labeled as experience reuse. Inheritance is a specifically object-oriented technology that allows
the descendents of a class to reuse its behavior, with or without modifications. Web services can
be described as components on the Web: they provide services across the Internet or intranets
and the consumers can ignore how the services are rendered. The aim of methodology is to reuse
abstract ideas as guidelines for discovering solutions on your own. Refactoring is the
consolidation of analysis, design or implementation artifacts to eliminate useless redundancy.
Source code reuse is usually discouraged but can be valuable in providing examples for learning.
Finally, development frameworks provide templates, bare skeletons that can be expanded into full
solutions.
IMPLEMENTATION INHERITANCE
Inheritance is one of the basic concepts of object orientation: an object can be a specialized type of
another object. Inheritance, however, is also a mechanism. The first type of this mechanism is
implementation inheritance, also called subclassing, by which a subclass (or child) can reuse,
extend or override the attributes and the operations of its parent without starting from scratch.
The subclass may change, limit or block the implementation of a service offered by its parent. This
is called overriding. It may also add attributes and/or operations that do not exist in the superclass.
This is called extension.
Instructors Manual

101

INTERFACE INHERITANCE
The second type of inheritance is interface inheritance. It is a mechanism by which multiple
classes share one interface but implement that interface independently of each other or of the
parent class. Unlike the implementation inheritance where the subclass inherits both the interface
and the functionality of its parent for specialization, the purpose of interface inheritance is to arrive
at a subclass that looks exactly like its parent but performs the services its own way.
Besides sharing an interface with other classes, a class might implement multiple interfaces,
regardless of whether any of the interfaces are shared with others or not. Multiple interfaces may
become necessary for many reasons, including complexity of the services that one class may offer,
security to ensure that other entities only see what they are allowed to, multiple functionality, and
change when the class must offer new services but must keep the existing contracts in place.
EMULATING INHERITANCE BY COMPOSITION
Multiple implementation inheritance is a well-established concept. Many popular development
platforms, however, do not support it. The reasons are usually not only technological, but also
logical. Single and multiple inheritance, however, can be emulated through composition. In fact,
many prefer composition to inheritance regardless of whether the technology supports inheritance
or not.
The composition approach is also called black-box reuse since the internal details of a class are
not exposed to subclasses. Reuse by composition is dynamic. How a service is performed is
decided by the object at runtime, and by the object only, not by its parent or parents.
Reuse by composition must rely on abstract interfaces to be workable. An abstract interface
hides the internal composition of a composite object and allows the object to change its behavior
without adversely affecting its clients.
COMPONENTS
A component is a relatively independent, encapsulated and replaceable unit of software that
provides services specified by one or more interfaces. Even though a component is not necessarily
reusable, it is the ideal method for creating flexible systems.
Components are not the same as objects. A component might be composed of one object, many
objects, or no objects at all. The other important difference is the binary nature of components:
components are language-neutral, while objects are language-dependent.
MODELING COMPONENTS
The standard UML icon is a box with two tabs, similar to a plug. Components, however, can also
be represented by stereotyped boxes. A component can be modeled both as a black box that
hides its internal structure, and as a white box that exposes that structure.
The component diagram models the interactions between components. Since one component may
support multiple interfaces and each interface has an independent connector, the component
diagram shows the use of each interface separately. Component diagrams are also known as
wiring diagrams since they show how different parts of the system are wired together.
COMPONENT-BASED DEVELOPMENT (CBD)
The term component-based development applies both to development with components and the
development of components. In either case, the required methodology goes beyond the traditional
analysis, design, implementation and testing activities and involves packaging, integration,
versioning, and creating installation programs.
Instructors Manual

102

The technology for supporting components is mature, but other factors influence its success and
adoption, including issues such as usability vs. reusability, the difficulties of developing domain
components as opposed to design components, the respective advantages and disadvantages of
building components versus buying them, and the optimization of methodology.
Component-based development also impacts project management. Milestones should include
delivery of components and the dependencies between components must be taken into account. On
the plus side, CBD allows multiple development teams to work in parallel, something without
which large and complex development projects have no realistic chance of success in an
acceptable timeframe.
V VI I. . N Ne ex xt t: : A Ar rc ch hi it te ec ct tu ur re e
An information system is composed of components that are interrelated and interact with each
other and the outside. So far, we have discussed the components and their interactions, both from
inside the system and with the outside. The grand view of these components and how they grouped
and arranged is the subject of architecture.
Instructors Manual

103

1
116
66.
.. A AR RC CH HI IT TE EC CT TU UR RE E
The design of the solution cannot proceed from the parts to the whole. Before we can build the
nuts and the bolts of the solution, and before we can fasten them together, we must make
architectural decisions and we must conceive of the overall framework that connects and organizes
the pieces. The architecture of the information system is composed of not one but several
overlapping frameworks that must cooperate to make the system work. An introduction to these
frameworks and other architectural concepts and patterns is the subject of this last chapter on
design.
Define architecture & architectural elements.
Learn about methodology, patterns and architectural views.
Describe the relationship of engineering to architecture.
Describe the significance of coupling to architecture.
Learn about architectural modeling and UML.
Define technology architecture.
Describe architecture of components, Web services & applications.
Understand service-oriented architecture & Web services.
Describe data management architecture.
Define workflow architecture.
Learn about architectural patterns and the layering pattern.
AN INTRODUCTION TO ARCHITECTURE & ARCHITECTURAL ELEMENTS
Architectural decisions are the most important design decisions; i.e., they decide the most
important aspects of the solution. To understand architecture, we must first gain a good knowledge
of the nuts and the bolts of the solution, but the design of the product must start with architecture
because it is the architecture that decides the fate of every nut and every bolt.
The importance of architecture, however, works against a clear definition since various definitions
might view it from widely different viewpoints without even contradicting each other. What is
more, the term architecture can apply to both the actual product and an abstraction of it. In other
words, architecture can be seen both as O the organization of a systems major components and
the relationships of these components to each other and to the whole, or as O how such an
organization and/or its development is viewed or modeled.
An actual architecture is defined by the configuration of architectural elements: components,
messages and connectors. We have studied components and messages. Connector, however, is
a new term. The connectors are mechanisms through which components are connected together or
communicate with each other. A message is (relatively) technology-independent, whereas
connectors are technology-dependent but are independent of messages. Connectors work as
conduits for messages.
Instructors Manual

104

METHODOLOGY, PATTERNS AND ARCHITECTURAL VIEWS
Architecture as the actual organization of a system is a subject of patterns; architecture as a way to
view the system or its development is an area of methodology.
How an architecture combines or uses patterns is called its style. Another architecture might
combine all or some the same patterns in a different style. In other words, style is how a
combination of architectural elements and patterns make a certain architecture different from, or
similar to, other architectures.
In discussing architecture, the term framework has more currency than methodology because
Methodology has come to imply a roadmap or a plan, while framework points more towards a
structure within which a certain freedom of choice exists. Architectural frameworks usually avoid
specifying processes and roadmaps. Instead, they aim to identify what is necessary or best O to
make an architecture take shape, and O to make its meaning comprehensible to all stakeholders,
from owners to builders.
The main tools in this mission are usually called architectural views. An architectural view is a
representation of the system that is shaped by four factors: what, who, when and where. By
representation we mean modeling in a very broad sense, as the systematic representation of the
relevant features of a product or a system from particular perspectives. The difference between a
model and an architectural view is that the latter may consist of one model or several. Views may
also share models.
THE RELATIONSHIP OF ENGINEERING TO ARCHITECTURE
For a while, engineering was seen as the Holy Grail of software development: if we could apply
engineering principles to software, then the software crisis would be over. That time is past and
the mantle has been passed to architecture. However, if we can break through the hype, past and
present, we will find that software engineering is a valid concept if our expectations are adjusted
somewhat: Engineering is the application of architectural concepts to the building of the actual
product.
To engineer is to understand the conceptual solution, to participate actively in outlining the logical
solution and to devise the physical solution in essential details.
THE SIGNIFICANCE OF COUPLING TO ARCHITECTURE
Architecture is about composition. When we think about architecture, we must think how things
are connected, not what we will end up with if we decompose the structure. Coupling is the extent
of dependency among the components from which the system is composed. Generally, a loosely
coupled system has advantages over a tightly coupled one, but other factors such as structural
strength, performance, maintenance, and cost should be taken into account as well.
To loosen coupling in software, we can use certain mechanisms that we have discussed in previous
chapters: signal events, abstract interfaces, component-based architecture and patterns such as the
Object Adapter.
ARCHITECTURAL MODELING AND UML
Architectural views need descriptions and models that are not provided by UML. Plus,
architectural views are independent from both the process of development and modeling
languages. UMLs standard diagrams and extensibility mechanisms, however, can satisfy many of
their visual demands. The only exception is when or where a framework is not object-oriented; for
example, when a framework considers data and function as separate concepts.
Instructors Manual

105

An important issue in architectural modeling is view management: how to keep the models that
result from the selection of what, who, where, and when connected and in sync. UML
offers two stereotyped relationships for view management: trace that indicates historical
dependency between models and refine that show a model as a less abstract version of another
one. These two mechanisms, however, only address the when and the what of the architectural
view. UML does not effectively address the who and the where.
TECHNOLOGY ARCHITECTURE
The architecture of an information system is an aggregation of the architectures of its components.
Therefore, it must be characterized as a heterogeneous and cooperative architecture, not as
centralized one.
A set of forces compete and cooperate to change the architecture of an information system during
its lifetime. The architecture of an information system is made possible and constrained by the
information technology.
Centralized architecture predates other technological architectures since computers, unlike
telephones, do not need a network of their kind to perform their basic tasks. In a centralized
architecture, all services depend on one computer system. When networks did not exist, this
architecture was the only available choice, but centralized computing has not disappeared. Among
others, most desktop computers used at homes can be considered as centralized.
In a distributed architecture, two or more computers on a network cooperate to perform services.
Distributed architecture took shape only gradually. LANs (Local Area Network) and WANs (Wide
Area Networks) were first used for file sharing, not for hosting a distributed software architecture.
The client-server architecture (CSA) was made possible by the evolution of networks and
provided the real break from centralized architecture. In the CSA model, one or more servers
provide services that are consumed by the client computers. Database management, Web hosting
and application services are the most prominent tasks usually performed by dedicated servers, but
the list includes other services as well. Distributed network architecture must not be mistaken with
distributed software architecture.
ARCHITECTURE OF COMPONENTS, WEB SERVICES & APPLICATIONS
The architecture of software or the organization of components is constrained by the architecture
of technology but it is not dictated by it.
An application can be defined as a logical grouping of components that cooperate to perform a
specific task. While how components are organized is eventually physical, the architecture of an
application remains logical and can be mapped to various physical configurations of components.
A monolithic application is a self-contained component that does not rely on other components
and cannot be reused, in part or in whole, by other applications. No modern application is truly
monolithic as it must rely on the services of the operating system. Still, the label can be applied to
applications that consist of only one component.
In a distributed software architecture, software components cooperate and interact across a
network to perform services. (However, an application composed of multiple components, like
most desktop application is not necessarily a distributed application, but simply a multi-
component application.) In theory, distributing components across servers enhances performance
and reduces installation issues. In practice, the distribution of application-specific components, as
opposed to general-purpose subsystems such as the database management system, has not been
very successful. We must not undertake a distributed software architecture just because the
technology is there. A viable alternative to this approach is clustering and load-balancing.
Instructors Manual

106

SERVICE-ORIENTED ARCHITECTURE & WEB SERVICES
Service-oriented architecture (SOA) aims to compose applications from platform-independent
services of virtual components. SOA envisions an application as a very loosely coupled
cooperation between services that can be rendered and consumed transparently across a network,
regardless of specific platforms that the nodes implement.
A virtual component is a component that O relieves its consumers from the issues of its physical
identity, and O complies with universally accepted standards instead of following proprietary
protocols. The technology choice for virtual components has generally come down to Web
services. A Web service is a virtual component that offers its services via standard Web protocols.
The adoption of Web services is gaining momentum. It offers one great benefit: it allows utterly
disparate system to communicate with each other over the existing Internet by using standard Web
protocols. However, besides performance penalties associated with any distributed scheme, Web
services are stateless. As a result, it is the responsibility of the clients to keep state and ensure the
integrity of transactions.
DATA MANAGEMENT ARCHITECTURE
We usually buy a DBMS to build an information system, but we must still make crucial architectural
decisions on how to use it. Nowadays, because of its complexity, a database management system
is always a separate subsystem. Some business models require that the database itself be
physically distributed. Distributed databases, however, have huge issues, such as synchronization,
that dwarf the problems that you encounter in dealing with distributed components.
Another area in which the data management architecture presents us with challenges is data
warehousing. In a nutshell, data warehousing is used when the intention is not the creation of a
new system instead of others or integrating an existing system, but when a large amount of data
from disparate sources must be made accessible in a uniform format for analysis, reporting and
decision support systems.
WORKFLOW ARCHITECTURE
Workflow influences the architecture of the information system and is, in turn, influenced by the
architecture of information technology. A keen architect must take into account how the workflow
and the human organization would affect the new system and vice versa. Is the workflow
envisioned by the clients rational and makes the best use of the system, or it is distorted because
the client does not know better or does not want to do better? Would the organization be able to
support the resulting workflow and the requirements of the new system? What organizational
changes are necessary for the new system or would follow its introduction?
ARCHITECTURAL PATTERNS AND THE LAYERING PATTERN
Architecture is essentially a pattern-driven activity. This means that although a certain pattern for
designing an architecture may apply to the majority of situations and therefore comes close to
becoming a rule, no architectural guideline can be applied with disregard for the actual situation.
What is more, since an information system is an aggregation of several subsystems, usually no
single pattern or guideline can apply to all subsystems.
Layering is one of the most common patterns used in software architecture. A layer is a collection
of components that provide similar services or are highly dependent on each other for performing
their services. The basic idea is simple: to manage a complex architecture, aggregate components
that perform the same kind of services, plus components that support them, into distinct layers. In
such a structure, horizontal layers embody a hierarchy: the lower layer supports the upper layer
and the upper layer relies on the services of the lower one.
Instructors Manual

107

Layers can be both horizontal and vertical. Vertical layers run across all horizontal layers, control
them, sometimes use their services and, most importantly, connect the layers together.
The relationship between conceptual, logical and physical layers is not necessarily one-to-one. For
a number of reasons, a conceptual layer might not become a logical or a physical layer. (A
physical layer on a separate server is called a tier; hence the terms two-tier, three tier, and n-
tier.) Nevertheless, conceptual layering is always useful, regardless of whether it is implemented
as physical layers or not. At the very least, it is an incentive to clearly define what kind of
responsibilities your classes must have.
WHO IS AN ARCHITECT?
A flippant answer to this question is that architect is someone who architects. Unfortunately, that
might be also the most reasonable answer that we can find, for if we summarize everything that we
read about the architect, we must come to the conclusion that an architect is part genius, part saint
or somebody whom the management considers as such and pays accordingly: capable of high
abstraction and yet highly knowledgeable about detail and technology, skillful in communicating
the architectural vision to both technically challenged stakeholders and business-challenged
developers, tolerant of misunderstandings, patient with the slow-witted, honest with the high and
the low, charitable, a dreamer with both feet firmly on the ground, and so on.
Geniuses and saints are hard to come by separately, let alone in one package. Fortunately, mere
mortals can do the job, given the right talents, tempered and nourished by experience and study of
patterns.
Yes, the architect must keep the high vision of the system untainted by petty detail, while knowing
enough about the particulars of the technology and the task at hand to prevent the abstract and the
concrete from harming each other. This capability, however, is not inborn (unless, of course, one is
a genius); rather, the prospective architect must, at some point in his or her career, get a good
grounding in the mundane tasks of software development to be able to distinguish between wishful
thinking and realistic visions.
During most of the short history of software development, architects did not exist because
architecture did not exist. Information system architecture, if it could be called that, appeared from
snap and ad hoc decisions and choices, often made by programmers who had no other choice but
to take the responsibility. Then the demands on software became more complex and theoretical
writings on software architecture started to appear. Management took notice and took action by
battlefield promotions of programmers to architects.
Good programmers must be good problem solvers with mastery of their tools and infinite patience
with detail. To be good architects, however, these qualifications are not enough. This does not
mean that a programmer is somehow, by nature, unqualified to become an architect, but it means
that architecture is a discipline in its own right, not an outgrowth of programming.
Who, then, is an architect? Someone who is able to think architecturally, has the experience and
the knowledge to do so realistically, and has the aptitude to do it creatively. Still not an exact job
description, but true.
LUDDITES FOREVER!
Participating in innovations often has morally ambiguous consequences. Between 1811 and 1816,
England witnessed a series of riots. Textile workers, afraid of losing their jobs by the introduction
of labor-saving machinery, smashed many of them. Their were named after Ned Ludd, an
Instructors Manual

108

eighteenth-century worker who was reputed to have done the same thing. Since then,
technophobes have been called Luddites.
In early 1990s, the city council in Brussels, Belgium, imposed a special tax on computers. (We
read this story in The International Herald Tribune but are quoting it from memory, so the
specifics might not be accurate.) Businesses were ordered to attach a label to their computers that
certified the payment of the tax. Asked to justify the levy, the spokesperson replied, apparently
with a straight face, that since computers cost people jobs, it was only right that businesses with
computers should contribute to their safety nets.
Technophiles are usually more successful in having their voices heard than technophobes. (After
all, they do not have an aversion to using technology to express their opinions.) For this reason, the
term Luddite has taken a completely derogatory meaning and has been thrown at anybody that
has questioned not only a certain technology but even how it is used.
The quandary is that there is often some justification to the arguments of both sides. Many English
laborers did lose their jobs and suffered as a result, but the new machines did help England to
become the most successful textile manufacturer in world and the most prosperous country in the
history until then.
We have seen the effects of computerization first hand. A little earlier than the Belgian story, we
built an automated system for a manufacturing company. A week after the system was introduced,
several desks on the floor where we worked were emptied from the same people who had helped
us to write the system. (We did not change careers, however.)
V VI I. . N Ne ex xt t: : N Ne ex xt t I Im mp pl le em me en nt ta at ti io on n. .
Architecture is not a set of models, as correct or as beautiful they might be. Neither are all other
analysis and design artifacts an exercise in abstraction. Models are essential to development, but
they must eventually lead to an actual product. The activity that turns ideas, models and
abstractions into the product is called implementation. It has issues, challenges and concepts that
are its own and are not an extension of those that belong to analysis and design. Two of the most
important activities in implementation are coding and testing, though even with successful coding
and testing, the job of development is not really finished: you must deploy the product and verify
that it works in the problem domain, the context for which the solution was intended. Remember
that understanding the context, or domain analysis, is where the development starts. In the next
chapter, we close the circle. Almost.
Instructors Manual

109

1
117
77.
.. I IM MP PL LE EM ME EN NT TA AT TI IO ON N. .
The process of development starts with gathering requirements and analysis, and continues with
design. It is concluded by implementation, a range of activities including programming, testing,
deployment and maintenance. This chapter provides a short introduction to these activities.
Define coding.
Describe programming languages & tools.
Learn about coding standards & code review.
Describe testing & its variations.
Learn about deployment & the deployment diagram.
Learn about user training.
Understand maintenance.
CODING
Coding is the realization of analysis and design: no code means no software. On the other hand,
coding without robust analysis and design cannot lead to quality software. Both sides of the
equation are equally important.
The more accurate the design is, the less complicated coding would become. Errors in design are
more costly to correct than errors in coding, but no design is perfect. Some design defects are not
predictable and can be only discovered through coding and testing. As important as analysis and
design are, coding should not be taken for granted. High-quality software cannot result from low-
quality code.
PROGRAMMING LANGUAGES & TOOLS
Although the programming language should be technically high quality, the choice of the
programming language depends on many factors. For components such as database management
systems, you must often use the language or the dialect that they require. If you create Web
applications, you cannot ignore the languages that browsers require. Sometimes the existing
framework and available resources constrain the freedom of choice for the programming language.
Furthermore, the methodology that you follow for development must be translatable to the
programming language.
Programming requires multiple tools to achieve its goals. Integrated development environments
aim to create one command center for conducting all or most programming activities.
CODING STANDARDS & CODE REVIEW
For teamwork, debugging and maintenance, coding standards are of utmost importance. The
primary reason for adopting a set of coding standards is to make it easier for developers to read
and understand each others code.
Instructors Manual

110

Code review is often neglected but, among other things, it is a major tool for enforcing standards.
There are two types of code review: walkthrough and inspection. Walkthrough is less formal and
essentially consists of going over the lists of questions and/or possible defects provided by the
participants. Inspection, on the other hand, is more formal and consists of going over code line-by-
line.
TESTING & ITS VARIATIONS
Quality assurance must be built into the process of product development, but testing is the last line
of defense against defects. Testing, however, is not a single activity; software must be tested for
each phase of implementation and deployment.
Unit testing is testing the smallest piece of software with an identity. In object-oriented
technology, unit testing applies to individual classes that, however, must be tested along with other
classes that they depend on.
A component is a relatively independent, encapsulated and replaceable unit of software that
provides services specified by one or more interfaces. Component testing is only meaningful if
the softwares architecture is component-based. It does not replace unit testing, but extends it.
Integration testing is a continuation of component testing but verifies how the components work
in relation to each other, and every component has to be tested again once a new component is
integrated into the whole.
System testing is conducted when all components of a system or subsystem are in place. And a
product passes acceptance testing when the people who have paid for its development accept it.
Object-oriented analysis, design and technology can reduce bugs, but not automatically. It can
even produce its own kind of unwanted side effects; encapsulations makes testing the inner
workings of an object more difficult, inheritance can create complex inheritance trees, and
message sequencing can make systematic examinations of messages confusing.
DEPLOYMENT & THE DEPLOYMENT DIAGRAM
Deployment covers all activities that make the software available for use. These activities include
release, installation, updating and adaptation.
Deployment diagram, the last major UML tool, is used to visualize the static aspect of the physical
nodes and their relationships and to specify their details for construction. This diagram is not
specifically about hardware, but about how the software is configured in relation to hardware.
Deployment diagram is a structural diagram that depicts the relationship between nodes. A node is
a physical element that exist at run time and that represents a computational resource, generally
having at least some memory and, often times, processing capability. You can use stereotyping
and other UML extension mechanism with the deployment diagram.
In one important aspect, the deployment diagram is very different from a class diagram: the
deployment diagram can be instantiated. This means that it can represented instances of nodes,
not just their classes.
USER TRAINING
People use applications to perform tasks. These tasks are modeled through use cases and,
therefore, use cases provide effective templates for user training. However, one kind of training is
not enough; nor it can fit every situation. The exact nature of training depends on what the user is
to be trained for, who the user is, and where the training is to place.
Instructors Manual

111

The primary tool for training the user is the user interface, its design, its flow and the tools that it
can exploit to help and guide the user. A wizard employs a user interface that guides the users,
step-by-step, through simple forms or pages. However, it can be time-consuming and annoying to
experienced users.
Online help, context-sensitive or otherwise, is nowadays expected from all applications. Online
help should be organized in a way that allows the user to read the topics from the beginning to the
end, select topics from a table of contents, and find topics through searching by keywords.
Training can also benefit from user guides and tutorials. Tutorials can be interactive applications
in their own right, but not every kind of application lends itself to interactive tutorials.
If trial-and-error is not an option in learning to operate an information system or an application,
then it must be taught through simulators. Creating a simulator is often an expensive undertaking,
but it must be done when the mission of the system demands it.
User training can be rounded up by classes and workshops. However, whereas the users of in-
house software and vertical applications can be required to attend workshops and classes before or
after deployment, classes for mass market applications form an aftermarket.
Increasingly, the potential of Web is being used for training through Webcasts, chat rooms and
online courses.
MAINTENANCE
Software should never be designed under the illusion that it can be perfect and will never change.
Maintenance may not be a term that is really appropriate for software, but what it implies is
unavoidable: things changes and software that is already in use must be fixed, upgraded or
replaced. Maintenance becomes necessary for a variety of reasons, including: engineering defects,
failures in analysis and design, obsolescence, change of requirements and expectations, and
competition.

Students Notes

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Students Notes

Enviado por

Direitos autorais:

Formatos disponíveis

OBJECT-ORIENTED SYSTEMS ANALYSIS & DESIGN

Você também pode gostar