Introduction to Systems

We build systems like the Wright brothers built airplanes-- build the whole thing, push it
off a cliff, let it crash, and start over again.

R.M. Graham

If builders built buildings the same way that programmers wrote programs, the first
woodpecker would destroy civilisation.

Gerald Weinberg

Introduction
We shall study the characteristics of a system, its attributes and some basic concepts and
strategies for studying them. Our philosophy is that an accounting information system is
merely a kind of an information system which in turn is a kind of a system. Therefore, the
study of basic principles of systems in general and, information systems in particular, is
important for a thorough understanding of accounting information systems. Our approach
to the study of accounting information systems, as will become clear, is an engineering
one, where one proceeds through a methodical path of specification, design, construction,
testing & evaluation, operation and maintenance. A well engineered system is easy to
understand, build, maintain, and upgrade.

What is a system?
A system is a set of inter-dependent components (some of which may be systems in their
own right) which collectively accomplish certain objectives.

Component Inter-dependency objectives (functions)

What is an information system?

An information system differs from other kinds of systems in that its objective is to
monitor/document the operations of some other system, which we can call a target
system. An information system can not exist without such a target system. For example,
production activities would be the target system for a production scheduling system,
human resources in the business operations would be the target system of a human
resource information system, and so on. It is important to recognise that within a vending
machine there is a component/sub-system that can be considered an information system.
In some sense, every reactive system will have a subsystem that can be considered an
information system whose objective is to monitor and control such a reactive system.

What is an accounting information system?

Being an information system, an accounting information system must have a target
system. It should be obvious that the target system must be business operations in a
narrow sense. Other non-accounting aspects of business operations are covered by
information systems such as Human Resources Information System, Management
Information System, Production Planning/Scheduling System, Strategic Planning System,
and so on. The target system for an accounting system has to do with the aspects of
business operations that have to do with accountability for the assets/liabilities of the
enterprise, the determination of the results of operations that ultimately leads to the
computation of comprehensive income, and the financial reporting aspects of business
operations.

A Contextual view
Any system operates by interacting with its environment. The contextual view describes
graphically the interaction of the system with the various entities in its environment. The
interactions consist of dataflows from and to such entities.The contextual view clarifies
the boundary of the system and its interfaces with the environment in which it operates.
Figure: Contextual View

A Control view
Any system must manipulate certain variables in order to achieve its objectives. It
determines the manipulation needed by processing its outputs/states in relation to certain
control parameters.
Figure: Contextual View

Attributes of Complex Systems: (Booch, 1994)

Frequently, complexity takes the form of a hierarchy, whereby a complex system is
composed of interrelated subsyatems that have in turn their own subsystems, and so on,
until some lowest level of elementary components is reached (Courtois, 1985). The
choice of what components in a system are primitive is relatively arbitrary and is largely
up to the discretion of the observer of the system. Intracomponent linkages are generally
stronger than intercomponent linkages (components of a system are loosely coupled, but
components themseklves are cohesive) (Simon, 1985). Hierarchical systems are usually
composed of only a few different kinds of subsystems in various combinations and
arrangements (same components can be reused)(Simon, 1985). A complex system that
works is invariably found to have evolved from a simple system that worked..... A
complex system designed from scratch never works and can not be patched up to make it
work. You have to start over, beginning with a system that works (Gall, 1986).

Some basic concepts & strategies in the study of systems

 Abstraction: ``We have developed an exceptionally powerful technique for
dealing with complexity. We abstract from it. Unable to master the entirety of a
complex object, we choose to ignore the inessential details, dealing instead with
the generalized, idealized model of the object" Wulf in Shaw, 1981).
 Formality: Rigor at each stage in the development of a system.
 Divide and conquer: Divide a complex problem into a set of simpler problems
that can be solved.
  Hierarchical ordering: Order the simplification of the problem in ``divide &
conquer" in hierarchies.
 Cohesion & coupling: Modularise the system such that interactions within
components (cohesion) is maximised and interactions between components
(coupling) is minimised. This way, the impact of errors, when they arise, is
localised and does not cascade through the system. Diagnosis of offending
components is also made easier.
 Information hiding: Each module (or subsystem) must have available to it just the
