4838 Wilkinson Apps pp 242-266 8/9/99 10:07 AM Page 253
APPENDIX 14.3
•
CD–253
APPENDIX 14.3
SYSTEMS DESIGN METHODOLOGIES AND TECHNIQUES
Design Methodologies
A systems design methodology is the collection of approaches, tools, and procedures by which a systems design is developed. A well-defined methodology provides
a discipline that aids systems analysis in preparing a
design. Thus it increases the productivity of systems
analysis. Moreover, it aids systems analysts in spotting
inconsistencies and omissions, thereby reducing the
likelihood of serious deficiencies in the design.
Numerous systems design methodologies have
been devised during recent decades. Prominent examples are Information Engineering (developed by James
Martin Associates and Ernst & Young), Business Systems Planning (developed by IBM), and Structured
Analysis and Design Technique (developed by Sof
Tech, Inc.). Each represents a combination of approaches, techniques, tools, and procedures. Although
certain methodologies draw on traditional techniques
applied manually, the more recently devised methodologies employ structured or object-oriented techniques that are often applied by means of
computerized tools. For instance, Information Engineering aids systems analysts in developing design
specifications through the computerized application
of a variety of structured techniques and documentation forms. Figure A14.3-1 portrays the steps and techniques and forms embodied in the methodology.
Through the set of specifications, the developers receive aid in writing structured application programs.
DEFINITION OF SYSTEM
(e.g., requirements,
structure charts,
data-flow diagrams,
entity-relationship
diagrams)
DATA BASE
(i.e., data structure
diagrams, record
layouts)
OUTPUTS
(i.e., report formats,
screen displays)
INPUTS
(i.e., input screens,
source documents)
MODELS
(i.e., computations,
comparisons)
APPLICATION
PROGRAMS
(structured)
FIGURE A14.3-1 Components of a systems methodology.
PROCEDURES
(i.e., system
flowcharts)
4838 Wilkinson Apps pp 242-266 8/9/99 10:07 AM Page 254
CD–254
•
APPENDIX 14.3
State-of-the-art developments are properly the subject of an advanced AIS course. However, we can illustrate their usefulness through brief surveys of the
object-oriented methodology, application generators,
and CASE tools.
Object-Oriented Systems Development Methodology
Object-oriented systems development represents an alternative to structured systems development. Rather
than emphasizing processes, the object-oriented
methodology focuses primarily on the data to be handled by an information system. Moreover, the data are
viewed in terms of objects—tangible or intangible
things that can be uniquely classified.
Advantages of Object-Oriented Development The
object-oriented methodology allows systems analysts to
build systems easily and effectively. This new methodology is an improvement over structured systems development for the following reasons:
1. Once an object (e.g., customer, fixed asset, employee, general ledger account) has been identified, it does not change. This trait gives stability to
a system design.
2. Both the data definition and the programming
logic are “encapsulated” within an object. Building
blocks are created that can be reused. Thus the
time required to write the program code for an application can be reduced, since an already-created
building block can be pulled from “inventory” and
“plugged in” to the system. Consequently, systems
analysts can be more productive.
3. Objects can form hierarchies of classes, such as
fixed assets, vehicles, trucks, and so on. Each
member of the hierarchy inherits the attributes of
its superior (e.g., a truck has the attributes of a vehicle). This inheritance trait increases the flexibility of the system development process.
4. Because of the modularity of objects and the
reusability of their encapsulated logic, the system
design is likely to be more reliable and free of coding errors.
Shortcomings of Object-Oriented Systems Development Object-oriented development employs special
programming languages, such as Smalltalk and C⫹⫹.
Because they must incorporate such constructs as object classes, encapsulation, and inheritance, these languages are more difficult to use. Thus programmers
need extensive training. The languages also impose
greater hardware demands, such as greater randomaccess memory and secondary storage. These shortcomings are expected to be temporary, however, and
object-oriented systems development is likely to displace structured systems development in time.
Application Generators
Current systems development generation methodologies usually incorporate powerful software tools. One
broad category of tools is known as fourth-generation
languages (4GLs). These languages are sufficiently userfriendly and powerful that users can design their own applications. For instance, an accountant can develop a
reporting program for her use in a cost control situation.
The 4GLs include a variety of languages, such as Interactive Financial Planning System, which enables users
to develop their own application programs.
An important user-friendly type of software tool, usually incorporating a 4GL, is an application generator. An
example is Application-By-Forms, a type of generator
that allows users to define desired applications by filling
in forms provided on screen by the software. (Application-By-Forms is a feature of Ingres, a data-base management product.) Other application generators, which
can be employed by users, are RAMIS II (from Mathematica, Inc.) and FOCUS (from Information Builders).
Computer-Aided Software Engineering
(CASE) Tools
A broad range of automated systems software development tools are labeled Computer-Aided Software Engineering (CASE). CASE tools are generally specialpurpose data-base management systems or dictionary
systems that aid in making methodologies operational.
CASE tools can enhance the productivity of systems analysts and produce high-quality documentation for computer-based systems being developed. Because of the
diversity of CASE tools available commercially, they are
often grouped into several categories.
Basic CASE Tools The most limited CASE tools primarily generate code and thus are similar to application
generators. More useful CASE tools support more than
one phase of the systems development life cycle. Certain
CASE tools emphasize the earlier phases, others emphasize the later phases, and still others span early and
later phases.
Front-end CASE tools focus primarily on the systems
analysis and design phases. These tools, also called upper CASE tools, provide conceptual design specifications by means of such techniques as entity-relationship
diagrams, data-flow diagrams, and structure charts. Examples of front-end CASE tools are DESIGN/1 (developed by Andersen Consulting) and Excelerator
(developed by Intersolv).
Back-end CASE tools focus on the detailed design
and implementation phases of the systems development life cycle. These tools, also called lower CASE
4838 Wilkinson Apps pp 242-266 8/9/99 10:07 AM Page 255
APPENDIX 14.3
•
CD–255
tools, generate structured program code from detailed
design specifications such as tables and screen formats.
They also perform testing and maintenance of the code.
Examples are CA-Telon (developed by Computer Associates, International) and DesignAid II (developed by
Transform Logic).
the creativity needed for superior systems design. Integrated CASE tools are quite expensive, and the training
costs can be high. Furthermore, CASE tools have been
found most useful in designing totally new systems,
which represent only a small percentage of all systems
development work.
Integrated CASE Tools A truly integrated CASE tool
package supports all phases of systems development. It
incorporates various software modules called workbenches and generators. A CASE workbench accepts definitions from human systems analysts; then it converts
the definitions into various structured diagrams and
charts. These diagrammatic descriptions are stored in a
centralized repository called a CASE encyclopedia. A
CASE generator next draws particular system descriptions from the encyclopedia and prepares suitable
coded application programs. The generator also develops the specifications for outputs, data base, and other
components of the newly designed system. Thus it automatically provides the documentation for a new product.
Figure A14.3-2 shows the components of an integrated
CASE package. Examples of integrated CASE tools include Information Engineering Workbench (developed
by KnowledgeWare) and Visible Analyst Workbench (developed by Visible Systems Corporation).
Detailed Design Techniques
Limitations of CASE Tools Although they improve productivity and the quality of developed systems, currently
available CASE tools have definite limitations. Perhaps
the most serious limitation is that they do not allow for
Developing a detailed systems design is a vital step in
the systems development life cycle. However, it can be
quite time consuming and tedious. Like systems analysis, detailed systems design can be aided by a variety of
techniques. Most currently employed techniques are
structured. Included in this category are decision tables,
Warnier–Orr diagrams, detailed structure charts, and
structured English. Extensive coverage of these techniques can be found in most systems analysis and design textbooks. We will briefly introduce selected
techniques to illustrate their usefulness.
Decision Tables A decision table focuses on the “decision choices” inherent in many applications. It shows,
within a matrix format, all of the rules pertaining to a
transaction processing or decision situation. Decision
tables can be viewed as replacements of program flowcharts, sequential flow representations of the steps performed by the instructions in computer programs.
The decision table in Figure A14.3-3 pertains to the
processing of transactions relating to customers. Each
decision point (which is represented by a diamond sym-
Designers
Enter
definitions
Work benches
(planner, analysis,
design)
CASE
processing
Encyclopedia
(diagrams,
charts, etc.)
FIGURE A14.3-2 Components of an integrated CASE tool.
Generators
(code, data base,
documentation)
Application
programs
4838 Wilkinson Apps pp 242-266 8/9/99 10:07 AM Page 256
CD–256
•
APPENDIX 14.3
Rule
Condition
C1. Has end-of-file indicator been reached?
C2. Is customer number on transaction
record larger than number on master record?
C3. Is customer number on transaction record
equal to number on master record?
C4. Is transaction a sale?
C5. Is transaction a payment?
C6. Is customer number the dummy 999?
1
2
3
4
N
Y
N
N
N
N
N
N
N
Y
Y
5
6
Y
Y
N
N
Y
N
X
X
X
Y
Action
A1.
A2.
A3.
A4.
A5.
A6.
A7.
Read transaction record.
Read master record.
Write new master record.
Write error message.
Add amount of transaction to customer
balance.
Deduct amount of transaction from customer
balance.
Stop processing.
X
X
X
X
X
X
X
X
Note: Y means yes, N means no.
FIGURE A14.3-3
A decision table.
bol in a program flowchart) appears as a separate condition. Each processing and input-output step (which is
represented by a rectangle or parallelogram symbol in a
program flowchart) appears as an action. Each logical
construct (which is represented by a branching in a program flowchart) appears as a rule.
A decision table differs in two significant ways from a
program flowchart. First, it does not specify the sequence in which the actions are to be performed. Thus a
decision table presents the unconstrained logic of the
situation being portrayed. Second, its construction is
based on mathematical principles. Thus a “full” decision
table consists of two rules, where R is the number of independent conditions. A “collapsed” table (such as
shown in Figure A14.3-3) is then developed by eliminating all redundant rules.
In summary, a decision table can be described as a
logic diagram of a decision-oriented situation. It reflects
the variety of possibilities that a computer program
might encounter with respect to transaction data. A decision table is particularly helpful when the situation being portrayed has numerous conditional branches.
If a situation to be portrayed in a decision table is
extremely complex, however, a decision table could
become too large to handle easily. For this reason, decision tables are often subdivided to reflect portions of a
complex situation. The fractional decision tables are
then linked together. Alternatively, an overall decision
table may be prepared at a broad level and then partitioned into a set of detailed decision tables. Because decision tables are logical diagrams capable of being
modularized, they qualify as a structured technique.
Warnier–Orr Diagrams Among the most widely used
of the detailed techniques are Warnier-Orr diagrams, devised by Jean-Dominique Warnier and Ken Orr. These diagrams are used to represent in graphical format a
processing sequence, a file structure, or the structure of
a document or report. Figure A14.3-4 displays the structure of a sales invoice. Each bracket indicates a grouping
of data; as the brackets move to the right in the diagram,
the data items become more detailed (i.e., to lower levels in the hierarchy).
Warnier–Orr diagrams provide easy-to-read data and
processing documentation. They can be decomposed to
very detailed levels. Hence, they are widely used to aid
in writing structured computer programs. Their main
drawback is that they are not well suited for large-scale
and data-base oriented systems.
Detailed Structure Charts A structure chart portrays the hierarchy of levels and relationships within a
system. A detailed structure chart depicts the program
modules that will comprise the subroutines of a com-
4838 Wilkinson Apps pp 242-266 8/9/99 10:07 AM Page 257
Customer name
Customer name
Address
Shipping address
⫹
Billing address
Terms
Invoice number
Customer data
(1)
Salesperson
Invoice data
(N)
Sales invoice
Street
City
State
ZIP Code
Product number
Product description
Unit price
Quantity ordered
Product data
(N)
Sales tax
Amount
Note: (a) Number or letter in parentheses indicates the number of times the item occurs.
(b) The ⫹ means that either or both of the items may appear.
FIGURE 14.3-4
A Warnier–Orr diagram of the data hierarchy within a sales invoice.
Prepare
sales
invoice
Cu
nu stom
mb e
r
Ed er
it f
lag
Custom
invoiceer and
data
Edit
customer
number
Print
invoice
header
ice
pr
it
Un
Get
customer
order and
record
ata
er d
Ord
r
de
or d
r
r
e
m co
sto d re
u
n
C a
Ex
ten
d
da Lin ed a Ext
Line
ta e-i m end
-item Invoic
an tem ou ed
dp
am
nt
data e tota Inv
oun
ric
oice EOF
(all) l
t
e
total
Print
line-item
data
Get
unit
price
Compute
extended
amount
Write
extended
amount
Compute
invoice
total
Data flag
Control flag
Loop repeated for
all line items
FIGURE A14.3-5 A detailed structure chart pertaining to the process of preparing a sales invoice.
CD–257
Print
invoice
total
4838 Wilkinson Apps pp 242-266 8/9/99 10:07 AM Page 258
CD–258
•
APPENDIX 14.4
GET CUSTOMER-ORDER
OPEN CUSTOMER file
GET CUSTOMER record
IF CUST-No is valid
THEN SET INVOICE-HEADER
THEN ENTER CUST-NO, CUST-ADDRESS, ORDER-DATE, ORDER-NO
THEN WRITE INVOICE-HEADER
ELSE
DISPLAY “CUSTOMER NUMBER NOT VALID”
ENDIF
FOR each line item
WRITE ITEM-NO and ORD-QTY on INVOICE-LINE
GET UNIT-PRICE-ITEM from pricing file
COMPUTE ITEM-EXTENSION as ORD-QTY times
UNIT-PRICE-ITEM
WRITE ITEM-EXTENSION on INVOICE-LINE
ENDFOR
COMPUTE INVOICE-AMT as sum of ITEM-EXTENSION
WRITE INVOICE-AMT on INVOICE-FOOTING
EOF
FIGURE 14.3-6 A segment of structured English pertaining to a sales invoice.
puter program. It can be used to guide the preparation
of program instructions or English-like pseudoinstructions.
Figure A14.3-5 shows a detailed structure chart that
graphically describes the subroutines of a program for
preparing a sales invoice. The box at the top, called the
boss procedure, represents the control module for the
overall program. This module calls on the subroutines
or individual instructions from left to right. The EOF
(end-of-file) symbol specifies that the program is completed. Data and control flags are used to annotate the
flows between the control module and the subroutines.
Structured English Structured English is an informal
language that uses English-like statements to describe
procedural logic. Its advantage is that the statements do
not require the syntax of a specific programming language, such as COBOL. However, structured English employs statements involving such key terms as IF, THEN,
ELSE, and COMPUTE, which are similar to the programming statements of commonly used languages. These
statements can be easily converted into a formal programming language. Figure 14.3A-6 lists a series of instructions written in structured English. The instructions
are based on the detailed structure chart in Figure A14.35, which describes the preparation of a sales invoice.
APPENDIX 14.4
NETWORK DIAGRAMS
Two major project planning and control techniques,
PERT (Program Evaluation and Review Technique) and
CPM (Critical Path Method), incorporate network diagrams. Our discussion follows the terminology of PERT.
To simplify the discussion, we will ignore the feature
of PERT that requires three time estimates for each
activity.
Nomenclature
Figure A14.4-1 presents a simple network diagram for a
hypothetical project. The key features of the diagram are
1. Activities: tasks to be completed in the course of
the project. Nine activities (labeled A, B, C, E, F, G,