Level 0 Diagram

1. Level 0 Diagram Cust. Info Order 0.1 0.2 Route Confirmation Prepare Orders Orderform Handle Orders Report Mail Copy-Orderform D0.1 Stock 0.3 0.4 Purchase Invoice Purchase Order Orderinformation Manage Stock Settle Invoice Cust. Invoice

2. Data Dictionary • Data dictionary is a main method for analyzing the data flows and data stores of data-oriented systems • The data dictionary is a reference work of data about data (metadata) • It collects, coordinates, and confirms what a specific data term means to different people in the organization

3. Data Dictionary Uses • Provide documentation • Eliminate redundancy • Validate the data flow diagram • Provide a starting point for developing screens and reports • To develop the logic for DFD processes

4. Data Dictionary Contents • Data flow • Data structures • Elements • Data stores

5. Defining Data Flow Name Customer Order Description Contains customer order information and is used to update the customer master and item files and to produce an order record. Source Customer External Entity Destination Process 1, Add Customer Order Type Screen Data Structure Order Information Volume/Time 10/hour Comments An order record contains information for one customer order. The order may be received by mail, fax, or by telephone.

6. Defining Data Structures Notation • Equal sign, meaning “consists of” • Plus sign, meaning "and” • Braces {} meaning repetitive elements, a repeating element or group of elements • Brackets [] for an either/or situation • The elements listed inside are mutually exclusive • Parentheses () for an optional element

7. Defining Data Structures Customer Order = Customer Number + Customer Name + Address + Telephone + Catalog Number + Order Date + {Order Items} + Merchandise Total + (Tax) + Shipping and Handling + Order Total + Method of Payment + (Credit Card Type) + (Credit Card Number) + (Expiration Date)

8. Data Structure Records Customer Name = First Name + (Middle Initial) + Last Name Address = Street + (Apartment) + City + State + Zip + (Zip Expansion) + (Country) Telephone = Area code + Local number

9. Defining data element Name Customer Number Alias Client Number Alias Receivable Account Number Description Uniquely identifies a customer that has made any business transaction within the last five years. Length 6 Input Format 9(6) Output Format 9(6) Default Value Continuous/Discrete Continuous Type Numeric Base or Derived Derived Upper Limit <999999 Lower Limit >18 Discrete Value/Meaning Comments The customer number must pass a modulus-11 check-digit test.

10. Data Store ID D1 Name Customer Master File Alias Client Master File Description Contains a record for each customer File Type Computer File Format Database Record Size 200 Maximum Records 45,000 Average Records 42,000 Percent Growth/Year 6%

11. Data Store Data Set/Table Name Customer Copy Member Custmast Data Structure Customer Record Primary Key Customer Number Secondary Keys Customer Name, Telephone, Zip Code Comments The Customer Master file records are copied to a history file and purged if the customer has not purchased an item within the past five years. A customer may be retained even if he or she has not made a purchase by requesting a catalog.

12. System Design

13. Elements of the Design • Data flows • Data Stores • Processes • Procedures • Controls • Roles

14. Output Design • Output - Info generated by the system • Considerations • What is the purpose of the output? • Who wants the information, why it is it needed, and how will it be used? • What specific information will be included? • Will the output be printed, viewed on-screen, or both? Variety of formats • Output from one becomes input for another • Routine reports/exceptions • Layout - Arrangement/quantum of info

15. Design of Files • Transaction details/historic data/reference • Data items to be included • Length of record • Storage structure (sequential/indexed/relative) • Use of existing files

16. Design of Input • Data to be input • Medium to use • Arrangement and coding • Dialogue with user • Validation • Error control

17. Control • Mistakes will be made • Ensure only authorized users • Guarantee transactions are acceptable • Validate data for accuracy • Determine completeness of data

18. Procedures • Data entry • Run-time • Error-handling • Security and back up

19. Program Specifications • Design of the computer software • Ensure that programs do what is intended • Modular structure • Enable maintenance and modification

20. Deliverables • The Design Book • Layout charts • Record layouts • Coding systems • Program specs/procedure specs • Development Plan and Cost

21. User Involvement User System analyst • Understand business problem • Know data needed • Know how to use software, PCs, equipment • Adhere to guidelines and standards • Translate general data needs into data specs & processing requirements • Provide training • Serve as consultants • Assistance in detecting and correcting errors

22. Database Interactions • Design of the computer software • Ensure that programs do what is intended • Modular structure • Enable maintenance and modification

23. ER Diagram

24. Implementation & Maintenance

25. Design Objectives • Maintainability • Reliability

