Slides

S1: Meeting 3

S2: 7.1 Specifications, Specification Document

Specifications
- Operational view: activities, experimental performances
- "intelligible to the client" (p. 222)
- "precise enough to result in a fault-free product"
- Unambiguity, completeness, clarity
Specification document "is a contract" (p. 223)
Specification Document May Contain
- Information: flow, content, interfaces
- Function:
  - processing narratives, design constraints, ...
- Non-functional requirements (constraints)
  - Delivery deadline, Reliability, response time
- Behaviour: states, events, actions
- Acceptance criteria
  - test classes, performance bounds
- Q? Is acceptance criteria really a specification?
- Why is it important?

S3: 8.2 Informal Techniques

S4: 8.3-5 Semiformal Techniques: Structured Analysis

Systems analyst = a specifier (MIS domain )
Systems Analysis = process of making the specs
Structured Analysis Methodology uses
- Data Dictionary for narratives
- Data Flow Diagram (DFD)
DFD Notation (See Fig. 8.1, pp 228)
- bubbles for transformers
- boxes for data stores, sources, and destinations
- arrows for data flows
Levels of DFDs
- Level 0: Context diagram (Fig. 8.2)
- Level 1: First decomposition (Fig. 8.3)
- Level (i+1): Elaborate more (Fig. 8.4)
  - i.e. each bubble is simple/well-understood
- Focus: Functional decomposition,
- Pros: End-to-end Data flow analysis
  - What do I need to do to get a drivers license?
- Cons: Data semantics not refined

S5: 8.3-5 Semiformal Techniques: Entity-Relationship Modeling

Information Engineering Methodology
- Data dictionary for item definitions (meta-data)
- Entity Relationship Diagram (ERD)
ERD Notation (See Fig. 8.8)
- boxes for data entities
  - annotations: weak/regular
- ellipses for attributes of entities
  - annotations: key-status, composite, derived, multi-valued
- arrows for relationships
  - annotations: cardinality, participation
- ERD = inspiration behind Class Diagrams in Object Paradigm
- Focus: Data semantics,
- Pros: reduces data inconsistency and duplication
- Cons: Process/function semantics not refined
Csci 5702 (Database I) will elaborate it further!

S6: 8.6-9 Formal Techniques: Finite State Machines

Concepts (See Fig. 8.11 & 8.12, pp 238)
- A set of States
- A set of Inputs/ events
- transition function: f(aState, anInput) returns aState
- The Initial state
- A set of final states
Operational Semantics: Example of Safe (Fig. 8.11)
Intuition about states:
- allow system to remember past inputs/events
- state space can enumerate possible input sequences
- Final states = desirable input sequences
- Error states = undesirable input sequences
Applications: useful for hardware specs, also certain programs
- Scenario Tree requirements analysis = > FSM
- Allows reasoning about system, e.g. Two-hase locking
Csci 5400 (Automata Theory ) elaborates it further

S7: 8.6-9 Formal Techniques: Petri Nets

Concepts (See Fig. 8.11 & 8.12, pp 238)
- A set of Places/States
- A set of transitions
- A Inputs function: I(a transition) returns aSetOfPlaces
- An Outputs function: O(a transition) returns aSetOfPlaces
- A marking function: M(aState) returns aNumberOfTokens
- An initial marking
Operational Semantics: Trace (Fig. 8.17 - 19)
IComments:
- Captures synchronization and concurrency.
  - systems with multiple parts running at the same time
- Csci 5103 (Operating Systems) elaborates synchronization issues
- .e.g. Producer-Consumer, Dining Philospher problems

S8: 8.10 Comparison

Informal techniques
- Easy to lcommunicate with client
- But, prone to ambiguity, imprecision
Formal techniques
- Hard to learn, requires mathematical background
- Hard for clients to understand
- Helps analysis, e.g. correctness proving
- Have not been tested in practice for large systems
Semi-formal techniques
- A trade-off between informal and formal methods
- Have been used in practice, well-understood

S9: 8.11-13 Testing, CASE Tools, Metrics

Testing
- Goal: Correctness, Completeness, Unambiguity
- Methods: walkthrough, inspection
- Testing / Proofs possible with Formal specs
CASE Toolsa
- Graphical Drawing diagrams with consistency checker
- Data dictionary to manage definitions
- e.g. ADW, Teamwork, System Architect, ...
Five Basic Metrics
- A. Quality- number of fault found in specs via inspection
- B. Size - spec size = pages/lines in spec document
  - product size predictor = number of processes in DFD
- C. Cost, D. Duration and E. Effort depend on size

S10: 8.14 MSG Case Study

Informal specification shows up in requirements (7.14)
Semi-formal Structured Analysis in 8.14 (pp. 258)
- Level 1 DFD (Fig. 8.27)
- Q? Where is the data dictionary?
- Q? Draw the context diagram for MSG System.
- Q? How many level 2 DFDs should be drawn?
Q? Compare section 8.14 with 7.14
Analyze DFD in Fig. 8.27 to answer the following:
- Which "data stores" are from requirements (pp. 216)?
- Which "functions" in DFD specify the following requirements?
  - (i) procedure to grant a 100 percent mortgage (pp. 214)
  - (ii) amount the couple pays MSG every week (pp. 215)
  - (iii) whether MSG has funds to approve a mrtgage (pp. 215)
  - (iv) add, modify, delete investments and mortgage data
  - (v) adjust value of annual operating expenses
  - (vi) reports on investments, mortgages, weekly computations
- Q? Refine Fig. 8.27 to add missing functionality .

S11: Conclusions

Q. Data flow diagrams do not represent:
- information flow
- data transforms
- data stores
- control flow
Q. What does a data flow diagram represent ?
- control flow
- information flow
- both of these
- neither of these
Q. A Level 1 DFD with n transforms will have
- how many Level 2 DFDs ?
- zero to n squared
- zero to 2 to the nth power
- zero to 2n
- zero to n