DFD (Recap) and Process Specification: Systems Analysis and Modelling Unit Convener: DR Saif Dewan

Lecture 6
DFD (Recap) and Process

Specification
Systems Analysis and Modelling
Unit Convener: Dr Saif Dewan
Systems Analysis and Modelling School of Information Systems and Accounting

Semester 2 2014 @ Faculty of BGL
Lecture Outline
• Administration
• DFD (Revision)
• Process Specifications
• ERDs
• Events, Conditions, Responses
(Revision)

Semester 2 2014 2
@ Faculty of BGL
Administration
• Assignment (Part 1) was due on last
Friday, 12th September 11:55 pm
• Assignment (Part 2) Specification is up

in Moodle
– It’s an Individual Assignment
– Due on Friday 17th October 11:55 pm,
Week 10
– Marking criteria is also available in
Moodle
Systems Analysis and Modelling School of Information Systems and Accounting 3
Where are We?

DFD Hierarchy
Level 0 Context Diagram
Level 1 DFD 0
Level 2 DFD s 1,2,3, etc
5
DFD Rules (Recap)
6
DFD Rules (Recap) cont.
7
Accessing Data Stores
1.2
Write, 1.1
Update write Read-
only
or Delete read Process
Process
Store
DataFlow
read then write/ Dataflow name to/from store

update may be omitted if all the data from
an element in the store is flowing.
1.3
Read
and
Write
Process

Process Specifications
All of the PSpecs together must contain an unambiguous
specification of all of the functional requirements of the system. PSpec 1.1.2
~~~~~~~~~
~~~~~~~~~
PSpec 1.1.1 ~~~~~~~~~
1.1.2 ~~~~~~~~~
~~~~~~~~~
~~~~~~~~~ 1.1.1 PROCESS
~~~~~~~~~
PROCESS
~~~~~~~~~
1.1.3
PSpecs typically occur STORE-A
lower down in the DFD PROCESS
structure. PSpec 1.1.3
PSpecs are functional primitives typically containing a ~~~~~~~~~

precise description of just one function that the system ~~~~~~~~~
is required to perform. ~~~~~~~~~
~~~~~~~~~

Process Specifications (continued)
• To describe what a primitive process must

accomplish.
• Inputs 1.1
Create
• Outputs Account
• Optionally
Accounts
– Pre-conditions Account_Details
– Post-conditions
• How to produce outputs from inputs.

Should be:
– Readable
– Verifiable
– Understandable
– Precise
– Succinct

• Can occur anywhere in hierarchy

• At the point where it doesn’t make
sense to break process down in
another DFD
• Usually don’t occur at DFD 0
PSpec 1.1 Create Account
1.1
Create
Account
Accounts
Account_Details

• Can be specified in several ways

– Structured Language
– Decision Table / Tree
– Reference to an algorithm documented
elsewhere
– Mathematical specification
– Flowcharts etc.

Writing Process Specifications
• Structured Language
» Restricted set of English verbs.
» Sequence, Selection and Iteration constructs
• Decision Tables / Trees
» For simplification of complex decision making processes.
• Algorithm Reference
» Don’t duplicate common or standard knowledge (e.g.
encryption).
• Mathematical Equations and Identities
» Algebraic expressions
» Standard mathematical notation
• Graphs and Charts
» Expressing properties / relationships

Structured Language
• Combines structured programming
techniques with narrative English (or
other language)
• Well-suited for lengthy sequential
processes or simple control logic
(single loop or if-then-else)
• Ill-suited for complex decision logic or
few (or no) sequential processing
steps
Structured Language Guidelines
1. Choose a restricted set of suitable verbs:
• Preferable to select a set of action words with which
the customer/user is familiar.
• When possible, obtain these verbs from the original
requirements document.
• Ensure that all such terms are used consistently.
• Create a glossary - try and limit it to less than 100
terms.
• Avoid using imprecise verbs or generalised entity
names.
2. Construct simple rather than compound sentences:

