Students Notes

OBJECT-ORIENTED SYSTEMS ANALYSIS & DESIGN Instructor’s Manual

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

OOBBJJEECCTT--OORRIIEENNTTEEDD SSYYSSTTEEMMSS AANNAALLYYSSIISS && DDEESSIIGGNN

TTaabbllee ooff CCoonntteennttss

CChhaapptteerr 11.. IInnffoorrmmaattiioonn SSyysstteemmss..

Overview ................................................................................................................ 8

Objectives .............................................................................................................. 8

Outline.................................................................................................................... 8

Review Questions & Answers .............................................................................. 11

Research Projects & Teamwork ........................................................................... 12

Discussion Notes ................................................................................................. 13

Next: The Concept of Object Orientation. ............................................................ 13

CChhaapptteerr 22.. TThhee CCoonncceepptt ooff OObbjjeecctt OOrriieennttaattiioonn..

Overview .............................................................................................................. 15

Objectives ............................................................................................................ 15

Outline.................................................................................................................. 15




Next: Methodology. .............................................................................................. 21

CChhaapptteerr 33.. MMeetthhooddoollooggyy..

Overview .............................................................................................................. 23

Objectives ............................................................................................................ 23

Outline.................................................................................................................. 23




Next: Gathering Requirements. ............................................................................ 31

OBJECT-ORIENTED SYSTEM ANALYSIS & DESIGN Instructor’s Manual


CChhaapptteerr 44.. GGaatthheerriinngg RReeqquuiirreemmeennttss..

Overview .............................................................................................................. 32

Objectives ............................................................................................................ 32

Outline.................................................................................................................. 32




Examples. ............................................................................................................ 38

Next: Domain Analysis ......................................................................................... 43

CChhaapptteerr 55.. DDoommaaiinn AAnnaallyyssiiss..

Overview .............................................................................................................. 44

Objectives ............................................................................................................ 44

Outline.................................................................................................................. 44




Examples. ............................................................................................................ 53

Next: Behavioral Modeling II – Use Cases: The Basics ....................................... 56

CChhaapptteerr 66.. BBeehhaavviioorraall MMooddeelliinngg II –– UUssee CCaasseess:: TThhee BBaassiiccss..

Overview .............................................................................................................. 58

Objectives ............................................................................................................ 58

Outline.................................................................................................................. 58




Next: Behavioral Modeling II – Developing Use Cases ........................................ 65

CChhaapptteerr 77.. BBeehhaavviioorraall MMooddeelliinngg IIII –– DDeevveellooppiinngg UUssee CCaasseess..

Overview .............................................................................................................. 67

Objectives ............................................................................................................ 67

Outline.................................................................................................................. 67






Examples ............................................................................................................. 72

Next: Structural Modeling ..................................................................................... 79

CChhaapptteerr 88.. SSttrruuccttuurraall MMooddeelliinngg..

Overview .............................................................................................................. 80

Objectives ............................................................................................................ 80

Outline.................................................................................................................. 80




Examples. ............................................................................................................ 88

Next: Dynamic Modeling ...................................................................................... 92

CChhaapptteerr 99.. DDyynnaammiicc MMooddeelliinngg..

Overview .............................................................................................................. 93

Objectives ............................................................................................................ 93

Outline.................................................................................................................. 93




Next: The Design Challenge ............................................................................. 101

CChhaapptteerr 1100.. TThhee DDeessiiggnn CChhaalllleennggee..

Overview ............................................................................................................ 102

Objectives .......................................................................................................... 102

Outline................................................................................................................ 102

Review Questions & Answers ............................................................................ 104

Research Projects & Teamwork ......................................................................... 104

Discussion Notes ............................................................................................... 106

Next: Application Design I: Flow & Control......................................................... 107



CChhaapptteerr 1111.. AApppplliiccaattiioonn DDeessiiggnn II:: FFllooww && CCoonnttrrooll..

Overview ............................................................................................................ 109

Objectives .......................................................................................................... 109

Outline................................................................................................................ 109




Examples. .......................................................................................................... 114

Next: Application Design II: The User Interface ................................................. 117

CChhaapptteerr 1122.. AApppplliiccaattiioonn DDeessiiggnn IIII:: TThhee UUsseerr IInntteerrffaaccee..

Overview ............................................................................................................ 118

