Presentation is loading. Please wait.

Presentation is loading. Please wait.

Classic Analysis CS524 – Software Engineering I Azusa Pacific University Professor Dr. Sheldon X. Liang.

Similar presentations


Presentation on theme: "Classic Analysis CS524 – Software Engineering I Azusa Pacific University Professor Dr. Sheldon X. Liang."— Presentation transcript:

1 Classic Analysis CS524 – Software Engineering I Azusa Pacific University Professor Dr. Sheldon X. Liang

2 Classical design References: Structured Analysis and System Specification – Tom Demarco Structured Design: Fundamentals of a Discipline of Computer Program and System Design – Edward Yourdon Object-Oriented & Classical Software Engineering – Stephen R. Schach The Z Notation – J.M. Spivey dictionary.com

3 What is Classical Analysis? Systems Analysis: 1. the evaluation of an activity to identify its desired objectives and determine procedures for efficiently attaining them.

4 What is Classical Analysis? Systems Analysis: 2.Computers. the methodical study of the data-processing needs of a business or department, together with recommendations for specific hardware and software installations.

5 Role of the Analyst The analyst is the liaison between the user and the development team. His final product must be understandable to the users and the developers. He doesn’t tell the developers how to create the product, just what it should do in a very exacting manner.

6 The Goal of Analysis The most important product of systems analysis – is the specification document.” - DeMarco Informal enough for the client Informal enough for the client The client is generally not a computer specialist Formal enough for the developers Formal enough for the developers It is the sole source of information for drawing up the design

7 Completion of the Analysis Phase Successful completion of the analysis phase involves all of the following: (DeMarco) 1. Selecting an optimal target 2. Producing detailed documentation of that target in such a manner that subsequent implementation can be evaluated to see whether or not the target has been obtained

8 Completion of the Analysis Phase Successful completion of the analysis phase involves all of the following: (contd) 3. Producing accurate predictions of the important parameters associated with the target, including costs, benefits, schedules and performance characteristics. 4. Obtaining concurrence on each of the items above from each of the affected parties

9 Specification Document The specification document is the final product of the systems analyst It is a contract between the client and the developer Specifies what the product must do and the constraints on the product

10 Methods of Analysis Three popular graphical specification methods of ’70s DeMarco DeMarco Gane and Sarsen Gane and Sarsen Yourdon Yourdon All are equivalent All are equally good

11 Methods of Analysis Demarco(1979) – Data Flow Diagram Data Dictionary Data Dictionary Structured English Structured English Decision Tables Decision Tables Decision Trees Decision Trees

12 Structured Systems Analysis Gane and Sarsen’s Structured System Analysis Nine Step process to analyze the clients needs Nine Step process to analyze the clients needs Stepwise refinement is used in many steps Stepwise refinement is used in many steps 1.Draw the data flow diagram. 2.Decide what sections to computerize and how (batch or online). 3.Determine the details of the data flows. 4.Define the logic of the process. 5.Define the data stores 6.Define the physical resources. 7.Determine the input-output specifications. 8.Perform the sizing. 9.Determine the hardware requirements.

13 Structured Systems Analysis Sally’s Software Shop buys software from various suppliers and sells it to the public. Popular software packages are kept in stock, but the rest must be ordered as required. Institutions and corporations are given credit facilities, as are some members of the public. Sally’s Software Shop is doing well, with a monthly turnover of 300 packages at an average retail cost of $250 each. Despite her business success, Sally has been advised to computerize. Should she?

14 Structured Systems Analysis The analysts job: What business functions should she computerize? What business functions should she computerize? Accounts payable Accounts receivable Inventory What equipment will they need? What equipment will they need? How much are they willing to spend? How much are they willing to spend?

15 Step 1. Draw the DFD The data flow diagram (DFD) shows the logical data flow “What happens, not how it happens” “What happens, not how it happens” First refinement Infinite number of possible interpretations Infinite number of possible interpretations

16 Second refinement PENDING ORDERS is scanned daily PENDING ORDERS is scanned daily Step 1. Draw the DFD

17 Portion of third refinement

18 Step 2. Decide What Parts to Computerize and How It depends on how much client is prepared to spend Large volumes, tight controls Batch Batch Small volumes, in-house microcomputer Online Online Cost/benefit analysis

19 Step 3. Determine the Details of the Data Flows Determine the data items for each data flow Refine each flow stepwise We need a data dictionary for larger products

20 Step 4. Define the Logic of the Processes We have process give educational discount Sally must explain the discount she gives to educational institutions Sally must explain the discount she gives to educational institutions 10% on up to 4 packages 15% on 5 or more

21 Step 4. Define the Logic of the Processes (contd) Translate this into a decision tree Give educational discount Educational Institution Other: 0% < or = 4 packages: 10% > 4 packages: 15%  The advantage of a decision tree  Missing items are quickly apparent Determine Football Seat Prices Faculty Undergraduate Alumnus 40 yard line: $20 End zone: $12 $2.00 40 yard line: $40

