Structured Analysis and Structured Design
-
Upload
sanjay-kumar-chakravarti -
Category
Documents
-
view
12.889 -
download
4
Transcript of Structured Analysis and Structured Design
Structured Analysis and Structured Design
Presented by:-
Sanjay kumar chakravarti
Roll:-RK2R13A28
Reg.-11006964
3/15/2012
s.k.chakravarti
1
Agenda
• Introduction
• SASD Tools and Exercises
• Pros and Cons
• Comparisons with Other Techniques
• Conclusion
• References
3/15/2012 s.k.chakravarti 2
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
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
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
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
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
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 system
3/15/2012 s.k.chakravarti 8
SASD Approach to Development Cycle
3/15/2012 s.k.chakravarti 9
Functional Architecture
System Architecture
Operational System
Existing or Foreseen Conditions
Analysis
Design
Build
Install and Operate
Requirements Definition
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 Cringley
3/15/2012 s.k.chakravarti 10
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
Elements of Structured Analysis and Design
3/15/2012 s.k.chakravarti 12
Essential Model
Environmental Model
Behavioural Model
Implementation Model
Essential Model
3/15/2012 s.k.chakravarti 13
Essential Model
Environmental Model
Behavioural Model
Implementation 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.
Environmental Model
3/15/2012 s.k.chakravarti 14
Essential Model
Environmental Model
Behavioural Model
Implementation 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.
Behavioural Model
3/15/2012 s.k.chakravarti 15
Essential Model
Environmental Model
Behavioural Model
Implementation 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.
Implementation Model
3/15/2012 s.k.chakravarti 16
Essential Model
Environmental Model
Behavioural Model
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 requirements. •Tool: Structure Charts
Analysis & Design Process
3/15/2012 s.k.chakravarti 17
Time
Activ
ity
Statement of Purpose
Context Diagram
Event List
DFD
ERD
Data Dictionary
State Transition Diagram
Structure Charts
Environmental Model
Behavioural Model
Implementation Model
Process Specification
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
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
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
Context Diagram - Notation
3/15/2012 s.k.chakravarti 21
Process - Represents the proposed system
Terminator - Represents the external entities
Flow - Represents the in and out data flows
Context Diagram - Example
3/15/2012 s.k.chakravarti 22
Credit Card Processing
Customer
Collection Company
Corporate Accounting
System Store
Customer Service Application
Bills
Payment
Transaction
Payment
Overdue Accounts
Credit
Account Summary
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
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
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
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
Data Flow Diagram - Notation
3/15/2012 s.k.chakravarti 27
Represents the external entities
Represents data flows
Represents functions in the system
Represents data stores
Data Flow Diagram - Example
3/15/2012 s.k.chakravarti 28
1.0 Customer* Store
2.0
3.0
4.0
New Customer
Account
Transactions
Process Application
Bill Customer
Process Payment
Transaction Capture
5.0
Determine Overdue Accounts
Collection Company
Customer Service
Cards
Transaction
Transaction
Transaction
Overdue Account
Credit Terms
Card Number
Account Details
Open to Buy
Customer* Cheque
Authorization
Transaction Total
Cheque Amount
Status
Overdue Amount
Data Flow Diagram - Leveling
3/15/2012 s.k.chakravarti 29
4
Process Payment
cheque
amount, account
4.1
Read Payment
4.3
Process Payment
4.4
Update Account
Account
4.2
Check Status
cheque
amount, account
Data Flow Diagram – Validation
3/15/2012 s.k.chakravarti 30
Black Hole
Spontaneous
Data Flow Diagram – Validation
3/15/2012 s.k.chakravarti 31
Context diagram - Exercise
• System context diagram
3/15/2012 s.k.chakravarti 32
Pay- invoice Vendor
accounting
management
invoice
payment
Cash requirements-report
Payment authorization
Cash-requirement report
[Kendall 1996]
Data Flow Diagram - Exercise
• Build a level 0 DFD
3/15/2012 s.k.chakravarti 33
Data Flow Diagram-level 0 Solution
3/15/2012 s.k.chakravarti 34
vendors Purchase orders
Packing slip item details
Packing slip details
Pending invoices
Purchase order item details
invoice Valid invoice details
Cash requirements report
payment
Payment authorization
payment authorization (Manual)
Check valid Invoice
1. Check Invoice
Payment authorization
2.
Produce Payment
3.
Data Dictionary - Purpose
• Defines data elements to avoid different interpretations.
3/15/2012 s.k.chakravarti 35
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
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
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 9999
3/15/2012 s.k.chakravarti 38
Data Dictionary - Exercise
3/15/2012 group 3: SASD 39
Build data dictionary items for the vendor name and vendor address
Data dictionary - Solution
3/15/2012 s.k.chakravarti 40
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 Country
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
Entity Relationship Diagram - Notation
3/15/2012 s.k.chakravarti 42
Data Element
Relationship
Associated Object
Cardinality – Exactly one
Cardinality – Zero or one
Cardinality – Mandatory Many
Cardinality – Optional Many
Entity Relationship Diagram - Example
3/15/2012 s.k.chakravarti 43
Accounts
Cards
Transactions
Transaction_ products
Bills Payments
receive
are made of
pay for include
contains
generate
Entity Relationship Diagram - Exercise
Create an ERD for the Warm Boot Manufacturing System
3/15/2012 s.k.chakravarti 44
Entity-Relationship diagram - Solution
3/15/2012 s.k.chakravarti 45
INVENTORY-ITEMS
orders
PURCHASE-ORDER ITEM-DETAILS
itemizes
PURCHASE-ORDERS
Bills for PENDING-INVOICES
includes PACKING-SLIP- DETAILS
VENDORS
itemizes
receives PACKING-SLIP- ITEM-DETAILS
Owed
to
Purchases from
Structure Charts - Purpose
• Functional Decomposition (Divide and conquer)
• Information hiding
• Modularity
• Low coupling
• High internal cohesion
3/15/2012 s.k.chakravarti 46
Transform Analysis
3/15/2012 s.k.chakravarti 47
Customer
4.1
Read Payment
4.2
Edit Payment
4.3
Process Payment
4.4
Update Balance
4.5
Update Open To
Buy
cheque, bill stub
edited payment
payment
Accounts
4.6
Insert Payment
Payments
payment
account, amount
account, amount
account, amount
account, amount
Afferent Flow
Efferent Flow
Central Transform
Structure Charts
3/15/2012 s.k.chakravarti 48
Input (Afferent Flow)
Process Central Transform)
Output (Efferent Flow)
Input Process Output
Control
Structure Charts - Notation
3/15/2012 s.k.chakravarti 49
Modules
Library modules
Module call
Data
Flag
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
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 randomly
3/15/2012 s.k.chakravarti 51
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
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
Structure Charts - Example
3/15/2012 s.k.chakravarti 54
Process Payment Control
Get Payment Process Payment
Write Payment
Read Record
Edit Record
Update Account
Insert Payment
Event
Raw Payment
Raw Payment
Payment
Payment Error
Payment
Payment Error
Payment Process Today
Payment
Payment
Payment
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
Process Specifications - Example
3/15/2012 s.k.chakravarti 56
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 applied
State Transition Diagram - Purpose
• Shows the time ordering between processes
3/15/2012 s.k.chakravarti 57
State Transition Diagram – Notation
3/15/2012 s.k.chakravarti 58
Objects
Transitions
State Transition Diagram – Example
3/15/2012 s.k.chakravarti 59
Create New Account. No Balance
Account application
Active Account. Balance
Customer makes purchase
Customer makes purchase
Customer pays bills
Bad Debt Account. Balance
Customer request to
close account & pays balance
Closed Account.
No Balance
Customer does not pay bills
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 Design
3/15/2012 s.k.chakravarti 60
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 thinking
3/15/2012 s.k.chakravarti 61
Pros of SASD
• Flexible
• Provides a means of requirements validation
• Relatively simple and easy to read
3/15/2012 s.k.chakravarti 62
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 conquer
3/15/2012 s.k.chakravarti 63
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 DBAs
3/15/2012 s.k.chakravarti 64
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 modules
3/15/2012 s.k.chakravarti 65
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 decomposing
3/15/2012 s.k.chakravarti 66
Cons of SASD
• Doesn’t address stakeholders’ needs
• Doesn’t work well with Object-Oriented programming languages
3/15/2012 s.k.chakravarti 67
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 deliberation
3/15/2012 s.k.chakravarti 68
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
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 often
3/15/2012 s.k.chakravarti 70
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 short
3/15/2012 s.k.chakravarti 71
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 requirements
3/15/2012 s.k.chakravarti 72
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 them
3/15/2012 s.k.chakravarti 73
SASD vs. Agile Methods
3/15/2012 s.k.chakravarti 74
similarities:
facilitate stakeholder communication
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 programmers
3/15/2012 s.k.chakravarti 75
SASD vs. Agile Methods (2)
Differences • SASD focuses on building a design model
• Agile methods don't 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 doesn't require too much user interaction
3/15/2012 s.k.chakravarti 76
SASD vs. Cleanroom
3/15/2012 s.k.chakravarti 77
Similarities: • 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
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
SASD vs. QFD
3/15/2012 s.k.chakravarti 79
Similarities: Both involve analysts and system designers
Both used in requirements analysis
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
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 systems
3/15/2012 s.k.chakravarti 81
SASD vs. JAD
3/15/2012 s.k.chakravarti 82
Similarities: • Both support customer-analyst communication and requirements
documentation Both need user support
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 design
3/15/2012 s.k.chakravarti 83
SASD vs. SSM
3/15/2012 s.k.chakravarti 84
Similarities: • Both focus on communication with stakeholders • Both have consideration of organizational/user impact • Both have the ability to model requirements
SASD vs. SSM
3/15/2012 s.k.chakravarti 85
Differences: 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)
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
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 requirements
3/15/2012 s.k.chakravarti 87
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 Diagram
3/15/2012 s.k.chakravarti 88
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.html
3/15/2012 s.k.chakravarti 89
THANKS