• Simple sentences are more succinct and less
ambiguous than compound ones.
• Use mathematical notation freely.
Systems Restrict
• Analysis
Semester 2 2014
object/subject
and Modelling of@aFaculty
simple
School of Information Systems andsentence
of BGL
Accounting to (data) 16
(continued)
3. Include sequence, selection & iteration constructs.
» Sequence:
– The natural order of statements (sentences) within a PSpec.
– A PSpec should be read from top to bottom.
» Selection:
– IF - THEN - ELSE
– CASE (WHEN) - DO
» Iteration:
– REPEAT - UNTIL
– DO - WHILE
(continued)
4. Develop pre-conditions by isolating the following:

• Necessary availability of particular inputs.
• Relationships between (fields of) different inputs or
conditions of elements within an input.
• Relationships between (fields of) inputs and elements of
(data) stores.
• Relationships between (elements of) different stores or
conditions of elements within a store.
5. Develop post-conditions by isolating the following:

• Particular outputs that will be generated from the PSpec.
• Relationships between output values and input values.
• Relationships between output values and values (of
elements) in stores with which the process communicates.
• Alterations to stores (Additions, Modifications, Deletions).

Structured English: An Example
of Purchase Process(1)
BEGIN IF
IF Purchase–amount is greater than $15,000.00
THEN Purchasing–Department APPROVES RFP
DO Bid Process
ELSE Purchasing–Department APPROVES Purchase
PURCHASE equipment
END IF
RETURN
19
of Purchase Process (1) cont.
(Bid Process)
SEND RFP
BEGIN IF
IF three Proposals received
AND Winning–Vendor is APPROVED by Purchasing–Department
AND no Violations
THEN AWARD contract
PURCHASE equipment
ELSE DO Rebid Process
END IF
RETURN
20
of Purchase Process (1) cont.
(Rebid Process)
SEND RFP
BEGIN IF
IF Winning–Vendor is APPROVED by Purchasing–Department
AND no Violations
THEN AWARD contract
PURCHASE equipment
END IF
ISSUE Purchase Order
RETURN
21
Sales Promotion Policy Procedure
(2)
If customer is a preferred customer
If customer orders more than $1000
Apply a 10% discount
If customer uses our credit card
Apply an additional 10% discount
End If
Else
Award a $50 bonus coupon
End If
Else
Award a $10 bonus coupon
End If 22
Structured English: An Example (3)

PSpecs as Decision Tables/Trees
• When written descriptions become too difficult to
follow because of complex decision logic then use
a Decision Table/Tree to express the logic more
clearly.
• Decision Tables/Trees are constructed when various
combinations of inputs to a decision making
process result in differing actions.
• More readable.

Decision Table
• It is a matrix representation of the

logic of a decision which specifies the
possible conditions for the decision
and the resulting actions.
• Best used for complicated decision
logic
25
Decision Table models Logic
using:
• Condition stubs: that part of a decision table that
lists the conditions relevant to the decision
• Action stubs: that part of a decision table that lists
the actions that result for a given set of conditions
• Rules: that part of a decision table that specifies
which actions are to be followed for a given set of
conditions
• Indifferent condition: in a decision table, a

condition whose value does not affect which
actions are taken for two or more rules
26
Decision Table: An Example
27
Procedure for Creating Decision
Table
1. Name the condition and the values
that each condition can assume.
2. Name all possible actions that can
occur.
3. List all possible rules.
4. Define the actions for each rule.
5. Simplify the table.
28
Simplified Decision Table
29
Decision Table: An Example (2)
30
Decision Table for Calculating
Shipping Charges: An Example
(3)

Decision Tree for Calculating
Shipping Charges

Process Specifications: A Note
of Caution
• Process Specifications are NOT
programs
• Structured Language should be

chosen appropriately for the particular
system being specified

Process Specifications: A Note
of Caution (continued)
• PSpecs are an important component of the Traditional Model.
• There is no advantage in trivialising PSpecs.
• Be prepared to write and rewrite PSpecs in order to reduce

