Introduction to Data Dictionaries in Formal Analysis

1. IMS1805Systems Analysis Topic 5: Formal analysis and specification

2. Agenda • Aim: To introduce the concept of data dictionaries and show why they are needed in formal analysis • To demonstrate some examples of data dictionary elements

3. 1. Rationale and basic concept of data dictionaries • Analysis for understanding (the big picture) versus analysis for specification (the specific details) • The need for precision in specifications: • Working in teams and sharing knowledge • Linking analysis to construction • Working with machines (especially computers) • Standards, formal plans and specifications

4. An example: The bracket • The idea (big picture concept) • The specific need (detailed requirements) • Dealing with the constructor (stage 1) • The packaged solution and its problems • The specification • Dealing with the constructor (stage 2)

5. Implications • Understanding audiences and their needs • Setting standards: • for diagramming • for terminology and techniques • for system elements • The need for a data dictionary

6. The data dictionary • What is a dictionary? The language dictionary as a familiar example: • What purpose(s) does a language dictionary serve? • What does a language dictionary contain for each dictionary entry? • What is the scope of a language dictionary? • What is a data dictionary? • Purposes it serves? • Contents? • Scope?

7. Examples of things which may require data dictionary definitions • Process-related system elements such as • Process descriptions • Object behaviours • Data-related system elements such as • Data flows and data stores • Object classes, entities and attributes • Data elements • System behaviour elements such as • Object states • Use cases • System participants such as • Actors/stakeholders/external agents

8. The Data Dictionary as a working document • The data dictionary contains information about all the elements of the models which are built to describe a system • The data dictionary is a major source of documentation/shared knowledge about the information system and its models • System builders should be able to base their construction of every system element on the specifications contained in the relevant data dictionary entries

9. Data dictionary entries defining data • Many data-related aspects of systems and system models • Hierarchy of level of detail and specificity • Broad descriptors – objects, entities, stores, etc; which contain …. • Mid-level features – attributes, flows, etc; which comprise .. • Data elements – indivisible ‘elementary particles’ of data • Low-level data elements may be used in many different high-level data elements • Complete dictionary entries should be given for all

10. Mandatory features of all data definitions • A unique name - should be as clear, unambiguous, and meaningful as possible • Any aliases or synonyms (alternative names which are used elsewhere in the system documentation) eg ‘wholesale price’/’trade price’; ‘unit’/’subject’; ‘first name’/’christian name’ • A brief description of the data component and its purpose/usage in the system

11. Other possible components of data definitions • Need for these varies between data components: • Related data: data components and/or ‘parent’ data types (ie the adjoining levels on the data hierarchy) eg ‘Name’ = ‘Surname’ + ‘first name’; ‘Street Number’ = component of ‘Address’;‘Grade’ is derived from ‘Student Mark’; etc • Data type: eg text, numeric, date, logical, etc • Format: eg ‘Date’ is in dd/mm/yyyy format; ‘Mark’ is a whole number (no decimal places); etc • Size: eg ‘Postcode’ is 4 digits; ‘Name’ is up to 20 characters long; ‘Street Number’ is up to 5 digits long; etc • Range of acceptable values: eg ‘Mark’ must be equal or greater than 0 and less than or equal to 100; ‘Grade’ can be any one of N, NP, PGO, P, C, D, HD; etc • Mandatory/optional: eg ‘Address’ must have ‘postcode’; ‘student’ must have ‘ID’; ‘Student Name’ may include ‘second name’; etc

12. Composite data elements • If a data component comprises a number of data elements (eg a data flow or data store), a structured format is used to show all the elements in the component • For example, see following slide which uses these standard symbols: = means is composed of + means and [ ] means select one of { } means iterations of ( ) means optional

13. Example dictionary entry for a composite data flow called sales order sales order = sales order no. + sales order date + (customer number) + [account customer, cash customer] + customer name + customer address + (customer telephone no) + {item no + item desc + item price + item qty} + sales order total amount • Note that each of these data elements will need its own dictionary entry (and customer name and address may each need to be further decomposed into more data elements)

14. Examples of data dictionary entries for data elements • Data element: Date of birth Alias: Birth date Description: Identifies the date of birth of a student as documented at enrolment time Type: Date Format: dd/mm/yyyy Range: Between 01/01/1900 and today’s date Data element: Student ID Alias: ID Description: Unique number assigned to each student at enrolment to identify them Type: 8 digit numeric Range: From 10000000 to 99999999

15. 3. Dictionary entries defining processes/behaviours • The hierarchy of processes (from FDD) • Upper-level processes • Middle-level processes • Lower-level (primitive) processes • Define upper and mid-level processes by description plus reference to ‘child’ processes which comprise them • Need precise and accurate specification of the bottom-level (primitive) processes • These are commonly known as mini-specs

16. Primitive Process Definitions • Many possible techniques • Narrative English • Structured English • Decision tables • Decision trees • Flow charts • Choose a method which: • Fits the type of processing • Is understandable to the audience

17. Narrative English • Narrative English is the form in which a user will describe a process. It tends to be too wordy, too vague, includes lots of implementation details (ie physical) and is not precise enough • For example: “I have an Excel spreadsheet which Trudi gives me which lists all the students in the subject. I take the assignment results which the tutors have sent me in spreadsheets, and copy the assignment result for each student from the tutor’s spreadsheet to the students result sheet. Then I take the exam booklets and copy the exam result off the front cover ……. etc etc “

