CIS 375 SOFTWARE ENGINEERING

University Of Michigan-Dearborn

Dr. Bruce Maxim, Instructor

ERPP:

Evolutionary rapid prototyping process.

(Write less throwaway code than in spiral model)

Start with Product Plan:


Risks/unknowns inspiring use:

Risks Using ERPP:
    1. Premature delivery.
    2. Premature design selection.
    3. Features in prototype can get lost in final product.
    4. There is a tendency to choose efficiency over modifiability

Requirements Analysis For ERPP:

Design:

(Always has one process, even in ERRP model)

Implementation & Testing:
    1. Code.
    2. Test.
    3. Debug.
    4. Goto 1 (repeat).

Final Spin Cycle:
    1. Leave as is.
    2. Rewritten.
    3. Replace with existing code.
    4. Discard, as no longer needed.

1) Prototype -> spaghetti code.
    1. Prototype -> cannot be extended to meet full user requirements.
    2. Work to fix -> work to start again.

Requirements Specification Methods:
    1. HIPO Chart:

      2. (Hierarchy Input - Output Chart)


      Strengths Weaknesses

      - Shows function - No mechanism for

      relationship. Non-functional requirements.

      - No checking mechanism.

    2. Hierarchical Data Structures:

 

How is it different from object hierarchy:
    1. Data Flow Diagrams:

      2. {square} = producer or consumer of information.

      {circle} = software client capable of transforming information.

      {arrow} = data item.

      {thing} = database.

      Key: this is data flow.

      PSPEC - process specification.

    2. CFD:

      3. Control flow diagram.

      CSPEC - control specification.

    3. General Data Model: (Focus on data)

Data object tables are determined.

Object = record.

Attribute = fields.

Normalization Rules:
    1. Given instance of an object has one value for an attribute.
    2. Attributes represent elementary items.
    3. When more than one attribute is used to identify an object, make sure they describe the same "key".
    4. All non-ID attributes represent the same characteristics of instance named by key.

E-R Diagram:

(Entity relationship)

{squares} = data object.

{diamonds} = relationship between objects.
    1. Decision Table:
 

Rules

  

Condition

1

2

  
 

Rules

  

Actions

1

2

  
    1. Finite state machines:
    1. Event table:

(Like decision table)

Mode

Event1

Event2

Event3

Event4

Presentation Graphics

Action1

Action8

O

X

Architecture

Drawing

X

A2 then A3

A5 & A6

O

Programming

O

A4

A1, A2 & A3

A7

O = no action / no state change.

X = no action defined.
    1. Petri Net:
    1. Sequential processes.

      2. f(state A, event) -> state S.

f(state A, event1, event2, event3) -> state S.

f(state A, event1, event2, event3) -> (state S1, state S2).
    1. Structured analysis and design technique(SADT)

      2. Structured analysis activity diagram:

      (Activity Network)

      Control

      ¯

      Inputs® ¬ Output

      ­

      Mechanism

      Structured analysis data diagram:

      (Data Network)

      Control

      ¯

      Generating Activity® ¬ Resulting Activity

      ­

      Storage Devices

      Design techniques:

      Explains how to interpret results of SA (control issues).

    2. Structured system analysis:

(Database way of attacking things)
    1. Requirements dictionary:

(a.k.a. data dictionary)
    1. Name.
    2. Aliases.
    3. Where something’s used & how it is used (producer & consumer).
    4. Content description (motivation for representation).
    5. Supplementary information - restrictions, limitations.

Procedural Design: (cont.)

{figure 53}

    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.
    1. Warnier diagrams

      2. {figure 54}

    2. Data flow diagrams

Perspective of the system as data transforms.