Principles of Se CH8
Principles of Se CH8
8
System Model
Subtopics:-
8.1 Context Model
8.2 Behavioral Model
8.3 Data Model
8.4 Object Model
System Modelling helps the analyst to understand the functionality of the system and
models are used to communicate with customers. Different models present the system from
different perspectives:
External perspective showing the system’s context or environment.
Behavioural perspective showing the behaviour of the system.
Structural perspective showing the system or data architecture.
There are several types of system model:
Data processing model showing how the data is processed at different stages
Composition model showing how entities are composed of other entities
Architectural model showing principal sub-systems
Classification model showing how entities have common characteristics
Stimulus/response model showing the system’s reaction to events
71 | P a g e C h a p t e r 8 : S y s t e m M o d e l
8.1 Context Model
Context models are used to illustrate the operational context of the system. They show what
lies outside the system boundaries. Social and organizational concerns may affect the
decision on where to position system boundaries. Architectural models show the system
and its relationship with other systems. Context models normally show that the environment
includes several other automated systems. However, they do not show the types of
relationships between the systems in the environment and the system that is being
specified. External systems might produce data for or consume data from the system. They
might share data with the system, or they might be connected directly, through a network
or not connected at all. They might be physically co-located or located in separate
buildings.
Behavioral models are used to describe the overall behaviour of a system. There are two
types of behavioural model:
• Data processing models that show how data is processed as it moves through the
system.
• State machine models that show the systems response to events.
These models show different perspectives so both of them are required to describe the
system’s behaviour. In data-processing models, Data Flow Diagram (DFD) may be used.
These show the processing steps as data flows through a system. Data Flow Diagrams are
an intrinsic part of many analysis methods. It is simple and intuitive notation usage that
customers can understand. In DFD, it shows end-to-end processing of data. It is 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.
72 | P a g e C h a p t e r 8 : S y s t e m M o d e l
Example of Data Flow Diagram
State machine model the behaviour of the system in response to external and internal
events. They show the system’s responses to stimuli so are often used for modelling real-time
systems. State machine models show system states as nodes and events as arcs between
these nodes. When an event occurs, the system moves from one state to another.
Statecharts are an integral part of the UML and are used to represent state machine
models. Statecharts allows the decomposition of a model into sub-models. A brief
description of the actions is included following the’do’ in each state. Statechart can be
complemented by tables describing the states and the stimuli.
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 show ‘Half Power’
Full power The oven power is set to 600 watts. The display show ‘ Full Power’
Set time 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.
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 time countdown. On
completion of cooking, the buzzer is sounded for 5 seconds. Oven light is on. Display
shows ‘Cooking complete’ while buzzer is sounding.
Microwave oven state Description.
73 | P a g e C h a p t e r 8 : S y s t e m M o d e l
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
Microwave oven Stimuli
Semantic data models used to describe the logical structure of data processed by the
system. An entity-relation-attribute model sets out the entities in the system, the relationships
between these entities and the entity attributes. These models widely used in database
design. It can readily be implemented using relational databases. No specific notation
provided in the UML but objects and associations can be used.
Data dictionaries are lists of all of the names used in the system models. It is the descriptions
of the entities, relationships, and attributes are also included. The advantages of data
dictionary;
• Support name management and avoid duplication
• Store of organizational knowledge linking analysis, design and implementation.
Many CASE workbenches support data dictionaries.
74 | P a g e C h a p t e r 8 : S y s t e m M o d e l
8.4 Object Model
Object models describe the system in terms of object classes and their associations. An
object class is an abstraction over a set of objects with common attributes and the services
(operations) provided by each object. Various object models may be produced;
Inheritance models
Aggregation models
Interaction models
Natural ways of reflecting the real-world entities manipulated by the system. More abstract
entities are more difficult to model using this approach. Object class identification is
recognized as a difficult process requiring a deep understanding of the application
domain. Object classes reflecting domain entities are reusable across systems. Inheritance
models organize the domain object classes into a hierarchy. Classes at the top of the
hierarchy reflect the common features of all classes. Object classes inherit their attributes
and services from one or more super-classes. These may then be specialized as necessary.
Class hierarchy design can be a difficult process if duplication in different branches is to be
avoided. The UML is a standard representation devised by the developers of widely used
object-oriented analysis and design methods. It has become an effective standard for
object-oriented modelling. UML consists of notation. Object classes are rectangles with the
name at the top, attributes in the middle section and operations in the bottom sections.
Relationships between object classes, known as association are shown as lines linking
objects. Inheritance is referred to as generalization and is shown upwards rather than
downwards in a hierarchy.
Example of UML
75 | P a g e C h a p t e r 8 : S y s t e m M o d e l
Rather than inheriting the attributes and services from a single parent class, a system which
supports multiple inheritance allows object classes to inherit from several super-classes. This
can lead to semantic conflicts where attributes/services with the same name in different
super-classes have different semantics. Multiple inheritance makes class hierarchy
reorganization more complex.
An object aggregation model shows how classes that are collections are composed of
other classes. Aggregation models are similar to the part-of-relationship in semantic data
models.
A behavioural model shows the interactions between objects to produce some particular
system behaviour that is specified as a use-case. Sequence diagrams in the UML are used
to model interaction between objects.
76 | P a g e C h a p t e r 8 : S y s t e m M o d e l
Structure methods incorporate system modelling as an inherent part of the methods.
Methods define a set of models, a process for deriving these models and rules and
guidelines that should apply to the models. CASE tools support system modelling as part of
a structured method. However, there are some weakness of structured methods which are:
They do not model non-functional system requirements
They do not usually include information about whether a method is appropriate for a
given problem.
They may produce too much documentation
The system models are sometimes too detailed and difficult for users to understand.
77 | P a g e C h a p t e r 8 : S y s t e m M o d e l