CS451 Topic 6: Domain Analysis

1
CS451Topic 6 Domain Analysis
Specification

• Yugi Lee
• STB 555
• [phone]
• leeyu_at_umkc.edu
• www.sice.umkc.edu/leeyu

2
Analysis Modeling Where to Begin?

• statement of scope can be acquired from
• the FAST working document
• A set of use-cases
• statement of scope a relatively brief
  description of the system to be built
• indicates data that are input and output and
  basic functionality and conditional processing
  implying certain constraints and limitations
• the statement of scope must be parsed to
  extract data, function and behavioral domain
  information

3
Identifying Data and Operations

• define data objects by underlining all nouns in
  the written statement of scope
• producers/consumers of data
• places where data are stored
• composite data items
• define operations by double underlining all
  active verbs
• processes relevant to the application
• data transformations
• consider other services that will be required
  by the objects

4
Structured Paradigm vs. Object
Oriented Paradigm

• ER Diagram
• (vs. Class Diagram, Sequence Diagram)
• Data Flow Diagram
• (vs. Sequence Diagram)
• State Transaction Diagram
• (vs. State Diagram, Activity Diagram)
• Control Diagram

5
Why Data Modeling?

• examines data objects independently of processing
• focuses attention on the data domain
• creates a model at the customers level of
  abstraction
• indicates how data objects relate to one another

6
What is a Data Object?

• Data Object a set of attributes (data items)
  that will be manipulated within the software
  (system)
• each instance of an object (e.g., a book) be
  identified uniquely (e.g., ISBN )
• each plays a necessary role in the system could
  not function without access to instances of the
  object
• each is described by attributes that are
  themselves data items

7
Typical Objects

• external entities (printer, user, sensor)
• things (e.g, reports, displays, signals)
• occurrences or events (e.g., interrupt, alarm)
• roles (e.g., manager, engineer, salesperson)
• organizational units (e.g., division, team)
• places (e.g., manufacturing floor)
• structures (e.g., employee record)

8
Data Objects/Attributes Relationship

• A data object contains a set of attributes that
  act as an aspect, quality, characteristic, or
  descriptor of the object
• object automobile
• attributes make, model, body type, price,
  options code
• A relationship indicates connectedness a
  "fact" that must be "remembered" by the system
  and cannot or is not computed or derived
  mechanically
• several instances of a relationship can exist
• objects can be related in many different ways

9
ER Diagram Notation
One common form
(0, m)
object
object
relationship
1
2
(1, 1)
attribute
Another common form
relationship
object
object
1
2
(1, 1)
(0, m)
10
Building an ER Diagram

• Level 1model all data objects (entities) and
  their connections to one another
• Level 2model all entities and relationships
• Level 3model all entities, relationships, and
  the attributes that provide further depth

11
The ERD An Example
request for service
Customer
places
(1,1)
(1,m)
(1,1)
standard task table
(1,n)
work order
generates
(1,1)
(1,1)
(1,1)
(1,w)
work tasks
selected from
consists of
(1,w)
(1,i)
materials
lists
12
(No Transcript)
13
ENTITIES ATTRIBUTES

• Entities represent a class of similar things. The
  differences among the instances of a class are
  denoted by the values of the entity's
  attributes.
• Entities are denoted by rectangles in Entity -
  Relationship ( ER ) diagrams. They contain a
  unique textual label indicating the name of the
  class.
• Attributes are denoted by circles. The textual
  label contained in the circle will ultimately
  become the name of a database field.
• Attributes are connected to their associated
  entities by unlabeled and undirected arcs.

14
RELATIONSHIPS

• Entities bear relationships to each other.
• Relationships are denoted by diamonds. The
  diamonds are connected to the associated entities
  by undirected arcs.
• The diamonds are labeled with verbs which are
  different from the verbs and verb phrases
  labeling process nodes in data flow diagrams
• DFD an active function to be performed by some
  computing process.
• ER more non-committal. They indicate that two
  entity classes are somehow related, not that one
  is necessarily produced from the other.

15
RELATIONSHIPS

• The arcs may be labeled. A label indicates the
  type of relationship between two entities.
• A 11 relationship indicates that each instance
  of one entity corresponds to one and only one
  instance of the second. Likewise, each instance
  of the second corresponds to one and only one
  instance of the first. E.g., each wife has
  exactly one husband and vice versa.
• A 1M relationship indicates that a single
  instance of one entity corresponds to multiple
  instances of the other. E.g., many familymembers
  may live in the same house.
• An MM relationship indicates that multiple
  instances of one entity corresponds to multiple
  instances of the other. E.g., a person eats many
  different kinds of vegetables, and a given type
  of vegetable may be eaten by different people.

16
Keys

• Modeling an entity involves selecting attributes
  to indicate how the instances of the entity class
  are represented in the database.
• It is important that one of the attributes have
  values that are unique. Such an attribute is
  called a key attribute and is indicated by an
  asterisk.
• E.g., the Social Security Number is often used as
  a key attribute when data about people is stored
  in a database.
• Sometimes, an ordered collection of attributes
  can serve as a key. E.g, a house can be
  identified by its street name and street number.

17
Roles

• It is possible to further clarify a diagram by
  labeling arcs with role names. This is useful
  when the relationship is recursive or involves
  more than two entities.
• For example

18
The Data Flow Model
Every computer-based system is an information
transform ....
computer based system
input
output
19
Data Flow Modeling Notation
external entity
process
data flow
data store
20
External Entity Process

