----------------------- Page 1----------------------Structured Analysis and Structured Design Presented by:Sanjay kumar chakravarti Roll:-RK2R13A28 Reg.-11006964 3/15/2012 s.k.

chakravarti 1 ----------------------- Page 2----------------------Agenda Introduction SASD Tools and Exercises Pros and Cons Comparisons with Other Techniques Conclusion References 2

3/15/2012 s.k.chakravarti ----------------------- Page 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 ----------------------- Page 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 ----------------------- Page 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 ----------------------- Page 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 ----------------------- Page 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 ----------------------- Page 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 system 3/15/2012 s.k.chakravarti ----------------------- Page 9----------------------SASD Approach to Development Cycle Existing or Install and Operate 8 6 5

Requirements Definition

Foreseen Conditions Analysis Functional Design Architecture System Architecture

Build Operational System

3/15/2012 s.k.chakravarti 9 ----------------------- Page 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 Cringley 3/15/2012 s.k.chakravarti 0 ----------------------- Page 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 ----------------------- Page 12----------------------Elements of Structured Analysis and Design Essential Model Environmental Model Implementation Model 3/15/2012 s.k.chakravarti 12 Behavioural Model 11 1

----------------------- Page 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 Environm ental Behavioural Model Model Im plementation Model 3/15/2012 s.k.chakravarti 13 ----------------------- Page 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. Behavioural Model Model Implement ation Model 3/15/2012 s.k.chakravarti 14 ----------------------- Page 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

Essential Model

Environmental Behavioural Model Model Implementa tion Model 3/15/2012 s.k.chakravarti 15 ----------------------- Page 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 Behavi oural Model Tool: Structure Charts Implementation Model 3/15/2012 s.k.chakravarti 16 ----------------------- Page 17----------------------Analysis & Design Process Environmental Model Behavioural Model Statement of Purpose A c t i v i t y Context Diagram Implementation Model

Event List Data Dictionary ERD DFD

Model

Process Specification State Transition Diagram Structure Charts

Time 3/15/2012 s.k.chakravarti 17 ----------------------- Page 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 ----------------------- Page 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 ----------------------- Page 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 ----------------------- Page 21----------------------Context Diagram - Notation Process - Represents the proposed system Terminator - Represents the external entities Flow - Represents the in and out data flows 3/15/2012 s.k.chakravarti 21 20 19 18

----------------------- Page 22----------------------Context Diagram - Example Customer Service Application Customer Bills Payment Corporate Accounting System Credit Card Processing Account Summary Payment 3/15/2012 s.k.chakravarti ----------------------- Page 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 ----------------------- Page 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 ----------------------- Page 25----------------------Event List - Example Customer Customer Customer Customer Customer applies for a credit card. makes a transaction at a store. pays a bill. disputes charges. Service changes credit terms. 25 24 23 Overdue Accounts Collection Company Credit

Transaction Store 22

3/15/2012 s.k.chakravarti ----------------------- Page 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 ----------------------- Page 27----------------------Data Flow Diagram - Notation Represents functions in the system Represents the external entities Represents data flows Represents data stores 3/15/2012 s.k.chakravarti 27 ----------------------- Page 28----------------------Data Flow Diagram - Example New Transaction Customer Customer* 2.0 Store Card Transaction Process Capture Cards Account Details Transaction Account 3.0 Transaction Total Transaction Bill Transactions Customer Cheque Amount Credit Terms Status Number Authorization Application Buy Open to 1.0 26

Overdue 5.0 Customer Amount Service 4.0 Determine Overdue Account Overdue Process Accounts Payment Cheque Customer* Collection Company 3/15/2012 28 ----------------------- Page 29----------------------Data Flow Diagram - Leveling cheque cheque 4.1 4.4 Read k Payment us 4 Account Process Payment 4.3 Proce ss amount, nt account amount, Account 3/15/2012 s.k.chakravarti 29 account Payme Update Stat Chec 4.2 s.k.chakravarti

----------------------- Page 30----------------------Data Flow Diagram Validation Black Hole Spontaneous 3/15/2012 s.k.chakravarti 30 ----------------------- Page 31----------------------Data Flow Diagram Validation 3/15/2012 s.k.chakravarti 31 ----------------------- Page 32----------------------Context diagram - Exercise System context diagram invoice Vendor anagement payment Payment authorization Cash-requirement report accounting [Kendall 1996] 3/15/2012 s.k.chakravarti 32 ----------------------- Page 33----------------------Data Flow Diagram - Exercise Build a level 0 DFD 3/15/2012 s.k.chakravarti 33 ----------------------- Page 34----------------------Data Flow Diagram-level 0 Solution 2. 1. Valid invoice details Payinvoice Cash requirements-report m

Check Invoice invoice Payment authorization