information that is needed by it.
 Conceptual integrity: Consistency in design.
 Completeness: Ensuring that the design meets all the specifications.
 Logical independence: Emphasis on the statement of system objectives in terms
of logical functions independent of physical implementation.
 Correctness & Efficiency: Correct in the sense that the design meets all the user
requirements. Efficient in that the system accomplishes the objectives with
minimum computing resources.

References
Booch, G. (1994) bf Object-Oriented Analysis and Design with Applications, 2nd ed.
Redwood City, California: The Benjamin Cummings Publishing Company, Inc.

Courtois, P. (1985) On Time and Space Decomposition of Complex Structures.

Communications of the ACM, vol. 28(6), p.596.

Gall, J. (1986) Systemantics: How Systems Really Work and How They Fail, 2nd ed.
Ann Arbor, MI : The General Systemantics Press.

Simon, H. (1982) The Sciences of the Artificial. Cambridge, MA : The MIT Press.

Martin, J. and McClure, C. (1988) Structured Techniques: The Basis for CASE,
Revised ed. Englewood Cliffs, NJ : Prentice Hall.

Shaw, M. (1981) ALPHARD: Form and Content. New York, NY: Springer-Verlag.
 Introduction to Systems Development
My experience has shown that many people find it hard to make their design ideas
precise. They are willing to express their ideas in loose, general terms, but are unwilling
to express them with the precision needed to make them into patterns. Above all, they are
unwilling to express them as abstract spatial relations among well-defined spatial parts. I
have also found that people aren't always very good at it; it is hard to do..... If you can't
draw a diagram of it, it isn't a pattern. If you think you have a pattern, you must be able to
draw a diagram of it. This is a crude, but vital rule. A pattern defines a field of spatial
relations, and it must always be possible to draw a diagram for every pattern. In the
diagram, each part will appear as a labeled or colored zone, and the layout of the parts
expresses the relation which the pattern specifies. If you can't draw it, it isn't a pattern.

Christopher Alexander (1979) in The Timeless Way of Building.

Introduction
The work of Christopher Alexander, a mathematician-turned architect, has had a subtle
and yet a profound impact on the methodologies for the development of information
systems in business. The main idea in architecture, espoused by Alexander, is that
buildings and cities can be designed from the combination of certain basic patterns. Such
patterns can be documented as diagrams which, in the architectural domain, specify
spatial relationships. In the domain of business (and accounting) information systems
development, the task is to create languages for describing and manipulating patterns to
create systems that meet the needs of business.

In this note, we shall study the types of information systems used in the business, the way
in which information systems are specified, and the various methodologies for the
development of information systems.

Types of Information Systems

Information systems can be classified in many ways, but for our purposes here, we will
consider their classifications based on the mode of processing, on the system objectives,
and on the nature of interaction of the system with its environment

Classification by mode of processing

 Batch processing systems: The transactions are collected as they occur, but
processed periodically, say, once a day or week.
  On-line batch systems: The transation information is captured by on-line data-
entry devices and logged on the system, but it is processed periodically as in batch
processing systems.
 On-line Real-time systems: The transaction data capture as well as their
processing in order to update records (and generate reports) is carried out in real-
time as the transaction is taking place

Classification by System Objectives

 Transaction Processing Systems: Their objective is to process transactions in
order to update records and generate reports, ie., to perform score-keeping
functions.
 Decision Support Systems: Their objective is to support the managerial decisions.
Usually, these systems are based on a model of the decision-making domain, and
utilize techniques from management science, finance or other functional areas of
business in order to build such models. These systems are also used often for
attention-directing purposes, ie., for directing the attention of managers to a
problematic aspect of operations.
 Expert Systems: These systems incorporate expertise in order to aid managers in
diagnosing problems or in problem-solving.

Classification based on the nature of interaction with

environment
 Transformational Systems: These are systems that transform inputs received from
the environment in order to generate reports (output).
 Reactive Systems: These are systems ``characterized by being, to a large extent,
event-driven, continuously having to react to external and internal stimuli" (Harel,
1987).

