(Murlidhar Group of Institutions,Bhavnagar Road, Rajkot) by:-assit. Prof. Vijay Vora (SOOADM) MCA-III

Transcription

1

2 Analysis Modeling

3 What is Analysis Modeling? Analysis modeling uses a combination of text and diagrammatic forms to depict(represent) requirements for data, function, and behavior These text and diagrammatic forms are represent in a way that is relatively easy to understand, and it is also more straightforward to review for correctness, completeness and consistency. In other words, Data modeling is a method used to define and analyze data requirements needed to support and to develop the new system/software. 3

4 The analysis model consists of a wide variety of diagrammatic forms used to bridge an important gap. Purpose: Describe what the customer wants built Establish the foundation for the software Provide a set of validation requirements 4

5 Analysis Model consist three types of Models Data Model ER model Object model Functional model Data flow model Behavioral model State transition model System behavior modeling with sequence diagram 5

6 Data Flow Diagram (Data Flow Approach) (Process Model) (Data Flow Graphs)

7 What is The Data Flow Diagram? A A Data Flow Diagram is a graphically representation of the flow of data. A A Data Flow Diagram (DFD) is a diagrammatic representation of the information flows within a system, that shows: how information enters and leaves the system, what changes the information, where information is stored. So, one can said that,the DFD tracks the data from an original source, carries it through a process, then flows it to a final destination. 7

8 In the DFD, flow is shown as an arrowed line with the arrow-head showing the direction of flow. Each data flow should be uniquely identified by a meaningful descriptive name (caption). Generally, DFD are commonly used during problem analysis. DFD Depict: System inputs Processes outputs 8

9 Purpose of Data Flaw Diagram? [self study] 9

10 Advantages of Data Flaw Diagram A A data flow diagram is an excellent tool for summarizing the information of system DFD organize a detailed information about a system s boundaries, processes, and data entities. It also provide the analyst with a logical map of the system. Documenting the system s boundaries by drawing a context diagram helps the analyst, the user, and the responsible managers to visualize alternative high-level logical system designs. The elements of a data flow diagram lead directly into physical design. 10

11 Disadvantages of Data Flaw Diagram [Self study] 11

12 Symbols of Data Flow Diagram (Elements of Data Flow Diagrams) (Components of Data Flow Diagrams) (Data Flow Diagram Icons)

13 Four primary symbols are used to create a data flow diagram External entities Processes Data stores Data flows 13

14 1. External entities it shows source or destination Sources and destinations define the system s boundaries Where/who Entity identifier Entityname 14

15 A A shape of external entity (source or destination) is represented by a shaded square. They are often beyond the area of influence of the developer. These can represent another system or subsystem. These go on margins/edges of data flow diagram. External entities are named with appropriate name. Thus, the external entities either input information to the system, output information from the system or both. Typically they may represent job titles or other systems that interact with the system to be built. 15

16 2. Processes Processes are work or actions performed on incoming data flows to produce outgoing data flows. Process identifier Process name A shape of Process is represented by a round-cornered rectangle. These show data transformation or change. Data coming into a process must be "worked on" in some way. Thus, all processes must have inputs and outputs. Major functions of processes are computations and making decisions. 16

17 Process Naming convention Processes are named with one carefully chosen verb and an object of the verb. There is no subject. Name is not to include the word "process". Each process should represent one function or action If there is an "and" in the name, then process have more than one function 17

18 3. Data stores Data Stores are repository(storage area) for data that are temporarily or permanently recorded within the system. Data StoreDescription Data Store identifier A A shape of Data Stores is represented by an open- ended, horizontal rectangle. It is an "inventory (record) of data. These are common link between data and process models. Only processes may connect with data stores. 18

19 Data Stores Naming convention Data stores are named with an appropriate name, not to include the word "file. Names should consist of plural nouns describing the collection of data. for e.g. - customers, orders, and products. These may be duplicated. These are detailed in the data dictionary. 19

