1. Syllabus
2. Milestone 1
3. Graphical design notation

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.

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 205/508.
3. The 508 requirements and specifications from last quarter are located at following URL:

   
   http://kdat.calpoly.edu/~gfisher/projects/work/inferno
   
   

1. Objective -- to construct an Integrated, Graphical, Uniform-Language, Multi- Platform Software Development Environment for use by undergraduate software engineering students.
   1. Integrated means that the environment will provide integrated support tools for all of the major phases of software development, most particularly for requirements, specification, design, implementation, and testing.
   2. Graphical means that the environment will provide a variety of graphical viewing and editing tools to aid in the software development process.
   3. Uniform-Language means that tools in the environment that use a textual language will use the same common language; in addition, the environment will provide features for the addition of new common languages in an efficient manner.
   4. Multi-Platform means that the environment will support the development of software on and for a number of common platforms, most particularly UNIX, PC, and Macintosh.
2. Figures 2 and 3 show the initial UI screen and expanded command menus for the environment.

   ---

   

   Figure 2: Initial user screen.

   ---

   ---

   

   Figure 3: Expanded command menus.

   ---

3. Major components of the environment are:
   1. Top-Level tools that provide a process-oriented GUI project; the specific top-level tools are the following:
      1. process navigator, for viewing the software process and launching development tools
      2. artifact navigator, for viewing the software artifacts produced by the steps of the process
      3. historical navigator, for viewing the version history of artifacts
      4. command-line navigator, providing a textual form of process navigation useful in particular for scripting
   2. Development tools tools for the five ordered steps of the process:
      1. requirements analysis
      2. specification
      3. prototyping
      4. design
      5. implementation
   3. Development tools tools for the four pervasive steps of the process:
      1. configuration management
      2. testing
      3. project administration
      4. project documentation
   4. General text and graphics editing tools, with customized functionality based on their context of use.

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.

1. Derive Initial Design from Spec. Based on the requirements specification, including the formal RSL specification, derive the initial rough design.
2. Define Subsystem Modules in Block Diagrams. Determine the major subsystems, which are roughly identified as the separate user-level processes in the specification; draw the high-level relationships between these modules in a block diagram.
3. Define Initial Object Modules using Class Diagrams. Begin the object-oriented design process by:
   1. associating each function with an appropriate class,
   2. "objectifying" function signatures,
   3. refining preconditions and postconditions for each function,
   4. defining class member visibility,
   5. defining inheritance and other relations,
   6. choosing appropriate data representations.
4. Define High-Level Control Flow in Function Diagrams. Begin to determine functional control flow, i.e, what functions call what other functions.
5. Further Refine Classes and functions. Continue the design refinement by applying well-known design methodologies:
   1. MVP -- model/view/process, which organizes the design to achieve maximal separation between graphical user interface modules and underlying data processing modules.
   2. HIPO -- hierarchical input/process/output, which organizes the design of the non-graphical components of the interface and processing
   3. Other domain-specific design methodologies, such as client/server, transaction processing, etc; such mythologies often embody what are called design patterns or design architectures
   4. These methodologies prescribe how to refine newly defined classes, which entails some or all of the following steps
      1. refining class data representations
      2. adding new member functions as necessary
      3. defining new superclasses and subclasses
      4. adding class/subclass details to the class hierarchy diagram
      5. defining preconditions and postconditions for all new functions
6. Define Exception Handling. Based on methodology guidelines as appropriate, define system events and exceptional conditions. For events, define the functions that respond to them. For exceptions, define where they are recognized and where they are handled.
7. Apply General Design Heuristics. These include heuristics to minimize inter-module coupling and maximize intra-module cohesion.
8. Define SCOs. Define Specification Change Orders and update the requirements and/or specification artifacts as necessary.

1. The employs techniques from a number of design methodologies, including:
   1. The OMT (object modeling technique) of Rumbaugh, et al.
   2. The structured design technique of Yourdon, et al.
   3. the MVP (model, view, process) technique used originally with the Smalltalk language.
   4. the HIPO (hierarchical input, process, output), developed originally at IBM.
2. The process works well for information processing systems with substantial end- user interfaces, which are the types of systems developed in 206 and 509.
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.

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. It is likely that specification languages differ from programming languages, since there are different forces influencing the design of the two types of languages.
   1. Specification languages:
      1. The spec language should be more abstract than a programming language, and free of any implementation-level features.
      2. It should be understandable to non-programmers at some level.
   2. Programming languages:
      1. Provide enough power to build efficient implementations.
      2. Provide enough features to organize implementations modularly.
      3. Understandability for non-programmers is not an issue.
3. The two languages we're concerned with are RSL and Java, so we'll use their terminology.

Now on to details of each step of the design process

1. An RSL-to-Java comparison table is shown Table 1

   ---

   
   

   RSL	Java
   module	package
   object	class or simple type
   operation	function
   function	function
   pre/post conds	comments only
   and composition	class data members
   or composition	inheritance (enumeration)
   list composition	varying implementations
   recursive composition	recursive class definition

   Table 1: RSL-to-Java comparison.
   
   

   ---

2. Each RSL composite object in the specification is transformed into a Java class, with exactly the same name.
   1. Each and'd component in an RSL object is transformed into a protected data member of the transformed class.
   2. Each or'd component in an RSL object is transformed into a protected data member in a subclass.
   3. Each list or recursively defined component in an RSL object is transformed into an abstract type data member in the transformed class, to be refined later into an appropriate concrete data representation.
3. Each RSL atomic object is transformed into a simple Java type.
   1. RSL type integer is transformed to Java int.
   2. RSL types real and number are transformed to Java double.
   3. RSL type string is transformed to Java String.
   4. RSL type boolean is transformed to Java boolean.
4. Each RSL operation is transformed into a Java function definition, with an equivalent input signature, and equivalent output signature if possible.
   1. An RSL input of the form

      name:type
      

      is transformed to a Java formal function parameter of the form:

      type name
      

   2. An RSL operation with a single output is transformed to a Java function that returns that output type.
   3. An RSL operation with more than one output is transformed to a Java function that returns void, with a comment indicating the multiple return types. This function will be refined later in the design process.
5. Figure 5 is a stylized illustration of how the derivation and subsequent refinement steps of the design process relate to one another.

   ---

   

   Figure 5: Stylized view design derivation and refinement.

   ---