the possibility of misinterpretation and the consequent
introduction of errors.
• Sometimes it is worthwhile writing the equivalent of PSpecs

for every process bubble - this leads to good abstraction.
• Use of formal specifications in PSpecs is worthwhile.

Coupling
• “Coupling or dependency is the

degree to which each program
module relies on each one of the
other modules”.
• Originally a design concept, but is

appropriate at the analysis activity
level as well.
Coupling (continued)
• Measure of interdependence.
• Changes in one activity affect other activities.
• Aim for low coupling because it:

• Allows change to be localised – reduces ripple
effect;
• Promotes understanding – easier to maintain;
and
• Promotes flexibility – easier to reuse.
• Avoid high coupling because:

• Activities are not independent; and
• Need to know the internal working of connected
activities.
Semester 2 2014
School of Information Systems and Accounting
@ Faculty of BGL
36
Types of Coupling
• “No coupling
Modules do not communicate at all with one another.
• Message coupling (low)

This is the loosest type of coupling. It can be achieved by state decentralization (as in
objects) and component communication is done via parameters or message passing.
• Data coupling
Data coupling is when modules share data through, for example, parameters. Each
datum is an elementary piece, and these are the only data shared (e.g., passing an
integer to a function that computes a square root).
• Stamp coupling (Data-structured coupling)

Stamp coupling is when modules share a composite data structure and use only a part
of it, possibly a different part (e.g., passing a whole record to a function that only needs
one field of it). This may lead to changing the way a module reads a record because a
field that the module doesn't need has been modified.
• Control coupling
Control coupling is one module controlling the flow of another, by passing it information
on what to do (e.g., passing a what-to-do flag). “

Types of Coupling (continued)
• External coupling
External coupling occurs when two modules share an externally
imposed data format, communication protocol, or device interface.
This is basically related to the communication to external tools and
devices.
• Common coupling
Common coupling is when two modules share the same global data
(e.g., a global variable). Changing the shared resource implies
changing all the modules using it.
• Content coupling (high)

Content coupling is when one module modifies or relies on the
internal workings of another module (e.g., accessing local data of
another module). Therefore changing the way the second module
produces data (location, type, timing) will lead to changing the
Highest Coupling
dependent module.
Cohesion
• Cohesion is a measure of how

strongly-related or focused the
responsibilities of a single module are.
• Originally a design concept, but is

appropriate at the analysis activity
level as well.

