CSC 395 –Software Engineering

Lecture 28:

Classical Analysis -or-Do You Really Want to Do That?

In This Lecture

Discuss analysis workflow for non-OO projects Alternatives to the large variety of UML diagrams Benefits of varying formality working with clients New techniques with which to analyze code

Specification Document

Main product at end of the analysis workflow Needs to be understood by the client

Need their agreement to move forward Cannot be so formal they cannot comprehend

Must communicate results to developers Sole source of information for the designers Should strive for absolute precision in every detail

Two requirements are mutually contradictory

Document Details

Contract between client and developers Should list important concerns like:

Deadlines, Portability, Reliability, Responsiveness Should list any hard real-time constraints

Also detail acceptance of final product Usually, tests software will need to passed Will often include restating important constraints

Makes sure client happy with end product Also improves odds you get paid in full

Solution Strategy

General approach to building the product Find strategies without worrying about constraints Then modify strategies to fit the constraints

Keep written record of discarded strategies Include why each strategy was discarded Shows analysis team did not just use first idea Prevents unwise “new” solutions from

reappearing

Informal Specifications

Written in natural language Easy for client to understand Easy to read and write Already fluent in these language(s)

Informal specifications also have problems Hard to be precise & detailed in natural languages Makes finding incomplete or contradictory

specifications difficult Watch a lawyer -- precision can be picked apart

Structured Systems Analysis

Three graphical specification methods DeMarco Gane and Sarsen Yourdon

All are equivalent & equally good Often used for commercial products Discuss Gane and Sarsen’s 9-step method

Many parts include stepwise refinement This method among the most commonly used

Data Flow Diagram

Shows flow of data Differs from control

flow diagram “What happens, not

how it happens”

Draw the DFD

Process goes through several refinements Slowly drill down to discover all the details

Final DFD can be quite large But going through process help client understand

If DFDs get to be too large… …set up hierarchy with boxes expanded at lower

levels

What To Computerize & How

Should consider many details Client’s Process being examined If batch or online processing acceptable Often involves cost/benefit analysis

Determine Data Flow Details

Determine data items for each data flow Refine each flow in stepwise manner

Good results rarely known immediately “Measure twice, cut once”

Large products often require data dictionary

Define Processes Logic

Display decisions as decision trees Clearly illustrates process at work Provides insight to necessary data Should highlight items still missing from analysis

Define Data Stores

Specify exact contents & representation Perform to level needed to enable coding Begin with ideal system Slowly modify design to fit with constraints placed

by customer Again, this is process of stepwise refinement

Similar process defines physical resources & I/O handling

Determine the Sizing

Obtain numerical data needed to compute hardware requirements Volume of input, both average and peak Size, frequency, deadline of each printed report Size, number of records passing between CPU

and mass storage Size of each file

Define Arch. Requirements

Storage requirements Back-up needs Input & Output needs Large projects often include designing entire

computer systems Is the existing hardware adequate? Lease additional hardware? Purchased it?

Entity-Relationship Modeling

Another semi-formal technique Widely used for specifying databases Examples:

Formal Methods: FSM

Case studySafe has combination lock with three positions, labeled 1, 2, & 3. Dial can turn left (L) or right (R), making six possible dial movements. Combination is 1L, 3R, 2L; other dial movement cause the alarm sound

Finite State Machines

Set of states J = {Safe Locked, A, B, Safe Unlocked, Sound Alarm}

Set of inputs K = {1L, 1R, 2L, 2R, 3L, 3R} Initial state is Safe Locked

Final states are {Safe Unlocked, Sound Alarm}

Extended FSM

Extend transitions using global predicates Transition rules now take form of

current state and event and predicate new state

Extended FSM have several advantages Easy to write down & validate Easy to convert into design & code Formal method is very precise “Almost as easy to understand”

But cannot capture time-dependent behavior

For Next Lecture

Finish review of classical analysis methods Look at “petri-nets” to analyze requirements Get chance to play with all of these tools DFD & petri-nets used for other uses, too