CSC 309 Lecture Notes Week 1

CSC 309 Lecture Notes Week 1
Introduction to the Course
Introduction to the Design Process

First-day handouts.
1. Syllabus
2. Milestone 1, including,
  1. SCO format
  2. work breakdown format
  3. meeting minutes format
Review of software systems life cycle (see Figure 1).

Figure 1: Software system lifecyle.
1. Requirements Analysis determines what end users want and need from a software system.
2. Specification formally defines user requirements.
3. Design defines and organizes the major operational components of the system.
4. Implementation defines operational details in a programming language.
Review of requirements analysis and specification phases of the life cycle.
1. The result of requirements analysis and specification is a document that specifies what the system does as opposed to how it works.
2. In general, requirements analysis and specification are the domain of CSC 308.
3. This quarter we will work three selected requirements specifications from 308: EClass, Grader, and TestTool.
  1. You can choose to work on the same requirements specification you wrote last quarter.
  2. Alternatively, you can choose different spec from last quarter, a previous quarter, or a combination of two or more specs.
  3. We will discuss details during the first week lab meetings.
4. Links to the specs from last and previous quarters are located at: http://www.csc.calpoly.edu/~gfisher/classes/309/specs
Major goals of the design process
1. Adhere to the specification
  1. Any deviation from the specification must be recorded and approved in a Specification Change Order (SCO).
  2. The specification plus SCOs form a binding contract between the customer and the design team.
  3. No changes to specification can be made without consulting with the customer and completing a signed SCO.
2. Achieve design quality goals:
  1. Traceability -- elements of the design trace back to corresponding elements of the specification.
  2. Modularity -- elements of the design are organized into logically cohesive modules.
  3. Portability -- the design is sufficiently general that it can be implemented on a variety of platforms and a variety of (related) programming languages.
  4. Maintainability -- the system is designed such that it can be easily repaired and enhanced.
  5. Reusability -- where appropriate, modules are designed to promote their reuse in other (future) designs.
Details of the 309 design process (see Figures 2

Figure 2: The 309 design process.

and 3).

Figure 3: Design Process Fully Expanded.
1. Design High-Level Architecture.
  1. The step starts by deriving the high-level architecture of the program from the requirements model constructed in the Specify step.
    1. The modularization defined for the structural model is carried forward into the packaging of the program design.
    2. This enforces traceability between the abstract specification and the corresponding architectural program design.
  2. The high level architecture of a program is defined in terms of data classes and computational functions.
    1. These are derived, respectively, from the objects and operations of the abstract requirements model.
    2. The program classes and functions derived directly from the requirements model constitute the model portion of the design.
    3. The program classes derived directly from concrete user interface are the view portion of the design.
2. Apply Design Patterns.
  1. Once the top-level design elements are derived from the requirements specification, software design patterns are applied.
  2. A design pattern is a pre-packaged piece of design, based on experience that has been gained over the years by software engineers.
  3. High level design patterns can be used to improve the software architecture, which entails how the major software components relate to one another and communicate.
  4. A widely-used design pattern for end-user software is Model-View- Process (MVP).
  5. The MVP pattern organizes the design into three major segments:
    1. the Model is directly traceable to the abstract functionality defined in the requirements model, and is independent of the concrete end-user interface;
    2. the View segment of the design is devoted specifically and solely to the end-user interface
    3. the Process segment defines underlying processing support for the model, in particular processing that encapsulates platform-dependent aspects of the design.
  6. Other patterns are employed to assist with design of program data, control, and communication.
3. Refine Model and Process Design.
  1. The derived, pattern-based design produced by the first two steps must be refined into a concrete, object-oriented program design.
  2. Model package design is refined using object-oriented design principles, information hiding conventions, and other design guidelines.
  3. Derived functions must be associated with specific model classes, along with other class refinements.
    1. The function-assignment step is necessary because the operations of the functional specification do not necessarily belong to specific objects.
    2. In terms of typical nomenclature, functions associated with classes become class methods, with appropriate adjustment to method signatures based on object-oriented design concepts.
    3. Other necessary design refinements are in the areas of class member visibility, inheritance, and the selection of concrete data representations.
    4. In a modern program design, data representations are typically selected from reusable program libraries.
  4. Process class design entails determining the underlying processing support that is necessary to produce an efficient program.
    1. To encapsulate platform-dependent data processing, process classes are interfaced with model classes via controller, adaptor, and wrapper classes.
    2. These model/process interface classes encapsulate aspects of the program that are specific to specific operating systems, hardware platforms, and external data stores.
  5. An important part of model and process refinement is detailed control flow design.
    1. Dataflow relationships defined in the specification are refined into concrete procedural or multi-process control flow
    2. Other important aspects of control-flow design are functional control flow, event handling, and exception handling.
