Professional Documents
Culture Documents
The Timeless Way of Building
The Timeless Way of Building
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.
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
In this note, we shall study the way in which information systems are specified, and
the methodology of Systems Development Life Cycle (SDLC) that is often used in the
development of accounting information systems.
Return to Contents
Components of specifications
Structure: How it is organised.
Function: What it does.
Behavior: How it responds to events and stimuli.
Data: Its meaning and organization.
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:
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.
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 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.
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.
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:
In this step, man-machine boundaries are drawn, and media selected for all dataflows
& datastores.
Return to Contents
An Example
A Toy Sales Order Entry & Processing System:
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.
Table of Contents
Context Diagram
Level 0 Logical Dataflow Diagram
Level 1 Logical DFD: Sales Order Entry Sub-system
Level 1 Logical DFD: Sales Order Processing Sub-system
Dataflow Specifications
Datastore Specifications
Process Specifications
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)
Return to Table of Contents (Example)
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 */
sorryBadCredit(CustomerName, CustomerAddress)
if
pricedOrder(CustomerName, CustomerAddress, Item, Quantity,
OrderPrice),
customerMaster(CustomerName, CustomerAddress, Balance, CreditLimit),
NewBalance is Balance + OrderPrice,
NewBalance >= CreditLimit.