The components of accounting systems such as payroll, general ledger are, it should be
obvious, usually batch processing systems, and also transaction processing systems that
are transformational systems. Systems for determination of sample sizes for audit testing,
on the other hand may be decision support systems. Systems aiding provision for
doubtful accounts (or loan loss reserves for financial institutions) may be expert systems.

Specification of Information Systems

Why specifications?
Specification of any system before its development is crucial. Specifications perform for
information systems the same function that blue-prints and engineering specifications
perform for physical structures. Specifications serve as benchmarks for evaluating
designs as well as their implementation. They also facilitate quality assurance via
verification (are we building the system right, ie., do the design and implementation meet
the specifications?) and validation ( are we building the right system, ie., does the system
meet the user needs?).

Formal vs. Informal Specifications

In the development of information systems in business, informal specifications through
graphical modeling have been used at least since late 70s. We shall be studying many of
these modeling tools. Recently, formal specification languages (such as Larch, VDM, Z,
FOOPS and OBJ) have been developed. While their use in business systems development
is in its very early stages, they are expected to play an important role in the future. These
formal specification techniques attempt to mathematically specify structure, function, and
behavior of information systems.

Components of specifications
Specification of an information system is given by their

Structure How it is organised.

Function What it does.
Behavior How it responds to events and stimuli.
Data Its meaning and organization.

Most CASE tools co-ordinate information systems projects through a project or system
dictionary. The function of the dictionary is to standardise the use of terms throughout the
organisation and to serve as a repository of all common information in the project. It
enforces consistency as well as (relative) completeness of the specifications, and
facilitates verification & validation of such specifications. It also serves as a means of
communication between the different persons on the information systems building team.
The figure below shows the various components of the specifications and the modeling
techniques utilised. We will be studying some of those techniques in this course.
Figure: Specification of Information Systems

Methodologies for Systems Development

There are many methodologies for the development of information systems: Systems
Development Life Cycle (SDLC), Data Structure-Oriented design, Object-Oriented
design, Prototyping, among others. We shall, however, be concerned here primarily with
SDLC and the Object-Oriented design

Systems Development Life Cycle

Referred to variously as the waterfall model and linear cycle, this methodology is a
coherent description of the steps taken in the development of information systems. The
reason why it is referred to as the waterfall model should be obvious from the following
figure (from Horner, 1993):
Figure: Systems Development Life Cycle

The methodology SDLC is closely linked to what has come to be known as structured
systems analysis & design. It involves a series of steps to be undertaken in the
development of information systems as follows:

 Problem definition: On receiving a request from the user for systems

development, an investigation is conducted to state the problem to be solved.
o Deliverables: Problem statement.
 Feasibility study: The objective here is to clearly define the scope and objectives
of the systems project, and to identify alternative solutions to the problem defined
earlier.
o Deliverables: Feasibility report.
 Systems analysis phase: The present system is investigated and its specifications
documented. They should contain our understanding of HOW the present system
works and WHAT it does.
o Deliverables: Specifications of the present system.
  Systems design phase: The specifications of the present system are studied to
determine what changes will be needed to incorporate the user needs not met by
the system presently. The output of this phase will consist of the specifications,
which must describe both WHAT the proposed system will do and HOW it will
work.
o Deliverables: Specifications of the proposed system.
 Systems construction: Programming the system, and development of user
documentation for the system as well as the programs.
o Deliverables: Programs, their documentation, and user manuals.
 System testing & evaluation: Testing, verification and validation of the system just
built.
o Deliverables: Test and evaluation results, and the system ready to be
delivered to the user/client.

The figure below provides an illustration for the above description.

Figure: Dataflow Diagram for SDLC

The waterfall model has many attractive features: Clearly defined deliverables at the end
of each phase, so that the client can take decisions on continuing the project. Incremental
resource committment. The client does not have to make a full committment on the
project at the beginning. Isolation of the problem early in the process.

It does, however, have some drawbacks:

Requires an all-or-nothing approach to systems development. Does not allow incremental

development. Requires very early isolation of the problem. In the real world, often the
problems are uncovered in the process of development of systems.
References
Alexander, C. (1971). Notes on the Synthesis of Form, 2d ed. Cambridge, MA: Harvard
University Press.

Alexander, C. (1979). A Timeless Way of Building. New York, NY: Oxford University
Press.

