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 study Safe 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