www.monash.edu.au

IMS1805Systems Analysis

Topic 5: Formal analysis and specification

www.monash.edu.au

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

www.monash.edu.au

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

www.monash.edu.au

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)

www.monash.edu.au

5

Implications

• Understanding audiences and their needs• Setting standards:

• for diagramming• for terminology and techniques• for system elements

• The need for a data dictionary

www.monash.edu.au

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?

www.monash.edu.au

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

www.monash.edu.au

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

www.monash.edu.au

9

2. 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

www.monash.edu.au

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

www.monash.edu.au

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

www.monash.edu.au

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

www.monash.edu.au

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)

www.monash.edu.au

14

Examples of data dictionary entries for data elements

• Data element: Date of birthAlias: Birth dateDescription: Identifies the date of birth of a

student as documented at enrolment time Type: Date Format: dd/mm/yyyyRange: Between 01/01/1900 and today’s date

Data element: Student IDAlias: IDDescription: Unique number assigned to each student

at enrolment to identify them Type: 8 digit numericRange: From 10000000 to 99999999

www.monash.edu.au

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

www.monash.edu.au

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

www.monash.edu.au

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 “

www.monash.edu.au

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

www.monash.edu.au

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

www.monash.edu.au

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

www.monash.edu.au

21

Examples of Conditional Control Structures

• 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

www.monash.edu.au

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

www.monash.edu.au

23

Example of Structured English

Get sales-order Find customer-name in customer listIf customer-name not found

Then reject sales-orderElse

Create invoiceDo while more sales-order-items

find item-details on sales-ordercalculate sales-order-item price = item price *order-qty

EndoWrite customer-name, item-details and sales-order-item-price on invoice

Endif

www.monash.edu.au

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

www.monash.edu.au

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

www.monash.edu.au

26

Decision Tables

A decision table is set out like a grid as follows:

conditions rules

actions

outcomesfor each setof conditionvalues

combinations of condition values

List of conditions

List of possibleactions

outcomes

www.monash.edu.au

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.”

www.monash.edu.au

28

Example Decision Table (for description on previous slide)

Pass

Y Y

X

X

X

X

X X

Exam mark > 39?

Assignment mark > 39?

Overall mark > 49?

Fail: Can repeat

Supplementary

Y

Y

Y

N

X

Fail: Can’t repeat

YY

N N

N NN

NN

NNNN

Y Y

Y Y

Y

www.monash.edu.au

29

wholesalecustomer

retailcustomer

local item

local item

Imported item

Imported item

Determine Customer

Discount

15%

10%

12%

7%

Decision Trees

• Like decision tables, but show conditions and outcomes as a series of nodes and branches

www.monash.edu.au

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

www.monash.edu.au

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

www.monash.edu.au

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.

www.monash.edu.au

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