18. Structured English • Structured English is like pidgin English - a simplified form of English which removes unnecessary words, and expresses all processing as precisely and succinctly as possible • It uses • only action (imperative) verbs such as get, put, add, calculate, find, delete, etc • only nouns or noun phrases which refer to components (data flows, data stores, data elements) of the DFDs • control structures - sequence, condition, and repetition to describe the sequence in which the actions are done

19. Control Structures in Structured English: Sequence • Sequence in which actions are done is the sequence in which the description presents them • For example: Read student_ID from class_listFind student_ID in exam_resultsRead exam_mark Find student_ID in assignment_resultsRead assignment_result Add exam_mark to assignment_mark to give final_mark Write student_ID, and final_mark in results_list • Sequence can be changed by condition and repetition statements

20. Control Structures in Structured English: Condition • Conditional statements are control structures which specify how the sequence of subsequent actions may change if certain outcomes or conditions occur • Two common forms of conditional control structure are the If... Then...Else statement and the Case statement. If…Then…Else is usually used only if there are two possible outcomes; the Case statement can be used for situations with many possible outcomes • Use indented text for clarity of reading

21. Using an If.. Then.. Else statement Read student_ID and final markRead student fees_status If fees_status = paid then enter final_mark as student_result otherwise enter Withheld as student_result Endif Using a Case statement Calculate mark Case 1 mark > 79: Grade = HD Case 2 mark is from 70-79: Grade = D Case 3 mark is from 60-69: Grade = C Case 4 mark is from 50-59: Grade = P Case 5 mark < 50: Grade = N Examples of Conditional Control Structures

22. Control Structures in Structured English: Repetition • Repetition statements are control statements which cause an action to be repeated until a condition occurs or ceases to occur. This is called a loop. • A Do-Until loop repeats until a condition is met • A Do-While loop repeats while a condition persists

23. Example of Structured English Get sales-order Find customer-name in customer list If customer-name not found Then reject sales-order Else Create invoice Do while more sales-order-items find item-details on sales-order calculate sales-order-item price = item price *order-qty Endo Write customer-name, item-details and sales-order-item-price on invoice Endif

24. Guidelines for Structured English • There are many different versions of Structured English, using slightly different language and structures • The basic principle behind them all is the same: use a series of brief precise statements of the actions which are performed to carry out a primitive process • Don’t worry too much about the detail, but make sure you understand the idea and can demonstrate an example of it in practice

25. Decision Tables • Decision tables can sometimes define a process more clearly and easily than Structured English • They are helpful for describing processes where several conditions may apply, and the actions that are taken are determined by combinations of the values of the conditions • They show all the possible choices and the conditions they depend on in a tabular form

26. outcomes for each set of condition values Decision Tables A decision table is set out like a grid as follows: combinations of condition values List of conditions conditions rules List of possible actions actions outcomes

27. Example process for using decision table • “A student’s final mark is based on their exam and assignment work. If they get less than 40% for either the exam or the assignment work, then they fail the subject regardless of what their overall mark is. If their overall mark is a pass, then they are allowed to repeat the subject, but if they fail overall as well as getting less than 40 for either the assignment or the exam then they are not allowed to attempt to repeat it. If they get over 40% for both the exam and the assignment and their overall mark is a pass, then they pass the subject. If their overall mark is less than 50, but they get at least 40% for both exam and assignment then they will be offered supplementary assessment to give them another chance to pass.”

28. Example Decision Table (for description on previous slide) Exam mark > 39? Y Y Y Y N N N N Assignment mark > 39? Y Y N N Y Y N N Overall mark > 49? Y N Y N Y N Y N X X X Fail: Can’t repeat X X Fail: Can repeat X Supplementary Pass X

29. wholesale customer retail customer Decision Trees • Like decision tables, but show conditions and outcomes as a series of nodes and branches local item 15% Imported item Determine Customer Discount 10% local item 12% Imported item 7%

30. Selecting Techniques for Process Descriptions • Structured English is useful where a process has a clear sequence of activities and there is no more than three levels of nesting of decisions • Decision tables are useful where a process involves a decision based on combinations of values of several conditions • decision trees are useful as for decision tables, but especially where there is also a sequential dependency in the combination of conditions. They give a better visual guide to the possible pathways

31. 4. Data Dictionary entries for system participants • Each actor/stakeholder/external agent should have a data dictionary entry which describes: • Who or what it is • What parts of the system it interacts with • The nature of its relationship/interaction with the system • Use case diagrams and use cases provide a useful formal structure for these definitions

32. Sample data dictionary entries for system participants • The following could be dictionary entry for an external agent named Student in the tutorial enrolment system: Student: Students who are enrolled in a subject can use the system to allocate to a tutorial. Students provide their ID and password to validate their use of the system, and then provide it with their tutorial preferences. The system confirms their preferences and tells them their actual tutorial allocation.

33. Summary • Data dictionaries are a VERY unexciting, but VERY necessary part of defining the information and processes which are used in a system • A good data dictionary has standard formats, information content and methods of organisation for all types of data dictionary entries • All components of analysis models have entries in the data dictionary which are kept up-to-date • Cross-referencing of entries in the data dictionary can help to check the completeness and consistency of the models