There are hundreds of programming languages and PDLs, more than 20 graphic notations for programs, at least five formal specification languages (LOTOS, Spec, VDL, Z, Ina Jo, SDL, etc.), and 40 "Design Representations" [Webster88]. Martin and McClure wrote a massive survey of diagrams for analysis and design.
CASE systems exist but they require expensive workstations with graphics and millions of bytes of direct access storage etc. [Huff92]. These systems support hierarchies of informal Data Flow Diagram(DFDs) plus Entity-Relationship Diagrams(ERDs). Usually they have a data dictionary linked to the DFDs and ERDs. Some CASE systems support state transition diagrams(STDs) to document dynamics. Few CASE systems support performance modeling, simulation, discrete mathematics, logic etc. They may not improve productivity or quality [VesseyJarvenpaaTractinsky92].
This analysis of software development suggests the following guidelines:
|(1) Design is Design.||The same principles apply to a system made of programs and to a program made of objects.|
|(2) Design is not Implementation.||Design should not be restricted to what we code easily in our favorite language.||Design should be based on understanding the problem domain.|
|(3) Non-sequential structures will be needed.||Problems are not naturally sequential.||Non-sequential designs have lower coupling and higher cohesion.||The parts in non-sequential designs are easier to maintain and reuse.|
|(4) Programming languages are screw-drivers not T-squares.||They are tools for constructing software not designing solutions.|
|(5) Analysis, Design and Implementation are not always easy to separate in practice.||Real engineers often rapidly cycle the different processes.|