Objectives .......................................................................................................... 118

Outline................................................................................................................ 118



Next: Application Design III: Database & Persistence. ....................................... 121

CChhaapptteerr 1133.. AApppplliiccaattiioonn DDeessiiggnn IIIIII:: DDaattaabbaassee && PPeerrssiisstteennccee..

Overview ............................................................................................................ 122

Objectives .......................................................................................................... 122

Outline................................................................................................................ 122




Examples. .......................................................................................................... 128

Next: Patterns .................................................................................................... 130

CChhaapptteerr 1144.. PPaatttteerrnnss..

Overview ............................................................................................................ 131

Objectives .......................................................................................................... 131

Outline................................................................................................................ 131






Next: Components & Reuse............................................................................... 134

CChhaapptteerr 1155.. CCoommppoonneennttss && RReeuussee..

Overview ............................................................................................................ 135

Objectives .......................................................................................................... 135

Outline................................................................................................................ 135



Next: Architecture .............................................................................................. 139

CChhaapptteerr 1166.. AArrcchhiitteeccttuurree..

Overview ............................................................................................................ 140

Objectives .......................................................................................................... 140

Outline................................................................................................................ 140




Next: Implementation .......................................................................................... 148

CChhaapptteerr 1177.. IImmpplleemmeennttaattiioonn..

Overview ............................................................................................................ 149

Objectives .......................................................................................................... 149

Outline................................................................................................................ 149




111... IINNFFOORRMMAATTIIOONN SSYYSSTTEEMMSS

II.. OOvveerrvviieeww

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.

IIII.. CChhaapptteerr OObbjjeeccttiivveess

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.

IIIIII.. CChhaapptteerr OOuuttlliinnee

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).



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

15th 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.



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.



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 (today’s 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 11th 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.

Automation: the assembly line moved instead of workers.

Continuous Flow: the line did not stop.

Division of Labor: each worker was trained for a specific operation.



Interchangeable Parts: the parts were standard, not customized.

Modern manufacturing has streamlined Ford’s methodology, but has not replaced it.

VVIIII.. NNeexxtt:: TThhee OObbjjeecctt--OOrriieenntteedd CCoonncceepptt..

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.



222... TTHHEE CCOONNCCEEPPTT OOFF OOBBJJEECCTT OORRIIEENNTTAATTIIOONN


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.

IIII.. CChhaapptteerr OObbjjeeccttiivveess..

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).

IIIIII.. CChhaapptteerr OOuuttlliinnee..

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.



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 object’s 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



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: something that mirrors a concept, something that

simulates a real thing, and something that is practically, essentially or effectively so, but not in

(absolute) fact. None, however, is limited to information systems, software or otherwise.



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.

CCOONNCCEEPPTTSS

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 (―I’ll 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.



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 receiver’s 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 clan’s 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 men’s concept of

Tiger were attributes to specify the state of the tiger: Old and Decrepit as opposed to Young and

Ferocious.



VVIIII.. NNeexxtt:: MMeetthhooddoollooggyy

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.



333... MMEETTHHOODDOOLLOOGGYY


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 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, standardize the development process and thereby make the

communication among participants in the development more effective and more reliable, and



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: gathering requirements, feasibility study, domain analysis, system

analysis, design, implementation, quality assurance and testing, deployment and training,

and 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).



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:

―initial‖ (or ad hoc), where the organization lacks a stable environment and relies on the

capabilities of the individuals ―repeatable‖ where the organization has adopted project

management principles ―defined‖ where the workflow has been shaped into an engineering

process, ―managed‖ where product and process quality are quantitatively predictable and

―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: an object-oriented

technology, an object-oriented analysis and design, and 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: how the real world is viewed, how

software is defined, the process of development, and 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 the goal of the

project is feasible, the project has a realistic plan for reaching its goal, we can track how the

project is proceeding, and 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 project’s lifetime is finite: it is not a continuous undertaking but has a beginning and an end. A

project’s lifecycle is composed of five ―umbrella‖ phases that in turn cover other steps or



activities: scope the project, develop the project plan, launch the plan, monitor the

project’s progress, and 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.

VVII.. DDiissccuussssiioonn NNootteess

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.



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 studio’s 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).

VVIIIIII.. NNeexxtt:: GGaatthheerriinngg RReeqquuiirreemmeennttss..