Harel, D. (1987). Statecharts: A Visual Formalism for Complex Systems. Science of

Computer Programming, pp.231-274.

Horner, K. (1993). Methodology as a Productivity Tool, in Software Productivity

Handbook, J. Keyes (ed), New York, NY: Windcrest/McGraw-Hill, pp.97-117.

Pressman, R. (1987). Software Engineering: A Practitioner's Approach, 2d ed. New

York, NY: McGraw-Hill.

Yourdon, E. (1993). A Natural Productivity in Object-Orientation, in Software

Productivity Handbook, J. Keyes (ed), New York, NY: Windcrest/McGraw-Hill, pp.97-
117.
 The Functional Model
One anxiety inherent in the design methods is the hierarchical nature of complexity. This
anxiety moves in two directions, escalation and infinite regression. I will use a story,
``The Warning of the Doorknob," to illustrate the principle of escalation.

This has been my experience in Washington when I had money to give away. If I gave a
contract to a designer and said, ``The doorknob to my office doesn't have much
imagination, much design content. Will you design me a new doorknob?" He would say
``Yes," and after we establish a price he goes away. A week later he comes back and says,
``Mr. Eberhard, I have been thinking about that doorknob. First we ought to ask ourselves
whether a doorknob is the best way of opening and closing a door." I say, ``Fine, I believe
in imagination, go to it." He comes back later and says, ``You know, I have been thinking
about your problem, and the only reason you want a doorknob is you presume you want a
door to your office. Are you sure that a door is the best way of controlling egress, exit,
and privacy?" ``No, I'm not sure at all." ``Well, I want to worry about that problem." He
comes back a week later and says, ``The only reason we have to worry about the aperture
problem is that you insist on having four walls around your office. Are you sure that is
the best way of organizing this space for the kind of work you do as a bureaucrat?" I say,
``No, I'm not sure at all." Well, this escalates until (and this has literally happened in two
contracts, although not exactly through this process) our physical designer comes back
with a very serious face. ``Mr. Eberhard, we have to decide whether capitalistic
democracy is the best way to organize our country before I can possibly attack your
problem."

On the other hand is the problem of infinite regression. If this man faced with the design
of the doorknob had said, ``Wait. Before I worry about the doorknob, I want to study the
shape of man's hand and what a man is capable of doing with it," I would say, ``Fine." He
would come back and say, ``The more I thought about it, there's a fit problem. What I
want to study first is how metal is formed, what the technologies are for making things
with metal in order that I can know what the real parameters are for fitting the hand."
``Fine." But then he says, ``You know, I have been looking at metal forming and it all
depends on metallurgical properties. I really want to spend three or four months looking
at metallurgy so that I can understand the problem better." ``Fine." After three months he
will come back and say, ``Mr. Eberhard, the more I look at metallurgy, the more I realize
that it is the atomic structure that's really at the heart of this problem." And so, our
physical designer is in atomic physics from the doorknob. That is one of our anxieties, the
hierarchical nature of complexity.

Eberhard (1970) quoted in Teague & Pidgeon (1985) and Yourdon (1989)
Introduction
The understanding and management of complexity is perhaps the most important task of
the designer of an information system. It is carried out bearing in mind the strategies of
abstraction as well as hierarchical ordering (divide & conquer).

In the real world, an accounting information systems designer (systems designer for
short) is rarely called upon to analyse and design a system from the scratch. Usually, such
a system does exist, but the client (user) is not quite satisfied with it. The systems
designer starts with the documentation of the existing accounting system, if it does not
exist. Often, documentation pertaining to the existing system is contained in the audit
workpapers pertaining to the auditor's study of control risk assessment. However, since
such documentation is not prepared with a view to design a system, it is used only as a
starting point in building the documentation to aid systems design.

In this document, we shall study how abstraction and hierarchical ordering strategies are
used to manage the complexity of analysing and designing the functions of an
information system.

The Strategy in Functional Modeling

The methodology of structured systems analysis & design provides a roadmap for the
development of functional specifications for an accounting information system, shown in
the Figure below.
Figure: Structured Systems analysis & Design Methodology

The functional specifications are documented graphically in Dataflow Diagrams (DFDs)

