Your SlideShare is downloading. ×
0
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Se 381 - lec 21 - 23 - 12 may09 - df-ds and data dictionary

400

Published on

Software Engineering, Lectures

Software Engineering, Lectures

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
400
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
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. SE-381 Software Engineering BEIT-V Lecture no. 21 (Data Dictionary)
  • 2. Logical Data Dictionary • Data Dictionary • Is a mean of recording metadata of a system • The Logical Data Model is to record and analyze data requirements independently of how these requirements are going to be met • The Physical Data Model is to record design decisions in terms of its implementation. Hence Data Dictionary • Is a mechanism for recording the data require- ments and data resources of an organization. • Is a tool for Analysis and Design phases of SD
  • 3. Data Dictionary (DD) – Data Dictionary – Is simply a record of data about data, or metadata – Can be compiled manually or by a fully automated package – Links different techniques and components of system together – Is not a static mechanism, but the information stored in will improve/increase and will be updated with time – Provides a logical bridge between Analysis & Design – Serves as back-bone for CASE tools In Structured System Analysis and Design, DD holds data about 3 of the 4 components of DFDs i.e. Data Stores, Processes and Data Flows. Further, the Data Elements and Data Structures need be defined to elaborate composition of Data Flows and Data Stores
  • 4. Templates - DD Components – Data Element: Name: A meaningful unique name Description: Short description of meaning of DE Aliases: Several dept may refer same DE by different names or terms Type: Character, Numeric or Alphanumeric Format: Used to prepare format checks in subsequent system design Values: To embody different codes to represent different categories Security: Who can modify, add or delete the given DE Editing: How +ve or –ve numbers be differentiated Comments: To record some special information about the DE
  • 5. Templates – DD Components. – Data Structure A Data Structure is made up of data elements and other data structures. Thus Data Dictionary should contain its complete info, explicitly mentioning which elements are Optional, Repeated or mutually exclusive. Optional Structure: Placed in square brackets eg [PREV- SURNAME] Alternate Structure: Place in braces eg {FATHER-NAME, HUSBAND-NAME} Iterations of Structure: Marked with an asterisk eg COURSE-REGISTERED * (1-5) with number of iterations placed, if known, in parentheses, here applicant can register in 1,2,3..5 courses Volume Information: Collected at the end of the form and used for resource estimation
  • 6. Backus Naur Form A Notation primarily used to define the syntax of programming languages, can also be used to define Data Elements and Data Structures = Left of the sign consists of whatever is on right + Equivalent to ‘and’ {…;…;…} Only one of the item is to be chosen – Selection [ … ] Optional i.e. zero or one occurrence (…) Item contains from zero to an infinite number of occurrences of whatever inside braces – Iteration *…* Comment i.e. it does not constitute the part of def Some examples of terms of Data Dictionary AGREED-PURCHASE-PRICE = *Price provisionally agreed between the purchaser and vendor * CENTRAL-HEATING = CENTRAL-HEATING-TYPE + CENTRAL-HEATING-DEGREE CENTRAL-HEATING-TYPE = {GAS ; ELECTRIC ; SOLID-FUEL } CENTRAL-HEATING-DEGREE = { MAJOR ; AVERAGE ; MINOR }
  • 7. Writing Data Dictionary Items in BNF
  • 8. Templates – DD Comps .. – Data Store – Contents of Data Store can be written more clearly and with less chance of error. Further, interrelationships of parts of systems are also represented by the occurrences of the structures. All data flows coming-in and going-out are recorded – Data Flow – Its Source, Sink and composition be recorded. – Process – Along with inputs and outputs to the process, its logic or working can also be recorded into the template
  • 9. Data Dictionary (DD) – Data Dictionary – Is simply a record of data about data – Can be compiled manually or by a fully automated package – Links different techniques and components of system together – Is not a static mechanism, but the information stored in will improve/increase and will be updated with time – Provides a logical bridge between Analysis & Design – Serves as back-bone for CASE tools In Structured System Analysis and Design, DD holds data about 3 of the 4 components of DFDs i.e. Stores, Processes and Data Flows. Further, the data Elements and Data Structures need be defined to elaborate composition of Data Flows and Data Stores
  • 10. References • Tom DeMarco (1978); Structured Analysis and System Specifications • Chris Gane and Trish Sarson (1979) Structured Analysis : Tools and Techniques • Paul Beynon-Davies (1989); Information Systems Development, Macmilon, London, UK • Steve Skidmore and Brenda Wroe (192); Introducing System Analysis, NCC Publications, BPB Plublications, India • Wayne P Stevens (1991); Software Design: Concepts and Methods, Printice Hall, London, UK
  • 11. DFDs for ATM System
  • 12. 0-Level or Context Diagram
  • 13. 1st-Level Diagram
  • 14. 2nd-Level Diagram (Process 3.0 Draw Cash)
  • 15. Guidelines for Constructing DFDs – Read the Problem Specification or listen carefully to the verbal specification of Problem – Analyze and identify the Externals – List down the Activities and Sub-activities, preferably in indented format, depicting hierarchy – In reply to question ‘How you managed to publish so much?’ Prof C A Hoar told: ‘I take a ream of white paper, handful of sharpened lead pencils, a thick good quality eraser, sit at a lonely place and start writing’ [Prof C A Hoar]‘ – Follow Prof Hoar’s advice
  • 16. – On a A4 sheet draw Externals at the periphery, mark the Data Flows originating from or destined to these Externals, and then draw a Process in the Middle of the page, with a name most appropriate for the system. – Link Externals to this central Process by extending Data Flows. Name the Data Flows – This is the 0-Level or Context Diagram Be Reminded - first few DFDs would be (probably) wrong, so Be patient and persistent. Failures are to learn and key to SUCCESS
  • 17. – To Identify Externals, read problem specs, mark or underline Nouns; these can be Externals, data flows or Data Stores, so look into the context how these are used, if these are acting as sources or destinations for data, then these are Externals – Mark Verbs representing actions these indicate activities or sub-activities, you have to decide their correlation-ship, i.e. which is sub-activity of which activity – To draw, 1st level or Overview Diagram, take an A4 sheet, draw a dashed line boundary, a larger rectangle and transfer all data flows from the Context Diagram to this – Now look for each of the activities and associate a Process to it, and so draw Processes for them.
  • 18. – Concentrate on each of the processes, and workout the possible data flows coming-in and going-out of these Processes, to demonstrate the requisite functionality – Introduce any of the Data Stores, if needed, and Data Flows thru these Data Stores is preferred, it helps in de-linking the Processes later – Now extend the inherited Data Flows, to the respective Processes, instead of their termination or origination from Boundary – Label or name and number all Processes, Data Flows and Data Stores as per Guidelines – Explode the Processes, where needed i.e. the ones having more functionality and activity
  • 19. Courses Registration at KICSIT Read the Case Study and draw logical Data Flow Diagrams, up to three levels, i.e Context or 0-Level, 1st Level or Overview Diagram and 2nd Level diagrams for the processes having sufficient functionality
  • 20. Courses Registration @ KICSIT Home Assignment – I hope every body tried to • Understand the Problem and • make the Data Flow Diagrams up to 2nd or 3rd level – Results of an attempt to make these DFDs are presented: • These are correct, but still open for discussion and correction, if any.
  • 21. 0-Level or Context Diagram
  • 22. The DFDs are to be revised and updated accordingly, and top- down and bottom-up iterations among different levels of DFDs are to be carried out to ensure consistency and balancing.

×