26. Design Objectives Maintainability • Accurate definition of requirements • Good system documentation • Effective Design • Good use of existing tools and techniques

27. Reliability • The ability of an item to perform a required function under stated conditions for a specified period of time. • Does not produce dangerous or costly failures when used in a reasonable manner • System may not always be used as expected • Error-free code - a myth

28. Reliability Approaches • Error Avoidance • Impossible in large systems • Error Detection and Correction • Correct error when program in use • Correct the effect on user • Error Tolerance • Redundant systems • Graceful degradation

29. Causes of Errors • Hardware Errors • Design errors - reproduced in every copy • Manufacturing errors • Wear and tear • Software Errors • Not obtaining right requirement • Not understanding requirements • Improper translation of requirements Software reliability is a design issue

30. Characteristics of good design • Component independence • High cohesion • Low coupling • Exception identification and handling • Fault prevention and fault tolerance

31. Coupling: Degree of dependence among components Loosely coupled-some dependencies No dependencies High coupling makes modifying parts of the system difficult, e.g., modifying a component affects all the components to which the component is connected. Highly coupled-many dependencies

32. Range of Coupling High Coupling Content Common Control Stamp Data Uncoupled Loose Low

33. Content coupling • Definition: One component references contents of another • Example: • Component directly modifies another’s data • Component refers to local data of another component in terms of numerical displacement • Component modifies another’s code, e.g., jumps into the middle of a routine

34. Part of program handles lookup for customer. When customer not found, component adds customer by directly modifying the contents of the data structure containing customer data. Example of Content Coupling-1

35. Part of program handles lookup for customer. When customer not found, component adds customer by directly modifying the contents of the data structure containing customer data. Improvement: When customer not found, component calls the AddCustomer() method that is responsible for maintaining customer data. Example of Content Coupling-2

36. Common Coupling • Definition: Two components share data • Global data structures • Common blocks • Usually a poor design choice because • Lack of clear responsibility for the data • Reduces readability • Difficult to determine all the components that affect a data element (reduces maintainability) • Difficult to reuse components • Reduces ability to control data accesses

37. Each source process writes directly to global data store. Each sink process reads directly from global data store. Example-1 Process control component maintains current data about state of operation. Gets data from multiple sources. Supplies data to multiple sinks.

38. Each source process writes directly to global data store. Each sink process reads directly from global data store. Improvement Data manager component is responsible for data in data store. Processes send data to and request data from data manager. Example-2 Process control component maintains current data about state of operation. Gets data from multiple sources. Supplies data to multiple sinks.

39. Control Coupling • Definition: Component passes control parameters to coupled components. • May be either good or bad, depending on situation. • Bad when component must be aware of internal structure and logic of another module • Good if parameters allow factoring and reuse of functionality

40. Acceptable: Module p calls module q and q passes back flag that says it cannot complete the task, then q is passing data Not Acceptable: Module p calls module q and q passes back flag that says it cannot complete the task and, as a result, writes a specific message. Example

41. Stamp Coupling • Definition: Component passes a data structure to another component that does not have access to the entire structure. • Requires second component to know how to manipulate the data structure (e.g., needs to know about implementation) • May be necessary due to efficiency factors: this is a choice made by insightful designer, not lazy programmer.

42. The print routine of the customer billing accepts a customer data structure as an argument, parses it, and prints the name, address, and billing information. Example-1 Customer billing system

43. The print routine of the customer billing accepts a customer data structure as an argument, parses it, and prints the name, address, and billing information. Improvement The print routine takes the customer name, address, and billing information as an argument. Example-2 Customer Billing System

44. Data Coupling • Definition: Two components are data coupled if there are homogeneous data items. • Every argument is simple argument or data structure in which all elements are used • Good, if it can be achieved. • Easy to write contracts for this and modify component independently.

45. Key Idea in Object-Oriented Programming • Object-oriented designs tend to have low coupling.

46. Cohesion • Definition: The degree to which all elements of a component are directed towards a single task and all elements directed towards that task are contained in a single component. • Internal glue with which component is constructed • All elements of component are directed toward and essential for performing the same task • High is good

47. Range of Cohesion High Cohesion Functional Informational Sequential Communicational Procedural Temporal Logical Coincidental Low

48. Coincidental Cohesion • Definition: Parts of the component are only related by their location in source code • Elements needed to achieve some functionality are scattered throughout the system. • Accidental • Worst form

49. Print next line Reverse string of characters in second argument Add 7 to 5th argument Convert 4th argument to float Example

50. Logical Cohesion • Definition: Elements of component are related logically and not functionally. • Several logically related elements are in the same component and one of the elements is selected by the client component.