0% found this document useful (0 votes)

942 views570 pages

Practical Analysis and Design

Practical Analysis and Design for Client / Server and GUI Systems, by David A. Ruble. Published by Prentice Hall, Specially prepared for d03063582 on 25 Oct, 2010 a division of Pearson Education, Inc.

Uploaded by

Aaron A Ash

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

0% found this document useful (0 votes)

942 views570 pages

Practical Analysis and Design

Uploaded by

Aaron A Ash

We take content rights seriously. If you suspect this is your content, claim it here.

Available Formats

Download as PDF, TXT or read online on Scribd

You are on page 1/ 570

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
PRACTICAL ANALYSIS
AND DESIGN
FOR CLIENT/SERVER
AND GUI SYSTEMS
ISBN: 0-536-56083-8

Specially prepared for d03063582

ANDREWS AND LEVENTHAL Fusion: Integrating IE, CASE, and JAD

ANDREWS AND STALICK Business Reengineering: The Survival Guide
AUGUST Joint Application Design
BODDIE The Information Asset: Rational DP Funding and Other Radical Notions
BOULDIN Agents of Change: Managing the Introduction of Automated Tools
BRILL Building Controls into Structured Systems
COAD AND NICOLA Object-Oriented Programming
COAD AND YOURDON Object-Oriented Analysis, 2/E
COAD AND YOURDON Object-Oriented Design
COAD AND MAYFIED Java Design: Building Better Apps and Applets
COAD WITH NORTH AND MAYFIELD Object Models: Strategies, Patterns, and Applications, 2/E
CONNELL AND SHAFER Object-Oriented Rapid Prototyping
CONNELL AND SHAFER Structured Rapid Prototyping
CONSTANTINE Constantine on Peopleware
CONSTANTINE AND YOURDON Structured Design
DEGRACE AND STAHL Wicked Problems, Righteous Solutions
DeMARCO Controlling Software Projects
DeMARCO Structured Analysis and System Specification
EMBLEY, KURTZ, AND WOODFIELD Object-Oriented Systems Analysis
GARMUS AND HERRON Measuring the Software Process: A Practical Guide to Functional Measurements
GLASS Software Conflict: Essays on the Art and Science of Software Engineering
GROCHOW Information Overload: Creating Value with the New Information Systems Technology
JONES Assessment and Control of Software Risks
KING Project Management Made Simple
McMENAMIN AND PALMER Essential System Design
MOSLEY The Handbook of MIS Application Software Testing
PAGE-JONES Practical Guide to Structured Systems Design, 2/E
PUTMAN AND MYERS Measures for Excellence: Reliable Software on Time within Budget
RUBLE Practical Analysis and Design for Client/Server and GUI Systems
SHLAER AND MELLOR Object Lifecycles: Modeling the World in States
SHLAER AND MELLOR Object-Oriented Systems Analysis: Modeling the World in Data
STARR How to Build Shlaer-Mellor Object Models
THOMSETT Third Wave Project Management
ULRICH AND HAYES The Year 2000 Software Crisis: Challenge of the Century
YOURDON Death March: The Complete Software Developer’s Guide to Surviving “Mission Impossible”
Projects
YOURDON Decline and Fall of the American Programmer
YOURDON Rise and Resurrection of the American Programmer
YOURDON Managing the Structured Techniques, 4/E
YOURDON Managing the System Life-Cycle, 2/E
YOURDON Modern Structured Analysis
YOURDON Object-Oriented Systems Design
YOURDON Techniques of Program Structure and Design
YOURDON AND ARGILA Case Studies in Object-Oriented Analysis and Design
YOURDON, WHITEHEAD, THOMANN, OPPEL, AND NEVERMANN Mainstream Objects: An Analysis
and Design Approach for Business
YOURDON INC. YOURDON Systems Method: Model-Driven Systems Development
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

David A. Ruble

To join a Prentice Hall PTR Internet

mailing list, point to:
http://www.prenhall.com/mail_lists

Yourdon Press
Prentice Hall Building
Upper Saddle River, NJ 07458
ISBN: 0-536-56083-8

Specially prepared for d03063582

Practical Analysis on 25 Oct,and2010
and Design for Client/Server GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
Library of Congress Cataloging-in-Publication Data
Ruble, David A.
Practical analysis and design for client/server and GUI systems /
David A. Ruble.
p. cm. -- (Yourdon Press computing series)
Includes bibliographical references and index.
ISBN 0-13-521758-X (cloth : alk. paper)
1. Client/Server computing. 2. Graphical user interfaces
(Computer systems) I. Title. II. Series.
QA76.9.C55R82 1997
004’.36--dc21 97-9895
CIP

Editorial/production supervision: Patti Guerrieri

Cover design director: Jerry Votta
Cover designer: David A. Ruble
Manufacturing manager: Alexis R. Heydt
Marketing manager: Dan Rush
Acquisitions editor: Paul W. Becker
Editorial assistant: Maureen Diana
©1997 by David A. Ruble
Published by Prentice Hall PTR
Prentice-Hall, Inc.
A Simon & Schuster Company
Upper Saddle River, NJ 07458
The publisher offers discounts on this book when ordered in bulk quantities.
For more information, contact: Corporate Sales Department, Phone: 800-382-3419;
Fax: 201-236-7141; E-mail: [email protected]; or write: Prentice Hall PTR,
Corp. Sales Dept., One Lake Street, Upper Saddle River, NJ 07458.
Macintosh and Lisa are registered trademarks of Apple Computer, Inc. IBM is a registered trademark
of International Business Machines Corporation. Lotus 123 is a registered trademark of Lotus Devel-
opment Corporation. Microsoft, Windows, Visual Basic, MS-DOS, WORD, EXCEL and ACCESS
are registered trademarks of Microsoft Corporation. MTV is a trademark of MTV Networks. Oracle
is a registered trademark of Oracle Corporation. Smalltalk is a trademark of ParcPlace Systems.
PowerBuilder and SYBASE are registered trademarks of Sybase, Inc. DataWindow is a trademark of
Sybase, Inc. Xerox STAR is a registered trademark of Xerox Corporation. All other products or ser-
vices mentioned in this book are the trademarks or service marks of their respective companies or
organizations.
All persons and companies used in the examples in this book are fictitious and do not represent any
persons living or dead or companies functioning or defunct.
All interior cartoons and illustrations are the original work of David A. Ruble.
All rights reserved. No part of this book may be reproduced, in any form or by any means, without
permission in writing from the publisher.
Printed in the United States of America
10 9 8 7 6 5 4 3 2 1
ISBN 0-13-521758-X
Prentice-Hall International (UK) Limited, London
Prentice-Hall of Australia Pty. Limited, Sydney
Prentice-Hall Canada Inc., Toronto
Prentice-Hall Hispanoamericana, S.A., Mexico
Prentice-Hall of India Private Limited, New Delhi
Prentice-Hall of Japan, Inc., Tokyo
Simon & Schuster Asia Pte. Ltd., Singapore
Editora Prentice-Hall do Brasil, Ltda., Rio de Janeiro
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Specially prepared for d03063582

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
CONTENTS

FOREWORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xix
PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxi
ACKNOWLEDGMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xxvii

CHAPTER 1 WHAT IS ANALYSIS AND DESIGN? . . . . . . . . 1

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
The Purpose of Analysis and Design . . . . . . . . . . . . . . 2
The Skills of an Analyst . . . . . . . . . . . . . . . . . . . . . . . . 3
The Skills of a Designer . . . . . . . . . . . . . . . . . . . . . . . . 5
What Is Needed for a Successful
Client/Server Project? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
The Right People . . . . . . . . . . . . . . . . . . . . . . . . . 6
Sound Project Management . . . . . . . . . . . . . . . . 9
Sound Methodology . . . . . . . . . . . . . . . . . . . . . . 9
What Makes a Methodology “Good”?. . . . . . . . . . . . . 15
Characteristics of Good Design Methodologies . . . 15
Characteristics of Good Analysis Methodologies . . 17
Overview of the Techniques in this Book . . . . . . . . . . 21
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
ISBN: 0-536-56083-8

vii

Specially prepared for d03063582

CHAPTER 2 THE PROJECT CHARTER . . . . . . . . . . . . . . . . 31

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
The Purpose of the Charter . . . . . . . . . . . . . . . . . . . . . 32
Who Does the Charter? . . . . . . . . . . . . . . . . . . . . . . . . 32
How Accurate Must the Charter Be? . . . . . . . . . . . . . . 33
Beware of Sloppy Charters . . . . . . . . . . . . . . . . . . . . . 34
The Project Decision-Making Framework . . . . . . . . . . 35
The Goal Statement . . . . . . . . . . . . . . . . . . . . . . . 36
Problems and Opportunities
are the Basis for Objectives . . . . . . . . . . . . . . . . . 37
Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Measuring Objectives — The X-Factor . . . . . . . . 40
Coming Back to the Goal Statement . . . . . . . . . . 42
Evaluation Criteria . . . . . . . . . . . . . . . . . . . . . . . . 43
Solution Options . . . . . . . . . . . . . . . . . . . . . . . . . 47
The Written Charter as a Contract . . . . . . . . . . . . . . . . 50
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

CHAPTER 3 THE CONTEXT MODEL . . . . . . . . . . . . . . . . . 55

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
The Purpose of the Context Model . . . . . . . . . . . . . . . 56
Data Flow Diagramming Notation . . . . . . . . . . . . . . . . 57
Processes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
External Agents . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Data Flows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Material Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Data Stores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Naming and Definitions . . . . . . . . . . . . . . . . . . . . . . . . 68
Techniques for Creating the Context Model . . . . . . . . 69
Expanded versus Reduced Scope . . . . . . . . . . . . . . . . 69
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
CONTENTS ix

One Project — Many Contexts . . . . . . . . . . . . . . . . . . . 74

How the Context Model Relates to Other Models . . . . 75
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

CHAPTER 4 THE EVENT MODEL . . . . . . . . . . . . . . . . . . . . 79

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
The Purpose of the Event Model . . . . . . . . . . . . . . . . . 80
What Is Event-Driven? . . . . . . . . . . . . . . . . . . . . . . . . . 80
What Is an Event?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
No Internal Events . . . . . . . . . . . . . . . . . . . . . . . . 82
Some Examples of Events . . . . . . . . . . . . . . . . . . 83
The Deliverables of the Event Model. . . . . . . . . . . . . . 85
The Event List . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
The Event Dictionary . . . . . . . . . . . . . . . . . . . . . . 86
Event Matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
Uncovering Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
User Interviews . . . . . . . . . . . . . . . . . . . . . . . . . . 93
The Charter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Existing System Documentation . . . . . . . . . . . . . 94
The Context Model . . . . . . . . . . . . . . . . . . . . . . . . 94
The Information Model . . . . . . . . . . . . . . . . . . . . 95
Event Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Unexpected Events . . . . . . . . . . . . . . . . . . . . . . . 96
Expected Events . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Review of Event Types . . . . . . . . . . . . . . . . . . . . . 99
Organizing Your Event Model . . . . . . . . . . . . . . . . . . . 99
Sequencing Events by Time . . . . . . . . . . . . . . . . . 102
Sorting by Subject . . . . . . . . . . . . . . . . . . . . . . . . 103
Sorting by Object . . . . . . . . . . . . . . . . . . . . . . . . . 105
Leveled Events . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
ISBN: 0-536-56083-8

Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

Specially prepared for d03063582

CHAPTER 5 THE INFORMATION MODEL . . . . . . . . . . . . . 117

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
The Purpose of Information Modeling . . . . . . . . . . . . . 118
A Brief History Lesson . . . . . . . . . . . . . . . . . . . . . 118
The Components of the Information Model . . . . . . . . 120
The Entity-Relationship Diagram . . . . . . . . . . . . . 121
Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Relationships . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Attributive Entity Types . . . . . . . . . . . . . . . . . . . . 137
Attribute Definition . . . . . . . . . . . . . . . . . . . . . . . . 139
Associative Entities . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Example of Deriving Associative Entity Types . . . 141
Supertypes and Subtypes . . . . . . . . . . . . . . . . . . . . . . 147
State Transitions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Entity Matrices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Top-Down versus Bottom-Up Strategies . . . . . . . . . . . 154
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

CHAPTER 6 THE INTERFACE PROTOTYPE . . . . . . . . . . . . 161

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
What Is a Prototype? . . . . . . . . . . . . . . . . . . . . . . . . . . 162
The Purpose of Prototyping . . . . . . . . . . . . . . . . . 162
Benefits of Early Prototyping . . . . . . . . . . . . . . . . 163
The Downside of Prototyping . . . . . . . . . . . . . . . 164
How Detailed Should the Prototype Be? . . . . . . . 164
Where Do Windows Come From? . . . . . . . . . . . . . . . . 165
The Prototype Begins the Man–Machine Dialogue . . . 166
Grouping Events by Subject . . . . . . . . . . . . . . . . 170
Grouping Events by Object . . . . . . . . . . . . . . . . . 172
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
CONTENTS xi

Using the Information Model to

Lay Out Window Content . . . . . . . . . . . . . . . . . . . . . . . 177
Requirements Traceability . . . . . . . . . . . . . . . . . . . . . . 181
Keeping the Models in Sync with the Prototype . . . . . 182
User Review Techniques . . . . . . . . . . . . . . . . . . . . . . . 183
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

CHAPTER 7 WRAPPING UP THE ANALYSIS PHASE . . . . . 189

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Business Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
The Business Issue Resolution Process . . . . . . . . . . . . 192
Business Issue Documentation . . . . . . . . . . . . . . . . . . 193
Summary of Analysis Deliverables . . . . . . . . . . . . . . . 195
How the Models Inter-Relate . . . . . . . . . . . . . . . . . . . . 196

CHAPTER 8 THE ARCHITECTURE MODEL . . . . . . . . . . . . 199

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
What Is Architecture Modeling?. . . . . . . . . . . . . . . . . . 200
Overview of the Client/Server Architecture . . . . . . . . . 201
Client/Server Hardware Tiers . . . . . . . . . . . . . . . . . . . . 202
Client/Server Software Layers . . . . . . . . . . . . . . . . . . . 206
Fat Client, Fat Server . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Gathering Statistics and Constraints . . . . . . . . . . . . . . 210
Gathering Statistics for the Information Model . . . 210
Gathering Statistics for the Event Model . . . . . . 212
Determining Geographic Distribution Requirements. . . 215
One Centralized Database . . . . . . . . . . . . . . . . . . . . . . 221
Replicated, Decentralized Data. . . . . . . . . . . . . . . . . . . 221
Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
ISBN: 0-536-56083-8

Specially prepared for d03063582

Summary of Geographic Distribution . . . . . . . . . . . . . 225

Determining Local Distribution
Requirements between Client and Server . . . . . . . . . . 227
Pros and Cons of Fat Client versus Fat Server . . . 227
Review of Architectural Trade-offs. . . . . . . . . . . . . . . . 235
Rapid Response Time at the Client . . . . . . . . . . . 235
Heterogeneity of Client Hardware . . . . . . . . . . . . 235
Heterogeneity of Client Software . . . . . . . . . . . . 236
Minimal Network Communication . . . . . . . . . . . . 236
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239

CHAPTER 9 RELATIONAL DATABASE DESIGN . . . . . . . . . 241

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Relational Databases in Business Systems . . . . . . . . . 242
Relational Database Concepts . . . . . . . . . . . . . . . . . . . 242
Translating an Information Model
into a Relational Database . . . . . . . . . . . . . . . . . . . . . . 243
One-to-Many Relationships . . . . . . . . . . . . . . . . . 244
One-to-One Relationships . . . . . . . . . . . . . . . . . . 246
Many-to-Many Relationships . . . . . . . . . . . . . . . . 246
Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Choosing a Primary Key. . . . . . . . . . . . . . . . . . . . . . . . 247
Multi-Column Primary Keys . . . . . . . . . . . . . . . . . 252
Implementing Supertype/Subtypes Entities . . . . . . . . 255
Supertype/Subtype Tables Solution . . . . . . . . . . 255
Supertype-Only Solution . . . . . . . . . . . . . . . . . . . 256
Subtype-Only Solution . . . . . . . . . . . . . . . . . . . . . 258
Performance Tuning . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Other Responsibilities of the
Database Administrator . . . . . . . . . . . . . . . . . . . . . . . . 264
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 264
Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265
ISBN: 0-536-56083-8

Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266

Specially prepared for d03063582 on 25 Oct, 2010

CHAPTER 10 GRAPHICAL USER INTERFACE CONCEPTS . . 267

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267
The Rise of the Graphical User Interface . . . . . . . . . . . 268
What Makes a GUI Different from a Green Screen? . . . 268
Criteria for Good GUI Design . . . . . . . . . . . . . . . . . . . . 270
User Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Responsiveness . . . . . . . . . . . . . . . . . . . . . . . . . . 273
Customization . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
Directness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
Consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Clarity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 278
Aesthetics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
Forgiveness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
Awareness of Human Strengths and
Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Window Cohesion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Functional Cohesion . . . . . . . . . . . . . . . . . . . . . . 290
Sequential Cohesion . . . . . . . . . . . . . . . . . . . . . . 291
Communicational Cohesion . . . . . . . . . . . . . . . . . 293
Procedural Cohesion . . . . . . . . . . . . . . . . . . . . . . 293
Temporal Cohesion . . . . . . . . . . . . . . . . . . . . . . . 295
Logical Cohesion . . . . . . . . . . . . . . . . . . . . . . . . . 295
Coincidental Cohesion . . . . . . . . . . . . . . . . . . . . . 296
Ranking Levels of Cohesion . . . . . . . . . . . . . . . . . 297
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 298
Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300

CHAPTER 11 EXTERNAL INTERFACE DESIGN . . . . . . . . . . 303

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
What Is External versus Internal Design? . . . . . . . . . . 304
Why Do a Written Design Specification? . . . . . . . . . . . 304
External Interface Design Deliverables . . . . . . . . . . . . 306
ISBN: 0-536-56083-8

System and Application Overviews . . . . . . . . . . . 307

Specially prepared for d03063582

Window Navigation Diagramming . . . . . . . . . . . 308

Window Specification . . . . . . . . . . . . . . . . . . . . . 324
Testing a Graphical User Interface . . . . . . . . . . . . . . . . 333
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339
Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 339

CHAPTER 12 INTERNAL COMPONENT DESIGN . . . . . . . . 343

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
What Is Internal Component Design? . . . . . . . . . . . . . 344
Overview of Object-Orientation . . . . . . . . . . . . . . . . . . 344
Basic Principles of Object-Orientation . . . . . . . . . . . . . 345
Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Information/Implementation Hiding . . . . . . . . . . 346
Persistent State . . . . . . . . . . . . . . . . . . . . . . . . . . 347
Object Identity . . . . . . . . . . . . . . . . . . . . . . . . . . . 348
Classes versus Objects . . . . . . . . . . . . . . . . . . . . . 348
Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Inheritance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Polymorphism . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Why Objects? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
How Object-Oriented Is Your Project? . . . . . . . . . . . . . 354
“Our Application Will Have a GUI.
Does that Make Us Object-Oriented?” . . . . . . . . 354
“Are We Object-Oriented, Even
Though We Have a Relational Database?” . . . . . 354
Choose the Target, then Map the Technique
to the Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355
Domains of Object Classes . . . . . . . . . . . . . . . . . . . . . 356
The Foundation Domain . . . . . . . . . . . . . . . . . . . 356
The Architectural Domain . . . . . . . . . . . . . . . . . . 357
The Business Domain . . . . . . . . . . . . . . . . . . . . . 357
The Application Domain . . . . . . . . . . . . . . . . . . . 358
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
CONTENTS xv

Deriving Business and Application

Domain Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Deriving Business Classes
from the Information Model . . . . . . . . . . . . . . . . 358
Deriving Application Classes
from the Event Model . . . . . . . . . . . . . . . . . . . . . 368
Modeling Triggers and Stored Procedures . . . . . . . . . 371
Structured Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
Exercises. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376

CHAPTER 13 TEN MYTHS OF CLIENT/SERVER

DEVELOPMENT . . . . . . . . . . . . . . . . . . . . . . . 379

Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 379
Myth 1: “Client/Server Technology Will
Make Users More Productive.” . . . . . . . . . . . . . . . . . . 380
Myth 2.1: “Client/Server Is Cheap.” . . . . . . . . . . . . . . . 381
Myth 2.2: “We Can Use the
New System to Force Improvements
in the Business Process.” . . . . . . . . . . . . . . . . . . 381
Myth 2.3: “Hardware Costs Will Go Down.” . . . . 382
Myth 3: “PC Stands for Personal Computer.” . . . . . . . 382
Myth 4: “It’s Easy to Build Windows Using
These New RAD Tools.” . . . . . . . . . . . . . . . . . . . . . . . . 383
Myth 5: “The Next Version of the Development
Tools Will Fix Our Current Problems.” . . . . . . . . . . . . 385
Myth 6: “The Manager Doesn’t Need
to Know the Methodology.” . . . . . . . . . . . . . . . . . . . . 387
Myth 7: “We Don’t Have to Do Any of this
Analysis and Design Stuff Because We’re
Going to Purchase Packages Rather Than
Build Systems.” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Myth 8: “Structured Walkthroughs Were Only
for Structured Analysis and Structured Design.” . . . . 389
ISBN: 0-536-56083-8

Specially prepared for d03063582

Myth 9: “Standards Will Emerge

as the Project Goes On.” . . . . . . . . . . . . . . . . . . . . . . . 391
Myth 10: “We Need One Standard Methodology
and One Standard CASE Tool.” . . . . . . . . . . . . . . . . . . 392
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394

APPENDIX VETC. CASE STUDY . . . . . . . . . . . . . . . . . . . 397

Author's Note . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 397

A Company Is Born . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Three Years Later . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 399
The Uptown Mall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 400
An Interview with Wanda Welcome,
Vetc. Customer Service Agent . . . . . . . . . . . . . . . 401
Behind the Wall at Vetc. . . . . . . . . . . . . . . . . . . . . 406
An Interview with Mattie Cote,
Vetc. Grooming Supervisor . . . . . . . . . . . . . . . . . 407
An Interview with Dr. Chur,
Vetc. Veterinarian . . . . . . . . . . . . . . . . . . . . . . . . . 409
An Interview with William Ling,
Vetc. Accountant . . . . . . . . . . . . . . . . . . . . . . . . . 410
Exercise Questions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411
Exercise 1 — Problems and Opportunities . . . . . 411
Exercise 2 — Objectives, Evaluation
Criteria, Solution Options . . . . . . . . . . . . . . . . . . 412
Exercise 3 — Context Model . . . . . . . . . . . . . . . . 412
Exercise 4 — Event Model . . . . . . . . . . . . . . . . . . 413
Exercise 5 — Information Model . . . . . . . . . . . . . 413
Exercise 6 — Interface Prototype . . . . . . . . . . . . . 414
Exercise 7 — Architecture Model . . . . . . . . . . . . . 414
Exercise 8 — Database Design . . . . . . . . . . . . . . 414
Exercise 9 — External Interface Design . . . . . . . . 415
Exercise 10 — Internal Component Design . . . . . 415
Exercise Answers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415
Answers to Exercise 1 —
Problems and Opportunities . . . . . . . . . . . . . . . . 415
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Answers to Exercise 2 —
Objectives, Evaluation Criteria,
Solution Options . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Answers to Exercise 3 — Context Model . . . . . . 437
Answers to Exercise 4 — Event Model . . . . . . . . 439
Answers to Exercise 5 — Information Model . . . 442
Answers to Exercise 6 — Interface Prototype . . . 454
Answers to Exercise 7 — Architecture Model . . . 459
Answers to Exercise 8 — Database Design . . . . . 461
Answers to Exercise 9 —
External Interface Design . . . . . . . . . . . . . . . . . . . 463
Answers to Exercise 10 —
Internal Component Design . . . . . . . . . . . . . . . . . 493

GLOSSARY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 495

BIBLIOGRAPHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 507

INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 511
ISBN: 0-536-56083-8

Specially prepared for d03063582

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
FOREWORD

The computer industry is fond of organizing its history into various “epochs” or “genera-
tions.” Everyone is familiar with the notion of generations of hardware, even if it consists
only of “286,” “386,” “486,” and “Pentium.” Similarly, almost everyone in the software
field has suffered through many sermons about the differences between first-generation,
second-generation, third-generation, and fourth-generation programming languages.
When it comes to “architectures,” the common tendency today is to divide the world
into mainframe systems, client/server systems, and Internet/intranet systems. There is a gen-
erational aspect to this, also: mainframes are old-fashioned, client/server is “mainstream,”
or state-of-the-art; and anything associated with the Internet is new, exciting, risky, and
potentially dangerous.
There are several other aspects of the computing field to which generational labels
could be attached, and there’s one that is particularly relevant for a good understanding of
David Ruble’s new book, Practical Analysis and Design for Client/Server and GUI Systems:
the generations of METHODOLOGIES. In the “old days,” when systems were developed in
assembly language on primitive mainframes, the simplistic (though somewhat unrealistic)
assumption was that developers had no methodology at all. Then, from the mid-1970s
through the late 1980s, developers tended to focus on structured analysis/design (SA/SD)
techniques, combined with a sequential “waterfall” lifecycle approach to development.
By the late 1980s and early 1990s, the transition from mainframes to client/server
architectures coincided with a transition from waterfall lifecycle approaches to RAD/
prototyping/spiral lifecycle approaches. Along with that, the emphasis on graphical user
interfaces (GUIs) initiated a transition from structured methods to object-oriented (OO)
methods, though it’s interesting to note that as this book is being published in mid-1997,
OO is still used far less commonly than SA/SD. On the other hand, it’s interesting to note
that the new generation of software developers (those who are typically in their mid-20s
today) often reject SA/SD for the same reason they reject mainframe computers and
COBOL: as far as they’re concerned, it’s hopelessly obsolete. It’s also interesting to note
ISBN: 0-536-56083-8

xix

Specially prepared for d03063582

that in many cases the rationale for such a rejection is that SA/SD requires a waterfall
approach; and since the waterfall approach is obsolete, they assume that SA/SD is, too.
David Ruble shows that this is not the case at all. Systems developed for the current
“mainstream” form of architectures⎯the client/server and GUI combination⎯can indeed
be developed with a robust structured analysis/design approach. And all of this can be
done with an intelligent, common sense iterative approach to building the system. And
while the newer generation of OO methodologies may believe that they are the ones who
invented “events” (often referred to as “use cases”), Ruble shows us that an event-based
model makes eminently good sense for client/server systems, and that it can be used quite
nicely with a structured methods approach. This is not an entirely revolutionary concept.
Steve McMenamin and John Palmer articulated the notion of an event-based approach to
structured analysis in 1984 (Essential Systems Analysis, Prentice-Hall/Yourdon Press,
1984), but their discussion didn’t have the opportunity to illustrate the ideas within the
modern context of client/server and GUI-based systems.
In short, what you’ll find in Dave Ruble’s book is an excellent mixture of the “old”
and the “new.” There’s a brief overview of object-oriented methods, but the primary
emphasis is on using robust, mature structured analysis/design methods, with an intelli-
gent spiral/iterative lifecycle, to build today’s client/server, GUI-based systems. It may
not be brimming with the latest buzzwords and references to Java that you’ll find in the
industry trade magazines, but this is exactly the kind of systems development approach
that most of today’s application developers need. Follow the guidelines, methods, and
techniques described in Ruble’s straightforward, easy-to-read style, and you’re almost
certain to succeed.

Ed Yourdon
New York City
March 1997

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
PREFACE

Client/server technology has dramatically changed the way we design and build infor-
mation systems. In most businesses, the glory days of the single mainframe processor are
gone. The one big box has been replaced or augmented by an integrated network of per-
sonal computers, communication networks, file servers and database servers. The popu-
larity of the graphical user interface (GUI) has placed ever-increasing demands on
information technology professionals to create applications that are complex, yet intu-
itive and easy to use. Client/server systems knit together sectors of the business organi-
zation into a broad computing fabric that reaches far beyond the boundaries of traditional
mainframe systems.
This book offers a practical guide to the core competencies required for analysis
and design of today’s client/server business information systems. In it, you will find
analysis and design techniques which have been employed with success on many large-
scale projects. Today’s information environment is one of rapidly expanding complex-
ity. Successful client/server project teams must master the design and creation of the
graphical user interface, manage and maintain systems using object-oriented program-
ming constructs, design databases capable of serving the needs of multiple business
sites, and link geographically-distributed users together, both inside and outside of the
enterprise. As if that isn’t enough, the ever-expanding scope of today’s information sys-
tems requires an even more savvy analytical understanding of the business and a well-
coordinated partnership with the users and business management teams than in the past.

WHAT IS PRACTICAL ANALYSIS AND DESIGN FOR

CLIENT/SERVER AND GUI SYSTEMS?

The reason I call this “Practical Analysis and Design” is because I am an analyst and
designer, myself. I don’t want to wade through an academic dissertation offering math-
ematical proof for some hypothetical methodology, and I figure that you don’t have the
ISBN: 0-536-56083-8

xxi

Specially prepared for d03063582

time either. We’ve got deadlines to meet. So I’ve included the key analytical techniques
and design concepts that I have used to get client/server projects delivered in a timely
and sensible manner.
These techniques can be employed using a variety of project-management philoso-
phies, ranging from traditional waterfall to iterative spiral approaches. Some activities
presented herein have definite predecessor–successor relationships while others can be
conducted concurrently. This is simply the stuff that needs to be done to ensure adequate
understanding of the business problem and provide reliable, traceable design specs to
build and test a system.
As for the last part of the book’s title, “for Client/Server and GUI Systems,” this
book assumes your new systems will include at least one, perhaps many computers ful-
filling the role of “server,” that your terminals or “clients” are likely to be personal com-
puters with some type of graphical user interface, and that your database will probably
be of the relational variety. The amount of object-orientation in your system will vary
tremendously, depending on the capabilities of your target development languages.
While the analysis and design techniques in this book are not limited to this environ-
ment, they are exceptionally well suited to this scenario.

WHAT’S THIS BOOK ABOUT?

If this book weighed 100 pounds, about 60 pounds of it would be analysis and 40 pounds
would be design. The analysis section starts with a chapter on project charters, which
marks the beginning of the analytical process even though this activity is commonly
referred to as the “planning” phase of a project. The activities of analyzing the business
need are covered in the subsequent five chapters on context modeling, event modeling,
information modeling, interface prototyping and resolving business issues. Then the
book moves on to system design. The design chapters show how to consume the mod-
els created during the analysis phase for making architectural decisions, designing the
database, and creating the interface and internal componentry.

THAT’S A LOT OF STUFF! WHAT ISN’T IN THIS BOOK?

This book is about writing specifications for systems, not about writing code at the line
level. There are plenty of programming and technical issues which are well beyond the
scope of this work. Computer hardware is something that this book definitely not about.
I won’t be telling you how to wire up your network or which plug goes in which socket.
I do not endeavor to endorse (or deride) any particular brand or type of hardware, lan-
guage or development tool, and I can’t possibly tell you whether to use version 1.342A
versus version 2.417B. That kind of advice would be out of date before the ink was dry
from the press.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

WHO NEEDS TO KNOW ALL OF THIS?

Developers, managers, business analysts, programmers . . . a lot of people need to know

this stuff. Within these pages are the core competencies that form the foundation of suc-
cessful software engineering. These techniques have evolved over the last three decades,
along with the capabilities of the available technology and the maturity of our industry.
Whether you are a traditional mainframe developer, an experienced client/server veteran
with many projects under your belt, or a mouse-slinging “PC cowboy” riding the range
of the GUI desktop frontier, you should be able to find something useful in this book.
Today’s information technology professional is becoming more and more special-
ized. Like the medical field, there is simply too much to learn to know it all. You can
carve out a specialized career niche by picking just one or two techniques from this book
and getting really good at them. Other readers may opt for a more generalized approach
by mastering many of the techniques along with a variety of programming languages and
technical skills.

HOW THIS BOOK IS ORGANIZED

The first chapter reveals the secret for a successful client/server project. It takes the right
people, sensible management, and a sound methodology. (Having a big sack of money
doesn’t hurt, either.) I discuss the skills required of a good analyst and the skills to look
for in a designer. I offer my thoughts on the waterfall versus spiral methodology debate,
and then move on to describe the key characteristics to look for in a good methodology.
The chapter closes with a brief overview of the techniques covered in the rest of the book.
Chapters 2 through 7 detail the deliverables of planning and analysis. In Chapter 2, The
Project Charter, I initiate the analytical process with a technique called the project decision-
making framework, which is used to help the business members determine the true objec-
tives of their new system. Chapter 3 covers The Context Model, a venerable yet important
technique for exploring and defining system scope and external interfaces. The Event Model
is the subject of Chapter 4. The event model defines the system’s observable behavior in busi-
ness terms, and documents the business policy and rules which comprise the process require-
ments. It is a crucial model which guides the development of the event-driven graphical user
interface. The Information Model, covered in Chapter 5, creates an organizational map of the
data that the system is required to remember. This is a vital technique for sound relational
database design and object modeling. Chapter 6 shifts from building models to consuming
models. The Interface Prototype is our first foray into design. Prototyping can be used to val-
idate models, design the interface, or even elicit requirements. Chapter 7 rounds out the
analysis section with some suggestions on resolving business issues.
Chapters 8 through 12 address the design of a client/server system and graphical
user interface. Chapter 8, on The Architecture Model, shows how to use the essential
models from analysis to determine the most desirable (or least offensive), technical
ISBN: 0-536-56083-8

Specially prepared for d03063582

architecture for your system. Chapter 9 covers the basics of transforming an informa-
tion model into a Relational Database Design. Chapter 10 introduces key Graphical
User Interface Concepts. The written External Interface Design specification is the
subject of Chapter 11. A written specification is a vital management tool for partition-
ing the development work among multiple programmers, and for devising adequate test
plans. Chapter 12 is the final technical chapter, covering Internal Component Design,
with an emphasis on object-oriented concepts.
In the final chapter, I present Dave’s Top Ten Myths of Client/Server Development.
This chapter is intended to help separate the fact from the fiction surrounding
client/server development. Following the formal chapters, I have included a comprehen-
sive case study which gives you an opportunity to exercise the techniques covered in this
book for a fictitious business, rife with many of the same types of problems and issues
that you find in real companies.
The philosophy of this book is simple. Building solid software applications requires
rigor and discipline. No amount of arm-waving and fad-of-the-year hoopla can eradicate
the need for getting into the gory details of the business problem. Techniques for analy-
sis and design need to be sufficiently robust and expressive to articulate the business need
and devise a solution, yet they must be practical enough to be practiced with everyday
tools in a format that allows analysts and designers to work closely with their users.
By using the techniques in this book, you can build reliable systems which realize
the goal of client/server, to exploit the power of micro, mini and mainframe computers by
allocating them to their most propitious use. By doing this in an organized and rational
manner, you will avoid the anarchy which is unleashed in less disciplined shops, and your
efforts will yield information systems that are flexible enough to meet your business’
needs while maintaining safe custody of the corporate data asset.

Questions or comments regarding this book can be addressed to the author at

www.ocgworld.com

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
PREFACE xxv

AUTHOR’S NOTE

Several conventions employed in this book are worthy of explanation.

The English language lacks a word to express “he or she” in the singular. “They”
denotes plural, and “he/she” is awkward. In the interest of readability, I have used the
words he and him instead of he/she and him/her. You may take any instance of the word
he or him in this book to describe either a male or female person, with the notable excep-
tion of my reference to General Eisenhower in Chapter 3, and various methodologists
named throughout.
In information modeling, the term entity is formally differentiated from the term entity
type. The entity type is the classification of the person, place, thing or abstract idea, and the
entity is a member or instance of the classification. Customer represents the entity type.
Bob’s grocery store represents an entity. This distinction is not always made in the vernac-
ular of common speech among practitioners. In the interest of smooth sentence flow I will
use the word entity at times in this book to mean either entity or entity type. The context of
the sentence should make it clear what I mean. This disclaimer also applies to my use of the
words attribute versus attribute type, and relationship versus relationship type.
The distinction is more clear in object-oriented design where we have entirely dif-
ferent words to distinguish between a class and an object. Objects are the instances that
exist at runtime (e.g., Bob). Classes are the templates from which the objects are wrought
(e.g., Customer). Since class can have different meanings in our language, I will some-
times use the term object class instead of simply class to make it clear that I am refer-
ring to an object-oriented construct.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Specially prepared for d03063582 on 25 Oct, 2010

Writing this book would not have possible had it not been for the ideas, concepts and
ingenuity of several colleagues who have profoundly influenced my thinking through the
years. Most notably, I extend my sincere thanks to Meilir Page-Jones, who has long been
a voice of reason in this industry. I also owe a debt of gratitude to Gary Konkel, who first
introduced me to the project decision-making framework and has taught me so much
about the art and science of analysis.
I would next like to recognize those outstanding developers, managers, visionaries
and project team members with whom I have had the distinct pleasure of working; Jeff
Brock (who produced the GUI windows for the screen-shots in this book), Rick Story,
Tom Mehrer, Chris Emerson, Bill Metro, Pennie Dembry, Tom Looy, Ray Craft, Howard
Woodard, Steve Weiss and my coprincipals at Olympic Consulting Group, Bill
McNaughton and Bob Burlingame. I would also be remiss if I didn’t thank the many
users of my systems, the good, the bad and the ugly (systems, not users), as well as my
many seminar students who never fail to teach me something new.
To the fine people at Prentice Hall—Paul Becker, Patti Guerrieri, Dan Rush,
Carolyn Gauntt, Ronnie Bucci, and the many others behind the scenes who reviewed,
copy edited and assembled this work—thank you for your tremendous skill and
patience. I also wish to thank Gerry Pasternack and Rex Hogan who reviewed my
completed manuscript, Amjad Umar, Ed Yourdon, Meilir Page-Jones, Gary Konkel
and Bill McNaughton who provided important feedback along the way, and many oth-
ers who took the time to read various chapters as they developed; Bob Burlingame,
Gary Schuldt, Rita Litchfield, Lan Ma, Allison Brazil, Skip Carter, Lori Pry, Scott
Walker, Tom Mehrer, Jeff Brock and a special thanks to Dave Duranceau who mirac-
ulously recovered Chapter 5 from the evil clutches of a general protection fault.
Finally, a special thanks for the unwavering support of my wife Mary, who endured
the trials of a stay-home husband while raising a toddler. And for Alix, Daddy will
always treasure all of the little interruptions . . . really!
ISBN: 0-536-56083-8

xxvii

Specially prepared for d03063582

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
CHAPTER
1

WHAT IS ANALYSIS
AND DESIGN?

INTRODUCTION

Welcome to Chapter 1. In this introductory chapter, I take a look at the purpose of analy-
sis and design as well as the characteristics of a good analyst and good designer. Laying
the groundwork for the chapters which follow, I review the trend toward specialization in
our industry, discuss the waterfall versus spiral methodology debate, and suggest some
criteria for what makes a methodology a “good” one. Finally, I give an overview of the
techniques which comprise the rest of this book, namely the activities and deliverables for
the analysis and design of client/server systems with graphical user interfaces.
ISBN: 0-536-56083-8

Specially prepared for d03063582

(a) Customer places order

(b) Credit manager approves order
(c) Customer cancels order
(d) Warehouse ships order
(e) Customer fails to pay invoice
2. Maureen is the purchasing agent for Villa St. Emily Wineries. Her job is to
review purchase orders that have been entered into the system by the field
office and approve or reject them. The purchase orders are already in the sys-
tem, so what’s the stimulus for the event dictionary entry for Purchase order
manager approves purchase order? Is it the Purchase order identifier and the
Approval status, or is it all of the selection criteria Maureen might use to get a
list of purchase orders on the window?
3. At Villa St. Emily Wineries, there is a business rule stating that if an in-process
order is priced according to a list price, and that list price changes prior to ship-
ment, then the order must be reviewed by a sales manager to either grandfather
the old price, or re-price the order at the new price. Where should this business
rule be documented in the analysis models?

ANSWERS
1. (a) Customer places order is usually an unexpected event in most business sys-
tems. Few businesses know ahead of time which customer will place any
particular order at a given point in time.
(b) Credit manager approves order is an event which is expected, assuming
that it is preceded by the event Customer places order, which establishes a
window of expectation, within which the order should be approved.
(c) Customer cancels order is unexpected.
(d) Warehouse ships order is expected, unless of course, your warehouse is
given to shipping items at random.
(e) Customer fails to pay invoice is actually the non-occurrence of an expected
event, Customer pays invoice, or in other words, a non-event.
2. The stimulus would be the purchase order identifier and the purchase order sta-
tus with a value of “approved.” The activity for the event would update the
identified purchase order to “approved” status. (It is possible that there is no
response required from the system for this event.) In the event model, you only
need to note that the user needs a way to acquire the purchase order to indicate
ISBN: 0-536-56083-8

Specially prepared for d03063582

THE PURPOSE OF ANALYSIS AND DESIGN

Analysis is the process of determining what needs to be done before deciding how it
should be done. Design is the process of determining which of many possible solutions
best accomplishes what needs to be done, while respecting the project’s budgetary and
technological constraints. Design chooses a specific how to apply to the what. Analysis
is the act of discovery. Design is the art of compromise.
Traditionally, analysis efforts have a dubious track record in software develop-
ment. Just about everyone knows of a project which spent untold months (or sometimes
years) drawing acres of bubbles, arrows, boxes and lines, only to abandon them to a
sorry bookshelf and start coding in a panic. You might even know of a project that
skipped any pretense of analysis altogether and commenced coding on the first day.
Building software is analogous to building a house. Very few people in their right
mind would purchase a plot of land, hire fifteen carpenters and turn them all loose in the
field with a pile of lumber, a crate of nails, and say “build me a house.” (The carpenters
won’t be too worried because they’ve all built houses before, so if issues over details such
as the required number of rooms or floors crop up, they’re sure to be able to resolve them
among themselves.)
The cost of such a folly might range around one or two hundred thousand dollars
and would yield a strange structure indeed. It’s quite probable that the owner wouldn’t
be entirely pleased with the result, and possible that the home would be completely
uninhabitable.
As silly as the story of our architecturally-challenged homeowner seems, it pales
in comparison to the millions of dollars lost each year on software projects that fail to
deliver what the users need, or collapse completely without delivering anything. Just as
it would be foolish to blame the carpenters for failing to produce a decent house under
these circumstances, it is rarely the case that a software development project fails due to
lack of technical prowess on the part of the programming staff. Most projects that fail do
so because of lack of sound project management and failure to analyze the business need
and failure to design a solution prior to construction of the product.
One could say that the purpose of analysis and design is, at worst, to keep your
project from going down in flames, or at best, to fully articulate the business need based
on an understanding of its current problems, and to derive a solution which best meets
the need and fits within the budgetary, resource and time constraints set by the business.
A residential architect determines the homeowner’s desires, tastes, particular problems,
needs and budget then explores design solutions to verify and validate the requirements
prior to building it. The software analyst defines the nature of the business problem and
the software designer explores the various solutions, making informed decisions to
arrive at a product that will satisfy the users.1

1 Analyst and Designer are roles. They can be the same person, separate persons, or entire teams of
people, depending on the size of the project and skill set of the staff.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

This boils down to a pretty simple concept: “Find out what the business requires
to be done before you start figuring out how to do it.”
The complicating factor is that businesses are not simple and their intrinsic prob-
lems are compounded by people with differing opinions of how to solve them (or
whether to solve them at all), and the whole mess is topped off with an absolute labyrinth
of pathological legacy systems.2

THE SKILLS OF AN ANALYST

The role of the analyst is to go forth and find out what problems exist in the business and
determine what those in charge of the business desire to have happen. This is a radically
different role and set of responsibilities from, say, a programmer, whose job is to write
reliable code. It stands to reason then, that the skills required of the analyst are different
than those required of the programmer.
I am torn between the terms “business analyst” and “software analyst” because
successful analysts are a mixture of both. As an analyst, you need to be acutely aware of
how a business makes money. As we’ll see in Chapter 2, business information systems
exist to contribute to the bottom line. On the other hand, the object of the game is to build
software. For this reason, the analyst cannot be completely oblivious to the basic princi-
ples of automation. The analyst needs to be profoundly aware of what is possible, feasi-
ble and practical when it comes to business computing.
Overall, the analyst is an investigator. Analysis is the process of discovery. The
analyst must be comfortable in the role of archeologist, unearthing untold gems of data
from the twisted wreckage of a legacy system’s flat files or deciphering the hieroglyph-
ics of a long-dead programmer’s ancient algorithms. Many times, the analyst becomes a
sociologist, forced to venture out and live among the tribe to learn their customs and
dialect, and to separate their mythology from reality.
Superb communication skills are of the utmost importance. Analysis is not a “heads
down” activity. In the analysis phase of a project, you will be spending a great deal of
your time coaxing information out of potential users of the system, reorganizing what you
learn and presenting it back to them for their validation. You may be called upon to play
diplomat, resolving conflicts and brokering solutions between warring factions of the
business, or to spend time in the role of camp counselor, assuaging users’ fear of change.
Some information technology (IT) shops subscribe to the belief that if a person spends
two years incarcerated in their cubicle maintaining COBOL code, they become magically
endowed with the above-mentioned skill-set and ascend to a higher order of existence;
“programmer-analyst.” Sadly, this is not true. Like so many other skills in life, a good ana-
lyst is created through dedicated practice and an original aptitude for the job. Analysts need

2 Legacy systems are those which already exist in the company, including the systems you may be
replacing. They have usually been developed some time ago with older technology.
ISBN: 0-536-56083-8

Specially prepared for d03063582

the proper training and an environment where they can hone their talents through repetition
of the analytical techniques.
Many talented programmers become excellent analysts; however, programming is
not a prerequisite for the job of analyst. The skill sets and aptitude required to do either
are widely disparate, and may not always arrive in the same person. In many IT shops,
the promotion to “programmer/analyst” involves little or no change in the amount of
programming required in the job, and very little time is spent actually conducting analy-
sis. In these situations, “analyst” is a title that is indicative of salary level only.
The reality is that no software development effort of any appreciable size can get
along without the skills of good managers, analysts, and technologists. A well staffed IT
shop will endeavor to attract and to cultivate all three skills sets within the organization
and reward each group according to their expertise.
Some shops have shown success turning system users into analysts, although this
usually requires some degree of training in the details of automation. Many colleges and
universities are now offering degrees in business with a concentration in information
technology, or augmenting their computer science curriculum with courses in account-
ing, marketing, manufacturing and general business. This is precisely the type of educa-
tional foundation which forms a solid basis for a career as an analyst.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

THE SKILLS OF A DESIGNER

The designer is a slightly different animal than the analyst. While the focus of the ana-
lyst is mainly business-oriented, with a strong grounding in technology, the focus of the
designer is mainly on technology, with a strong grounding in business.
Design is all about making trade-offs. The designer is faced with the daunting task
of mapping the business requirements articulated in the analysis document to the avail-
able technology. The analyst enjoys the luxury of assuming perfect technology. They
document the user’s requirements as if all processors were infinitely fast and all data
instantly available. The designer, however, must make the users’ whimsy and fantasy run
on the sorry collection of boxes made available by the IT department.
The designer drafts the blueprint from which the system will be constructed, making
him part engineer, part craftsman. A good designer is creative, resourceful, and savvy at
evaluating choices between less than perfect solutions. The skills of a designer are much
closer to the skills of a programmer. In fact, most designers are culled from the ranks of
the programming population. Although programming is not always a prerequisite to
becoming a good designer, you must have a firm grasp of the capabilities of the target envi-
ronment in order to craft systems which take advantage of its strong suits and avoid its
more anomalous proclivities.
ISBN: 0-536-56083-8

Specially prepared for d03063582

WHAT IS NEEDED FOR A SUCCESSFUL

CLIENT/SERVER PROJECT?

The secret to successful development in today’s multi-platform client/server environment

is really no secret at all. It takes the right people, sensible management, and a sound
methodology. Of course, it doesn’t hurt to have a big sack of money handy as well; but
since this book is conveniently not about funding client/server projects, let’s get back to
the subject of “the right people.”

The Right People

The Era of the Generalist
On occasion, when I find myself before an audience of programmers or project managers,
I like to pose the question, “When was the last time in this industry that you felt that you
knew everything?” The younger programmers look at me like I’ve gone mad, but some of
the more seasoned participants have been known to lapse into a brief reverie after which
I hear dates uttered wistfully and reverently; “1967,” “1974,” “June of 1979.”
By the mid to late 1970s, the prototypical mainframe shop was pretty much under
control from a technological standpoint.3 The languages employed to move data in and
out of files, put little green characters on terminal screens or process vast quantities of
data were fairly well established. If a project needed more help, a manager could pick up
the phone and have an additional platoon of qualified bit warriors sent over from the
local stable of programmers. It was typical by the early 1980s to see a resume that
boasted over twenty years of programming experience in a given language. If you had
hardware problems, you could call your shop’s designated vendor and they’d send a
team of blue-suited technicians winging your way on the next flight.
The workings of the mainframe were well understood, and a superb generalist
could mount tapes, lay out files, write program logic and manipulate screens. While
there were some areas of specialty emerging in the industry, the vast majority of data
processing workers did a little of everything. With a largely homogenous resource pool,
a project manager could almost get away with throwing enough people at any given
problem, secure in the belief that they’d figure it out and get it done.
Everyone could go home at night knowing that the corporate store of all knowl-
edge was safe and secure in the mainframe. Especially comforting to data processing
managers of the era was the knowledge that they were the only game in town. Their
staffs were competent, highly interchangeable, and the users had nowhere else to go.
All sense of control ended with the advent of the personal computer (PC). The first
personal computers started to appear in the back offices of many businesses in the early
1980s. Many mainframe shops failed to recognize the importance of these wimpy little
machines and regarded them in the same genre as pocket calculators, typewriters and

3 Whether it was under control from a methodological standpoint is entirely another issue.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
WHAT IS NEEDED FOR A SUCCESSFUL CLIENT/SERVER PROJECT? 7

adding machines. The users saw the PC as their savior, freeing them from the evil
clutches of the dreaded and inflexible mainframe and its white-coated attendants in the
air-conditioned glass room.
Before long, any user with a respectable petty cash allowance could amble down to
the corner store and purchase a PC and box of floppy disks. A new species of techies
appeared on the planet who weren’t entirely programmers in the traditional sense, yet they
were being hired by users in droves to write spreadsheet macros, build little desktop data-
bases, and hook up laser printers. The result in many shops was chaos and anarchy. The
mainframe was no longer considered to be the vast ocean of information that it once was.
Instead, the repository of corporate knowledge was scattered on the hard drives and
floppy disks of the PCs throughout the enterprise like so many tidal pools.
The PC explosion forced the status quo to recognize the power of packaged software
and end-user computing in the business community. By the mid-to-late 1980s, IT shops
were scrambling to make sense of what hit them and construct a strategy to get the corpo-
rate information flow back under control. About the same time, reliable network technol-
ogy began to emerge which enabled personal computers to be hooked together into work
groups and to access the mainframe and shared file servers. Client/server technology had
entered the mainstream of business computing.

The Trend Toward Specialization

Those IT managers who were huddled in the bomb shelter during the technology boom
of the 1980s emerged to a completely foreign landscape in the 1990s. A robust IT depart-
ment is no longer composed of iterations of the same skill set. Much like the medical
profession, the body of knowledge required to keep up with the technology explosion
has become so large that specialization is becoming a must. A development team needs
skills in business analysis, event modeling, information modeling, interface design, data-
base design, user representation, business issue resolution, database administration,
object class library management, network communications, host systems hardware and
operations, personal computer hardware and operations, graphical user interface pro-
gramming, object-oriented programming, SQL expertise, traditional programming, elec-
tronic data interchange, project management, test planning and execution, user training,
help administration, software release management, version control and so on. (My
apologies if I’ve left out your favorite skill.)
This is not to say that the generalist has gone the way of the iceman. A stellar
development team is almost always held together by a few general practitioners who
know enough about each specialty to help orchestrate the technical effort. I also don’t
wish to imply that you need to hire a different body for every skill. Most people come
through the door with sufficient expertise in several areas; however, it is highly improb-
able to expect a person to achieve competency in all or even a majority of the skills
listed. The complexity of today’s development tools, coupled with the overwhelming
reach of automation into every facet of the business enterprise demands a level of exper-
tise in each area far beyond what is reasonable to expect from one individual.
ISBN: 0-536-56083-8

Specially prepared for d03063582

The key to assembling a successful team isn’t just to hire the requisite number of
smart people and throw them at the problem. Rather, it is to build a matrix of skills needed
throughout the duration of the project, and to determine which skills are needed at what
time. Then the project manager can go shopping for a core team to provide project conti-
nuity, and augment the team with specialists who may serve an abbreviated tour of duty,
providing critical skills only when needed (Figure 1–1).

Internal or OO design

Figure 1–1. A sample skills matrix

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
WHAT IS NEEDED FOR A SUCCESSFUL CLIENT/SERVER PROJECT? 9

The sheer complexity of today’s client/server environment forces us to recognize

that we can’t rely entirely on generalists. We need people who are highly skilled in
areas that have steep and long learning curves. Specialties are cultivated by repeated
experience. Allowing an individual to engage in the same types of tasks over and over
is the best way to build skills. This assertion challenges many traditional IT organiza-
tional structures where groups of programmers build a system for a particular part of
the business, and then stay there and maintain it until either the system or the pro-
grammers retire or die of old age. Instead, IT shops need to concentrate on specific skill
building by letting people move around from project to project so they can surpass mere
competence and rise to the level of expertise that today’s business systems demand.

Sound Project Management

The project manager’s job is to plan and assign the work, measure progress on a contin-
uous basis, and adjust the plan based on his measurements. This is an impossible task
unless you have some plan against which to gauge progress.
This book details a series of techniques for conducting analysis and design of
client/server systems and graphical user interface applications. A technique is a repeat-
able, structured method for achieving a specific task. Examples of techniques in this
book include event modeling, information modeling, and window navigation diagram-
ming. A software engineering methodology is the orderly arrangement of techniques
into a systematic approach to the construction or acquisition of information systems.
While the individual analysts, designers and developers are responsible for mas-
tering and executing the techniques, the project manager serves as the guiding force for
ordering tasks into a coherent methodology to meet the project’s objectives. The man-
ager of a software development project is very much like the general contractor of a con-
struction project. The construction manager makes sure that concrete crews, framers,
roofers, plumbers, electricians and wallboard crews arrive on the project on the appro-
priate date, and he coordinates their efforts with each other. In the same fashion, the soft-
ware development manager has to juggle the agendas and timetables of the network and
hardware crew, the business analysts, interface designers, communications specialists,
programmers, testers and trainers. The bigger the project, the more likely these will be
individual teams of people, not just different roles played by the same people.

Sound Methodology

Of Spirals and Waterfalls

Methodologies come in many shapes and sizes. Much ado has been made about the advan-
tages of a “spiral methodology” versus the “waterfall methodology.” Other entries in the
field of methodological metaphors include pyramids, whirlpools, vortices and something
ISBN: 0-536-56083-8

Specially prepared for d03063582

that resembles overlapping camel humps. Their philosophies range anywhere from a Dra-
conian cookbook approach to “evolutionary programming,” which is the latest fancy
euphemism for hacking.

The Waterfall Approach

The traditional waterfall has a certain logic to it. You do a plan for your project, then you
conduct your analysis of the problem domain. When victory is declared on analysis, the
design commences, and once the design is completed, construction begins. The outputs
from one stage are the inputs to the next, hence the metaphor of the “waterfall” (Figure 1–2).

Figure 1–2. A waterfall methodology

The waterfall has an orderly appeal that makes it an especially convenient model
for teaching software engineering techniques. In fact, you will note that this very book
is laid out in a similar manner, with the charter chapter preceding the analysis chapters,
and the design chapters following thereafter. However, the organization for learning a
series of techniques does not always equate to the organization for employing a series of
techniques in our rather chaotic and ambiguous real world. While few would argue that
planning should occur before detailed analysis, and that analysis is a logical precursor to
design and construction, it would be foolish to insist that a large-scale development project
complete all of its analysis before conducting an iota of design, or that it should design all
of the system before constructing of any part of it.
Software engineering instructors have long cautioned that while their courses were
presented in a waterfall approach, real projects were executed in phases, with many tasks
occurring concurrently and with a moderate degree of iteration as you learn things down-
stream that cause you to revisit upstream tasks. My theory is that many project managers
were out of the room, on the phone during this particular speech. Thus, the history of soft-
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
WHAT IS NEEDED FOR A SUCCESSFUL CLIENT/SERVER PROJECT? 11

ware engineering is dotted with monumental failures that were more the result of poor man-
agement of the techniques rather than due to inadequacies of the techniques themselves.
Incremental phased development and some degree of iteration has always been a
key practice in the successful implementation of any of the so-called waterfall method-
ologies (Figure 1–3). Good project managers have been doing this for years. The water-
fall methodologies really suffer from an unfortunate metaphor. Water, being a victim of
gravity, tends not to gallop back up hill for another ride over the falls. Likewise, people
tend to treat forays back into analysis or design as a retreat rather than a step forward.

Figure 1–3. A waterfall with iteration built in

Phased Implementation
It is a sensible practice to phase large projects (Figure 1–4). One of the primary reasons is
that the learning that accrues while taking a piece of the project through the whole life cycle
provides valuable expertise that speeds the development of the subsequent phases. Another
benefit is the early delivery of some portion of the system that can be used by the business.4
Many project failures which have been chalked up to the waterfall really were the
result of failure to employ sound modeling techniques in a sensibly phased implementa-
tion plan. The term “analysis paralysis” was coined to describe projects which found them-
selves entangled in a hopelessly large problem domain with no foreseeable conclusion to
the mammoth modeling effort. Such projects were usually terminated by frustrated spon-
sors, convinced that the IT department had become professional students, studying the
problem rather than doing something about it; or worse, the business needs had changed
so drastically in the ensuing eons since the project started that the resulting system would
be obsolete before it was installed.

4 This is traditionally known as the “18 month rule.” Any project failing to deliver something within
18 months is likely to be canceled. Unfortunately, the 18 month window of expectation is shrinking
in today’s fast-paced business environment.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 1–4. A phased waterfall approach

The Spiral Approach

In contrast, the spiral development model (Figure 1–5) has phasing and iteration built
right into the metaphor. The spiral model originally was developed at the Pentagon as a
method to control runaway costs on massive weapons and defense system development
projects. The idea was to break the projects into shorter phases of analysis, design, devel-
opment and evaluation. After each phase, the viability of the work completed would be
evaluated, along with a refined estimate for the next phases. This budgeting technique
provided crucial feasibility checks for projects which were often researching entirely
new technology. A decision would be made at the evaluation phase whether to continue
with another iteration.
The idea of the spiral has mutated slightly to adapt to the peculiar sensibilities of
the software industry. Instead of focusing on controlling the budget, the spiral has been
employed as a method for early delivery of code in a methodology which has become
popular under the term RAD, which stands for “Rapid Application Development.”
RAD couples the spiral approach with a strategy of dividing a large project into
“time boxes” (Figure 1–6). A time box is a defined set of functionality that is promised
to be delivered to the users within a fixed time frame, say, 90 days. Within the time box,
a modicum of analysis is done, a brief design, and then, using high-powered develop-
ment tools, a working prototype is constructed. The prototype is reviewed by the users
and modifications are requested. The cycle of coding and refining the prototype is
repeated three times, spiraling through re-analysis, re-design, coding and evaluation. At
the end of the time box, the resulting application is installed.
In practice, RAD suffers no less spectacular misapplication than the waterfall.
Many managers and programmers see the spiral model as three iterations of “coding
ISBN: 0-536-56083-8

stuff.” RAD’s primary lure is early code, and in many shops, the production of code is

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
WHAT IS NEEDED FOR A SUCCESSFUL CLIENT/SERVER PROJECT? 13

viewed as the only tangible measure that meaningful activity has occurred. This leads to
a “three strikes and it’s out” mentality where any semblance of analysis and design is
quickly abandoned, resulting in rickety systems which perform dubiously in the mainte-
nance phase of their lives.

Figure 1–5. A spiral methodology

Figure 1–6. Three spiral iterations within time boxes

RAD’s strong points are intensive user involvement, early prototyping, and phased
implementation. Its weak points include a bias toward early coding which shifts many
analysis and design tasks into the hands of the programmer, hence a dependency on
superb generalists. It relies on programmers who are masters of their respective devel-
opment tools and programming environments and at the same time are adept at interface
ISBN: 0-536-56083-8

Specially prepared for d03063582

design and business analysis and are skillful communicators. The overwhelming focus
on the time box makes it difficult to engineer reusable components for the long term, and
when the due date approaches, the first thing to go is the documentation. Instead of man-
aging against a tangible specification, the manager finds himself armed with nothing but
a bullwhip and a stop watch. The primary measure of progress becomes the number of
revisions made to the code.
I recently encountered a client who had been sent to a seminar to investigate spi-
ral development. While there, he learned about RAD techniques and how software is
incrementally improved with each iteration through the spiral. He returned to work on
Monday, beaming with enlightenment and announced to the project team, “The quality
of a software system is proportional to the number of versions you throw away.” To me,
this sounded vaguely like the chorus from an industry that has all but given up trying to
build it right the first time. His budget-rattling conclusion reminded me of the story of
Odius and Tedius, two temple builders in ancient Rome.

Odius was a Roman project manager stationed near Salisbury, England in the
3rd century AD, who is credited with declaring, “The quality of a temple is
proportional to the number of temples you throw away.” After ordering the
construction and subsequent demolition of at least three versions of the
town’s temple, he was brutally murdered in an uprising by his Briton con-
scripts. As it turned out, the locals had saved the Emperor the cost of a pub-
lic execution, since Odius had woefully overspent his capital budget and had
nothing to show for it except three piles of rubble.
Odius was succeeded by his cousin, Tedius, who employed a strict
waterfall approach to temple building. After three years of analyzing and bal-
ancing the needs of the priests, gods and worshipers, Tedius had produced
rolls and rolls of models and diagrams but a temple had still failed to mate-
rialize on the Salisbury plain. Tedius was simultaneously dispatched from the
project and the planet for failure to deliver.

The waterfall and the spiral approaches both have good points. Unfortunately, they
both suffer from shocking abuses in the real world. I believe that the key to project success
lies somewhere between these two extremes. The fact is, a superb manager will be able to
make either a waterfall or a spiral approach work. If handed a waterfall to work with, he
will break the project into multiple phases and may introduce some manner of controlled
iterations. If given a spiral, he will continue to employ sound “waterfall” techniques
through each phase and iteration to create more discrete units with which the project can
be effectively managed.5
By assembling the right people with the appropriate skills, employing sensible
management of phased deliverables, and using a sound development methodology, a

5 A poor project manager is likely to make a mess of either approach.

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

project can enjoy the benefits of a rich foundation of models without sinking into the
quagmire of analysis paralysis or without hacking out inadequate solutions in a clicking
and coding frenzy.

WHAT MAKES A METHODOLOGY “GOOD”?

A good methodology arms practitioners with a tool kit of reliable, repeatable techniques
that are particularly well suited to the problems they are trying to solve. The techniques
in the modeler’s quiver should allow him to assemble the proper balance and mix of
techniques for the problem at hand. Not all business problems are created equal. Some
are rich in data but have very little processing requirements. Others are event-rich, with
almost no process but entail large amounts of data, and so on. A balanced methodology
includes techniques which give the analysts and designers full coverage of all of the
aspects that they might need to model, but allows them to skew their modeling empha-
sis to match the bias of the business problem.
Any good analysis or design methodology should have five basic traits. It should:

1. Encourage the intended activity,

2. Be complete,
3. Be verifiable for correctness,
4. Produce deliverables against which progress can be measured,
5. Be easily consumable in the subsequent phase.

Let’s examine these traits of good analysis and design methodologies, starting with
how they apply to good design practices.

Characteristics of Good Design Methodologies

Design is the act of deciding how the system shall be constructed to meet the users’
requirements. Good design methodologies share the following characteristics:

1. Good design should encourage decision-making by helping to evaluate

choices. Design is all about trade-offs. As we will see, later in the book, there
is no perfect solution in the client/server environment. For each essential busi-
ness requirement, there will be many possible ways to achieve it. A design tech-
nique should allow the designer to evaluate their decision against other
possibilities. For example, using the analysis event model coupled with a data-
base design schema, the designer can simulate the volume of reads and writes
to the database for any given business event (e.g., Customer places order). This
allows the team to evaluate the feasibility and projected performance of a given
database table layout and data distribution scheme prior to building it.
ISBN: 0-536-56083-8

Specially prepared for d03063582

2. The design needs to be complete, in that it covers each major aspect of the soft-
ware that needs to be built. This will cause you to have several different kinds
of models in the design documentation. Much like the architectural blueprints
for the foundation, framing, electrical and plumbing systems of a house, the
software design blueprint includes a model for the database layout, window and
report layout, window navigation, specifications for any other electronic inter-
faces, and static and dynamic models of the internal componentry. Each model
is specialized to depict a particular aspect of the system. You will find that mod-
els are particularly adept at articulating those aspects for which the modeling
technique was intended, but fail miserably when you attempt to stretch the
model beyond its original purpose. No model can depict all facets of the entire
working system. That would be the system itself.
3. The design should be verifiable prior to construction. One of the primary pur-
poses of design is to review and discuss the solution before charging ahead and
coding it. Part of the verification process is traceability. With a good design
specification, you should be able to demonstrate that the requirements of the
project will be met, as well as distinguish between various versions of the
design at any point in time.
The design documentation has two distinct audiences. The externally visible
portions of the design (window layouts, reports, navigation diagrams, menu
and button specifications) need to be reviewed by the user community. This
means that a large portion of the external design should be written in a non-
technical manner. The internal specifications for what happens behind the
scenes is another matter. The audience for internal specifications is limited to
the IT community that must build, test and maintain the system. The internal
specification should be written directly for this audience.
4. A good design methodology creates distinct deliverables which are measurable.
One of the most formidable tasks of any project is estimating when it will be
done. In order to make an estimate, the project manager must take measure-
ments. Taking measurements involves counting things that need to be done and
applying some sort of metric against them to estimate how long it will take to
do them. The metric, of course, comes from having counted these things in the
past and having measured how long it took to do them before (or from stealing
someone else’s metric). Therefore, a design methodology must render up
countable components as early as possible. “How many tables do we have?
How many windows will be required for the interface? How many reports are
required? What is the number of objects we need to design and construct?”
As soon as the manager can get a hold of solid deliverables to count, he can
start refining estimates on the requisite effort and skills sets needed to accom-
plish the task. As the project progresses, he then has intermediate deliverables
against which progress can be gauged. “How many windows have been
designed? How many are left to be designed? What is the team’s productivity
rate? What is the average time it is taking us to code and test a window and its
ISBN: 0-536-56083-8

background functions? What does that do to our original estimate?”

Specially prepared for d03063582 on 25 Oct, 2010

5. Last, but not least, the design should be easily consumed in the final product.
It should express the usage and structure of the system in a form very close to
the intended result. This point may seem obvious, but I have seen projects
which attempted to use design techniques which were entirely inappropriate for
the target language in which the system was to be coded. You wouldn’t want
your home architect to render a blueprint that was so esoteric that you had no
idea what manner of house would arise on your lot. The motto of the designer
is: map the technique to the target. If your system is to operate over a relational
database, then choose techniques which are particularly well-suited to rela-
tional database design. If your system will employ an object-oriented language,
then you should be using object-oriented design techniques for those parts of
the system which will require objects to accomplish their tasks. If your system
will include more traditional components, such as structured functions on the
client or batch routines on the server, then more traditional structured design
techniques are in order for those parts of the system.
Many of today’s client/server business systems have all of the afore mentioned
language paradigms, attempting valiantly to live in harmony. If this is true for
your system, then your design document will include a variety of design tech-
niques, ranging from relational, object-oriented to traditional, each mapped to
their respective target portions of the system.

Characteristics of Good Analysis Methodologies

Analysis is the act of understanding and documenting the user’s needs. Understanding
comes from asking questions and writing down the answers, examining the answers and
asking more questions. An analyst who asks no questions is conducting questionable
analysis, indeed. An analyst who writes nothing down has done no analysis at all, rather
he is on a journey of self-improvement by expanding his personal knowledge of the busi-
ness. Failing to document your analytical discoveries sabotages all five of the benefits of
successful analysis. The result is neither analytical, complete, verifiable, measurable or
consumable. Assuming then that good analysis is written down, a successful analysis
methodology will exhibit the following characteristics:

1. An analysis technique should encourage the act of discovery by providing a

framework in which the analyst can write down what they know and evaluate
what they have yet to learn. This includes having a rich set of heuristics to guide
the analysis. For instance, the analysis technique of information modeling dic-
tates that the analyst discover the business policy for all four points of cardinal-
ity on each relationship.6 The model gives you a place to record this information
and the result is visually apparent on the entity-relationship diagram for review.
ISBN: 0-536-56083-8

6 The concepts of information modeling are covered in Chapter 5.

Specially prepared for d03063582

2. The analysis methodology should be complete in that it adequately covers each

aspect of the business problem. As we will see later in this book, business sys-
tems have data they must remember, processing rules, and definable behavior.
The analysis methodology needs to be sufficiently rich to model all three view-
points. Because no model can serve all masters adequately, we will need to
employ a suite of specialized, interlocking models which allow us to rotate our
perspective to each facet of the problem domain.
3. The results of the analysis needs to be verifiable. The analysis phase also has a
dual audience. The users are the primary audience for blessing the documents
as an accurate representation of their needs. Most software engineering models
fail to live up to this requirement. Your average user isn’t going to point out an
inaccurate relationship cardinality on an information model any more than they
are going to challenge your employment of multiple inheritance on an object-
oriented class diagram. Instead of subjecting users to the technical models, a
good analytical technique will be easily convertible into something with which
the users are more familiar, such as a prototype of window layouts.
It is imperative that the users understand what the analyst has discovered.
Analysis should not be conducted in the dark dungeons of the IT department
with the resulting epic tome mailed out to users for their signature. Instead,
users need to be personally involved with the project from the beginning,
and as much as possible, joint application requirement sessions (JAR), peri-
odic analysis reviews and inspections should be conducted by the analyst
with groups of users present. An adept analyst will stop at nothing to make
sure the users are on the same wavelength as the project team. I call this the
“interpretive dance” portion of the project, where you may find yourself
engaging in wild gesticulations, pasting clip art over the top of an entity-
relationship diagram, or inviting users to fill real data into your window lay-
outs on an overhead project with colored pens.
The other audience for the analysis document, is of course, the project team
itself. The quality of the analysis will impact the quality of the design. The
analysis techniques need to be precise and unambiguous such that a designer can
devise a solution without having to retread through the entire analysis process.
4. The analysis methodology must also create measurable units for the project
manager. At the start of the analysis stage, the size and scope of the project
may still be a bit fuzzy. The business wants to know when their software will
be delivered, and the project manager still doesn’t know the size of the prob-
lem. The early analysis models can go a long way toward serving up things for
the manager to count. These early counts are used to extrapolate the effort
required for the rest of the project. The manager should be asking, “How many
entities are involved? Does our system create, read, update or delete all of
those entities? How many significant business events is the system chartered
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

to recognize? Do those events entail simple table updates or do they require

significant processing? How long does it take us to analyze problems of this
size? Given the number of entities we expect to maintain, how many windows
will we need to design?”
5. This brings us to the final topic of consumability. Nobody in this industry
would argue that an analysis methodology should encourage analysis, be
complete, verifiable and measurable. The extent to which it should be easily
convertible into a design, and therefore, might be biased towards a particular
type of design, has provided the catalyst for many heated and contentious
conference debates.
Conventional wisdom has long held that analysis should be an articulation of
the problem’s essence, completely free from any particular solution, hence the
term essential analysis. People have found, in practice, that some analysis tech-
niques are predisposed to being more easily convertible into a particular design
than others. As a practical matter, if you are confronted with a set of compet-
ing analysis methodologies, each replete with techniques which encourage
good analysis; have balanced coverage of data, process and behavior; are
equally verifiable; and produce measurable results, then the tie breaker over
which one to use will likely come down to consumability.
In my own career, I have not yet found an analysis modeling technique that is
completely without some technical bias. Structured analysis,7 and its emphasis
on data flow diagramming is very process-oriented. It is fairly easy to convert
a set of data flow diagrams into a structure chart for a 3GL system. That is fine
for building process-oriented systems. It is not so easy to convert a set of data
flow diagrams into an object-oriented design. The technique is also quite cum-
bersome for designing graphical user interfaces.
In a very similar manner, object-oriented analysis (OOA),8 enjoys a much
higher convertibility factor if the target is a full-blown object-oriented system.
If the target is not an object-oriented system, or perhaps a mixed-paradigm sys-
tem (e.g., relational, 4GL and some objects), then object-oriented analysis will
have a lower convertibility factor and can actually make the designer’s life
more difficult. OOA is simply another way to organize the same essential infor-
mation that must be articulated for any successful analysis effort. The OOA
organization may be well suited to object-oriented projects, only because it is
more directly consumable in object-oriented design, not because it enjoys any
superiority as analytical technique or is any way more complete, verifiable, or
measurable.

7 De Marco, 1979.
8 Booch, 1994, Jacobsen et al., 1992, Rumbaugh et al., 1991.
ISBN: 0-536-56083-8

Specially prepared for d03063582

The ability to easily convert an analysis model into a design walks a fine line
between articulating the problem and mandating a solution. The shape of the
analysis models can profoundly influence the shape of the design. A particular
analysis methodology could dictate a particular type of design, in that to choose
any other style of design would entail a re-write of the analysis document. In
this instance, the analysis actually prohibits the devising of an alternative
design paradigm. The danger of this situation is that the analyst may make pre-
mature design decisions in the name of analysis, closing off options that can be
safely deferred until a time when better information exists on which to base a
decision. A common example arises in object-oriented analysis models when
the analyst attempts to allocate a particularly vexing method to its single best
home, only to find that the process could live in a variety of classes, each solu-
tion with its respective pros and cons.9 This type of trade-off is indicative of a
design decision, not an analysis discovery.
On the other hand, a particular analysis methodology might encourage or allow
for a variety of designs by providing enough analysis material that is easily
assembled in different ways. It is likely that if an analysis methodology encour-
ages certain types of design, it may discourage others (e.g., an information model
may encourage a relational design, but discourage the use of, say, 3-dimensional
array technology).
Finally, an analysis technique could be entirely neutral as to the various design
options which might be employed. The conversion into one paradigm versus
another would be done with equal ease or equal difficulty.

For this book, I have chosen a set of analysis techniques, specifically, context mod-
eling, event modeling, information modeling and interface prototyping, which I believe
are appropriate for the vast majority of today’s client/server business systems, and stand
up well to the five criteria for a good methodology. Each model has a firm historical
grounding in software engineering, and a long successful track record in the industry.
They have been proven to encourage good analysis, and cover the gamut of process, data
and system behavior. The inclusion of the interface prototype goes a long way toward
making the results of the analysis verifiable by the user community. The models also
produce discrete units which can be counted and measured, such as entities, events, win-
dows, and reports. These units have been around long enough to have amassed a mod-
est base of metrics within the industry.
So, where do the techniques in this book stand on the issue of consumability? The
activities of analysis, detailed in the following chapters, were selected with consumption
in mind. As one who has spent roughly equal time designing systems as I have analyz-
ing them, the ability to transition easily from analysis to design is very important to me.

9 Object-oriented techniques are covered in Chapter 12.

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

The technological premise of this book is that your target business system is most
likely to include a relational database, a graphical user interface, and a variety of program-
ming languages which may range from object-oriented, to object-based, to SQL-based,
to traditional 3GLs, with the industry trending more and more toward object-oriented
constructs. The analysis models will need to convert handily into designs for this environ-
ment. I have included techniques which fall into the category of encouraging and allowing
for the likely target design, without absolutely mandating a particular design paradigm or
prohibiting others.
I have chosen the information model as the primary data model because of its excel-
lent track record for creating well-normalized relational database designs. It is a technique
which has been very popular and successful, and as a result, the discipline enjoys a wide
field of expert practitioners. The information model shows quite clearly what needs to be
remembered in the system, without cluttering the view with procedural elements that cur-
rent relational database management systems are not capable of handling.
The event model is included because it is particularly well suited to organizing the
analysis specification in such a manner that it lends itself well to designing the event-driven
graphical user interface, a task which will consume a great deal of project time. The event
dictionary provides the framework for the system’s internal process specification. Taken
together with the information model, these two models contain the raw materials needed to
declare a class structure for an object-oriented system, design structure charts for traditional
system components, or design stored procedures for the database server.
The context model is included as a time-honored technique for determining and
depicting project scope. It is mainly a planning tool that helps clarify the area of study
and determine what lies inside and outside of your span of control.

OVERVIEW OF THE TECHNIQUES IN THIS BOOK

Let’s get on with the important task of previewing what lies ahead between here and
the index.
I shall use the pyramid as the primary geometric metaphor to organize the activi-
ties of system development (Figure 1–7). There isn’t tremendous significance attached
to the pyramid per se. I could just as easily use a square, circle or a set of amorphous
clouds, but I find the pyramid representation convenient for a number of reasons.
The pyramid never lets you forget that the code you build is simply the founda-
tion of a structure which is chartered to reach a set of business objectives. At the top
of the pyramid is the project charter. This includes the goal of the project and its sup-
porting objectives. These are the reasons that the project exists in the first place.
Beneath the charter are all of the activities, roughly arranged in a descending fashion,
that need to occur between the identification of the project’s business objectives, and
the deployment of the ones and zeros at the bottom of the pyramid that constitute the
resulting software.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 1–7. The software development pyramid

If you think of time traveling roughly north to south, the pyramid graphically
depicts your ever-expanding base of knowledge about a subject as you descend from the
lofty reaches of analysis, down through design, and then start grubbing around in the
code. Project managers, business sponsors, and the more cynical among us may prefer
to picture the pyramid as the ever-widening expenditure of money as time marches on.
The structure of the pyramid metaphor is not intended in any way to mandate a
waterfall or a spiral approach to get from the top to the bottom. Rather, it shows how the
final code and intermediate analysis and design products support the business charter.
Whether you phase your project, or develop it in one grand sweep, will depend on the
size of the project and the demands of your business.
Let’s start at the top and work our way down.
Every project needs a charter (Figure 1–8). The charter contains the marching
orders from the business that articulate the end goal and objectives of the project. The
charter is a planning tool that is developed by the IT group, in concert with the business.
It is vital for defining and controlling scope. Without a charter, the analyst has no clear
direction or priorities for what to analyze, and has no idea when to stop. You will find
the project charter covered in Chapter 2.
You may find it curious to see the next three models aligned on the same level of
the pyramid. The context model, event model and information model are so interdepen-
dent that it is impossible to finish one without having a good handle on the others. I call
them the “big three” because together they form the bulk of the system requirements.
The context model (Figure 1–9) defines the system’s boundaries and shows how it
is situated within the business environment. This is a venerable old modeling technique
which hails from the days of structured analysis. It is particularly handy in today’s
client/server world to explore the impact of moving the automation boundary in the busi-
ness. Context modeling is covered in Chapter 3.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Figure 1–8. The project charter

Figure 1–9. The context model

The event model (Figure 1–10) defines the system’s behavior by showing how the
system is expected to respond for each business event in the charter. Not only does the
event model map inputs to outputs, it includes the processing specification for each event
that provides crucial detail for the internal design of the system’s functions, methods and
procedures. Event modeling is a vital analytical technique for discovering and document-
ing business rules. Because graphical user interfaces are, by definition, “event driven,”
the event model provides the framework and rationale for the design of the user interface.
Chapter 4 in this book is dedicated to event modeling.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 1–10. The event model

The final model of the “big three” is perhaps the most crucial of all. The informa-
tion model (Figure 1–11) contains the static map of the data that the system is required
to remember. It profoundly influences the database design and impacts virtually every
aspect of the system. The modeling techniques include entity-relationship diagramming,
attribute definition and state-transition diagramming. Information models also respect no
project boundaries. Much of the data you will be modeling for your system will also make
an appearance in other systems within your organization (and perhaps outside of it too).
For this reason, it is imperative that information modeling efforts have some enterprise-
wide coordination. Information modeling should always be conducted with a strong sense
of context, bound by a scope of business events. Otherwise, you can model data forever
or until you run out of time or money. Information modeling is the topic of Chapter 5.

Figure 1–11. The information model

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

The interface prototype (Figure 1–12) lies just below the “big three” models. I am
a strong advocate of early prototyping, especially those of the quick and easy variety.
The prototype puts a face on the abstract models by sketching out what the windows and
reports could look like in the new system. Although prototyping is begun early in the
analysis phase, it is the first foray into system design. In practice, I have found it virtu-
ally impossible to finish the “big three” without verifying the requirements with some
level of interface prototype. On some projects, I have used prototyping even earlier to
drive out business event requirements and the information model. You may find yourself
bouncing back and forth between the “big three” and the prototype several times until
you and your users are convinced that you understand their needs. A robust system may
have many different kinds of prototype. The key to successful prototyping is to first iden-
tify the learning objective, and then to choose the most cost-effective method of proto-
typing for reaching that particular objective. Prototyping is the subject of Chapter 6.

Figure 1–12. The interface prototype

Chapter 7 takes a brief pause from modeling to discuss the important topic of
resolving business issues. One of the most insidious project-killers of client/server
endeavors is the hidden cost of re-engineering the business. Client/server often brings
standardization and automation to frontiers of the business that were heretofore the
domain of the spreadsheet, word processor, yellow sticky-note and scribbled cocktail
napkin. As an analyst, you may find yourself in the unfortunate position of discovering
gaping holes in the target company’s business practices or policies with absolutely no
authority to resolve them. Chapter 7 lays out an issue resolution process that can be used
to remove these project roadblocks.
We return to our pyramid in Chapter 8 with architecture modeling. Architecture
modeling is the process of mapping the business requirements articulated in the analysis
ISBN: 0-536-56083-8

Specially prepared for d03063582

OVERVIEW OF THE TECHNIQUES IN THIS BOOK

Specially prepared for d03063582

Figure 1–7. The software development pyramid

Specially prepared for d03063582 on 25 Oct, 2010

Figure 1–8. The project charter

Figure 1–9. The context model

Specially prepared for d03063582

Figure 1–10. The event model

Figure 1–11. The information model

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Figure 1–12. The interface prototype

Specially prepared for d03063582

models onto a variety of hardware configurations, and choosing the most appropriate, or the
least offensive. For this task, the analysis models need to be supplemented with some sta-
tistics, such as transaction volumes, event rates, record sizes and user expectations for
response time and data currency. There is no “right” answer in architecture modeling. Every
business and every target programming environment comes with its own peculiar warts and
wrinkles. The key to successful architecture modeling is to be able to use the models to eval-
uate the design trade-offs and relative performance of different geographic distribution
schemes, as well as the distribution among hardware tiers within the same business site.
While many of the analysis and design activities can be easily partitioned and
phased, much of the overall client/server architecture for the whole project is likely to be
decided prior to the design of the first phase. In practice, it is also unlikely that the hard-
ware will be chosen after all of the analysis is conducted. The architectural track often
runs parallel with the analysis effort. In some projects, you may not be able to choose
the most appropriate hardware at all; instead you may be forced to squeeze your soft-
ware into the ramshackle collection of boxes already in residence in the computer room.
Architecture modeling (Figure 1–13) takes up this late position on the pyramid because
this is the last point to which you can safely defer architectural choices, and it is also the
point at which you are armed with the best information on which to base those decisions.

Figure 1–13. The architecture model

The database design (Figure 1–14) transforms the information model into a physical
database schema. Whether you design all of your database at once or in phases, may depend
on whether you phase your project. Like many of the subjects in this book, a full discussion
on the art of database design could fill an entire volume. The purpose of Chapter 9 is to show
how the information model transforms into a first-cut relational database design, and to dis-
cuss the various options at your disposal for optimizing performance.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Figure 1–14. The database design

Chapters 10 and 11 cover the design of the graphical user interface. Chapter 10
starts with a discussion of what makes a “good” GUI. Many of the concepts represent
a significant shift from the green screen world of the mainframe. The last part of Chap-
ter 10 introduces the concept of window cohesion. I have applied Larry Constantine’s10
measure of module cohesion from structured design, and adapted it as a rating of the
impact on usability and maintainability of combining multiple business events on the
same window.
External interface design (Figure 1–15) is covered in Chapter 11. This includes
window navigation diagramming, an important and cost-effective technique for deter-
mining window type, navigation and defining the user’s appropriate unit of work. The
external interface design refines the analysis prototype into a formal design specification
from which the interface can be coded. A written specification is crucial for the testing of
a GUI and for downstream user training and documentation. I have conducted GUI devel-
opment many times both with a written specification and without. I need no further con-
vincing that the written external design specification is vital to the construction, testing
and implementation of the project.
The internal component design (Figure 1–16) of the system includes models
which map directly to paradigm of the target coding language. If the system includes
object-oriented code, then the internal design will include both class models and
dynamic object-communication models for that part of the system. If the system
includes more traditional functions and database procedures, then you will find your-
self drawing structure charts and writing specs for stored procedures. Chapter 12 shows
how the models of analysis are consumed in the activities of internal design.

10 Yourdon, Constantine, 1979.

ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 1–15. The external interface design

Figure 1–16. The internal component design

At the bottom of the pyramid is the construction phase, which includes coding,
testing and deployment. While coding and testing are not the primary topics of this book,
I include a discussion at the end of Chapter 11 on the challenges of testing a graphical
user interface, and how the analysis and design specification can be used to create test
scripts and scenarios.
The book concludes with Chapter 13 which includes some issues for managers.
The client/server revolution has spawned a number of myths and exaggerated claims. In
this closing chapter, I chime in with my two-cents-worth, debunking ten myths of
client/server development.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
SUMMARY 29

SUMMARY

Analysis is a voyage of discovery in which the participants determine a business sys-

tem’s data, process and behavioral requirements. Design is the act of deciding how to
implement a system that meets those needs. We are experiencing a trend toward spe-
cialization in our industry which is driven by the ever-expanding universe of knowledge
required to conduct software development. The skills needed to be a good analyst are not
necessarily the same skills needed to be a good programmer. Project managers are
increasingly finding themselves managing teams of specialists rather than the groups of
generalists that tended to be employed on traditional development projects.
While the individual project member is a competent practitioner of his respective
techniques, a project manager’s job is much like the general contractor, coordinating the
activities of the specialists into a sensible methodology. Methodologies come in many
forms. Both the traditional waterfall approaches and spiral models have many good points,
but both suffer from abuses in practice. A sensible manager will phase large projects and
build a degree of iteration into the project plan. While I have chosen the pyramid in this
book to represent the organization of the models, their dependencies and the project’s
expanding level of commitment over time, it does not imply a waterfall, nor does it endorse
radical iteration.
Imagine your development team deposited by helicopter on the top of a pyramid
in Egypt. You would not be compelled to descend directly to the bottom, but instead you
may explore the terrain of various levels, sometimes retreating back up in your eventual
journey to the bottom. However, there is a logical progression of activities in software
development. Like our imaginary hike down the pyramid, it would be risky to jump from
the top level to the bottom in one step. Leaping from charter directly to code carries with
it similar risk. It is up to the project manager to decide whether it is appropriate to lead
his troops en masse in a direct descent from top to bottom, or to divide and conquer the
pyramid with multiple journeys and iterative side trips to ensure complete coverage of
the terrain.
Any good methodology should encourage the intended activity by providing a
framework in which to record knowledge. The techniques employed should be complete,
in that they cover all aspects of the problem and solution domain. The models created
should be verifiable for correctness by their intended audience. This audience can be
both technical and non-technical. The methodology must produce units against which
progress can be measured, forming a basis for estimating level of effort. Finally, the
deliverables must lend themselves to being easily consumed in the subsequent phases of
the project.
The models and activities of the analysis phase include project charters, context
modeling, event modeling, information modeling, interface prototyping and business
issue resolution. The design activities produce an architectural model, database design,
external interface design and internal component design which form the blueprint for
constructing and testing the system.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
CHAPTER
2

THE PROJECT
CHARTER

INTRODUCTION

A successful project begins with a good plan. In Chapter 2, I cover the project chartering
process and introduce a valuable technique called the project decision-making framework.
This technique is particularly useful for leading the business members through the steps of
understanding their current problems and recognizing new opportunities that have gone
previously unexploited. Those problems and opportunities then form the basis for articu-
lating the objectives of the project in clear, measurable terms. Rather than simply accept-
ing a list of “requirements” at face value, this technique helps the business people and the
IT professionals come to consensus on what business problems the new system is really
supposed to solve. The charter gets everybody aligned and pointed in the same direction.
It states the project’s reason for existence for all to see, and clearly prioritizes the project’s
ISBN: 0-536-56083-8

Specially prepared for d03063582

objectives. The objectives stated in the charter become part of the evaluation criteria that
can be used to choose between various solution options all throughout the project. The first
solution option, as we will see near the end of the chapter, is whether to even proceed with
the project in the first place.

THE PURPOSE OF THE CHARTER

The charter states the goals and objectives of the project. More important, it provides
a set of measurements which let you know when you have achieved your objectives.
It also states who does what, for both the IT department and the users. The charter is
a contract, and like a contractual agreement, it takes two parties to complete the trans-
action. There are significant roles and responsibilities on both sides.
Most builders wouldn’t dream of building a house without a contract. These
days, the neighborhood baby sitter might even ask you to sign a contract before
watching over your little darlings. Likewise, it makes no sense at all to embark on
building large-scale information systems without any semblance of a contract with
the business.

WHO DOES THE CHARTER?

The chartering process is a cooperative effort between IT and the business. It is the
responsibility of the IT organization to provide technical, analytical, and procedural
assistance and to lead the business through the process of producing a charter. IT acts as
a facilitator to lead the business through the various solutions which could help the busi-
ness meet its goals.
It is the responsibility of the business to commit the people and the time to
articulate the business’ goals, objectives and evaluation criteria, and to materially
participate in the decisions made. The information systems people are usually not the
policy-makers in an organization. This is why it is critical for members of the busi-
ness to articulate their goals and objectives clearly so IT can provide the appropriate
technical support.
Unfortunately, for many organizations, the goals and objectives are not clearly
stated, or worse, not even written down. In these cases, the IT department must extend
their responsibility further to help the business communicate, and sometimes discover,
their needs. If the information systems people don’t step in to fill the void in the plan-
ning phase, the project may be doomed from the start. This constitutes a large leap “out
of bounds” for many technical people. In addition to delivering systems, we have a
responsibility to educate business leaders as to their role in the planning and develop-
ment process.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

HOW ACCURATE MUST THE CHARTER BE?

The charter is the project’s strategic plan and marching orders. The chartering process
determines the feasibility of proceeding with a project, and what direction and pace the
effort should take. In addition to stating the objectives of the project, the charter details
the estimated cost of pursuing those objectives. The quality of the charter is crucial to
the success of the project which follows.
The accuracy of the project time and resource estimates made in the charter are
directly proportional to the amount of effort put into them. The more up-front modeling
done for the charter (covered in the following four chapters), the better the estimates.
This is not to say that your typical chartering effort will require a full-blown analysis.
The amount of modeling and research that you put into a charter is determined by how
detailed a project time and cost estimate you must submit. In more cynical terms, the
quality of the estimate in the charter is determined by how broad an estimate the busi-
ness will let you get away with. A very small and innocuous project has little downside
of being off the mark, and therefore requires very little in the way of a formal charter. A
large and high-profile project, however, should include careful planning. Whether your
project is small, medium or large, it is advisable to go through the chartering steps out-
lined in this chapter. It is the need for accuracy, or perhaps the risk of inaccuracy, that
will determine how rapidly you proceed through this phase.
Many of you may have found yourselves trapped in a meeting where your busi-
ness sponsors demanded a gold-plated, engraved, one-hundred-percent-accurate cost
estimate for a project on the very day that they saw fit to reveal their requirements.
(Even though they reserved the right to change the requirements at any point in time
without affecting the due date or budget.) While common, this situation is largely due
to ignorance, inexperience or wishful thinking on the part of the user. (I have found the
occasional executive who believes it profitable to play such games, and usually this
type of individual is steering the firm down a risky and treacherous course on many
fronts due to his recklessness.)
It is not in your best interest to roll over and blurt out a number under duress. An
estimate is only one-hundred percent accurate on the last day of the project. On the first
day of the project, an estimate is usually not worth the oxygen it took to utter it. What
you need is a way to pull yourself quickly up the accuracy scale from zero percent to a
level you and the business can live with. The chartering process is designed to rapidly
increase your understanding of the problem, and therefore, allow you to increase the
accuracy of your estimates for a solution as early in the project as possible.
I have found that by involving the business members intimately in the creation of
the charter, their sense of ownership in the project and its estimates is greatly increased,
as is their appreciation of the challenge of producing meaningful cost, time and resource
projections with limited information.
ISBN: 0-536-56083-8

Specially prepared for d03063582

A good charter is never cast entirely in stone. It is periodically revisited as the project
progresses to check and to revise the estimates. Managing a project against a well-crafted
charter is also the best way I know of to assess the impact of scope changes that occur along
the way. When the business members help you create the charter, they are more likely to
understand how mid-stream changes in requirements can affect the time and budget
required to finish the system.

BEWARE OF SLOPPY CHARTERS

Many project disasters can be traced back to a sloppy or missing charter. A spectacular
example occurred once at Frieda’s French Fry Factory.1 The factory floor manufacturing
systems were run via a motley collection of ancient batch applications. The system was
written about fifteen to twenty years ago in a mix of COBOL and Assembly Language.
The users were beginning to wonder aloud why their children were using a PC at the
local pre-school to identify stellar constellations, while at work they were still typing
mnemonics on a blank screen.2
Fenwick Prescott, the chief information officer, moved quickly to convene a project
team, nominate an acronym, and get started with the important work of requirements
analysis. Unfortunately, he didn’t bother to produce a charter which stated the project’s
objectives and scope. A team of analysts descended on the business, producing reams of
diagrams, bubbles and arrows, and boxes and lines. Within months the scope of the analy-
sis had spread from the production systems into sales, order entry, invoicing, accounting,
human resources and payroll. Each user and business manager added their own personal
laundry list of requirements to the project, creating monumental scope creep. The project
manager had nothing to manage against, because the original expectation had never been
written down and agreed upon.
After eighteen months, it was clear that the project team was lost in the wilderness.
The initial euphoria had long since worn off and open animosity and acrimony had bro-
ken out between the business and the IT department. Convinced that the IT department
was incapable of producing anything, the CEO negotiated a secret deal to outsource the
company’s information management, and summarily fired the entire IT staff, including
a beleaguered and bewildered Mr. Prescott.
The lesson to be learned is that the charter establishes a contractual obligation
between IT and the business. It is important to state each party’s expectation and respon-
sibilities explicitly. If it is not written down, the unstated expectations may come back to

1 The names have been changed to protect the guilty.

2 This is a mundane, but powerful example of how the PC has changed user expectations of what con-
stitutes an acceptable interface. Many workers are simply refusing to use the old technology, and
companies are finding it increasingly difficult to lure new college graduates into jobs that involve
using character-based systems.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

bite you. In today’s global information marketplace, a technical or political project fail-
ure can result in the wholesale elimination of the IT department.

THE PROJECT DECISION-MAKING FRAMEWORK

Any sensible development life cycle includes a planning or feasibility stage. I like the
term “project charter” because the word charter connotes “reason for being.” The project
decision-making framework is a technique for bringing people together to reach consen-
sus on the goal, objectives, and evaluation criteria for a project. This common vision is
then used as the basis for making choices throughout the project’s existence.
Figure 2–1 shows a diagram of the project decision-making framework. At the very
top of the pyramid is the project’s goal. The goal is a summary statement which lets every-
one know what the project is attempting to achieve. Supporting the goal, in the next layer,
are a variety of objectives. Objectives are like mini-goals. Each objective contributes to
the goal in some way. When all of the objectives are met, the goal has been reached.

Problems Opportunities

Figure 2–1. The project decision-making framework

Underneath the objectives is a layer called the evaluation criteria. This layer contains
the measurements that you will need to determine whether an objective has been met. The
bottom-most strata of the decision-making framework represents the various solution
options that are possible. Solution options are all of the various paths that could be taken
to reach the goal. The solution options are evaluated against the objectives by using the
evaluation criteria to determine which solution best meets the project’s objectives.
The remainder of this chapter will focus on how to use the decision-making frame-
work to create a charter for your project. This is not an exercise that is done by a manager,
ISBN: 0-536-56083-8

Specially prepared for d03063582

hidden away in a dark corner. The project decision-making framework is a technique

which requires open participation from users, technical staff, and managers who represent
all of the stake-holders in the new system. The most successful project charters are the
result of careful planning and execution of a series of consensus-building sessions in which
a facilitator leads the group through the process of building the framework.
For many projects, some degree of additional modeling, such as context, event and
information modeling, will also be required before reasonable estimates can be made of the
project’s scope and size. These modeling topics will be covered in subsequent chapters.

The Goal Statement

I am reminded of a ride I once took to the city dump with my next-door neighbor. He
was a retired engineer who worked on the booster rocket for the Apollo program. I
remember asking him, “How did a team of thousands of individuals from all over the
country land a man on the moon in the 1960s and today it’s a struggle to deliver a decent
order entry system?”
His answer was quite simple. “We all knew the goal. Every person involved on the
Apollo project had no doubt about its mission. We had to land a man on the moon before
the end of the decade, and return him safely to the earth.” (I’m convinced that the astro-
naut’s union inserted the “return” clause in version 1.2 of the goal statement.)
The Apollo program’s goal was clear. It was short and to the point. It was unam-
biguous because it used simple language that everyone could understand. The best thing
about it was that it was measurable. You knew what constituted success, namely, get
someone to the moon and back safely before December 31, 1969. Another key factor was
that many people believed that it was achievable. Aside from the explicit goal, there was
also an implicit goal on the Apollo project which wasn’t officially stated. Can you
remember what it was?3
Every information systems project has a goal. The complicating factor is that busi-
ness systems are not simple. People have differing viewpoints on what a project is all
about. A charter is needed to bring the goal of the project into focus. The goal needs to
be clear, unambiguous, concise, and measurable. Everybody needs to agree on what it
is, and know when it has been achieved.
But how to come up with the goal? I have found it very difficult to start by writ-
ing one simple goal statement that sums up an entire project. A better way to tease out
the goal is to determine the entire list of individual objectives that must be achieved for
the project to be deemed a success. Objectives are determined by uncovering all of the
problems with the current way of doing business, and brainstorming unexploited oppor-
tunities. After the list of objectives has been ratified by the group, it can be distilled into
a summarized goal statement that represents the whole of the project’s objectives.

3 The implicit goal was to “beat the Russians to the moon.” This unstated goal probably served to
motivate the project far more than the official stated goal.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

I’ll come back to the goal statement after we’ve discussed problems, opportunities
and objectives.

Problems and Opportunities are the Basis for Objectives

When you first gather a group of system users, business managers and technical staff
together to discuss a new information system, it is inevitable that people will start out by
telling you everything that’s wrong with the old one. In fact, little or no discussion is
likely to take place about a new vision for the future until everyone has had a chance to
vent their frustration with the current way of doing business.
This is an important human dynamic to recognize, and as an analyst, you can take
advantage of it. The venting process is critical. You need to give your users the opportu-
nity to vent, in a controlled environment, early in the planning phase. If they don’t get
their issues out in the open, they are likely to grumble and cause trouble for the entire
duration of your project.
For the best results, a cross-section of users and managers should join the project
team members for a session that can last anywhere from several days to a week. A facil-
itator plays the role of leading the discussion and asking the questions, being careful not
to interject his own personal opinion. It is often worth it to pay for a professional con-
sultant to provide the third-party neutrality that is required for this role. All of the pro-
ceedings are recorded, either electronically or manually. It is of paramount importance
that when a user tells you a problem, they see you write it down.

Problems
The beginning of the analytical process begins by asking people what is wrong with their
current environment. Typically, people start out slowly, not wanting to offend or draw
attention to themselves, but quickly the gloves come off and the group erupts into a
litany of sins visited upon them by the current system. Each of these statements is
recorded on a list of problems. The point of the exercise is to discover as many problems
as possible, but not to attempt to solve them at this point.
A new information system is a solution. In order to design the proper solution, you
must understand the problem you are trying to solve. Problems may range from the
show-stopper variety (such as, “The old system produces spurious results and can no
longer be relied upon for accurate data.”), to the mundane (such as, “The line printer
reports are hard to read.”).
A problem exists any time someone is dissatisfied with the behavior or capabilities
of their existing information systems, and can express to you what they think appropri-
ate behavior or capability should be. For example, if an order entry clerk complains that
the system is too slow, then what is an acceptable response time? In the 1982 best seller,
The One Minute Manager, Drs. Kenneth Blanchard and Spencer Johnson gave a won-
derful definition of a problem in behavioral terms.
ISBN: 0-536-56083-8

Specially prepared for d03063582

“A problem exists if there is a difference between what is actually happening

and what you desire to be happening.” And they add: “If you can’t tell me
what you’d like to be happening, you don’t have a problem yet. You’re just
complaining.”4

By stating each complaint as a problem, you leave the door open to many different
solution options.

The Difference between Problems and Opportunities

In addition to problems with the current systems, organization and procedures, there may
be unexploited opportunities available to the business that are yet untapped. The differ-
ence between problems and opportunities is subtle. A problem exists when something
isn’t working and you want to fix it. With an opportunity, nothing is necessarily broken.
An opportunity arises when you can leverage new technology, products or services that
didn’t exist before or hadn’t been considered.
Opportunities are often inspired by new technology. For instance, a participant
may come up with the idea to give the sales people laptop or hand-held computers so
they can write up orders electronically while they’re on the road. We have to be careful
not to state a technological solution in our opportunity statement. There may be many
ways to exploit the opportunity, both technological and non-technological. A good
opportunity statement for our example is, “Eliminate redundant entry of data by moving
data capture closer to the source.”

Objectives
While many project plans traditionally start and stop with an exhaustive list of require-
ments, the purpose of determining the objectives is to get to the reasons behind the require-
ments. For example, a common requirement that I have seen is, “the system shall interface
with a laser printer.” After searching for the underlying objective, you may find that the
real problem is that your customers can’t read their invoices because they are printed on
multi-part pink paper with pale purple impact-printer type. The “requirement” was some-
one’s proposed solution to the problem. The true objective of the requirement might be to
“reduce errors in payment and increase customer satisfaction by clearly communicating the
charges due from the customer on each invoice.” When you’ve stated the issue in this man-
ner, it opens the door for a variety of solution options, ranging from changing the color of
paper in the impact printer to invoicing your customers electronically.
An objective is a statement which, when realized, removes a problem or exploits
an opportunity. Objectives are like “mini goals.” They should also be clear, concise and
measurable. Each objective supports one piece of the goal (Figure 2–2). If you reach all
of your objectives, you have reached the total goal.

4 Blanchard and Johnson, 1982.

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Figure 2–2. Many objectives can support the goal

Each problem and opportunity is turned into an objective statement by applying a

simple concept called IR AC IS, (pronounced ’ear-ack-iss). This is an old IBM® term.
It’s an acronym which stands for Increase Revenue, Avoid Costs, Improve Service to our
customers. We need to remember that businesses exist to make money and have happy
customers.5 The reason business information systems exist is to help the company in this
mission.
Using IR AC IS, it is fairly easy to convert a problem or opportunity into an objec-
tive which states whether the business will realize a gain in revenue, lower cost, or
improved service to customers when the objective is met. Many of your objectives may
fall into more than one category. By determining whether we intend to increase revenue,
avoid costs or improve service, this exercise sets us up for finding a way to ultimately
measure the objective. The objective statements also tend to move the chartering partic-
ipants away from overtly stating technical solutions, and forces them to consider the
business reasons for their proposals.
Let’s take a problem identified by a marketing group at a security check printing
firm that supplies checks to banks and other financial institutions. When patrons open
new accounts at the bank, they are shown a dazzling array of personal checks that can
be theirs for a small fee. Many of these checks are products created by the check print-
ing firm especially for that bank.
The check printer’s sales force was supposed to be the primary customer contact
for all aspects of the relationship. The marketing department’s product development

5 Cynics may argue that some government agencies exist to lose money and irritate customers, but
their underlying business mission should be the same.
ISBN: 0-536-56083-8

Specially prepared for d03063582

group was having a problem. The problem was that the sales people in the field had
incomplete and inconsistent methods for collecting vital information about new cus-
tomers and the new products that these banks required. This forced the product devel-
opment group to establish separate contacts with the customers to clarify their needs,
causing delays in the specification for new products.

Problem: Sales people provide incomplete information about new customers

and new product requirements to the product development group.

How can we turn this into an objective? Start by making the negative problem a
positive statement.

Sales people need to provide complete information about new customers and
new product requirements to the product development group.

Next, we need to apply IR AC IS. As an analyst, you ask, “By addressing this prob-
lem, are we likely to increase revenue, avoid costs or improve service to our customers?”
Let’s brainstorm some possibilities:

Increase Revenue: There is no apparent correlation between getting com-

plete customer and product information and getting more customers or more
sales from existing customers.
Avoid Costs: Getting complete customer information will definitely lower
the cost per new product to process the information through the product
development group because they won’t have to call customers back so many
times for clarification.
Improve Service: It will also improve service to the customer. When cus-
tomers are bothered less, it lowers their actual cost of doing business with the
company.
Now we can restate the objective, using the proper IR AC IS terms.
Objective: Avoid cost of calling customer for clarification by having sales
people provide complete new product information. This will also improve
service to our customers by reducing the number of times they are contacted.

Measuring Objectives — The X-Factor

We’re not finished with our objective yet. This objective is clear and concise, but how
do we measure it? This is where many project charters fall apart. They get to this stage
and declare victory, but the real work is just beginning. We need to find what I call the
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

elusive x-factor. The x-factor puts a number to the increase in revenue, the decrease in
costs and the improvement in service for every objective which is possible to measure.
If we never state the x-factor, how will we ever know if the project was a success?
Getting back to the check printing firm, this particular company had no idea how
much time was actually being spent by the product development group contacting cus-
tomers for clarification. Therefore, they didn’t even know if they had a problem! There is
an old business adage that says, “You cannot improve that which you do not measure.” If
you only perceive that you have a problem, you really can’t proceed to make any rational
decisions about fixing it until you know its relative importance, and have some idea of the
degree to which you can address it.
The process of creating a project charter often uncovers the need to take some
baseline measurements in the organization. It is important that these measurements be
taken. When you discover an objective that is lacking any measurement as to the degree
of the problem, the following steps will allow you to record the deficiency and move on
with your group meeting.

1. Establish with the group how they could measure the objective. Hard measure-
ments can be taken in terms of dollars or time. Some objectives may require
soft measurements such as “customer satisfaction.” Objectives designed to
improve service to customers may be difficult to measure. One technique is to
try to measure the customer’s cost of doing business with you, in either time,
dollars or effort expended. Try to get as many hard measurements as you can
in your charter. It will help you establish the benefit side for any cost-benefit
analysis that may be performed on your various solution options.
2. Insert an x-factor into the objective statement, showing where a measurement
is needed. The existence of the variable makes is it clear to any reader that the
objective statement is incomplete until a value is supplied.

Objective, (with x-factors inserted): Avoid cost of calling cus-

tomer for clarification (by $ x) by having sales people provide com-
plete new product information. This will also improve service to our
customer by reducing the number of times they are contacted by (y
number of calls).

3. Assign specific people to establish baseline measurements to evaluate the

extent of the problem. In the example, they could measure the number of calls
and the duration of each call. They could also classify the calls by what infor-
mation was being requested. An average labor cost for the department will also
have to be established.
4. Schedule a time to reconvene the group, after the measurements are taken, to
review the measurements and evaluate the degree to which they want to
address the problem.
ISBN: 0-536-56083-8

Specially prepared for d03063582

You must be very careful if your charter includes an objective which promises a
reduction in labor costs. The implication is that your project intends to reduce head
count. Do not make this statement in your charter unless you intend to deliver that result.
Quite often labor savings doesn’t reduce head count, instead it shifts workers from cler-
ical activity to more advantageous tasks. This doesn’t eliminate the cost of the worker
from the company, but hopefully makes them more productive. Make sure your charter
makes it clear which result your project intends to deliver. The charter should clearly
state the criteria by which you will be judged when the project is over.
Another common trap to avoid is what I call the “motherhood and apple pie”
objectives. These are broad sweeping statements such as, “The new system will avoid
costs by eliminating all errors in the production cycle.” Everybody can agree that this is
a good thing, but it is entirely unachievable. This kind of statement leaves a project wide
open for failure. The project can be lambasted as a disaster when the first error occurs in
production after the new system’s installation.
It doesn’t take any research to write a “motherhood and apple pie” objective.
Instead, you should be asking, “What is the error rate in the current production cycle,
and what is the root cause of those errors?” “To what extent can a new or improved infor-
mation system reasonably be expected to lower the rate of these errors?” “What other
creative solutions might be employed to reduce errors in production?”
The x-factors that are put into the project charter will be used to justify the project’s
existence, and will ultimately be used to rate its success when delivered. Think of them
as your test cases and take the time to measure and negotiate reasonable expectations with
the business.

Coming Back to the Goal Statement . . .

After you have compiled an exhaustive list of objectives with your group, and deter-
mined the method for measuring each objective, it is time to return to the goal statement.
If you have a rough draft goal statement for the project, review and amend it in light of
your objectives and see if it still summarizes the project. If you deferred the goal state-
ment until after the objectives were complete, now is the time to distill the objective
statements into a short summary which can serve as the project’s ultimate goal.
A good technique for analyzing and summarizing objectives is to group them into
categories. List all of the objectives which increase revenue, followed by those which
avoid costs, and finally those which improve service to customers. Some objectives may
fall into two or even all three categories.

Prioritizing Objectives
All objectives are not created equal. The chartering team needs to determine which
objectives are more important than others. For this exercise, you will need to have your
x-factors filled in. The team will need a strong indication as to which problems are the
most severe, and which objectives will contribute the most to the company’s well being.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

This type of analysis often requires some direction from upper management as well. The
strategic direction of the business can also skew the weighting of the objective list.
Good goal statements are like good objective statements. They need to be:

clear and unambiguous, (use short, common, understandable words),

concise, (one sentence to three sentences should suffice),
and measurable, (include measurements from your most critical objectives).

Let us return to our check printing firm example for a moment. Prior to going
through the decision-making framework, they drafted an initial goal statement. On the
morning of the first day of the sessions, the users and their management were perfectly
happy with the following goal:

“The goal of the project is to deliver to the marketing department a computer

system for collecting and disseminating new product information.”

They had stated a solution instead of a goal. After following the steps outlined in
this chapter, they rewrote their goal statement as follows:

“Our goal is to reduce the time it takes for the marketing department to val-
idate and complete the specifications for a new product from five days to two
days, from the time of receipt of complete information from the sales office to
the delivery of accurate, approved specifications to the plants.”

It is clear, unambiguous, concise and measurable. In fact, when this particular

group finished with the project decision-making framework, they settled on a solution
which didn’t even involve a new computer system. It turned out that through a combi-
nation of sales training and new forms design, they were able to achieve their objective
without re-writing a single automated system!
When your objectives are sorted and weighted in terms of their relative impor-
tance, then you are ready to finalize the project goal statement and move on to the next
tier of the decision-making framework.

Evaluation Criteria

The next layer of the project decision-making framework is the evaluation criteria. The eval-
uation criteria establishes how you will measure any given solution against the objectives.
Your x-factor measurements in your objectives will already provide you with many
of your evaluation criteria. For example, if an objective is to “avoid cost of $1,400 per
month by eliminating paper transfer of documents between warehouse and plant,” then
the evaluation criteria is to measure to what degree any proposed solution option meets
the $1,400 per month reduction target.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Convert Your Objectives into Evaluation Criteria

To establish a list of evaluation criteria, start by listing the measurable or tangible objec-
tives. Establish how you will rate any solution against the measurement. Must the objec-
tive be entirely met, or can solutions be accepted that meet the objective target to some
lesser degree? For the objectives that cannot be easily measured, you also need to deter-
mine the evaluation criteria. Discuss within the group how you might attempt to rate a
solution against each intangible objective.
When you finish this step, you should have an evaluation criteria established for
each objective. Your evaluation criteria should carry a weighting that corresponds to the
objectives’ relative importance.

Extend Your List with Standard Cost-Evaluation Criteria

Any evaluation of proposed courses of action should involve some cost/benefit determi-
nation. Until now, we have focused on the benefits of improving the business. The objec-
tive list gives us a measurement of those benefits. The evaluation criteria also needs to
weigh the cost of any given solution.
Costs come in many flavors. The following list includes several cost categories that
should be part of any evaluation for an information system. You may have a more
detailed list of costs in your organization.

Optimal cost to procure (build or buy)

Optimal cost to implement
Optimal cost to maintain over time
Avoids undue technical risk
Acceptable time to deliver
Feasible with available people and expertise

Add these costs-related items to your list of evaluation criteria. Your team needs to
agree on how important these items are in relation to the others on the list. For instance,
does time to deliver outweigh all others? Will a solution be rejected if the cost to imple-
ment outweighs the benefit measured by the objectives?
Some companies demand that each project be independently cost-justified. Expe-
rience has shown that the first client/server project is several times more expensive than
if it were developed using mainframe technology. This makes it very difficult to justify
on the basis of one project alone.
So, if the learning curve and technological complexity of this environment is so
expensive up front, then why switch? I can’t answer that question for you directly. I can
offer these observations, however. The move to client/server technology is often driven
by powerful, yet mundane forces in the business workplace. The personal computer has
clearly won the war for the users’ hearts. The sheer multitude of PC packaged software
that can be exploited is mind-boggling.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Usually, client/server has to be justified on a far more strategic level, such as re-
engineering the business to move data capture and manipulation out of the glass room
and out to the frontiers of the organization where people have direct contact with cus-
tomers, vendors and the product.
Since the first project is going to get hit with an inordinate amount of learning,
modeling and technological infrastructure, it makes sense to start small and work up to
the big systems, rather than with a big-bang approach. The real benefits occur on the sec-
ond, third and fourth projects, when, by reusing the people, models, methodology and
technology, systems can be developed in a far more productive time frame.

Additional Evaluation Criteria for Information Systems

In addition to the evaluation criteria related to the benefits of the project’s objectives and
the costs associated with a solution, there are considerations which are universally applic-
able to information systems that should be on your list. This is often called the “-ility” list
because so many of the quality vectors on the list end in “-ility.”

Usability
Reliability
Maintainability
Extensibility
Flexibility
Security
Efficiency
Currency of information
Immediacy of response
Ability to communicate with other systems

The items on this list need to be carefully considered. Experiments by Gerald

Weinberg6 have shown that if a programmer is told or perceives that one of these items
is more important than others, they will vary the degree to which they meet the others.
Many of these quality vectors are in conflict with one another. For instance, a program-
mer who strives for immediacy of response may not write a program which is easy to
maintain or flexible.
Compounding this issue is the fact that the primary quality vector for the applica-
tion may vary dramatically across the system. The on-line customer service system may
require sub-second response time, but the users may tolerate much slower performance
in the month-end inventory balance application.

6 Weinberg, 1971
ISBN: 0-536-56083-8

Specially prepared for d03063582

Try to avoid sweeping statements in your charter such as “the new system must be
user-friendly.” Instead, develop a list of measurements of system quality and have the
group rate the importance of each item for each major subject area or sub-system within
your scope (Figure 2–3).

Figure 2–3. Quality vector ratings by subject area

You may have noticed, that so far, we haven’t talked about hardware. All of the
evaluation criteria to this point can be applied to non-automated systems as well as auto-
mated solutions. It is important not to bias the evaluation criteria toward purely techni-
cal solutions. For instance, if your shop has selected a standard database management
system, the underlying quality vector may be to achieve maintainability and extensibil-
ity, ability to communicate with other systems and optimal cost to procure and maintain
over time. Standardized development software also avoids undue technical risk and is
feasible with available people and expertise within the department.
When you have compiled your list of evaluation criteria, you should have the
following:

A weighted list of criteria which measure the benefit of achieving the tangible and
the intangible objectives.
A list of cost, time and risk criteria which measure the resources required to imple-
ment any given solution, and agreement over the constraints on the project. The
cost criteria also should be weighted for their relative importance.
A matrix of quality vectors for each major sub-system within your scope, which
provides technical direction for the user’s expectations of the system’s perfor-
mance and behavior.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

When finished, each item on the evaluation criteria list should be assigned a weight-
ing which reflects its criticality. Armed with this information, the group is ready to brain-
storm various options and will be able to reach consensus on a rational course of action.

Solution Options

There are many points during a project when you will be confronted with choices. The
planning stage is just one of them. Any decision involves trade-offs, and the decision-
making framework helps bring focus back to the original objectives of the project so
people can make choices rationally. Later in the project, many decisions will have to be
made involving the architecture of the hardware and the distribution of process and data
across the network. Having a solid charter, and a model of the business as described in
the next few chapters will help you understand the engineering trade-offs and make well-
informed choices. Without the foundation of the charter, these critical issues are often
solved by management fiat, or by “he who shouts the loudest or longest.”
Solution options should be brainstormed with your chartering group. Brainstorm-
ing rules dictate that any suggestion must be written down, and all evaluation is deferred
until the group has finished adding solution options to the list. A good facilitator will
guide the group through brainstorming a variety of technical solutions, running the
gamut from very high-tech to low-tech implementations. The group should also be
encouraged to see if the problem could be solved without a purely technical solution.
Sometimes changing the way the business operates and leaving the technology alone is
a good fit.
Whatever solution options end up on your list, the first option should always be
“status quo.” Always measure the cost/benefit of doing something against the baseline
of doing nothing at all. Sometimes “status quo” ends up being the best solution.
Let’s return to our example of the check printing firm’s product development
group. Their goal statement was as follows:

After they developed their objectives and evaluation criteria, they began brain-
storming solution options.

Marketing Department’s Solution Options

1. Status quo
2. Hire more people
3. Replace the paper files and filing cabinets with a PC-based on-line database
ISBN: 0-536-56083-8

Specially prepared for d03063582

4. Redesign the paper forms used by the sales people

5. Redesign the work-flow so marketing keys information directly into plant systems
6. Better training of the sales staff
7. Capture data electronically at the source (e.g.: give the sales people laptops),
and download data directly to production systems.
8. Combination of #4 (new forms) and #6 (better training)

After an exhaustive list of solution options has been created, it’s time to measure
which option or options are the best fit to the evaluation criteria. A matrix can be created
(Figure 2–4) which lists all of the evaluation criteria and their associated weightings
down the left side. Across the top, the solution options are arrayed, with “status quo” in
the first column.

Figure 2–4. Sample evaluation form

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

I like to list the objective-based evaluation criteria first, followed by the cost-based
criteria, then followed by the quality vector criteria. The group can first focus on scoring
the benefits as determined by the objective-based criteria. Any scoring system will work
as long as it is consistently applied. For example, you can use a rating from zero to five.
If a solution option completely satisfies an evaluation criteria, you put a five in the cell
where they intersect. If it fails to address the evaluation criteria at all, you write in a zero.
If it meets the criteria somewhat, the group will have to determine a suitable score which
reflects the degree to which the option fits the criteria. When you’re finished, you can
weight the scores based on the weighting of the evaluation criteria, and add them up.

Estimating Cost
For cost-based criteria, it is best to use the estimated monetary costs, time costs and
resource costs. Since this book’s primary focus is on software engineering and not project
management, I do not propose to cover cost estimating in great detail. It would take up an
entire volume to do it justice. However, within the context of business system analysis,
let me offer these observations.
To estimate the cost of any given solution, you will need to have a good idea of the
size of the problem. The best way I know to determine the size of a business problem is to
do some preliminary analysis. The larger the project, the more important it is to begin mod-
eling the “big three,” the context, event and information models, in the planning phases.
Estimating cost begins with finding things you can count. The context model will
declare the system boundary and show the interfaces required. Your context model may
expose electronic data interfaces or complex integration with existing systems as well as
on-line and reporting components. The event model will provide you with a list of all of
the major business events to which the system is chartered to respond. This list is crucial
to determining the desired functionality of the system. The information model, perhaps,
is the most important indicator of system complexity. By determining how many entities
are involved in the business problem, the size of the solution can be measured against
the cost of similar business systems.
Once you have an idea of the system’s size, as expressed by your models, there are
a variety of ways to determine the cost of construction or purchase of such a system. Just
about anything you can count can be assigned a metric to determine the total effort
required to create that object. You can count entities, number of reports, function points,
number of windows and so on.
For GUI applications that will concentrate heavily on the creation of the interface
and underlying database, I have successfully estimated project size based on number of
windows. The number of windows in the interface is particularly relevant to GUI busi-
ness applications because that’s where most of the development effort is expended. The
object-oriented structure of a GUI program makes “lines of code” estimating particularly
irrelevant.
ISBN: 0-536-56083-8

Specially prepared for d03063582

An estimated number of windows can be extrapolated from the entity count and
event list. If you accept that a good GUI application which is responsible for the creation,
inquiry, update and deletion of an entity will at minimum need a window to select from
multiple instances of the entity, and a window to update a single instance of the entity,
then a ball-park estimate for number of windows in a system is “number of entities times
two.” Other factors that can increase the number of windows are unusual events which
are beyond the pale of simple create, read, update and delete functions.
The next step is to beg, borrow or steal some metrics from a similar type of
client/server-GUI project. You can divide total effort for analysis, design, coding and
testing by the number of windows yielded in the final application to get a “per window”
metric.
If your shop has some metrics for software development, you’re way ahead of the
game. If it doesn’t, you can call around to your local user groups, consultants and pro-
fessional associations to borrow some metrics from other companies.
After you have costed out each of the solution options, you can evaluate them as to
their relative delivery cost, maintenance cost, time to delivery and relative risk. The last cri-
teria to apply are the quality vector ratings. Remember that criteria such as rapid response
time may be applied unevenly across the application, so when evaluating solution options,
you must be conscious of for which portions of the system the quality vector is intended.
When the evaluation is finished, your group should be able to agree on a course of
action. Sometimes a group will choose a less optimal solution simply because it is expe-
dient. Other times, the more expensive solution will be chosen for long-term strategic
reasons. Whatever solution is chosen, the important thing is that the business and the IT
organization have arrived at a consensus together. Everyone knows why the project
exists, and has a vision of what it should be upon completion.

THE WRITTEN CHARTER AS A CONTRACT

The majority of this chapter illustrates the process that people go through to reach con-
sensus on the goals and objectives of an undertaking. I feel strongly that understanding
the process is more important than the actual structure of the written document that the
process yields. I would be remiss in my duties if I didn’t tell you how to write it all down,
so here’s a suggested format for a project charter document. Your actual format may vary
depending on corporate standards, however, the content should include the following:

The goal. A written charter should clearly state the goal of the project on the
front page.
The objectives. Immediately following the goal statement, the project’s individual
objectives should be listed in clear, concise, measurable terms. The objectives
should also be ranked according to their relative importance so every reader is
aware of the primary versus secondary objectives.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

The recommended course of action. The next section should state the recom-
mended solution or next steps. (Some companies will insist on an entire project
plan, others may commit only to proceed with business analysis and reconvene
another chartering session to determine the optimal design solution.) Included with
the overview of the chosen solution, you also should include a review of the eval-
uation process so the reader understands how the group settled upon the stated
direction and which options were rejected.
Solution scope. The solution option should include a statement of scope. The
scope tells the reader how much of the business is included within the boundary
of the project. For this section, you will often need to venture into the next few
chapters and produce a conceptual-level context model, event list and entity-
relationship diagram. The context model and event list are very good at defining
scope. I also find it advisable to include an explicit statement of what is out of
scope. This is far safer than implying that a part of the business is out of scope
simply by omission.
Project plan. Prior to proceeding with analysis, many companies will insist on a
project plan. This includes a detailed statement of the methodology to be
employed, usually stated in terms of a work breakdown structure. Staffing, budget
and schedule can be determined only after the project size has been estimated by
doing some modeling.
Roles and responsibilities. The roles of both IT and the business need to be
spelled out in the charter. Both parties need to execute their responsibilities for the
project to be successful. To ensure that the business holds up its end of the bargain,
I am very explicit in my charters as to which people are needed and for how long.
Go ahead and name names. Also include the names of the project sponsor, business
steering committee and issue resolution team.
Critical success factors. Any preconditions to success that are out of the control
of the project manager must be stated up front. I always reiterate the names of the
business people and time commitment required in this section. If acquisition and
installation of any new technology is required, it is best to state that the success of
the software development is dependent on the successful installation and testing of
the hardware.
Signatures. Just like any other contract, the charter must be ratified by both par-
ties. IT management and the project sponsor must sign on the dotted line. The most
successful projects are those which get business commitment at the highest levels
of the organization.

By the time the charter is completed, the analytical process is already well under-
way. The next chapters will focus on the details of models needed for sound analysis of
business information systems.
ISBN: 0-536-56083-8

Specially prepared for d03063582

SUMMARY

To state it simply, the charter is the why, analysis is the what, design is the how. The char-
ter lays out the justification and objectives for the project. It spells out who the players
are and states everyone’s roles and responsibilities. It tells the analysts where to start and
tells them when they’re finished.
The analyst can turn to the project charter and ask, “what are the most important
objectives?” That’s where you focus your efforts. If your project runs out of time and
money, you want to make sure that the most important objectives have been met.
The project charter is the beginning of the analytical process. The project decision-
making framework is technique for determining the goals and objectives of a project.
Picture the goal as a flag planted on the top of the pyramid. There are many ways to
reach the goal. All subsequent activity on the project should be focused to achieve it.
Individual objectives are derived from problem and opportunity statements. An
effective way to discover problems is to collect the interested parties together in a room
and let them vent about their current situation. The problems and new opportunities can
then be converted into objective statements which should be clear, concise and measur-
able. Since all objectives are not created equal, each objective needs to be weighted in
terms of its relative importance.
When attempting to measure objectives, determine if achieving the objective is
likely to increase revenue, avoid costs or improve service to your customers. Perhaps
the most important task in defining objectives is the search for the elusive x-factor.
The x-factor is the variable that you place in your objective statement to indicate how
much of an increase in revenue, reduction of cost or improvement of service is desired.
It takes some additional research, but each x-factor should be replaced with meaning-
ful, achievable numbers. These become the measurements by which your project will
ultimately be judged.
After the objectives are established, they can be quickly converted into a set of
evaluation criteria to use for considering solution options. The evaluation criteria should
also include cost factors such as time, cost to procure, cost to maintain and a recognition
of potential risks. Additional evaluation criteria which measure system quality should be
stated for those parts of the system to which they are relevant. Once this framework is
established, the project has a rational basis on which to evaluate choices. Solution
options are brainstormed and evaluated against the criteria. Once the group has reached
a consensus on a course of action, a project plan can be drawn up.
The result of the chartering process should be written down. This document is not
meant to be cast in stone for all time. The charter is continually negotiable. If the users
demand additional functionality which was not included in the original project charter,
then IT now has a basis for negotiation for either more time or resources. (You will find
yourself in an even better position if you had specifically excluded the functionality in
your statement of scope.)
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
EXERCISES 53

The importance of a good project charter should not be underestimated. If you

readily accept that the quality of a good piece of code can be attributed largely to the
quality of its design, then you should be willing to accept that the quality of the design
can be traced to a great extent to the quality of the preceding analysis. It is by no means
a stretch of the imagination then to state that the quality of any analysis effort is due to
the clarity and completeness of its charter.
The charter tells the analyst why they are analyzing the business in the first place.
It states which areas of the project are most important and limits the scope to those areas
of the business which need to be modeled in order to meet the project’s objectives.

EXERCISES
1. Old Mother Hubbard’s Cupboard is an old-fashioned family grocery store that
has been in business for fifty years in the same street corner building. Mother
Hubbard recently retired, leaving the business to her son, Hubble Hubbard.
Hubble is considering replacing the old key-punch cash register with a laser-
scanning bar-code reader. Using concepts from the project decision-making
framework, what should Hubble Hubbard consider before proceeding with the
project?
2. Most information systems are designed to Avoid Costs and/or Improve Ser-
vice. Systems which are intended to Increase Revenue are more rare. What are
the two main ways in which a company can increase revenue?
3. Imagine that you are brought on to a project with at least 24 objectives on the list.
You are asked to write a concise goal statement. How might you go about it?
4. Name three benefits of doing a project charter.

ANSWERS
1. Hubble should ask himself what problem he is attempting to solve with scan-
ners. Bar-code scanners are a solution option. Hubble needs to work back up the
decision-making framework and state the original problem. For instance, scan-
ners can be used to speed the check-out process. Hubble could examine whether
speed of check-out is a problem at his store. It may be that his customer volume
is low enough that nobody ever has to wait in line very long. Perhaps Aunt Edna,
who runs the cash register, can ring up items by hand just as accurately and
rapidly as a scanner. He may also find that Edna also doubles as the town gos-
sip, and most of the neighborhood relies on her for keeping them informed of
any newsworthy events — a service that could be seriously impaired by faster
check-out. Scanners can also be employed to help track inventory. If Hubble has
ISBN: 0-536-56083-8

Specially prepared for d03063582

an inventory-tracking problem, then he should first state the true nature of that
problem and determine to what level he wants to improve his inventory manage-
ment. Then he should re-examine whether scanners are the most cost-effective
solution. Perhaps he should hire cousin Nelson to count the stock after school
instead.
2. Revenue is increased by either increasing volume, or increasing price. An
information system that affords the business the capability of doing either
might contribute to an increase in revenue. It is far more common for business
information systems to allow the business to reduce costs, and therefore
increase profit margin. Improvement in service to customers is far harder to
measure, but can often be thought of as reducing the customer’s cost of doing
business with your company.
3. The goal statement is a high-level reflection of the most important project objec-
tives. Its purpose is to remind everyone about the project’s intended outcome.
The long list of objective statements needs to be prioritized by the business mem-
bers to determine which objectives are more important than others. The objec-
tives should include a measurement (the x-factor) which quantifies the desired
increase in revenue, reduction in cost, or improvement in service. With the ben-
efits of meeting the objectives quantified, the business can then prioritize the list
based on potential payback and/or immediacy of need. Then the goal statement
can be written as a summary of the most important objectives of the project.
4. (1) The project charter delineates the roles and responsibilities of both parties,
the business and the information technology staff, to the project. It makes it clear
that, to obtain the desired benefits of meeting the project’s objectives, it will take
effort and cooperation on both sides. (2) The charter also prioritizes objectives
so that the analysts and designers of the system know which are the most impor-
tant. That way, they can start analyzing and designing the most critical parts of
the system before the money or the allotted time runs out. (3) The charter also
provides a means against which subsequent scope changes or requests for addi-
tional functionality can be measured and managed. Projects rarely have their
requirements “frozen” for the duration of development. When changes occur,
the project manager can assess the new or altered objectives against his original
or updated cost assumptions and inform the business members of the impact of
their new requests. ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
CHAPTER
3

THE CONTEXT MODEL

INTRODUCTION

This chapter introduces the first of the “big three” analysis models, the context model.
While I devote the next three chapters individually to context modeling, event modeling
and information modeling, on a real project they are created together, iteratively and
often in phases. The veracity of each model depends on the integrity of the other two.
The context model defines the scope of your new system. As a diagram (Figure 3–1), it
looks deceptively simple. It contains one circle which depicts the entire proposed system
as one big process. The boxes around the edges show the people, organizations, cus-
tomers and other systems which will have to communicate with your new system. The
input and output arrows show the flow of data as it stimulates your system into action,
and as it leaves your system in the form of a response to the world at large. You can draw
a context diagram simply by tracing around your coffee cup. The hard part starts when
ISBN: 0-536-56083-8

Specially prepared for d03063582

you begin to name and define the things on your diagram and find that pinning down the
exact scope of your project can be a difficult task. The context diagram looks so simple
that many projects skip this important step to rush on to the “fun stuff,” only to find
themselves lost in the analysis wilderness with ill-defined project boundaries. “Scope
creep” can be a monumental problem on many real-world projects. The act of creating a
good context model lends clarity and focus to the project’s boundaries and responsibili-
ties which can go a long way toward helping you control and measure the impact of
scope changes as the project proceeds. In this chapter, I will cover data flow diagram-
ming notation, the concepts of expanded and reduced scope, and show you how the con-
text model fits in with the other models.

Figure 3–1. A context diagram example

THE PURPOSE OF THE CONTEXT MODEL

General Dwight D. Eisenhower once said, “It’s not the plan that matters, it’s the plan-
ning.” He was, of course, referring to the Allies’ D-Day invasion of Europe in World War
II. What appeared deceptively simple on paper had taken years and years of planning and
preparation.
The context diagram also looks deceptively simple on paper. It has only one bub-
ble in the center which represents “the system.” Classic data flow diagram notation is
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

used to show all of the stimulus flows into the system and their response flows back to
the outside world. Agents which are external to the system are shown as boxes. They rep-
resent the originators of the stimulus flow and/or the destination of the response flows.
To borrow a concept from General Eisenhower, “It’s not the resulting context dia-
gram that matters, as much as the act of doing it.” Now, before the rabid defenders of
process modeling start lighting torches and coming for me in the night, shouting “blas-
phemy,” allow me to explain.
It is of paramount importance that the project members understand, define and com-
municate the scope of the area of study as early as possible. The act of creating a context
model will help you toward that end. Later, we’ll see that scope is a relative concept. It is
quite likely that the project will have several context diagrams before it is delivered.
The context diagram is less useful downstream in the project when it comes to cre-
ating relational database or graphical user interfaces. The information model and event
model have far more value in terms of consumption, but beware of skipping the context
step! Those other models must work within a specific scope to be effective. The act of
creating a context model provides such a boundary.
I call the context, event and information models the “big three.” The context rep-
resents the whole of the process model. When embarking on a new project, the context
may consist of a business area which is a new candidate for automation, or one or more
legacy systems that are being expanded, integrated, re-hosted, or completely rebuilt. The
event model defines the system’s behavior by detailing the appropriate stimulus, activ-
ity and response for each business event. The information model contains the static map
of data required to carry out the policy for each event. Together, they define the shape of
the business through three interdependent views; process, behavior and data.

DATA FLOW DIAGRAMMING NOTATION

The context model uses classic data flow diagramming notation (Figure 3–2). Data flow
diagrams (DFDs) were first introduced in 1979 by Tom DeMarco in his book Structured
Analysis and System Specification.1 Data flow diagrams are models which depict the path
that data takes through an organization, unbiased by any specific implementation.

Figure 3–2. Data flow diagramming notation

1 DeMarco, 1979
ISBN: 0-536-56083-8

Specially prepared for d03063582

The primary strength of the DFD notation is that is treats a process as a black box.
The term black box comes from the world of electrical engineering. A black box repre-
sents any system with known inputs and outputs, but with the internal mechanism hidden
from the user. (This is not the infamous black box from airliner disasters; however, after
surveying the wreckage of numerous software projects, I’ve come to wish I had one.)
A television set is a wonderful example of a black box. The user of the television
need not know how it does its magic. In fact, most of us are completely ignorant of the
inner workings of our electronic friend. We do know how to use it. As television view-
ers, we are familiar with the inputs and outputs. What’s even more important, the behav-
ior of the television is well understood. I know that if I click “4” on the remote control,
the program will switch to whatever is currently being broadcast on channel 4. (I also
know that if I do this repeatedly, my wife will wrestle me to the ground and take the
clicker away from me.)
To the users of business software, the computer application is also a black box. Our
users don’t care how we get their data onto their screen, or whether their invoices are
being created on the client, server or any tier in between. For them, the inner workings
of the system remains an enigma. It is useful to begin by taking the user’s perspective
because it is ultimately a black box that you will deliver.
The notation for the context diagram is very simple. I’ll cover the formal defini-
tions as briefly as possible, and then get on to explaining why this seemingly innocuous
diagram is so useful for client/server development projects.
There are four primary notations for the context diagram; the circle or ellipse used
to represent process, the data flow arrow, a rectangle to depict external agents, and a set
of parallel lines to show stored data.

Processes

Conventional data flow diagramming rules insist that a process be named with a strong
action verb, followed by the object to which the action applies. Lower level processes,
those which carry out one functionally cohesive activity, are fairly easy to name.

Create customer invoice

Accrue unpaid wages
Ship finished product
Determine vehicle speed

For most business systems, the process bubble on a context diagram is such a pot-
pourri of various activities that coming up with a good name can be arduous. Before you
give up and slap the project acronym on your bubble, try to come up with a good
verb–object name that describes the entire system. You will find it to be a challenging
but clarifying experience that will help you understand what your system is all about.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Try brainstorming several names for your context bubble, being careful to nomi-
nate fine, upstanding verbs and relevant object names. Then define the process in a sim-
ple, short paragraph of clear text. Include in your definition a brief overview of all of the
processes contained within your context scope. You may also want to specifically
exclude neighboring process which are not within your area of study. After you are sat-
isfied with the definition of the process, re-examine the names you have nominated and
see if one fits, or if a better one becomes apparent.
There are a few rules and assumptions regarding processes. The law of transfor-
mation states that a process actually transforms the data in some way.2 The output must
be different than the input. Figure 3–3 shows a data flow diagram fragment which vio-
lates the law of transformation. The customer order appears to be both input and output
of the validation process.

Figure 3–3. Inputs and outputs appear to be identical

The apparent violation is really due to sloppy naming. The process, Validate customer
order has a customer order as input, reads some static approval limits from a data store, and
sends out either an invalid customer order or a valid customer order. When we correct the
data flow names, we can see that the data has truly been transformed (Figure 3–4).
The law of conservation insists that a process bubble’s output must be derivable
from its input, and furthermore, it should only be given enough information to do its job.3
Process bubbles are not in the business of forwarding superfluous data on to some other
process which will actually use it. In other words, “starve your bubbles.” This technique
allows you to remove all of the “nonsense” paths that data may follow as it meanders
through the current system.

2 Page-Jones, 1987
3 Page-Jones, 1987
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 3–4. Corrected data flow names

The purpose of imposing these rules is so the diagram can be used to analyze how
data is amended, validated, converted, calculated and consumed within an organization,
without regard to any physical constraints of location, speed or storage capacity.

External Agents

Each party in the environment around the system, that interacts with the system, is
shown as a rectangle on the context diagram. I hesitate to give a name for this symbol,
because, for some unknown reason it is subject to extreme prejudice of fashion. In the
late 1970s, anything sending information into the system was known as a source of
data. Any party receiving information from the system was known as a sink. Appar-
ently, the term sink didn’t sit well with the industry, because in the 1980s it was quickly
changed to terminator. You might imagine that this conjured up images of bionic pro-
grammers annihilating their way through cyberspace, so both terms were quickly aban-
doned in favor of external entities. This lasted only a few short years until the 1990s
where hem lines were shorter, men wore flowered ties and these boxes became exter-
nal agents. It was about this time that I gave up trying to be trendy. I’ve stuck with the
name, external agents, but if you really want to be hip, you can call them actors,
although by the time you read this, they’ll probably be referred to as business-oriented
inter-activity objects.
External agents are outside of the context’s area of study. For this reason, we never
show flows between any two external agents. Only data flowing into or out of the sys-
tem is displayed on the context diagram. External agents are named with a noun. They
can represent specific departments or user groups within your business, customers, ven-
dors, shippers, or even other information systems. Each external agent on your model
requires a name and a definition.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Do’s and Don’ts of Naming External Agents

I am often asked “are people inside the system or outside the system?” It’s a perfectly
legitimate question. Even though people go home at night, the activities they carry out
at work may exist inside our area of study as processes. Some of their roles may be out-
side our area of study, and show up as external agents. For instance, in a medical system,
a doctor may perform an appendectomy, and also update the patient’s records. It is
unlikely that you’ll be asked to automate the process Perform appendectomy, but Update
patient medical history is a good candidate.
It is inadvisable to put the actual name of a person as an external agent. At Sam-
son Demolition, Inc. (Figure 3–5), everybody in the company may know that Delilah
enters customer payments into the receivables portion of the system, but Delilah is not a
proper name of an external agent. You could get a very strange diagram indeed, if you
discover that Delilah also processes employee medical claims and enters benefit data
into the human resources module.

Figure 3–5. Don’t use a person’s name for the external agent

Figure 3–6. Instead, use the person’s role or function name for external agents

Whenever dealing with people or departments, try to determine the role they are
playing in any given event (Figure 3–6). As we will see, later in the chapter, it may even
ISBN: 0-536-56083-8

Specially prepared for d03063582

be preferable to expand the scope of the context model all the way out to ultimate ini-
tiators of the information (Figure 3–7).

Figure 3–7. Initiators of the data as external agents

I’ll have a lot more to say about external agents in the section on expanded versus
reduced scope. Choosing an external agent can be very complicated and can have impor-
tant ramifications in the client/server world.

Data Flows

I like to picture data flows as being made up of individual data attributes, grouped
together in packets of information on a conveyor belt. Each time a packet is delivered
into the system, the system is required to react in a predictable manner. That reaction
may include issuing a response which is likewise a packet of information composed of
individual data attributes.
On the context diagram, data flows fall neatly into two categories, stimulus and
response. The stimulus flows are the “innies,” and the response flows are the “outies.”
There is no convention that insists that flows travel left to right on a data flow diagram;
however, in the western world, people tend to perceive them in this manner. Because of
the vast number of flows that are usually represented on a context diagram, it is unlikely
that all data will travel neatly in an easterly direction.
The definition of a data flow is critical. It is ironic that the strongest aspect of data
flow diagramming is exactly where the technique often falls apart in practice. You must
always remember that data flows are made up of data. I’m not trying to be glib about
this. If the data flows are made up of data, then in which model is data defined? (If you
answered “the data model,” you win. It’s a trick question, since our industry has clev-
erly changed the name of the data model to the information model.)
Ultimately, you can derive an information model (covered in detail in Chapter 5),
by attributing all of the data elements on the input and output flows of your context
model to entities on your information model. Furthermore, we’ll see in Chapter 4 that
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

the stimulus and response data flows on the context model exist solely to carry out spe-
cific business events. Therefore, it is highly unlikely that you’ll be able to sit down and
draw the perfect context model without getting a good start on the event model and infor-
mation model at the same time.
The reason that data flow naming and definition becomes so complicated is
because data attributes can be grouped together in a fairly arbitrary manner by the mod-
eler for graphical convenience. To illustrate this point, I’ve drawn the same logical idea
several different ways.
In Figure 3–8, a single flow, named New customer order, comes into the system
from the customer. In Figure 3–9, we have essentially the same information entering the
system, but it is shown as two flows, Customer dossier, and New order.

Figure 3–8. New customer order shown as one data flow

Figure 3–9. New customer order shown as two data flows

If we peel the top off of our context bubble to see where these flows are going,
we find that the customer dossier portion of the data has been routed to the process
Update customer dossier, and the order information has been routed to create new
order. To comply with the law of conservation, Figure 3–10 uses a data flow splitter or
junction to separate the flow into two flows so only requisite information is routed to
each process. Figure 3–11 already has the flows separated, so they can flow directly
into their respective processes.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 3–10. A splitter can be used to break apart data flows

Figure 3–11. No splitter is needed here

Either choice is valid. It may seem that keeping the flows separate is clearer, but
don’t be fooled by the simplicity of this example. On real systems, the data flows
become so complex that many of them will have to be bundled together on high-level
diagrams to achieve any sense of readability.
Looking at the data definition of our two versions in this example, we see that the
data elements contained on these flows are absolutely identical. Figure 3–12 uses a
fragment of the information model to define the data and their relationships depicted on
New customer order. Figure 3–13 shows that the same fragment of the information
model has been split into two smaller pieces to define the flows Customer dossier and
New order.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Figure 3–12. Entity relationship diagram of New customer order

Figure 3–13. Entity relationship diagrams of Customer dossier and New order

No matter how we bundle data flows graphically, it is the data definition which is
the most important. You may already have surmised that bundled data flows can defined
simply by giving the name of the component data flows which make up the bundle. At
ISBN: 0-536-56083-8

Specially prepared for d03063582

some point, however, you must define each data flow in terms of the data elements it is
carrying. The best way to do this is by using the information model.

Material Flow

As an information analyst, you will spend most of your time modeling data. There may
be some occasion, especially when dealing with manufacturing systems, that you will be
confronted with understanding the flow of material. Material flows show the actual
movement of physical material through a process, while data flows show the movement
of data through a process.
When dealing with information systems that track data about material, it is often use-
ful to do a material flow diagram to help you develop the context diagram for the informa-
tion system. Figure 3–14 shows a material flow diagram for an automated manufacturing
process which fills jars with baby food, caps the jars and applies the appropriate labels.

Figure 3–14. A material flow diagram

For manufacturing systems, several machines may be employed to handle the mate-
rial. Any given machine may be capable of providing data to the information system
which tracks and controls the automated process. By creating a material flow diagram
(Figure 3–15), you can verify your knowledge of the process and establish a basis for
communication with your users (who may know nothing about computers, but they’ve
been making baby food for twenty-five years).
By converting the material process bubbles into external agents, we now can estab-
lish an automation boundary for an information system, and understand its relationship
to the material which it tracks and controls (Figure 3–16).

Data Stores

Data stores are places in the system where data is remembered when it is not being used.
They are shown as parallel lines. In the real world, these can represent databases, filing
cabinets, computer memory, or even human memory. Since the dawn of time, it has been
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

decreed, “thou shalt not place data stores on a context diagram.” The conventional wis-
dom is that data stores depict data at rest inside the context boundary.

Figure 3–15. The data flow may track or control the material flow

Figure 3–16. The material processors become external agents for the information system

There is one instance where I don’t mind putting data stores on a context diagram.
That is the case of passive data stores. If the data flowing into the system is being con-
sumed from a data store over which your system has no control (your system has read
access only), then I think it’s just fine to show it as a data store. Likewise, you could
show it as an external agent. If your system ever updates that data store, then it becomes
an active data store and you are compelled to move that portion of the data store inside
your context boundary (Figure 3–17).
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 3–17. Two acceptable notations for passive data stores

NAMING AND DEFINITIONS

You’ve been given a bubble, a handful of arrows, some boxes and the occasional set
of parallel lines. Your task is to describe, on one page, an overwhelmingly complex
business system. This is why it is so important that you choose descriptive, mean-
ingful names, otherwise, the diagram can’t tell you much. Even if your naming is
superb, every person who reads it will form a slightly different opinion about what
you are trying to convey. You will need clear textual definitions for every object on
the diagram.
Beware of falling into the lazy-name trap. The worst name you can put on a
process bubble (aside from no name at all), is Process data. We already know it
processes data. That’s what a bubble does. Similarly, it is inadvisable to put the words
Data or Information on a data flow. You will have squandered valuable real estate and
told the reader nothing.
Graphical diagrams alone do not constitute an analysis specification. Nothing
replaces clear, concise text. The diagrams provide a structure and organization for the
text, but in no way do they negate the need for explanation and definition. The best ana-
lysts I have ever had the pleasure to work with all had one thing in common, they
excelled at writing.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

TECHNIQUES FOR CREATING THE CONTEXT MODEL

Context diagramming is a lot harder than it looks. It is unlikely that you are going to
absolutely nail down the scope of your system by drawing one bubble on a blank page,
surround it with boxes and start connecting them with arrows (Figure 3–18). Rather than
draw one bubble, I like to draw a “flattened” data flow diagram of the business subject
area (Figure 3–19). It’s like taking the lid off of the context bubble and exposing the
major processes inside. Additionally, I also include neighboring processes that may or
may not be within my scope. I find it very useful to make an events list based on my
charter (see Chapter 4 for a detailed discussion of event modeling), and let my events list
guide me by tracing each major group of events through the business.

Figure 3–18. Sample context diagram for order entry

EXPANDED VERSUS REDUCED SCOPE

Let’s say our charter is to create a new order entry system for Chic Chat Industries (CCI),
makers of feline designer rainwear. CCI has typical geographic structure. There are ten
regional sales offices around the country and two manufacturing facilities. Corporate
headquarters are located on the top three floors of CCI Plaza in downtown Puyallup.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 3–19. A flattened DFD for the same subject area

The current order entry system is a COBOL application with a flat file database.4
There are five terminals located in the corporate office where order entry clerks spend
their day keying in orders from paper forms which are faxed, phoned or express-mailed
in from the sales offices. On average, it takes about fifteen minutes to enter an order into
the system. The key-entry portion can be done in less than five minutes, but the order

4 COBOL is a third-generation programming language (3GL) which was popular for mainframe busi-
ness applications throughout the 1960s, 1970s and 1980s. The acronym stands for COmmon Business-
ISBN: 0-536-56083-8

Oriented Language.

Specially prepared for d03063582 on 25 Oct, 2010

entry clerks have to spend additional time on the phone clarifying the information with
the regional sales office that sent in the order. Each of the five clerks enter about twenty-
eight orders in a day. With some quick math, we can see that CCI’s total volume is about
140 orders per day (Figure 3–20).

Figure 3–20. A context data flow annotated with volume statistics

Over the last fifteen years, this application has been incrementally enhanced,
patched and extended to the point where any new change request stabs fear into the
hearts of the maintenance programmers. Leopold Morris, vice president of sales, has
been enamored with the promise of client/server ever since he read about it in a news
magazine on an airplane trip. He wants to deep-six the “dumb terminals” in favor of PCs
with a graphical user interface.
We could set our brains to the “off” position and proceed to replace the current
technology with fancier technology. Dutifully, we would draw a context diagram show-
ing the order entry clerk as the external agent.
Switching our brains to the “on” position, there are a number of interesting questions
that arise: “Wouldn’t a set of GUI windows actually slow down the order entry clerk?”
“Do we have an opportunity to re-engineer the business process, using client/server tech-
nology?” Let’s see if we can use the context model to help us explore our options.
Figure 3–21 is an example of a reduced scope context diagram. The external agents
are the parties which directly transport the information into the system. I like to think of
the term reduced scope as reduced options. You have significantly reduced your options
for exploring new ways of doing business.
Figure 3–22 is an example of an expanded scope context diagram. The external
agents are now the ultimate initiators and consumers of our system’s data. The scope
of the context bubble has been expanded out to engulf all processes between the data
initiators and data consumers. I prefer to create an expanded scope model early in the
project to help stimulate new ideas and keep my implementation options open.
Client/server technology presents us with a tremendous opportunity to move the tradi-
tional automation boundary in our organizations. This cost to re-engineer the business
should not be underestimated. It is one of the major hidden costs of introducing
client/server.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 3–21. A reduced scope context diagram

Figure 3–22. An expanded scope context diagram

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

The expanded scope diagram allows us to temporarily ignore who does what, and
where it occurs. Now we can delve inside the context and see what data-transforming
processes take place for the event Customer places order.
What we find is that traditionally there has been a great deal of activity going on at
the regional sales offices which fell outside of the old system’s domain. CCI’s customers
are mostly local pet shops and specialty stores. They are visited once a month by a sales
rep who attempts to take the order at that time, but usually ends up leaving a catalogue
for the store owner. Customers then phone their orders into the regional sales office.
At the sales office, the order is recorded on a preliminary order form. It is standard
policy to attempt to sell additional accessories that coordinate with whatever the cus-
tomer is purchasing. If the customer takes the bait, additional items are added to the
order. The order is checked for completeness, the customer’s credit standing is checked,
and the order is confirmed. In the current system the confirmed order form is sent to cor-
porate headquarters where it is keyed into the system. An order acknowledgment is
printed on a line printer and faxed back to the customer.
At this point, you may have already identified some areas for improvement in this
business. Many technological limitations from the past have conspired to influence the
shape of business organizations today. When the original mainframe order entry system
was installed fifteen years ago, it is likely that there would have been tremendous resis-
tance if we had tried to put order entry terminals in the sales offices. Some of the rea-
sons would be due to the available technology at the time. Telecommunications software
was immature. Disk space was expensive and traditional character-based screens had
very limited real estate. This necessitated the use of cryptic codes and data abbreviations,
making the interfaces difficult to learn and use.
Today, our telecommunication capabilities have greatly advanced. Disk space is
relatively cheap. Powerful personal computers are widely available, equipped with
graphical user interfaces that allow a vast amount of descriptive and pictorial informa-
tion to be displayed. Our user community is changing too. Nowadays, the PC is a com-
mon appliance in most offices, schools and many homes. Virtually any new-hire should
already know how to use one.
By moving the order entry process to the regional sales offices, many processes
which are currently manual could be easily automated. With a well-designed intuitive
interface, the sales people could capture preliminary orders on-line instead of on paper.
The volume of orders handled by each office is only one tenth of the volume in the cor-
porate order entry department. The computer could be used to help suggest accessory
items that coordinate with the customer’s order. Simple editing could validate the order
for completeness, as well as do an electronic credit check. By the time the order is con-
firmed, it’s already in the system. We may even explore the possibility of moving the
order entry function all the way to the customers.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Our expanded scope diagram also helps us explore possible improvements for
response flows. In our reduced scope diagram, the order acknowledgment was sent to the
printer. In the real world, each order entry clerk stands up, walks over to the printer, tears
off the acknowledgment (being careful not to tear it in half), places it face down on the
fax machine, dials the customer’s fax number and sends it.
Our expanded scope diagram shows the order acknowledgment flow going
directly to the customer. We are now free to explore new technological solutions to this
problem. For this situation, there are software packages readily available on the market
which can FAX a document directly from the PC, without going to a printer. The new
order entry system could look up the customer’s phone number and send the document
directly to them.

ONE PROJECT — MANY CONTEXTS

Using the preceding techniques, it is likely that your project will explore many different
contexts before settling on the final scope. As your analysis proceeds, your scope may
also change. Major scope changes, such as moving data capture out to the field offices
also requires rigorous cost/benefit analysis. This type of decision is really part of the
chartering phase of the project.
You may start with a reduced scope of the current system, then create an
expanded scope diagram showing the ultimate generators and consumers of the data.
Later on in the project, as you allocate parts of your model to technology, you may
want to create a new reduced scope diagram to depict the context as it pertains to a
particular implementation.
There are also some human factors to consider when doing this type of analy-
sis. How do you suppose the order entry clerks are going to react to a context model
which clearly eliminates their department? I have seen several projects get them-
selves into political hot water because no one had prepared the users for the magni-
tude of change that ensues when a radically new system is introduced. This lack of
consideration for the human factors often results in users who begin subversively or
overtly obstructing the project by either refusing to participate, or by complaining bit-
terly about the quality of work being done. Sometimes, animosity quickly deterio-
rates into open hostility and can actually kill the project. The only way to turn this
situation around is to tackle the problem head-on by showing the affected parties
what their job will be like when the new system arrives. (Even if they’ll be standing
in the unemployment line when the new system arrives.) The information technology
department is not going to be able to do its job without cooperation of upper man-
agement to share the vision of the future with the business, manage user expectations
and address their concerns.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

HOW THE CONTEXT MODEL RELATES TO OTHER MODELS

We have already seen how closely linked the context modeling process and the project
chartering process can be. For any project contemplating a change to the boundary of the
system it is replacing, the context model becomes a crucial element for exploring options
and establishing a charter (Chapter 2).
We will see in the next chapter that the context model is directly related to the
event model (Figure 3–23), which forms the basis of much of the interface design tasks
to follow. Anytime the context boundary is moved, it will alter the landscape of the event
model as well (Chapter 4).

Figure 3–23. Events stimulate the system to respond in a predictable manner

When the project’s context expands to include geographically distributed business

locations, such as the example given in this chapter, then the technical architecture of the
target system becomes far more complicated (Chapter 8).
Finally, it is the definition of the data which crosses the system boundary that
becomes the system’s information model (Figure 3–24). Ultimately, you will have to
attribute each data element to its proper entity type, and understand the complex rela-
tionships between data (Chapter 5).

SUMMARY

The context model consists of one bubble in the center which represents the area of
study. External agents which fall outside of the control of the system are shown as rec-
tangles. These external agents either send stimulus flows into the system or receive
response flows from the system.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 3–24. Data flow elements are defined in the information model

Every object on the context diagram is backed up with clear textual definition.
Data flows are further defined by their entities and attributes, which we will cover in
detail in Chapter 5 on information modeling.
The process of creating the context model is an important step in exploring the
ramifications of moving the automation boundary in any organization. Through expand-
ing and reducing the scope of the context, various scenarios can be explored, and new
technology can be exploited to push the capture and presentation of information further
out than our former systems were able to accomplish. It is this process of exploration that
gives the context model its greatest value.

EXERCISES
1. Velma is a civil engineer who inspects bridges for the Blither County High-
way Department. She carries a clipboard with a pre-printed paper form (Form
INSP-B5.2) on which she fills out the bridge number, her county employee
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
ANSWERS 77

code, and the date of the inspection, checks off items from a list, and makes
notes of the bridge’s general condition. Each morning, she turns in a stack of
completed forms to her cousin Orville, who is the clerk at the county office.
Orville divides his morning between entering highway inspection forms into
the county’s mainframe system and reviewing building permits for the
county’s unincorporated areas. Blither County is embarking on a project to
replace its old mainframe highway inspection tracking system with a modern
client/server system. Given what you know of the process, should the external
agent which represents the source of bridge inspection data on the context dia-
gram be Velma, Bridge Inspector, Orville, Clerk, or Bridge? Why?
2. Orville currently manually approves building permits. The new proposed
county system will automatically approve 85% of the county’s permits within
a user-controlled set of parameters. In essence, part of Orville’s current job will
end up inside the “system.” Are people inside or outside of the bubble on con-
text model?
3. Can you think of a system for which you can draw no essential context model?
(Hint: The trick question meter is turned up to “10” on this one.)

ANSWERS
1. Velma’s role of Bridge Inspector is the most appropriate choice for an external
agent on an expanded scope context diagram. Orville is not the initiator of the
bridge inspection data, and the bridge is incapable of giving the system any
information. Furthermore, we don’t put people’s names on a context diagram.
By nominating the inspector as the external agent, instead of the clerk, the pro-
ject might consider the option of using hand-held devices in the field and elim-
inating or drastically reducing the data entry function at the office.
2. As strange as this question sounds, I hear it often from people who are draw-
ing their first context diagram. People are outside of the system. Processes and
data stores are inside the system. The key is to differentiate between the person
and the process he currently performs, or the data store he may possess inside
his head. In our example, Orville approves building permits. He manually con-
ducts the process Approve building permit by examining some input data (the
permit application), checking it for completeness, checking it against a set of
parameters or rules that he has memorized and making sure the fee is paid. The
process Approve building permit can live inside the context bubble, making it
inside our area of study and within the scope of potential automation, but
Orville, as a person, does not belong inside the bubble. He gets to go home at
night. Not all of the processes performed by Orville are in scope. Orville also
answers the phone and makes coffee. Unless you intend to include these
processes in the new system, it’s best to leave them out.
ISBN: 0-536-56083-8

Specially prepared for d03063582

3. The trick part of the question is “essential” context model. The word “essen-
tial” has been used in our industry for decades to mean implementation inde-
pendent. The context model is a top-level view of the system using data flow
diagramming as the technique for representation. Data flow diagramming con-
ventions dictate that a process bubble must transform data in some way, not
simply transport it. Therefore, applications which only move data from one
system to the next will have no essential context model, since they perform no
transforming process.

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
CHAPTER
4

THE EVENT MODEL

INTRODUCTION

Chapter 4 is devoted to the topic of event modeling. Event modeling is a way of defin-
ing the system’s requirements from a user’s point of view. We start by listing the busi-
ness events for which our users will employ the system. Every event on our event list is
given a detailed definition in the event dictionary. The event dictionary lists the data
which stimulates the system into action, and the data which comprises the system’s
response to the event. These data elements are then recorded in the information model,
the subject of Chapter 5. Between the stimulus data and the response data, we write a
mini-spec definition of what activities the system must do internally to transform the
given input into the desired output. The sum of the event dictionary’s activity entries
form the processing specification for our new system. The event dictionary documents
ISBN: 0-536-56083-8

Specially prepared for d03063582

the business policy and rules required to respond adequately to every event in your char-
ter. In this chapter, I will cover the formal definition of an event, and show you how to
uncover events as you conduct your analysis. I will provide you with a format for record-
ing the event dictionary for each event, and show you the various ways an event list and
event matrices can be organized to aid you in analysis and design. Event modeling is not
without its own industry jargon, so dutifully, I will cover different types of events (unex-
epected, expected, temporal and non-events) and event levels (the conceptual level, busi-
ness level, dialogue level and design level). Event modeling is a key concept that, when
mastered, helps you organize your analysis specification in a manner which is easily con-
sumed in the design of the graphical user interface.

THE PURPOSE OF THE EVENT MODEL

The purpose of the event model is to describe what is appropriate behavior for a system.
It accomplishes this by listing all of the events in the business to which the system is
chartered to respond. For each event on the list, an event dictionary entry is created
which details the definition, stimulus, activity, response and effect on the business. The
event dictionary tells us how the system is expected to behave when the event occurs. It
becomes a crucial repository for the business policy which must be executed each time
the event occurs.
The event model is completely consumed in the tasks which follow its creation. For
the analyst, the event model states the user’s business in terms they can easily understand.
The event list describes the system from the user’s perspective. For the client/server archi-
tect, an event model which has been annotated with statistics provides critical information
about who uses the system, what data is required at any given time, and how quickly it is
expected to respond. For the interface designer, the event model provides the business
rationale for navigation and window content. The keystrokes and mouse clicks that are
ultimately coded are a direct implementation of the business events in the model.
For the internal designer, the business policy stated in the event dictionary provides the
rationale for the business logic which will be coded into the system. The event dictionary
is the primary place where you will discover the same policy and rules cropping up in dif-
ferent events which lead you to identify and factor out reusable software components in
your internal design.

WHAT IS EVENT-DRIVEN?

If you take a look at the sticker on the shrink-wrap of just about any GUI development
tool today, you’ll see the claim “Event-Driven.” It has become as commonplace in our
vernacular as the word “NEW” on a box of laundry detergent. But what does event-
driven really mean?
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

In a graphical-user interface, event-driven means that the program responds

directly to mouse clicks and keystrokes as soon as they occur. Now, anyone who gradu-
ated from high school after 1985 might look at this and say, “duh.” For the rest of us
dinosaurs, this represents a fundamental change in the way humans communicate with
computers.
Hundreds of thousands of mainframe applications still grace the global landscape
today, hosted on a technology which has limited portals to the processor. In the traditional
“green screen” world, the user types a screen full of data with the main processor bliss-
fully unaware that anything is going on. Only when the user presses Enter or a function
key does the processor arise from its slumber, get the screen load of data and process it.
Are we led to believe that this technology was oblivious to events? Certainly not!
The striking of the Enter key or a function key qualifies as a bona fide event (as we will
soon see). The distinguishing factor between “green screens” and GUIs is that the sheer
number of events recognized by a GUI is inordinately higher than the relatively minus-
cule number of events recognized by a green screen. This makes the green screen sys-
tem’s morphology favor process-rich structures, while a graphical user interface,
although performing the very same processing, will be required to recognize a much
richer topography of events.

WHAT IS AN EVENT?

In a business enterprise, events occur all around us. Customers order products and ser-
vices, vendors deliver supplies, warehouses ship finished goods, employees go on leave,
and so on. Every time one of these things happens out there in the world, the business is
expected to respond in some way.
For those of us involved with computers, a good portion of the business activity for
any given event may be automated. Event modeling is a way of determining all of the
things that go on in the real world that should cause the system to leap into action and
do something.
The syntax for stating an event is Subject-verb-object. Somebody [subject] does
something [verb] to some thing [object]. Later in the chapter, we will see some special
types of events which stray from this convention, but the subject-verb-object syntax has
proven to be very useful for organizing lists of events.
There are some rules which govern whether any old sentence in subject-verb-
object syntax actually qualifies as an event to our system. To achieve membership in the
Grand Fraternal Order of Events, a candidate must pass each of the following tests:

1. An event occurs at a moment in time.

2. An event occurs in the environment, not inside the system.
3. The occurrence of said event is under the control of the environment, not the
system.
ISBN: 0-536-56083-8

Specially prepared for d03063582

4. The system must be able to detect that the event occurred.

5. The system is supposed to do something about it; meaning it is relevant to the
charter of the project.

Failure to comply with any one of the rules is sufficient to disqualify the candidate
event.
Notice that this definition relies on the modeler having a clear understanding of
what is in the environment versus what is in the system. The list of events for a project
will vary directly with any movement of the boundary on the project context model,
reflecting any change in scope. This means that as you explore various versions of your
project context, the list of events to which the system is chartered to respond will likely
be altered as well.

No Internal Events

This definition does not recognize what some methodologists refer to as internal events.
Like the context model, the event list assumes a black box point of view. It is compiled
from the user’s vantage point. Internal events are triggers between two processes inside
the system and therefore hidden from the user.
I contend that at this point in the analysis, modeling internal triggers is premature
and not relevant to the user. Additionally, the reason any process leaps to life inside our
system can be traceable to an external event. We will see later in this chapter that the
event dictionary entry for each event provides most of the detail needed to understand
requirements for the inner workings of the system.
To be fair to the internal event crowd, let’s see how an internal data flow could
become a bona fide external event by changing our scope. In Figure 4–1, the process Add
item to order is executed on the client, and the process Check customer credit limit is
executed on the server. Check Customer credit limit is triggered by a data flow Validated
order item coming from Add item to order.

Figure 4–1. Two processes inside of the system

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

During the analysis of the business problem, we do not allocate processes to either
client or server. This task is safely deferred until we have a better understanding of the
event, data required for inputs, processing or output, frequency, peak volumes and geo-
graphic distribution. It appears that the project in our example has progressed into the
design phase since someone has decided that Check customer credit limit should be exe-
cuted via a stored procedure rather than running on the client with the rest of the appli-
cation. If we trace the data flow upstream from this fragment, we undoubtedly will find
an event such as Customer requests additional item.
If we redraw the context diagram to narrow the scope of study to only those activ-
ities carried out by the server, then any formerly internal communications with the server
become events which are now external to our narrowed scope (Figure 4–2).

Figure 4–2. Context restricted to the server only

With our new context model restricted to the server machine, we can list the event,
Client submits validated order item. We know this because (1) it occurs in a moment in time,
(2) it is outside of the system, as defined by our context (the server), (3) it is not under the
control of the system, (4) our process can detect the event, and (5) our system is obliged to
react in some manner. When we expand our context back out to the project boundary, this
event is subsumed by the system and becomes internal again, dropping off our event list.

Some Examples of Events

Using a black box example, let’s use our knowledge about the common household tele-
phone answering machine to see what is and what is not an event. I’ll propose a candi-
date event, and you can practice using the five criteria to decide whether it belongs on
the event list. (Peeking is allowed, but try covering up the answer with a sheet of paper
the first time through this exercise.)

Candidate events:

1. Caller places call to owner

2. Machine plays pre-recorded greeting
3. Caller falls over
ISBN: 0-536-56083-8

Specially prepared for d03063582

4. Caller hangs up
5. Owner hears message
6. Owner requests messages
7. Owner is not home

Answers:

1. Caller places call to owner is an event. It occurs, (1) at a moment in time, (2)
in the environment around the system. It is, (3) under the control of the envi-
ronment, (4) detectable by the system when the call is received and (5) relevant
to the system charter, in that the answering machine is specifically designed to
respond to the call. Congratulations!
2. Machine plays pre-recorded greeting is not an event to the system. The play-
back of the greeting is generated by the system, and therefore, it fails number
(2) and number (3), described above. The pre-recorded greeting is an example
of a response flowing from the answering machine back to the environment.
Responses from the system are not events, however they are evidence that an
event has occurred. When you encounter a response flow from the system, trace
it back upstream to find the inbound stimulus which caused the system to react.
In this case, Caller places call to owner is the triggering event.
3. Caller falls over is not an event. It does occur at a moment in time in the envi-
ronment and under the control of the environment, but it fails numbers (4) and
(5) in that it is not detectable by the system, nor is it relevant.
4. Caller hangs up is an event. My very first answering machine was a big bulky
early model in which the machine’s designers failed to recognize this event. If
a caller hung up during the greeting, the machine didn’t turn itself off. When I
came home at night, I was greeted with several minutes of recorded dial tone.
5. Owner hears message. Sorry, this is not an event. This one is not detectable by
the system, so it fails number (4).
6. Owner requests messages. This one is an event. It passes all five criteria. The
wording is also very specific. It would be very easy to create a definition which
describes how the system should behave when this event occurs.
7. Owner is not home. This is not an event because it fails number (1). The
absence of the owner is a constant state, not a single occurrence. Even if we fix
the syntax to read Owner leaves house, the event now passes number (1), but
fails number (4). When an event fails the test, it may still warrant further inves-
tigation. If we dig a little deeper, we find that the analyst was actually groping
around for the event, Owner activates answering machine to answer calls,
which turns out to be a bona fide event that needs to be on the list.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

If it seems that I am being overly picky about the name of the event, I am. The most
important elements you can put on a model are the words! The words you use convey
specific meanings. If the original analyst put Owner comes home on the answering
machine’s event list instead of Owner requests messages, who would know what answer-
ing machines would be like today? Perhaps our welcome mats would contain electronic
devices that blurt out our messages when someone darkens our door. We all know that
answering machines don’t behave this way, but business systems are far more complex
and ambiguous. It is extremely important to get the event named properly so it passes all
five criteria in the test.

THE DELIVERABLES OF THE EVENT MODEL

Business systems are required to recognize a vast number of events. Organizing this
wealth of information can be a challenge. The event model consists of two primary deliv-
erables, the event list and the event dictionary. After the event list is created, a third deliv-
erable, the event matrices can be used to relate specific events to other objects in our
model of the business.

The Event List

The event list is exactly what it sounds like, a list of the events to which the system is char-
tered to respond. The event list catalogues each event by name in subject-verb-object
syntax (Figure 4–3). There is no standard graphical notation for an event, nor is one needed.
The most readable way to present an event list is by simply writing one event per line.

Customer places order

Customer cancels order
Warehouse ships customer order
Accounting invoices customer order
Customer pays invoice
Customer fails to pay invoice
Marketing requests quarterly sales report
Warehouse notifies customer of back-order
-

Figure 4–3. A sample event list

The event list isn’t just a bunch of words. Each event needs to be recognized in our
model as a discrete object which can be related to other, more traditional objects in the
model, such as entities, business locations and processes. The event list will also need to
ISBN: 0-536-56083-8

Specially prepared for d03063582

be sorted and leveled in a variety of ways in order for it to be truly useful. I’ll have more
to say about the different ways to dice and slice an event list later in this chapter in the
section on “organizing your event model.”

The Event Dictionary

An event list is of little value to the analyst or designer without the event dictionary. The
event dictionary entry for each event defines its business relevance and component parts.
Figure 4–4 shows an event as it threads its way through the system on a context diagram.
This is called an event thread or transaction. It is defined using the event dictionary.

Figure 4–4. An event thread

The event occurs at a moment in time in the environment, inside the external agent.
The system cannot cause the event occurrence; however, we will see later that the sys-
tem can “bait” the environment for events. The event occurrence is entirely under the
control of the external agent. The stimulus is the inbound data flow which triggers the
event. The activity is the processing carried out by the system to produce the appropri-
ate response. The response flow consists of data, sent from the system, back into the
environment to produce a desired effect on the business.
The event dictionary replaces a great deal of the detail that was formerly embed-
ded in the leveled process model in traditional structured analysis techniques. Figure 4–5
shows a sample event dictionary entry for the event, Warehouse ships customer order.
The event id can be a number, but I recommend against making that number mean-
ingful in any way. A randomly assigned identifier allows you to change the name of the
event without changing its identifier. The reader of the event list need not ever see the
actual event identifier. Whenever I’ve tried numbering events chronologically, the
method always falls apart as soon as I discover events which can occur simultaneously,
or when I forget an event and try to add it in later.
The event name is a clear statement of the event in words that the user can under-
stand. It is stated in subject-verb-object syntax whenever possible. We will soon see that
this enables us to sort our event lists by subject, or by object. You may want to identify
the subject and object of each event as separate properties to facilitate this type of sort-
ing later on.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Event ID:

Event name:

Description:

Stimulus:

Activity:

Response:

Effect:

Figure 4–5. A sample event dictionary entry

The event description informs the reader, in clear and simple terms, of the event’s
business policy. If the users read no further than the description, they should be able to
verify whether you’ve captured the essence of their business. The event description is
also reused downstream in the design documentation. For example, when you design a
window layout, just like any other object in your model, you have incurred an obligation
ISBN: 0-536-56083-8

Specially prepared for d03063582

to define it. The core of any window layout definition is the description of the events
which are recognized by that window. There’s no need to retype all of the business pol-
icy in the design, testing, help and training documentation. Simply steal it from the
analysis models, and add the physical design elements.
The stimulus section of the event dictionary identifies the data required to trigger
the event. All events need some sort of input data flow. This may either take the form
of a classic data flow containing discrete data elements, or a control flow, which con-
tains no data, only a message from the environment telling the system to “do it.” In the
example, we don’t have to feed all of the information about the customer’s order back
into the system. It’s already in there, presumably due to a predecessor event Customer
places order. The stimulus suggests that the order only needs to be identified, and the
relevant information from the order can be retrieved by the activities that need it.
The stimulus is data. We find this data represented in at least two other related
models. On the context diagram, the event stimulus may be represented as one or
more data flows into the system. Be careful not to assume that there is a one-to-one
correlation between data flows and event stimuli. Data flows can be arbitrarily bun-
dled for graphical convenience on the diagram, but the event stimulus must be very
specific to the event at hand. The primary model in which data is defined is the infor-
mation model. In the next chapter, we will see that all of the data on the stimulus
flows, combined with all of the data on the response flows, comprise the system’s
information requirements.
The activity occurs inside the system. This is all of the processing that the system
must do to convert the stimulus input into the appropriate response for the event. The
activity section should look very familiar. It’s a process mini-spec. There are a variety of
ways to document the activity for an event.
In the example in Figure 4–5, I chose to write a short mini-spec, using a pseudo-
code style to convey the business policy for the event. For many simple events, all you
need is a brief mini-spec and the information model, and you have enough to proceed
with prototyping and design. For more complex events, you’ll need to define the process
in more detail.
For our sample event, Warehouse ships customer order, I could have drawn an
event-neighborhood diagram to specify the activity section. Any solid process model-
ing technique will work. Data flow diagramming is extremely useful for breaking
down complex processes into understandable components. Figure 4–6 shows an event-
neighborhood diagram for Warehouse ships customer order.
For each symbol placed on the data flow diagram, the modeler incurs an obligation
to define it. The data flow diagram graphically depicts the overall process for the event
activity, and allows you to partition the activity into manageable pieces by writing a
mini-spec for each primitive process on the diagram. In practice, I find that the event-
neighborhood diagram is only needed when a detailed mini-spec for the activity section
begins to exceed several pages of text. For this example, a lexical activity section should
suffice.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Figure 4–6. An event neighborhood diagram

This approach of employing the event model to define a system’s process require-
ments differs slightly from some historical process modeling techniques, however it is
solidly rooted in early work by McMenemin and Palmer.1 The processing required by
today’s GUI and client/server systems is no less complex than the mainframe systems of
old. In fact, these systems do far more in the way of on-screen editing, validation and
general user-helpfulness than green screens ever could. When you toss in the likelihood
that a system today will automate more of the business than ever before, you’ve got a
significant amount of “processing” to understand. The difference in GUI applications is
that much of the processing is far more fragmented than before. Users can execute indi-
vidual pieces of the business policy by clicking on their window. They don’t have to wait
until they hit the Enter key.
In my own experience developing large-scale client/server business systems, I
have found that the activity section of the event dictionary adequately covers a large
proportion of the process model of the information system. There may come a place in
any system where the richness of the processing requirement rises above the point
where a textual specification alone is no longer adequate. There are a variety of well
known, tried and true process specification techniques available. I see no reason to
invent a new one. The role of data flow diagramming has diminished in recent years,
but the technique can be very useful for imposing an organization on very large sys-
tems, or when clarifying particularly complex internal procedures. The data flow dia-
gram makes no assumptions about which program or object will eventually house any
particular portion of the business policy, and for that reason alone remains a valuable
technique for capturing the essential business requirement prior to designing an imple-
mentation strategy.

1 McMenamin, S. M., and Palmer, J. F., 1984.

ISBN: 0-536-56083-8

Specially prepared for d03063582

The activity section of the event dictionary is neutral as to the target language of the
project. Later, in the design phase of an object-oriented implementation, the activity sec-
tion for each event can be converted into an object-communication diagram to depict how
activity has been mapped onto object classes (see Chapter 12). The activity section of the
event dictionary gives the object-oriented designer much of the analytical basis for creat-
ing what some techniques refer to as the event-trace model or dynamic object model.
The activity section of the event dictionary has proven to be an effective place to doc-
ument business rules. Let’s digress for a moment to a different example to illustrate how
you might use the event dictionary to record business rules. Let’s say that Dick is married
to Jane. Jane is a manager of projects. Dick works on projects as an employee at the same
company. There is a business rule that states, “no employee shall manage a project on
which his/her spouse is employed, nor shall an employee be assigned to a project on which
his/her spouse is a manager.” In our analysis, we quickly find at least three events that need
to check this policy:

Employee is assigned to project

Manager is assigned to project
Employee marries manager (and vice versa).

By finding more than one event which carries out the same policy, you have iden-
tified a place in the system where the policy could be factored out into a reusable com-
ponent. In the application design, this policy could be implemented as a separate
Marriage monitor object in an object-oriented system, or it could be coded as a stored
procedure on your database server, or even be designed as a callable library module or
function in a more traditionally-structured system. At this point in the analysis, you may
elect to record the rule as its own process mini-spec and simply reference it from each
event activity section (e.g.: “invoke employee/manager marriage rule”), or leave the pol-
icy fully spelled out in each event dictionary entry and comb through your events later,
as a separate step with the purpose of locating all potential reusable procedures.
Some simple business rules are very data-centric (e.g.: start date must be greater than
or equal to end date), and can fit nicely into your attribute definition in the information
model (covered in Chapter 5). Other business rules are more process-centric, and difficult
to model using traditional entity-relationship diagramming. Some information modelers
advocate a semantic modeling notation which allows you to identify relationships as being
mutually exclusive. This works, but tends to add a layer of complexity to the information
model that can make it hard to manage on a large scale. Some object-oriented analysis
advocates assign business rules directly to objects. I view this as a decision involving
design trade-offs and therefore premature in the discovery phase. My preference is to
record business rules in the activity section of the events which invoke them.
The response section of the event dictionary identifies the data required by the user
to achieve the desired effect on the business environment. From our user’s black box point
of view, if you put the stimulus in, you expect a particular response back. Our example in
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Figure 4–5 shows a bill of lading as the desired response to the event Warehouse ships
customer order. Reports, either printed or visually displayed, are typical response flows
for business systems. The best way to specify a report is by using a picture of the desired
layout and an information model to show how the source data is organized.
Event responses will also show up on the context model, but beware, just like stim-
ulus flows, there is not a one-to-one correlation between a response and an outbound
data flow on the context diagram. Many events have decision points which could pro-
duce one or more different responses for the same event.
Other events, such as those that simply update internally stored information in the
system may have no response flow noted on the context model. An example is a table
update event such as Marketing adds new product. This event inserts a new instance of
product, but there is no apparent response from the system other than to acknowledge
that the new product record was saved successfully. In these cases, I like to write “save
acknowledgment” in the response section of the event dictionary so the reader knows
that I haven’t omitted an important response.
The effect is the desired post-condition of the environment after having received
the response. Like the event, the effect also occurs in the environment. The effect is not
part of the automated system, but is of paramount importance to our users. The entire
purpose of the system is to produce the desired effect in the real world. As technologists,
we must never lose sight of the reason we’ve been employed in the first place. If the busi-
ness users could get directly from the event to the effect without involving any bother-
some computers or programmers, they would be absolutely delighted.

Event Matrices

Once you have an event list for your project, there are a number of matrices that can relate
events to other parts of your business model. I’ll cover event matrices in more detail in
Chapter 8 on architecture, but I want you to get an idea of where I’m going with this.
Most large businesses operate more than one location. These various locations can
be housed in the same building, or may be flung clear across the globe. The whole idea
of enterprise client/server computing is to link all of the locations of the business
together into one apparently seamless network of computing capability. An important
element in this endeavor is understanding which events occur where.
Events can play a key role in determining the data and process distribution require-
ments for a client/server system. The event/business location matrix (Figure 4–7), shows
which events are to be recognized at each business location. This tells you that these
locations will need access computing capability to capture these events.
The event/entity CRUD matrix (Figure 4–8) shows which events create, read,
update or delete (CRUD), instances of the entities in your information model. This
matrix gives you a good overview of the data operations required to properly respond to
each event. By examining the event/entity CRUD matrix, you can see which events per-
form similar or identical actions on their respective entities, and use this information to
ISBN: 0-536-56083-8

Specially prepared for d03063582

identify procedures and rules that would be good candidates for coding as reusable soft-
ware components. If you find six different events which create or update customer
addresses, the rules which ensure the accuracy of addresses should be coded only once.
(For example, you might have a restriction which states that post office boxes may not
be flagged as a ship-to address, or a rule which makes state or province a required field

Event/Business location

Customer places order

Credit dept. approves order
Prod. dept. assigns order
Plan fills customer order
Plant ships customer order
Accounting invoices customer order
Marketing mails catalogue

Figure 4–7. An event/business location matrix

Event/Entity

Customer places order

Credit dept. approves order
Prod. dept. assigns order
Plan fills cust. order
Plant ships cust. order
Acctg invoices cust. order
Marketing mails catalogue

for cities within the United States or Canada, but optional for all other countries.)
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Figure 4–8. An event/entity CRUD matrix

Since you now have an event/business location matrix and an event/entity CRUD
matrix, through Boolean matrix multiplication, or by simple inspection, you can derive
a business location/entity CRUD matrix (Figure 4–9), showing the data distribution
requirements for the business. This matrix, combined with the constraints of the avail-

Business location/Entity

able technology, gives the client/server architects much of the raw data they need to
determine whether data access for any given business location will need to be local,
remote, or some combination of the two.
Figure 4–9. A business location/entity CRUD matrix

UNCOVERING EVENTS

Discovering events is easy once you make the mental shift from viewing every problem
from an internal processing point of view to seeing the system from a stimulus/response
perspective.

User Interviews

Users will blurt out events faster than you can write them down. The only problem is that
users don’t typically converse in a neat and tidy subject-verb-object format. A clerk at the
receiving dock might say something like, “Acme Supply Company sends a red delivery
ISBN: 0-536-56083-8

Specially prepared for d03063582

truck over every Tuesday morning. Bob puts the yellow copy of their tally sheet on the top
of my ‘in’ basket. After lunch, I key the tally sheet into the GURBNIT system.”
The business analyst quickly converts this to Vendor delivers supplies and writes
down the event and a description based on the user’s vignette. He then acquires a copy
of the tally sheet to examine the data elements which comprise the event stimulus. The
next logical question is to find out what the GURBNIT system does with the tally infor-
mation, what is the user’s desired response and subsequent events. The savvy analyst will
always ask the user if anything is inconvenient or wrong with the current process, and be
on the look-out for new opportunities.
On larger projects, or one where consensus-building is key factor, the analyst may
elect to conduct formal JAR sessions (joint application requirements). During these
meetings, the first-cut event list and information model are elicited from a selected group
of users by a facilitator in a series of group sessions and break-out exercises. For more
up-close-and-personal analysis, a great way to uncover events is to sit with the users and
watch them do their job for a while. For users who may have problems with the more
formal abstractions of analysis, a simple paper prototype can be used to elicit require-
ments for both the event and information models.

The Charter
A well-crafted charter will include a set of events at the conceptual level. The event list
which typically is included in a charter document paints the system’s responsibilities in
fairly broad brush strokes. The business analyst inevitably discovers more events and
more variations on events during detailed analysis. If your charter doesn’t include an
explicit list of events, there is undoubtedly evidence of events throughout the document.
Project charters often include a section that I refer to as the “commandments.” This
is usually a list of requirements beginning with the phrase “The system shall . . . .” Con-
sider these as erstwhile events just waiting for some enlightened analyst to discover them.
For example, the charter might say, “The system shall print a receipt for each cash trans-
action.” Using what you know of events, what component of an event is the receipt?
A printed receipt is the desired response from the system. If the receipt is the response,
then what’s the event? Somebody, at sometime, is expected to submit a cash transaction to
the system, and it looks as though the system is supposed to do something about it.

Existing System Documentation

If you’re lucky enough to have documentation for the legacy systems that you’re replac-
ing, you can bet that they’re full of events. Every input screen or report represents stim-
uli and responses, evidence that a business event occurs. Any existing test scripts that
might be excavated from the system library should do a good job of mapping the stimu-
lus to the expected response.

The Context Model

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

You can also derive events from other existing models. If you already have a context dia-
gram for your system, you can determine the event or set of events which account for
every stimulus data flow into the system, and any response flow out of the system.

The Information Model

Events can even be derived by “interviewing” an information model. If your system is

chartered to remember any given data element, some event must put it there. Figure 4–10
shows a small fragment of an entity-relationship diagram (discussed in detail in the next
chapter). We can ask ourselves, “What events account for every symbol’s existence on
the diagram?” We may surmise that a new instance of Order is created when the event

Customer places order occurs. Examining the cardinality that says an order is placed by
one and only one customer, we know that the relationship “Customer placed Order” is
also created at the same time. Now that we’ve established how an order is created, we
can broaden our search for events by asking which events update orders, and start look-
ing for any events which delete orders.
Figure 4–10. ERD fragment for the event, Customer places order

The cardinality on the right side of the relationship is also a clue to possible events.
The information modeler has indicated that a customer may place zero to many orders.
The zero is particularly interesting because it implies that an instance of customer can be
created without a corresponding instance of order. It may be that this company solicits
potential customers with a high probability that they’ll place an order. Perhaps they
record the customer information, but don’t accept an order until the customer passes an
authorization procedure. It also might imply that all of a customer’s orders could be
deleted, without removing the customer. Whatever the reason, the event list should be
able to account for anything you see in the information model. If you find entities, attrib-
utes or relationships in your information that you can’t explain, then you’ve either
missed some events, or your model is in error.

EVENT TYPES

Events can be classified into several types. Understanding the pattern associated with
each event type gives the analyst an added advantage when determining the appropriate
behavior for the system, and aids in discovering subsequent events.
Certain types of events have similar characteristics and patterns. Pattern recognition
ISBN: 0-536-56083-8

is one of the key elements to reusability. By detecting a familiar pattern that we have seen

Specially prepared for d03063582

before, we can reuse our knowledge about the pattern. Reuse isn’t just applicable to code.
It also applies to business models. In fact, much of the reuse that can be leveraged in an
application development project comes from having a model of the business problem. Pat-
terns are far more recognizable in models than they are in the installed source code.

Unexpected Events

The vast majority of events in business information systems are unexpected. An unexpected
event means that, for any given instance of the event, the system never knows when it will
happen, or whether it will happen at all. The granddaddy of all unexpected events for most
businesses is Customer places order. (The Marketing Department can get rather defensive
at this statement and argue that there is a statistical likelihood that any given customer will
place an order within a certain time frame. Unless the system is actually chartered to make
this prediction, Customer places order remains an unexpected event.)
Examples of unexpected events include:

Customer places order

Customer cancels order
Acquisition department purchases new plant
Management requests ad hoc sales report
Marketing department introduces new product line
Sales department announces price increase

The key characteristics that these events have in common are that the system has
no responsibility for predicting or prompting for their occurrence. If they never hap-
pened, the system would just lie around all day doing nothing. When they do happen,
however, the system is supposed to leap to life and do something interesting.

Expected Events

For an expected event, the system has some window of expectation in which it antici-
pates that the event should happen. An event becomes expected when a predecessor
event has set up a deadline within the system before which the expected event should
occur. The event still occurs outside of the system, in the environment. The only differ-
ence is that the system can identify the particular instance or instances of the events for
which it is waiting.

Temporal Events
The most common type of expected event found in business systems is triggered by the
passage of time. Time-triggered events are called temporal events. Temporal events are
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

always expected because some predecessor event must establish the schedule inside the
system. Think of the schedule as the timer. The timer can be set on an absolute basis, so
that the event is scheduled to occur at a particular date and time, or it can be set relative
to another event.
Temporal events break the subject-verb-object event naming convention. They are
typically named “Time to [do something]” (Figure 4–11).
Figure 4–11. Examples of temporal events

Event Recognition
Temporal events are particularly interesting because the system has to do some extra

work to determine that the event occurred. Figure 4–12 shows the typical pattern of an
indirectly recognized event. A schedule has been previously established in the system.
The process plays the role of event recognizer. It must periodically read the schedule and
check it against raw input data from the environment. When the system has determined,
ISBN: 0-536-56083-8

Specially prepared for d03063582

based on the input flow and the schedule, that the event has occurred, it leaps into action
and fires off another process to manage that event’s activity.
Figure 4–12. DFD for an indirectly recognized event

In the case of temporal events, the input flow is Time. Even though your computer
system contains a clock, the system itself does not control the passage of time. It has been
a long-standing tradition in context modeling that we don’t show a data flow called Time
coming into the system. It is declared to be universally available to all information systems.
Indirectly recognized events are not limited to temporal or expected events.
Although this book is aimed primarily at the development of business information sys-
tems, the concept of events has its roots in real-time systems. Real-time systems are used
in the control and monitoring of machinery and have a much richer set of event recog-
nizers than business systems. Events in real-time systems might be set in motion by rise
or fall of pressure in a tank, or a product reaching a checkpoint in the production line.
These events may be expected or unexpected.
Most of the events in an on-line information system will be directly recognized.
This means the onus is on the user to tell the system that the event has happened. Direct
event recognition will usually manifest itself as a command button or menu item on the
application window.

The “Non-Event”
The full name for a non-event is “the non-occurrence of an expected event.” In simple
terms, a non-event “occurs” when an expected event fails to occur. On the surface, this
appears to violate the first test for an event, “the event occurs.” That’s why the sentence
reads, “An event occurs at a moment in time.” It’s the “moment in time” clause that
allows us to keep non-events on our list. For a non-event to pass the event test, its fail-
ure to occur must be detectable by the system at a moment in time. The occurrence is
determined by the expiration of the time frame, coupled with the failure for the event to
present itself at the system’s doorstep.
The system cannot create events. The effect of one event, such as Billing Depart-
ment invoices customer order may bait or entice the environment for the next expected
event in the chain, Customer pays order. Although the system sets up a window of expec-
tation (such as 30 days from invoice date), there is no guarantee that the customer is
going to pay the invoice. It is this type of pattern that produces the non-event.
Non-events must have a companion expected event. Like all expected events, they
are preceded in time by some other event which has established the expectation. Non-
events are often overlooked and omitted from the event list, but they are very important.
Quite often, you will find much more complex business policy attached to the non-occur-
rence of an expected event than to its run-of-the-mill occurrence.
The event Customer pays invoice is a ho-hum affair for most systems. The accounts
receivable clerk applies the payment and the outstanding balance is reduced. If Customer
fails to pay invoice occurs after thirty days, the system may have to accrue late charges
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

and send out a polite reminder. If Customer fails to pay invoice occurs after sixty days,
more late payment interest is accrued and a less than polite reminder is sent out. If the
customer still hasn’t paid after ninety days, the system may be required to notify the
acquisition department for some midnight asset reclamation.
Each event on the event list should be classified as unexpected or expected. For the
expected events, you should always ask, “Does the business care if it doesn’t happen?”
If the system is responsible for the policy associated with the non-event, it is likely that
you will have to do a great deal more work on your project. If the system is not respon-
sible for detecting the non-event, I make a note of it in the event dictionary of the com-
panion expected event. This lets other project members know that the question has been
raised and answered.

Review of Event Types

Events fall into two major types; unexpected or expected. Most of the events in an on-
line business information system will be unexpected. Real-time systems deal with a sig-
nificantly higher number of expected events. The classification into these two categories
is important because it systematically leads the analyst through a set of questions:

Is the event unexpected or expected?

If the event is expected,
Is it a temporal event expected relative to another event or at an absolute time?
Does the system care if it doesn’t happen (the non-event)?
What is the predecessor event which establishes the expectation?
For either unexpected or expected events,
Is the environment (direct recognition) or the system (indirect recognition)
responsible for recognizing the event?
What are the predecessor events in the chain?
What are the successor events in the chain?

Asking these questions will help you create a more complete model of the system’s
desired behavior. The distinction between unexpected and expected events will also
assist you in determining the proper chronological sequence of events when you begin
organizing your event list.

ORGANIZING YOUR EVENT MODEL

The event model will be completely consumed in all of the subsequent steps of analysis,
design and testing. The event model represents a fundamental shift in the organization of
ISBN: 0-536-56083-8

Specially prepared for d03063582

business requirements. Traditionally, the hierarchical process model was the primary
structure for housing requirements.
The process model was represented as either a decomposition diagram, or a leveled
set of data flow diagrams. During the design phase, these essential processes were trans-
formed into a structure chart, which provided an organizational map of the 3GL pro-
grams that would be constructed. The shape of the hierarchical analysis model was
largely driven by the shape of the chosen solution. Monolithic process-driven programs
were easier to design if the analysis models conformed to the same morphology.
As an example, Figure 4–13 shows a typical green screen layout for entering cus-
tomer discounts. This screen is used to establish discount percentages for a specific cus-
tomer, for a specific product line. The user types in the customer number, the product
line code, the discount amount and associated dates, sales rep. code, and up to four lines
of special instructions. When they are through typing, they either press Enter, a function

START: // END: //

key, or type a string on the command line. Only then does the computer’s processor rec-
ognize the need to edit, validate and store the information on this screen. The accompa-
nying program running behind this screen might have a structure chart that looks roughly
like the one in Figure 4–14. Since the prime deliverable for the programmer was a large
program, the structured design and preceding structured analysis models reflected this
bias and were organized to be easily consumed by the programmer.
Figure 4–13. Green screen for Customer Discount Maintenance

Now imagine taking the large program represented by the structure chart in Figure
4–14 and tearing it up into little pieces, loading it into a shotgun and firing it at a win-
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

dow. The result would be little snippets of code, fragmented like buckshot, scattered
among all of the objects contained on the window.

Figure 4–15 shows the same customer discount maintenance application hosted on
a GUI window. What once was a structured, predictable program has been broken up into
little bits of code which may be independently executed at the user’s discretion simply
by typing or clicking the mouse.
Figure 4–14. Structure chart of Maintain Customer Discount
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 4–15. GUI window for Customer Discount Maintenance

The customer ID field has been replaced by a customer name lookup which will
accept null, partial or complete strings and pop open a list of matching customer names from
which the user may choose. (I use the question mark [?] icon in this book to differentiate
this behavior from that of a drop-down list.) The need to remember product line codes has
been eliminated by allowing the same manner of selection as the customer field. The win-
dow itself contains code to open, close, move and re-size. A command button allows the user
to save his work at any time.
The event model provides far more flexibility to the analyst for organizing his
model. Since the target environment is far more random and flattened, it is useful to have
the same capability in the organization of the analysis models. This section examines dif-
ferent ways that the event model can be organized to aid the analyst and designer toward
the goal of building a client/server-GUI system.

Customer places order

Credit department confirms customer credit limit
Customer pays deposit on order
Sales manager approves order
Production department schedules order
Plant produces order
Plant ships order
Time to issue monthly A/R statements
Customer pays balance due

Sequencing Events by Time

One of the most obvious ways to organize an event list is to sequence events chronolog-
ically (Figure 4–16). On the surface, the technique is very simple. Events are sorted in
the order in which they typically occur. The events on your sorted list are linked together
in an event chain. All event chains start with an unexpected event.
Figure 4–16. Event list sorted chronologically

Sequencing an event list by time makes it very easy for the users to read and vali-
date. The order of the events often mirrors how they have explained their job to you. The
chronology of events also gives you an excellent opportunity to determine predecessor
and successor events, identify expected versus unexpected events, and look for non-
events that may be missing from the list. Once you embark on this endeavor, you may
find that sorting events chronologically isn’t as simple as it initially appears.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Rather than take the example in Figure 4–16 as gospel, let’s start asking some
questions. This is called “interviewing your model.” After making my initial chronolog-
ical listing, my next step as an analyst would be to start asking the users more questions:

“Does the credit department always have to approve credit on each order, or can
customers be pre-approved up to a certain limit?”
“Do all orders require a deposit?”
“Do any customers elect to pay in full in advance (negating the need for the last
two events)?”
“What happens if the plant cannot schedule the order in a reasonable time?”
“At what points can the customer cancel their order?”
“Are all orders subject to sales manager approval, or only the big ones?”
“What happens if the customer doesn’t pay?”
“What happens if their credit is rejected?”
“What happens if the sales manager doesn’t approve the order?”

Depending on the answers you receive, the event list could get far more compli-
cated. You may find that a large percentage of orders advance through the chain in neat
and tidy linear fashion, but others follow a variety of exception paths. Non-events can
reroute your event chain into alternate detours or dead ends. Some events can occur out
of sequence while others must follow a prescribed chronology.
When it comes time to design an interface for this system, the designer needs to be
able to facilitate the normal event chain easily, but still handle the chartered exceptions in
a reasonable manner. In the next chapter, we will introduce a critical model, the state tran-
sition diagram, which does a good job of graphically depicting complex event chain paths.
Sequencing events chronologically is very useful as a tool for validating your
model with the users. It is unlikely that you will be able to create a single chronology for
all of the events in a large business system. For example, table maintenance events such
as System administrator adds new country have virtually no useful relationship to the
events pertaining to customer orders or financial transactions. However, the technique
works extremely well within a particular subject area.
By examining the sorted event list, you can tease out which events must precede oth-
ers and which are optional. The chronological sorting makes it easy to spot expected events
and identify non-events which may be missing from the list. Every business has exceptions,
and it is these exception paths that will complicate the chronological sorting. Ordering
events by time is an excellent way to discover exceptions to the rules early in the project
and avoid costly oversights later. Additional models, such as the state-transition diagram,
covered in the next chapter, will be needed to sort out particularly tangled event sequenc-
ing.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Sorting by Subject

The subject-verb-object syntax of event names provides us with the ability to group
events together by the subject who initiates the event (Figure 4–17). This technique
resurfaces the same issue of expanded versus reduced scope that arose in Chapter 3. The
event list is directly sensitive to any elasticity in the boundary of the context model.
Figure 4–17. Event list sorted by subject

An expanded scope event list is entirely appropriate in the analysis phase, especially
when there are opportunities to change the business organization. In Chapter 3 there is an
example of an order entry function which could be moved from the central headquarters
to the remote sales offices due to the enabling communications technology and the wide-
spread acceptance of the personal computer. Prior to such a decision being finalized, I pre-
fer to state events using the expanded scope subject, Customer places order.
The expanded scope has several advantages. First of all, it doesn’t imply the final
organizational structure of the people who will use the system. It keeps your implemen-
tation options open. It also allows you to sort your event list by subject and group all
events which are originated by the same subject (in this case Customer) together and
examine it for completeness, patterns and possible redundancy.
After the implementation decision has been finalized regarding which user groups
will have the responsibility of interacting directly with the system, the subject can be
stated in reduced scope fashion. Customer places order becomes Sales office enters
order. Sorting by subject on a reduced scope event list gives the interface designer a
wealth of information for organizing the interface. It enables the designer to create cus-
tom groupings to locate functions in convenient proximity for the users of the system.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Event: Customer places order

Initiator: Customer
Transporter: Sales assistant

Event: Customer picks up order

Initiator: Customer
Transporter: Will-call office clerk

To improve the rigor of the event dictionary, I suggest making two separate prop-
erties for the subject of the event. One is the logical initiator of the event, the other is the
transporter of the information to the system which has been nominated by the business
(Figure 4–18). This allows you to sort by initiator or transporter without changing the
name of the event. The initiator is discovered by examining the event using expanded
scope. The transporter is based on an implementation and organizational decision by the
business, and may not be known until later in the project.
Figure 4–18. Event dictionary entries for initiator and transporter

Sorting events lists by subject is a powerful technique. Using the expanded

scope initiator of the event, the sorted list shows the complete role played by the sub-
ject in the system’s context. We will see in the next chapter, (The Information Model)
that this can be particularly useful for uncovering all of the data elements that the sys-
tem may be required to remember about the initiator. The list can be easily verified
by subject matter experts. It also points out patterns that can be useful in determining
which user group should play the role of physically transporting the event’s stimulus
into the system.
Once the optimal user groups are defined, sorting the event list by transporter
becomes a valuable tool for the application designer, as we will see in Chapters 6 (The
Interface Prototype) and 11 (External Interface Design). By identifying all of the tasks
of each user group, it also allows you to plan for upcoming prototyping, testing, training
and documentation efforts.

Sorting by Object

2 I once saw an event list which was sorted by verb. This could yield some bizarre results (especially
if the list contains events such as Accountant executes month-end reporting along with State exe-
cutes death row inmate). I think the analyst was attempting to separate events which create infor-
mation in the system from those which request data. This is better accomplished with an event/entity
CRUD matrix.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Order events:
Customer places order
Sales manager approves order
Customer cancels order
Customer picks up order
Customer fails to pick up order
Production department schedules order
Warehouse fills order

Price List events:

Marketing department establishes new price list
Sales manager requests current price list
Sales manager requests price trend report

It stands to reason that if there are benefits to sorting the event list by subject, there may
also be advantages to sorting the event list by object (Figure 4–19). In this case, I am
using the term “object” to mean the noun in the sentence which receives the action of the
verb.2 The object of the event represents a real world entity, attribute or information
abstraction such as Order, Invoice, Product, Customer account. The object may be a sin-
gle data element as in Shipping Line changes last receiving date. Conversely, the object
may represent many data elements on many entities as in the case of Customer places
order, or Manager requests weekly sales report.
Figure 4–19. Event list sorted by object

In object-oriented systems, the term “object” represents a programming construct

which mirrors a real world entity or information abstraction in its data, process and
observable behavior. I am not implying that every object of the event list syntax will
become an object in an object-oriented business system; however, there is a strong like-
lihood that many of the system’s object classes can be found in the event list as both sub-
jects and objects in the sentence structure. I’ll have more to say about business objects
later in Chapter 12 on internal component design.
The trick to sorting the event list by object is to determine the primary object on
which the event acts and to assign object names consistently. This technique isn’t going
to be applicable for every single event in your system. Its main advantage is to identify
all of the events for the major objects in your system. It’s OK to have a number of stray
events that don’t seem to fit in neatly with the others.
A more rigorous method of relating events to objects is by creating an event/entity
CRUD matrix (Figure 4–8). Events are listed on one side of the matrix, and the entities
from your information model are listed on the other side. In each cell it is indicated
whether the event creates, reads, updates or deletes an instance of the entity. As we will
see in the chapter on architecture modeling, the event/entity CRUD matrix can be very
useful for determining the physical requirements for very large and widely distributed
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

systems. The technique may be overkill for smaller localized applications and you may
find that sorting the event list by object suits your needs.
Sorting the event list by object can yield some specific benefits. The sorted list can
be trotted around to the object’s subject matter experts to see if it is complete and cor-
rect. We will see in the chapter on interface prototyping that the on-line designer needs
to know which events are capable of being executed by the user, once they have acquired
the business object on the window.
For projects which are fully object-oriented (OO), this is the first step toward cat-
aloguing business objects. I strongly suggest, that if your project is going full-blown OO,
that you take the time to create an information model, event model, and the event/entity
CRUD matrix, and use this as a basis for cataloguing most of your business objects.
Without this level of rigor, objects are sometimes determined by “he who shouts the
loudest” in a group design session and can be subject to sudden fits of overly creative
thinking.
You may have already noticed that sorting an event list by object is easier if you
have an information model at hand to which you can refer. It is virtually impossible to
create a complete and useful event model without also creating the information model.
It is also unlikely that the context model can be created without creating a good portion
of the event model as well. This is why I call these models the “big three.” They form
the foundation of the project’s analysis, and are best done iteratively and concurrently.

Leveled Events

For very large systems, the analyst needs some way of grouping events together in a way
that makes sense. Events can be decomposed or leveled, just like traditional process
modeling. The challenge is that the scope of any given event is subject to the modeler’s
interpretation.
The analyst must always be aware of the appropriate level of granularity for each
phase of a development project. Events, just like traditional process models, have an
implied hierarchy. I have defined four major levels of events that I find very useful for
helping me organize my models. The conceptual level, business level, dialogue level, and
design level (Figure 4–20).
The conceptual level is useful for project planning. The business level, coupled with
an information model is the heart and soul of the analysis effort. Early prototyping on the
project introduces the dialogue level, which begins the transition to design. The design
level comprises all of the decisions made by the developers about how the system will be
physically constructed to recognize and react to the logical business level event.

The Conceptual Level

The conceptual level is appropriate for the project charter and planning phases of a
project. Events stated at the conceptual level are intended to define the major func-
tional areas of the system. Customer places order is often a conceptual level event in
ISBN: 0-536-56083-8

Specially prepared for d03063582

Customer Sales Rep Sales Rep...

Customer
places enters order clicks New
New Order
Order,
places order
preliminary order header enters order,
clicks Save,
Save
clicks Requested
Requested
Sales Rep
Ship
Ship Dates,
Dates
enters requested
enters request,
shipment date
clicks Save,
Save
clicks Request
Request
Sales Rep Confirmation,
Confirmation
requests order closes window.
confirmation

Sales Manager SM requests Sales Manager...

confirms unconfirmed clicks Find
Find
order orders Unconfirmed
Unconfirmed
Orders,
Orders
reviews list on-line,
Sales Manager
selects orders
confirms
to confirm
orders
clicks Confirm,
clicks Save
Confirm
closes window.
Save

Logistics office Logistics Agent Logistics Agent...

schedules order requests order clicks Find
Find
for shipment schedule Requested
Requested
Orders,
Orders
clicks Allocate ToTo
Allocate
Logistics Agent Available
Available Space
requests available Space,
transport space reviews results,
modifies selected
Logistics Agent exceptions,
Save
assigns order clicks Save,
to space closes window.

most big companies because the process of ordering products or services can be very
complex. As soon as the analyst delves into the details of this event, it will soon
become obvious that this event is at too high a level for useful analysis and design.
Many projects opt to dispense with the event syntax and label the conceptual level
events with a function area name, such as Order entry, Accounts receivable and
Accounting. These functional areas just as easily could be named Customer places
order, Customer pays invoice, Time to account for sales.
Figure 4–20. Event levels
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

The Business Level

The conceptual level Customer places order points us in the right direction. Detailed
analysis of the business area uncovers a rich lode of related, more granular events which
fall under its umbrella. These events are at the business level. This is the level which is
most appropriate for event modeling during the analysis phase because it corresponds to
what the business users consider a complete task. At the business level, the prime objec-
tive is to uncover all of the system’s detailed essential requirements, without designing
interface dialogue. When conceptual level events are decomposed into business level
events, they may take the form of either event chains or subtypes.
Event chains are multiple events in succession, that comprise the logical conceptual
level event. Customer places order may break down into a chain such as: Customer places
preliminary order, followed by Sales manager confirms order, Logistics office schedules
shipment. The business level events were too granular to mention in the project charter,
but they clearly fall under the auspices of Customer places order.
Event subtypes are variations on the same event. Bank customer applies for loan
may break down into subtypes of the event, such as Bank customer applies for car loan,
Bank customer applies for boat loan, Bank customer applies for home equity loan.
The business level will yield many different permutations on the same event. For
instance, in a point of sale receipting system, the event Customer pays for merchandise
can be subtyped into

Customer pays by check,

Customer pays with cash,
Customer pays by credit card.

Subtyping the event dramatically surfaces all of the different flavors of the event
that the system will have to recognize. This is important because it leads the analyst to
discover that the stimulus data required and the business policy associated with the activ-
ity section for each subtype of the event are different. If the customer pays by check, the
check number and account number will have to be entered and funds may be verified via
a phone line. If the customer pays by credit card, the system needs to know the credit
card type, number and expiration date, and the credit balance verified via a different on-
line service. For cash transactions, none of that data or processing is required.
As an analyst, you have the option of documenting business events at the subtype
or supertype level in your event model. Whichever method you choose, there will be a
trade-off. If you create a separate event dictionary entry for each subtype event, you will
incur some redundancy for any stimulus, activity or response which is identical between
the subtypes. Rolling all of the subtypes up into one event dictionary entry is also accept-
able, but you may find yourself having to include mutually exclusive case statements in
your stimulus and activity sections.
In the example in Figure 4–21, the stimulus definition has to differentiate which
data elements pertain to which subtypes. The activity section will also have to state
which processing is exclusive to each subtype. We also see that the check and credit card
ISBN: 0-536-56083-8

Specially prepared for d03063582

payments necessitate an intervening event before the logical purchasing transaction can
be completed. The system has to dial a verification service and wait for authorization.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

The outcome of the customer’s visit to our store can vary dramatically depending upon
whether the subsequent event turns out to be Verification service authorizes transaction
or Verification service denies transaction.
Figure 4–21. This supertype event dictionary entry should be three separate entries

After attempting to create an event dictionary for the supertype (Figure 4–21), it is
clear that the differences between the subtypes outweigh the similarities. I would opt to
make separate event dictionary entries for the subtype events in this case. Subtyping will
also crop up again in the next chapter. The subtyping found in the event model is likely
to be mirrored by subtyping in the information model.
How far to level your event model can be a topic for intellectual debate; however,
experience soon guides the analyst to a practical solution. Fewer events on the list will
yield more complex event dictionary entries; more granular events will have simplified
specifications but there will be more of them.
My general rule of thumb is similar to the heuristics for data flow diagramming.
When your activity section begins to exceed one to three pages of specification, or when
you are introducing numerous case statements into your stimulus and response flows,
you probably need to decompose the event further, either through subtyping, or looking
for a logical break in the chain. If your event list is gigantic, and the activity section is
really skimpy, it is possible that you are starting to design user interface dialogue and
have descended past the business level.

The Dialogue Level

One of the primary tasks of the interface designer is to determine the appropriate level
of dialogue between the user and the system. The dialogue level takes each business
event and breaks it into a dialogue between user and system, based on the power of the
technology, the skill level of the user, and the appropriate unit of work for the business
task at hand.
To illustrate this point, let’s take two events from a department store. The first
event, Vendor signs new pricing contract, occurs when one of the department store’s ven-
dors signs an exclusive agreement to supply the store at a stated discount off their regu-
lar price. The terms of the agreement are to be entered into their new computer system.
Let’s say the agreements are entered by a clerk in the payables department with fifteen
years of computer experience. If there are ten data elements in the stimulus for this event,
it is likely that the interface designer will be able to put them all on one window. The
business event has been implemented in the system without being broken apart into
smaller chunks of dialogue.
A second event, Shopper inquires on back order status, is to be implemented via a
terminal mounted in a kiosk by the entrance of the store. Shoppers can inquire directly
on the status of available stock in the store, and even see if the desired item has been
back-ordered. This event requires just a handful of data elements as well, such as the
department, the garment type, the brand name, color and size.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Since the kiosk terminal is to be used by the general public and not a professional
“power user,” the designers may break apart the event into more discrete dialogue
between human and computer. In this case, the designer may break up the event so the
computer asks for each piece of information separately. For instance, the user may first
point to the department they want, and the computer asks them what type of item they
desire. That fragment alone qualifies as an event at the dialogue level. It is just a small
piece of the business event, but the designer has opted to create a dialogue in order to
make the computer easier to use for the average shopper.
The dialogue level is typically begun in early prototyping (Chapter 6) and is fully
fleshed out in detailed external interface design (Chapter 11). At this level, the event list
and event dictionary are fully consumed to design the appropriate interface. Each event
is broken apart into a conversation between user and computer, based on the available
technology, the skill level of the user, and the appropriate unit of work.
At the dialogue level, the events are too numerous to manage in a practical manner
through an event list and event dictionary. The navigation diagram, interface prototype
and window layouts are far better models for conveying the behavior of the proposed
system. By using the event list and event dictionary as a basis for the interface design,
the appropriate behavior is engineered into the product. Each window or set of windows
developed should be traceable to the logical business level events to which they were
designed to respond.

The Design Level

The last level in the event hierarchy is the actual keystrokes and mouse clicks that will
have to be coded to implement the event. At the design level, the event’s dialogue is
decomposed further into the specific action the user must take to fully inform the system
that the event has occurred.
The design level incorporates actual navigation, button and menu item names, and
specific field positioning on each window. The appropriate tools for this kind of detailed
design are the window navigation diagram, the window layout, the GUI design specifi-
cation which describes the enablement and behavior of each control on the window and
the presentation and business rules for the data itself. We will see in the following chap-
ters that the user interface can be engineered from the business event model and infor-
mation model using a reliable and repeatable process.

SUMMARY

The event model is the glue that holds all of the pieces of analysis, design, construction
and testing together. The event list embodies the reason you have been hired. The busi-
ness needs to be able to respond to real world events, and it is the responsibility of the
information technology staff to supply them with products that service that need.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

The event model contains an event list and event dictionary. Whenever possible,
events on the list are stated in subject-verb-object syntax. The event dictionary provides
the core of the process specification for your system. For each event on the list, the ana-
lyst has an obligation to define its meaning in clear, concise text. The technical portion
of the event dictionary contains a definition of the stimulus data required to trigger the
event, the activity carried out by the system to formulate the appropriate response, and
the data contained on that response. Additionally, the effect on the environment is docu-
mented so we can understand what the users are trying to achieve.
Most business events are unexpected. The system never knows when a particular
occurrence will happen. Some events are expected. A predecessor event has established
some window of expectation within which the system anticipates the occurrence of the
event. It is very important for the analyst to ask whether the system cares if the event fails
to occur, and include the “non-event” on the list. Expected events in a business system
can be temporal events, meaning they are triggered by measuring the passage of time
against a schedule. Most events in a business system, however, will rely on the user to
directly inform the system that the event has occurred.
The event model is a powerful document which is completely consumed through-
out the project. The information model, the foundation of the underlying database
design, is constructed concurrently with the event model by cataloguing the data require-
ments for each event. The interface prototype declares candidate window layouts, based
on the capability of the technology, the sophistication of the users, the complexity and
sequence of the events, and the character of the data required.
Events can also play a key role in architectural decisions. Event matrices can be
used to plan hardware requirements based on which events occur at the various distrib-
uted business locations. The event dictionary is once again consumed in the detailed
design phase as the designer determines navigation paths, menu and button specifica-
tions, object classes, background functions and stored procedures to execute the business
policy for the event.
The event model also becomes the basis for creating testing plans. The event dic-
tionary already contains a mapping between required stimulus and appropriate response
that can be easily expanded into test scenarios.
Event modeling has its roots in traditional structured analysis. The technique has
risen to the forefront today because the systems we are building are far more flattened
than the hierarchical structures of old. The event list and event dictionary have proven to
be powerful GUI development models. The term event-driven is used to describe GUI
systems because the user’s navigation patterns and flow of work are far more unpre-
dictable now that they are armed with a mouse.
The key to good GUI design is understanding how the system should behave when
responding to business events, and engineering just enough flexibility into the design to
manage multiple events and non-traditional sequencing. This is not to say that GUI win-
dow design is a free-for-all. A significant task of the GUI designer is to decide what the
user can’t do at any given time. A solid event model helps to organize this task.
ISBN: 0-536-56083-8

Specially prepared for d03063582

EXERCISES
1. Which of the following events are expected vs. unexpected in a typical order
management system?

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 25 Oct, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
ANSWERS 115

(a) Customer places order

Specially prepared for d03063582

The Information
Model

INTRODUCTION

Chapter 5, in which Christopher Robin discovers entities, attributes, and relationships. We

ought to start teaching information modeling skills in grade school, because it is without a
doubt, the singular skill which is most vital to the success of your project. I wish that I could
make information modeling as easy for you as a stroll through the Hundred Acre Wood, but
alas, it’s a tremendously complex yet important topic, so we’ll have to wade through it
together. The concepts and traditions of information modeling form the basis of relational
database design and are a core competency for good object modeling. An ill-conceived
information model can play havoc with not only your project, but every successive project
which attempts to use it or extend it. In this chapter, I will cover the entity-relationship dia-
gram, and the information model’s three primary constructs, the entity, the relationship and
the attribute. I will cover relationship cardinality and the concept of normalization. Advanc-
ing past the basis, we will proceed to attributive entity types, associative entity types and
ISBN: 0-536-56083-8

117

Specially prepared for d03063582

Practical Analysis on 12 Nov,
and Design for Client/Server and2010
GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
118 Chapter 5 / THE INFORMATION MODEL

supertypes and subtypes. We’ll take a look at a the state-transition diagram, an important
link between the information model and the event model. I’ll round out the chapter with
some advice on strategies for constructing your information model.

THE PURPOSE OF INFORMATION MODELING

Data is the central core of any information system. It comprises the map of the corporate
memory for any organization. If I was limited to only one model on a development pro-
ject, I’d chose this one in a heartbeat. The information model (a.k.a. data model) creates
the foundation on which the database is designed.
Most businesses are rich in data. There are literally thousands of facts that com-
puter systems must remember. The trends towards relational databases, open systems
and enterprise-wide computing has elevated the importance of proper data modeling
because data respects no project boundaries. Chances are, if your project is interested in
some information about, say, customer discount agreements, then some other part of the
business is likely to be interested in that information as well.
Documenting a business’ data requirements is peculiar in that it has spawned so
many rival notations and naming conventions. Modeling data is as difficult as is it
important. Compounding the difficulty of mastering a technique and notation is the fact
that so many disparate parties within the organization are interested in differing facets of
the same stuff. If you can get your organization to agree on which style of boxes and
lines to adopt, you’re only part way there. The real challenge is to agree on what to put
on the boxes and lines.
The goal of this chapter isn’t to foist a particular notation on you (or heaven for-
bid, invent a new one), but rather to help the reader understand how to assemble an infor-
mation model that accurately reflects the data requirements of the system.

A Brief History Lesson

If you got into information systems as a career after the advent of relational databases,
you may not appreciate how things used to be. Back in the old days, you had to walk five
miles through the snow to get your data, holding nothing but a baked potato in your
hands to keep you warm. Well, maybe it wasn’t that bad, but understanding where data
has been can help us to appreciate the rationale for some of the questionable habits that
still exist in the industry today.
In the 1960s and 1970s the predominant method for storing data was in flat files.
A flat file is simply a named file on the disk which contains data about a subject. You
can imagine the flat file as being comprised of individual records. Each record is made
up of individual data elements, such as customer_name, street_address, city, state,
zip_code, phone_number. In order to access the data on a record, the programmer would
count the number of characters in the record and declare in the program the exact posi-
tion where each data element begins and ends. By altering the definition of the parsing
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

routine, the designer of the flat file is able to redefine individual records within a flat file,
so that the definition of one record can vary from the next.
As abhorrent as this sounds to anyone raised on today’s relational database tech-
nology, one has to remember that at the time, disk space was far more expensive than it
is today. Database management systems were primitive at best, and every programmer
had to manually declare the name, length and data type of every data element read from
the database. This led to conflicting definitions of the same data element across many
programs, and even different naming conventions of the same data element appearing in
different flat files.
As the breadth and depth of information stored on disk expanded throughout the
world it was clear that a technical and organizational crisis was looming. Businesses
needed to get their arms around the type of data that their systems needed to remember.
Standards needed to be established and runaway redundancy had to be curtailed.
By the late 1970s and early 1980s, data flow diagramming was gaining favor as a
method for analyzing the process carried out within a system and the data requirements
flowing into and out of each process. Data for every data flow was defined in the data
dictionary using a short-hand notation to describe the relationship between elements. For
example, the data flow customer_order would be defined as:
customer_order = customer_name, customer_address, account_number,
current_date + {product_code, quantity}.
The reader would interpret this as “customer order equals customer name, cus-
tomer address, account number and current date, plus iterations of product code and
quantity. Additional symbols were included to convey optionality.
Although this technique was cumbersome, it was far better than anything that
existed up to this point in time. The translation from data dictionary entries into database
design was not obvious, and many early structured analysis projects collapsed under the
weight of their own data dictionaries.
Along came Peter Chen’s concept of the entity-relationship model to the rescue.1
He devised an implementation-neutral and process-neutral way to depict the structure of
data itself. Logical groupings of data elements about real-world objects were called enti-
ties, and were drawn as rectangles. The relationship between the entities was drawn with
a diamond on a connecting line. This is commonly referred to as Chen notation. The dia-
gram is known as an entity-relationship diagram (ERD) (Figure 5–1).
Examining the diagram, we can intuitively see that this system appears to be inter-
ested in persons and dwellings. Furthermore, we can deduce that the system is chartered to
keep track of which persons reside in which dwellings. Chen notation has not entirely sur-
vived in today’s world of automated CASE2 tools. The diamond has largely been dropped
in favor of just a single line to represent relationships. The main reason for the diamond
falling out of favor is that it occupied too much real estate on the computer screen.

1 Chen, 1976
2 CASE is an acronym for Computer-Aided Software Engineering.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 5–1. Chen notation

Some of the early adopters of Chen’s technique were very successful in modeling
their data requirements. Others experienced problems in the design phase, since rela-
tional databases still had not come into their own in the marketplace. The constraints of
the flat file or hierarchical databases of the time often prompted dramatic departures
from the logical data model when it came time to implement a design.
Today, with the advent of modern relational database technology, it is possible and
desirable to implement a database which closely resembles the real world structure of the
data. Relational databases have continually improved in their speed and ability to efficiently
handle multiple table joins. These improvements, coupled with the availability of cheaper
disk space has removed most of the criticisms of data modeling leveled by early skeptics.
The structure of the data model has undergone some improvements since Chen’s
time as well. Most CASE tools do a reasonably good job of managing the data model,
but unfortunately, competing vendors have introduced a variety of notations. The term
information modeling has come into vogue, since the term data implies a collection of
facts, but information implies that the facts have some business relevance beyond their
sheer existence. I’m not too picky about which term you use. The term object modeling
has been used by some in an attempt to appear more object-oriented, but this term car-
ries with it a more complex connotation of process and behavioral elements, as well as
a bending or outright suspension of the traditional rules of normalization. For this rea-
son, even on a project with an object-oriented target language, I prefer to build an infor-
mation model to document my data requirements, especially when a relational database
is involved. The activity of cataloguing objects is a natural follow-on task.

THE COMPONENTS OF THE INFORMATION MODEL

A complete information model which is sufficiently detailed to be useful for subsequent

design or software package purchase decisions should include the following. The rest of
this chapter will provide detailed definitions of each component.

Entity-relationship diagram, showing all named entities, named relationships

and the minimum and maximum cardinality on each relationship in both direc-
tions. Large diagrams should be partitioned for readability.
Volume and retention estimates for each entity
Attribute listing for each entity
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Clear textual definition of each entity, relationship and attribute

Properties of each attribute including: optionality, data type, range, unit of
measure, precision and restricted values
State-transition diagrams for each status attribute or relevant entity life cycle
A variety of entity matrices

If this looks like a tall order, it is. This model provides the detailed foundation for
all data design decisions which follow, including physical database design, data distrib-
ution, even window and report layout. A so-called “high-level” information model which
only includes a hastily drawn diagram with no attributes or definitions is of absolutely
no use at all to the designer or to the software package purchasing team. Regardless of
whether you will build or buy your software, this is where the project must get into the
nitty-gritty dirty details of the business requirements. It’s better to take the time to build
the information model now than have to suffer the consequences of making ill-informed
decisions later.

The Entity-Relationship Diagram

The information model’s primary graphic element is the entity-relationship diagram

(ERD). It is comprised of the entities about which the system needs to remember spe-
cific facts, and the relationships which exist between these groups of facts. Figure 5–2
shows a small piece of an entity relationship diagram. In the following sections, I will
cover all of the components represented in the notation.

Entities

Webster’s New World Dictionary defines entity as, “n. 2. a thing that has definite, indi-
vidual existence in reality or in the mind.” That’s a very broad statement, so let’s see if
we can cast the word entity in terms of software engineering.
We see from Webster’s that an entity is a noun. Additionally, it can represent a real
world construct such as Customer, Order, Sales person or it can represent an abstraction
such as Order item, Discount agreement or Magazine subscription. Each individual
instance of each entity is unique; however, they have similar characteristics and behav-
ior which makes it often advantageous to group them. The system needs to be able to
represent entities in a persistent format that can be recalled on demand. Our software-
engineering definition of an entity is:

An entity is a person, place, thing or abstract idea, about which the system
needs to remember something. Instances of each entity have similar charac-
teristics and behave in a similar manner.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 5–2. A sample entity-relationship diagram

Entities are represented graphically as a rectangle. The name of the entity is placed
inside the box. Imagine the box as containing a bunch of dots. Each dot represents an
individual instance of the entity. No single instance is represented twice (Figure 5–3).

Figure 5–3. Each member of the entity is unique

When you create an entity, just like any other object in your model, you have
incurred an obligation to define it. Write down the name of the entity, and then write a
clear textual definition. Try to picture in your mind if the definition adequately describes
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

the real-world instances of the entity. Read your definition and re-examine the entity
name to see if you’ve chosen the best one.
As you create your model, you may come across entity volume and retention esti-
mates. Volume is the number of instances of the entity that a business might expect, such
as number of customers, number of orders placed per year, number of vendors. Reten-
tion is how long you need to keep any given instance of the entity on-line. These statis-
tics will become important later in the design of the architecture and application, so if
you encounter the information now, it’s good to include it with the entity definition.

Relationships

Entity members are very social. Instances of entities are constantly associating with
other entities. Customers place orders, orders may have multiple order items, each asso-
ciated with a product, which may be associated with an inventory balance, and so on.
These associations are called relationships. A relationship is drawn as a line between one
entity and another. Imagine that the line connects the “dots,” or rather the instances of
one entity with the instances of another. In Figure 5–4, we see a relationship between the
entity Person and the entity Dog.3 The relationship can be read in either direction. Read-
ing from left to right, we use the name above the line, “Person owned Dog.” Reading
from right to left, we use the name below the line, “Dog has been owned by Person.”

Figure 5–4. Horizontal orientation

For relationships which are depicted vertically (Figure 5–5), or at an angle, imag-
ine our horizontal relationship rotated clockwise. The name which was on top is now
read from top to bottom down the right-hand side. The name which was on the bottom
is now read northbound up the left-hand side.
You may have noticed that I named this relationship in the past tense. Just like any
other words we use on a model, the names of entities and relationships need to be very
precise in order to convey the same meaning to each reader. If the relationship is supposed

3 I must give credit to Meilir Page-Jones for his world-famous Person owns Dog example, which has
been pressed into service many times to illustrate a host of information modeling concepts.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 5–5. Vertical orientation

to represent all dogs that the owner has ever owned, past tense is appropriate. If the rela-
tionship is restricted to only the dog or dogs currently owned, present tense should be
used. Better yet, the relationship name can be modified to be even more descriptive, such
as “Person has ever owned Dog” or “Person currently owns Dog.” In addition to naming
the relationship, you also have an obligation to define it with a clear textual statement.
Relationship names are extremely important because they are able to convey a
great deal of business policy and meaning when named correctly. I beseech you to avoid
sloppy names such as Can have, Is related to or Is associated with. The fact that you
have drawn a line already informs the reader that a relationship or association exists.
This type of lazy name is about as useful as naming each entity Entity.

Relationship Cardinality
There is an important constraint on relationships that is declared graphically on the
entity-relationship diagram called cardinality. Cardinality is how many of one thing
relate to another. Relationship cardinality is particularly important because it forms the
basis of many design decisions. Cardinality is expressed with a value for minimum and
maximum. The minimum value describes whether the relationship is optional or
required. The maximum value describes whether the relationship is singular or plural.
Since relationships are stated in both directions between two entities, the minimum and
maximum cardinality must also be stated in both directions. This means that for every
relationship in your model, four points of cardinality are required to express the nature
of the relationship adequately (minimum and maximum in both directions).4 Let’s

4 I will concede that on large, conceptual level information models, which are used for planning but not
detailed design, you can get away with stating only the maximum cardinality. However, when you get
into detailed analysis and design, you need all four points of cardinality to adequately express the busi-
ness rules which need to be enforced in the database structure and perhaps on the interface as well.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

explore the different facets of relationship cardinality using our example of “Person
currently owns Dog” (Figure 5–6).

Figure 5–6. Relationship without cardinality notation

Once you have established that the system is chartered to remember which persons
currently own which dogs, the next four questions to arise are:

1. Must a person own a dog?

2. May a person own more than one dog?
3. Must a dog be owned by a person at all times?
4. May a dog be owned by more than one person at a time?

Question 1 is designed to tease out the minimum cardinality when reading from
left to right, entity A to entity B. Is a person compelled to be a dog owner in our system?
If so, what happens if their dog dies or runs away? Do we run the dogless individual out
of town? Do we hound them until they get a new dog? Should we supply them with a
replacement?
Question 2 is designed to determine if the same instance of entity A can participate
in relationships with multiple instances of entity B at the same time. When the answers
to questions 1 and 2 are determined, the analyst can place the minimum and maximum
cardinality on the diagram to express the business rule.
The graphic notation for minimum cardinality is either a zero, meaning “optional,”
or a one, meaning “required.” The notation for maximum cardinality is either a one,
meaning “only one,” or a pair of crow’s feet, meaning “many.” Figure 5–7 shows the
four possible combinations and their accepted vernacular.

Min Max Graphic notation

- -
Zero-to-One

- -
Zero-to-Many

- -
One-to-One

- -
One-to-Many

Figure 5–7. Notations for relationship cardinality

ISBN: 0-536-56083-8

Specially prepared for d03063582

The cardinality notation is placed directly on the relationship line to the right of the
relationship name which it modifies. If we have determined that a person may own zero
to many dogs, it would be expressed graphically as in Figure 5–8.

Figure 5–8. Relationship with minimum and maximum cardinality in one direction

To read the diagram, you start by saying the name of the first entity, followed by
the proper relationship name in the direction you are reading, followed by the cardinal-
ity notation, and finally the name of the second entity. In Figure 5–8, we read “Person
currently owns zero to many Dogs.”
We are only half finished with relationship cardinality. We have yet to answer
questions 3 and 4 which will tell us the cardinality in the opposite direction. Question 3
starts with the Dog entity and reads backwards towards Person, asking if the relationship
between a dog and its master is optional or required. The business implication of a zero
minimum cardinality is that we will allow stray dogs in the system.
Question 4 asks whether we will allow joint custody of dogs, or whether dog owner
is always one person only. Notice that the relationship is named Is currently owned by. We
might get a different answer to our question if the relationship means Was ever owned by.
Assuming that the business tells us that a dog may be currently owned by only one
person, and that a dog must have an owner to be a dog of interest, we can finish our dia-
gram by placing the minimum and maximum relationship cardinality for the opposing
side of the relationship (Figure 5–9).

Figure 5–9. Relationship with all four points of cardinality

In summary, relationship cardinality is expressed by the minimum and maximum

number of occurrences allowed between an instance of entity A and instances of entity B.
To fully describe the nature of the relationship, the cardinality must also be determined
between an instance of entity B and instances of entity A. The cardinality pairs are placed
on the diagram at the end points of the relationship. When reading the diagram, you start
by reading the name of entity A, followed by the relationship name between entity A and
entity B, followed by the cardinality closest to entity B, and finally the name of entity B
(Figure 5–10). This process is exactly reversed for reading in the opposite direction.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Figure 5–10. Reading relationship cardinality

There are several graphic notations for relationship cardinality. I favor the crows
feet notation because it is so intuitive for the reader. It uses a “1” for “one,” a “0” for
“zero” and the “<” sign that we all remember fondly from our second grade introduction
to set mathematics. Whichever notation you use, make sure that all four points of rela-
tionship cardinality are expressed graphically on your diagram.
The minimum and maximum cardinality must be expressed in both directions to
adequately define the business rule. To stress the importance of this point, let me illus-
trate how the designer consumes this information.
Let’s say our business users have told us that a dog must be owned by one and only
one person. A person must own at least one dog, and possibly many. The business rule
would be expressed as shown in Figure 5–11.

Figure 5–11. Persons must own at least one dog

It is the responsibility of the database designer to implement this relationship in a

physical database schema. During the relational database design many, if not all, of the
entities in your information model will become tables. (More on this subject in Chapter 9.)
Given the relationship in Figure 5–11, it is inadvisable (and downright malfeasance) to
place the primary key of the Dog in the Person table as a foreign key, because it would
require a repeating group. It is acceptable (and common practice), to place the primary key
of the Person table in the Dog table, since there will only ever be one person representing
the owner for each dog. Of course, if the business ever declares that joint custody of dogs
is acceptable, your design is blown. Note that the maximum cardinalities on this relation-
ship dictated which physical table got the foreign key. The minimum cardinality between
Dog and Person dictates that the person’s primary key will be required as a foreign key in
the Dog table.
Perhaps more interesting is the relationship between Person and Dog. The mini-
mum cardinality on the “many” side of the relationship is not enforced by referential
ISBN: 0-536-56083-8

Specially prepared for d03063582

integrity in relational database management systems. The business rule that a person
must have at least one dog will have to be coded into the system. Several possibilities
are available to the designer. When entering a new person into the system, the designer
could elect to disable the Save until the user specifies at least one dog. The user would
also have to be disallowed from ever removing the last dog from a person. The chal-
lenge of enforcing this rule would certainly move me to explain to the users the ram-
ifications of their decision, and ask them again if they want the rule enforced in their
system. Relationship cardinality has an extremely powerful impact on the database
and application design. The cost of making a mistake in your model can be very high
down the road.

Attributes

The third major component of the information model is the attributes which represent all
of the data elements in your system. Each fact about an entity constitutes a separate
attribute. There is no standard graphical notation for attributes, since they are often too
numerous to list on an entity-relationship diagram. Usually, the attributes are provided
on a separate list which accompanies each entity. Some CASE tools allow you to print
the attributes listed inside of the entity box on the ERD, however, this can get unwieldy
as the list grows.
The following example takes the business event Customer drops off laundry and
shows how each data element involved in the transaction can be attributed to an entity
on the information model.

Example: Attributing Data Elements to Entity Types

Let’s take a moment to pry into the private life of traveling salesman, Slick Pitchman.
Slick has been touring the countryside selling portable household vacuum cleaners
which are reportedly powerful enough to suck up small cats. After having relieved
Dodge County’s citizens of several of their beloved felines in an ill-fated demonstration
at the fairgrounds, he has made a hasty retreat to Winthorp on the other side of the
mountains. His first order of business is to drop off his shirts and jacket at the local dry
cleaners.
He walks through the door and sets fifteen identical white shirts and a soiled cor-
duroy sport coat on the counter. The clerk eyes him suspiciously and asks him if he’s
new in town. Slick doesn’t know it, but he is about to become an instance of the entity,
Customer.
The clerk has certain facts that she needs to collect about Slick and his laundry. She
takes down his first name, last name and the phone number of his cheap motel. She notes
that fifteen shirts need to be laundered and one jacket requires dry-cleaning. She also
makes a note of the peculiar red stains and preponderance of cat hair that will have to be
removed from the jacket. Slick is issued a dated and numbered claim ticket, with the
price marked in the corner. The clerk promises him that his clothes will be ready the next
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

day after 5:00 PM, and politely declines his dinner invitation. Figure 5–12 summarizes
the list of data elements required by the system to recognize and respond to this event.

Customer’s first name,

Customer’s last name,
Customer’s current phone number,
Date dropped off,
Claim ticket number,
Date promised,
Time promised,
Plus a repeating group of:
Garment type,
Number of garments,
Service required,
Service price,
Special instructions.

Figure 5–12. Data elements for event: Customer drops off laundry

The data elements of any business problem can be attributed to entity types
through a process called normalization.5 Normalization is a set of heuristics developed
by Edgar F. Codd in the early 1970s to extend the life expectancy of applications by rep-
resenting the data in a non-redundant relational format. Systems with well normalized
databases are able to withstand extensions to data, functionality, and changes in the
nature of inquiries with minimal disruption.
Codd’s principles of normalization are the foundation of relational database
design. The goal of the information model is to create a logical representation of sys-
tem’s normalized data requirements; in other words, to store each fact in one place. To
this end, Codd provides us with three levels of normal form, cleverly entitled, First Nor-
mal Form, Second Normal Form and Third Normal Form.6
Unnormalized data is a random collection of data elements with repeating record
groups scattered throughout. Figure 5–13 shows the data from our dry cleaning exam-
ple, unnormalized. It appears as though Claim Ticket has been nominated as the primary
key for this rabble.7

5 Codd, 1972
6 There are additional levels of normalization, but in practice most analysts will stop at third normal form.
7 The term primary key is used for the field or fields which uniquely locate a record in a physical table
or file. A foreign key is a primary key that is embedded in a different (or same) table, (hence the
name foreign), to link two records together by providing a reference back to the table in which it is
a primary key. The term unique identifier is used for the attribute(s) and relationship(s) which may
be used to identify a specific instance of an entity.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 5–13. Unnormalized dry cleaning order

First Normal Form

In First Normal Form, there are no repeating groups of attributes.

To achieve first normal form, the repeating records are first moved off to a separate
group and associated back to the other data through the use of a relationship. In a physi-
cal database design, the primary key of the first group, Claim ticket number, is inserted in
the second group as a foreign key to link the records. In the information model, the graphic
relationship between entities suffices to inform the reader of the association. The foreign
keys are not shown as attributes in the other entities. This omission adheres to the concept
of safe deferral. As long as the database hasn’t been physically designed, the primary key
of any given entity could be a topic of debate, and therefore, scattering it about the model
as a foreign key in other entities is premature and inadvisable.
Figure 5–14 shows our dry cleaning order in first normal form. The Order can still
be uniquely identified by the claim ticket number, but the individual services ordered
require both the Claim ticket number, Garment type and Service type to uniquely iden-
tify an instance of Order item.
Figure 5–15 shows the entity-relationship diagram for our dry cleaning order in
first normal form.
First normal form solves the age-old problem of repeating groups in data sets. In
the dark ages of database design, the analyst attempted to guess at the upper limit of the
repeating group and establish the requisite number of columns in an unnormalized file.
Everyone in the business would swear on their grandmother’s grave that no customer
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

had ever brought in more than five garment types at one time. Inevitably, as soon as five
repeating groups had been petrified for all time in the system, the first six-garment-type
customer would parade through the door.

Figure 5–14. Dry cleaning order in first normal form

Figure 5–15. ERD for the dry cleaning order in first normal form

Second Normal Form

In Second Normal Form, for records with concatenated primary keys, all non-
key attributes are fully functionally dependent on the whole of the primary key.

Second normal form addresses the problem of records which have primary keys
comprised of multiple data elements. When you have concatenated keys, each data element
on the record should be functionally dependent on the entire key, and not just part of the key.
In our Order item in first normal form, the primary key is comprised of Claim ticket num-
ber, Garment type and Service type. Notice that the Unit price is not entirely dependent on
the whole key. The current unit price can be determined using the Garment type and Service
type. It appears that this business is in need of a price list for the services it provides.
We can remove the Unit price from the Order item and put it in a table with Gar-
ment type and Service type. While this satisfies the syntactic requirements of second nor-
mal form, it presents a problem to the business because the Unit price could be changed
ISBN: 0-536-56083-8

Specially prepared for d03063582

on the Service type table, leaving them unable to query historical prices associated with
each Order item. For this reason, I suggest strongly that we qualify the unit price on the
Service type table as Current unit price charged by the business. We need to also include
unit price back to the Order item as well and qualify it as the Order unit price, which
represents the unit price charged at the time the order was taken. The Current unit price
is dependent only on the Service type and Garment type. The Order unit price is depen-
dent on Service type, Garment type and Claim ticket.
The unit price is an example of apparent redundancy. If we named both attributes
Unit price, they might look redundant but they really are not. I have seen cases where
one or the other attributes were removed from the model in the name of eradicating all
redundancy. The resulting system was problematic. To avoid over-zealous abuse of nor-
malization, each attribute in your model must be defined. In this case of unit price, only
the definition would point out that the unit price on the order is subtly different than the
unit price stated on the service type price list. Figures 5–16 and 5–17 show our dry-
cleaning order in second normal form.

Figure 5–16. Dry cleaning order in second normal form

Second normal form removes data elements which are not fully dependent on a
concatenated key and places them in their own table. Because the rule for second nor-
mal form is limited to data sets with multi-column keys, it is not as obvious a distinction
as first or third normal form.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Figure 5–17. ERD for the dry cleaning order in second normal form

Third Normal Form

In Third Normal Form, each attribute is functionally dependent on the key, the
whole key, and nothing but the key.8 (Transitive dependencies are removed.)

If we examine our data layout so far, we can still spot a problem. The customer’s
First name, Last name and Phone number are not really attributes of the Order. They are
attributes of the Customer. From a technical standpoint, we are wasting space when all
this information has to be repeated for every order that is placed. From a business stand-
point, we lack the ability to accurately query all orders for a given customer since the
customer’s name could be spelled differently on any given order. We can address the sec-
ond problem by assigning each customer a unique Customer number. The problem of
data redundancy, however, still exists until we take the attributes which are transitively
dependent on Customer number out of the Order and move them to their own entity.
Much of your system’s data can be resolved to third normal form quickly if you just
take the time to play a game that I call “Are you my mother?” Are You My Mother, writ-
ten by P.D. Eastman and first published in 1960, is a book which teaches pattern recog-
nition to small children by relating the story of a baby bird hatched while his mother was
away gathering worms. The baby bird proceeds to wander about the yard asking the kit-
ten, hen, dog, cow, car, boat, plane and snort9 if they are his mother. By simple inspection
the bird (and hopefully the reader) can see that these creatures are not birds, and therefore
could not be his mother. When the bird finally is reunited with his mother, it is plainly
obvious to all that the baby belongs with the mommy because they are both birds.
8 So help me, Codd.
9 Eastman, 1960. If you don’t know what a “snort” is, I suggest you acquire a copy of the book. I don’t
wish to give away the entire plot.
ISBN: 0-536-56083-8

Specially prepared for d03063582

A great number of the attributes floating around your system can be reunited with
their mother entities if you simply take the time to use a strong dose of common sense
and ask, “Are you my mother?” Is Customer name an attribute of Order? No, it’s an
attribute of the Customer. Most of our customers were named by their parents long
before they decided to drop off any laundry at our establishment. Their name is not an
attribute of their dry cleaning order.
Is the customer’s Phone number an attribute of the Order? No, it is the number
where the customer can be reached. It clearly is dependent on the customer. With a little
common sense, we can quickly get much of the model to third normal form by asking if
the attribute really belongs to the entity. Take the time to try this with your information
model. Many of the attributes in your models represent real-world entities. If you sim-
ply visualize the entity and its characteristics, it isn’t difficult to pigeon-hole a large per-
centage of your attributes correctly. Then your team can argue over the hard ones.
Figures 5–18 and 5–19 show our dry cleaning order in third normal form. The
attributes which are dependent on the customer have been moved to a Customer entity.
Since no suitable logical identifier exists for Customer, a Customer number has been
added. Remember that I’m only including the foreign keys to illustrate normal forms. In
an information model, the relationships suffice to communicate the linkage between
entities. The decision to place the Customer number in the Order is an implementation
decision and would be deferred until database design.
It is important for every professional in the information industry to be at least
familiar with the concepts of normalization. I am not suggesting, however, that you must
always be ready for a pop quiz on second normal form should somebody accost you with
their data layout in an elevator. As your information modeling skills develop, you will
find yourself instinctively attributing your entities in something very close to third nor-
mal form.
I present normalization in this chapter because it is a foundation on which the infor-
mation model and relational database concepts are based. In practice, it is not necessary
to turn the iron crank of the normalization machine every time you need to organize your
data. The analyst must know what his data means and how it is to be used to do a good
job of information modeling, or, as Meilir Page-Jones is fond of saying, “Normalization
is a syntactic solution to a semantic problem.”10
A small percentage of the information modeling population will use normalization
as a formal technique for organizing a sea of tangled legacy data elements. Most people
will simply employ the rules of normalization as a method of testing the completed
information model. It is my sincere desire that you will internalize the concept, lodge it
in the back of your mind and go about your days subconsciously creating elegantly nor-
malized information models.

10 Additionally, Page-Jones asserts, “Normalization is a proofreading technique for information models,

not a construction technique.” I agree whole-heartedly.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

$7.50

Figure 5–18. Dry cleaning order in third normal form

Figure 5–19. ERD for the dry cleaning order in third normal form
ISBN: 0-536-56083-8

Specially prepared for d03063582

Attribute Cardinality
You may have inferred from the section on normalization that each attribute in your
model gets a name and a clear textual definition. The textual attribute definitions create
a data dictionary that is used throughout the entire life of the system.
Another important property of attributes is attribute cardinality. Attribute cardi-
nality declares how many instances of the attribute can apply to one single instance of
its entity.
There are two points of cardinality for every attribute, a minimum and a maximum
value. The minimum value can be zero or one. A minimum of zero declares that the
attribute is optional for any given instance of the entity. A minimum of one says that the
attribute is required. This is a critical piece of information because it will determine
which columns are capable of storing nulls in your database design.
The maximum value may be one or many (or some fixed upper limit number
greater than one). The maximum value is designed to tell us whether the attribute is
repeating for any instance of the entity. The maximum cardinality is important because
it will help you eliminate repeating groups and quickly get your model to first normal
form. Many seasoned information modelers reflexively record their model in at least first
normal form, so repeating groups are automatically eliminated. In this case, you only
need to record whether an attribute is optional or required because the maximum cardi-
nality will always be one.
Returning to our “Person owns Dog” example, let’s examine some attributes that
might be associated with a dog. Our system might be chartered to remember the dog’s
License number, Name, Weight, Birth year, Vaccination type and Vaccination date. The
License number has been nominated as our unique identifier.

Figure 5–20. Attributes of the Dog entity

By assigning the attribute cardinality we find that the License number is required.
We will accept no unlicensed dogs in our system. Each dog will have only one license.
The business has also insisted that the Name of the dog is required, and a dog may have
only one name. The Weight is optional and we are only interested in the current weight.
The Birth year is optional, and again there will only be one birth year for any given dog.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

The Vaccination type and Vaccination date, however, could have no values if the dog
has never been vaccinated, but could have multiple values if the dog has received many
shots. The resulting attribute cardinality can be expressed using a short-hand notation to
the left of the attribute name (Figure 5–21). The minimum value is stated on the left, the
maximum value on the right.

Figure 5–21. Attribute cardinality

Your first normal form violation siren should be going off about now. The Vacci-
nation type and Vaccination date need to be moved off to a separate entity to eliminate
the repeating group. When one or more the attributes of one entity get promoted to an
entity of their own, this is called an attributive entity type.

Attributive Entity Types

An attributive entity type is an entity which started life as an attribute or set of attributes
of another entity. Because it is inextricably linked to its parent entity, it cannot exist on
its own. Figure 5–22 shows the entity-relationship diagram for Dog and our new entity
Dog vaccination.

Figure 5–22. An attributive entity type

Note that the relationship cardinality between Dog and Dog vaccination is zero to
many. It is the same as the attribute cardinality for Vaccination type. The unique identi-
fier for an attributive entity will be a concatenation of the relationship to the parent entity
and at least one other attribute. In this case the relationship to Dog, plus the Vaccination
type and the Vaccination date is required to identify a unique instance of Dog vaccina-
tion (Figure 5–23).
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 5–23. Attributes for Dog and Dog vaccination

The attribute cardinality for Vaccination type and Vaccination date has now
changed. The zero-to-many relationship cardinality takes care of the repeating group.
The attribute cardinality now expresses how many occurrences of Vaccination type and
Vaccination date are possible for one instance of the entity Dog vaccination. In other
words, for any record of the dog getting a shot, how many values could you have for the
type of shot and the date of the shot? The answer is one. If the dog receives two types of
vaccination on the same date, you record two instances of the entity Dog vaccination.
Attributive entity types can be noted graphically on the entity-relationship dia-
gram. Several notations have cropped up. The most common is a pyramid in the box. An
alternative is a rounded corner rectangle (or “roundangle”) in the box (Figure 5–24). By
noting the attributive entity types graphically on the diagram, you convey to the reader
that the entity is really a logical extension of its parent entity.

Figure 5–24. Two versions of attributive entity type notation

Figure 5–25 shows a common attributive entity type, Product price. The product
entity has an attribute called Price which itself has attributes, Start date and End date.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Most businesses have a requirement to keep prices past, present and future, causing this
attribute group to repeat for any instance of product. The attributive entity type comes to
the rescue again as a good solution to this problem.

Figure 5–25. Product and attributive entity type, Product price

Attribute Definition
So far in this chapter, we’ve seen that each attribute requires the following properties:

Name: A concise, understandable name conforming to your shop’s data-

naming conventions
Definition: A clear and complete textual statement of the attribute’s meaning
and its purpose and use in the system. The definition should be
verifiable by the intended users of the system. Much of the field-
level on-line help and definitions within the written system docu-
mentation should be derivable from the attribute definitions.
Cardinality: Attribute cardinality has two values, a minimum and maximum.
The minimum value is either zero or one. It determines whether
the attribute is optional for any given instance of the entity. The
maximum value is either one or many. It determines if the attribute
can repeat for any instance of the entity.

In addition to these properties, the analyst should also record,

Data type: The data type describes the length and valid values for the
attribute. You may use standard SQL data types such as Char(1),
Integer, Decimal(11,2), Varchar(200), in accordance to your
shop’s standard data type convention.11 You may also create stan-
dard data type abstractions such as:

11 So far in this chapter, I’ve implied that you have a published set of standard naming and abbrevia-
tion conventions and a standard set of data types in your shop. The word “standard” also implies
that there is some penalty for non-compliance. If your IT shop does not have these established,
there’s no point in proceeding any further until you get this in place. Without standards, your infor-
mation modeling efforts will quickly descend into chaos.
ISBN: 0-536-56083-8

Specially prepared for d03063582

YES/NO: a one-character field whose valid values are “Y” and “N”
MONEY: a DECIMAL(11,2) field with nine digits to the left,
two to the right, to be used for all domestic currency
attributes.
Whichever method you use to assign data types, it is important that
you achieve a reasonable level of consistency across the entire
model that will serve you well in the database design.
Range: If your data is numeric, you must specify the upper and lower lim-
its of the range (e.g., Dog weight must be greater than zero and less
than 1,000 pounds.).
Unit of I like to embed the unit of measure in the attribute name, such as
measure: Shipping weight MT. This tells the reader that the shipping weight
is stored in metric tons, rather than short tons, pounds or kilo-
grams. Fiscal year conveys far more explicit information than Fis-
cal period. If your shop’s standard does not employ such a naming
convention, you must include the unit of measure in your
attribute’s properties.
Precision: Sometimes the precision allowed (number of places to the right
of the decimal) is more restrictive than the data type is capable
of storing. For example, your standard data type for percentage
fields might allow for three decimal places (e.g.: “0.125” for
1/8th), but your application might only allow increments of
1/8th rather than any three digits. If the precision is not readily
discernible from the data type, it needs to be explicitly stated.
Restricted Many values in GUI systems will become drop-down lists. Their
Values: values are restricted to a particular set of words or characters and
they are sufficiently invariant that a separate reference table is not
needed. For example, the values of order status might be “pending,
confirmed, back-ordered, filled, shipped and invoiced.” The val-
ues must be listed in the information model so they can be
designed into the interface and application logic.

There is a lot of information to be gathered about each attribute in the system.

This is where most of the detailed definition of your system’s requirements resides.
A well-crafted information model with detailed attribute definitions, coupled with a
robust event model will give you a wealth of knowledge from which you can engi-
neer applications that meet the business’ needs. From this point forward in your pro-
ject, there is little or no use for a “high-level” information model. You need to be
down in the details.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

ASSOCIATIVE ENTITIES

If an attributive entity type is an entity which started life as an attribute or set of attrib-
utes about another entity, then you may have surmised that an associative entity type is
an entity which started life as an association or relationship between two or more enti-
ties. Let’s do a simple example to illustrate how associative entity types are derived, then
tie it back to a classic example from a real business system.

Example of Deriving Associative Entity Types

Let’s say our firm has been hired to analyze a problem at a local chicken ranch. We
find our chicken ranch located at the intersection of four state highways, two running
north–south and two running east–west. Due to a recent increase in traffic, and the
unfortunate location of the ranch, there has been an unusually high fatality rate as the
chickens seem unshakable in their determination to cross the roads. Our job is to cre-
ate an information system which will track which chickens crossed which roads and
gather statistics about the conditions at the time of the crossing, and rate the success
of the endeavor. The database will be used to come up with a solution for this vexing
problem. (If this project had done a charter, they probably would have figured out that
a simple fence would suffice.)
First, identify the event(s) which create the association. In this case, Chicken attempts
road crossing is the culprit. Record and define the entities which represent fundamental, tan-
gible things in the real world. Chicken and Road fall into that category (Figure 5–26).

Figure 5–26. Begin with the fundamental entity-types

Once you’ve drawn an entity, it’s a good habit to define it right away. Defining
Road is easy, but Chicken can be more difficult. Are you going to create a record for
every chicken on the ranch or only those who attempt road crossings? What you’re really
verifying is which event or events create instances of the fundamental entities in your
model. This is very important stuff. Most errors that I have seen on information models
are due to sloppy naming and poor definitions, which often lead to various members of
the project team making divergent assumptions about the system. By management fiat,
I will declare that chicken means “only chickens which have attempted at least one road
crossing.” (We should cross-check our event dictionary entry for Chicken attempts road
crossing at this point to ensure we have mandated that novice chickens have their iden-
tities established on their first crossing attempt.)
ISBN: 0-536-56083-8

Specially prepared for d03063582

Now that you have settled on the fundamental entities, establish a relationship
between them. Name it in both directions, and define all four points of cardinality.
The resulting cardinality (Figure 5–27) shows us that chickens must indeed cross
at least one road before they are recorded in the system, and they may cross many roads
as long as their luck holds out. Additionally, roads need not be crossed before they are
recorded in the system, and any given road can be crossed many times.

Figure 5–27. A many-to-many relationship

This pattern is called the many-to-many relationship. It allows for a single instance
of either entity to be associated with multiple instances of the other entity.

A many-to-many relationship occurs when an instance of entity A can be

related to multiple instances of entity B, and an instance of entity B can be
related to multiple instances of entity A.

Many-to-many relationships add a great deal of complexity to the design of a sys-

tem. The first problem is in the relational database design. Let’s jump forward to the
design phase and imagine that we have a Chicken table and a Road table. To implement
the relationship, Chicken crossed road using foreign keys, the relational database
designer can’t place the Chicken number in the Road table, or the Road number in the
Chicken table. To work around this dreadful design, users would have to add a redundant
row to either table every time a crossing occurred (or worse, call the IT department and
have them splice in some extra columns). Such a relational database designer is likely to
be murdered after hours by the programming team.
The last vexing issue is that we have no place in which to store attributes such as:
Crossing date, Crossing reason, Crossing direction, Traffic conditions, Crossing suc-
cessful. These are not attributes of the Chicken or the Road. They are actually attributes
of the relationship Crossed. The evidence is mounting that we have another entity
emerging in our model which is an associative entity type.

An associative entity type is used for the following reasons:

1. to resolve many-to-many relationships,
2. to hold additional attributes which are characteristics of the relation-
ship, not of the participating entities,
3. to allow a relationship to participate in other relationships.

Promote the relationship to become an entity. The graphic notation for an associative
entity type is a diamond in the box. This is a quaint carry-over from Chen notation which
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

depicts relationships as diamonds. This graphic clue immediately informs the reader that
the entity started life as a relationship. The entity must be named and defined. In this case,
I’ve chosen the name Crossing, and defined it as “an instance of a single chicken attempt-
ing a crossing of one of the four roads surrounding the ranch” (Figure 5–28).

Figure 5–28. The many-to-many relationship resolves to an associative entity type

We now have two relationships to define, one on either side of the associative
entity. Since we’ve already used the primary relationship name for the associative
entity, naming these secondary relationships can be tricky. The resulting diagram in
Figure 5–29 shows that the many-to-many relationship has been replaced with one-to-
many relationships.

Figure 5–29. The resulting cardinality for the associative entity, Crossing

An important pattern emerges. Notice that the cardinality connecting Chicken and
Road to the associative entity is “one to one.” This is because a relationship cannot exist
without its end points. Also notice that the original one-to-many and zero-to-many still
exist, but they have crossed over. Figure 5–30 shows how the cardinality on a many-to-
many relationship typically resolves using an associative entity type.

Figure 5–30. The typical many-to-many resolution pattern

ISBN: 0-536-56083-8

Specially prepared for d03063582

We now have a suitable home for the attributes associated with the Crossing.
Notice that the relationships to the originating entities are included in the unique identi-
fier for an instance of crossing, along with at least one other qualifying attribute to dis-
tinguish between repeated attempts (Figure 5–31).

Figure 5–31. Attributes for Chicken, Road, and Crossing

Suppose that we decide to promote Crossing reason to become an entity so

the users can control the list of valid reasons. The associative entity type, Crossing,
gives us the ability to allow the original relationship to participate in other rela-
tionships. We can simply connect the entity Crossing to the entity Crossing reason
(Figure 5–32).
Now, let’s see if this pattern holds for more complex systems. Pretend that our
Chicken has been transformed into Customer, and the object of her desire is not a Road,
but instead a Product or Service offered by your company.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Figure 5–32. Associative entity types can participate in other relationships

Figure 5–33. Customer and Product are fundamental entity types

Identify the event or events of interest. In this case, I’ll nominate Customer orders
product. Record and define the entities which represent fundamental, tangible things in
the real world, Customer and Product.
You will recall the wrangle over defining chickens. Defining Customer is just as
tricky. You must decide when a customer becomes a customer in your system. Is it when
they place their first order, when they apply for credit, or will you record potential cus-
tomers as well? (I don’t know the correct answer for your company, but I’ll settle this
one by saying it’s when they place their first order, just so we can finish this book.)
Establish a relationship between Customer and Product, and determine all four
points of cardinality (Figure 5–34). Now you can begin to resolve the many-to-many
relationship by promoting it to an associative entity type. What emerges is the famous
associative entity type, Order (Figure 5–35).

Figure 5–34. A many-to-many relationship

Figure 5–35. The many-to-many relationship resolves to the associative entity type, Order
ISBN: 0-536-56083-8

Specially prepared for d03063582

We must be very precise when placing the cardinality on these relationships. Cus-
tomers can place one and perhaps many Orders. An Order is placed by one and only
one Customer. Orders, however can request one or more Products, and Products can be
requested on zero or many Orders. We have yet another many-to-many relationship
(Figure 3-36)! Many-to-many relationships don’t always resolve in one step.

Figure 5–36. The resulting cardinality still includes a many-to-many relationship

We repeat the process one more time to resolve the many-to-many relationship
between Order and Product. Order item emerges to represent the various Products that
can be requested on a single instance of Order.
Figure 5–37 shows the finished ERD fragment. This important pattern crops up
over and over again throughout any system where customers acquire the products or ser-
vices of business or government. You will see this pattern emerge throughout this book.
(I was struck once by the similarities between the information models of a sales system
and a superior court system. The only difference was that the customers of the court were
not showing up voluntarily, and the court was dispensing prison sentences instead of
products.)

Figure 5–37. The classic customer-order pattern

It is important to resolve all of your many-to-many relationships in your logical

model prior to designing the database. By uncovering your associative entity types, you
create a mother entity for all of the attributes which are characteristics of the relationship.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

The associative entity type also allows the originating relationship to participate in other
relationships.
Perhaps the most important reason to recognize these objects in the analysis phase
is because they can severely complicate your design. Associative entity types will result
in intersection tables in your relational database, adding an additional table join to link
participating members in the relationship. They will require additional windows and
more complex reporting. Associative entity types present the GUI designer with some
interesting navigational challenges, especially if the many-to-many nature of the rela-
tionship is the exception rather than the rule.

SUPERTYPES AND SUBTYPES

In the real world, many objects belong to a similar class, but themselves have divergent
characteristics. Planes, Trains and Automobiles are all examples of the class Vehicle, but
they clearly have different characteristics and behavior. Some of the entities in your
model will follow similar pattern. Collectively, they fall into a broad category called the
supertype, within which each instance shares a limited number of similar attributes and
can participate in the same relationships. The supertype may break down into several
categories called subtypes. Subtypes are groupings within the supertype that have attrib-
utes which are unique to the subtype, and not shared among all instances of the super-
type. Subtypes may also participate in relationships which are exclusive to the subtype.
The most common and often most complex supertype/subtype in most business
systems is the entity Customer. Customers come in many shapes and sizes. Take, for
example, the customers of a typical international manufacturing firm. The data required
for export customers is different than that for domestic customers. Customers who are
responsible for payment may be different than the customers who actually receive ship-
ment of the goods. Customers may be internal to the organization or external. External
customers may be trading companies operating on behalf of the real customer. Under-
standing and modeling the structure of the customer is often one of the most difficult
information modeling tasks facing an organization. Other likely candidates for subtyp-
ing including the products and services offered by the company, and the different types
of employees, contractors and service providers involved in the business.
There are a variety of notations available for subtyping. Figure 5–38 shows three
of the most popular notations. The first is a simple decomposition diagram of the entity,
showing that Vehicle can be either a Plane, Train or Automobile. The second notation
uses garden-variety relationships to express that a “Vehicle can be a Plane,” but a “Plane
is a Vehicle.” The third notation nests the subtype entities inside of the supertype entity.
This is particularly handy because it saves space on the CASE tool screen.
Attributes which are common to all instances of the supertype are stored in the super-
type entity. They are not repeated in the subtype entity. The supertype/subtype relationship
declares that any subtype entity inherits all of the attributes of its supertype and participates
in any relationships attached to the supertype.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 5–38. Three supertype/subtype notations

Attributes which are unique only to the subtype must be listed with the appropri-
ate subtype. Similarly, all relationships which are restricted to the subtype must be
attached only to the subtype entity.
In our example, all vehicles may have a Vehicle ID, Passenger capacity and Top
speed. These attributes can be safely housed in the supertype entity Vehicle. If you need
to store Wingspan, however, this attribute is only applicable to the Plane and should
reside only in that subtype (Figure 5–39).

Figure 5–39. Relationships and attributes of supertypes and subtypes are depicted
at the level to which they apply
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

A relationship such as “Company owns Vehicle,” could apply to all instances of the
supertype, but other relationships such as a plane’s base airport or an automobile’s currently
assigned parking space should be connected to only the subtypes to which they apply.
In practice, subtyping has to be approached with a strong dose of common sense. If
you modeled every possible subtype and permutation of Customer, in most large organi-
zations, the number of entities needed to represent Customer could be extremely high.
The goal of subtyping isn’t to eliminate every optional attribute in your model, rather it
is to identify the major classes of supertypes which define common behavior for their sub-
types, and to separate out specialized subtypes at a reasonable and relevant level.
For determining “how low to go” when subtyping an entity, I prefer to brainstorm
all of the different types of the entity. Returning to our manufacturing example, a cus-
tomer may break out initially to:

Ship to versus Bill to roles

Export versus Domestic locations
Internal versus External ownership.

I’ll stop there before this example gets too complicated for the confines of this
chapter. The next step is to examine the similarities and differences between the attrib-
utes of the different customer types and the relationships in which they participate.
We may find that the attributes for the location to which the product is shipped are
very different than those for the customer to whom the product is billed. The shipping
location could be the customer’s manufacturing location or their warehouse. The bill
could be sent to the parent company’s corporate office. The Bill to customer requires
attributes regarding its credit status, the Ship to does not. Additionally, we may find that
pricing and product specifications are related to the Ship to customer, but not to the Bill
to customer. Conversely, the invoice must relate to a Bill to customer.
As a general rule, I find the exclusivity of relationships at the subtype level is a
far more compelling reason to model the subtype as a separate entity than is the pres-
ence of a few specific attributes. Let’s say that the only difference between Internal
and External customers is a few attributes, but no significant relationships are asso-
ciated exclusively at the subtype level. I find it acceptable and practical to roll these
back up to the supertype level and use an attribute such as Customer type to make the
distinction.
This simple suggestion can save you a lot of grief if someone on your project
goes overboard on subtyping. You mustn’t ignore subtypes altogether. They are a crit-
ically important part of your modeling effort, and there are a variety of ways to rep-
resent them in a physical database. Differentiating subtypes based on their
participation in relationships will help you keep your model grounded at a practical
and consumable level.
ISBN: 0-536-56083-8

Specially prepared for d03063582

STATE TRANSITIONS

One of the most useful models to the GUI designer is a state-transition diagram. Many
of the entities in your model pass through a life cycle. An instance of the entity is born,
passes through several phases in life, and is eventually laid to rest. The tip-off that your
system is chartered to remember the current life cycle phase of an entity is typically an
attribute called Status.
An entity, such as Order, might have a Status whose values may be restricted to:

tentative,
confirmed,
canceled,
back-ordered,
filled, or
shipped.

To “kick” an entity from one status value to the next, you need an event. The state-
transition diagram forges an important link between the event model and the information
model because it graphically shows which events change the value of a given state
attribute.
Figure 5–40 shows the state transition diagram for order status. The status values
are shown inside the box. The events are shown as arrows which note the direction of
the state change. The initial status is indicated by an arrow entering the diagram from
the top or side. In this case, the event, Customer places order sets the order status to
“tentative.”
It appears that one of two events may occur next. Credit department approves
credit, could set the order status to “confirmed,” or the customer could call and cancel
his order. The state-transition diagram is very powerful and easy to read. We can see
from this example that only “confirmed” orders can be “filled” or “back-ordered.” This
implies that tentative orders cannot be filled or back-ordered. Similarly, a shipped order
cannot be canceled, but a filled order can.
As an analyst, you can take the state-transition model to the users and lead them
through the possible transitions. What you will often find is that there are additional
events lurking out there that have heretofore eluded the project team. You may find, for
instance, that the customer can cancel a filled order, but is charged a restocking fee. This
difference in policy for filled orders should be reflected in the event dictionary.
The rules expressed by the state-transition diagram are critical to the design of a
well-crafted user interface. Figure 5–41 shows an Order Selection window on which the
user can retrieve a set of orders based on the selection criteria he enters at the top of the
window. Once the orders are retrieved, he may click through the list and carry out a vari-
ety of actions based on the command buttons on the window.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Figure 5–40. State-transition diagram for Order status

Figure 5–41. Window layout for Order Selection

ISBN: 0-536-56083-8

Specially prepared for d03063582

Notice the Cancel Order button on the button bar. Command buttons and menu
items are enabled or disabled depending on whether the action is a valid one for the user
to take. If the user has clicked on, or “set focus” on any given order, should the Cancel
Order button be on or off? The answer depends on the status of the selected order. If the
status is “canceled” or “shipped,” the button should be disabled (grayed out). Our state
transition diagram tells the designer that the Customer cancels order event is not valid
when the order has already been canceled or has been shipped. If the user clicks on a dif-
ferent order in the list which happens to have a status of “tentative,” then the Cancel
Order button should be enabled once again.
Status fields are not trivial matters in complex business systems. Many entities may
have multiple status attributes, each tracking a different aspect of the entity, such as Pro-
duction status, Pricing status, or Approval status. Each attribute which holds a state value
for an entity should have its own state-transition diagram. The state-transition diagram
allows the analyst to model and verify the business rules, prior to the design and coding
of the system. It also provides a basis for testing the system’s behavior after coding is
complete.
The state-transition diagram graphically depicts each restricted value for a status
field as a rectangle. The arrows show the events which can move the status from one
value to the next. The diagramming technique is extremely useful for those state values
which do not proceed in a neat and tidy sequential fashion. An unexpected event such as
Customer cancels order throws an exception path into the natural progression of the
order through its life cycle. Exception paths such as these make simple sequencing of the
event list unwieldy. The state-transition diagram rides to the rescue by allowing the ana-
lyst to map multiple paths on one diagram.

ENTITY MATRICES
Once you have a list of the entities in your system, a variety of matrices can be built to
relate the entities to other objects in your model. In traditional information engineering,12
entity matrices are used extensively in the formation of an organization’s information
strategy plan. These matrices, and variations thereon, are also useful for deriving the dis-
tribution requirements for an overall client/server architecture.
We saw at the end of Chapter 4 that an event/business location matrix can be cre-
ated to show which events are to be recognized at each business location (Figure 5–42).
Each event’s data requirements can be summarized in an event/entity CRUD matrix
(Figure 5–43). This shows which events create, read, update or delete (CRUD) instances
of the entities in the information model.13

12 Martin, Finkelstein, 1981.

13 This model largely replaces the entity/process CRUD matrix used in traditional structured analysis
for mainframe systems. Since the activity section of the event dictionary contains the system’s pro-
cessing requirements, events are really a “user’s perspective” way of identifying procedure, albeit
with some redundancy.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Event/Business location

Customer places order

Credit dept. approves order
Prod. dept. assigns order
Plant fills customer order
Plant ships customer order
Accounting invoices customer order
Marketing mails catalogue

Figure 5–42. An event/business location matrix

Event/Entity

Customer places order

Credit dept. approves order
Prod. dept. assigns order
Plant fills cust. order
Plant ships cust. order
Acctg invoices cust. order
Marketing mails catalogue

Figure 5–43. An event/entity CRUD matrix

Given these two matrices, a third matrix can be derived. If the event occurs at the
business location, then the event’s required data must also be accessible at that location.
The business location/entity CRUD matrix displays the data distribution requirements
(Figure 5–44).
ISBN: 0-536-56083-8

Specially prepared for d03063582

Business location/Entity

Figure 5–44. A business location/entity CRUD matrix

A variation on the event/entity CRUD matrix is the event/entity currency matrix

(Figure 5–45). The values in the cells show how old the data can be for any given event.
For instance, the customer’s credit information must be 0 hours old for the event Credit
department approves order. Similarly, the customer’s shipping address must be 0 hours
old for the event Plant ships customer order. On the other hand, the data can be up to 48
hours old for the event Marketing mails catalogue. This information will give the sys-
tem architects a sense of how quickly they need to either replicate or transport data
around a widely distributed system.
The user authorization/entity CRUD matrix (Figure 5–46) is a variant of the
event/entity CRUD matrix. Instead of events, the matrix shows the user groups who are
authorized to carry out the events. The duplicate entries are distilled down to a matrix
which shows which user groups are authorized to create, read, update and delete which
entities. The result is a matrix which forms the basis of the user authorization for your
relational database management system.

TOP-DOWN VERSUS BOTTOM-UP STRATEGIES

The information model, event model and context model form the “big three” analysis
models. Together, they cover the data, behavioral, process and boundary requirements of
the system. All that is missing is to put a face on the interface with some interface pro-
totyping to validate the essential requirements.
I want to stress that even though this book presents context, events and informa-
tion sequentially in separate chapters, in practice, these models are built concurrently. It
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Event/Entity

Customer places order

Credit dept. approves order
Prod. dept. assigns order
Plant fills cust. order
Plant ships cust. order
Acctg invoices cust. order
Marketing mails catalogue

Figure 5–45. An event/entity currency matrix

User authorization/Entity

Sales representative
Credit manager
Production manager
Production assistant
Invoicing clerk

Figure 5–46. A user authorization/entity CRUD matrix

is a matter of personal choice as to which one you start first, but it is almost impossible
to finish one without having a good handle on the other two. Additionally, we will see in
the next chapter that the interface prototype, to a large extent, can be derived from the
“big three” models. What I have found in practice, however, is that it also works in
reverse. The interface prototype can also help you derive and finish the “big three.”
ISBN: 0-536-56083-8

Specially prepared for d03063582

So, how do you get started on your information model? There are several ways to
approach it. A top-down strategy can be employed by looking around your event model
for all of the major things about which the system needs to remember something. This
will lead to subject-area entities such as Customer, Order and Product.
Once you have the main entities for your major functional areas, you can start sub-
typing them and refining them. Customer may break out into several subtypes. Order
will possibly end up as Order header, Order item, Scheduled shipment, Scheduled ship-
ment item. Your Product entity will decompose into the various subtypes of products and
relationships to the pricing structures, bill of materials and manufacturing specifications.
Eventually, the top-down approach progresses from large subject area entities, to
more granular refined entities, and eventually to the attributes. A top-down approach
works well if you are creating an enterprise-wide information model for strategic infor-
mation planning. It is also useful at the project level if your legacy system offers few
clues to the data elements needed for the new system.
A bottom-up approach starts with the attributes, and using the concepts of normal-
ization (and a good dose of “are you my mother” and common sense) aggregates the facts
in the system into entity groups. A bottom-up approach is appropriate when you are con-
fronted with the amorphous sea of data from an unnormalized legacy system. You collect
all of the data together and simply grind through it, systematically attributing the data ele-
ments to their proper entity types and working out the relationships and cardinality.
A middle-in approach is one that I use, by building my information through accre-
tion. I like to get a rough idea of my major entities first, then start doing some event mod-
eling. I determine the data elements required for each stimulus and response and attribute
those to my information model, refining as I go. In the end, I model only the informa-
tion that the system needs, and I have accounted for how each attribute is created and
consumed by the system.
It is important to recognize that information models respect no project boundaries.
Data is the core shared asset in any organization. Your information modeling effort must
be bound by some sense of scope. The event model and context model provide that
boundary. Without setting some sort of limit, the information model can expand infi-
nitely as you creep ever outwards into other subject areas and eventually beyond the bor-
ders of your organization.
This caveat goes both ways. At the same time that you are limiting your modeling
effort to the scope of your project, you must be aware that other projects need your data.
The first client/server project in your organization may also be the first entirely relational
database. If this is the case, you are presented with a fantastic opportunity to normalize
your organization’s data. This is a tremendous responsibility because the database for the
first client/server project often is confronted with modeling the core entities such as Cus-
tomer and Product. Of course, this means that the first project will get hit with the cost
of modeling much of the business’ data, which will drive up the cost disproportionally.
If you do a good job of information modeling on the first project, however, the subse-
quent projects will reap the benefits of a solid foundation.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
SUMMARY 157

Businesses that already have an enterprise model and significant relational data-
base expertise stand a much better chance of success on their first client/server endeavor
than those who have yet to institute sound data resource management.

SUMMARY

The information model’s importance transcends a single project. Data is the central
information asset of the business and should be modeled and managed prudently. The
primary components of an information model are entities, relationships and attributes.
Entities are persons, places, things or abstract ideas about which the system needs to
remember facts. Instances of an entity are grouped together because they share common
characteristics and exhibit similar behavior. Entities are represented as rectangles on the
entity-relationship diagram (ERD). Each entity should be carefully named and defined.
Relationships represent the associations between entities. A relationship is drawn
as a line between one entity and another on the ERD. The relationship should be named
in both directions. Reading from left to right, use the name above the line, from right to
left, use the name below the line. The rule applies for vertical relationships. Simply
rotate the diagram clockwise (Figure 5–47).

Figure 5–47. A sample entity-relationship diagram

ISBN: 0-536-56083-8

Specially prepared for d03063582

Relationship cardinality expresses the minimum and maximum number of occur-

rences of the relationship that can occur between instances of the entity. A relationship
may occur for an instance of an entity one and only one time, one to many times, option-
ally only once (zero to one), or zero to many times. Relationship cardinality is used to
determine the foreign key structure of the physical database. It is very important that
your model express all four points of cardinality, minimum and maximum in both direc-
tions, for each relationship.
A many-to-many relationship is one which allows multiplicity in both directions.
These relationships can severely complicate a system and should be resolved by trans-
forming them into associative entity types. An associative entity type is one which began
as a relationship, but is promoted to become an entity so it can hold attributes of its own
and participate in additional relationships.
Each fact about an entity constitutes a separate attribute. Attribute cardinality
declares how many instances of the attribute can apply to one single instance of its entity.
Each attribute should occur only once for each instance of the entity. You must specify
whether it is optional or required. If the attribute repeats, then it should be promoted to
an attributive entity type. Attributes which are dependent on their entity’s key, the whole
key and nothing but the key are said to be in third normal form.
Attributes should be carefully named, according to your shop’s data naming con-
ventions. Every attribute should have a clear and complete textual definition. In addition
to the textual definition, you should specify the data type, upper and lower limits of
numeric ranges, unit of measure, precision and restricted lists of values if they apply.
Some entities have groups of instances that themselves share common characteris-
tics and behavior that is not shared by all of the members of that entity. These are called
subtypes. Subtypes can have attributes and participate in relationships that are unique to
the subtype and they automatically inherit all of the attributes and relationships of the
supertype.
The state-transition diagram forges an important link between the information
model and the event model. It is used to show which events alter the status of an entity.
Entities can be used in a variety of matrices. The event/entity CRUD matrix shows
which events create, read, update or delete instances of each entity. The entity/business
location CRUD matrix shows the organization’s logical data distribution requirements.
The user authorization/entity CRUD matrix depicts which user groups are authorized to
create, read, update and delete which entities. The event/entity currency matrix tells us
how old the data can be for any given event.
The information model can be built using a top-down, bottom-up or middle-in
approach. It is important to bound your effort within the context of the project at hand,
but be constantly aware that the information model is shared by all projects. If you are
interested in certain data, it is more than likely that another application inside or outside
of your organization is concerned with the same data. Sound information modeling is
one of the secrets to client/server success.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

EXERCISES
1. A developer in a life insurance company once found a curious set of data in the
legacy system’s database. The column for policy holder’s Age contained both
positive and negative values. Wondering how their customers could be negative
years old, the developer tracked down the source of the anomaly and was sur-
prised by the reason. Can you guess the reason?
2. In an old mainframe banking system, a developer found an even more curious
comment embedded in thousands of lines of undocumented code. The solitary
comment read: “Customer-sex-code: 0 = Unknown, 1 = Male, 2 = Female,
3 = Other.” The value “3” was actually referenced in the code several times. Can
you guess what information modeling problem caused this bizarre situation?
3. Customers very often have many addresses that a system has to keep track
of. For this reason, Customer address often appears on the information
model as an attributive entity type of the Customer entity. Employees also
have multiple addresses, and so do Vendors. Can you see anything wrong
with putting all addresses in the system into one entity called Address and
linking it to the appropriate other entities, such as Customer, Vendor and
Employee?
4. The users at a check printing firm once told me that checks could be purchased
with up to six additional options, such as a custom monogram, or the cus-
tomer’s name under the signature line. The Order Entry screen dutifully had six
columns of option codes next to each order item in which the additional options
could be ordered, corresponding to six columns of option codes in the Order
item table. Loud sirens should be going off in your information modeling minds
at this time. What’s wrong with this picture?
5. Can an associative entity type exist with only one relationship connected to it?

ANSWERS
1. The system stored age literally in the database and held the Date of birth in a
separate field. Each night a batch program ran to determine if anyone had cel-
ebrated a birthday and incremented their age one year. Unfortunately, the sys-
tem analysts failed to recognize either Date of death, or Whether deceased as
attributes of the policy holder, so an intrepid programmer had decided to insert
a negative sign in front of the age field to denote policy holders who are no
longer with us. That way, the happy birthday batch program knew to skip over
these records, since dead people don’t get any older.
2. The information modelers had failed to properly subtype customers into
human customers and nonhuman customers such as businesses. Because there
ISBN: 0-536-56083-8

Specially prepared for d03063582

was no overt way to distinguish between the two, the programmer needed a
way to disregard attributes that pertain to humans that companies do not pos-
sess, and vice versa. Since businesses are neither male nor female, he saw an
opportunity to create a Customer-sex-code value of “3” to identify business
customers, thus packing two pieces of information into one field. The result
was an unseemly mess throughout the entire application wherever customers
needed to be distinguished by type.
3. This is a common information modeling error that I call aggregation by coinci-
dent data type, not by business reason. The only apparent reason that a modeler
would lump addresses together into one grand entity is because they all have a
street address, city, state and zip code. It would make no more sense to lump all
prices in the system into a entity called Money. A true test of whether the con-
cept is valid is to define the entity Address and see if it makes any business
sense. The definition might be “a physical location on the map at which a per-
son or company of interest to the system resides, makes child-support payments,
does business, receives mail, receives invoices or accepts shipments.” In most
business systems, this definition would be nonsense. Employee addresses have
no relationship to customer addresses, and therefore do not belong in the same
entity. Few businesses have such a compelling interest in knowing which
employees are also customers of the business and further require complete real-
time maintenance of related data to make this schema valid. However, it would
be perfectly valid to create a reusable address object which retrieves and pre-
sents address information on the interface in a standardized manner.
4. The six option codes on the order item form a repeating group, violating first
normal form. More important, I found with further questioning, that many peo-
ple at the company firmly believed that checks only had room for six options.
In fact, there was no true limit to the amount of customization you could order
on your checks, and customers routinely ordered seven, eight or nine options.
The extra options were being keyed into the sixth column on the old Order
Entry screen as “option code 99-miscellanous,” and were being referenced in a
comment field and manually priced. As a result, this firm really had no idea
how many options of each type they were selling. The solution was to promote
Order item options to become an attributive entity type and allow for an unlim-
ited number of additional charges on an order item.
5. No. An associative entity type is, by definition, the result of an association
(relationship) between two entities (or a many-to-many recursive relationship
to the same entity). It cannot exist without explicit references to all of the end
points of the original relationship.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
CHAPTER
6

THE INTERFACE
PROTOTYPE

INTRODUCTION

Now we get to the fun stuff. Chapter 6 introduces the concept of prototyping. In some
shops, prototyping is a euphemism for “code something quickly and see if the users will
accept it.” You won’t find that approach advanced within these pages. Instead, I propose
that a prototype can be well engineered. A successful prototype starts with a stated objec-
tive of what you want to learn from doing the prototype. Once you understand what it is
you’re trying to achieve, you can select a prototyping technique (low-tech or high-tech)
which is most cost effective for achieving the objective. In this chapter, I will discuss the
pros and cons of early prototyping and discuss valid reasons for both low-tech and high-
tech approaches. We will then turn our attention to how the analysis models can be used
to engineer the system interface. The event model allows you to group events together,
based on the user who initiates them, the sequencing of the events, and the objects to
ISBN: 0-536-56083-8

161

Specially prepared for d03063582

which the events apply. The information model provides an organizational map of the
data which must appear on the user interface. The relationships in your information
model will heavily influence the layout of your windows. We will also see that proto-
typing can be done at many stages during the project. You can use it as a technique to
discover and validate the business event and information requirements to create your
“big three” models. During the design phase, you can prototype the various navigation
and user control decisions you will have to make before coding the application.

WHAT IS A PROTOTYPE?

A prototype is generally accepted to be a mock-up or facsimile of the real thing, but

not so fully functional as to pass for the final product. Prototypes come in many shapes
and sizes. In the auto industry, prototype cars can range in complexity from a model
carved from a block of wood to an actual motorized vehicle that you can drive around
the back lot.
The same range of complexity holds true for software systems. The prototype can
be as simple as a set of paper window layouts taped to the wall, or as sophisticated as an
animated software program which allows users to click buttons and enter data.
A prototype can be useful at several phases in a project. At each phase, the objec-
tive of the prototype must be clear. During the analysis phase, a prototype can be used
to elicit user requirements. In the design phase, a prototype can help evaluate many
aspects of the chosen implementation.

The Purpose of Prototyping

Prototyping should always be done with a specific learning objective in mind. This chap-
ter focuses on how to create window layouts by consuming the context, event and infor-
mation models for early prototyping in the analysis phase.

In the analysis phase of a project, the prime directive of prototyping is to

derive and validate your essential requirements while keeping your imple-
mentation options open.

The analysis prototyping effort focuses on window information content and busi-
ness events. This means that design issues such as final layout, navigation, determining
the user’s appropriate unit of work and nailing down every command button and GUI
control are still premature and can be safely deferred. You will start forming opinions and
begin collecting information about the ultimate design of the product, but that is not the
purpose of prototyping while gathering requirements. When reviewing an analysis stage
prototype with the users, keep them informed of the prime directive. If the users bring
up design issues, write their comments down and draw their focus back to content and
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

business events. You will come back to the GUI design later in the project. We will see
in Chapters 10 and 11 that there is a lot more to a GUI than window content.

Benefits of Early Prototyping

More than any of the “big three” models, the interface prototype really draws the users
into the project. For the first time, the system has a “face.” Inevitably, after seeing the
prototype, someone will tell the analyst about an event that heretofore has gone unmen-
tioned. They will also add data items to the window which were not mentioned during
interviews, and possibly take some away as irrelevant. For this reason, I find it impossi-
ble to really finish the information model or the event model until I have a prototype.
Taking it to a further extreme, prototyping can be used as an interview tool to actually
derive the information and event models.
Prototyping will also cause business process issues to surface. When a client/server
system begins to intrude into what once was the personal computer’s domain, you may
find people who perform essentially the same task in radically different manners. The
new system may eliminate redundant data entry into spreadsheets or ancillary systems,
or alter or eliminate someone’s job description. The prototype is often the users’ first
clear glimpse of their future working environment.
Prototyping will also surface technical issues at a point in the project when there’s
still enough time to do something about them. Window layouts can be mapped to the
information model to get a sense of how complex the data access might be. I recently
encountered a dramatic example of a window prototype which surfaced a vexing techni-
cal problem. A sales support group required a very densely packed inventory projection
window which was capable of displaying past, present and projected future inventory
balances. The information model indicated that a massive number of complex table joins
and calculations were required to put the data on the display. The potential performance
bottleneck had gone undiscovered until the prototype was created. The analyst handed
off this window to a technical team that was able to take the time to find a way to make
it work, averting a last minute coding crisis.
The prototype also lets you explore possible target environments. It may be that a
graphical user interface is not optimal for your particular application. You can explore
how your interface would look with pen-based systems, hand-held devices, bar-code
readers, a web page, or good old character-style green screens.
It is important that your users are familiar enough with the target technology to
evaluate your layouts without getting confused. For users who have never seen a GUI,
you will need to give them an introduction and demonstration using several standard
GUI applications such as a word processor and a spreadsheet, or perhaps demo another
GUI application in your shop. Users need to understand that they can have multiple win-
dows open, relevant data in the title bar, and have the ability to drag windows out of the
way. Otherwise, your users may insist on practices which were artifacts of the green
screen days, such as repeating header information at the top of each screen.
ISBN: 0-536-56083-8

Specially prepared for d03063582

The Downside of Prototyping

Like all good things, prototyping has a downside. Even though you are still gathering
requirements, the prototype starts the project down the road to design. Analysts must
constantly mind the prime directive and use the prototype to derive and validate the
requirements while safely deferring detailed design decisions. I insist on this separation
because analysis is hard enough without being distracted by navigation, ergonomics, or
worse, coding issues.
For any portion of your project on which you want to move into design, it is impor-
tant to get the information model and event models nailed down first. The detailed design
of the interface can be done concurrently with the architectural modeling and database
design efforts which follow the completion of the analysis models. All of these tasks,
however, will be severely hampered and plagued with rework if the information and
event models are not well understood.
Be careful in your prototype not to imply features that you can’t deliver. The GUI
paradigm comes with a plethora of features and controls. The goal is to use the ones
which are appropriate, not to use them all. On my very first client/server project, we
promised a slick drag-and-drop feature in the prototype. When it came to actually cod-
ing it, we found the drag-and-drop function of the development tool to be problematic.
We regretted ever promising that particular navigation style, since the users had become
enamored with the idea and wouldn’t entertain any other alternatives, even though a
variety of methods would have worked. Coding took twice as long as expected and test-
ing it was a nightmare. From that point on, we kept the prototypes simple and relatively
neutral on navigation issues. In the detailed design phase, we concentrated on those GUI
features that we knew we had mastered.
Perhaps the gravest danger of early prototyping is that the project manager may let
slip the reins from the programmers. Freed from the shackles of analysis, they may drop
all pretense of modeling and start coding the system. On a project of any appreciable
size, this spells disaster.
One of the basic premises of this book is that client/server-GUI applications are more
complex and require more engineering savvy than their mainframe counterparts. Through
years of trial and error, I am completely convinced that the current crop of development
tools are still more expensive to modify than a well crafted design specification. A discrete
design step will yield a specification that allows the project manager to partition the pro-
gramming effort among multiple coders, and enables independent testing of the applica-
tion by a quality assurance team. Without a design specification, all subsequent testing and
documentation efforts must wait until the programmer delivers finished code. The design
specification is one of the most cost-effective deliverables in the entire project.

How Detailed Should the Prototype Be?

There are two schools of thought when it comes to prototyping. One camp supports a
high-tech coded prototype which eventually evolves into the finished system. The system
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

is coded incrementally, starting with the interface layout, then adding more and more
detail to animate the system.
The other camp believes that so-called high-tech prototypes are still too expensive
and that the same benefit can be yielded from cheap low-tech layouts made in a word
processor, drawing tool, piece of paper, white board or CASE tool.
At this point in the evolution of software development tools, I am a firm believer
in low-tech prototypes. Even the low-tech prototype is reused in the design specification
and test script. The reason I support low-tech prototyping has to do with the high speed
of achieving the learning objective, and the low cost of making changes.
Remember that the prime objective of prototyping in the analysis phase is to gather
and validate requirements, while deferring detailed design decisions. Low-tech proto-
typing is cheap, it’s fast and it meets the learning objective. Many of the leading GUI
development tools (which I place in the high-tech category) still insist that a relational
database be installed prior to making windows which are capable of being reused in the
final application. This dependency on tables drives up the cost of making changes to the
prototype as well as forces the creation of a database design at a time in the project when
the information model isn’t complete. While this approach may work on very small
applications, it doesn’t scale up to a cost-effective methodology for the larger projects.
The low-tech prototyping method minimizes the phenomenon called “pride of
authorship.” The longer a programmer is allowed to work on a design, the less likely he
will be willing to change it. The low-tech prototype ensures that very little emotional
investment is made before the product is ready to be reviewed and amended by the users
or the rest of the development team.
There are legitimate reasons for building a working, animated high-tech prototype.
A small, isolated construction effort can be very instructive if either the development or
the users have never before worked with a GUI application. In this situation, the con-
struction of the prototype should be treated as a research and development lab, with clear
learning objectives and a scope limited to one small piece of the system. The goal is to
get developers and users familiar with the target environment, so in the future, they can
recall the abstractions without having to build every piece of the product in order to
understand it.
For creating cheap, low-tech prototypes, any drawing tool, or even a word processor
can do a reasonable job of imitating a window layout. Project teams have very successfully
created templates for objects such as scroll bars, title bars, menus, buttons and fields, mak-
ing it easy to cut and paste together a new layout in a matter of minutes. Once several win-
dow templates have been created in the chosen tool, it is very easy to copy them for
subsequent windows, ensuring a common layout pattern throughout the application.

WHERE DO WINDOWS COME FROM?

Structured software engineering methodologies have been plagued in the past with a deep
chasm between analysis and design into which many projects have fallen, never to emerge.
I prefer to view the transition from analysis into design as a gradual gradient, in which the
ISBN: 0-536-56083-8

Specially prepared for d03063582

models become more design-like with each decision made. The interface prototype is the
first step into the realm of design. To begin the prototype, we turn to our analysis models.
Windows are the physical manifestation of the stimulus and response flows from the
business events for which you have chosen to implement using a graphical user interface.
The first step is to decide which events lend themselves to a GUI. You can start by revisit-
ing the context model. Now that you understand a great deal about your system, you are
ready to entertain ideas about the physical transport of data into and out of your application.
Using the context model as a graphic aide, examine the stimulus, response and
external agents for each event. Consider whether the interface should be on-line, direct
to a printer or fax machine, to an electronic data interchange, to another database or to
some other means of transport (Figure 6–1).

Figure 6–1. A context diagram, annotated with transport mechanisms

The context model declares the interface boundary. You will have to design a trans-
port mechanism for each stimulus and response which crosses the boundary. The data
which crosses the interface is declared in the event model by the stimulus and response.
The organization and definition of that data can be found in the information model.

THE PROTOTYPE BEGINS THE MAN–MACHINE DIALOGUE

Imagine that we have been hired to design an automated teller machine. (Assume that
none of us have left our cubicles for twenty years, and have therefore never seen a cash
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

machine.) We have some sketchy analysis models of the business problem, and have
been asked to transform them into an interface prototype. Figure 6–2 depicts the event
dictionary entry for Bank customer requests withdrawal.

Figure 6–2. Event Dictionary entry for Bank customer requests withdrawal

Our project’s technical director has read an article about client/server computing and
come up with the bright idea of strapping a monitor, keyboard and mouse to the side of the
bank. With our brains in the “off” position, we can create a prototype window to recognize
this event simply by arranging the stimulus data elements in the window workspace. The
response data will be returned to the user via a printer, therefore no significant response
ISBN: 0-536-56083-8

Specially prepared for d03063582

data is needed on the display. The illustration below shows the results of our design mas-
terpiece. Does this prototype satisfy the essential requirements as defined by the analysis
models? It appears that it does. Is the prototype design any good? No, it’s rubbish!

The analysis models cannot be mechanically transformed into an interface prototype

without any additional brain-wave activity. The essential models are silent about the
intended user’s level of expertise. In the case of our cash machine interface, it is unlikely
that the typical bank customer will take the time to type their account number, account type,
PIN and withdrawal amount. Many of the bank’s customers don’t know how to type at all.
Real-world automated teller machine designers are confronted with a quality vector
that insists that the interface must be usable by any customer from age five to one hun-
dred and five. To accommodate this requirement, the designers have to break the essen-
tial stimulus flow into a series of dialogues. Most modern cash machines have taken the
decomposition of business events into dialogue to the logical extreme. They request one
data element at a time, followed by an editing activity and a system response prompting
for the next data element. Each fragment of the dialogue is an event in its own right.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Bank customer requests withdrawal =

Bank customer inserts account card
Bank customer types PIN
Bank customer selects account type
Bank customer indicates withdrawal amount

The level of granularity of these events is driven by design considerations, and the
entire suite of events in the dialogue is required to satisfy the single business-level event.
For this reason, an event dictionary entry for each dialogue event is overkill. The interface
prototype becomes a superior visual aide. Figure 6–3 shows a reasonable prototype for
the event Bank customer requests withdrawal, based on the intended user’s skill level.

Figure 6–3. A prototype respecting the skill level of the intended user

The point of this example is to illustrate that the interface prototype is a design
activity. It is very difficult to avoid usability issues once you start laying out windows.
Be mindful of the analysis prototype’s prime directive to derive and validate the essen-
tial requirements. You will need to address a certain portion of usability issues so your
prototype won’t be summarily rejected by your users, but try to keep your design options
open. As we will see later in this book, there are a wealth of considerations that go into
a well-crafted interface that are deferrable until the detailed design stage. These include
determining the user’s appropriate unit of work, window type, navigation, and the points
at which work must be committed to the database.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Grouping Events by Subject

Events can be used in a variety of ways to guide the prototype. An event list can be sorted
or grouped by transporter, or subject. This technique gathers together all of the events for
which a particular user group is responsible. Figure 6–4 is a subset of the many events
initiated by a doctor in a family health clinic.

Figure 6–4. Events grouped by transporter

Traditionally, many systems have been designed following a company’s traditional

organizational structure. The sales module included the order entry functions, the patient
history section would include medical records, the accounting module would contain the
financial reports, and so on. Given the list of events initiated by the doctor in Figure 6–5,
how many “modules” must the doctor delve into?

Figure 6–5. Events in their traditional “modules”

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Organizationally structured systems assume that people’s job descriptions are par-
titioned neatly along political boundaries (Figure 6–6). The interface is structured
accordingly. Each window is typically located in one place in the application, for
instance, the daily reservation schedule can be found only under the Reservations icon
on the main menu. The reservations application also includes all functionality required

for creating, modifying and canceling reservations.

Figure 6–6. An organizationally-structured application

One strategy to control user access in an organizationally structured application is

to deliver the same application to everybody, but vary their access depending on their
authority to initiate various events. This is the most common implementation in the
client/server environment because it makes version control very easy when everybody
has the same software. The downside is that a single user, such as the doctor, has to
become familiar with several major subsystems in order to find the windows they need.
Problems arise in organizationally structured applications when the users’ actual job
activity strays outside of traditional political boundaries. This is becoming a more com-
ISBN: 0-536-56083-8

Specially prepared for d03063582

mon occurrence in today’s “empowered” enterprises. An alternative to organizational

structure is to package windows together into applications which are targeted to specific
event initiators (Figure 6–7). The major advantage of this method is that the user gets one-
stop-shopping for the events in which they are responsible. In addition, the size of the
application is physically smaller, and the user does not need to learn how to navigate
unused portions of the application. The downside is that the on-going version control of
software upgrades will have to manage the building and distribution of multiple and dis-

parate executables to different client sites.

Figure 6–7. An application organized by transporter

We will continue to see that design is full of trade-offs and compromises. Group-
ing events by transporter helps the designer prototype different organizations for the
same application, ranging from traditional functional decomposition to heterogeneous
packaging based on individual user needs.
Grouping events by initiator, (e.g., “customer”) can also be very revealing. By
determining the ultimate source of the data, you may be able to extend your data capture
or response presentation outside of the traditional organization, and all the way to the
customer. Creative examples include electronic ticketing in airline applications, subways
and rail stations, and placing orders via the Internet.

Grouping Events by Object

One of the most powerful ways to consume an event model is to group events by object.
The syntax of an event name is Subject-verb-object. The object represents the real world
thing upon which the event is visited. Take our venerable old event, Customer places
order. The object Order may be represented in the data model by multiple entities. In
Figure 6–8, we see a typical data structure for Order, where a customer can place orders
for multiple products and request one or more deliveries of those products over time.
Please recognize that the word object is severely overloaded in our industry. Object
(or more precisely class) can be a representation of a single entity type, or an abstraction
which represents multiple entity types, or even has no representation in the information
model. It can also be a wide variety of programming constructs which are purely imple-
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

mentation-oriented. In the context of this chapter, the word object refers to the noun or
modified noun in the event name which represents a business abstraction, for which rel-

evant data may be represented within one or more entities in the information model.
Figure 6–8. An ERD of the Order

For projects which are targeted to fully object-oriented implementations, this group-
ing and examination of the event model, in conjunction with the information model is the
first step to discovering and cataloguing business classes in an object-oriented design. I
will defer a full discussion on this topic until Chapter 12, on internal component design.
Grouping events by object leads to the object-action paradigm. The object-action
paradigm is a shift in the overall design of user interfaces that has transpired over many
years. Early research into the usability of different screen designs revealed that it is more
intuitive and efficient when users first acquire an object on the screen, and then tell the
computer the action to apply. Early on-line programming languages often encouraged
the exact reverse. Figure 6–9 shows the main menu for an action-object implementation.
The main menu for a typical action-object application would have the user declare
the type of action they intend to take. They may type UO for “Update Orders” and press
Enter. The program would call up a blank order update screen (Figure 6–10). The user
would then identify the order they wish to update by typing a key such as the order num-
ber at the top of the screen and pressing Enter again. The screen would then retrieve the
order and they could get on with their business. This type of design supported an envi-
ronment where the user’s tasks were extremely repetitive. They could stay on the same
screen and enter orders all day, keying in data from stacks of input sheets.
Today, we recognize that most user’s jobs are more complex. By pushing automa-
tion out to the front lines of the organization, the repetitive motion of the data entry
departments of old have given way to the more random forces of the real world. Sales-
people receive calls from customers asking for new orders, changes to work in progress
and cancellation of existing orders. The object-action paradigm states that users should
ISBN: 0-536-56083-8

Specially prepared for d03063582

be able to select a list of objects from the database, highlight one or more of them, and
then specify the action that they want to invoke.

Figure 6–9. An action-object main menu

Figure 6–10. The Update Order screen

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Figure 6–11 shows a window which supports the object-action paradigm. The user
can enter various optional selection criteria at the top of the window which allows them
to retrieve a list of orders when they click the Find button. The list displays in the lower

portion of the window.

Figure 6–11. The Order Selection window

By clicking through the rows in the result set, they can select the object of their
desire. The command button line (or menu in some applications), contains all of the
actions that are capable of being invoked from this window. The user first selects the
object, then applies the action. To update an order, the salesperson simply finds the order
on the list, and clicks the Open button. The Order Maintenance window then opens,
with the data prefilled from their selection (Figure 6–12).
The graphical user interface also supports an important extension to the object-
action paradigm. When the user has selected the object, the interface is sufficiently intel-
ligent to inform them which actions are legal at any point in time based on the user’s
authority and the current status of the object. Command buttons and menu items are rou-
tinely disabled (grayed out) on the interface when the action is illegal for the selected
object. This can be a daunting task to program and virtually impossible to test for cor-
rectness without a state-transition diagram.
Figure 6–13 shows a list of events which have been grouped by object. The object
of the event can usually be determined by simple inspection. Often, events will affect
ISBN: 0-536-56083-8

Specially prepared for d03063582

more than one object. A far more rigorous approach is to produce an event/entity CRUD
matrix to determine which entities are affected by each event; however, this level of

Figure 6–12. The Order Maintenance window

Event name Transporter Object

Customer places order Sales rep. Order

Customer modifies order Sales rep. Order

Customer cancels order Sales rep. Order

Prod. dept. allocates order Production mgr. Order

Trans. dept. books order Marine booking rep. Order, Booking

Plant ships order Shipping clerk Order, Shipment

Sales mgr. requests order report Sales mgr. Order

Customer inquires on order status Sales rep. Order

detail is not always required.

Figure 6–13. Events grouped by object
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
USING THE INFORMATION MODEL TO LAY OUT WINDOW CONTENT 177

A sensible method for getting started on a prototype for these events is to first exam-
ine the transporter of the events, and then examine the object. We can see in Figure 6–13
that the sales representative is responsible for entering, updating and canceling orders, as
well as answering customer inquiries. We may also find that the sales manager is an occa-
sional user of the application, and nine times out of ten, he asks the sales representative
to pull reports for him.
Since each of these events is transported into the system by the same user group,
and affects the same object, they are likely candidates to be grouped together in the inter-
face. Using the object-action paradigm, we can give the sales representative a window
on which he can acquire a list of objects from the database, and initiate these events for
the selected items.
In the prototype, we would expect to see a layout of an Order Selection window on
which the user may browse multiple instances of orders, and as many Order Mainte-
nance windows as it takes to capture the information about a single instance of order. In
the analysis phase, the prototype can safely defer detailed design issues such as the final
navigation, window type and whether the user may have multiple orders open at one
time. These issues should be addressed in a design prototype after the essential content
of the interface has been validated.

USING THE INFORMATION MODEL TO LAY OUT

WINDOW CONTENT

The information model is a critical guide to window layout. The organizational map of
the data is dictated by the relationship cardinality on the entity-relationship diagram. If an
order can have multiple order items, one for each product ordered, then one would expect
a classic header-detail relationship on the order maintenance window (Figure 6–14).

Figure 6–14. The information model guides the data layout on the interface
ISBN: 0-536-56083-8

Specially prepared for d03063582

If there is room to display both entities on the same window, then the order entity
can be arranged at the top, and a grid style section can display each instance of order item
in the lower portion of the window. If there are too many attributes to fit comfortably on
one window, then multiple windows will have to be employed to display the information.
For updatable fields, avoid at all costs using scroll bars to view fields which have
been hidden to the right or bottom of the window. Users often reject scrollable windows
which have updatable fields hidden from view (Figure 6–15).

Figure 6–15. Improper use of vertical and horizontal scroll bars

Vertical scroll bars are best employed for large lists where more rows are
returned than can fit on the screen. Horizontal scroll bars should be reserved also for
non-updatable lists when the number of columns returned exceeds the width of the
display. When using horizontal scrolling lists, it is a polite practice to use grid-style
windows which allow the users to rearrange their columns to their specifications and
save their format to a local file (Figure 6–16).
Just like the consumption of any of the other models, the information model can-
not be consumed in an intellectual vacuum. Consider the following ERD fragment,
(Figure 6–17). An Invoice can have many Invoice items. The prototype designer has
dutifully translated each entity on the information model into a window. There is a win-
dow for Invoice Selection, Invoice Maintenance, Invoice Item Selection, and Invoice
Item Maintenance. The user’s first reaction to the application is that it takes too many
windows to get to the Invoice Item Maintenance window. The analyst reminds them that
the purpose of this prototype is just to validate content, and not to address navigation,
but the users are concerned and won’t let it drop.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
USING THE INFORMATION MODEL TO LAY OUT WINDOW CONTENT 179

Figure 6–16. Proper use of vertical and horizontal scroll bars

Figure 6–17. An ERD fragment from an invoicing system

Even though final navigation decisions will be deferred until the detailed design
stage, it is OK to diffuse the situation in analysis by demonstrating the many ways nav-
igation could be handled. The users may be assuming a single threaded navigation from
window to window (Figure 6–18).
The analyst should ask, “How many invoices have more than one item on them in
reality?” If the users indicate that a majority of invoices have only one item on them, then
the designer can help them skip a screen. The information model simply states that more
than one item is allowed. It does not address the norm.
When the user clicks the Invoice Items . . . button on Invoice Maintenance, instead
of blindly retrieving the Invoice Item Selection window, the system could first count the
instances of Invoice Item. (This SQL statement proves to be fairly fast.) If the system
returns a count of “one,” the application opens the Invoice Item Maintenance window, if
the system counts more than one item, the user is presented with a list of items from
which they may choose one. Figure 6–19 shows the streamlined navigation.
ISBN: 0-536-56083-8

Specially prepared for d03063582

The analyst may also determine that a significant number of invoice inquiries are
made at the invoice item level, not the invoice header. The Invoice Items . . . button
could also be placed on the Invoice Selection window, allowing the users to bypass the
Invoice Maintenance window entirely and go straight to the item level.

Figure 6–18. Single thread navigation

Figure 6–19. Navigation paths for single versus multiple-item invoices

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Graphical user interfaces allow for such a vast array of navigation designs. This is
why I insist on keeping my options open while I’m still gathering and validating require-
ments. If you find yourself faced with a group of users who are hung up on navigation,
demonstrating multiple navigation paths for your proposed window layouts will often
assuage their concerns. It will also elicit important design considerations that can be used
later, and will help to get the users back on topic.
The information model is a critical guide to window layout. It provides a map of the
cardinality between data groups. In addition to the data’s structure, the interface designer
also needs to understand the real-world statistics behind the cardinality to avoid creating
interfaces that force users to follow the rare exception paths, instead of the norm.

REQUIREMENTS TRACEABILITY

As business events are allocated to windows, an event/window matrix can be created to

provide a traceability document (Figure 6–20). Events are listed down one axis, window
titles across the other. An “R” is placed in the matrix for the window on which the event
is first recognized. An “A” is placed in the matrix for additional windows used to support
the activity of the event.

Event/Window

Customer places order

Credit dept. approves order
Prod. dept. assigns order
Plant fills cust. order
Plant ships cust. order
Acctg invoices cust. order

Figure 6–20. An event/window matrix

For events triggered by other methods, such as the receipt of an EDI transmission,
the appropriate interface object name can be indicated on the same axis used for window
object names. This document provides users, trainers and testers with an index to the win-
dows which initiate and execute business events. It also provides a test for completion of
ISBN: 0-536-56083-8

Specially prepared for d03063582

the preliminary interface design activities and assures both users and managers that all
chartered events have been accounted for. The manager can also use the completed win-
dow count to make estimates for the design and implementation effort required to com-
plete the project. If your model also includes an event/entity CRUD matrix, then a
window/entity CRUD matrix can be derived, showing which windows need the data ser-
vices for each entity.

KEEPING THE MODELS IN SYNC WITH THE PROTOTYPE

The interface prototype is a model which needs to be kept in sync with the other mod-
els. When new events are discovered during the prototype review, they should be added
to the event model. Errors found in the model for existing events should be corrected.
Data elements not represented in the information model should be added, and attributes
found to be in the wrong place should be moved to their proper entity.
CASE tools could go a long way to taking the drudgery out of keeping models in
sync. A CASE tool should treat a business event as an independent object, capable of
having properties and relationships to other objects in the CASE tool repository. The
CASE user should have the ability to model the stimulus and response for each event
graphically as a portion of the information model. For each attribute, the tool should
allow the analyst to specify default label names for use when the attribute is displayed in
a free form field or in a columnar format.
The creation of a candidate window layout should be as easy as selecting an event
or list of events and declaring that they should be recognized on a window. With the
event model and information model already linked, the CASE tool already knows which
attributes need to be captured on the display, and also knows the relationship between
the entities represented. It should provide, at minimum, a list of known attributes that the
designer could drag onto the window layout, or better yet, generate a preliminary layout
based on the stimulus and response attributes, and the cardinality between their entity
types (Figure 6–21). If the designer drags an attribute from the header area of a window
into the detail area, the tool should be polite enough to ask if they’d like to move the
attribute in the underlying information model as well. CASE tools will never be able to
read our thoughts. The preliminary design generated by a computer might look a lot like
that dreadful cash machine interface at the beginning of this chapter. It would, however,
give the designer a starting point, and provide much needed traceability and balancing
capabilities between the various models.
CASE technology has alleviated many of the mundane activities of system devel-
opment such as drawing graphics and generating database schema. As of this writing,
they have a long way to go in terms of helping us create interface prototypes in the analy-
sis stage, as well as modeling business events in a distributed business environment. In
the absence of the CASE tool of our dreams, the analyst still has the responsibility to
manage these tasks the old fashioned way.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Figure 6–21. The relationship between events, entities, and window layouts

USER REVIEW TECHNIQUES

Prototypes can be instructive to build, but their real value is realized when they are
reviewed with the intended users. Inform the users of the specific learning objective prior
to walking them through the prototype. It is best to review the prototype in person so you
can witness the users’ reactions. Don’t fall into the lazy trap of simply mailing analysis
documents to the users and requesting their approval within a stated time frame. Even if
your users are geographically remote, a variety of technologies such video conferencing,
remote PC links or even the good old telephone can be employed to help the team review
the product together.
Many projects are very successful at reviewing paper prototypes without incurring
the cost of having to build a working, coded product. Using an overhead projector with
the window layouts printed on transparencies, the users are invited to use colored pens
to simulate data entry. As they fill in the fields, the analyst can indicate which data ele-
ments will be free-form entry, on drop-down lists or selected from pop-up windows.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Most users will be able to validate window content and ensure you have captured the
events properly using this low-tech method of prototyping. Any detailed design sugges-
tions made during the session are written down for later consideration.
Even detailed design issues such as navigation, ergonomics or ease of learning an
interface design can be tested on paper. One technique is to give the user no prior training
on how to use the interface. The user then fills out the interface design form and “clicks”
buttons with a pencil. The facilitator lays a new layout in front of the user to simulate a
window opening. By observing the subject attempting to use the interface, the designer can
see where the interface is intuitive and where the user has trouble. Changes suggested by
the user in a debriefing can be quickly made to the paper prototype and retested.
A good prototyping technique for reviewing navigation is to tape pictures of the
window layouts to a white board (Figure 6–22). Using the event model as a guide, the
designer walks the users through each business event which uses the various windows.
By using colored dry-erase white board markers, the users and designer trace the navi-
gation paths between windows for each major event. By seeing all of the candidate win-
dows at once, the users gain an appreciation for how much data is involved, and can
make relevant suggestions as to the optimal way to navigate the application. If one sug-
gestion is ruled out, the path is simply erased from the white board.

Figure 6–22. A white board navigation session

The payoff for using low-tech prototypes is that most of the analysis and a lot of the
design information can be gathered without incurring the cost of building a semi-working
product. Low-tech prototypes are cheap to build and easy to change. When a product
undergoes several iterations of prototyping on paper prior to its initial construction, the
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

beta version of that product is far more likely to be closer to the mark. When reviewing
either low-tech or high-tech prototypes with your users, it is also important to implement
some level of version control so you can recover the last acceptable version if they don’t
like your latest ideas.

SUMMARY

A prototype is a model created to test some aspect of a proposed product design. Auto-
mobile designers don’t have just one prototyping session and neither should software.
Each prototype should have a specific learning objective. Once the learning objective has
been established, a good software engineer will look for the most expedient method of
deriving the prototype. In most cases, paper prototyping is still cheaper than incurring
the cost of building a working interface, even with today’s point-and-click GUI tools.
When development tools evolve to the point where meaningful prototypes can be derived
easily from abstract models such as the information and event models, then the cost
scales may tip in favor of animated, working prototypes.
The interface prototype can be used in the analysis phase of the project to validate
the information model and event model to ensure that the user’s requirements are ade-
quately understood. It can also be employed as a method for deriving the information
model based on the data the users ask for on the window. Inevitably, refinement of events
and discovery of new events also occurs during prototype review sessions with the users.
Prototyping will also surface business process issues, especially when the corporate
automation boundary is being pushed into areas that were previously the domain of man-
ual processes and personal computer desktop packages. It may also surface potential
technical issues, such as performance bottlenecks, while there is still time in the project
to do something to address them sensibly. Prototyping can also be used to explore the
look and feel of various different target environments without having to commit to a par-
ticular technology.
The event model provides a list of all events to which the system must respond. For
those events which are to be communicated to the machine via the on-line interface, a
prototype can be developed using the event model as the basis. Each event’s stimulus and
response contains the data elements that are required to pass across the interface. Addi-
tional display elements may be indicated in the activity section, and more data may have
to be displayed in order to make the interface polite, informative and friendly. Turning a
business event into a window or set of windows often involves breaking the essential
event into a dialogue between human and machine. The level of granularity of the dia-
logue will depend, to a great extent, on the capability of the intended user.
The event model is an important tool for organizing the user interface. Events can
be grouped by subject, or transporter, to create overall areas of one-stop-shopping for
users. Grouping events by object leads to the object-action paradigm. The user is allowed
to acquire a set of objects from the database, and then apply the desired action to selected
objects. The state-transition diagram is used to determine which actions are legal, based
ISBN: 0-536-56083-8

Specially prepared for d03063582

on the status of the selected object. An event/window matrix can be created to demon-
strate which windows are involved in the recognition and activity for each event.
The information model contains an organizational map of the data which will
appear on the interface. The relationship cardinality between entity types is used as a
guide by the interface designer to group data into header-detail relationships, and shows
which information can be successfully joined together on a window.
Interface prototyping starts the project down the path to design. The process
requires careful project management to keep it from careening out of control. After the
window content and business policy have been uncovered, subsequent prototyping
efforts can begin to focus on design issues. We will see in Chapters 10 and 11 that a host
of decisions confront the GUI designer. Detailed design prototyping sessions can be used
to evaluate window type, navigation, ergonomics, ease of learning, and the user’s appro-
priate unit of work.
Your project might choose to use low-tech paper prototypes in the analysis phase
to discover and validate requirements. During design, you might employ navigation dia-
gramming techniques (covered in Chapter 11) to prototype the organization of the appli-
cation on paper and review it with your peers. Many portions of the system may go all
the way through the external design stage without coding anything. Other parts may
require that you build a piece and show it to the users to get their feedback. Prototyping
can be used as a learning technique during many phases of the project. The most impor-
tant thing to remember is that you should identify the objective for doing the prototype,
and then select the method which best meets that objective in a cost-effective manner.
The prototype should always be reviewed with the intended user group. Face-to-
face walkthroughs are far more valuable to the development team than is communicat-
ing through the interoffice mail. Always inform the users of the purpose of the prototype,
and write down all of their comments, even if they pertain to deferred design issues.
After the walkthrough, it is the analyst’s responsibility to ensure that the analysis mod-
els are kept up to date with any new information discovered in the review.

EXERCISES
1. List the advantages of low-tech prototyping.
2. Why might you choose a high-tech prototyping method over a low-tech method?
3. Take a look at some of the legacy systems in your shop. Do they support the
object-action paradigm or the action-object paradigm?

ANSWERS
1. Low-tech prototyping methods, such as using a drawing tool or word-
processor to mock-up window layouts, have the following advantages over
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

high-tech methods, such as using the target GUI development tool to

“evolve” the application:
Low-tech prototypes are inexpensive to create
They can be created rapidly
They can be modified quickly
They engender low emotional commitment on the part of the developer,
making it easier for the author to accept constructive criticism
There is no danger that the development team will start hacking out the final
product before they understand the requirements.
2. A good time to use high-tech prototyping methods is when the use, applicabil-
ity or performance of the target technology is not well known, and building an
actual piece of the application can serve as an important proof-of-concept.
3. If your old systems have screens on which the user must first declare a “mode,”
such as insert mode, update mode, or delete mode, then proceed to a screen
which supports just that mode, then the design most likely is based on an
action-object paradigm. Old systems which allowed users to first retrieve lists
of database items, then apply a variety of actions to any given row that they
may have marked, were designed more from an object-action viewpoint.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Specially prepared for d03063582 on 12 Nov, 2010

WRAPPING UP THE
ANALYSIS PHASE

INTRODUCTION

Chapter 7 wraps up the analysis section of the book by introducing the topic of busi-
ness issues. The larger the project, the more likely you will encounter unforeseen
issues which could seriously impede your progress if left unresolved. The timely doc-
umentation and resolution of issues is key to getting through the analysis effort while
there is still time and money to deliver a solution. This chapter offers up some tech-
niques and advice on how to manage that effort. Finally, I close the chapter with a
brief summary of the analysis phase, and the models which comprise the analysis
deliverables.
ISBN: 0-536-56083-8

189

Specially prepared for d03063582

BUSINESS ISSUES

The last topic in the analysis section is uncovering and resolving business issues. Busi-
ness issues are questions raised by the project team that are outside of the realm of
automation. They are fundamental procedural or policy questions regarding how the
company intends to conduct business. Software does not exist in a vacuum. Instead, it
can be viewed as the automated center of a much larger system. Figure 7–1 shows three
concentric layers of a business system.

Figure 7–1. Software is the automated core of a much larger system

At the core is the software, reliably chugging away to fulfill its robotic duties. The
software is surrounded by a layer of manual procedures and business practices. This is the
non-automated processing that occurs outside of the system. The direct users of the system
inhabit this strata. It is because the manual procedure layer of the organization carries out
its duties in a consistent and standardized fashion, that we are able to exploit software to
take over more and more of the drudgery of daily business life. In a completely random
and chaotic environment, we would have a hard time automating anything useful.
The outermost layer represents the business policy. Policy and direction is set at
the highest levels of the organization. The mission and goals of the business provide the
reason why the business behaves as it does. The policy layer envelops all that goes on
within. Together the software and manual procedure exist to carry out what needs to be
done to execute the business policy.
Now, what does this have to do with analysis?
Client/server systems and GUI applications are often chartered to boldly go where
no system has gone before.1 They wrap or replace existing legacy systems, and then
extend the automation boundary outward to the very frontier of the business. If the
legacy system is simply replaced, the business may end up with GUI windows over a

1 Or “to go boldly,” for those of you who object to split infinitives.

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

formerly heads-down data entry system. This would annoy the data entry people tremen-
dously, since a GUI is likely to slow them down. Client/server moves the information
capture and presentation directly to the offices of the decision makers, sales force, pro-
duction workers and accountants.
One of the biggest hidden costs of client/server is the cost to re-engineer the busi-
ness. In the terms of the diagram in Figure 7–1, when the software boundary moves,
there must be changes in the manual procedure layer, and sometimes even in the busi-
ness policy layer. In the most successful client/server projects, the business has taken the
time to redefine its policy and procedures in anticipation of the new software boundary,
prior to detailed analysis and design of the software system. This strategy gets all of the
users aligned to the new business processes, with visible support from the highest levels
of the organization.
Unfortunately, not all shops are blessed with such visionary management. Often
client/server projects are started with less than full appreciation of the cultural changes
they will trigger. Such businesses pay a high price for their process re-engineering when
it is done concurrently or after an expensive software development effort.
When the analyst ventures out into Userland, he routinely is confronted with con-
flicting practices, unstated policy and divergent viewpoints on how business should be
conducted. The project charter may call for one consolidated source for customer infor-
mation, but the plant manager refuses to let the Neanderthals at corporate headquarters
update his customer records, and the high mucky-mucks at corporate headquarters are
indignant at the plant’s refusal to recognize their omniscience. This type of conflict is
typical. Where people and software meet, the analyst finds blurry, indistinct scope
boundaries, a wealth of previously undiscovered personal spreadsheets, divergent report-
ing requests and stakeholders vehemently defending their version of reality.
Issues which arise in the manual procedure layer and certainly in the policy layer
of the business are outside the analyst’s authority to resolve. It is absolutely the ana-
lyst’s responsibility to surface them! It is important that we separate in our minds the
responsibilities of an analyst versus a programmer. A programmer’s responsibility is to
write code which meets the specification’s requirements and is free of software bugs.
The analyst’s responsibility is to uncover business problems and define the require-
ments which will address them. It is OK for a programmer to ignore a business issue.2
Strictly speaking, it’s not their problem. It is professional malpractice for an analyst to
ignore a business issue!
The analyst is placed in a difficult position. He has the professional responsibility
to point out holes in the manual procedure and policy layer of the business that may pre-
vent the software layer from behaving effectively. He doesn’t, however, have the author-
ity to resolve those issues. That is why, as part of the project chartering process, the
business should establish a business issue resolution process.

2 This highly inflammatory statement is intended to draw a clear distinction between the role of pro-
grammer and the role of analyst. Even though these roles may be played by the same person on a
project, the responsibilities are vastly different.
ISBN: 0-536-56083-8

Specially prepared for d03063582

THE BUSINESS ISSUE RESOLUTION PROCESS

The project charter should contain the names of the user council. This team is comprised
of system users and their immediate supervisors. These are the best people to resolve
issues within the manual procedure layer, at the operational level of the business. By
solving their own problems, they are more likely to accept the solutions. For issues
which the user council is unable to resolve, or those which require a policy decision, a
steering committee is needed. The steering committee resolves issues at the tactical and
strategic level of the business. It is also the supreme court of issue resolution for opera-
tional issues that the user council is unable to resolve. Its members should contain pol-
icy makers and system stakeholders at the highest level of the organization who have the
authority to make key decisions.
It should be obvious that the steering committee should only be bothered with the
most broad sweeping issues such as, “Should invoicing be done at the production facil-
ities or consolidated at corporate headquarters?” The more mundane issues such as,
“Should the user be able to credit and reissue multiple invoices at once, or one at a
time?” can be left to the user council.
The analyst’s job is to document the issue and add it to the project’s centralized
issues list. The issues list is owned by the project manager. One of the jobs of the pro-
ject manager is to remove roadblocks which may impede his team’s progress. The pro-
ject manager is responsible for shepherding issues through the resolution process. This
involves convening the user council or steering committee periodically, and ensuring
that the business reaches resolution on each issue. This often involves a degree of polit-
ical wrangling and arm twisting.
The project manager will have much more leverage with the business if the
issue resolution process is in the project charter and the timely resolution of issues
identified as a critical success factor. At some point, if enough issues clog the
pipeline, the project manager can publish the fact that the project is dead in the water
until the business gets moving on its responsibilities.3 This will only work if the busi-
ness is educated about its role in a development project, up front. Otherwise, the man-
ager will look like an ineffective whiner, and the business may never resolve its
problems.
The analyst’s job is to provide the business with enough information about the
issue so those responsible can make an informed decision. For tracking issues, I have
found the following format effective. Some project management or defect tracking soft-
ware packages include similar data elements, or a simple application can be created
using any of the popular relational database products.

3 I have seen good project managers use various tactics, ranging from broadcast e-mail to posting a
list of unresolved issues and the people who are sitting on them in the lobby of the building.
Although extreme, public humiliation tends to elicit some action.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

BUSINESS ISSUE DOCUMENTATION

For each issue, the following information should be captured:

Tracking number: A sequential number is often used. The number serves as the
unique identifier of the issue.
Title: The title of the issue should be a short phrase which conveys the essential
meaning of the issue, often posed as a question, (e.g., “Should invoicing be consol-
idated at corporate HQ?” or “Will sales agents be willing to pull their own on-line
commission reports instead of receiving paper in the mail?”).
Author: The author is the name of the project team member who uncovered the
issue. This is usually the analyst.
Date discovered: This is the date on which the issue was uncovered.
Description: The issue should be explained in enough detail so that no other
research is required to understand the nature of the problem. I prefer to structure
the description of the issue as follows:
Background: This is the context of the problem. It is safe to assume that the
reader is familiar with the business, but may not have the same depth of detail
as an analyst who has been immersed in a particular subject area. Include a
brief synopsis of the functional area of the business in which the problem
exists and the portion of the application affected.
Problem: State the problem in clear, concise terms.
Impact: State the impact of doing nothing. If the problem is allowed to con-
tinue, what will be the result to the project and to the business.
Solution options and recommendation: Many people are not fond of mak-
ing decisions. Making choices is easier. It is very likely that the analyst
already knows what should be done, he just needs approval from a higher
authority to make the change. If there are several options, assess the pros and
cons of each one. Include a recommendation if you have a strong opinion.
Assigned to: Name the team or business individual to which the issue has been
assigned for resolution.
Date Assigned: Record the date on which the issue was forwarded to the resolu-
tion team.
Resolution: Document the decision made by the resolution team.
Date Resolved: Record the date on which the resolution was received by the
project team.
Resolved by: Sometimes the issue will be resolved by an authority higher than the
one to which it was assigned. It is useful to record whether the line-level clerks or
the company president made the decision.
ISBN: 0-536-56083-8

Specially prepared for d03063582

You may be experiencing a sense of déjà vu when it comes to the issue description.
The problem statement, impact of doing nothing and presentation of solution options
come straight from the decision-making framework presented in the charter chapter. In
fact, the analyst can strengthen his recommendation by evaluating solution options based
on the criteria laid out in the charter, namely, the ability to meet project objectives, cost
and application of the quality vectors.
One of the first things I ask for when joining a project is the issues list. In the
early analysis stages, a healthy project will have a rich lode of unresolved issues. This
is good! It means that the analysts are out there asking questions. If you were to track
the number of unresolved issues on a project over time, the graph should look similar
to Figure 7–2.

Figure 7–2. Outstanding unresolved issues

On the first day of the project the number of unresolved issues is zero. Nobody
has asked any questions yet. As the analysts go forth and analyze, plenty of questions
should arise which are written down as unresolved issues. On a healthy project, the
number of unresolved issues will climb rapidly. As the project manager guides the
unresolved issues through the resolution process, the number of resolved issues
should start to outnumber the unresolved ones. Eventually, the number of unresolved
issues should drop off as the business achieves a common vision of how their new
world will operate.
The crux of an analyst’s job is to ask questions, to write those questions down, go
find out the answers, and write the answers down. The answers will beget more ques-
tions, and each of those are written down. The objective is to get as quickly as possible
from a state of profound ignorance to a state of simple ignorance (Figure 7–3).
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

Figure 7–3. Moving from a state of profound ignorance to simple ignorance

In a state of profound ignorance, you do not know that which you do not know. In
a state of simple ignorance, you do know what you do not know. In less twisted words,
you cannot manage a state of profound ignorance, because you are completely blind to
the issues which may confront you. A manager in a state of profound ignorance comes
to work each day to find bombs exploding on all fronts of the project. A manager in a
state of simple ignorance has a list of the major issues that have been uncovered, and can
manage against that list. He can estimate how badly progress is impeded and develop a
plan to get the issues resolved.
The list of resolved issues becomes an important document for the training and
implementation phase of the system. The changes made in business policy and proce-
dures reflect the difference between the old way of doing business and the new. The
issues list provides a means for the project to remember why it did things the way it did,
and who was involved in the decisions. It is probably a safe time to start designing any
part of the system where the analysis models are reaching completion, and the resolved
issues are clearly out numbering the unresolved issues.

SUMMARY OF ANALYSIS DELIVERABLES

The purpose of analysis is to define the user’s essential business requirements. It is a

critical step to understanding the business’ needs prior to designing technical solutions.
The analysis phase of a client/server-GUI system includes the following activities.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Forge a charter with the business which articulates the goals and objectives of the
project in clear, concise, measurable terms. Make sure that both parties have reached
consensus on the objectives and have agreed to their respective roles and performance
requirements in writing.
Further define the scope of the area of study through creating a context model and
validate it with the appropriate user base.
Define the events to which the system is chartered to respond. Events are listed in
the event list and defined, in detail, in the event dictionary. For each event, the dictionary
entry includes the event’s meaning, stimulus data required to initiate the event, activity to
be carried out to formulate the appropriate response, and the response data which is
expected by the users. The effect of each event is documented to keep faith with what the
system is attempting to accomplish in the real world.
Create an information model which comprises all of the data elements that your
system is chartered to remember. The information model respects no project boundaries,
and therefore a strong sense of scope is required to determine which data elements are
relevant. The information model can be built through accretion by defining the data
required for each event’s stimulus and response.
Put a face on the system by creating an interface prototype. The prime objective
of the prototyping effort, in the analysis stages of a project, is to derive and validate the
essential system requirements while leaving your implementation options open.
Please remember that these steps are not necessarily lineal tasks. The best charter-
ing efforts I have seen were done in conjunction with a context diagram, event list and
first-cut information model. Without doing some preliminary modeling, there is nothing
upon which to base an estimate of the resources required to tackle the problem. It is also
unlikely that a project will nail down its information model and event dictionary to the
last detail without having done some sort of prototype.

HOW THE MODELS INTER-RELATE

The analysis models pull the business problem apart into three respective views; data,
process and behavior. The data requirements are modeled in the information model. The
process requirements are found in the activity section of the event dictionary. Appropri-
ate behavior is defined for the system in the event model by mapping the stimulus to the
desired response for each business event to which the system is chartered to respond.
These three views of the business are heavily interdependent (Figure 7–4). The
data requirements are the sum of the stimulus and response elements in the event model.
The processes only exist to provide the proper responses upon receipt of the stimuli. If
you change the scope of the project, you also change the events, processing and data
requirements. They are three views of an object, commonly called “the system.”
We have seen that the analysis models can be consumed to create a first-cut interface
prototype. The rest of this book will focus on the design effort, where the separate views of
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 12 Nov, 2010

the analysis models will be synthesized into a solution. The shape of that solution will be
dependent to a large degree on the chosen technology. Third generation language solutions
will have a clear separation between the process and data elements of the model, while
object-oriented languages will have a much tighter coupling of process, data and behavior.

Figure 7–4. The inter-relationship of the analysis models

As of this writing, most client/server projects call for a mix of approaches. Some
elements of the solution will be heavily object-oriented, while others may be 3GL or
4GL in nature, and the database is likely to be relational. The essential analysis models
detailed in this book provide the client/server system designer with the raw material nec-
essary to make sensible engineering decisions, and to exploit a wide variety of technical
paradigms.
ISBN: 0-536-56083-8

Specially prepared for d03063582

THE ARCHITECTURE
MODEL

INTRODUCTION

Chapter 8 takes a serious departure from the safe haven of analysis and examines how
to meet the project’s requirements with the sorry rabble of equipment provided by the
management. Architecture modeling begins by gathering statistics and constraints
about the events and information requirements you have documented during analysis.
The architecture modeler will need to know the rate at which the most significant
business events occur, and the response time expectations to which the new system
must conform. The information model is used to estimate the size of records and pre-
dict network traffic and database size for various configurations. The architecture
modeling phase makes key decisions about the geographic distribution of both data
and processes across the wide-area network. At a more granular level, the chosen pro-
gramming languages may influence whether a fat client or fat server approach is
ISBN: 0-536-56083-8

199

Specially prepared for d03063582

Practical Analysis on 16 Dec,
and Design for Client/Server and2010
GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
200 Chapter 8 / THE ARCHITECTURE MODEL

favored for the construction of the application code. You will find in this chapter that
there is no such thing as a perfect solution. Architecture modeling is all about mak-
ing trade-offs and compromises between sub-optimal solutions. By using the analy-
sis models to aid your efforts, you can choose the least objectionable technical
architecture through a process of informed consent, rather than by accident or the
time-honored technique of loud shouting and repeated assertion.

WHAT IS ARCHITECTURE MODELING?

The architecture model maps the essential requirements from the analysis phase onto a
technical architecture. Because so many different architectures are possible, the purpose
of the architecture modeling effort is to choose the optimal configuration, or perhaps the
“least worst.” The process of devising an architecture includes gathering data volume
statistics and event rates for the essential model, documenting the geographic topology
of the business, determining the geographic distribution of computing sites, determining
the local partitioning of process and data within each site, and validating the architecture
against the essential model.
Up until now, I haven’t addressed the issue of hardware. In the essential requirements
phase, we allow ourselves to bask in the luxury of assuming infinitely fast processors and
infinitely large storage capacity. We make this assumption about perfect technology so we
don’t cast our statement of the business problem in the form of a solution. Now it’s time
to figure out how this perfect model is going to run on the sorry collection of boxes that
management has given us.
It is unlikely that you would get this far into a project without addressing some
aspect of architecture. The reason that the chapter appears at this point in the book is
that you can’t put it off any longer. The reward to the procrastinators is that you now
have far more information on which to base your decisions than you would if you
tried to make architectural decisions without the benefit of a model of the business
requirements.
This chapter is all about trade-offs. It is not my intention or desire to discuss the
gory details of stringing together one type of hardware configuration versus another. For
that task, I regret I must leave you to sort through the opinions of other authors, jour-
nalists and the claims of the vendors. Instead, I will focus on how to use the essential
models to help you make rational architectural decisions by balancing the requirements
of the business against the constraints of the available technology. Today, this is no easy
task. In the future, perhaps advances in technology will lower the barrier of constraints
imposed by technology’s own limitations, and architectural modeling may someday
become irrelevant. The propensity of software to absorb quickly any improvements in
computing capacity, however, makes this rosy scenario unlikely.
Architecture modeling is the allocation of the essential requirements model to spe-
cific technology. The architecture modeling effort determines which processes will run
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

on which processors, where the data will be stored, and how much communication is
required between processors. It is a major leap into design. At the end of the architecture
modeling effort, the team will have determined:

the geographic distribution of computing requirements,

the hardware components for the client machines,
the hardware components for the server machines,
the configuration and number of client/server hardware tiers,
the network communication mechanisms and languages,
the operating systems,
the development paradigm (object-oriented, 4GL, 3GL or mixed),
the presentation language,
the background coding languages,
the database management system,
the location or locations of the processes,
the location or locations of the physical data,
and the synchronization strategies for geographically distributed data.

Many of these decisions will have been made already, either by management fiat,
or by the fact that hardware or standard shop languages already exist. For the lucky few
projects that have complete control over their choice of architecture, the architecture
modeling phase becomes a global quest for the most appropriate technology, based on
the requirements of the essential model. For the rest of us, architectural modeling is a
search for the least objectionable way to meet the business requirements, recognizing the
limitations of what we’ve been given to work with. In other words, it’s an attempt to
squeeze ten pounds of requirements into a five pound box.

OVERVIEW OF THE CLIENT/SERVER ARCHITECTURE

Before launching into a long diatribe on client/server architecture modeling, I feel com-
pelled to attempt to further define the term “client/server.” The problem with coming up
with a precise definition is that client/server is yet another one of those overloaded words
in our industry. It is important that we all share the same view of the term for the remain-
der of this book, even though the definition in your shop may vary slightly. For this book:

Client/server computing is the cooperative processing of business informa-

tion by a set of processors in which multiple, geographically distributed
clients initiate requests that are carried out by one or more central servers.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Primarily, client/server is used to describe software which executes on more than

one piece of hardware in order to accomplish a business task. Hardware separation is the
norm for client/server applications, although some have used the term to describe dis-
parate software components communicating with each other while running on the same
box. The distance between remote processors varies from computers which are located
in the same room or building, to those which are located in different buildings, different
cities, or even flung across the entire planet.
Today, the different processors are typically a hybrid of types, meaning that a dif-
ferent type of computer is used for the client machines than is used for the server machine.
This potpourri of hardware can be compounded when a wide variety of client machines
must be accommodated. A heterogeneous mix of desktops, workstations, laptops and
palmtops can seriously complicate the client side of the equation.
The idea of client/server computing is to treat a computer like an appliance. Each
appliance in a professional kitchen is capable of doing many things, but a master chef will
allocate each machine to its most propitious use. For instance, it is possible to cook a
piece of toast in a large convection oven. A toaster, however, does a far more reliable job,
takes less skill to operate, and requires less power to run. Mainframe computers are very
much like the convection oven. They are big and powerful, but require a great deal of skill
to operate, and are overkill for a wide variety of mundane requests. Personal computers
are far better at managing presentation, take less user skill to operate, and provide cheap
and efficient processing for many of the ancillary tasks of the organization.
Now, imagine the users as patrons in your information restaurant. They order up a
new report which requires a mix of graphics and data. In the mainframe environment,
the programmer would have to don an asbestos suit and venture into the convection oven
to fulfill the request. In the client/server world, the requisite data can be sent off to the
PC toaster, where the user can decide whether to top their toast with jelly, marmalade, or
fresh strawberries. From the users’ point of view, they don’t care on which appliance
their toast was cooked. From the master chef’s point of view, the appropriate appliance
is allocated to the task without bothering the user with the details.
Client/server applications seek to balance the desire of the users to have their toast
and eat it too with the chef’s need to keep control over the central kitchen. The client ini-
tiates requests from the server, much like our restaurant patron making demands of the
waiter. The server manages requests from multiple clients, delivering the appropriate
response back to each client machine, much like the waiter taking orders from multiple
parties and servicing requests from a single kitchen.

CLIENT/SERVER HARDWARE TIERS

The most common use for client/server architecture is to exploit the power of the PC for
managing the graphical user interface, while still protecting the integrity of the business
data on a central host machine. The overriding concern to the user is that the applications
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

appear seamless, so users remain blissfully unaware as to which processor is working at

any given time. In its least complicated form, client/server architecture involves multi-
ple clients making requests of a single server (Figure 8–1). This model shows a two-tier
hardware architecture.1
The client machine meets the demand for a helpful, friendly, courteous and kind
user interface. This demand has probably always been with us. It is just recently that the
technology has begun to catch up with the need. Our new challenge is what to do with
the rest of the PC’s vast processing potential. It’s a no-brainer to decide to move the pre-
sentation management portion of the application to the client, but what about the rest of
the application?

1 The word tier originated as a way to describe levels of hardware, although it has been also used by
some authors to describe layers of software (e.g., the presentation layer, business logic layer and
data management layer have also been called the presentation tier, etc.). To avoid confusion, I will
make every attempt to reserve the word tier for describing levels of hardware, and layer to describe
levels of software.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 8–1. A two tier client/server architecture

Information is one of any company’s key assets. Keeping control over the data
asset is far easier if you can corral the data into one place to resolve redundancy and
ensure periodic back-ups. It’s another no-brainer to decide that at some point, data
should come back to the safe custody of one or more central servers, but what about the
location of data at run time?
There are no easy answers to these questions. Before we explore the possibilities,
let’s complicate matters once again by introducing more tiers into the client/server
architecture. Figure 8–2 shows a three tier client/server architecture, in which client
machines are connected via a local area network to a local application server, which in
turn communicates with a central database server.
In the three-tier architecture model, the lines between client and server begin to
blur. The PC which hosts the interface application is certainly a client, and the central
database host which houses the data is certainly a server, but what about the local appli-
cation server? It’s sometimes a client and sometimes a server, depending on the direc-
tion of communication. Let’s compound the issue further by allowing the PCs to connect
directly to the database server, bypassing the local server. How many tiers do we have
now (Figure 8–3)?
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

Local application server Central server

Figure 8–2. A three tier client/server architecture

Figure 8–3. An n-tier client/server architecture

ISBN: 0-536-56083-8

Specially prepared for d03063582

The n-tier architecture is quickly becoming the norm in most organizations as local
area networks, wide area networks, the Internet and the World Wide Web are all linked
together. The distinction between strict client and strict server is almost obliterated in
such an environment, making client/server more of a conceptual pattern that is applied
on a transaction by transaction basis at run time.
For the sake of simplification, much of this chapter will assume a two tier
client/server architecture, where multiple PC clients make requests from a central data
server. This will allow us to explore some of the most common and fundamental char-
acteristics of the client/server environment without splitting hairs over terminology.

CLIENT/SERVER SOFTWARE LAYERS

In order to discuss the deployment of software across a multi-tier hardware architecture,

we must first dissect the software application into its layers. The innards of a business
application can be grouped into at least three major categories; the presentation layer, the
business logic layer, and the data management layer.2 Figure 8–4 shows a business event
as it passes through the three layers of a software application.

Figure 8–4. Software layers

2 When you deploy an application across multiple hardware tiers, you incur a fourth software layer,
that which manages machine-to-machine communications.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

The presentation layer resides at the edge of the software system. Its job is to cap-
ture external event stimuli and perform some degree of editing on the incoming data. It
also is charged with presenting the event response to the outside world. The presentation
software is almost always located on a client machine, such as a PC, however, this is not
a strict rule. PCs can be used to emulate mainframe screens with very little of the pre-
sentation logic resident at the client. The language paradigm of the presentation layer is
increasingly object-oriented. The windowing environment of most client operating sys-
tems lends itself naturally to object constructs.
The business logic layer contains the code which executes and enforces the pol-
icy of the business. Rules and regulations, as well as the internal calculations are all
found in the business logic layer. Software which executes business logic is the layer
which is most mobile. It can be located on the remote clients, the central server, or any
place in between. Many of the pros and cons presented in this chapter focus on the
location of this layer of the application. As of this writing, the language paradigm for
the business layer is a mixed bag. The trend is a movement toward object-oriented
constructs. The degree of object-orientation employed in the business logic layer is
heavily dependent on the chosen language or development tool. It is entirely possible
to have 3GL, 4GL and object components mixed within the same application.
The data management layer provides access to the corporate data. It manages
concurrent requests to read and write to the database, as well as the synchronization of
distributed data elements. Much of the data management layer will follow the physical
location of the data. The decision to distribute or centralize the database will determine
much of the location of the data management layer. For most business systems, the data-
base paradigm of choice remains the relational database. Most data collected by busi-
nesses fits nicely into the column and row format of the relational paradigm. Relational
database vendors are also responding to pressure to extend their databases to handle
unstructured data such as multi-media, sound, video and hypertext objects.

FAT CLIENT, FAT SERVER

A somewhat politically incorrect term has cropped up that is used to define an appli-
cation’s philosophy regarding where the bulk of the business logic layer of the appli-
cation lies. Fat client (thin server) means that the lion’s share of the software is
executed on the client machine, and the server is relegated to slavishly doling out data
upon request and mindlessly stuffing it back into the database when instructed to do
so by the client.
Fat server (thin client) describes an allocation of duties in which the client is
restricted to the presentation of the interface and minimal editing, while the majority of the
business logic and rule enforcement is executed on the central server. Of course, this is an
overly simplified view of the world, since n-tier client/server architectures can support
vastly complex software layers with fat deposits all over the network, but the term does
help us to recognize the philosophical leanings of a particular programming language.
ISBN: 0-536-56083-8

Specially prepared for d03063582

The first generation of many popular client/server-GUI development tools assumed

a two tier hardware architecture when they were first developed. The earliest versions of
packages such as PowerBuilder® and Visual Basic® absolutely encouraged a fat client
approach (Figure 8–5). The business logic was inextricably tied to the presentation layer
of the application. Through the introduction of object-oriented concepts such as inheri-
tance (covered in Chapter 12) many of these tools have been very good at exploiting the
reuse of object constructs which manage the presentation of the interface.

Figure 8–5. The fat client approach

Responding to the demands of the marketplace for more flexible development lan-
guages, the second generation of GUI development tools recognizes the need to separate
presentation from business logic. This partitioning provides several advantages, reusability,
portability and maintainability. The most widely promoted reason is reusability. Presenta-
tion classes are extremely easy to reuse because they are very mechanical in nature.3 Busi-
ness classes, on the other hand, are highly complex. A business class, such as Customer,
plays many different roles within the organization. The goal is to create classes which
enforce all of the business rules for a particular business class, and also to be able to reuse
that code any place in the application which deals with the class. In order to achieve reusable
code in this layer, a high degree of software engineering discipline is required.
ISBN: 0-536-56083-8

3 The word class, here, is used to mean a class of objects in an object-oriented system.

Specially prepared for d03063582 on 16 Dec, 2010

Portability is a second compelling reason for separating code which manages pre-
sentation from code which executes business logic. Once severed from the interface,
the business logic code can be relocated in various tiers of the client/server architecture
in order to achieve optimal performance. The ability to move business logic around the
client/server architecture enables the business to take advantage of improvements in
processing speed of particular machines, and to supplement the hardware architecture
with a faster component, without having to rewrite large sections of the application
(Figure 8–6).

Figure 8–6. Business logic moved from client to a file server

A third reason for corralling business logic into its own set of classes is to attempt
to keep the business rules in one place, rather than scatter them like buckshot across the
interface. The big pay-off of this strategy is the reduction of the ripple effect of making
maintenance changes and enhancements to the system.
The trend in development languages is to allow the project to balance the demands
of the application against the hardware architecture. Whether the resulting deployment
resembles fat client or fat server should be a product of sound engineering decisions,
based on the project’s quality vectors, and not a result of the constraints of the chosen
development language. It is important to recognize the bias of your chosen development
language and make sure it fits with the needs of the essential requirements.
ISBN: 0-536-56083-8

Specially prepared for d03063582

GATHERING STATISTICS AND CONSTRAINTS

Determining the correct architecture for your system involves sizing the computing
capacity to the problem. The essential analysis models provide a reliable framework for
estimating the computing requirements of the finished system. The first act of architec-
tural modeling is to fill in that framework by counting things.

Gathering Statistics for the Information Model

Two essential pieces of information are required to estimate the size of a database; the
size of the columns, and the number of estimated rows that will accrue over time. These
are relatively simple numbers to come up with. To determine the size of the data
columns, refer to the data type that has already been recorded for each attribute. Simply
add up the number of bytes for each attribute in the entity, and then add the number of
bytes for the primary key, and foreign keys implied by the relationships. (We will cover
the translation from information model to relational database in Chapter 9.) This yields
a very close estimate of the number of bytes that a single table row in the database will
occupy. A reasonably good CASE tool should be able to do this for you.
The next statistic needed is the number of expected rows for each table. Some enti-
ties will result in the creation of control tables, such as State, County and Country. The
number of instances in these entities are relatively fixed, unless the business expands
into new market regions, or global conflict alters the geo-political landscape. If your
enterprise is only interested in fourteen counties, then one would expect fourteen rows
in the county table.
It is far more interesting to estimate volume for the transaction tables. These tables are
created from entities such as Order, Order item and Invoice. The event model can tell us
which events create an instance of these entity types. In Figure 8–7, we see a fragment of
the information model. In this example, the event Customer places order always creates one
instance of Order. To find out how many orders come into the system, we need to know how
often the event occurs. Let’s say that the users tell us that they receive 100 orders per day,
five days a week. The order table is going to get about 500 new rows each week.

Figure 8–7. ERD fragment for Order and Order item

What about Order item? Note that the cardinality between Order and Order item
is one-to-many. We know that the event which creates an instance of Order must create
at least one instance of Order item, but the model doesn’t tell us how many instances of
Order item is the norm. We have to do some more research. We might take a look at the
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

existing database, a sampling of customer orders, or talk to the order-takers to find out
how many products a customer typically orders at one time.4 We may find that the aver-
age order has three instances of Order item. Given this information, we can estimate that
the system will add about 1,500 new rows to the Order item table each week.
The last piece of information required to estimate the number of rows in a table is
the retention period for the oldest row. If the company has a requirement to keep orders
on-line for two years, then the average number of rows in the Order table will be:

500 rows per week x 104 weeks = 52,000 rows

By using the attribute data types, and primary and foreign key estimates to deter-
mine the length of each row, we can now estimate the total size of the order table. Let’s
say each row works out to be 500 bytes. The Order table will occupy about 26,000,000
bytes or 26 megabytes of disk space.
Using our example from above, if a row in the Order item table is estimated to be
about 300 bytes, then the total size of the order item table will be:

1500 rows per week x 104 weeks x 300 bytes per row = 46,800,000 bytes total

The order table and order item tables will occupy approximately 26 megabytes and
47 megabytes, respectively.
Gather the following statistics for each entity in the information model:

1. estimated length, in bytes, of one instance of the entity (calculated by adding up

attribute data types and adding in size estimates for primary and foreign keys),
2. event rate for how often a new instance is created,
3. retention period.

When the information model is used to generate a relational database schema, you
will already have the volume estimates for the table sizes. The estimated length tells you
much space is required by one row. The event rates tell you how often new rows are
inserted, and the retention period declares how long you must keep a row before archiving
it off-line.
The statistics that are gathered for the information model are used to estimate the
resources needed to adequately house the database. Even if disk space is not a problem
for your project, the statistics will also be useful for working out other issues. The busi-
ness events that the system handles need access to the very same data. As we will see in
the following sections, the problem gets more complicated when the physical data repos-
itory is geographically remote from the event that needs that data.

4 Be careful when gathering this type of statistic if the legacy system you are replacing is not prop-
erly normalized. When you ask an order entry clerk how many items a customer requests per order,
he may say “one,” since that is all the old system will accept.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Gathering Statistics for the Event Model

The system is constantly being bombarded with business events. Some events are far
more critical than others, in that the ability of the system to respond rapidly is of para-
mount importance. The event model can be annotated with statistics that capture the rate
of the event and the desired response time for the event.
A little common sense can go a long way in terms of how many statistics you take
time to gather. The events which affect the mainstream transactions of the business are
the most critical. Events such as Customer places order, Passenger books airline ticket,
Time to invoice order, Train approaches station, Customer inquires of order status, Bro-
ker places stock trade order, Plaintiff files civil suit, are the meat and potatoes of their
respective businesses.
If an event such as Trucking company changes address occurs about once every two
years in your area, it probably doesn’t need intense scrutiny. A blanket benchmark for per-
formance can be stated for most of the mundane events which simply update control tables.
For the major business transaction events in your system, you need to collect the
average rate of the event, the peak rate and the peak time period. Let’s take an example
from Joe-Joe’s Pizza Delivery Company. Joe-Joe delivers pizzas out of several kitchens
which are distributed across the greater metropolitan area. To order a pizza, his cus-
tomers call one central hot-line. Pizza orders are automatically dispatched to the kitchen
nearest the customer, to ensure that a piping hot pizza is delivered on time to the cus-
tomer’s door.
Joe-Joe has built a reputation based on good food and fantastic service. Sixty per-
cent of Joe-Joe’s customers are return customers, and that percentage is growing. Most
call from home or from their car phones, so he has installed caller identification software
to search the database for their customer profile as the incoming call is received. By the
time the customer service rep picks up the call, the caller’s prior pizza ordering profile
is already on the screen. Joe-Joe is considering allowing customers to place orders
directly from their home computer via the Internet.
The most significant business event for Joe-Joe is Customer places pizza order. In
Joe-Joe’s case, he sells an average of 875 pizzas per day between the hours of ten in the
morning and two o’clock the next morning. It is fairly easy to do the math and determine
the average event rate is around 55 pizzas per hour. It takes approximately two minutes
for a customer to place a pizza order. With a new order coming in every minute, one
could extrapolate that Joe-Joe needs a system capable of answering three phone calls
simultaneously (one in-coming, one in progress, one hanging up). But is there anything
wrong with this? Such an ill-conceived system would probably put poor Joe-Joe out of
business in less than a month!

Irregular Event Rates

Average event rates can only tell you the normal level for an event. We also need to know
the peak rates. As you may have suspected, Joe-Joe’s customers don’t order their pizzas in
a uniform pattern from morning until night. There is very little activity before 11:30 AM,
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

then there is a big spike as the lunch crowd descends on the city (Figure 8–8). Business
drops off after 1:30 PM, then quickly accelerates at the five o’clock hour, and then trails off
again after nine at night. To complicate matters, the ordering pattern varies on Friday, Sat-
urday and Sunday. Friday’s evening spike lasts a lot longer into the night, as does Satur-
day’s. Saturday and Sunday have much smaller lunch peaks, but steadier business through
the late afternoon.
Number of pizzas ordered per hour

Figure 8–8. Event rate pattern for Customer places pizza order

Sizing the System for the Peak Rate

Joe-Joe has a critical architectural dilemma. Should he size the system to be able to han-
dle his highest peak so that no customer ever gets a busy signal or languishes on hold?
If he sizes for the peak capacity, then he has unused capacity sitting idle for a great deal
of the day. If he sizes the system for less than the peak capacity, he may have customers
who will turn to his competitors for their dinner.
These decisions are not easy, and should not be made by IT alone. The example of
Joe-Joe’s Pizza illustrates an irregular event pattern in which the customer is a major
player. If the system can’t handle the peaks, then the customer is impacted. Unless the
cost is prohibitive, most organizations will prefer to spend the money to size the system
close to the peak to avoid inconveniencing or losing customers.

Move the Peak

Some companies have come up with creative solutions in an attempt to smooth out the peak
in some event rates. Some stock brokerages charge their customers a higher commission to
move their stock trade orders into the priority queue during peak hours. Customers who
ISBN: 0-536-56083-8

Specially prepared for d03063582

don’t want to pay the surcharge allow their trade to wait in the regular queue until the com-
puter is available. The phone company does similar load leveling by charging higher long
distance rates during business hours, and discounting rates during evenings and weekends.
It not only makes good financial sense for the phone company, it encourages customers to
make their discretionary calls during off-hours and lowers the number of lines needed to
manage peak periods. Our friend Joe-Joe, however, may not be so lucky. People tend to
want their pizzas at meal time, so he would be hard-pressed to offer a discount that would
persuade customers to eat dinner at three in the afternoon.
You do not have to go hog-wild collecting event rates for the entire system. Concen-
trate on the major business events with the highest volume, largest amounts of data, most
geographically remote locations, and largest customer impact. For each of these events,
determine whether the event rate is uniform or irregular. For uniform rates, the average
event rate will suffice. For irregular event patterns, you must determine the peak event rates
over time and involve the business in the decision of whether to size the system for the cur-
rent peak traffic, for something less than peak, or for a peak that might even grow.

Event Performance Requirements

In Chapter 2 (project charters) we discussed quality vectors. One of the recurring qual-
ity vectors for information systems is immediacy of response, more commonly referred
to as response time. The requirement for the maximum acceptable response time needs
to be stated on an event-by-event basis. You may already have a target benchmark stated
in the project charter. If not, you need to know what the target is for the most critical
events in the system.
Again, a good dose of common sense is required. The team should concentrate its
efforts on the most important business events, those which occur most often and impact
the customer or users the most. Response time can be measured either at the business
event level or the dialogue level. At the business level, the response time metric mea-
sures time between receipt of the initial stimulus to the issuance of the final response. At
the dialogue level, the response time metric measures the time it takes the system to
respond to a single query, which might be just one portion of a whole business event.
For example, in a customer service department, the most important metric may be
time spent responding to each customer’s call. If the goal of the system is to cut the aver-
age call time by fifty percent, then the response time is measured from the time the cus-
tomer calls, to the time he hangs up. The actual response time of the system to return a
single query is just one part of the total transaction time. The designer has a number of
creative solutions at his disposal. One option might involve bringing back more infor-
mation about the customer onto the screen, so that the service rep makes fewer individ-
ual queries against the database. The response time of the initial query might be longer,
but the total average response time for the business event might be reduced. Another
solution might be to optimize certain windows to quickly return the most frequently used
queries. By training customer service reps to use the special window for those queries,
the average call time may be reduced without having to speed up the rest of the system.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
DETERMINING GEOGRAPHIC DISTRIBUTION REQUIREMENTS 215

When response time is expressed at the dialogue level, the designer is far more
constrained. In this case, the business expects that the computer will respond within the
stated time for any of the queries or updates required to execute the business event. For
the architecture modeler, this means that the client needs rapid access to the data.
Other events, such as Time to run monthly closing, have immense processing needs.
These events do not necessarily affect customers directly. CPU-intensive monthly closing
routines are legendary in many companies. Lights dim within a ten-mile radius as the jobs
are run to post the month’s activity to the general ledger. Many companies have decided that
as long as their customers aren’t impacted, it is acceptable to have poor system performance
for the one or two days a month that it takes to close the books. In many shops, closing rou-
tines are run at night, in an attempt to move the peak resource drain into off-hours.
The event model can be annotated with statistics to record the average rate of the
event, peak rate patterns for irregular event rates, and the response time expectation for
the event, either at the business event level or the dialogue level. The next step is to
examine the geographic distribution of events. This will lead naturally to the required
distribution of data access. Together, the frequency of events, volume of data, response
time constraints and the geographic distribution of the business will form the basis for
determining an acceptable architecture for your system.

DETERMINING GEOGRAPHIC DISTRIBUTION REQUIREMENTS

In Chapters 4 and 5, I mentioned several matrices that can be used to map the essential
model onto the topology of business locations. These matrices relate each event and the
associated data entities to the location in which the event occurs. The purpose of this exer-
cise is to map out your organization’s geographic distribution of computing requirements.
Let’s take an example from the Nihilist Toy Company, manufacturers specializing
in particularly violent and offensive playthings. The firm was the brainchild of Billy Joe
Bobcat of Windy Hills, Nebraska, a man of questionable taste, who found himself unable
to locate toy weapons that would allow his eight- and ten-year-old sons to engage in real-
istic war games. Billy Joe’s early prototypes proved immensely popular with the local
grade school kids, but it wasn’t until the CIA placed an order for 30,000 units of the now-
famous “Pan-Continental Annihilator,” that the company was able to pull up stakes and
move to New York City.
Today, the Nihilist Toy Company has sales offices in London, Boise, Miami and
New York City. Figure 8–9 shows the geographic distribution of the major order fulfill-
ment events.5 Orders are accepted in each sales office, with three located in the United
States, and one in England. The New York City office serves as galactic headquarters for
the operation. Their central credit department must approve each new order before it is
allocated for production.

5 For this example, I am using conceptual level events. When mapping events to business locations,
the use of conceptual level events can be a convenient simplification.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Event/Business location

Customer places order

Credit dept. approves order
Prod. dept. assigns order to plant
Plant fills customer order
Plant ships customer order
Accounting invoices customer order
Marketing mails catalogue

Figure 8–9. Event/business location matrix

Toys are manufactured in two plants located in North Carolina and California. The
allocation of orders to a particular plant is determined in the New York office. The rout-
ing of an order to either plant is based on the size of the order, shipping logistics to the
customer and availability of inventory and raw materials.
Orders for Western and Eastern Europe, Mediterranean and the Middle East are
invoiced out of the London office. Orders for the Pacific Rim, Asia, South America, Cen-
tral and South Africa, Australia and North America are invoiced out of the New York
office. Twice a year, the company mails a new catalogue to all of its customers. Mailings
are done from the New York and London offices.
The event/entity CRUD matrix is derived from the activity section of the event
dictionary. For each event, the matrix indicates whether the system needs to create,
read, update or delete instances of the named entity. In Figure 8–10, we see that the
event, Customer places order, can create an instance of Customer, and read or update
the Customer entity.6 It also creates an instance of Order and Order items.
Reading through the matrix, we see that the event, Credit department approves order
has the ability to update the Customer entity, reads and updates the Order (to set its status
to “approved”), and reads information from the Order item (most likely the price). The
event, Production department assigns order to plant, reads Orders, Customer shipping

6 This example has been simplified for teaching purposes. On a real project, the Customer entity
would likely be represented by several entity types, including subtypes, supertypes and attributive
entity types which make up the customer. The project may choose whether to create matrices using
discrete entity types from the information model, or aggregate them into conceptual objects, if they
are utilized by the event as a logical unit.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
DETERMINING GEOGRAPHIC DISTRIBUTION REQUIREMENTS 217

addresses, each plant’s Finished goods inventory and Raw materials inventory, and creates
one or more Plant orders and Plant order items, scheduling the production and/or delivery
orders in the plants. It also appears that the event reserves either finished goods or raw
materials by creating Inventory transactions. Inspection of the other events in the matrix
reveals their respective data access requirements.

Event/Entity

Customer places order

Credit dept. approves order
Prod. dept. assigns order
Plant fills cust. order
Plant ships cust. order
Acctg invoices cust. order
Marketing mails catalogue

Figure 8–10. Event/entity CRUD matrix

From these two matrices, a third matrix can be derived. Once you know the geo-
graphic distribution of events, and each event’s data access requirements, then you can
derive the geographic distribution of data access requirements, the business location/
entity CRUD matrix (Figure 8–11). This important matrix tells you exactly which
business locations need create, read, update and delete capabilities for each entity in
the model.
We now have a model of the data access requirements for each business location,
against which we can begin assessing potential architectural solutions. Before we lock
the data centralization fanatics and the data distribution fanatics in a room to shout each
other down, a few statistics can help either faction defend its case.
Each business will have different utilization patterns for its system. That is why
there is no universally “correct” architecture. The architectural solution which emerges
for our Nihilist Toy Company example is appropriate for them only because it takes into
account their unique geographic distribution, data volumes and event rates. Before dis-
cussing the pros and cons of centralized versus decentralized solutions, let’s find out a
bit more about our purveyor of fine toys.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Business location/Entity

Figure 8–11. Business location/entity CRUD matrix

The matrix in Figure 8–12 shows the intersection between events and entities. But
instead of indicating create, read, update or delete in the cells, a number is inserted to
show how current the data must be for the event. For those entities which are created or
updated by the event, a zero indicates that the database must instantly reflect the most
recent update. For entities which are read by the event, the number may be higher than
zero, indicating that it is acceptable for the data to be slightly older. A currency matrix
can be misleading, and really requires some narrative background before it makes sense
to the reader.
In this example, we have discovered that although the production department reads
the customer’s Shipping address in the process of assigning orders to plants, it doesn’t
care if the address is one hundred percent correct. Production’s reasoning is that ship-
ping addresses rarely change so dramatically that producing a customer’s order on one
coast of the United States versus the other would be affected. The business has also
informed us that the shipping address plays a minor role in the allocation of orders to
plants, and that frequently a customer’s order may be split, with portions manufactured
at both plants.
Once the plant has received the Plant order, subsequent changes made to the Order
or Order item are not immediately relevant. Customers rarely cancel orders after they
have been scheduled for production. If a customer cancels an order at the last minute, the
plant managers have found it more cost effective to let the day’s production run as sched-
uled and place the product into finished goods inventory than to interrupt production.
Therefore, they need up-to-date plant orders, but the customer’s master order can be up
to one day old.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

Practical Analysis and Design for Client/Server and GUI Systems, by David A. Ruble. Published by Prentice Hall,
a division of Pearson Education, Inc. Copyright © 1997 by David A. Ruble.
DETERMINING GEOGRAPHIC DISTRIBUTION REQUIREMENTS 219

Event/Entity

Customer places order

Credit dept. approves order
Prod. dept. assigns order
Plant fills cust. order
Plant ships cust. order
Acctg invoices cust. order
Marketing mails catalogue

Figure 8–12. Event/entity currency matrix (in hours)

When the marketing department sends out catalogues, they do a mass mailing
using the Purchasing address for each customer. Unlike the event, Plant ships customer
order, marketing is willing to accept data which is up to two days old. The cost of mail-
ing a catalogue to the wrong address is insignificant, whereas the cost and customer
impact of mailing the order to the wrong address can result in the loss of a loyal cus-
tomer. Statistically, customers don’t change their addresses often enough to warrant real
time updates.
Figure 8-13 shows a different view of the currency requirements. In this matrix, the
currency for each entity has been aggregated for each event which takes place at a busi-
ness location. We see that the 48 hour currency tolerance for the marketing department
in New York City has been lost in this view because they are located at a site where other
departments require instantaneous (less than one hour) updates to customer records.
Even the plants, who can tolerate customer information which is one day old for pro-
duction, require rapid notification of changes to shipping addresses when the order is
ready to ship.
We really seem to have painted ourselves into a corner with this view. It appears
that every location needs its data to be up-to-date within the hour at all times, even
though individual events at those sites can tolerate data which is slightly less than fresh.
This viewpoint is too generalized to reveal the fact the only certain attributes (or
columns, if I may switch to the physical vernacular) are needed to be updated or even
accessible at certain locations.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Business location/Entity

Figure 8–13. Business location/entity currency matrix

Figure 8–14 shows a matrix of the customer attributes and business locations which
need access to them. Customers are created and maintained at the sales offices, with the
exception of the Credit limit and Credit standing, which is maintained at the New York
office. Customers tend to order through the sales office closest to them, however, there
are a few national and international customers who may span multiple sales zones.

Business location/
Customer attributes

Figure 8–14. Business location/customer attribute CRUD matrix

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

Whether you need to analyze data distribution to the attribute level in your organi-
zation will depend on the complexity of your problem, and the span of your geographic
distribution. Now let’s take a look at the various strategies for ensuring each location has
the timely data access they require.

ONE CENTRALIZED DATABASE

The first solution option to consider for distributing data is to not distribute it at all. Only
one master copy of the data is kept at a central location, and all applications which need
access to that data must make their queries and updates to the central server (Figure 8–15).
The benefits are numerous:

It is easy to back up your data when only one copy exists.

The design of the overall system is less complicated, e.g., security is enforced
centrally, no synchronization routines are required.
The data is always current.
No data is ever redundant across business locations.

The downside can be significant in a geographically remote application deployment.

As of this writing, many data communication technologies are still not fast enough
or cost effective for large scale, geographically remote applications. The data vol-
umes and event rate statistics that you gather, when compared to the communication
capabilities of your network, can tell you whether remote data access is feasible.
You have a big problem if the central server or the communications lines go down.
Your remote sites will effectively be without a computer.

Unacceptable performance, and risk of down-time are the two leading factors that
cause businesses to steer away from centralized databases.

REPLICATED, DECENTRALIZED DATA

On the other end of the spectrum, the database can be completely replicated at all sites
that need it (Figure 8–16). Updates to one site can be broadcast to other sites on a real-
time basis. Using this strategy, there are some obvious benefits:

The design of local applications is simplified by having access to local data.

The response time for each transaction isn’t burdened by wide area network traffic.
It promotes local ownership of the data, and provides easy local access.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 8-15. One central database

The downside involves many complications:

The overall traffic on the wide area network is increased due to replication of the
data to all sites.
Complex synchronization software is required to keep the various copies of the
database updated.
Problems can arise if the same record is updated in two places. These can be exac-
erbated by time zone differences.
If one of the servers goes down, or the replication software fails, it can be difficult
to rebuild the data sets and apply updates in the right order.
Which database is the master? Backup procedures become more complex.
Completely replicated data may incur needless data redundancy.

Fragmentation
A compromise is often struck between severe centralization and completely replicated
decentralization. The distribution of the data is optimized so that only the data which is
needed by each site is made local. This is called fragmentation. There are several strate-
gies and more jargon associated with this technique.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

Figure 8–16. Replicated decentralized databases

Vertical Fragmentation
Vertical fragmentation occurs when only certain tables or columns are physically dis-
tributed to remote sites (Figure 8-17). Each location has only those tables or columns
that are needed by the events which occur at that site. This reduces the wide-area net-
work traffic because only the necessary data elements need to be synchronized with
other sites. The downside is that this strategy can be very complex to manage. The
replication procedures must be able to synchronize updates on a column-by-column
basis to different sites.
Many companies already have a version of vertical fragmentation which has
occurred more by historical accident than by design. The corporate systems were con-
structed separately from the manufacturing systems. Both systems carry some of the
same attributes about the customer and order, but many of the other columns are dif-
ferent. Unfortunately, the columns which should be the same, often are not. They vary
in both data type and data value. The same customer is represented in both systems,
but with different identifiers, sometimes even different names. As many firms try to
integrate their operations, they face the daunting task of consolidating and reconciling
historically fragmented records which were never designed to be electronically linked.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 8–17. Vertical fragmentation

Horizontal Fragmentation
Horizontal fragmentation occurs when only certain rows in a table are physically dis-
tributed to remote sites (Figure 8–18). This is typically employed when locations have
their own customers which do not do business in other locations. In our example of the
Nihilist Toy Company, each plant would receive only its own plant orders, and not the
orders allocated to the other plant.
With horizontal fragmentation, each location has a complete copy of the database
schema. All of the table structures are identical in each location, but the rows of data
which populate those tables can be different. Usually, there is a master database which
contains every row. Like vertical fragmentation, horizontal fragmentation cuts down on
the overall wide-area-network traffic by eliminating needless data transfer. It does, how-
ever, complicate the synchronization process somewhat. Problems can arise when loca-
tions share some rows. For instance, if a customer does business in two sales zones,
which one “owns” the customer’s record?
There is no easy answer. If both physical locations have their own copy of the record,
you will have to manage updates made at either location to keep the data in sync. You may
elect to keep only one “official” copy of the row and make one location go out over the
network to retrieve the customer from the office in which it is “most used” or “last used.”
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

Figure 8–18. Horizontal fragmentation

Mixed Fragmentation
Vertical fragmentation occurs when sites have different columns and/or tables, but the
same rows. Horizontal fragmentation occurs when sites have the same columns, but dif-
ferent rows. Mixed fragmentation occurs when both conditions exist. The distributed
databases share the same logical entity types, but have different columns and different
rows (Figure 8–19).
Mixed fragmentation strives for the ultimate in distributed data optimization. Each
site has only those columns and only those rows which are actually needed by events
which occur at that location. Taken to an extreme, mixed fragmentation can be very dif-
ficult to manage. Usually, some number of columns and rows which are not necessarily
needed at a site are allowed to be replicated in a mixed fragmentation scheme to ease the
burden of managing the replication process.

SUMMARY OF GEOGRAPHIC DISTRIBUTION

The essential models created during the analysis phase provide a wealth of information
for determining the geographic distribution requirements of your system. We started by
gathering statistics in order to determine the overall size of the database. This is done by
determining the record size in bytes for each row, the rate at which rows are created, and
their retention period. This information is critical, not only for determining disk require-
ments, but, when data is physically distributed, the record size and event rates will
ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 8–19. Mixed fragmentation

enable you to estimate your network traffic. Statistics captured for the event model
include the average rate of the event, peak rate patterns for irregular event rates, and the
response time expectation for the event.
Armed with these statistics, the next step is to apply them to the site topology of
the business. Several matrices have proven useful for modeling this aspect of the system.
The event/business location matrix maps events onto the business location in which they
are recognized. The event/entity CRUD matrix, derived from the activity section of the
event dictionary, summarizes the data access requirements for each event. The business
location/entity CRUD matrix is a derived matrix which shows which business locations
require what kind of data access, based on the fact that specific events have been allo-
cated to those sites. These are the most useful and important matrices for declaring event
distribution, and deriving data distribution requirements.
Once the business requirements for data access have been determined, additional
information will help the project team make sound architectural choices. The
event/entity currency matrix and business location/entity currency matrix show how
“old” an entity may be for any given event and business location. This can help you
decide whether real-time synchronization of distributed data is called for, or whether a
batch update routine will suffice.
Given the size of your data records, the rate of events which create, read, update
and delete those records, and the distance between business sites, the team can now
explore their architectural options. Data distribution strategies vary anywhere from
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

complete centralization to complete distribution. For enterprise-wide systems, you are

more likely to employ some degree of vertical, horizontal or mixed fragmentation.
What ever choices you make, the essential models of analysis allow you to engineer a
solution based on balancing the needs of the business with the constraints of your cho-
sen technology.
Once the project has determined the wide-area, or global distribution, it is time to
focus on the local area issues of a client/server system.

DETERMINING LOCAL DISTRIBUTION REQUIREMENTS

BETWEEN CLIENT AND SERVER

Once you have determined what data must reside locally, within the reach of a local area
network, it is time to tackle the many issues which arise when multiple computers are
employed to perform tasks within a geographic site. Just like the wide area distribution
decisions that we just covered, there is no “right” answer for the allocation of process or
data to a client, departmental server, mainframe or mini-computer server. If one could
reduce architecture modeling to a bumper sticker, it might read:

Every solution has a problem.7

Every possible deployment of our “perfect” essential model to the imperfect

world of technology will have some downside. The purpose of the rest of this chapter
is to point out the trade-offs which arise when you move parts of the application from
the desktop computer to the server, or vice versa. By understanding the trade-offs, you
will be able to make sound engineering decisions by evaluating the impact that any
potential architectural scheme may have on your ability to live up to the business
requirements.
Many development languages and tools have a predisposition toward either fat
client or fat server deployments. As coding languages become more portable, we will see
less of this phenomenon. Let’s start by looking at the pros and cons of a fat client versus
fat server application.

Pros and Cons of Fat Client versus Fat Server

Fat client applications are those in which the bulk of the processing is done locally, usu-
ally on a desktop PC. Most of the popular GUI development tools positively encourage a
fat client application since their scripts were designed specifically for the PC. In Figure
8–20 we see a transaction as it passes through a typical fat client architecture.

7 An old Ruritanian folk saying, unearthed by Meilir Page-Jones.

ISBN: 0-536-56083-8

Specially prepared for d03063582

Figure 8–20. A transaction in a fat client architecture

The data capture and editing is done on the client. If the user makes an error, he is
immediately informed. The interface application edits immediately for proper data type,
date and numeric ranges, and valid values for restricted lists. The client application also
enforces a wide variety of business rules. This involves giving the user visual cues to dis-
tinguish between optional and required fields based on the status of the object being
updated. The application also uses the status values and knowledge of the user’s level of
authorization to turn on and off command buttons and menu items.
An extremely fat client application will also execute any calculations that need to
be performed, in lieu of using stored procedures on the server. The server simply
receives data and instructions to either create, read, update or delete values in specific
tables. The database management system, residing on the server, enforces referential
integrity, user authority, correct data type and required fields; however, all of these fac-
tors have already been edited by a well-crafted fat client application. On the outbound
side of a transaction, say a query, the data is sent from the server back out to the client
where it can be sorted, filtered, formatted and displayed to the happy user.
Now that I’ve painted the fat client scenario, let’s pick it apart to expose its strong
and weak points. It’s pretty obvious that the client machine must be capable of putting
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

some sort of display on a monitor, so we can take screen presentation as a pre-ordained

duty of the client. Moving on to the editing, the decision to edit for proper data type at
the client is low cost, high pay-back. Any decent GUI development tool has the ability
to read the data type from the development database and provide data type editing at the
client without having to code it by hand. If field has a data type of date in the database,
then the client application should only accept valid date formats, and inform the user
promptly if he attempts to enter a value which doesn’t pass muster. A character field,
such as order status, may only have a restricted set of values. In this case, the presenta-
tion application should enforce the setting of the field’s values, either by setting it auto-
matically, or by allowing the user to select values from a list. This low-cost editing
prevents entry errors at the client from ever reaching the server.
Whether to locate a business rule on the client or server is not as clear cut. A sim-
ple rule such as “a price list’s expiration date shall not be less than its effective date,” is
a common cross-field edit in business applications. You could get all sorts of weird
results if you allowed the user to establish price lists that end before they start. Where
should this rule be enforced? On the client’s interface application, or on the server’s
database management system?
Both choices have their merits. To enforce the rule on the client, you might write a
line of code that is triggered when the user attempts to save his price list. (You could also
put the edit code in the expiration date field, to trap the error as soon as it occurs. How-
ever, be aware that when the user is armed with a mouse, he could enter the expiration
date prior to entering a start date, making an edit check at the field level tricky and poten-
tially annoying to the user.) By detecting the error at the client, the application is able to
give the user a chance to redeem himself before incurring the cost of sending the data over
to the server. There is a widespread expectation among GUI users that a modern interface
will contain such features, befitting that amorphous adjective, “user friendly.”
Enforcing this innocuous date rule on the client reduces the time it takes for the
system to inform the user that he has made an error. It reduces the potential network traf-
fic because it eliminates the need for the server to inform the client that bad data has been
received. On the other hand, by putting the business rule solely on the client, other appli-
cations which access the same data must include an identical rule to ensure compliance.
Herein lies one of the great dilemmas of a client/server architecture. Business rules
are designed to protect the integrity of the company’s information asset. The client soft-
ware needs immediate access to such rules to meet the expectations of a friendly inter-
face, but the data on the server needs to be protected from erroneous update by
applications which may be ignorant of the rules. If your database can be accessed by a
wide variety of applications (e.g., the ominous “end-user computing”), this will drive
you toward a fat server philosophy of putting business rules on the server, in either stored
procedures or custom code.
Heterogeneity of client hardware may also push a project toward a fat server imple-
mentation. Let’s say that the database server needs to be capable of fielding queries and
updates from workstations, laptops, palmtops, telephones and interactive television. There
ISBN: 0-536-56083-8

Specially prepared for d03063582

isn’t sufficient processing power on some of these devices to do any serious rule checking.
These types of constraints will lead you toward encapsulating your data on the server with
a layer of business application logic through which all transactions must pass to access or
update the data. Fat server applications have a maintenance advantage over fat client appli-
cations in that all of the rules can be found in one place, so are more handily modified.
Business logic which is scattered among different client applications can create a version
control and maintenance hassle down the road.
Before I start sounding like a fat server bigot, let me return the fat client camp
once again. Today’s users are simply not going to tolerate an application which slaps
them about the head for committing preventable entry errors. They expect the client
interface to be aware of the rules and guide them through the use of the application.
Today, this often results in coding the same rule in two places, once in the client soft-
ware to allow for immediate enforcement at the interface, and again on the server to
guard against a renegade insurgency from another application. Needless to say, no one
is very thrilled about this duplicity. Vendors are working hard to make their coding
scripts more portable, so at minimum, the business logic doesn’t have to be coded in
two different languages.
This problem of maintaining two sets of business rules is partially responsible for
the popularity of company intranet technology. The application code resides on the
server, and is accessed by the client at run time. The pay-off is one set of rules, but the
drawback, of course, is increased network traffic to the web server.
And what of object-orientation? Can OO help us meet the stringent demands of
the interface while still keeping the wagons circled around our data? I will cover object-
orientation further in Chapter 12, but we must delve into the concept here because it has
relevance to the fat client versus fat server debate.

Business Objects in a Fat Client Application

Much fanfare and hoopla has been made over the use of object-oriented coding tech-
niques to manage business rules.8 In brief, the programming construct wraps an object’s
data (known in OO jargon as variables) in a veil of publicly known procedures, called
methods, through which all access to the data is channeled. This is known as encapsu-
lation, meaning that if you want to query or modify the data in any way, you must appeal
to the object’s methods to do it for you.
Taking this idea and running with it, we can say “Let’s take all of the rules regard-
ing an Order and stuff them into an Order object and make all portions of our applica-
tion which deal with orders appeal to the order object to do their business!” (This is a

8 I must note, that much of what I’m about to say can also be achieved with good old structured design
and remote procedure calls. Object-orientation is not a prerequisite for solving client/server architectural
dilemmas. It is just one of many solution options to the problem.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

gross oversimplification of the process, I know, but this will suit our purposes for the
time being.) We certainly have the material for deciding what an Order object should
contain. The information model tells us all of the data that the business cares about for
each order. The event model, and specifically the event dictionary’s activity section, tells
us the procedural requirements for how to manipulate orders. To illustrate, if you were
to peruse an event model for a typical order fulfillment system, you might find state-
ments in the event dictionary such as:

If an order is canceled, the system must cancel all of the order’s pending
shipments.
If an update to an order’s requested ship date falls outside of the effective dates
of the attached price list, the order must be repriced.
All orders must have raw materials allocation prior to being scheduled for
production.
Vehicle ID is required for all orders shipped via rail car or truck. Vehicle ID is
not required for will-call orders.

These rules are far more interesting than our mundane date edit. Given these busi-
ness requirements, a user would be within his rights to expect the interface to behave
accordingly. If the user cancels an order, the system should acknowledge that his pend-
ing scheduled shipments are also canceled. If he extends an order’s ship date beyond the
period of the price list, the interface should tell him promptly and clearly that he needs
to reprice the order. If he doesn’t yet have raw materials allocation, the button or menu
item which schedules production should be turned off. Similarly, if he is shipping via rail
or truck, it should be visually apparent that the Vehicle ID field is required, and if the
order is for will-call pick up, the Vehicle ID field should be disabled or hidden.
By looking at the mapping of events to candidate windows in the interface proto-
type, we may find that various aspects of an order are modified on many, many windows
within the application. Focusing purely on the client side of an application, the idea of
employing object-orientation to manage business rules can be powerful. When an idea
as complex as a customer order is scattered about many windows, each window needs
access to the business logic which is germane to the tasks conducted therein. The user
should expect the rules to be enforced uniformly, no matter which window he is using.
A sound strategy is to partition code which controls the behavior of business classes,
such as Order and Customer, from code which controls the behavior of presentation classes,
such as Window or Button (Figure 8–21). By separating the business logic from the presen-
tation logic, the designer meets two objectives. The business logic now resides in one place
within the client application, yet is accessible to each presentation window that needs it.
Thus, the elusive “reuse” of the business class is achieved within the same applica-
tion by reducing the amount of redundant business logic code required to run the interface.
The ability to reuse presentation classes, such as windows, buttons and controls is also
increased, because these classes are unburdened with any knowledge of the business, and
ISBN: 0-536-56083-8

Specially prepared for d03063582

therefore can concentrate on what they do best, namely the mechanics of managing a
graphical interface. Many of today’s popular GUI development languages already support
this type of application partitioning.

Figure 8–21. Many windows appealing to the same business object

Business Objects in a Fat Server Application

Partitioning the business logic from the presentation logic on the client allows for higher
reuse and less redundant code, but it still doesn’t address the need to encapsulate data on
the server with the same business rules. To solve this problem, you need a language that
allows presentation objects on the client to appeal directly to business objects on the
server. This is managed with what is known as an object request broker (ORB). An
object request broker is an object which keeps track of the physical location of objects
which are deployed throughout a client/server architecture. When a presentation object,
such as a window, needs to appeal to the Order object, it sends its request to the object
request broker, which routes the communication to the appropriate machine on which the
target object is located (Figure 8–22).
Object request brokers make business logic portable. The big pay-off is that business
rules are made available to the client application, without having to physically locate them
on the client. This allows for the central maintenance of one copy of the business class, used
by all applications which require access to the data. Another huge benefit is that the busi-
ness logic can be moved from machine to machine, simply by moving the object and updat-
ing its location in the object request broker. This allows the system architect to take
advantage of new technology as it becomes available to the project, redistributing objects to
gain optimal performance without redesigning and recoding large sections of the entire
application.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

Figure 8–22. An object-request broker

Remember, every solution has a problem. The idea of distributing the business
logic to the server, and still having access to the rules at run time on the client is allur-
ing, but it comes with a price. The design assumes that the speed of the network between
client and server is sufficient to handle the additional traffic imposed by insisting that the
client go across the line to appeal to the server-based rules.
One-stop-shopping for rules about a suite of complex business objects requires
skillful design. No single window or application may ever care about an object such as
Order in its entirety. To have to instantiate the entire object on the client at run time and
populate it with lots of data from the server over a wimpy network is like trying to suck
an elephant through a straw. Complex business objects can be compared to the old fable
of the blind men and the elephant. The story goes something like this:

Three gentlemen who happened to be sight-impaired were introduced to a

pachyderm one fine day, for reasons which escape me. The first sight-
impaired gentleman touched the elephant’s trunk and proclaimed, “an ele-
phant is like one of those large vacuums that you rent at the car wash. I shall
use this elephant to clean my van pool bus.” The second man of limited vision
walked directly into the elephant’s flank. “I beg to differ with you!” he
ISBN: 0-536-56083-8

Specially prepared for d03063582

protested. “An elephant is like a large rubber wall. One can charge tavern
patrons a fee to bounce against it.” The third man, who really wasn’t entirely
blind, made straight for the elephant’s tusks, proclaiming, “Gentlemen, we
could make a fortune turning these into piano keys and decorative trinkets,”
upon which he was promptly arrested under the United Nations Endangered
Species International Accord for malicious intent to poach a protected animal.

Interface objects, such as windows which are designed to recognize specific busi-
ness events are much like the blind men encountering the elephant. A window which cre-
ates an order header may be interested in the credit standing of the customer, but may
not be interested in the level of inventory for the ordered product. A window which spe-
cializes in splitting a requested order into two separate shipments cares nothing about the
customer’s credit standing, but may depend entirely on the availability of transportation.
Each window only needs a portion of the order, much like the blind men require only a
portion of the elephant.
The moral of the story is that if your window only requires a portion of the elephant,
say a tusk, flank or trunk, then you need not burden the application with any knowledge
about the rest of the elephant. The presentation logic should only be aware of those fea-
tures of the object that are required for the job, and the business object should not encum-
ber the application with having to retrieve data it doesn’t need. The designer will, in many
cases, need to create services which access only the data required for each task.
Let’s look at where your business objects might reside at run time. One option is
to locate the business objects on the server. Any presentation object running on the client
must appeal to the business objects over the network, usually via an object request bro-
ker. The cost of this solution is increased network traffic.
If your network is unable to handle the messaging between presentation objects on
the client and business objects on the server, then another option is to instantiate busi-
ness objects on the client at run time in order to service the interface effectively, assum-
ing there is no appreciable impact on run-time performance to do so. In this solution, the
network still must be able to handle a stampede of data from the database required to
bring the objects to life. Remember, don’t pass the entire elephant across the network for
a window that may only require a quick look at the toenail.
A third option is to create two physical sets of the object classes, one on the server
and one on the client.9 The pay-off is that your business rules are resident on the client
once again for use by the interface, and an identical copy exists on the server, to protect
the data. The penalty is that, once again, we are back to coordinating two physical ver-
sions of the rules.

9 I am still assuming for the whole of this book that the system’s data is housed in a relational data-
base, and therefore, some portion of the runtime objects will still be responsible for the retrieval and
update of the data.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

This scheme is only feasible with languages with true portability between client
and server platforms, whether they are object-oriented or not. For development tools
with lesser capabilities, we will continue to find ourselves coding business logic in two
places to meet the user’s demand for visually apparent business rules on the interface,
and to meet the need to ensure safe custody of the corporate data.

REVIEW OF ARCHITECTURAL TRADE-OFFS

The following section briefly covers some of the many architectural trade-offs that must
be considered when designing a client/server system. I will state a quality vector, such
as rapid response time at client, then list the possible ways to achieve it.

Rapid Response Time at the Client

For systems that demand lightning speed at the client, there are several ways to avoid a
sluggish system.
If you have many concurrent users, a fat server application could bog down the
server with excessive processing demands. By purchasing very powerful client
machines, you can distribute much of the processing to the desktop. This reduces the
overall network traffic, eliminating many remote procedure calls. The cost, of course, is
that you pay top dollar for the latest client technology. Throwing hardware at perfor-
mance problems is often cost-effective. It is also important to ensure that there is a high-
speed network in place, and sufficient fire power at the server to reduce wait time.
Turning our attention to the data, other solutions include optimizing the database
through the use of indices or views to speed up queries on the highest volume transac-
tions. Some data with low volatility may be able to be cached either at the client or on a
local file server.

Heterogeneity of Client Hardware

Some businesses have a requirement that the application must run on any variety of client
machines, from a workstation to a laptop, palmtop or telephone. This will force the appli-
cation toward an extreme fat server architecture, to protect the integrity of the data. Appli-
cation program interfaces (APIs) will have to be built to allow different client applications
with various degrees of intelligence to access the server. For applications which run GUIs
on fairly intelligent workstations, you may encounter the demand that many of the busi-
ness rules housed on the central server also be resident at the client at run time.
For most of this book, I am making the bold assumption that the client hardware
is virtually identical for all client machines, or at least, the differences are managed by
the IT department. I have found through experience that the subtle differences between
ISBN: 0-536-56083-8

Specially prepared for d03063582

even different brands of personal computers can sometimes make the same client appli-
cation behave unexpectedly. The IT department must wrest control over the purchasing
and configuration of personal computers away from the business, and maintain a stan-
dard approved hardware configuration for the applications it creates or procures. This
includes setting guidelines for the use of a personal computer. It seems that every com-
pany has at least one errant manager who is famous for coming in on the weekend and
installing a copy of his kid’s “Galactic Vomitron Warriors,” which just happens to
reconfigure his system files, resulting in an angry call to the IT director on Monday
morning when his client application aborts after the sign-on window. Business people
who are unwilling to give up the historical PC “free-for-all” probably aren’t ready for
the discipline required for client/server computing. (See Chapter 13, myth #3: PC
stands for personal computer.)

Heterogeneity of Client Software

Not every user is responsible for the same business events, so not every user needs all
of the software you deploy. Assuming that there are many applications which run over
the same database, the designer has the choice of distributing one large application to
everybody or many smaller applications to only those who need them.
The second alternative has some advantages. When you break up a large client
application into several pieces, the client software occupies less disk space. When the
user requests enhancements to the software, you can isolate changes to a particular exe-
cutable. The pay-off is that you disrupt fewer users with a new software upgrade when
you release the enhanced application, and you need not test the pieces of the application
which are unaffected. The downside is that all of this partitioning has to be managed with
a rigorous version control and distribution process to ensure that IT is acutely aware of
what pieces of the application is on each user’s PC.
For businesses with a mix of applications sharing the same database, which may
be built by different groups within IT or contain some purchased packages, a fat sever
solution may be necessary to ensure that the data is adequately encapsulated with the
proper business rules.

Minimal Network Communication

Some sites may not have the network speed, due to either size or distance, to handle large
transaction volumes effectively. If this constraint exists, the system architects can turn
once again to the essential model for help. Taking the most critical and high volume
events, draw an event neighborhood data flow diagram for the event’s activity, showing
all process and data store access (Figure 8–23).
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

Figure 8–23. An event-neighborhood diagram annotated with statistics

Annotate the diagram with the event rates and the number of bytes represented by
each data flow. Armed with this kind of information, you can play “what if” games to
come up with a client/server distribution of process and data that results in the lowest
possible communication. Try separating the client from the server at the point of mini-
mal data flow. Try caching some data locally, at the client or on a client-site departmen-
tal server, to reduce the traffic to the central server. By using the model, you can simulate
transactions on an endless variety of configurations until you find one that will work.

SUMMARY

The purpose of architecture modeling is to use our knowledge of the essential business
requirements, combined with the constraints of available technology, to come up an ade-
quate distribution of data and processing to the various hardware tiers of the client/server
architecture.
The client/server software application can be broken up into layers. The presenta-
tion layer is used to manage the mechanics of the interface. The business logic layer con-
tains the code which enforces the business policy, as described by the activity section of
the event model. The data management layer manages concurrent access to the database,
as well as synchronization of distributed data. The term fat client (thin server) is used to
describe an application in general terms in which the majority of the business logic layer
executes on the client machine. Fat server (thin client) describes an application where
the lion’s share of the processing occurs on the server, and the client is relegated pri-
marily to presentation duties.
ISBN: 0-536-56083-8

Specially prepared for d03063582

Architecture modeling starts by gathering statistics about your business, and doc-
umenting the performance expectations that constrain specific events. The size of the
database is determined by calculating the number of bytes required for a single row in
each table, multiplied by the number of expected rows. The number of expected rows is
a function of how often rows are added by an event, and how long you must retain the
record. The statistics collected for record size are also relevant when determining the
network traffic load between client and server.
Statistics gathered for the event model include the average rate for the business
events, and peak rate patterns for events which occur irregularly. Response time con-
straints are also gathered for the most critical business events.
The geographic distribution of the business is documented in an event/business
location matrix. This shows which events occur in the various business locations that are
geographically remote from each other. By combining the event/business location matrix
with an event/entity CRUD matrix, a third matrix, the business location/entity CRUD
matrix can be derived, showing the logical data distribution requirements for the applica-
tion. By combining this knowledge with a sense of how current the data must be at each
site, the team can start evaluating whether to have one centralized database, distributed
and synchronized databases, or employ a fragmentation scheme for distributing data.
The architect is also faced with local distribution decisions. Users of modern GUI
applications demand that many of the business rules be visually apparent to them at run
time. The business also has a responsibility to protect the data asset, usually residing on
the server, from update by other applications which may not be aware of the business
rules. With many development tools and languages, this dilemma can force developers
to code rules in two places.
Many of today’s popular GUI development tools are predisposed toward fat client
architectures. As development languages become more portable, we may see applica-
tions trend back toward server-based business logic and Internet/intranet technology,
however, this will place even more demands on our existing networks to handle the
increased messaging.
Architectural modeling is all about trade-offs. To properly engineer a client/server
solution, you should use the model to simulate transactions through various architectural
scenarios. The purpose of this chapter is show how the essential analysis models can be
used to replace the traditional architecture decision-making method of “he who shouts
the loudest wins.” The moral of the story is that “every solution has a problem.” By
becoming aware of the downside for each solution, your team can arrive sensibly at the
least objectionable architecture to meet your business needs.

EXERCISES
1. What factors might push the design of an application toward a fat server imple-
mentation rather than a fat client design?
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

in a script associated with a window on the client and in a stored procedure in the
relational database management system). The challenge then becomes to devise
some traceability between the requirement for the rule to exist and the various
places you may have tucked the rule in your final code. For systems in which
requirements traceability is of supreme importance (such as in some government
defense systems), each line item in the event dictionary can be numbered and ref-
erenced by comments in the final code. While this is overkill for most business
systems, it is a good idea to document the location of any business rules or policy
in your system which are likely to change or be up for re-evaluation in the fore-
seeable future. This can be done by amending your event dictionary to note the
physical location of key pieces of policy in the final code.

ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

RELATIONAL
DATABASE DESIGN

INTRODUCTION

In Chapter 9, I provide a brief survey of relational database concepts and demonstrate

how an information model translates into a relational database design. I follow with a
discussion of the various options you may face when choosing a primary key. I also
touch on the options for implementing supertype/subtype relationships. The chapter
closes with some tips for performance tuning your database, which could be titled
“Everything you should think about before you decide to denormalize your database
design.”
ISBN: 0-536-56083-8

241

Specially prepared for d03063582

RELATIONAL DATABASES IN BUSINESS SYSTEMS

The relational database has enjoyed a tremendous rise in popularity throughout the 1980s
and 1990s. It is currently the favored format for storing business data in many organiza-
tions throughout the world. Many client/server development tools assume that the under-
lying database will be relational. The strength of the relational model is that it promotes
an implementation-neutral and largely non-redundant format for storing information.
Implementation neutrality is important in business systems, because unlike many
real-time applications with specific tasks or defined functions, business people are con-
stantly searching for new ways to exploit the information they have collected. Requests
to extend the data set or aggregate it in new ways often surface after the initial system is
designed and built.
We have seen from the information modeling chapter that data respects no project
boundaries. Relational databases are designed to serve many masters. This profoundly
powerful concept is often the target of the relational model’s harshest critics who point
out that performance is impacted precisely because the database layout isn’t optimized
toward a particular business function. While some early relational databases didn’t
exactly perform at lightning-fast speed, the modern versions are now performing at rates
that are generally acceptable in business systems.
The intent of this chapter is to show how to convert a logical information model
into a database design. After covering the basics of the transformation, I will offer some
tips on tuning the design for databases where the logical structure has been proven to
have a performance problem.

RELATIONAL DATABASE CONCEPTS

A relational database is made up of a series of tables. Each table consists of columns,

which represent individual data elements, and rows which represent data records in the
organization.1 Figure 9–1 shows a table from a dog kennel system. There is no logical
implication of the physical ordering of columns from left to right. They may be stored
in any order or interchanged at any time.2
Rows are also interchangeable, and no two rows are identical. Each is uniquely
identified with a primary key (underlined), which may be comprised of one or more
columns in the table. Each column should depend on the key, the whole key and noth-
ing but the key, following the rules of normalization, covered in Chapter 5.

1 The official jargon is that a table is a relation and a row is a tuple. A column is referred to as an
attribute or field. In the interest of keeping this epic readable, I prefer to use the common vernacu-
lar, tables, rows and columns.
2 This characteristic of relational databases makes bulk inserts or updates which rely solely on col-
umn position a very dangerous practice. I have seen this technique used in batch routines which
apply EDI transactions. It works fine until another programmer alters the table structure.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

Figure 9–1. The Dog table

These concepts should look very familiar by this point in the book. Much of the
layout of the database is already achieved when you create a well normalized informa-
tion model (see Chapter 5). In the next section, I will show how the information model
can be converted, in very mechanical manner, into a first-cut database design.

TRANSLATING AN INFORMATION MODEL

INTO A RELATIONAL DATABASE

Most data modeling CASE tools will generate a first-cut relational database from the
information model. Each entity becomes a table. The unique identifier for each entity
becomes the primary key of the table. Each attribute becomes a column in its respective
table, and relationships are implemented by placing the primary key of one table in the
related table, as a foreign key, (fk).
Prior to generating a relational database design for any part of your information
model, you must first ensure that the model is complete. Each attribute must have the
appropriate data type. All of the attribute cardinality and relationship cardinality must be
complete and correct. Each entity must have a unique identifier. The unique identifier is
important because it will become the primary key when a table is created for the entity,
and be used as foreign keys throughout the database.
The notation for a relational database diagram isn’t significantly different than that
of an information model. Each fundamental, attributive and associative entity type in the
information model is translated into a table in the relational database. Where the humble
entity is represented with a rectangle on the entity-relationship diagram, we are relieved
to find a rectangle representing a table in the relational database diagram (Figure 9–2).
Relationships are replaced with foreign key references. The four points of cardi-
nality from the information model relationship are retained on the diagram. As noted in
Chapter 5, only three of these points of cardinality are enforced by the declared database
structure. The mandatory nature of the “many” side of the relationship must be enforced
ISBN: 0-536-56083-8

Specially prepared for d03063582

somewhere in the application code. The relationship name has been eliminated from the
line because the relationship has been implemented by embedding the primary key of
one table into the other. An arrow head on the line shows which table has a foreign key
“pointer” back to the table in which it is a primary key.

Figure 9–2. ERD versus RDB notation

The pattern of the relationship cardinality in the information model dictates which
table gets the foreign key. Let’s look at some examples.

One-to-Many Relationships

One-to-many relationships are the meat and potatoes of the relational database. The
overwhelming majority of business relationships fall into this category. The rule is sim-
ple. The primary key from the “one” side is embedded in the table on the “many” side
to implement the relationship. In the example, a person may own many dogs, but a dog
must be owned by only one person. To implement the relationship, the primary key from
the Person table is embedded in the Dog table. We cannot embed the primary key from
the Dog table in the Person table because this would result in a repeating group for any-
one who owns more than one dog. Figure 9–3 shows the entity-relationship diagram, and
the resulting relational database diagram and table schema.
If the “one” side of the relationship is optional, then the foreign key will be
optional (Figure 9–4). If the “one” side of the relationship is required, the foreign key
will be a required field in the table.
To join a dog with its current owner, Dog rows are joined to the corresponding Per-
son row by matching the person’s foreign key in the Dog table to the person’s primary
key in the Person table. The concept of the table join is a basic tenet of Structured Query
Language (SQL), which is used to access data in relational databases.
ISBN: 0-536-56083-8

Specially prepared for d03063582 on 16 Dec, 2010

Figure 9–3. Required relationship results in required foreign key

Figure 9–4. Optional relationship results in optional foreign key

Foreign keys allow the database management system to ensure that no row can be
deleted from the database as long as a row in any table references its primary key. A Per-
son record cannot be deleted if a Dog row exists which references it. The dogs must be
deleted first before the person can be eliminated. This is called referential integrity.
ISBN: 0-536-56083-8

Specially prepared for d03063582

One-to-One Relationships

Figure 9–5 shows a rather odd one-to-one relationship. A person may optionally own one
dog, but not more than one. A dog must be owned by only one person. I must say that one-
to-one relationships are exceptionally rare in business systems. Most of the few one-to-one
relationships that I have encountered have turned out to be supertype/subtype relationships
in disguise. I seriously doubt that the modeler, in this case, is trying to say that a dog is a
type of person, and that a person can be dog. (An assertion that is likely to earn the undy-
ing affection of the dog, but could result in a slap in the face from anyone represented in
the person entity.) I’ll cover the translation of supertype/subtype relationships later in the
chapter, so please suspend disbelief just long enou