When we undertake to create a new product, we must first understand clearly what the product

must do. If we don’t, 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.



444... GGAATTHHEERRIINNGG RREEQQUUIIRREEMMEENNTTSS


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.



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

system’s 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.



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.)

VVIIII.. DDiissccuussssiioonn NNootteess

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: When should we resort

to interviews instead of questionnaires? (In a TV program on a movie star, questionnaires would

not generate high ratings.) Should we keep the text of the interview word-for-word, or should

we edit and reorganize it to relate to the project’s objectives? 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.



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 Group’s 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]



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 don’t 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.

VVIIII:: EExxaammpplleess

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



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

…

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.

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.

Section n: Title ID Definition True/False Comment

065 Requirement definition.

…



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: Medium: High:

True:

False:

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.

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. IEEE’s 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:

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).

Composing an SRS document is an iterative task: it is built gradually, usually in parallel by

different persons and groups.

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.)



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



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 product’s 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.



IIXX.. NNeexxtt:: DDoommaaiinn AAnnaallyyssiiss

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.



555... DDOOMMAAIINN AANNAALLYYSSIISS


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.



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.)



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 business’s 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.

ISN’T 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]



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:

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.

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



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.



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.

DDOOMMAAIINN DDEEFFIINNIITTIIOONN:: RRIISSKKSS && LLIIMMIITTSS

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.

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.

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.

DDOOMMAAIINN DDIICCTTIIOONNAARRYY:: EEXXPPAANNSSIIOONN && TTRRAANNSSFFOORRMMAATTIIOONN

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):

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.



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.

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!

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.

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.

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.]



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 concept’s 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 tire’s 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 1990’s, ―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.)

VVIIII:: EExxaammpplleess

WALDEN MEDICAL CENTER’S DOMAIN DEFINITIONS

Table below is a complete listing of domain definitions for Walden Medical Center. While this

decomposition of the hospital’s 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/. SAP’s 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

http://www.sap.com/solutions/industry/healthcare/



Treatments

Patient Relationship Management

Medical Records

Management: Digital Lab Library,

Treatment Reports

Prescriptions

Doctor’s 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



Business Intelligence &

Decision Support System: Stakeholder Relationship Management

Performance Measurement

Patient Relationship Analysis

Supply Chain Analysis

Revenue & Cost Analysis

Risk Analysis

Planning

DOMAIN DICTIONARY FOR WALDEN’S PATIENT MANAGEMENT

Table below is the complete listing of the preliminary domain dictionary for Walden Hospital’s 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.



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.

VVIIIIII.. NNeexxtt:: BBeehhaavviioorraall MMooddeelliinngg

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.



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.



666... BBEEHHAAVVIIOORRAALL MMOODDEELLIINNGG II –– UUSSEE CCAASSEESS:: TTHHEE BBAASSIICCSS


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.

IIII.. CChhaapptteerr OOuuttlliinnee

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 system’s 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: a goal as the successful outcome of the use case, stakeholders whose interests are

affected by the outcome, including actor(s) who interact with the system to achieve the goal, a

system that provides the required services for the actors, and 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: normal flow is the best-case

scenario that results in the successful completion of the use case; alternate flow that is present

only if conditional steps are needed; sub-flows if steps in the normal flow contain sub-steps;

Exceptions that describe what may prevent the completion of one step or the entire use case.



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



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 alone…This 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 driver’s license and your car’s 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.



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 Walden’s 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 system’s behavior under various condition as the

system responds to a request from one of the stakeholders, called the primary actor.

[Cockburn 2001]



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



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 don’t 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: ―Let’s write the program and show them; we can

change it later.‖



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.

VVIIIIII.. NNeexxtt:: DDeevveellooppiinngg UUssee CCaasseess

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.



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.



777... BBEEHHAAVVIIOORRAALL MMOODDEELLIINNGG II –– DDEEVVEELLOOPPIINNGG UUSSEE CCAASSEESS


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 a use case has the necessary building blocks and 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.



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.



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 system’s 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.

VVIIII.. EExxaammpplleess

WALDEN USE CASES

RReeggiisstteerr PPaattiieenntt..

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 patient’s 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



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 patient’s 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 patient’s address.

1.3 The registration clerk enters or updates patient’s phone number.

