Understanding Structured Analysis in Software Design

undefined
 
S
o
f
t
w
a
r
e
 
A
n
a
l
y
s
i
s
 
a
n
d
 
D
e
s
i
g
n
0
7
2
1
3
2
2
 
1
 
C
C
h
h
a
a
p
p
t
t
e
e
r
r
 
 
3
3
S
S
t
t
r
r
u
u
c
c
t
t
u
u
r
r
e
e
d
d
 
 
A
A
n
n
a
a
l
l
y
y
s
s
i
i
s
s
 
Introduction
 
The analysis model must achieve three primary
objectives :
 1. to describe what the customer requires
 2. to establish a basis for the creation of a software
design
 3. to define a set of requirements that can be
validated once the software is built.
 The analysis model bridges the gap between
system-level description that describes overall
system functionality and system design.
 
2
 
Introduction
 
Two different modeling philosophies can be applied:
     - 
Structured analysis :
 
Considers data and the process that transform the data as separate
entities.
 Views software as an information transformer.
Assists the software engineer in identifying data objects, their
relationships,  and the  manner in which those data  objects are
transformed.
 
     - 
Object-oriented analysis :
 Focuses on the definition of classes and the manner in which they
collaborate with one another to affect customer requirements.
 
3
 
 
Structured Analysis Model Elements
 
 Data flow diagram (DFD)
 - provides an indication of how data are
transformed as they move through the system; also depicts
functions that transform the data flow.
Entity relationship diagram (ERD)
 - depicts relationships between
data objects
 
Data dictionary
 - contains the descriptions of all data objects
consumed or produced by the software
 
State diagram (SD)
 - indicates how the system behaves as a
consequence of external events, states are used to represent
behavior modes. Arcs are labeled with the events triggering the
transitions from one state to another (control information is
contained in control specification or CSPEC)
 
 
4
 
Flow-oriented modeling
 
Flow-oriented modeling shows how data are transformed inside the
system by processing functions.
 Creating a Data Flow Model :
    
The Data-flow models are used to show how data objects flow
    through a  sequence of processing steps.
 Creating a Control Flow Model :
   
Represents “events” and the processes that manage  events.
 
5
 
6
 
 
Creating a Data flow Model
 
The data flow diagram enables the software engineer to develop
models of the information domain and functional domain.
Data-flow modeling is a core modeling activity in  structured analysis.
DFDs model the system from a functional perspective
Tracking and documenting how the data associated with a process is
helpful to develop an overall understanding of the system
Data flow diagrams may also be used in showing the data exchange
between a system and other systems in its environment.
 DFD's cannot show procedural detail (e.g., conditionals or loops) only
the flow of data through the software
 
7
 
 
Creating a Data flow Model
 
 
 
8
 
 
Levelled DFDs
 
Break each process
down into sub-
processes
Numbering of processes
indicates their parents
process, and thus their
position in the hierarchy
of levelled DFDs0
 
9
 
 
 
Context Diagram
A data flow diagram (DFD) of the scope of an organizational system that
shows the system boundaries, external entities that interact with the
system and the major information flows between the entities and the
system
   
- Indicate the people, organisations and systems which communicate with our
system
   - Show the data which our system receives from the outside world
   - Show the data produced by the system and sent to the outside world
   - Show the data which is shared by the system with the outside world
   - Show the boundary between the system and the rest of the world
Level-O Diagram
A data flow diagram (DFD) that represents a system’s major processes,
data flows and data stores at a high level of detail
 
 
Levelled DFDs
 
10
 
 
 
Context diagram of Hoosier Burger’s food ordering system
 
11
 
 
 
Level-0 DFD of  food ordering system
 
12
 
 
 
Process Specifications
 
 
Data flow diagrams do not show the logic inside the processes
 
Logic modeling involves representing internal structure and
functionality of processes depicted on a DFD
All bottom level processes are specified
The specifications may be
o
Structured English
o
Pre/Post Conditions
o
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
13
Process Specifications and DFDs
CONTEXT DIAGRAM
Figure 0
DFD
Figure 2 DFD
Process 
Specification
for 
Process
 2.3
Process Spec for Level 2.3
kahgdkljhckldsajcaljscaljljakdclnh
kljclkjcl;kjcl;asjca;sjcjc;kkdj;jsa;k
ckjal;kjcalkjcal;jcaljcal;kjckljcakj
if kjc = mjclakj
then
    do
        ldclscknlskld
