• Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
10,642
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
317
Comments
0
Likes
2

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Structured Analysis and Structured Design Presented by:- Sanjay kumar chakravarti Roll:-RK2R13A28 Reg.-110069643/15/2012 s.k.chakravarti 1
  • 2. Agenda • Introduction • SASD Tools and Exercises • Pros and Cons • Comparisons with Other Techniques • Conclusion • References3/15/2012 s.k.chakravarti 2
  • 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.chakravarti 3
  • 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.chakravarti 4
  • 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 a computer in his home.” Kenneth H. Olson, Digital Equipment Corp. 1977.3/15/2012 s.k.chakravarti 5
  • 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.chakravarti 6
  • 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.chakravarti 8
  • 9. SASD Approach to Development Cycle Existing or Install and Operate Foreseen Requirements Conditions Definition Analysis Functional Design Architecture System Build Architecture Operational System3/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.chakravarti 10
  • 11. Characteristics of a Good Analysis Method • 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.chakravarti 11
  • 12. Elements of Structured Analysis and Design Essential Model Environmental Behavioural Model Model 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 Environmental Behavioural Model Model Implementation 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 Environmental Behavioural Model Model Implementation 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 Model Environmental Behavioural Model Model Implementation Model3/15/2012 s.k.chakravarti 15
  • 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-functional Essential Model requirements. Environmental Model Behavioural Model •Tool: Structure Charts Implementation Model3/15/2012 s.k.chakravarti 16
  • 17. Analysis & Design Process Environmental Model Statement of Behavioural Model Purpose Implementation Activity Context Diagram Event List Data Dictionary Model ERD DFD Process Specification State Transition Diagram Structure Charts Time3/15/2012 s.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.chakravarti 20
  • 21. Context Diagram - Notation Process - Represents the proposed system Terminator - Represents the external entities Flow - Represents the in and out data flows3/15/2012 s.k.chakravarti 21
  • 22. Context Diagram - Example Customer Service Application Customer Credit Bills Payment Credit Card Overdue Collection Processing Accounts Company Corporate Accounting Account Transaction System Summary Payment Store3/15/2012 s.k.chakravarti 22
  • 23. Event List - Purpose • A list of the events/stimuli outside of the system to which it must respond. • Similar to “use-cases”3/15/2012 s.k.chakravarti 23
  • 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.chakravarti 24
  • 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.chakravarti 25
  • 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 - Notation Represents functions in the system Represents the external entities Represents data flows Represents data stores3/15/2012 s.k.chakravarti 27
  • 28. Data Flow Diagram - Example New Transaction Customer Customer* 1.0 2.0 Store Card Transaction Process Number Open to Capture Authorization Application Cards Buy Account Details Transaction Account 3.0 Transaction Total Transaction Bill Transactions Customer Cheque Amount Credit Terms Status Overdue 5.0 Customer Amount Service 4.0 Determine Overdue Account Overdue Process Accounts Payment Cheque Customer* Collection Company3/15/2012 s.k.chakravarti 28
  • 29. Data Flow Diagram - Leveling cheque cheque 4.1 4.2 4.4 Read Check Payment Status Update 4 Account Process Payment 4.3 Process amount, Payment account amount, Account account3/15/2012 s.k.chakravarti 29
  • 30. Data Flow Diagram – Validation Black Hole Spontaneous3/15/2012 s.k.chakravarti 30
  • 31. Data Flow Diagram – Validation3/15/2012 s.k.chakravarti 31
  • 32. Context diagram - Exercise • System context diagram Cash invoice requirements-report Pay- Vendor invoice management Payment payment authorization Cash-requirement report accounting [Kendall 1996]3/15/2012 s.k.chakravarti 32
  • 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 details Check Invoice invoice Check valid Payment Cash requirements report Invoice authorization Purchase order Packing slip item details details vendors Purchase orders Pending Packing slip invoices item details Payment authorization 3. payment authorization (Manual) Produce payment Payment3/15/2012 s.k.chakravarti 34
  • 35. Data Dictionary - Purpose • Defines data elements to avoid different interpretations.3/15/2012 s.k.chakravarti 35
  • 36. Data Dictionary - Purpose • Example: – Alien: “What’s a name?” – Person: “Well, you know, it’s just a name. It’s what we call each other.” – Alien: “Does that mean you can call them something different when you are 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 PI…But that’s a number, not a name. But what about your first and last name. Or is your first name 3, and your last name 141592653?”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 to 5191 9999 9999 99993/15/2012 s.k.chakravarti 38
  • 39. Data Dictionary - Exercise Build data dictionary items for the vendor name and vendor address3/15/2012 group 3: SASD 39
  • 40. Data dictionary - Solution Element Name = Vendor Name Alias = none Format = 30 characters Element Name = Vendor Address Alias = none Format =Vendor street + Vendor city + Vendor Province + Vendor Postal Code + Vendor Country3/15/2012 s.k.chakravarti 40
  • 41. Entity Relationship Diagram (ERD) - Purpose • A graphical representation of the data layout of a system at a high level of abstraction. • Defines data elements and their inter- relationships in the system.3/15/2012 s.k.chakravarti 41
  • 42. Entity Relationship Diagram - Notation Data Element Relationship Associated Object Cardinality – Exactly one Cardinality – Zero or one Cardinality – Mandatory Many Cardinality – Optional Many3/15/2012 s.k.chakravarti 42
  • 43. Entity Relationship Diagram - Example Payments receive Bills are made generate Accounts of Transactions contains pay for include Cards Transaction_ products3/15/2012 s.k.chakravarti 43
  • 44. Entity Relationship Diagram - Exercise Create an ERD for the Warm Boot Manufacturing System3/15/2012 s.k.chakravarti 44
  • 45. Entity-Relationship diagram - Solution PACKING-SLIP- INVENTORY-ITEMS receives ITEM-DETAILS orders itemizes PURCHASE-ORDER ITEM-DETAILS includes PACKING-SLIP- DETAILS itemizes Purchases VENDORS PURCHASE-ORDERS from Bills for PENDING-INVOICES Owed to3/15/2012 s.k.chakravarti 45
  • 46. Structure Charts - Purpose • Functional Decomposition (Divide and conquer) • Information hiding • Modularity • Low coupling • High internal cohesion3/15/2012 s.k.chakravarti 46
  • 47. Transform Analysis Central 4.6 payment Customer Transform Insert 4.3 Payment cheque, Process Payments bill stub Payment account, 4.5 4.1 amount Update Read Payment account, Open To amount Buy payment 4.4 edited Update payment Balance account, 4.2 amount Edit account, Payment Afferent amount Efferent Accounts Flow Flow3/15/2012 s.k.chakravarti 47
  • 48. Structure Charts Input Process Output (Afferent Flow) Central Transform) (Efferent Flow) Control Input Process Output3/15/2012 s.k.chakravarti 48
  • 49. Structure Charts - Notation Modules Library modules Module call Data Flag3/15/2012 s.k.chakravarti 49
  • 50. Structure Charts - Cohesion Functional Elements are combined to complete one specific function. Sequential Elements are combined because data flows from one step to another. • Communicational Elements are combined because they all act on one data store. Procedural Elements are combined because control flows from one step to another.3/15/2012 s.k.chakravarti 50
  • 51. Structure Charts - Cohesion Temporal Statements are together because they occur at the same time. Logical Elements are together because of their type of function such as all edits. Coincidental Elements are grouped together randomly3/15/2012 s.k.chakravarti 51
  • 52. Structure Charts - Coupling Indirect relationship Modules are independent and there is no way to communicate. Data Only necessary data is passed between two modules. Stamp A data structure is passed to a module but the module only needs a portion of the data in the data structure. Control Flags are passed between modules.3/15/2012 s.k.chakravarti 52
  • 53. Structure Charts - Coupling External Two or more modules reference the same piece of external data . This is unavoidable in traditional batch processing. Common Modules access data through global variables. Content One module changes the data of another module.3/15/2012 s.k.chakravarti 53
  • 54. Structure Charts - Example Payment Process Payment Control Error Payment Payment Payment Process Get Payment Today Write Payment Process Payment Payment Raw Payment PaymentPayment Error Raw Payment Update Insert Payment Account Payment Read Edit Event Record Record3/15/2012 s.k.chakravarti 54
  • 55. Process Specifications - Purpose • Shows process details which are implied but not shown in a DFD. • Specifies the input, output, and algorithm of a module in the DFD. • Normally written using pseudo-code.3/15/2012 s.k.chakravarti 55
  • 56. Process Specifications - Example Apply Payment For all payments If payment is to be applied today or earlier And has not yet been applied Read account Read amount Add amount to account’s open to buy Add amount to account’s balance Update payment as applied3/15/2012 s.k.chakravarti 56
  • 57. State Transition Diagram - Purpose • Shows the time ordering between processes3/15/2012 s.k.chakravarti 57
  • 58. State Transition Diagram – Notation Objects Transitions3/15/2012 s.k.chakravarti 58
  • 59. State Transition Diagram – Example Customer Customer Active pays bills makes purchase Account. Account Balance Customer application makes purchase Customer Create request to New Account. close account & Customer No Balance pays balance does not pay bills Closed Bad Debt Account. Account. No Balance Balance3/15/2012 s.k.chakravarti 59
  • 60. Following steps • Draw structure chart for each function • Document process description for each module(Detailed Design) • Document data dictionary(add flags and the files’ structures into analysis dictionary) • Report, screen and source Document Design3/15/2012 s.k.chakravarti 60
  • 61. Pros of SASD • It has distinct milestones, which allows for easier project management tracking • Very visual – easier for users/programmers to understand • Makes good use of graphical tools • Well known in industry • A mature technique • Process-oriented approach is a natural way of thinking3/15/2012 s.k.chakravarti 61
  • 62. Pros of SASD • Flexible • Provides a means of requirements validation • Relatively simple and easy to read3/15/2012 s.k.chakravarti 62
  • 63. Pros of SASD Context Diagram: • Provides a black box overview of the system and the environment Event List: • Provides guidance for functionality • Provides a list of system inputs and outputs • Means of requirements summarization • Can be used to define test cases DFD: • Ability to represent data flows • Functional decomposition- divide and conquer3/15/2012 s.k.chakravarti 63
  • 64. Pros of SASD Data Dictionary: • Simplifies data requirements • Used at high or low level analysis ERD: • Commonly used; well understood • Graphical tool; easy to read by analysts • Data objects and relationships are portrayed independently from the processes • Can be used to design database architecture • Effective tool to communicate with DBAs3/15/2012 s.k.chakravarti 64
  • 65. Pros of SASD Process Specifications: • Expresses the process specifications in a form that can be verified. State Transition Diagrams: • Models real time behaviour Structure Charts: • Modularity improves system maintainability • Provides a means for transition from analysis to design • Provides a synchronous hierarchy of modules3/15/2012 s.k.chakravarti 65
  • 66. Cons of SASD • It ignores non-functional requirements • Minimal management involvement • Non-iterative; waterfall approach • Not enough user-analyst interaction • Doesn’t provide a communication process with users • Hard to decide when to stop decomposing3/15/2012 s.k.chakravarti 66
  • 67. Cons of SASD • Doesn’t address stakeholders’ needs • Doesn’t work well with Object-Oriented programming languages3/15/2012 s.k.chakravarti 67
  • 68. Cons of SASD Context Diagram: • Does not provide a specific means to determine the scope of the system. Event List: • Does not define all functionality (ex. Edits) • Does not define specific mechanism for interaction. DFD: • Weak display of input/output detail • Users find it confusing initially • Do not represent time • No implied sequencing • Assign data stores early in the analysis with little deliberation3/15/2012 s.k.chakravarti 68
  • 69. Cons of SASD Data Dictionary: • No functional details • Formal language is confusing to users ERD: • May be confusing for users; formal notation • Complex in large systems Structure Charts: • Does not work well for asynchronous processes such as networks • Could be too large to be effectively understood with large programs.3/15/2012 s.k.chakravarti 69
  • 70. Cons of SASD Process Specifications: • They may be too technical for the users • Difficult to stay away from the current “How” State Transition Diagrams: • Explains what action causes a state change but not when or how often3/15/2012 s.k.chakravarti 70
  • 71. Where to use SASD? • In well known problem domains • With contract projects where SRS is specified • In both real-time systems and transaction processing systems • Not appropriate when time to market is short3/15/2012 s.k.chakravarti 71
  • 72. SASD vs. OOAD Similarities • Both SASD and OOAD had started off from programming techniques • Both techniques use graphical design and graphical tools to analyze and model the requirements. • Both techniques provide a systematic step-by-step process for developers • Both techniques focus on documentation of the requirements3/15/2012 s.k.chakravarti 72
  • 73. SASD vs. OOAD Differences • SASD is Process-Oriented • OOAD is Data-Oriented • Another difference is that OOAD encapsulates as much of the systems data and processes into objects • while SASD separates between them3/15/2012 s.k.chakravarti 73
  • 74. SASD vs. Agile Methods similarities: facilitate stakeholder communication 3/15/2012 s.k.chakravarti 74
  • 75. SASD vs. Agile Methods (1) Differences  SASD emphasizes requirement documentation Agile supports a process of requirements elicitation  SASD uses top-down process from analysis to design Agile uses incremental process from requirement elicitation to final system integration and delivery  SASD uses formal analysis and design tools for each step, such as data flow diagram. Agile Methods have solid technique for requirement analysis and design, Agile Methods use pair programming, test first and customer onsite techniques.  SASD is performed by analysts, users and designers Agile Methods team involve project manager, customers and programmers3/15/2012 s.k.chakravarti 75
  • 76. SASD vs. Agile Methods (2) Differences • SASD focuses on building a design model • Agile methods dont allow for too much planning • Agile methods use prototyping with short iterative life cycles • SASD requires longer life cycles because of the analysis and design involved • SASD is good for long term planning • Agile Methods is good for short term quick software releases • Agile methods require frequent user interaction • SASD doesnt require too much user interaction3/15/2012 s.k.chakravarti 76
  • 77. SASD vs. CleanroomSimilarities:• Both use top-down development process Both use decomposition to analyze the system Both use diagrams to demonstrate different components of the system: - Context Diagram VS. Black Box - State Transition Diagram VS. State Box - Data Flow Diagram VS. Clear Box 3/15/2012 s.k.chakravarti 77
  • 78. SASD vs. Cleanroom Differences: • SASD emphasizes on requirement documentation and facilitate human communication  Cleanroom doesn’t support requirement elicitation  SASD is non-iterative in both analysis and design phases  Cleanroom uses incremental development and go through requirement analysis, design, coding and verification  SASD uses system modeling techniques from different system perspectives and uses modularity design techniques with tool support • Cleanroom uses usage model, box structure design, formal specification and statistical certification techniques  SASD is performed by analysts, users and designers • Cleanroom needs cooperation of different teams in different development phases.3/15/2012 s.k.chakravarti 78
  • 79. SASD vs. QFDSimilarities: Both involve analysts and system designers Both used in requirements analysis 3/15/2012 s.k.chakravarti 79
  • 80. SASD vs. QFD Differences:  SASD supports human communication and requirement documentation QFD prioritizes customer requirements for requirement analysis  SASD uses top-down decomposition process from requirements analysis to system design QFD uses prioritizing and comparison of customer requirements and techniques from analysis to design  SASD uses system modeling techniques and tools aided by system specification QFD uses HOQ matrix for prioritizing and comparisons  SASD is performed mainly by development team and discussed with users if it is necessary QFD involves development team, customer, market analysts and system analysts. It emphasize on customer consideration.3/15/2012 s.k.chakravarti 80
  • 81. SASD vs. QFD Differences: • SASD takes us a step further than QFD into building an implementation model • QFD is used mostly for competitor analysis for generic products • SASD is used to build user-specific systems3/15/2012 s.k.chakravarti 81
  • 82. SASD vs. JADSimilarities:• Both support customer-analyst communication and requirements documentation Both need user support 3/15/2012 s.k.chakravarti 82
  • 83. SASD vs. JAD Differences:  SASD uses top-down decomposition process for requirements analysis and system design JAD uses knowledge sharing and decision making by defined group session steps at the beginning of requirement elicitation and system design  SASD uses system modeling with tools support JAD uses group session to share information from users and make decision jointly  SASD is performed by mainly system analysts and designers  JAD needs a session leader, executive sponsor, a specialist, one analyst.  JAD requires good communication between users and analysts  SASD focuses more on analysis and design without much interaction with users  JAD focuses on Customer satisfaction  SASD focuses on quality design3/15/2012 s.k.chakravarti 83
  • 84. SASD vs. SSMSimilarities:• Both focus on communication with stakeholders• Both have consideration of organizational/user impact• Both have the ability to model requirements 3/15/2012 s.k.chakravarti 84
  • 85. SASD vs. SSMDifferences: SSM uses Rich Pictures to record the systems analysis SASD uses DFD’s to record the requirements analysis SSM is goal-driven to a desirable future system SASD starts with current situation and tries to improve it SASD has a limited boundary to build or improve a system SSM considers a broad view of the environment (world view) 3/15/2012 s.k.chakravarti 85
  • 86. Class Discussion of SASD • Have you ever used SASD? • Does it reduce maintainability costs? • Is it Useful? • Is it efficient? • Is it appropriate for E-commerce development?3/15/2012 s.k.chakravarti 86
  • 87. Conclusion(1) • SASD is a process-driven software analysis technique • It has a long history in the industry and it is mature • It provides a good documentation for requirements3/15/2012 s.k.chakravarti 87
  • 88. Conclusion (2) • The Environmental Model: - Statement of Purpose - Context Diagram - Event List • The Behavioural Model: - Data Flow Diagram - Process Specification - Data Dictionary - Entity-Relationship Diagram • The Implementation Model: - Structure Diagram3/15/2012 s.k.chakravarti 88
  • 89. References • “Introduction to System Analysis and Design:a Structured Approach”, Penny A. Kendall, Northern Illinois University. • “Systems Analysis And Design”, elias M. Awad, Mclntire school of Commerce, University of Virginia. • “Structured Analysis for Requirements Definition”, Ross, Douglas T., Schoman, Kenneth E. JR., IEEE Transactions on Software Engineering, January 1977, Pg 6-15. • “Structured Analysis/Structured Design”, Englehart, Kevin, http://www.ee.unb/kengleha/courses/CMPE3213/Sasd.html3/15/2012 s.k.chakravarti 89
  • 90. THANKS