20 4. Data flows Data flow represents the input or output of data to or from a process ("data in motion"). Data flow A A shape of Data Flow is represented by an arrow in any direction. Data flows only data, not control Data flows must begin and/or end at a process. Data Flow Naming convention Data flows are always named. Name is not to include the word "data". Should be given unique names. Names should be some identifying noun. For example, order, payment, complaint. 20

21 21

22 Steps to develop data flow diagrams (Different Levels of Data Flow Diagrams)

23 Steps to draw Data flow diagram Top-Down approach is use to draw DFD. 1. Make a List of business activity and use it to determine various External entities Data flows Process Data stores 2. Create a Context Diagram this shows external entities and data flows to and from the system, Do not show any detailed processes or data stores. 3. Draw Diagram 0, the next level. Show processes, but keep them general. Show data stores at this level. 4. Create a child diagram for each of the processes in Diagram Check for errors and make sure the labels that assign to each process and data flow are meaningful. 6. Develop a physical data flow diagram from the logical data flow diagram. Distinguish between manual and automates process. Describe actual files and reports by name Add controls to indicate when processes are complete or error occur. 7. Partition the physical data flow diagram by separating or grouping parts of the diagram in order to facilitate programming and implementation. 23

24 Create a Context Diagram (step-2) The highest level (i.e. the 0 level) in a data flow diagram Context diagram is to explain current or proposed system as summary A context diagram documents the system s boundaries by highlighting its sources and destinations Generally, it Contains only one process to represent the entire system Documenting the system s boundaries by drawing a context diagram helps the analyst, the user, and the responsible managers visualize alternative high-level logical system designs. All external entities, as well as Major data flows are shown The diagram does not contain any data stores. 24

25 Figure shows the context level diagram 25

26 Drawing Diagram 0 (step-3) The explosion of the context diagram May include up to nine processes Each process is numbered Major data stores and all external entities are included Data flow diagram 0 shows the system s primary processes, data stores, sources, and destinations linked by data flows. Start with the data flow from an entity on the input side Examine the data flow to or from a data store Analyze a well-defined process Take note of any fuzzy(unclear) areas 26

27 Figure shows the Diagram 0 27

28 Each process start from context level diagram and it may be explode to a next lower level The lower level diagram number is the same as the parent process number Processes that do not create a child diagram are called primitive 28

29 Creating Child Diagrams (step-4) Each process on diagram 0 may be exploded to create a child diagram A child diagram cannot produce output or receive input that the parent process does not also produce or receive The child process is given the same number as the parent process Below given figure shows the child Diagram, in which Process 3(in Diagram 0) would explode to next level diagram i.e. Diagram 3 29

30 30

31 Entities are usually not shown on the child diagrams If the parent process has data flow connecting to a data store, the child diagram may include the data store as well In addition, the lower-level level diagram may contain data stores that are not shown on the parent process. 31

32 Checking the Diagrams for Errors (step-5) Checking errors like Forgetting to include a data flow or pointing an arrow in the wrong direction 32

33 Connecting data stores and external entities directly to each other 33

34 Incorrectly labeling processes or data flow Each object or data flow is properly labeled Data flow described with a verb. Processes should indicate the system name or use the verb-adjective-noun format. Try to not include more than nine processes on a data flow diagram Because having too many processes creates a cluttered diagram that is confusing to read and understand. The next figure shows the payroll example, in that the typical errors can occur in a data flow diagram 34

35 35

36 Logical Data Flow Diagrams and Physical Data Flow Diagrams (types of DFD)

37 Logical Data Flow Diagrams Focuses on the business and how the business operates Not concerned with how the system will be constructed Describes the business events that take place and the data required and produced by each event Physical Data Flow Diagrams Shows how the system will be implemented Depicts the system 37

38 38

39 The progression of models from logical to physical 39

40 Advantages of Logical Data Flow Diagrams Advantages of Physical Data Flow Diagrams 40

41 Physical data flow diagrams contain many items not found in logical data flow diagrams 41

42 Self study Event Modeling and Data Flow Diagrams Event Response Tables Use Cases and Data Flow Diagrams Partitioning Data Flow Diagrams Reasons for Partitioning 42

43 Data Dictionaries