22 Step 5. Define the Data Stores Define the exact contents and representation (format) Java: specify to int/string level Java: specify to int/string level Ada: specify digits or delta Ada: specify digits or delta Specify where immediate access is required Data immediate-access diagram (DIAD) Data immediate-access diagram (DIAD)

23 Step 6. Define the Physical Resources For each file, specify File name File name Organization (sequential, indexed, etc.) Organization (sequential, indexed, etc.) Storage medium Storage medium Blocking factor Blocking factor Records (to field level) Records (to field level) Table information, if a DBMS is to be used Table information, if a DBMS is to be used

24 Step 7. Determine Input/Output Specifications Specify Input forms Input forms Input screens Input screens Printed output Printed output

25 Step 8. Determine the Sizing Obtain the numerical data needed in Step 9 to determine the hardware requirements Volume of input (daily or hourly) Volume of input (daily or hourly) Size, frequency, deadline of each printed report Size, frequency, deadline of each printed report Size, number of records passing between CPU and mass storage Size, number of records passing between CPU and mass storage Size of each file Size of each file

26 Step 9. Determine the Hardware Requirements Mass storage requirements Mass storage for back-up Input needs Output devices Is the existing hardware adequate? If not, recommend whether to buy or lease additional hardware If not, recommend whether to buy or lease additional hardware

27 Structured Systems Analysis Response times cannot be determined The number of I/O channels can only be guessed CPU size and timing can only be guessed Nevertheless, no other method provides these data for arbitrary products Overall The method of Gane and Sarsen/De Marco/ Yourdon has resulted in major improvements in the software industry

28 Entity-Relationship Modeling Semi-formal technique Widely used for specifying databases Widely used for specifying databases Example Example Author Novel Reader Writes Reads Owns 1 1 1 n n n  Many-to-many relationship Supplier Part Is supplied By m n

29 Finite State Machines A finite state machine (FSM) is a model of behavior composed of a finite number of states, transitions between those states, and actions. states

30 Finite State Machines Case study A safe has a combination lock that can be in one of three positions, labeled 1, 2, and 3. The dial can be turned left or right (L or R). Thus there are six possible dial movements, namely 1L, 1R, 2L, 2R, 3L, and 3R. The combination to the safe is 1L, 3R, 2L; any other dial movement will cause the alarm to go off

31 Finite State Machines (contd) The set of states J is {Safe Locked, A, B, Safe Unlocked, Sound Alarm} The set of inputs K is {1L, 1R, 2L, 2R, 3L, 3R} The initial state J is Safe Locked The set of final states J is {Safe Unlocked, Sound Alarm}

32 Figure 11.14 Finite State Machines (contd) Transition table – so you can write it as a matrix to be machine readable.

33 11.8 Petri Nets A major difficulty with specifying real-time systems is timing Synchronization problems Synchronization problems Race conditions Race conditions Deadlock Deadlock Often a consequence of poor specifications

34 Petri Nets (contd) Petri nets Technique for specifying systems that have potential problems with interrelations Technique for specifying systems that have potential problems with interrelations A Petri net consists of four parts: A set of places P A set of places P A set of transitions T A set of transitions T An input function I An input function I An output function O An output function O

35 Petri Nets (contd) Set of places P is {p 1, p 2, p 3, p 4 } Set of transitions T is {t 1, t 2 } Input functions: I(t 1 ) = {p 2, p 4 } I(t 2 ) = {p 2 } Output functions: O(t 1 ) = {p 1 } O(t 2 ) = {p 3, p 3 } Figure 11.18

36 Petri Nets (contd) More formally, a Petri net is a 4-tuple C = (P, T, I, O) P = {p 1, p 2,…,p n } is a finite set of places, n ≥ 0 P = {p 1, p 2,…,p n } is a finite set of places, n ≥ 0 T = {t 1, t 2,…,t m } is a finite set of transitions, m ≥ 0, with P and T disjoint T = {t 1, t 2,…,t m } is a finite set of transitions, m ≥ 0, with P and T disjoint I : T  P ∞ is the input function, a mapping from transitions to bags of places I : T  P ∞ is the input function, a mapping from transitions to bags of places

37 Petri Nets (contd) O : T  P ∞ is the output function, a mapping from transitions to bags of places O : T  P ∞ is the output function, a mapping from transitions to bags of places (A bag is a generalization of a set that allows for multiple instances of elements, as in the example on the previous slide) (A bag is a generalization of a set that allows for multiple instances of elements, as in the example on the previous slide) A marking of a Petri net is an assignment of tokens to that Petri net A marking of a Petri net is an assignment of tokens to that Petri net

38 Petri Nets (contd) Four tokens: one in p 1, two in p 2, none in p 3, and one in p 4 Represented by the vector (1,2,0,1) Represented by the vector (1,2,0,1) Figure 11.19