Check valid Invoice Cash requirements report

Packing slip details vendors Purchase orders Pending Packing slip invoices item details

Purchase order item details

Payment authorization 3. payment authorization Produce (Manual) ment Payment 3/15/2012 ----------------------- Page 35----------------------Data Dictionary - Purpose Defines data elements to avoid different interpretations. 3/15/2012 s.k.chakravarti 5 ----------------------- Page 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 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 PIBut thats a number, not a name. But what about your first and last name. Or is your first name 3, and your las t name 141592653? 3/15/2012 s.k.chakravarti 36 3 s.k.chakravarti 34 pay

----------------------- Page 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) 37

3/15/2012 s.k.chakravarti ----------------------- Page 38----------------------Data Dictionary - Examples Element Name Definition Alias Format = Card Number = *Uniquely identifies a card* = None = LD+LD+LD+LD+SP+ LD+LD+LD+LD+SP+ LD+LD+LD+LD+SP+ LD+LD+LD+LD = *Space* = {0-9} *Legal Digits* = 5191 0000 0000 0000 to 5191 9999 9999 9999

SP LD Range

3/15/2012 s.k.chakravarti ----------------------- Page 39----------------------Data Dictionary - Exercise Build data dictionary items for the vendor name and vendor address 3/15/2012 group 3: SASD 39 ----------------------- Page 40----------------------Data dictionary - Solution Element Name Alias Format Element Name Alias Format = Vendor Name = none = 30 characters

38

= Vendor Address = none =Vendor street + Vendor city + Vendor Province + Vendor Postal Code + Vendor Country

3/15/2012 40

s.k.chakravarti

----------------------- Page 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 interrelationships in the system. 3/15/2012 s.k.chakravarti ----------------------- Page 42----------------------Entity Relationship Diagram - Notation Data Element Relationship Associated Object Cardinality Exactly one Cardinality Zero or one Cardinality Mandatory Many Cardinality Optional Many 3/15/2012 s.k.chakravarti 42 ----------------------- Page 43----------------------Entity Relationship Diagram - Example Payments receive Accounts contains pay for Cards Transaction_ products 3/15/2012 s.k.chakravarti ----------------------- Page 44----------------------Entity Relationship Diagram - Exercise Create an ERD for the Warm Boot Manufacturing System 43 include generate Transactions Bills are made of 41

3/15/2012 s.k.chakravarti 44 ----------------------- Page 45----------------------Entity-Relationship diagram - Solution PAC KING-SLIPINVENTORY-ITEMS M-DETAILS orders itemizes PURCHASE-ORDER ITEM-DETAILS includes PACKING-SLIPDETAILS itemizes Purchases VENDORS PURCHASE-ORDERS Bills for Owed to 3/15/2012 45 ----------------------- Page 46----------------------Structure Charts - Purpose Functional Decomposition (Divide and conquer) Information hiding Modularity Low coupling High internal cohesion 3/15/2012 s.k.chakravarti ----------------------- Page 47----------------------Transform Analysis Central Transform Customer cheque, bill stub 4.1 4.3 Process Payment Payment account, Payments 4.5 4.6 Insert payment 46 s.k.chakravarti from PENDING-INVOICES receives ITE

amount Read Payment payment edited payment t, 4.2 t Edit Payment Afferent Flow 3/15/2012 s.k.chakravarti 47 Efferent Flow account, amount Accounts amoun account, amount 4.4 Update Balance Update Open To Buy accoun

----------------------- Page 48----------------------Structure Charts Input (Afferent Flow) Process Central Transform) Control Input 3/15/2012 s.k.chakravarti 48 ----------------------- Page 49----------------------Structure Charts - Notation Modules Library modules Module call Data Flag 3/15/2012 s.k.chakravarti ----------------------- Page 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. 49 Process Output Output (Efferent Flow)

 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

----------------------- Page 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 randomly 3/15/2012 s.k.chakravarti 51 ----------------------- Page 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 ----------------------- Page 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 ----------------------- Page 54----------------------Structure Charts - Example Payment Error Payment Get Payment Process Payment Payment Raw ent Payment Raw Payment Payment Read Edit Event Record Record 3/15/2012 s.k.chakravarti 54 ----------------------- Page 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 ----------------------- Page 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 55 Account Payment Payment Error Update Insert Paym Process Payment Control Payment Payment Process Today Write Payment

Read amount Add amount to accounts open to buy Add amount to accounts balance Update payment as applied 3/15/2012 s.k.chakravarti ----------------------- Page 57----------------------State Transition Diagram - Purpose Shows the time ordering between processes 3/15/2012 s.k.chakravarti 57 ----------------------- Page 58----------------------State Transition Diagram Notation Objects Transitions 3/15/2012 s.k.chakravarti 58 ----------------------- Page 59----------------------State Transition Diagram Example Customer makes purchase Account application Create New Account. No Balance Customer request to close account & pays balance Closed Account. No Balance 3/15/2012 s.k.chakravarti 59 ----------------------- Page 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 Design Active Account. Balance Customer pays bills Customer makes purchase Customer does not pay bills Bad Debt Account. Balance 56

