Structured Analysis

Home , Structured analysis

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Lecture 15: Structured Analysis Structured Modeling Methods ➜ Definition Structured Analysis is a data-oriented approach to conceptual modeling ➜ Basics of Structured Analysis Common feature is the centrality of the dataflow diagram Notations used Mainly used for information systems Modeling Process variants have been adapted for real-time systems ➜ Modeling process: indicative optative Variants (existing system) (new system) SADT Abstract SASS (essential functions) 2. Current 3. New logical logical system system SSADM SRD Concrete 1. Current 4. New ➜ Advantages and Disadvantages (detailed model) physical system physical system Model of current physical system only useful as basis for the logical model Distinction between indicative and optative models is very important: Must understand which requirements are needed to continue current functionality, and which are new with the updated system © 2001, Steve Easterbrook 1 © 2001, Steve Easterbrook 2

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Central Concepts Modeling tools Source: Adapted from Svoboda, 1990, p257 Source: Adapted from Svoboda, 1990, p258-263 ➜ Process (data transformation) ➜ External entity ➜ Data flow diagram activities that transform data An activity outside the target system Context diagram (“Level 0”) related by dataflows to other Acts as source or destination for whole system as a single process processes, data store, and external dataflows that cross the system entities. boundary intermediate level DFDs decompose each process External entities cannot interact ➜ functional primitives are processes that cannot be decomposed further Data flow directly with data stores indicate passage of data from output ➜ Data dictionary of one entitie to input of another ➜ Data group represent a data group or data A cluster of data represented as a Defines each data element and data group element single dataflow Use of BNF to define structure of data groups Consists of lower level data groups, ➜ Data store or individual elements ➜ Primitive Process Specification a place where data is held for later use ➜ Data element Each functional primitive has a “mini-spec” Data stores are passive: no a basic unit of data these define its essential procedural steps transformations are performed on Expressed in English narrative, or some form of pseudo-code the data ➜ Structured Walkthrough

© 2001, Steve Easterbrook 3 © 2001, Steve Easterbrook 4 University of Toronto Department of Computer Science University of Toronto Department of Computer Science Hierarchies of DFDs Data Dictionary & Process Specs Source: Adapted from Svoboda, 1990, p262-4 Level 0: Context Diagram Level 1: Whole System customer query ExampleExample DataData DictionaryDictionary customer customer ExampleExample Mini-SpecMini-Spec query Mailing Label = ticket Mailing Label = FOR EACH Shipped-order-detail customer customer_name + FOR EACH Shipped-order-detail system 1. travel customer_name + tickets determine request Timetables customer_address GET customer-name + customer- booking 2. customer_address GET customer-name + customer- form of confirmation check address travel schedule customer_name = address booking schedule customer_name = booking proposed customer_last_name + FORFOR EACHEACH part-shippedpart-shipped request itinerary customer_last_name + system proposed customer_first_name + GET retail-price itinerary customer_first_name + GET retail-price 3. Fare tables customer_middle_initial reserve 4. customer_middle_initial MULTIPLYMULTIPLY retail-priceretail-price byby seats issue fares customer_address = quantity-shipped Level 2: subprocesses booked tickets customer_address = quantity-shipped Level n: subprocesses booking itinerary local_address + TO OBTAIN total-this-order Level n: subprocesses request tickets local_address + TO OBTAIN total-this-order check 3.1 seating prefs community_address + zip_code booking community_address + zip_code schedule request booking CALCULATE shipping-and-handling Proposed 3.1 booking customer CALCULATE shipping-and-handling reser- booking confirmation preferences request3.1 request system local_address = itinerary vations booking booking local_address = ADD shipping-and-handling TO preferences res.request request ADD shipping-and-handling TO Req id. house_number + street_name + Request id. res. request request house_number + street_name + total-this-order Request id. booking total-this-order RequestReq id. id. booking (apt_number) issue 3.3. Request id.system (apt_number) TO OBTAIN total-this-invoice 3.2. systembooking TO OBTAIN total-this-invoice tickets 3.2. collate confirm system community address = booked log3.2. seat confirm-3.3. booking community address = PRINT invoice bookinglog PRINT invoice itinerary timestampsdata ationstrack3.3. confirmationbooking city_namecity_name ++ [state_name[state_name || timestamps track confirmationbooking province_name] confirmation province_name]