4. Refine User Interface Design.
  1. The fourth step of design is devoted to refining the end-user interface.
  2. In the current state of the art, user interface design typically relies heavily on libraries of reusable interface classes.
  3. The class libraries define commonly-used interface elements and layouts.
  4. In a Model-View design, the model classes must be refined to support the view classes, based on the specifics of the user interface.
  5. A particularly useful design pattern in this regard is called the "Observer/Observable" pattern.
  6. This pattern defines the way in which view classes can be systematically updated in response to changes made by the user to data values stored in the model classes.
5. Design for Non-Functional Requirements
  1. Any non-functional requirements that were not modeled in the specification or are not yet incorporated in the design are dealt with in this step.
  2. The purpose of this step is to ensure that all system-related non-functional requirements are fully addressed in the design.
6. Formally Specify Design.
  1. As the detailed program design is established, the design is formally specified.
  2. This entails the precise definition of function (i.e., method) input/output signatures, followed by the specification of preconditions and postconditions for all functions.
  3. For the model functions derived directly from the specification, the function conditions are derived directly from the preconditions and postconditions defined in the derived-from operations.
  4. For other model and process functions, preconditions and postconditions are defined with the same methodology used in the abstract specification model.
  5. Namely, preconditions are expressions that must be true before function invocation; postconditions must be true after function executions.
7. Apply Design Heuristics.
  1. Various design heuristics (i.e., general guidelines) can be applied throughout the process of design.
  2. Minimizing coupling among program elements aims to reduce the dependency and communication to only that which is essential
  3. Maximizing cohesion means that program elements that are functionally related are grouped together, without extraneous unrelated elements.
  4. Other heuristics can be applied, such as controlling the size of various program components.
8. Define SCOs and Iterate Back as Necessary.
  1. During the course of program design, the developer may discover aspects of the requirements specification that need to be modified or enhanced.
  2. In such cases, the designer defines a specification change order that clearly states the necessary modifications or enhancements.
  3. This formalized change order is in keeping with the high-level process decomposition into problem definition and problem solution phases.
    1. As discussed above, the Analyze and Specify process steps comprise the problem definition phase.
    2. The Design and Implement steps then comprise the problem solution phase.
  4. In this software process, as in a traditional problem-solving process, changing the problem definition while the solution is underway requires careful consideration.
  5. The specification change order codifies this careful consideration in a precise way.
Comments on the 309 Design Process.
1. The process employs techniques from a number of design methodologies, including:
  1. The UML (unified modeling language) of Rumbaugh, et al.
  2. The structured design techniques of Yourdon, et al.
  3. The MVP (Model-View-Process) technique (aka, MVC -- Model-View-Controller), used originally with the Smalltalk language, and now used extensively in Java designs.
2. The process works well for information processing systems with substantial end- user interfaces, which are the types of systems developed in 308 and 309.
3. For other types of system, similar process steps can be used, but possibly in a different order, and with different domain-specific methodologies.
4. Other major system types include:
  1. Realtime systems, such as communications software.
  2. Utility systems, such as compilers and operating systems.
  3. Embedded systems, such as device drivers and process controllers.
The languages of system specification and design.
1. One of the problems to be confronted in designing from a formal specification is the translation from the requirements/specification language into the design/implementation language.
2. In some cases, specification languages may differ from programming languages, since there are different forces influencing the design of the two types of languages.
  1. In the case of specs written in Fall 2012, the specs are written in a subset of Java, which is the same as the 309 design and implementation language.
  2. Specs from past quarters of 308 used a modeling language different from Java.
  3. The data dictionary generated from the formal specification can be useful, but you are not expected to read or understand the compilable model code.
  4. If you use requirements from previous quarters, you'll need to generate the Java model from scratch, but this should not be an overly difficult task.
Milestone 2 Discussion
1. See the writeup.
2. We'll go over key points in class.