Software Engineering: Analysis and Design CSE3308

1
Software Engineering Analysis and Design -
CSE3308
CSE3308/DMS/2002/8
Monash University - School of Computer Science
and Software Engineering

• Structured Analysis 2

2
Lecture Outline

• Process Specifications
• Entity-Relationship Diagrams
• State Transition Diagrams
• The Data Dictionary
• Integrating the models

3
Process Specifications

• All bottom level processes are specified
• The specifications may be
• Structured English
• Pre/Post Conditions
• Decision Tables
• Need to be more formal and specific than normal
  English
• Need to be easily understandable by the user
• Should not impose arbitrary design or
  implementation decisions

4
Process Specifications and DFDs
CONTEXT DIAGRAM
Figure 2 DFD
2.2
Process Specification for Data Flow Diagram 2.3
2.1
2.3
Process Spec for Level 2.3 kahgdkljhckldsajcaljsc
aljljakdclnh kljclkjclkjclasjcasjcjckkdjjsak
ckjalkjcalkjcaljcaljcalkjckljcakj if kjc
mjclakj then do ldclscknlskld else
jhalkscjl lnhclsncdslnc end -
specification
Figure 0 DFD
1
2
4
3
5
Structured English

• Subset of English with restrictions on usage
• Each sentence must be as follows
• an algebraic equation e.g. X (Y(Z2))/Q14
• or consist of a simple imperative sentence with a
  verb and an object
• e.g. Read next Order
• e.g. Display Result to Screen
• Can use IF THEN ELSE construction
• Can use CASE construction
• can use LOOP construction
• Object must be defined in the analysis (i.e. in
  Data Dictionary) or must be a local term defined
  for that process only

6
Structured English 2

• Some Acceptable Verbs
• GET/READ
• PUT/DISPLAY/WRITE
• FIND
• ADD
• SUBTRACT
• MULTIPLY
• DIVIDE
• COMPUTE
• DELETE
• VALIDATE
• MOVE
• REPLACE
• SET
• SORT

Define other verbs as necessary, but each must
have a clear and specific meaning
7
An example
Calculate Tax Rate - Process Specification in
Structured English IF goods are Taxable DO
CASE CASE goods-type Food set tax-rate
to 0 CASE goods-type Vehicle set
tax-rate to 20 CASE goods-type
Clothes set tax-rate to 40 OTHERWISE set
tax-rate to 15 ENDCASE ELSE write Tax not
applicable to Results data store ENDIF
8
Restrictions

• No more than one A4 page long
• No more than three levels of nesting
• Use indentation to show levels of nesting

9
Pre and Post Conditions

• Describe the process without specifying the
  algorithm
• Useful approach when
• need to get away from existing method of
  performing the task
• there may be many possible algorithms to use
• want to let the implementer explore the values of
  various algorithms

10
Pre Conditions

• Describe what must be true before the process
  begins operating
• What inputs must be available
• e.g. Account Number exists
• What relationships exist between inputs or within
  inputs
• e.g. Purchase Order account number is the same as
  the Customer account number
• What relationships exist between inputs and data
  stores
• e.g. There is a Customer with that account number
  in the Customer data store
• What relationships exists between different
  stores or within a single store
• e.g. there is a purchase order in the Purchase
  Order data store with the current date

11
Post Conditions

• Describe what must be true when the process is
  completed
• The outputs that will be generated by the process
• e.g. An invoice will be generated
• The relationship between the output and the
  original input values
• e.g. invoice-total will equal the sum of the unit
  prices multiplied by number ordered plus
  shipping-costs
• Relationships between output values and values in
  one or more stores
• e.g. The number-remaining for each item in the
  Inventory data store will be reduced by the
  amount-ordered for each item
• The changes that will have been made to stores
• e.g. A new record will be appended to the Invoice
  data store