44 What is Data Dictionary? Data Dictionary is a Centralized repository of information about data such as meaning, relationships to other data, origin, usage, and format. A A data dictionary allows more precise descriptions of the data to be made Collects and coordinates data terms, and confirms what each term means to different people in the organization 44

45 Need for Understanding the Data Dictionary Provide documentation Eliminate redundancy Validate the data flow diagram Provide a starting point for developing screens and reports Determine the contents of data stored in files To develop the logic for DFD processes 45

46 Data Repository A A data repository is a large collection of project information It includes: Information about the data maintained by the system Procedural logic and use cases Screen and report design Data relationships Project requirements and final system deliverables Project management information 46

47 How data dictionaries relate to data flow diagrams 47

48 Category of Data Dictionary Data flows Data structures Elements Data stores 48

49 Data flows ID - identification number (optional) Unique descriptive name A general description of the data flow The source of the data flow The destination of the data flow Type of data flow The volume per unit time An area for further comments and notations 49

50 An example of a data flow description from World s Trend Catalog Division 50

51 Data structures Data structures are made up of smaller structures and elements An algebraic notation is used to describe data structures»algebraic Notation Equal sign, meaning is composed of Plus sign, meaning "and Braces {} meaning repetitive elements Brackets [] for an either/or situation Parentheses () for an optional element 51

52 Data structure example for adding a customer order at World s Trend Catalog Division 52

53 Another example of Data Structure Student record= student ID + Student name+ Address + Date of birth + Gender + Nationality + Telephone number + (mobile telephone number) + { course record} Course record= course name + Course number+ Grade 53

54 [Self Study] (this points are sub-points of Data Structures)»Structural Records»Use of Structural Records in Different System»Structural Record Example 54

55 »Logical and Physical Data Structures»Logical Show what data the business needs for its day-to-day operations»physical Include additional elements necessary for implementing the system 55

56 Elements Description Element ID The name of the element Aliases A A short description of the element Element is base or derived Element length Type of data Input and output formats Validation criteria Default value An additional comment or remark area 56

57 Example of an element description form from World s Trend Catalog Division 57

58 Data Stores Description The Data Store ID The Data Store Name An Alias for the table A A short description of the data store File format The maximum and average number of records on the file as well as the growth per year The file or data set name specifies the file name, if known Primary keys Comments 58

59 An example of a data store form for World s Trend Catalog Division 59

60 Creating the Data Dictionary»Data dictionary entries Created after the data flow diagram is completed or Created as the data flow diagram is being developed»created using a top-down approach 60

61 Two data flow diagrams and corresponding data dictionary entries for producing an employee paycheck 61

62 »Analyzing Input and Output A descriptive name for the input or output Whether the data is input or output The format of the data flow Elements indicating the sequence of the data on a report or screen A list of elements 62

63 An example of an input/output analysis form for World s Trend Catalog Division 63

64 »Developing Data Stores Represent data at rest Contain information of a permanent or semipermanent (temporary) nature When data stores are created for only one report or screen, it refer to as an userviews 64

65 Using the Data Dictionary To have maximum power, the data dictionary should be tied into a number of systems programs May be used to Create screens, reports, and forms Generate computer language source code Analyze the system design, detecting flaws and areas that need clarification 65

66 [Self Study] Using Data Dictionaries to Create X M L 66

67 Process Specifications

68 What is Process Specifications? Process Specification is a deep clarification or explanation of primitive processes. Sometimes it called mini-specs, because they are a small portion of the total product specifications Created for primitive processes as well as for some higher level processes on a data flow diagram Process Specifications explain the decision- making logic and formulas that transform process input data into output. 68

69 Purpose/Goal of Process Specifications? Reduce process ambiguity make the analyst to learn details about how the process works. Obtain a precise description of what is accomplished Validate the system design 69

70 When to not create Process Specifications? (Process Specifications are not created ) Processes that represent physical input and/or output Processes that represent simple data validation Processes that use prewritten code 70

71 How Process Specifications relate to the data flow diagram? 71

