Select this to skip to main content [CSUSB] >> [CNS] >> [Comp Sci Dept] >> [R J Botting] >> [Monograph] >> 01_6
[Index] || [Contents] || [Source] || [ Search monograph] || [Notation] || [Copyright] Wed Mar 10 16:05:45 PST 2004

Contents

    6 Review

      6.1 Conclusions

        Analyzing the software process has found techniques for implementing solutions(SWR, OOP,...) and procedures that work well but need formalizing (SAD, DDD, DAD, OOA, OOD, . . .). There are simple, well known, and useful way to document sequential structures (EBNF, STDs). There are more complex and less well understood non- sequential models (DFDs, ERDs/ERAs). Mathematics is used in documenting and developing software.

        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.

      6.2 Requirement - Documentation is data.

        We need to store data in the software process to describe (1)the new software (Specifications & Design Documentation), (2) systems into which the software fits (Requirements & Domain Documentation, repositories of existing components etc ), (3) the process itself (Process Definition), and (4) ways to do things (Hand books, Manuals, Public Libraries). Software engineers will need to present, record, view, summarize, rediscover, reuse, modify, re-engineer, share, publish, and evaluate this data. The following types of data are needed:
        1. * Facts and hypotheses - logic, set theory, numbers, statistics, etc.
        2. * Interconnections between parts/modules in a system.
        3. * The language used: Lexicons, glossaries, dictionaries, grammars, semantics,... .
        4. * Dynamics - scenarios, patterns of change, schedules, test patterns, life histories, concurrency, . . .
        5. * Entities, relations and attributes that will be represented by objects in the software.
        6. * Quantities and formulae involved in predicting the qualities of the software.
        7. * Interconnections between ideas, evidence, sources, and alternatives.
        The desirable qualities of documentation is that it is clear, formal, simple, quick to draft, quick to change, easy to search, easy to retrieve and reuse [Bellinzonaetal95], portable, makes simple designs look tidy, and can be maintained inexpensively with current technology(compare with VDM eg [McDermid89] p207]. At different times different editors, readers, and software will access it for different reasons and so in different ways. Minimally a document will be used as a data-base, book, and presentation. Hence we need an electronic hypertext reference documentation [HalaszSchwartz94].

      6.3 Preview

        As a feasibility study I have designed a mock-up language called MATHS. It shows that the requirements (6.2 above) can be satisfied using limited resources. To make it easy to prepare and share it uses the standard code and the simplest technology - ASCII and programming editors [Owreetal95] p118. It follows that normal configuration management, versioning, 'make' and other programmers tools can be applied to the raw files as well. However simple, MATHS can still model both abstract and concrete systems. A subset of the notation is interpretable as specifications and and a smaller subset for program designs. This subset has a graphical notation (Temporal Maps) and to English. Appendix 0 is a manifesto giving the detailed aims, goals, and objectives for MATHS. Appendix 1 is a sample. Appendix 4 is a set of quick reference sheets. Chapter 2 introduces MATHS and TEMPO. Chapter 3, 4 and 5 define MATHS. In chapter 6 I show how to fit it into many current methods. Chapter 8 summarizes conclusions and indicates what needs to be done. Managers can skip the details by jumping to chapter 8.

    Formulae and Definitions in Alphabetical Order