12
Example
Process Specification Compute Sales Tax Pre
Condition 1 SALE-DATA occurs with ITEM-TYPE
matching an ITEM-CATEGORY in TAX-CATEGORIES Post
Condition 1 SALES-TAX is set to SALE-AMOUNT
TAX-RATE Pre Condition 2 SALE-DATA occurs with
ITEM-TYPE not matching an ITEM-CATEGORY in
TAX-CATEGORIES Post Condition 2 ERROR-MESSAGE
is generated and written to Results data store
13
Decision Tables

• Used when the process result is based around
  several different variables and the logic gets
  too complex for other methods
• To create
• List all the relevant variables
  (inputs/conditions) and all the relevant actions
  on the left of the table
• Number all the possible combination of variables
  on the top of the table
• Generally use binary (True/False) variables
• Set a rule for each possible result
• i.e. certain combinations of inputs imply certain
  actions

14
Example
15
Entity-Relationship Diagrams

• Model the relationships between data in the
  system
• Highlight the relationships between data stores
  directly
• Very useful in relational database systems
• Often more central to your system than DFDs
• 4 Components
• Entity types
• Relationships
• Associative entity types
• Supertype/subtype indicators

16
Entity Types

• A collection of entities whose individual members
  have the following characteristics
• Each can be uniquely identified in some manner
• Each plays a necessary role in the system we are
  building
• Each can be described by one or more data elements

• CHARACTERISTICS
• Has a Customer Number
• Is necessary for a sales system
• Described by elements such as name, address,
  customer number, phone, number, credit rating etc.

Customer
17
Relationships

• Entities are connected by relationships
• Relationships represent a set of connections
  between entities
• Relationships have cardinality
• one to one
• one to many
• many to many

CUSTOMER
ITEM
18
Relationships
Note these are ERD fragments. In a complete ERD,
all relationships between entities are shown
One to One Relationship
COUNTRY
CAPITAL
One to Many Relationship
CUSTOMER
ITEM
Many to Many Relationship
COMPANY
SUPPLIER
19
Exercise - Complete the Relationships
Employee
Company
Mother
Child
Driver
Car
20
Multiple relationships
Patient
Doctor
21
Associative Entities

• Sometimes it is necessary to store data about a
  relationship
• We then need to turn the relationship into an
  entity
• We might want to keep track of date of purchase,
  method of purchase, location of purchase, none of
  which fit into the Customer or Item entity

CUSTOMER
ITEM
purchases
22
Associative Entity 2

• So we create a Purchase entity
• Note that Customer and Item exist regardless of
  any Purchase
• Purchase only exists as a result of the
  relationship between the other two

Customer
Item
Purchase
23
Supertypes/Subtypes

• Often there are different types of a basic entity
• For example if we have a CUSTOMER entity, but we
  keep different information on customers using
  cash and customers using credit we could specify
  it as follows

Customer
Cash Customer
Credit Customer
24
E-R Diagram Guidelines

• If all data elements in an entity dont apply to
  all instances, think about creating subtypes
• Carefully examine to see if associative entities
  are needed
• Modify the diagram when
• Consist only of an identifier and have no data
  elements
• Have only one instance in the system
• Can derive the information and thus the
  relationship is unnecessary
• Remember that ER-Diagrams are for modelling data
  stored in the system
• There is no need to show external entities about
  which no data is stored

25
A complete ERD
26
State-Transition Diagrams

• Represent a process specification for a Control
  bubble in a Data Flow Diagram
• only for control processes!
• Have 4 components
• States
• Transitions
• Conditions
• Actions
• Can be levelled like DFDs
• Must have one initial state
• May have multiple final states

27
Answering Machine Example states and transitions
Idle
Playing Messages
Rewinding
Recording Message
Waiting for call
Note this STD is incomplete conditions and
actions are not shown
Answering Call
28
Conditions and Actions

• A condition is an event in the external
  environment which triggers a transition to a new
  state
• An action is a response sent back to the external
  environment or a calculation whose result is
  stored by the system that occurs when the
  transition takes place