Strong Cohesion
Types of Cohesion
Functional cohesion (best)
Functional cohesion is when parts of a module are grouped because they all contribute
to a single well-defined task of the module (e.g. tokenizing a string of XML).
Sequential cohesion
Sequential cohesion is when parts of a module are grouped because the output from
one part is the input to another part like an assembly line (e.g. a function which reads
data from a file and processes the data).
Communicational cohesion
Communicational cohesion is when parts of a module are grouped because they
operate on the same data (e.g. a module which operates on the same record of
information).
Procedural cohesion
Procedural cohesion is when parts of a module are grouped because they always follow
a certain sequence of execution (e.g. a function which checks file permissions and then
opens the file).
Temporal cohesion
Temporal cohesion is when parts of a module are grouped by when they are processed -
the parts are processed at a particular time in program execution (e.g. a function which
is called after catching an exception which closes open files, creates an error log, and
notifies the user).
Logical cohesion
Logical cohesion is when parts of a module are grouped because they logically are
categorized to do the same thing, even if they are different by nature (e.g. grouping all
mouse and keyboard input handling routines).
Loose Cohesion
Coincidental cohesion (worst)
Coincidental cohesion is whenSchool
partsofofInformation
a module are grouped
Systems arbitrarily; the only
and Accounting 40
relationship between the parts is that they have been grouped together (e.g. a
PSpec Checks
• Any data mentioned as input in the

PSpec must be an input to the PSpec.
• Any output must be produced by the

PSpec.
• Looking at the PSpec in isolation,

someone should still be able to
understand it.
PSpec Rules
• Balancing again
• Inputs and Outputs on parent diagram

must match the inputs and outputs in
the Process Specification.

Entity Relationship Diagram
• Entities
– Attributes
– Key attributes
• Relationships
– Reflexive Relationships
– Other complex relationships
(relationship loops)
Key Attributes
• Primary Key Attributes
– The primary key of an entity unambiguously
distinguishes between occurrences of the entity
• (Candidate) Key Attributes

– Need to identify during analysis
what attributes and combination
of attributes are keys
(not design/implementation unique IDs)
– Record in data dictionary

Foreign Key Attributes
• Foreign keys (also known as referential
attributes) are attributes that define
relationships between entities.
• Relationships are represented in the ERD
• How they are formalised is a design issue:
leave out of analysis
Car
Person
Driver

Attribute Types
• Document in data dictionary
• May also represent on the ERD
(this makes the ERD a more useful diagram)
• Depends on size and
purpose of ERD
Car
Registration Number: ACT Registration Number
Vehicle Identification Number: VIN
Make: Text
Model: Text
Year of Manufacture: Year

Recursive Relationships
• Relationships where the SAME entity
is on both ends of the relationship.
• AKA Reflexive Relationships

Recursive Relationships (continued)
• Often represent a hierarchy.

Relationships - Complexity
• Determining attributes is often quite

straight-forward
• Relationships, their creation, lifecycle

and (possible) deletion is usually
where a lot of complexity occurs.

Relationship Loops
• Possible loop constraints.
Department Enrolled for Degree Student
Constraint: A student can only Currently

study units that are part of the Studying
degree they are enrolled in
Unit

Events Recap
• An event is some change in a system’s environment.
• An event occurs at a determinable time and place, with

or without the participation of human agents. It may be
a part of a chain of occurrences as an effect of a
preceding occurrence and as the cause of a succeeding
occurrence.
• A temporal event may occur at the arrival of a

significant point in time. In project management, an
event marks the point in time when a task is
completed.
• A response is the set of actions (usually accompanied

by some message returned to the environment)
performed
Semester 2 2014 by the system
whenever a (particular) event
School of Information Systems and Accounting
@ Faculty of BGL
51
Events and Conditions
• An event will have at least a noun (possibly more)
and a verb.
• Something outside the system (a stakeholder)
does something.
• The system is in a condition
– Depending on the condition, the system performs an
activity
– Not all systems have conditions – don’t make them up if
they don’t exist.
• The system produces a response
– Response goes to something outside the system
(stakeholder) or
– Data is saved for later use.
Bad Events: Examples
• “Have to re-build nursery so that
adapt to the comprehensive
information system.”
– Part of purpose
• “Order”
– What does this mean?
• “Create Order”
– This is an activity
Good Events: Examples
Stakeholders
Verbs (in red)
And/or Nouns (in blue)
Custome Submits Order

r
Customer Searches for Birth Details
Time for Producing Monthly

Report

Coffee Shop: An Example
• This example is intended to give you

an indication of how the parts of the
analysis work together – it is not a
complete example

Coffee Shop: An Example (continued)

Purpose
• A business to sell beverages and

cakes to seated and take-away
customers.

Stakeholders
• Customer
• Barista
• Cook
• Wait Staff
• Owner
• Supplier
• Government (GST, OH&S etc.)
• Bank
Rich Picture (Progressive)
Coffee Shop
Customer
Bank
Wait Staff
Barista
Owner
Supplier
Cook
Government
Some Events
{
• Seated Customer submits Order
External • Seated Customer pays for Order
• Take away Customer submits
and pays for Order
• Time to open shop

Temporal { • Time to close shop
State
{• Beverage low point reached

Data Dictionary: A Partial
Example
Order ::= Order_Type + (Beverage_Order) +
(Cake_Order)
Order_Type ::= Sit_Down | Take_Away
Beverage_Order ::= 1{Quantity + Beverage}*
Quantity::= “Whole Number”
Beverage ::= Beverage_Size + Beverage_Type +
(Syrup)
Beverage_Size ::= Small | Medium | Large
Beverage_Type ::= Cappicino | Latte | Long_Black |
Water
Syrup ::= Vanilla | Caramel | Hazelnut
Cake_Order ::= 1{Quantity + Cake}*
Cake ::= Banana_Bread | Carrot_Cake | Cheesecake
| Analysis and Modelling
Systems School of Information Systems and Accounting 61
Next Week
• ERDs (continued)
• DFDs (continued)
• Data Dictionary

Questions


DFD (Recap) and Process Specification: Systems Analysis and Modelling Unit Convener: DR Saif Dewan

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

DFD (Recap) and Process Specification: Systems Analysis and Modelling Unit Convener: DR Saif Dewan

Hochgeladen von

Copyright:

Verfügbare Formate

Lecture 6

DFD (Recap) and Process

Systems Analysis and Modelling School of Information Systems and Accounting

Systems Analysis and Modelling School of Information Systems and Accounting

• Assignment (Part 2) Specification is up

Systems Analysis and Modelling School of Information Systems and Accounting 4

Level 2 DFD s 1,2,3, etc

read then write/ Dataflow name to/from store

Systems Analysis and Modelling School of Information Systems and Accounting 8

PSpecs are functional primitives typically containing a ~~~~~~~~~

Systems Analysis and Modelling School of Information Systems and Accounting 9

• To describe what a primitive process must

Systems Analysis and Modelling School of Information Systems and Accounting 10

Systems Analysis and Modelling School of Information Systems and Accounting 11

• Can occur anywhere in hierarchy

Systems Analysis and Modelling School of Information Systems and Accounting 12

• Can be specified in several ways

Systems Analysis and Modelling School of Information Systems and Accounting 13

Systems Analysis and Modelling School of Information Systems and Accounting 14

2. Construct simple rather than compound sentences:

3. Include sequence, selection & iteration constructs.

4. Develop pre-conditions by isolating the following:

5. Develop post-conditions by isolating the following:

Systems Analysis and Modelling School of Information Systems and Accounting 18

Systems Analysis and Modelling School of Information Systems and Accounting 23

Systems Analysis and Modelling School of Information Systems and Accounting 24

• It is a matrix representation of the

• Indifferent condition: in a decision table, a

Systems Analysis and Modelling School of Information Systems and Accounting 31

Systems Analysis and Modelling School of Information Systems and Accounting 32

• Structured Language should be

Systems Analysis and Modelling School of Information Systems and Accounting 33

• PSpecs are an important component of the Traditional Model.

• There is no advantage in trivialising PSpecs.

• Be prepared to write and rewrite PSpecs in order to reduce

• Sometimes it is worthwhile writing the equivalent of PSpecs

• Use of formal specifications in PSpecs is worthwhile.

Systems Analysis and Modelling School of Information Systems and Accounting 34

• “Coupling or dependency is the

• Originally a design concept, but is

• Aim for low coupling because it:

• Avoid high coupling because:

• Message coupling (low)

• Stamp coupling (Data-structured coupling)

Systems Analysis and Modelling School of Information Systems and Accounting 37

• Content coupling (high)

• Cohesion is a measure of how

• Originally a design concept, but is

Systems Analysis and Modelling School of Information Systems and Accounting 39

• Any data mentioned as input in the

• Any output must be produced by the

• Looking at the PSpec in isolation,

• Inputs and Outputs on parent diagram

Systems Analysis and Modelling School of Information Systems and Accounting 42

• (Candidate) Key Attributes

Systems Analysis and Modelling School of Information Systems and Accounting 44

Systems Analysis and Modelling School of Information Systems and Accounting 45

Registration Number: ACT Registration Number

Vehicle Identification Number: VIN

Year of Manufacture: Year

Systems Analysis and Modelling School of Information Systems and Accounting 46

• AKA Reflexive Relationships

Systems Analysis and Modelling School of Information Systems and Accounting 47