else
         jhalkscjl
         lnhclsncdslnc
end - specification
Note:
Process 2.3 is a
lowest-level
process
Note:
Observe that Figures 0
and 2 are balanced
w.r.t. incoming and
outgoing dataflows
 
14
 
 
 
Structured English
 
Subset of English with restrictions on usage
Each sentence must be as follows:
an algebraic equation e.g. X = (Y*(Z+2))/Q+14
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
 
15
 
 
 
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
 
16
 
 
 
Process 1.0:
 Update Inventory Added
Do
     READ next Invoice-item-record
     FIND matching Inventory-record
     ADD Quantity-added from Invoice-item-record to Quantity-in-
stock on inventory-record
UNTIL End-of-file
Process 2.0:
 Update Inventory Used
Do
     READ next Stock-item-record
     FIND matching Inventory-record
     SUBTRACT Quantity-used on Stock-item-record from Quantity-
in-stock on inventory-record
UNTIL End-of-file
 
An example
 
17
 
 
 
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
 
18
 
 
 
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
 
 
19
 
 
 
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
 
20
 
 
 
Modeling Logic with Decision Tables
 
A matrix representation of the logic of a decision
Used when the process result is based around several different variables and
the logic gets too complex for other methods
Specifies the possible conditions and the resulting actions
Best used for complicated decision logic
Consists of three parts
Conditions
Lists condition relevant to decision
Actions
Actions that result from a given set of conditions
Rules
Specify which actions are to be followed for a given set of conditions
 
 
21
 
 
 
Complete decision table for payroll system example
 
22
 
 
 
E
x
a
m
p
l
e
 
23
 
 
 
 
 
Entity-Relationship Diagrams
 
Model the relationships between 
data
 in the system
Highlight the relationships between data stores directly
When using ERD for data modeling, only relationships that are
represented in the data stores (e.g. via a foreign key) should be
shown
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
 
24
 
 
 
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
Customer
 
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.
 
25
 
 
 
Relationships
COUNTRY
CAPITAL
 
One to One Relationship
CUSTOMER
ITEM
COMPANY
SUPPLIER
 
One to Many Relationship
 
Many to Many Relationship
 
26
 
 
 
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
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
Customer
Purchase
Item
 
27
 
 
 
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
 
28
 
 
 
E-R Diagram Guidelines
 
If all data elements in an entity don’t 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
 
29
 
 
 
30
 
 
 
 
 
 
 
Data dictionaries
 
Data dictionaries are lists of all of the names used in the
system models. Descriptions of the entities, relationships
and attributes are also included
Advantages
Support name management and avoid duplication
Store of organisational knowledge linking analysis,
design and implementation
 
31
 
 
 
 
 
Name
 - 
primary name for each data or control item, data store, or
external entity
 
Alias
 - 
alternate names for each data object
 
Where-used/how-used
 - 
a listing of processes that use the data or
control item and how it is used (e.g., input to process, output from
process, as a store, as an external entity)
 
Content description
 - 
notation for representing content
Supplementary information - 
other data type information, preset
values, restrictions, limitations, etc.
 
Data Dictionary Contents
 
32
 
 
 
Data Dictionary Notation
 
=
 
is composed of
+
 
and
( )
 
optional ( may be present or absent)
{ }
 
iteration
[ ]
 
select one of several alternatives
**
 
comment
@
 
identifier (key field) for 
a data
store
|
 
separates alternative choices in the [ ] construct
 
33
 
 
 
Data Dictionary examples
order = @order-id + customer-name + shipping-address + 1{item}10
orders = {order}
customer-
name = 
c
ourtesy-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-Z|a-z|0-9|’|-| |]
 
 
u
a
n
 
o
r
d
e
r
 
a
l
w
a
y
s
 
h
a
s
 
a
n
 
o
r
d
e
r
-
i
d
 
(
w
h
i
c
h
 
i
s
 
t
h
e
 
k
e
y
 
f
i
e
l
d
)
,
 
a
c
u
s
t
o
m
e
r
-
n
a
m
e
 
a
n
d
 
a
 
s
h
i
p
p
i
n
g
-
a
d
d
r
e
s
s
,
 
a
n
d
 
h
a
s
 
b
e
t
w
e
e
n
 
1
 
a
n
d
 
1
0
i
t
e
m
s
.
 
34
 
 
 
State-Transition Diagrams
 
 State-Transition Diagrams (STD) model time-dependent behavior. Many