1.4 The registration clerk enters or updates the name, the address and the phone number of the

patient’s 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

RReecceeiivvee PPaattiieenntt..

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



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?

VVeerriiffyy IInnssuurraannccee PPllaann..

This use case illustrates two concepts:

The role of the supporting actor (Health Insurance Provider) in helping the primary actor.

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 patient’s 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.



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.

MMaakkee AAppppooiinnttmmeenntt..

Make Appointment is a use case without a precondition. The hospital’s 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 patient’s personal and contact data.

3. Appointment clerk records information about the referral source.

4. Appointment clerk consults hospital’s 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 hospital’s schedule matches patient’s 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.

RReeffeerr PPaattiieenntt..

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



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?

RReessoollvvee PPaattiieenntt BBiilllliinngg IIssssuuee..

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.



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 patient’s 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

patient’s account. (Extend: 164 - Charge Credit Card.)

6.d Patient pays by check. Hospital clerk applies the check to the patient’s 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.

VVeerriiffyy CCrreeddiitt CCaarrdd..

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 patient’s 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.



GGeenneerraalliizzeedd MMaakkee AAppppooiinnttmmeenntt..

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: Patient: needs the appointment to receive medical service.


Generalization:

Include:

Extend:

Precondition: Patient needs to receive a medical service from the hospital.

Trigger:

Normal Flow: 1. Appointment agent records patient’s personal and contact data.

2. Appointment agent records information about the referral source.

3. Appointment agent consults hospital’s 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:


MMaakkee AAppppooiinnttmmeenntt BByy RReeffeerrrraall SSoouurrccee..

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: Patient: needs the appointment to receive medical service.




(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 patient’s contact data.

(S: Normal Step 1, UC 118)

2. Referral source consults hospital’s 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)

VVIIIIII.. NNeexxtt:: SSttrruuccttuurraall MMooddeelliinngg

The behavior of the system flows from its components, their relationships and their interactions

with each other and with the world outside the system.

System’s 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.



888... SSTTRRUUCCTTUURRAALL MMOODDEELLIINNGG


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 the nature of its building

blocks (or units) and 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



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 object’s

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 object’s 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 identify nouns that serve as grammatical objects, search for

grammatical objects hidden in verbs that have both transitive and intransitive forms, discard

obvious misfits, 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

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 confirm

that the tentative responsibilities do belong to the class and 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.



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.



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 hospital’s 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



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.

CCRRCC CCaarrddss

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



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.

VV.. EExxaammpplleess

WALDEN’S PATIENT MANAGEMENT CLASS CANDIDATES

The table below is the full listing of class candidates for Walden’s 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 Walden’s 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.




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

162: Apply Cash Payment



Billing Activity (Billing

Item) Knows a charge or a payment to

patient’s account.


Cash Payment Knows cash payment to patient account.

162: Apply Cash Payment


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 patient’s health insurance plan.

Verifies patient’s health insurance plan.

140: Register Patient


Outside Hospital Knows the identity of hospital as a referral source.

100: Refer Patient

Hospital ID Card Issues hospital card. 130: Receive Patient


144: Issue Hospital Card

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 patient’s personal data.

Knows patient’s contact data.

Knows patient’s appointments.

Knows patient’s insurance data.

Knows patient’s financial data.

Knows patient’s referral source.

Knows patient next of kin.

Issues hospital card.

100: Refer Patient





144: Issue Hospital Card



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




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 patient’s account.


Referral Source Knows the referral source. 120: Make Appointment

Hospital Schedule Knows appointments.

Knows openings for medical

services.


WWAALLDDEENN’’SS TTRRAACCKK MMEEDDIICCAALL SSEERRVVIICCEE UUSSEE CCAASSEE

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.



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: Patient’s 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.



VVII.. NNeexxtt:: DDyynnaammiicc MMooddeelliinngg

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.



999... DDYYNNAAMMIICC MMOODDEELLIINNGG..


Modeling actions and interactions of a system’s 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.


DDeessccrriibbee DDyynnaammiicc mmooddeelliinngg aanndd iittss rreellaattiioonnsshhiipp wwiitthh bbeehhaavviioorraall aanndd ssttrruuccttuurraall mmooddeelliinngg..