• External Entity A producer or consumer
  of data
• Data must always originate somewhere and must
  always be sent to something e.g., a person, a
  device, a sensor, computer-based system
• Process A data transformer
• (changes input to output)
• Data must always be processed in some way to
  achieve system function e.g., compute taxes,
  determine area, format report, display graph

21
Data Flow
Data flows through a system, beginning as input
and be transformed into output.
base
compute triangle area
area
height
22
Data Stores
Data is often stored for later use.
sensor
sensor , type, location, age
look-up sensor data
report required
type, location, age
sensor number
sensor data
23
Constructing a DFDI

• review ERD to isolate data objects and
  grammatical parse to determine operations)
• determine external entities (producers and
  consumers of data
• create a level 0 DFD

processing request
user
requested video signal
digital video processor
monitor
video source
NTSC video signal
24
Constructing a DFDII

• write a narrative describing the transform
• parse to determine next level transforms
• balance the flow to maintain data flow
  continuity
• develop a level 1 DFD
• use a 15 (approx.) expansion ratio

25
The Data Flow Hierarchy
a
b
P
x
y
level 0
c
p2
a
f
p1
b
p4
d
5
g
p3
e
level 1
26
DFDs A Look Ahead
analysis model
Maps into
design model
27
Behavioral Modeling
events
behavior
Outside world
Application
28
The States of a System

• statea set of observable circumstances that
  characterizes the behavior of a system at a given
  time
• state transitionthe movement from one state to
  another
• eventan occurrence that causes the system to
  exhibit some predictable form of behavior
• actionprocess that occurs as a consequence of
  making a transition

29
Behavioral Modeling

• make a list of the different states of a system
  (How does the system behave?)
• indicate how the system makes a transition from
  one state to another (How does the system change
  state?)
• indicate event
• indicate action
• draw a state transition diagram

30
State Transition Diagram Notation
state
event causing transition
action that occurs
new state
31
State Transition Diagram
full and start
reading
invoke manage-copying
operator
commands
full
invoke read-op-input
copies done
invoke read-op-input
making copies
reloading paper
empty
invoke reload paper
jammed
invoke problem-diagnosis
not jammed
invoke read-op-input
problem state
32
Microwave Oven Model
33
Microwave oven state description
State
Description
Waiting
The oven is waiting for input. The display shows
the
current time.
Half power
The oven power is set to 300 watts. The display
shows Half power.
Full power
The oven power is set to 600 watts. The display
shows Full power.
Set time
The cooking time is set to the users input
value. The
display shows the cooking time selected and is
updated as the time is set.
Disabled
Oven operation is disabled for safety. Interior
oven
light is on. Display shows Not ready.
Enabled
Oven operation is enabled. Interior oven light is
off.
Display shows Ready to cook.
Operation
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.
34
Microwave oven stimuli
Stimulus
Description
Half power
The user has pressed the half power button
Full power
The user has pressed the full power button
Timer
The user has pressed one of the timer buttons
Number
The user has pressed a numeric key
Door open
The oven door switch is not closed
Door closed
The oven door switch is closed
Start
The user has pressed the start button
Cancel
The user has pressed the cancel button
35
Statecharts

• Allow the decomposition of a model into
  sub-models (see following slide)
• A brief description of the actions is included
  following the do in each state
• Can be complemented by tables describing the
  states and the stimuli

36
Microwave oven operation
37
UML State Diagram

• Shows the behavior of one object
• how does it change its state based
• on the messages it receives,
• narrowly focused, fine-grained
• State condition/situation during
• lifetime of an object
• State transition relationship indicating a
  state change (atomic non interruptible)
• Action atomic non-interruptible

38
State notation (1)

• Substates disjoint/concurrent
• Entry/exit actions
• entry an action that is performed on entry to
  the state
• exit an action performed on exiting the state
• do an ongoing activity performed while in the
  state (example display window)
• interruptible
• on an action performed as a result of a specific
  event

State name
state variable(s)
entry entry action
do activity-A
on event-A action-A
exit exit-action
39
Transition notation (2)
Event(arguments)condition/action
State-A
State-B

• Event significant occurrence that has a location
  in time and space
• triggers the transition
• signals, calls, passing of time, change in state
• Guard condition
• Transition only eligible to fire when guard
  evaluates to true
• Guards of transition exiting one state are
  mutually exclusive
• Action executable atomic computation

40
State diagram notation (3)

• Start state
• No event triggers allowed
• branch conditions allowed
• may not remain in start states
• End state
• Top level end state terminates a state machine

41
State transitions for an order
get next item not all
Item received some
items checked
items not in stock
All items checked some
items not in stock
Checking
/ get first item
Waiting
do check item
All items checked
Item received all items
all items available
available
Dispatching
Delivered
Delivered
do initiate delivery
42
The Control Model

• the control flow diagram is "superimposed" on the
  DFD and shows events that control the processes
  noted in the DFD
• control flowsevents and control itemsby dashed
  arrows
• a vertical bar implies an input to or output from
  a control spec (CSPEC) a separate specification
  that describes how control is handled
• a dashed arrow entering a vertical bar is an
  input to the CSPEC
• a dashed arrow leaving a process implies a data
  condition
• a dashed arrow entering a process implies a
  control input read directly by the process
• control flows do not physically
  activate/deactivate the processesthis is done
  via the CSPEC

43
Control Flow Diagram