complex systems have time-dependent behaviour, that is, the sequence in
which data will be accessed and functions will be performed
Have 4 components
States
 : A state is usually denoted either with a rectangle or an oval.
The state is labeled with a noun.
Transitions
 : A transition is denoted by an arrow line connecting one
state to another, with the arrow indicating the transition direction. The
transition is labeled  with a condition, and optionally a corresponding
action. A condition is usually a noun phrase, while an action is most
often a verb phrase.
Conditions
 : A condition is an event in the external environment which
triggers a transition to a new state
Actions
 : 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
Can be levelled like DFDs
Must have one initial state and may have multiple final states
 
 
35
 
 
 
Answering Machine Example: states and
transitions
Idle
Playing
Messages
Rewinding
Recording
Message
Waiting
for call
Answering
Call
Note: this STD is
incomplete: conditions
and actions are not
shown
 
36
 
 
 
Example of conditions/actions
Idle
Waiting for
Call
Answering
Call
 
Press Answer button
 
Ready to receive light
goes on
 
Action
 
Condition
 
Incoming call detected
 
Condition
 
End of Call or tape runs out
 
Press Cancel button
 
Ready to receive button
goes out
 
Condition
 
Condition
 
Action
 
37
 
 
 
Microwave oven model
 
38
 
 
 
Microwave oven state description
 
39
 
 
 
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
 
40
 
 
 
 - The structured analysis model.
 
Extra remarks
 
41
 
42
 
 
Structured analysis and structured design (SASD) may be approached in the
following manner:
Environmental modeling: defines the boundary between the system and the
rest of the world (external objects) and consists of three different activities:
context diagram
event list
Functional/Behavioral modeling: The functional and behavioral model
describes the required behavior of the insides of the system necessary to
interact successfully with the environment
data flow diagram
process specification
data dictionary
entity relationship diagram
state transition diagram
Implementation Modeling : The 
implementation model 
comprises the design
portion  of SASD
structure charts
considerations for modules
 
structured design
 
43
 
 
 
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
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.
 
 
 
44
 
 
 
E-R Diagram and DFDs
 
 
 
Data dictionary entities 
must
 apply to both the DFD model and
the E-R model
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
 
CUSTOMERS = 
 
{Customer}
CUSTOMER =
 
name + address + phone-number + …...
Slide Note
Embed
Share

Structured analysis in software design aims to describe customer requirements, create a basis for software design, and define validatable requirements. Two main modeling philosophies, structured analysis, and object-oriented analysis are discussed. Structured Analysis Model Elements such as Data Flow Diagrams (DFD), Entity Relationship Diagrams (ERD), and State Diagrams are key components. Flow-oriented modeling illustrates how data is transformed within the system. Creating Data Flow Models is essential for developing a comprehensive understanding of the system.


Uploaded on Jul 22, 2024 | 1 Views


Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

E N D

