CS 310 Ch8: System models

1
CS 310 Ch8 System models

• Abstract descriptions of systems being analyzed
  to
• help the analyst understand the system
  functionality
• communicate with customers
• Models present the system from different
  perspectives
• external perspective for the systems context or
  environment
• behavioural perspective showing the behaviour of
  the system
• structural perspective showing the system or data
  architecture

2
Models

• 8.1 Context Models (illustrate the system
  boundaries)
• Architectural models show a system and its
  relationship with other systems
• Process models show the processes that the system
  supports. Used to describe a systems overall
  behaviour.
• 8.2 Behavioural models (how a system behaves)
• Data flow models (DFD) show how data moves
  through the system
• State machine models show the systems response to
  events
• 8.3 Data Models (ER diagrams and data
  dictionaries)
• 8.4 Object Models (like C classes)
• 8.5 Structured methods
• Very little difference between DFD and process
  models

3
Context model an ATM system
the system
This is architectural, it says nothing about how
systems interact
4
Equipment procurement process
Process models needed to describe activities
5
8.2.1 Data-flow models

• Data flow diagrams (DFDs) show the processing
  steps as data flows through a system
• from a functional perspective
• simple and intuitive notation that customers can
  understand
• Similar to process diagrams, with the focus on
  data flows
• tracking and documenting the data associated with
  a process helps to develop an overall
  understanding of the system
• Data flow diagrams may also show what data is
  exchanged with other systems in the environment

6
Order processing DFD
How does this differ from an architectural
process model? In the way it is arrived at one
is derived from what information passes through
the system, the other from what is happening May
be a small piece of one of the bubbles in the
process model
7
8.2.2 State machine models

• Model the system response to external and
  internal events
• Often used for modelling real-time systems
• Conventions
• system states are nodes
• events are arcs between these nodes
• when an event occurs, the system moves from one
  state to another

8
State machine microwave oven
state name what it does
state transitions
9
Microwave oven expansion of the Operation state

10
Context (8.1) versus Behavioral Models (8.2)

• Context defines system boundaries
• high level fig 8.1 shows simple boundaries
• lower level process diagrams (e.g. fig 8.2) show
  activities, distinguishing between internal and
  external activities
• Behavioral how it behaves
• data flow (like process, but emphasis is on data)
• sometimes an elaboration of an activity in a
  process model
• state machine

11
Process Diagram for IM Operation
...
DFD for IM Sign On
12
8.3 (Semantic) data models

• Describe the logical structure of data processed
  by the system using ER model
• How does this differ from CS 325 notation?

13
8.4 Object models

• Describe the system in terms of object classes a
  set of objects with common attributes and the
  services (operations)
• Natural way to reflect the real-world entities
• Abstract entities are more difficult to model
  this way
• Types
• inheritance models
• aggregation models
• interaction models

What do you know about object models?
14
Library class hierarchy
8.4.1 Inheritance models
15
Multiple inheritance

• Object classes can inherit from several
  super-classes
• Can lead to semantic conflicts when
  attributes/services with the same name in
• different super-classes have different
  semantics
• Makes class hierarchy reorganization more complex

16
Object aggregation
17
8.4.3 Object behaviour modelling using a UML
sequence diagram
18
8.5 Structured Methods

• Often a company will have a well-defined modeling
  process
• Structured methods define
• a set of models
• a process for deriving these models
• rules and guidelines that should apply to the
  models
• Normally with specific CASE tool support
• This can be too restrictive
• More commmon practice
• use a variety of models to elicit requirements