3/15/2012 s.k.chakravarti ----------------------- Page 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 thinking 3/15/2012 s.k.chakravarti ----------------------- Page 62----------------------Pros of SASD Flexible Provides a means of requirements validation Relatively simple and easy to read 3/15/2012 s.k.chakravarti ----------------------- Page 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 conquer 3/15/2012 s.k.chakravarti 63 ----------------------- Page 64----------------------Pros of SASD Data Dictionary: Simplifies data requirements Used at high or low level analysis ERD: Commonly used; well understood

60

61

62

 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 ----------------------- Page 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 modules 3/15/2012 s.k.chakravarti 65 ----------------------- Page 66----------------------Cons of SASD It ignores non-functional requirements Minimal management involvement Non-iterative; waterfall approach Not enough user-analyst interaction Doesnt provide a communication process with users Hard to decide when to stop decomposing 3/15/2012 s.k.chakravarti ----------------------- Page 67----------------------Cons of SASD Doesnt address stakeholders needs Doesnt work well with Object-Oriented programming languages 3/15/2012 s.k.chakravarti ----------------------- Page 68----------------------Cons of SASD Context Diagram: Does not provide a specific means to determine the scope of the system. 67 66

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 ----------------------- Page 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 ----------------------- Page 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 often

3/15/2012 s.k.chakravarti 70 ----------------------- Page 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 short

3/15/2012 s.k.chakravarti ----------------------- Page 72----------------------SASD vs. OOAD Similarities

71

Both SASD and OOAD had started off from programming techniques Both techniques use graphical design and graphical tools to analyze and mo del 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 ----------------------- Page 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 a processes into objects while SASD separates between them 3/15/2012 s.k.chakravarti 73 ----------------------- Page 74----------------------SASD vs. Agile Methods similarities: facilitate stakeholder communication 3/15/2012 74 ----------------------- Page 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 s.k.chakravarti

nd

Agile Methods team involve project manager, customers and programmers 3/15/2012 s.k.chakravarti 75 ----------------------- Page 76----------------------SASD vs. Agile Methods (2) Differences ed SASD Agile Agile SASD is good Methods methods doesnt for long term planning is good for short term quick software releases require frequent user interaction require too much user interaction SASD Agile Agile SASD focuses on building a design model methods dont allow for too much planning methods use prototyping with short iterative life cycles requires longer life cycles because of the analysis and design involv

3/15/2012 s.k.chakravarti 76 ----------------------- Page 77----------------------SASD vs. Cleanroom 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 3/15/2012 77 s.k.chakravarti

----------------------- Page 78----------------------SASD vs. Cleanroom Differences: SASD emphasizes on requirement documentation and facilitate human communication Cleanroom doesnt support requirement elicitation SASD is non-iterative in both analysis and design phases Cleanroom uses incremental development and go through requirement anal ysis, design, coding and verification SASD uses system modeling techniques from different system perspective s 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 developmen

t phases. 3/15/2012 s.k.chakravarti 78 ----------------------- Page 79----------------------SASD vs. QFD Similarities: Both involve analysts and system designers Both used in requirements analysis 3/15/2012 79 s.k.chakravarti

----------------------- Page 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 techn iques 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 ----------------------- Page 81----------------------SASD vs. QFD Differences: SASD takes us a step further than QFD into building an implementation mode l 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 ----------------------- Page 82----------------------SASD vs. JAD

Similarities: Both support customer-analyst communication and requirements documentation Both need user support 3/15/2012 82 s.k.chakravarti

----------------------- Page 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 sessio n 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 decisi on jointly SASD is performed by mainly system analysts and designers JAD needs a session leader, executive sponsor, a specialist, one analy st. 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 ----------------------- Page 84----------------------SASD vs. SSM Similarities: Both focus on communication with stakeholders Both have consideration of organizational/user impact Both have the ability to model requirements 3/15/2012 84 s.k.chakravarti

----------------------- Page 85----------------------SASD vs. SSM Differences: SSM uses Rich Pictures to record the systems analysis SASD uses DFDs 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 85 s.k.chakravarti

----------------------- Page 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? 86

3/15/2012 s.k.chakravarti ----------------------- Page 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 requirements 3/15/2012 s.k.chakravarti ----------------------- Page 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 Diagram 3/15/2012 s.k.chakravarti 88 ----------------------- Page 89----------------------References

87

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 197 7, 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 ----------------------- Page 90----------------------THANKS