Presentation Transcript


  1. Chapter 3 Structured Analysis Software Analysis and Design 0721322 1

  2. Introduction The analysis model must achieve three primary objectives : 1. to describe what the customer requires system description 2. to establish a basis for the creation of a software design analysis model 3. to define a set of requirements that can be validated once the software is built. The analysis model bridges the gap between system-level description that describes overall system functionality and system design. design model 2

  3. Introduction Two different modeling philosophies can be applied: - Structured analysis : Considers data and the process that transform the data as separate entities. Views software as an information transformer. Assists the software engineer in identifying data objects, their relationships, and the manner in which those data objects are transformed. - Object-oriented analysis : Focuses on the definition of classes and the manner in which they collaborate with one another to affect customer requirements. 3

  4. Structured Analysis Model Elements Data flow diagram (DFD) - provides an indication of how data are transformed as they move through the system; also depicts functions that transform the data flow. Entity relationship diagram (ERD) - depicts relationships between data objects Data dictionary - contains the descriptions of all data objects consumed or produced by the software State diagram (SD) - indicates how the system behaves as a consequence of external events, states are used to represent behavior modes. Arcs are labeled with the events triggering the transitions from one state to another (control information is contained in control specification or CSPEC) 4

  5. Flow-oriented modeling Flow-oriented modeling shows how data are transformed inside the system by processing functions. Creating a Data Flow Model : The Data-flow models are used to show how data objects flow through a sequence of processing steps. Creating a Control Flow Model : Represents events and the processes that manage events. 5

  6. Creating a Data flow Model The data flow diagram enables the software engineer to develop models of the information domain and functional domain. Data-flow modeling is a core modeling activity in structured analysis. DFDs model the system from a functional perspective Tracking and documenting how the data associated with a process is helpful to develop an overall understanding of the system Data flow diagrams may also be used in showing the data exchange between a system and other systems in its environment. DFD's cannot show procedural detail (e.g., conditionals or loops) only the flow of data through the software 6

  7. Creating a Data flow Model 7

  8. Levelled DFDs Terminator 1 Terminator 2 Break each process down into sub- processes Numbering of processes indicates their parents process, and thus their position in the hierarchy of levelled DFDs0 The System Datastore 1 Terminator 3 Context Diagram Terminator 2 1. Wiggle Widget Terminator 1 2. Grind Gadget 3. Dangle Doover Terminator 3 Datastore 1 Figure 0 DFD 8

  9. Levelled DFDs A data flow diagram (DFD) of the scope of an organizational system that shows the system boundaries, external entities that interact with the system and the major information flows between the entities and the system - Indicate the people, organisations and systems which communicate with our system - Show the data which our system receives from the outside world - Show the data produced by the system and sent to the outside world - Show the data which is shared by the system with the outside world - Show the boundary between the system and the rest of the world Level-O Diagram A data flow diagram (DFD) that represents a system s major processes, data flows and data stores at a high level of detail Context Diagram 9

  10. Context diagram of Hoosier Burgers food ordering system 10

  11. Level-0 DFD of food ordering system 11

  12. Process Specifications Data flow diagrams do not show the logic inside the processes Logic modeling involves representing internal structure and functionality of processes depicted on a DFD All bottom level processes are specified The specifications may be o Structured English o Pre/Post Conditions o 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 implementationdecisions 12

  13. Process Specifications and DFDs Figure 2 DFD CONTEXT DIAGRAM Note: 2.2 Process 2.3 is a lowest-level process 2.1 Note: Observe that Figures 0 and 2 are balanced w.r.t. incoming and outgoing dataflows 2.3 Process Spec for Level 2.3 kahgdkljhckldsajcaljscaljljakdclnh kljclkjcl;kjcl;asjca;sjcjc;kkdj;jsa;k ckjal;kjcalkjcal;jcaljcal;kjckljcakj if kjc = mjclakj then do ldclscknlskld else jhalkscjl lnhclsncdslnc end - specification 1 2 Process Specification for Process 2.3 3 4 Figure 0 DFD 13

  14. Structured English Subset of English with restrictions on usage Each sentence must be as follows: an algebraic equation e.g. X = (Y*(Z+2))/Q+14 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 14

  15. An example Calculate Tax Rate - Process Specification in Structured English IFgoods are Taxable DO CASE CASEgoods-type = Food SET tax-rate to 0 CASEgoods-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 15 ENDIF

  16. An example Process 1.0: Update Inventory Added Do READ next Invoice-item-record FIND matching Inventory-record ADD Quantity-added from Invoice-item-record to Quantity-in- stock on inventory-record UNTIL End-of-file Process 2.0: Update Inventory Used Do READ next Stock-item-record FIND matching Inventory-record SUBTRACT Quantity-used on Stock-item-record from Quantity- in-stock on inventory-record UNTIL End-of-file 16

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

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

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

  20. Modeling Logic with Decision Tables A matrix representation of the logic of a decision Used when the process result is based around several different variables and the logic gets too complex for other methods Specifies the possible conditions and the resulting actions Best used for complicated decision logic Consists of three parts Conditions Lists condition relevant to decision Actions Actions that result from a given set of conditions Rules Specify which actions are to be followed for a given set of conditions 20

  21. Complete decision table for payroll system example 21

  22. Example 1 Y Y N N N 2 Y N Y N N X 3 Y N N Y N 4 Y N N N Y 5 N Y N N N 6 N N Y N N 7 N N N Y N 8 N N N N Y Goods are taxable Goods type = Clothes Goods type = Food Goods type = Vehicles Goods type = Other Set tax rate = 0 Set tax rate = 20 Set tax rate = 40 Set tax rate = 15 Write tax not applicable X X X X X X X 22

  23. Entity-Relationship Diagrams Model the relationships between data in the system Highlight the relationships between data stores directly When using ERD for data modeling, only relationships that are represented in the data stores (e.g. via a foreign key) should be shown 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 23

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

  25. Relationships has CAPITAL COUNTRY One to One Relationship purchases ITEM CUSTOMER One to Many Relationship SUPPLIER supplies COMPANY Many to Many Relationship 25

  26. Associative Entities Sometimes it is necessary to store data about a relationship We then need to turn the relationship into an entity CUSTOMER ITEM purchases 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 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 26

  27. 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 Credit Customer Cash Customer 27

  28. E-R Diagram Guidelines If all data elements in an entity don t 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 28

  29. 29

  30. Data dictionaries Data dictionaries are lists of all of the names used in the system models. Descriptions of the entities, relationships and attributes are also included Advantages Support name management and avoid duplication Store of organisational knowledge linking analysis, design and implementation 30

  31. Data Dictionary Contents Name - primary name for each data or control item, data store, or external entity Alias - alternate names for each data object Where-used/how-used - a listing of processes that use the data or control item and how it is used (e.g., input to process, output from process, as a store, as an external entity) Content description - notation for representing content Supplementary information - other data type information, preset values, restrictions, limitations, etc. 31

  32. Data Dictionary Notation = is composed of + and ( ) optional ( may be present or absent) { } iteration [ ] select one of several alternatives ** comment @ identifier (key field) for a datastore | separates alternative choices in the [ ] construct 32

  33. Data Dictionary examples order = @order-id + customer-name + shipping-address + 1{item}10 orders = {order} customer-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-Z|a-z|0-9| |-| |] an order always has an order-id (which is the key field), a customer-name and a shipping-address, and has between 1 and 10 items. 33

  34. State-Transition Diagrams State-Transition Diagrams (STD) model time-dependent behavior. Many complex systems have time-dependent behaviour, that is, the sequence in which data will be accessed and functions will be performed Have 4 components States : A state is usually denoted either with a rectangle or an oval. The state is labeled with a noun. Transitions : A transition is denoted by an arrow line connecting one state to another, with the arrow indicating the transition direction. The transition is labeled with a condition, and optionally a corresponding action. A condition is usually a noun phrase, while an action is most often a verb phrase. Conditions : A condition is an event in the external environment which triggers a transition to a new state Actions : 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 Can be levelled like DFDs Must have one initial state and may have multiple final states 34

  35. Answering Machine Example: states and transitions Idle Waiting for call Recording Message Playing Messages Rewinding Note: this STD is incomplete: conditions and actions are not shown Answering Call 35

  36. Example of conditions/actions Condition Condition Idle Press Cancel button Press Answer button Ready to receive light goes on Ready to receive button goes out Waiting for Call Action Action End of Call or tape runs out Incoming call detected Answering Call Condition Condition 36

  37. Microwave oven model Full power Full power do: set power = 600 Timer Waiting do: display time Number Operation Set time do: get number exit: set time Full power do: operate oven Half power Half power Door closed Cancel Timer Door open Start Door open Waiting do: display time Half power do: set power = 300 Enabled do: display 'Ready' Door closed Disabled do: display 'Waiting' 37

  38. Microwave oven state description State Description Waiting Half power The oven is waiting for input. The display shows the current time. The oven power is set to 300 watts. The display shows Half power . The oven power is set to 600 watts. The display shows Full power . The cooking time is set to the user s input value. The display shows the cooking time selected and is updated as the time is set. Oven operation is disabled for safety. Interior oven light is on. Display shows Not ready . Oven operation is enabled. Interior oven light is off. Display shows Ready to cook . Oven in operation. Interior oven light is on. Display shows the timer countdown. On completion of cooking, the buzzer is sounded for 5 seconds. Oven light is on. Display shows Cooking complete while buzzer is sounding. Full power Set time Disabled Enabled Operation 38

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

  40. - The structured analysis model. 40

  41. Extra remarks 41

  42. Structured analysis and structured design (SASD) may be approached in the following manner: Environmental modeling: defines the boundary between the system and the rest of the world (external objects) and consists of three different activities: context diagram event list Functional/Behavioral modeling: The functional and behavioral model describes the required behavior of the insides of the system necessary to interact successfully with the environment data flow diagram process specification data dictionary entity relationship diagram state transition diagram Implementation Modeling : The implementation model comprises the design portion of SASD structure charts considerations for modules structured design 42

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

  44. E-R Diagram and DFDs CUSTOMERS = CUSTOMER = name + address + phone-number + ... {Customer} Data dictionary entities must apply to both the DFD model and the E-R model 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 44

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#