29
Example of conditions/actions
Idle
Condition
Condition
Press Cancel button
Press Answer button
Ready to receive light goes on
Ready to receive button goes out
Waiting for Call
Action
Action
Condition
End of Call or tape runs out
Incoming call detected
Condition
Answering Call
30
Levelling State-Transition Diagrams
State 2
Can be partitioned to
State 2.3
State 2.1
State 2.2
State 2.4
31
Guidelines for State-Transition Diagrams

• Have all states been defined?
• Can you reach all the states?
• Can you exit from all the states?
• In each state does the system respond to all
  possible conditions?

32
The Data Dictionary

• Provides definitions for all elements in the
  system which include
• Meaning of data flows and stores in DFDs
• Composition of the data flows e.g. customer
  address breaks down to street number, street
  name, city and postcode
• Composition of the data in stores e.g. in
  Customer store include name, date of birth,
  address, credit rating etc.
• Details of the relationships between entities

33
Data Dictionary Notation
is composed of and ( ) optional ( may be
present or absent) iteration select one
of several alternatives comment _at_ identifier
(key field) for store separates alternative
choices in the construct name
courtesy-title first-name (middle-name)
last-name courtesy-title Mr. Miss
Mrs. Ms. Dr. Professor first-name
legal-character middle-name
legal-character last-name
legal-character legal-character
A-Za-z0-9-
34
Data Dictionary examples
Current-height units metres range
1.00-2.50 sex values MF As
both are elementary data, no composition need be
shown, though an explanation of the relevant
units/symbols is needed order customer-name
shipping-address 1item10 means that an order
always has a customer name and a shipping
address and has between 1 and 10 items
35
Integrating the Models

• Structured Analysis consists of many different
  models
• Each model focuses on one aspect of the system
• Often hard to see the connections between the
  different models, resulting in inconsistencies
• Need an approach to check each model against the
  other models

36
DFDs and the Data Dictionary

• Every data flow (arrow on a DFD) and every data
  store must be defined in the data dictionary
• Every data element and every data store must
  appear on a data flow diagram somewhere in the
  system

37
DFD and the Process Specifications

• Every bubble in the DFDs must be associated with
  a lower level DFD or with a process specification
• Every process specification must have an
  associated bottom-level bubble in the DFDs
• Incoming and outgoing data flows in the DFD and
  connections to data stores must be matched in the
  relevant process specification
• Each data element in the process specification
  must be
• the name of a data flow or data store
• or a local term explicitly defined in the process
  specification
• or a component in a data dictionary for a data
  flow or data store connected to the bubble

38
E-R Diagram and DFDs and Process Specifications

• Every data store in the DFDs must correspond to
  an entity type or a relationship or an
  associative entity
• Entity names and data store names must match. Use
  plural for data stores, singular for entities.
• Data dictionary entities must apply to both the
  DFD model and the E-R model

CUSTOMERS Customer CUSTOMER name address
phone-number ...
39
Process Specifications and E-R Diagrams

• Process specifications, as a whole, must
• Create and delete instances of each entity type
  and relationship in the E-R Diagram
• Some DFD bubble sets the values for each data
  element in an entity
• Some DFD bubble uses the the values of each data
  element

40
DFDs and State-Transition Diagrams

• Every Control bubble in a DFD must have an
  associated state-transition diagram as its
  process specification
• Every condition in the state-transition diagram
  must correspond to an incoming control flow on
  the control bubble
• Every action in the state-transition diagram must
  correspond to an outgoing control flow on the
  control bubble

41
Correspondence between the DFD and the
State-Transition Diagram
42
Importance of Maintaining Model Integrity

• Maintaining the integrity of all the components
  of the analysis model is absolutely vital
• This is a key task of Configuration Management
• If the correspondences between the various
  components described in the preceding slides are
  not maintained, the overall model is essentially
  useless
• THIS WILL BE AN IMPORTANT FACTOR WHEN YOUR
  ASSIGNMENTS ARE ASSESSED

43
References

• Yourdon, E., Modern Structured Analysis, Prentice
  Hall, 1989.