University of Toronto Department of Computer Science University of Toronto Department of Computer Science DFD variants SASS methodology Source: Adapted from Svoboda, 1990, p264-5 Source: Adapted from Davis, 1990, p83-86 Control data 1. Study current environment Structured Analysis and Design Technique (SADT) draw DFD to show how data flows through current organization Developed by Doug Ross in the mid-70’s Transformed label bubbles with names of organizational units or individuals Uses activity diagrams rather than dataflow Incoming Activity data diagrams data Distinguishes control data from processing data 2. Derive logical equivalents Performing replace names with action verbs Structured Analysis and System Specification mechanism (SASS) merge bubbles that show the same logical function Developed by Yourdon and DeMarco in the mid-70’s delete bubbles that don’t transform data ‘classic’ structured analysis Structured System Analysis (SSA) 3. Model new logical system Name Developed by Gane and Sarson Modify current logical DFD to show how info will flow once new system is ID Notational style slightly different from Yourdon & in place DeMarco Name Don’t distinguish (yet) which components will be automated Adds data access diagrams to describe contents of data stores 4. Define a number of automation alternatives Structured Requirements Definition (SRD) ID document each as a physical DFD Developed by Ken Orr in the mid-70’s Name Analyze each with cost/benefit trade-off Introduces the idea of building separate models for Select one for implementation each perspective and then merging them ID Name Write the specification © 2001, Steve Easterbrook 7 © 2001, Steve Easterbrook 8 University of Toronto Department of Computer Science University of Toronto Department of Computer Science Alternative Process Model: SRD Later developments Source: Adapted from Davis, 1990, p72-75 1. Define a user-level DFD ➜ Later work recognized that: interview each relevant individual in the current organization development of both current physical and current logical models is overkill actually a role, rather than an individual top down development doesn’t always work well for complex systems Identify the inputs and outputs for that individual entity-relationship diagrams are useful for capturing complex data Draw an ‘entity diagram’ showing these inputs and outputs ➜ Structured Analysis / Real Time (SA/RT) 2. Define a combined user-level DFD Developed by Ward and Mellor in the mid-80’s Merge all alike bubbles to create a single diagram Extends structured analysis for real-time systems Resolve inconsistencies between perspective Adds control flow, state diagrams, and entity-relationship models 3. Define the application-level DFD ➜ Modern Structured Analysis Draw the system boundary on the combined user-level DFD Captured by Yourdon in his 1989 book Then collapse everything within the boundary into a single process Uses two models: the environmental model and the behavioral model together these comprise the essential model 4. Define the application-level functions Includes plenty of advice culled from many years experience with structured label the inputs and outputs to show the order of processing for each analysis function I.e. for function A, label the flows that take part in A as A1, A2, A3,... © 2001, Steve Easterbrook 9 © 2001, Steve Easterbrook 10

University of Toronto Department of Computer Science University of Toronto Department of Computer Science Real-time extensions Source: Adapted from Svoboda, 1990, p269 Evaluation of SA techniques Source: Adapted from Davis, 1990, p174 Current Line gauge tension ➜ Enable Advantages Line Control Line tension Enable line Facilitate communication. status Disable conditions KEY Notations are easy to learn, and don’t require software expertise Disable 3.1 Report material Clear definition of system boundary line Control status Tension off inlet Use of abstraction and partitioning name Transfor- 3.2 Tension ok Enable 3.3 mation Automated tool support ID Enable Disable Disable e.g. CASE tools provide automated consistency checking Control flow Inlet control (discrete) ➜ Disadvantages Control flow Little use of projection Controlling (continuous) Monitor even SRD’s ‘perspectives’ are not really projection tension Control name Confusion between modeling the problem and modeling the solution Current Tension Store 3.4 most of these techniques arose as design techniques tension 3.5 These approaches model the system, but not its application domain Tension settings table Tension Timing & control issues are completely invisible inlet control Although extensions such as Ward-Mellor attempt to address this

van Vliet, H. “Software Engineering: Principles and Practice (2nd Edition)” Wiley, 1999.

In common with many authors, van Vliet does not separate structured analysis from structured design. This makes sense because the two are intended to be used together. Section 11.2.2 gives a nice overview of the whole process, based on Yourdon’s notations (SASS & descendents). He also gives a good introduction to SADT in section Section 9.3.3. Svoboda, C. P. “Structured Analysis”. In Thayer, R. H and Dorfman, M. (eds.) “Software Requirements Engineering, Second Edition”. IEEE Computer Society Press, 1997, p255-274 Excellent overview of the history of structured analysis, and a comparison of the variants

Davis, A. M. “Software Requirements: Analysis and Specification”. Prentice-Hall, 1990.