CIS 375 SOFTWARE ENGINEERING

UNIVERSITY OF MICHIGAN-DEARBORN

DR. BRUCE MAXIM, INSTRUCTOR

Date: 10/27/97

Week 8

PROCEDURAL DESIGN: (CONT.)

S1

Case V of

Case 1: while C1 do

S2

S3

Case 2: S4

S5

Case 3: if C2 then

Repeat

S6

S7

Until C3

Else

S8

S9

1. Decision tables.
2. PDL (program design language)
   1. Fixed syntax for keywords, control structures, data declarations, module declarations.
   2. "Free" natural language syntax.
   3. Data declarations for simple and structured types.
   4. Subprogram definition and call techniques for several interface types.
3. Warnier diagrams

1. Data flow diagrams

Perspective of the system as data transforms.

DATA STRUCTURED SYSTEM DEVELOPMENT (DSSD):

JACKSON SYSTEM DEVELOPMENT (JSD):

1. Entity action step (object, events).
2. Entity structive step.

1. Initial model - entity and action steps = process model.

(SSD = system specification diagram)

Details via structured text

Button1

Read BB

Push BDY iterate while BD

Push

Read BD

Push BDY end

Button1 end

1. Function step.

(function = action spec.)

1. System timing step.

(Process scheduling characteristics)

1. Implementation step

(hw & sw)

DESIGN NOTATION SELECTION CRITERIA:

1. Modularity.
2. Simplicity.
3. Ease of exiting.
4. Machine readability.
5. Structive enforcement.
6. Automatic processing.
7. Maintainability.
8. Data representation (local & global).
9. Logic verification
10. Code generation.

EVALUATE USEFULNESS OF ANY DESIGN TOOL OR METHOD:

1. What is the idea behind it?
2. Ease of use or ease of learning?
3. Effect of tool complexity on design.
4. Promote modularity.
5. How well does the tool integrate with other processes?
6. Ease of modification.
7. Phase development possible?
8. Does it require automated equipment?
9. Portable product?
10. How helpful is the tool?

DESIGN QUALITY:

1. Structure.
2. Error prevention & correction:
   1. Error detection (active/passive).
   2. Defensive designing.
   3. Error correction.
   4. Fault tolerance.
3. Module complexity.

1. Reduce unconditional branching (pitch goto).
2. Eliminate context sensitive module.

1. Simplify flow diagram.

DESIGN REVIEW FOCUS:

1. Design solve problem?
2. Design modular & well structured?
3. Improve modularity?
4. Design portable?
5. Understood by programmers?
6. Appropriate algorithms?
7. Easy phase transition?
8. Well documented?
9. Cross referenced with requirements for modules?
10. Cross referenced with requirements for data?

Date: 10/29/97

Week 8

OBJECT ORIENTED DESIGN:

OBJECT

1. Private data & related operations.
2. Shared part (interface).

ADVANTAGES:

• Modularity is inherent
  1. Decomposability (problem -> sub-problem).
  2. Composability (reusability of pieces).
  3. Understandability (with respect to independence).
  4. Continuity (easy to change).
  5. Protection (encapsulation).

DESIGN PRINCIPLES FOR MODULARITY:

1. Linguistic modular units.

(ADT's should be supported)

1. Few interfaces.
2. Small interfaces (weak coupling).
3. Explicit interfaces (parameter - not common coupling).
4. Information hiding.

O.O.D. GENERIC STEPS:

1. Describe each subsytem, so that it is implementable
   • Allocate systems to processes and tasks.
   • Implement strategy for data management, interface design, task management.
   • Design system control mechanism.
   • Review / tradeoffs.
2. Design objects.
   • Each operation designed at the procedural level.
   • Define internal classes.
   • Define internal data structures for classes.
   • Review design and iterate as required.

O.O.D. (BOOCH - ABBOT METHOD):

1. Define problem.
2. Develop process narrative for software realization of problem domain.
3. Formalize strategy.
   1. Identify object & attributes.
   2. Identify operations which can be applied to objects.
   3. Establish interfaces by showing relationships between objects and operations.
   4. Resolve design details to allow implementation.
4. Recursively apply (2) & (3).
5. Refine work done during O.O.A..
6. Represent data structures associated with object attributes.
7. Represent procedural derail for each operation.

OPERATOR CLASSIFICATIONS:

1. Data manipulator (add, delete, format).
2. Computation.
3. Monitors.

BASIC NOTATION FOR O.O.D.:

• Class diagram (static).

• 
  
  • Object diagram (dynamic).
  • (communication)
  • 
    
  • Object module diagram.
• 
  
  • Process diagram.
• 
  

ALTERNATIVE GENERIC APPROACH TO O.O.D.:

1. Identify the data abstraction for each sub-system.
2. Identify attributes for each data abstraction.
3. Identify operations for each data abstraction.
4. Identify communication between objects.
5. Apply inheritance where appropriate.

OBJECT ORIENTED PROGRAM DESIGN:

1. Undertake object oriented system requirements specification.
2. Identify object and their services.
3. Establish interactions between objects (services required & rendered).
4. Identification of reusable components from previous design.
5. Implementation of low level objects.
6. Introduce inheritance relationships (superclass & subclass).
7. Class combination and generalization.

COMMON DESIGN FLAWS:

1. Classes that make direct modifications to other classes.
2. Classes with too much responsibility.
3. Classes with no responsibility.
4. Classes with unused responsibility .

1. Misleading names.
2. Unconnected responsibility.
3. Inappropriate inheritance.
4. Repeated functionality.

HUMAN FACTORS IN USER INTERFACE DESIGN:

USER INTERFACE; SOFTWARE LEVEL:

• Involves on-line help and documentation (in addition to displays).
• Functionality first, user interface is added at the end as an after-thought.
  • Why?
  • Because managers are rewarded for:
    • Function.
    • Cost.
    • Schedule.
    • {Usability is not here}