described in the next section below.

STEP 0: (Defining the scope of the system under study.) This accomplished by
drawing the context diagram for the system.
STEP 1: (Documentation of how the existing system works.) This is accomplished
by drawing the Physical DFDs of the existing system. These DFDs specify the
current implementation of the existing system, and would answer questions such
as:
 Who performs the tasks?
 How they are performed?
 When or how often they are performed?
 How the data is stored (media)?
 How the dataflows are implemented (media)?

These physical DFDs may be levelled, or, if the system is not very large, prepared
all on a single DFD.

STEP 2: (Documentation of what the existing system does.)This is documented in

Logical DFDs of the existing system. Deriving these logical DFDs of the existing
 system from the physical DFDs involve abstraction of all implementation details.
Since the systems designer would not like to be tied down by the current
implementation of the system, all such details are abstracted. These logical DFDs
are usually levelled in order to reduce the perceived complexity of the system, and
balanced in order to assure consistency in the design.
STEP 3: (Documentation of what the proposed system will do.) After step 2, the
systems designer will examine why the existing system does not meet the user
requirements, and how it can be modified in order to meet such needs. The result
is a set of logical DFDs which describe what the modified (proposed) system will
do. These functional specifications are devoid of implementation considerations,
and therefore rather abstract specifications of the proposed system. These logical
DFDs are also levelled and balanced.
STEP 4: (Documentation of how the proposed system will work.) The logical
DFDs of the proposed system derived in step 3 above are then examined to
determine which implementation of it meets the user requirements most
efficiently. The result is a set of physical DFDs of the proposed system. They
answer questions such as:
 Who will perform the various tasks?
 How they will be performed?
 When or how often they will be performed?
 How the data will be stored (media)?
 How the dataflows will be implemented (media)?

In this step, man-machine boundaries are drawn, and media selected for all dataflows &
datastores

Dataflow Diagrams
The function of any information system can be expressed in terms of transformation
(processing) of certain inputs (which are data) into outputs (which are data too) where
memory (which too consists of data) may need to be consulted (or updated). This
suggests that two crucial elements in a system's description are data and processing of
data. A complete description of an information system demands description of both these
elements. In fact, we can reduce this, in a mundane fashion to the equation:

System = Data + Processing of data

While it is impossible to describe an information system exclusively in terms of data or

its processing, it is possible to study a system's functions (what the system must do) in
terms of the transformations it must perform of the data which is modeled separately. A
coherent description of the information system, however, would require that the models
of data and its processing are not inconsistent. An information system's functions, which
describe its processing aspects, is modeled in the structured systems approach, as
dataflow diagrams.Such a model of an information system is, for obvious reasons,
referred to as functional model or process model.
A dataflow diagram consists of external entities (represented by rectangles), processes
(represented by either rounded rectangles or circles), data stores (represented by either an
open rectangle or two parallel lines) and dataflows (represented by arrows).

Guidelines for Drawing Dataflow Diagrams

 Naming conventions:
o Processes: strong verbs
o dataflows: nouns
o datastores: nouns
o external entities: nouns
 No more than 7 - 9 processes in each DFD.
 Dataflows must begin, end, or both begin & end with a process.
 Dataflows must not be split.
 A process is not an analog of a decision in a systems or programming flowchart.
Hence, a dataflow should not be a control signal. Control signals are modeled
separately as controlflows.
 Loops are not allowed.
 A dataflow can not be an input signal. If such a signal is necessary, then it must be
a part of the description of the process, and such process must be so labeled. Input
signals as well as their effect on the behavior of the system are incorporated in the
behavioral model (say, state transition graphs) of the information system.
 Decisions and iterative controls are part of process description rather than
dataflows.
 If an external entity appears more than once on the same DFD, then a diagonal
line is added to the north-west corner of the rectangle (representing such entity).
 Updates to datastores are represented in the textbook as double-ended arrows.
This is not, however, a universal convention. I would rather you did not use this
convention since it can be confusing. Writing to a datastore implies that you have
read such datastore (you can not write without reading). Therefore, datastore
updates should be denoted by a single-ended arrow from the updating process to
the updated datastore.
 Dataflows that carry a whole record between a datastore and a process is not
