Structured Analysis and Structured Design

  • View

  • Download

Embed Size (px)


  • 1.Structured Analysis and Structured DesignPresented by:- Sanjay kumar chakravartiRoll:-RK2R13A28 Reg.-110069643/15/2012 s.k.chakravarti 1

2. AgendaIntroductionSASD Tools and ExercisesPros and ConsComparisons with Other TechniquesConclusionReferences3/15/2012 s.k.chakravarti2 3. Definition of Structured analysis Structured analysis is a set of techniques and graphical tools that allow the analyst to develop a new kind of system specification that are easily understandable to the user. Analysts work primarily with their wits, pencil and paper.3/15/2012 s.k.chakravarti3 4. History of SASD Developed in the late 1970s by DeMarco, Yourdon, and Constantine after the emergence of structured programming. IBM incorporated SASD into their development cycle in the late 1970s and early 1980s. Classical SASD was modified due to its inability to represent real-time systems. In 1989, Yourdon published Modern Structured Analysis.3/15/2012 s.k.chakravarti4 5. History of SASD The availability of CASE tools in the 1990s enabled analysts to develop and modify the graphical SASD models. Interesting Quote: There is no reason for any individual to have acomputer in his home. Kenneth H. Olson, DigitalEquipment Corp. 1977.3/15/2012 s.k.chakravarti5 6. Philosophy of structured analysis and design Analysts attempt to divide large, complex problems into smaller, more easily handled ones. Divide and Conquer Top-Down approach (Classical SA), or Middle-Out (Modern SA) Functional view of the problem. Form follows function Analysts use graphics to illustrate their ideas whenever possible. Analysts must keep a written record.3/15/2012 s.k.chakravarti6 7. Philosophy of structured analysis and design [The purpose of SASD] is to develop a useful, high quality information system that will meet the needs of the end user. [Yourdon, 1989]3/15/2012 s.k.chakravarti 7 8. Goals of SASD Improve Quality and reduce the risk of system failure Establish concrete requirements specifications and complete requirements documentation Focus on Reliability, Flexibility, and Maintainability of system3/15/2012 s.k.chakravarti8 9. SASD Approach to Development CycleExisting or Install and OperateForeseen Requirements Conditions DefinitionAnalysisFunctional DesignArchitecture System Build ArchitectureOperationalSystem3/15/2012 s.k.chakravarti 9 10. Drivers Behind SASD Creation Prior to SASD, requirements were documented through text rather than graphically. Large problem decomposition. Reduces redundancies. If the automobile followed the same development as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year killing everyone inside. Robert Cringley3/15/2012 s.k.chakravarti10 11. Characteristics of a Good AnalysisMethod Graphical with supporting text. Allow system to be viewed in a top-down and partitioned fashion. Minimum redundancies. Reader should be able to predict system behaviour. Easy to understand by user.3/15/2012 s.k.chakravarti11 12. Elements of Structured Analysis andDesign Essential Model EnvironmentalBehavioural ModelModel Implementation Model3/15/2012 s.k.chakravarti 12 13. Essential Model Model of what the system must do. Does not define how the system will accomplish its purpose. Is a combination of the environmental and behavioural model.Essential Model EnvironmentalBehavioural ModelModelImplementation Model3/15/2012 s.k.chakravarti 13 14. Environmental Model Defines the scope of the proposed system. Defines the boundary and interaction between the system and the outside world. Composed of: Statement of Purpose, Context Diagram, and Event List.Essential Model EnvironmentalBehavioural ModelModelImplementation Model3/15/2012 s.k.chakravarti 14 15. Behavioural Model Model of the internal behaviour and data entities of the system. Models the functional requirements. Composed of Data Dictionary, Data Flow Diagram, Entity Relationship Diagram, Process Specification, and State Transition Diagram.Essential ModelEnvironmentalBehaviouralModelModel Implementation Model3/15/2012 s.k.chakravarti15 16. Implementation Model Maps the functional requirements to the hardware and software. Minimizes the cost of development and maintenance. Determines which functions should be manual vs. automated. Can be used to discuss the costs-benefits of functionality with the users/stakeholders. Defines the Human-Computer Interface. Defines non-functionalEssential Modelrequirements. EnvironmentalModel Behavioural Model Tool: Structure ChartsImplementation Model3/15/2012 s.k.chakravarti16 17. Analysis & Design Process Environmental Model Statement of Behavioural ModelPurposeImplementationActivity Context Diagram Event ListData DictionaryModel ERD DFD Process Specification State Transition DiagramStructure Charts Time3/15/2012s.k.chakravarti 17 18. Statement of Purpose A clear and concise textual description of the purpose for the system. It is deliberately vague. It is intended for top level management, user management, and others who are not directly involved in the system.3/15/2012 s.k.chakravarti 18 19. Statement of Purpose - Example The purpose of the credit card system is to provide a means for the company to extend credit to the customer. The system will handle details of credit application, credit management, billing, transaction capture, remittance, and management reporting. Information about transactions should be available to the corporate accounting system.3/15/2012 s.k.chakravarti 19 20. Context Diagram - Purpose Highlights the boundary between the system and the outside world. Highlights the people, organizations, and outside systems that interact with the system under development. Special case of the data flow diagram.3/15/2012 s.k.chakravarti20 21. Context Diagram - NotationProcess - Represents the proposed systemTerminator - Represents the external entitiesFlow - Represents the in and out data flows3/15/2012 s.k.chakravarti 21 22. Context Diagram - ExampleCustomer ServiceApplication Customer Credit Bills PaymentCredit Card Overdue CollectionProcessingAccounts CompanyCorporateAccounting Account TransactionSystemSummaryPaymentStore3/15/2012 s.k.chakravarti22 23. Event List - Purpose A list of the events/stimuli outside of the system to which it must respond. Similar to use-cases3/15/2012 s.k.chakravarti23 24. Event List - Types Flow Oriented Event. (Process is triggered by incoming data). Temporal Event. (Process is triggered by internal clock). Control Event. (Process is triggered by an external unpredictable event).3/15/2012 s.k.chakravarti24 25. Event List - Example Customer applies for a credit card. Customer makes a transaction at a store. Customer pays a bill. Customer disputes charges. Customer Service changes credit terms.3/15/2012 s.k.chakravarti25 26. Data Flow Diagram - Purpose Provides a means for functional decomposition. Primary tool in analysis to model data transformation in the system.3/15/2012 s.k.chakravarti 26 27. Data Flow Diagram - NotationRepresents functions in the systemRepresents the external entitiesRepresents data flowsRepresents data stores3/15/2012 s.k.chakravarti27 28. Data Flow Diagram - Example New Transaction Customer Customer* 1.0 2.0 Store CardTransactionProcessNumberOpen toCapture Authorization ApplicationCardsBuyAccountDetails TransactionAccount3.0 Transaction Total Transaction BillTransactionsCustomer Cheque Amount Credit TermsStatus Overdue5.0 Customer Amount Service4.0 Determine Overdue AccountOverdueProcess AccountsPayment Cheque Customer* Collection Company3/15/2012 s.k.chakravarti28 29. Data Flow Diagram - Levelingchequecheque4.14.2 4.4 Read CheckPayment Status Update 4 AccountProcessPayment4.3 Processamount, Paymentaccount amount, Account account3/15/2012 s.k.chakravarti29 30. Data Flow Diagram ValidationBlack HoleSpontaneous3/15/2012 s.k.chakravarti30 31. Data Flow Diagram Validation3/15/2012 s.k.chakravarti31 32. Context diagram - Exercise System context diagramCashinvoicerequirements-report Pay- Vendorinvoice management Paymentpaymentauthorization Cash-requirement reportaccounting[Kendall 1996]3/15/2012 s.k.chakravarti32 33. Data Flow Diagram - Exercise Build a level 0 DFD3/15/2012 s.k.chakravarti 33 34. Data Flow Diagram-level 0 Solution 2. 1. Valid invoice detailsCheck Invoiceinvoice Check validPayment Cash requirements reportInvoiceauthorization Purchase order Packing slip item details details vendorsPurchase ordersPendingPacking slipinvoicesitem details Payment authorization 3.payment authorization (Manual) Produce paymentPayment3/15/2012 s.k.chakravarti34 35. Data Dictionary - Purpose Defines data elements to avoid different interpretations.3/15/2012 s.k.chakravarti 35 36. Data Dictionary - Purpose Example: Alien: Whats a name? Person: Well, you know, its just a name. Its what we call each other. Alien: Does that mean you can call them something different when youare angry or happy? Person: No, of course not. A name is the same all the time. Alien: Now I understand. My name is 3.141592653. Person: Oh your name is PIBut thats a number, not a name. But whatabout your first and last name. Or is your first name 3, and your last name141592653?3/15/2012 s.k.chakravarti 36 37. Data Dictionary Notation =is composed of +and () element is optional {} iteration [] select one of a list of elements |seperates choices of elements ** comments @identifier for a store (unique id)3/15/2012 s.k.chakravarti 37 38. Data Dictionary - Examples Element Name= Card Number Definition= *Uniquely identifies a card* Alias = None Format= LD+LD+LD+LD+SP+ LD+LD+LD+LD+SP+LD+LD+LD+LD+SP+LD+LD+LD+LD SP= *Space* LD= {0-9} *Legal Digits* Range = 5191 0000 0000 0000 to5191 9999 9999 99993/15/2012 s.k.chakravarti 38 39. Data Dictionary - ExerciseBuild data dictionary items for the vendor name and vendoraddress3/15/2012 group 3: SASD39 40. Data dictionary - SolutionElement Name = Vendor NameAlias= noneFormat = 30 chara