SShhooww hhooww oobbjjeeccttss iinntteerraacctt bbyy eexxcchhaannggiinngg mmeessssaaggeess..

DDeeffiinnee TThhee rroollee ooff ppaarraammeetteerrss aanndd rreettuurrnn vvaalluueess iinn eexxcchhaannggiinngg mmeessssaaggeess..

DDeessccrriibbee mmeetthhooddss aanndd tthheeiirr rreellaattiioonnsshhiippss wwiitthh ooppeerraattiioonnss..

DDeessccrriibbee eevveennttss aanndd tthheeiirr iimmppoorrttaannccee iinn ddyynnaammiicc mmooddeelliinngg..

LLeeaarrnn aabboouutt SSeeqquueennccee aanndd CCoollllaabboorraattiioonn ddiiaaggrraammss..

LLeeaarrnn aabboouutt SSttaatteecchhaarrtt aanndd AAccttiivviittyy ddiiaaggrraammss..


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.



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).



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.



VVIIIIII.. DDiissccuussssiioonn NNootteess

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 hand–eye 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 don’t 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



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

town’s 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.



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.

VV.. NNeexxtt:: DDeessiiggnn

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.

111000... TTHHEE DDEESSIIGGNN CCHHAALLLLEENNGGEE..


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.



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-



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 designer’s 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 application’s 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).



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.

VV.. DDiissccuussssiioonn NNootteess..

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 today’s 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



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.‖

VVII.. NNeexxtt:: AApppplliiccaattiioonn DDeessiiggnn..

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: a set of identifiable goals that, together, define a mission, and 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.



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.



111111... AAPPPPLLIICCAATTIIOONN DDEESSIIGGNN II:: FFLLOOWW && CCOONNTTRROOLL


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.



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 object’s 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



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

operation’s 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.



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.



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.

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.

Appointment clerk records patient’s 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.)



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.

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.

Appointment clerk consults hospital’s 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.

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.

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]



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.

VVIIII.. NNeexxtt:: TThhee UUsseerr IInntteerrffaaccee

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.



111222... AAPPPPLLIICCAATTIIOONN DDEESSIIGGNN IIII:: TTHHEE UUSSEERR IINNTTEERRFFAACCEE


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.

IIII.. CChhaapptteerr TTooppiiccss

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.



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 UI’s 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.

VV.. NNeexxtt:: PPeerrssiisstteennccee && DDaattaabbaassee

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



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.‖

111333... AAPPPPLLIICCAATTIIOONN DDEESSIIGGNN IIIIII:: DDAATTAABBAASSEE && PPEERRSSIISSTTEENNCCEE..


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.



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.



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.

VV.. DDiissccuussssiioonn NNootteess..

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



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



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.

CODD’S 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

Codd’s 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 attribute’s 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 Codd’s

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 database’s 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]

http://www.cogsci.princeton.edu/cgi-bin/webwn

http://en.wikipedia.org/wiki/Data

http://eliteral.com/glossary/decision-support-systems-glossary.php

http://www.cdc.gov/tobacco/evaluation_manual/glossary.html

http://www.ssqi.com/Library/glossary.html

http://www.utmb.edu/is/security/glossary.htm

http://www.reson.com/Gloss-d.htm



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.

VVIIII..NNeexxtt:: PPaatttteerrnnss

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 people’s 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.



111444... PPAATTTTEERRNNSS


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.

IIII.. CChhaapptteerr TTooppiiccss

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



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. DDiissccuussssiioonn NNootteess

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.

VVIIII.. NNeexxtt:: CCoommppoonneennttss && RReeuussee

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.



111555... CCOOMMPPOONNEENNTTSS && RREEUUSSEE


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.



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.



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.

VVII.. NNeexxtt:: AArrcchhiitteeccttuurree

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.



111666... AARRCCHHIITTEECCTTUURREE


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 the organization of a system’s major components and

the relationships of these component’s to each other and to the whole, or as 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.



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 to

make an architecture take shape, and 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. UML’s 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.



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.‖



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 relieves its consumers from the issues of its physical

identity, and 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.



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



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.)

VVII.. NNeexxtt:: NNeexxtt IImmpplleemmeennttaattiioonn..

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.



111777... IIMMPPLLEEMMEENNTTAATTIIOONN..


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 other’s code.



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 software’s 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.



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

Documents

Transcript of Students Notes