72 Process Specification Format Information The process number Must match the process ID on the data flow diagram Allows the analyst to work on or review any process, and to locate the data flow diagram containing the process easily The process name The same as displays within the process symbol on the DFD Description of what the process accomplishes (achieve) A A list of input data flow Output data flows Type of process Batch Online Manual Uses prewritten code Include the name of the subprogram or function containing the code Process logic description Logic method reference List any unresolved issues 72

73 example of a completed process specification 73

74 Method of writing process specifications Logic Tools of process specifications Logic/ Structured Decision Analysis 1. Structured English 2. Decision Tables 3. Decision Trees Structured English

75 What is Structured English? Structured English is a method of writing process specifications which is combination of English language and structured programming. This is the only method which provides environment for representing program logic with the natural English language. In short, Structured English is a description of processes in simple English 75

76 The objective of using structured English Expand a DFD so that a user can understand it Develop algorithms corresponding to processes in a DFD Ease writing programs for DFDs 76

77 Writing Structured English Structured English uses 3 basic types of statements to describe processes namely: - 1. Sequential structure. The sequential structured are single declarative statements denoting single step or action in a process. 2. Decision structure. The decision structured allows branching instructions providing YES / NO type decisions. For these decision structures keywords like IF THEN ELSE are used 3. Looping or repetitive structure The repetitive structure allows to specify group of instructions which in to be executed until given conditions are satisfied. Some of the ways of writing repetitive structures are: - DO.. WHILE. REPEAT. UNTIL.etc 77

78 Structured English uses 3 basic types of statements to describe processes namely Use and capitalize accepted keywords such as IF, THEN, ELSE, DO, REPETE etc Indent blocks of statements to show their hierarchy (nesting) clearly Clarify the logical statements 78

79 Examples of logic expressed in a sequential structure, a decision structure, a case structure, and an iteration 79

80 Advantages of Structured English Clarifying the logic and relationships found in human languages An effective communication tool, it can be taught to and understood by users in the organization 80

81 Method of writing process specifications Tools of process specifications 1. Structured English 2. Decision Tables 3. Decision Trees Decision Tables

82 What is Decision Tables Decision table is one of those method which is use for writing process specifications in which shows how a rule or set of rules are applied for repetitive situations. A A table of rows and columns, separated into four quadrants Conditions Condition alternatives Actions to be taken Rules for executing the actions 82

83 The standard format used for presenting a decision table 83

84 Example of decision table Constructing a decision table for deciding which catalog to send to customers who order only from selected catalogs 84

85 Second Example of decision table 85

86 Developing Decision Tables Determine conditions that affect the decision Determine possible actions that can be taken Determine condition alternatives for each condition Calculate the maximum number of columns in the decision table Fill in the condition alternatives Complete table by inserting an X where rules suggest actions Combine rules where it is apparent Rearrange to make more understandable 86

87 Checking for Completeness and Accuracy Four main problems Incompleteness Impossible situations Contradictions Redundancy 87

88 Example shows Contradiction & Redundabcy 88

89 Decision Table Advantages Help the analysis ensure completeness Easy to check for possible errors Impossible situations Contradictions Redundancy 89

90 Method of writing process specifications Tools of process specifications 1. Structured English 2. Decision Tables 3. Decision Trees Decision Trees

91 What is Decision Trees? Decision Tree is a tool of process specification which is used when complex branching occurs in a structured decision process Decision trees are superior to decision tables when sequence of testing conditions is particularly important 91

92 Drawing Decision Trees Identify all conditions and actions and their order and timing (if they are critical) Begin building the tree from left to right, making sure you list all possible alternatives before moving to the right 92

93 Example of decision tree to show the noncash purchase approval actions for a department store 93

94 Decision Tree Advantages The order of checking conditions and executing actions is immediately noticeable Conditions and actions of decision trees are found on the same branches but not on others Compared to decision tables, decision trees are more readily understood by others in the organization 94

95 Which Technique,user have to Select for Structured Decision Analysis or for Process Specification Use structured English when there are many repetitious actions or when communication to end users is important Use decision tables when complex combination of conditions, actions and rules are found, or system require a method that effectively avoids impossible situations, redundancies, and contradictions Use decision trees when the sequence of conditions and actions is critical 95

96 To download material Visit 96