This page is a part of the CS599 course materials at the California State University, San Bernardino. It was generated from dick05.mth by Dr. Dick Botting.

Contents

    Outline for Class 5 on Software Engineering
    (previous): [ dick04.html ]
    (home): [ dick.html ]
    (next): [ Operating Systems II in index ]

    Definitions
  1. formal::="Techniques and methods that use mathematics and symbolic logic".

  2. JSP::="Jackson Structured Programming", A mis-named data directed design method developed in the UK by Michael A Jackson. This is a semi-formal method based on the theory of grammars plus experiences with commercial data processing and compilers.

  3. JSD::="Jackson System development", an Analysis and Design method developed for Management Information Systems and other software that needs to keep a real time model of a real world system and report on its state to the users. The method was developed by John Cameron and Michael A. Jackson in the UK in the late 1970's and is based on simulation techniques and coding methods used in JSP.

  4. OCL::="Object Constraint Language", a semi-formal notation for expressing constraints and behavior of objects as part of the UML". [ ocl.html ]

  5. OOD::="Object Oriented Design".

  6. PDL::="Program Description Language", introduced in the 1970's as a replacement for flow charts. Any hybrid of a programming language and English.

  7. SRS::="Software Requirements Specification based on the standards presented earlier", see listing in [ SRS in dick03 ]

  8. UML::= See http://www.csci.csusb.edu/dick/cs599/dick.html#UML.

    Deliverables

     Hand in printed copy of SRS for Phase I of your project.

    Each team makes a 5 minute presentation of their SRS.

    Topics

    Many Techniques

     The newest theory is that it is best to know many ways to design solutions to problems and to know the kinds of problems that they work best with. For example JSP work well when there is a well defined set of sequential input and output streams. JSD works well when the problem is monitoring and controlling a real system. Transaction centered design works well when the problem is about handling transactions. and so on. For more see [Jackson95c] on requirements and specifications.

    Many levels

     Schach describes two levels: Architectural and detailed. In complex software there may be many levels each designed to use a lower level architecture.

    A wise designer separates different concerns into different modules. For example handling the user is a different type of problem to sorting a set of numbers -- keep them apart. Handling a database depends on the type of database -- oracle/MSAccess/... so separate this from modeling the accountancy rules of a business.

    Try to put each assumption and decision in its own special place. This makes it easy to find and easy to change. Aim for: "Don't Repeat Yourself" and "Say everything Once and Only Once" as design guides.

    Client server systems in particular need a high-level architecture that splits the user interface from the business rules and the data base handling. See AmblerS96 for discussions of these architectures and also how to wrap up a data base as a set of persistent objects.

    Action oriented

    Not used much

    Data Directed

     Better than action oriented but not used much.

    Object Oriented design

     The dominant paradigm of the first decade of the 2nd millennium. May be overtaken by agent-oriented programming however -- here the modules have all the properties of objects but can negotiate their own interfaces with other modules as they need to meet their own goals!

    Schach gives 3 OOD steps. In complex software you may need the following steps,
    #StepChapter in Fowler & ScottIdeas
    1Interaction Diagrams.5 Objects, messages, creation and deletion, lifelines, selfcalls, [conditions], * iterations, returns, ... [ uml.seq.gif ] [ uml.collab.gif ]
    2Class design6 Parameters [ uml.template.gif ] , stereotypes, constraints, dependency, objects, class-wide scope, aggregation and composition, derived attributes and relations, {constraints}, {abstract}, {frozen} [ uml.find.gif ]
    3Clients and Objects6, 7 dependencies, interfaces, and packages [ uml.gen.gif ] [ uml.interface.gif ] [ uml.client.gif ]
    4Design components10 In complex software gather the classes into separately compiled modules with defined interfaces.
    5Deployment10Allocate components to hardware
    6Detailed Design-How formal? PDL? OCL? Add code to CASE tool data?

    Real-Time Systems

    Testing designs

    Tools

     CASE.

    Code generation.

    Round-trip.

    Metrics

    Fan-in + fan-out.

    Cyclomatic complexity.

    Cohesion and coupling.

    . . . . . . . . . ( end of section Topics) <<Contents | Index>>

    Activities

    See Deliverables above.

    . . . . . . . . . ( end of section Outline for Class 5 on Software Engineering) <<Contents | Index>>

    Next

    [ Operating Systems II in index ]

Formulae and Definitions in Alphabetical Order