39 Petri Nets (contd) A transition is enabled if each of its input places has as many tokens in it as there are arcs from the place to that transition

40 Petri Nets (contd) Transition t 1 is enabled (ready to fire) If t 1 fires, one token is removed from p 2 and one from p 4, and one new token is placed in p 1 If t 1 fires, one token is removed from p 2 and one from p 4, and one new token is placed in p 1 Transition t 2 is also enabled Important: The number of tokens is not conserved The number of tokens is not conserved

41 Petri Nets (contd) Petri nets are indeterminate Suppose t 1 fires Suppose t 1 fires The resulting marking is (2,1,0,0)

42 Petri Nets (contd) Now only t 2 is enabled It fires It fires The marking is now (2,0,2,0)

43 Petri Nets (contd) More formally, a marking M of a Petri net C = (P, T, I, O) is a function from the set of places P to the non-negative integers M : P  {0, 1, 2, …} A marked Petri net is then a 5-tuple (P, T, I, O, M )

44 Petri Nets (contd) Inhibitor arcs An inhibitor arc is marked by a small circle, not an arrowhead An inhibitor arc is marked by a small circle, not an arrowhead Transition t 1 is enabled

45 Petri Nets (contd) In general, a transition is enabled if there is at least one token on each (normal) input arc, and no tokens on any inhibitor input arcs

46 Z – A Formal Specification Language Z: The Elevator Problem Case Study A Z specification consists of four sections: 1.Given sets, data types, and constants 1.Given sets, data types, and constants 2.State definition 2.State definition 3.Initial state 3.Initial state 4.Operations 4.Operations Given sets are sets that need not be defined in detail Given Set Names appear in brackets So, for example, here we need the set of all buttons and our specification begins [Button] [Button]

47 2. State Definition Z specification consists of a number of schemata A schema consists of a group of variable declarations, plus A list of predicates that constrain the values of variables In this problem there are four subsets of Button The floor buttons The elevator buttons buttons (the set of all buttons in the elevator problem) pushed (the set of buttons that have been pushed)

48 3. Initial State And Operations The state when the system is first turned on Button_Init ^= [Button_State' | pushed' =  ] Button_Init ^= [Button_State' | pushed' =  ] A button pushed for the first time is turned on, and added to set pushed Without the third precondition, the results would be unspecified

49 Z: The Elevator Problem Case Study If an elevator arrives at a floor, the corresponding button(s) must be turned off This example is VERY oversimplified – doesn’t distinguish between up and down floor buttons

50 Analysis of Z Z is the most widely used formal language It has been used to specify CICS (part) CICS (part) An oscilloscope An oscilloscope A CASE tool A CASE tool Many large-scale projects (especially in Europe) Many large-scale projects (especially in Europe) Difficulties in using Z The large and complex set of symbols The large and complex set of symbols Training in mathematics is needed Training in mathematics is needed

51 Analysis of Z Reasons for the great success of Z It is easy to find faults in Z specifications It is easy to find faults in Z specifications The specifier must be extremely precise The specifier must be extremely precise We can prove correctness (though we don’t have to) We can prove correctness (though we don’t have to) Only high-school math needed to read Z Only high-school math needed to read Z Z decreases development time Z decreases development time A “translation” of a Z specification into English (or another natural language) is clearer than an informal specification A “translation” of a Z specification into English (or another natural language) is clearer than an informal specification

52 Comparison of Classical Analysis Techniques Formal methods are Powerful, but Powerful, but Difficult to learn and use Difficult to learn and use Informal methods have Little power, but are Little power, but are Easy to learn and use Easy to learn and use There is therefore a trade-off Ease of use versus power Ease of use versus power

53 Comparison of Classical Analysis Techniques (contd) Figure 11.29

54 CASE Tools for Classical Analysis A graphical tool is exceedingly useful So is a data dictionary Integrate them Integrate them An analysis technique without CASE tools to support it will fail The SREM experience The SREM experience Typical tools Analyst/Designer Analyst/Designer Software through Pictures Software through Pictures System Architect System Architect

55 Metrics for CASE Tools Five fundamental metrics Size, cost, duration, effort & quality Size, cost, duration, effort & qualityQuality Fault statistics Fault statistics The number, type of each fault The number, type of each fault The rate of fault detection The rate of fault detection Metrics for “predicting” the size of a target product Total number of items in the data dictionary Total number of items in the data dictionary The number of items of each type The number of items of each type Processes vs. modules Processes vs. modules

56 Challenges of Classical Analysis A specification document must be Informal enough for the client; but Informal enough for the client; but Formal enough for the development team Formal enough for the development team Analysis (“what”) should not cross the boundary into design (“how”) Do not try to assign modules to process boxes of DFDs until the classical design phase


Download ppt "Classic Analysis CS524 – Software Engineering I Azusa Pacific University Professor Dr. Sheldon X. Liang."

Similar presentations


Ads by Google