labeled in the textbook since there is no ambiguity. This is also not a universal
convention. I would rather you labeled such dataflows explicitly.
 Conservation Principles:

Datastores & Dataflows: Datastores can not create (or destroy) any data. What
comes out of a datastore therefore must first have got into a datastore through a
process.
Processes: Processes can not create data out of thin air. Processes can only
manipulate data they have received from dataflows. Data outflows from processes
therefore must be derivable from the data inflows into such processes.
 Levelling Conventions:

Numbering: The system under study in the context diagram is given number `0'.
The processes in the top level DFD are labelled consecutively by natural numbers
 beginning with 1. When a process is exploded in a lower level DFD, the processes
in such lower level DFD are consecutively numbered following the label of such
parent process ending with a period or full-stop (for example 1.2, 1.2.3, etc.).
Balancing: The set of DFDs pertaining to a system must be balanced in the sense
that corresponding to each dataflow beginning or ending at a process there should
be an identical dataflow in the exploded DFD.
Datastores: Datastores may be local to a specific level in the set of DFDs. A
datastore is used only if it is referenced by more than one process.
External entities: Lower level DFDs can not introduce new external entities. The
context diagram must therefore show all external entities with which the system
under study interacts. In order not to clutter higher level DFDs, detailed
interactions of processes with external entities are often shown in lower level
DFDs but not in the higher level ones. In this case, there will be some dataflows at
lower level DFDs that do not appear in the higher level DFDs. In order to
facilitate unambiguous balancing of DFDs, such dataflows are crossed out to
indicate that they are not to be considered in balancing. This convention of
crossing is quite popular, but this text does not follow it. I would rather you
followed this convention.

A Toy Sales Order Entry & Processing System

(Example):
I give below the functional specifications for a toy sales order entry and processing
system. The specifications given are for the logical aspects of the system only, and
therefore are, incomplete. They are also incomplete in that the behavior model is absent.
They are given as illustrations only. They consist of:

 Context diagram
 levelled logical dataflow diagrams
 Relation specifications for a Relational Database
 Specifications for the dataflows
 Process descriptions in raw prolog code. (Prolog is a relational language. The
code is given here, since prolog code is generally easily grasped). The code given
here, with very minor changes, should be executable.

I will not provide the physical DFDs below, since they are implementation dependent,
and I have not based this toy system on any real-world accounting system.

We have yet to discuss the data models and databases. We will not be discussing
programming aspects of systems. Therefore, the database specifications are given as a
prelude to our class discussions on databases later in the semester. The code is given just
for the purpose of appreciation.

We are talking about a very small firm that considers orders from customers for one item.
You should be able to add bells and whistles as you wish. The situation considered is
rather unrealistic, but it makes important points about specifications for an accounting
system and its documentation.

Dataflow Diagrams:
Context Diagram: (Sales Order Entry & Processing System)

Figure: Context Diagram

Level 0 Logical Dataflow Diagram: (Sales Order Entry & Processing System)
Figure: Level 0 Dataflow Diagram

Level 1 Logical Dataflow Diagram: (Sales Order Entry Sub-system)

Figure: Level 1 Dataflow Diagram (Sales Order Entry Subsystem)

Level 1 Logical Dataflow Diagram: (Sales Order Processing Sub-system)

Figure: Level 1 Dataflow Diagram (Sales Order Processing Subsystem

Dataflow Specifications

Syntax: dataflowName(attribute1, attribute2,.....)

order(CustomerName, CustomerAddress, Item, Quantity)

pricedOrder(CustomerName, CustomerAddress, Item, Quantity,

OrderPrice)

weDontSell(CustomerName, CustomerAddress, Item)

sorryBadCredit(CustomerName, CustomerAddress)

approvedOrder(CustomerName, CustomerAddress, Item, Quantity,

OrderPrice)
sorryNotInStock(CustomerName, CustomerAddress, Item)

acceptedOrder(CustomerName, CustomerAddress, Item, Quantity,

OrderPrice)

salesOrder(CustomerName, CustomerAddress, Item, Quantity,

OrderPrice)

billOfLading(CustomerName, CustomerAddress, Item, Quantity)

invoice(CustomerName, CustomerAddress, Item, Quantity, OrderPrice)

Datastore Specifications:

Syntax: relationName(attribute1, attribute2,......)

priceList(Item, Price)

customerMaster(CustomerName, CustomerAddress, Balance,

CreditLimit)

inventoryMaster(Item, QuantityOnHand)

salesOrderMaster(CustomerName, Item, Quantity, OrderPrice)

billOfLading(CustomerName, Item, Quantity)

openInvoices(CustomerName, Item, Quantity, OrderPrice)

customer(CustomerName, CustomerAddress)

order(CustomerName, CustomerAddress, Item, Quantity)

Process Specifications:

Syntax: prolog clause

/* Orders are priced by multiplying the quantity ordered by the

price for the item on the price list */

pricedOrder(CustomerName, CustomerAddress, Item, Quantity,

OrderPrice)

if

order(CustomerName, CustomerAddress, Item, Quantity),

priceList(Item, Price),

orderPrice is Price * Quantity.

/* We don't sell the item ordered by the customer if such item is
not on the price list */

weDontSell(CustomerName, CustomerAddress, Item)

if

order(CustomerName, CustomerAddress, Item, Quantity),

not priceList(Item, - ).

/* A customer order for an item is approved if the order is priced

and the account balance after the order is less than the credit
limit */

approvedOrder(CustomerName, CustomerAddress, Item, Quantity,

OrderPrice)

if

pricedOrder(CustomerName, CustomerAddress, Item, Quantity,

OrderPrice),

customerMaster(CustomerName, CustomerAddress, Balance,

CreditLimit),

NewBalance is Balance + OrderPrice,

NewBalance < CreditLimit.

/* A customer order is rejected on account of bad credit if the

order is priced and the account balance after the order exceeds
the credit limit for the customer */

sorryBadCredit(CustomerName, CustomerAddress)

if

pricedOrder(CustomerName, CustomerAddress, Item, Quantity,

OrderPrice),

customerMaster(CustomerName, CustomerAddress, Balance,

CreditLimit),

NewBalance is Balance + OrderPrice,

NewBalance >= CreditLimit.

/* A customer order is accepted if it is approved and the quantity

on hand of the item ordered is at least as much as the quantity
ordered */
acceptedOrder(CustomerName, CustomerAddress, Item, Quantity,
OrderPrice)

if

approvedOrder(CustomerName, CustomerAddress, Item, Quantity,

OrderPrice),

inventoryMaster(Item, QuantityOnHand),

QuantityOnHand >= Quantity.

/* A sales order is prepared if a customer order is accepted */

salesOrder(CustomerName, CustomerAddress, Item, Quantity,

OrderPrice)

if

acceptedOrder(CustomerName, CustomerAddress, Item, Quantity,

OrderPrice),

/* A bill of lading is prepared if a sales order is prepared */

billOfLading(CustomerName, CustomerAddress, Item, Quantity)

if

salesOrder(CustomerName, CustomerAddress, Item, Quantity,

OrderPrice).

/* An open invoice is prepared if a bill of lading is prepared */

openInvoices(CustomerName, Item, Quantity, OrderPrice)

if

billOfLading(CustomerName, CustomerAddress, Item, Quantity).

/* A customer's account is updated by adding the order price to

the current balance in the account if open invoice is prepared */

updateCustomerAccountsForInvoices

if

openInvoices(CustomerName, Item, Quantity, OrderPrice),

retract(customerMaster(CustomerName, CustomerAddress, Balance,

CreditLimit)),
 NewBalance is Balance + OrderPrice,

assert(customerMaster(CustomerName, CustomerAddress, NewBalance,

CreditLimit)).

References
Eberhard, J. (1970) We Ought to Know the Difference, in Engineering Methods in
Environmental Design and Planning, Gary T. Moore, ed. Cambridge, Mass.: MIT
Press. pp.364-365.

Teague, L and C. Pidgeon. (1985) Structured Analysis Methods for Computer

Information Systems. Chicago, Ill.: Science Research Associates.

Yourdon, E. (1989) Modern Structured Systems Analysis. Englewood Cliffs, NJ:

Prentice Hall.