 | A structured design notation or
tool provides graphical and/or text elements representing each of the above logical
constructs that enforce & support the rules of structure. If the notation is
used faithfully it is impossible to design an unstructured solution. Flowcharts, although they may be used to teach structural elements, are not a
structured notation since they can be just as easily used to make an unstructured
algorithm.
It is important that the design tool be able to show both an overview
of a system's or program's logic and the details sufficient to represent each line
of code in the program. The more complex the problem the more
important it is to prepare detailed sketches of algorithms to solve it.
|
| It is helpful if the structured
design notation lends itself to quick sketching of complex logic so that the
programmer/analyst can try multiple approaches to a problem, bench check the
algorithms, and choose the one that yields correct results in an efficient manner.
Working from accurate sketches (perhaps of Use Cases in RRose?) a skilled programmer can
supply the details as code. An Analyst might provide
logical detail one or two levels deep and refer the sketch to a programmer for exploding
out to the three or four (or five...) levels of detail required to plan the algorithm in
the code.
One line in the Analyst's sketch might result in 40 or 50 lines of
code. One line in the Programmer's sketch might result in only five or ten lines of
code. An instructor's diagrams may need one-to-one correspondence as a new language
is introduced. A student's diagrams need enough detail to convince the instructor of
design competence.
|
| Estimates of time required to
complete any project require a 'work breakdown structure. In programming
projects a structured overview of the system development effort provides the work
breakdown structure as well. Since all the objects and scripts are named it is easy
to attach person hours to each. It is somewhat more difficult to put the right number
there, but experience with the methods in a project environment develops estimating
skills. '
|
| The more complex the problem, the
more complex the solution. A more complex problem will require an equally
complex algorithm which will consist of a number of lines of code. Please keep in
mind during this course that one of our main goals is to make a system simple enough that
we can finish in the weeks allowed -- the longest script may only be a couple hundred
lines. In a real enterprise scripts of thousands of lines are not uncommon.
Delivering a highly integrated system with a 'simple' user interface (as
in all Managers & Owners like to say 'KISS' at the Analyst) and 'intuitive' navigation
(as in No training $$ should ever be expended for users after the system is deployed) is
still a quite complex task in Y2K. It represents a Grail for systems administrators
-- Philip Morris, for example, is just beginning to get the joy of seeing a SAP system
work for them that has been more than five years in its implementation. Although it
may be simple for the users, there is not much simple about the system.
Real, production systems require exquisite attention to editing data at
the user interface and otherwise handling business rules for the enterprise.
Please use our simple exercises to develop your style of object orientted and structured
notation to use when you encounter real systems.
The scripts for our purposes in 465 are perhaps dozens or a hundred
lines of code. Those you'll encounter as a programmer protecting the user from every
fluke or circumstance presented by the networks, DBMS, &c involved in connecting to a
database in a real system are likely be hundreds or thousands of lines long.
|
| It is very difficult to develop & debug longer algorithms on the
screen, so before typing the code into the computer one should draw up the solution on
paper or using structured design software. This helps
avoiding errors and mistakes and therefore prevents extensive debugging after the program
is complete.
|
| When programmers encounter existing code with no documentation the
best approach begins with marking it up in the left margin to determine its
structure. Marked this way, a well-structured program will reveal itself.
But, if there are go to statements
everywhere and lines of control are consistently crossed by them, then spaghetti code is
found and it should probably be replaced since it will take hours to figure out where to
put the changes and perhaps days of effort between users and programmer to make the
changes work.
If highlighting the control structures in
the code (the if/thens, loops, &c) reveals the structure quickly then it can probably
be changed economically, making it a valuable part of the legacy. If accurate
documentation of the library is available then this work isn't needed.
|
| Pseudocode, Tight English, and other rules for using words,
indentation, & punctuation to represent structured logic are early examples of
structured design tools. These were better than no structure at all, but they aren't
good for today's level of complexity. When data came
from cards or tapes, editing them was easy. Now that more & more data come from
the User at the Point Of Origin, editing them appropriately is more of a challenge.
We need better design tools than pseudocode today.
Indentation becomes a problem when logical structures become more than
two or three levels deep and there isn't much room left for the words. Words provide
no visual clues to highlight the logical constructs of looping and selection: the
programmer has to read each word and visualize the structure
Flow-charting symbols are sometimes used to show structured
designs. But, there is nothing inherent in these shapes and arrows to enforce rules
of structure. Flow charts allow arrows to be placed anywhere and programs
designed with flow charts are more likely to result in spaghetti code than those using a
structured notation.
Trying to make complex statements fit in little square boxes is also a
problem & the abbreviations invented by analysts to fit the little boxes are more
likely to obfuscate the algorithm for the programmer than clarify it. My bias is
toward notation that doesn't use little boxes.
|
| Warnier-Orr notation is particularly well suited to
quick sketching of system functions and programming logic. J. D. Warnier is a French
systems analyst who devised the notation. Kenneth D. Orr brought Warnier's methods
into English. Its few symbols parallel the rules of structure and
using this notation to construct algorithms results in well-structured code.
Brackets indicate a sequence of statements until a logical condition is
encountered which leads to another sequence in a bracket placed to the right of the
condition.
A statement's actions may be detailed further in a bracket to the
right. Placing a page number in the bracket indicates transfer to another page.
Named subroutines or procedures not in the 'mainline' of the code are
referred to by name where they are called in the mainline code & their details defined
on the page outside of the mainline bracket.
|
| Here are some web references
about Structure:
CERN provides
these concise definitions in a dictionary page
about structure.
Here's a good
discussion posting which rhapsodizes about the uses and
beauty of structure notation and helps to make its place clear
in our OO world.
Here's
another page from an IT consultant's workbook with
discussion about Warnier diagrams.
Kenneth Orr (the Orr in Warnier-Orr) has a good page about Warnier diagrams.
Orr's earlier work, Structured Systems Development, 1977, is a
classic that I'm pleased to have discovered shortly after its introduction.
He now uses a tool called Brackets which is similar the to
B-Liner used to prepare samples of structured docs for the class
project.
Varatek B-liner is an economical tool and you may find their tool
is any easy way to sketch algorithms. It lets you revise easily without erasing or
redrawing. This page is shows an overview of B-liner's 8 building blocks for logic
diagrams. They go into more detail about how to read Warnier diagrams on this page. They also provide a Java How To that is animated. You
can download a student version for free or the licensed version for $79.95. Unless you
need automation of SQL and other CASE-like functionality B-liner may be the only
structured design tool you'll ever need.
|
| Following are three views of our
class project and the Enterprise Engine. The first is an unstructured list of the
steps, objects, and logic involved. Next, indentation is applied to indicate
structure. Then, a Warnier-Orr diagram is presented. I'm hoping this will
convince you of the power of these simple brackets and symbols, plus pagination, to help
recognize, plan for, and build structured systems.
|