2.2. Software cycle Models-System_Models.ppt

System Models
A description of the various models that
can be used to specify software
systems.

Objectives
 To explain why the context of a system
should be modelled as part of the RE process
 To describe behavioural modelling, data
modelling and object modelling
 To introduce some of the notations used in
the Unified Modeling Language (UML)

 System modeling is the process of developing abstract
models of a system, with each model presenting a different
view or perspective of that system.
 It is about representing a system using some kind of graphical
notation, which is now almost always based on notations in
the Unified Modeling Language (UML).
 The Unified Modeling Language (UML) is a general-purpose,
developmental, modeling language in the field of
software engineering that is intended to provide a standard way to
visualize the design of a system.
 Models help the analyst to understand the functionality of
the system. They are used to communicate with customers.
System Modeling

Models can explain the system from different
perspectives:
 An external perspective, where you model the context or
environment of the system.
 An interaction perspective, where you model the
interactions between a system and its environment, or
between the components of a system.
 A structural perspective, where you model the
organization of a system or the structure of the data that
is processed by the system.
 A behavioral perspective, where you model the dynamic
behavior of the system and how it responds to events.

Five types of UML diagrams that are the most
useful for system modeling:
 Activity diagrams, which show the activities involved
in a process or in data processing.
 Use case diagrams, which show the interactions
between a system and its environment.
 Sequence diagrams, which show interactions between
actors and the system and between system
components.
 Class diagrams, which show the object classes in the
system and the associations between these classes.
 State diagrams, which show how the system reacts to
internal and external events.

Activity diagram
 An activity diagram is a behavioral diagram
 It depicts the behavior of a system.
 An activity diagram portrays the control flow
from a start point to a finish point showing the
various decision paths that exist while
the activity is being executed.

2.2. Software cycle Models-System_Models.ppt

Use case diagram
 A use case diagram is a dynamic behavior diagram
in UML.
 Use case diagrams model the functionality of a system
using actors and use cases.
 Use cases are a set of actions, services, and functions
that the system needs to perform.

Sequence diagram
 A sequence diagram simply depicts interaction between
objects in a sequential order i.e. the order in which
these interactions take place.
 We can also use the terms event diagrams or event
scenarios to refer to a sequence diagram.
 Sequence diagrams describe how and in what order
the objects in a system function.

State diagram
 A state diagram is a type of diagram used in
computer science and related fields to
describe the behavior of systems.
 State diagrams require that the system
described is composed of a finite number
of states.

Class diagram
 A class diagram in the Unified Modeling Language
(UML) is a type of static structure diagram
 It describes the structure of a system by showing the
system's classes, their attributes, operations (or
methods), and the relationships among objects.

Object models
 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.

Object 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 recognised as a
difficult process requiring a deep
understanding of the application domain
 Object classes reflecting domain entities are
reusable across systems

Inheritance models
 Organise 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
specialised as necessary.
 Class hierarchy design can be a difficult process if
duplication in different branches is to be avoided.

Object models and the UML
 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.
 Notation
 Object classes are rectangles with the name at the top,
attributes in the middle section and operations in the
bottom section;
 Relationships between object classes (known as
associations) are shown as lines linking objects;
 Inheritance is referred to as generalisation and is shown
‘upwards’ rather than ‘downwards’ in a hierarchy.

Object aggregation
 An 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.

Model types
 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.

Process models
 Process models show the overall process
and the processes that are supported by the
system.
 Data flow models may be used to show the
processes and the flow of information from
one process to another.

Equipment procurement process
Get cost
estimates
Accept
delivery of
equipment
Check
deli
vered
items
Validate
specifica
tion
Specify
equipment
requir
ed
Choose
supplier
Place
equipment
order
Install
equipment
Find
suppliers
Supplier
database
Accept
delivered
equipment
Equipment
database
Equipment
spec.
Check
ed
spec.
Delivery
note
Delivery
note
Order
notifica
tion
Installa
tion
instructions
Installa
tion
acceptance
Equipment
details
Checked and
signed or
der f
orm
Order
details plus
blank order
form
Spec. +
supplier +
estimate
Supplier list
Equipment
spec.

Behavioural models
 Behavioural models are used to describe the
overall behaviour of a system.
 Two types of behavioural model are:
 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.

Object behaviour modelling
 A behavioural model shows the interactions
between objects to produce some particular
system behaviour that is specified as a use-
case.
 Sequence diagrams (or collaboration
diagrams or interaction diagrams) in the UML
are used to model interaction between
objects.

Structured methods
 Structured methods incorporate system
modelling as an inherent part of the method.
 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.

Data-processing models
 Data flow diagrams (DFDs) may be used to
model the system’s data processing.
 These show the processing steps as data
flows through a system.
 DFDs are an intrinsic part of many analysis
methods.
 Simple and intuitive notation that customers
can understand.
 Show end-to-end processing of data.

What is a Data Flow Diagram?
 A data flow diagram (DFD) is a graphical
representation of the movement of data
between external entities, processes and data
stores within a system.
 Simply put, DFD’s show how data moves
through an information system.

DFD Symbols (cont.)
 Process: work or actions performed on data
(inside the system)
 Data store: data at rest (inside the system)
 Source/sink: external entity that is origin or
destination of data (outside the system)
 Data flow: arrows depicting movement of data

Process
 The work or actions performed on data so that
they are transformed, stored, or distributed.
 Process labels should be verb phrases!
33
1.0
Produce
Grade
Report
Grade Detail Grade Report

 A path for data to move from one part of the
system to another.
 Data in motion!
 Arrows depict the movement of data.
 NO VERBS
34
2.1
Post
Payment
Accounts
Receivable
D1
Payment Detail
Invoice Detail
Data Flow

Data Store
 Used in a DFD to represent data that the system
stores
 Data at rest!
 Labels should be noun phrases
 (NO VERBS)
35
Students
D1

External Entity or Source/Sink
 The origin or destination of data!
 This represents things outside of the system.
 Source – Entity that supplies data to the system.
 Sink – Entity that receives data from the system.
 The labels should be noun phrases!
36
CUSTOMER
1.0
Verify
Order
Order
Invoice

DFD Diagramming Rules
Process
No process can have
only outputs or only
inputs…processes
must have both
outputs and inputs.
Process labels should be verb phrases.

Data Store
Data store labels should be noun phrases.
All flows to or from a data store must
move through a process.

Source/Sink
Source and sink labels should be noun phrases.
No data moves directly between external entities
without going through a process.
Interactions between external entities without
intervening processes are outside the system and
therefore not represented in the DFD.

Data Flow
Bidirectional flow
between process
and data store is
represented by two
separate arrows.
Forked data flow
must refer to exact
same data item (not
different data items)
from a common
location to multiple
destinations.

Data Flow (cont.)
Joined data flow
must refer to exact
same data item (not
different data items)
from multiple
sources to a
common location.
Data flow cannot
go directly from a
process to itself,
must go through
intervening
processes.

Data Flow (cont.)
 Data flow from a process to a data store
means update (insert, delete or change).
 Data flow from a data store to a process
means retrieve or use.
 Data flow labels should be noun phrases.

General DFD Rules
43
YES NO
A process to another process
A process to an external entity
A process to a data store
An external entity to another external entity
An external entity to a data store
A data store to another data store

Advantages of DFDs
 Simple graphical techniques which are easy to
understand
 Helps define the boundaries of the system
 Useful for communicating current system
knowledge to users
 Explains the logic behind the data flow within the
system
 Used as the part of system documentation file
44

Order processing DFD
Complete
order f
orm
Order
details +
blank
order f
orm
V
alidate
order
Recor
d
order
Send to
supplier
Adjust
available
budget
Budget
file
Orders
file
Completed
order f
orm
Signed
order f
orm
Signed
order f
orm
Check
ed and
signed or
der
+ order
notifica
tion
Order
amount
+ account
details
Signed
order f
orm
Order
details

Data flow diagrams
 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.

Insulin pump DFD
Insulin
requirement
computa
tion
Blood sugar
analysis
Blood sugar
sensor
Insulin
delivery
contr
oller
Insulin
pump
Blood
Blood
parameters
Blood sugar
level
Insulin
Pump contr
ol
commands Insulin
requir
ement

Process Modeling
 Graphically represent the processes that
capture, manipulate, store, and distribute
data between a system and its environment and
among system components
 Utilize information gathered during requirements
determination
 Processes and data structures are modeled

Process Modeling (cont.)
Deliverables and Outcomes
 Context data flow diagram (DFD)
 Scope of system
 DFDs of current physical and logical system
 Enables analysts to understand current system
 DFDs of new logical system
 Technology independent
 Show data flows, structure, and functional
requirements of new system
 Thorough description of each DFD component

Data Flow Diagram (DFD)
 A picture of the movement of data between
external entities and the processes and data
stores within a system
 Difference from system flowcharts:
 DFDs depict logical data flow independent of
technology
 Flowcharts depict details of physical systems

Functional Decomposition
 An iterative process of breaking a system
description down into finer and finer details
 High-level processes described in terms of
lower-level sub-processes
 DFD charts created for each level of detail

DFD Levels
 Context DFD
 Overview of the organizational system
 Level-0 DFD
 Representation of system’s major processes at high
level of abstraction
 Level-1 DFD
 Results from decomposition of Level 0 diagram
 Level-n DFD
 Results from decomposition of Level n-1 diagram

Context Diagram
Context diagram
shows the
system
boundaries,
external entities
that interact with
the system, and
major
information flows
between entities
and the system.
NOTE: only one process symbol, and no data stores shown.

Level-0 DFD
Level-0 DFD
shows the
system’s major
processes, data
flows, and data
stores at a high
level of
abstraction.
Processes are labeled 1.0, 2.0, etc. These will be decomposed into
more primitive (lower-level) DFDs.

Level-1 DFD
Level-1 DFD shows
the sub-processes
of one of the
processes in the
Level-0 DFD.
This is a Level-1
DFD for Process
4.0.
Processes are labeled 4.1, 4.2, etc. These can be further
decomposed in more primitive (lower-level) DFDs if
necessary.

Level-n DFD
Level-n DFD shows
the sub-processes
of one of the
processes in the
Level n-1 DFD.
This is a Level-2
DFD for Process
4.3.
Processes are labeled 4.3.1, 4.3.2, etc. If this is the
lowest level of the hierarchy, it is called a primitive DFD.

Guidelines for Drawing DFDs
 Completeness
 DFD must include all components necessary for
system.
 Each component must be fully described in the
project dictionary or CASE repository.
 Consistency
 The extent to which information contained on one
level of a set of nested DFDs is also included on
other levels.

Guidelines for Drawing DFDs (cont.)
 Timing
 Time is not represented well on DFDs.
 Best to draw DFDs as if the system has never started and
will never stop.
 Iterative Development
 Analyst should expect to redraw diagram several times
before reaching the closest approximation to the system
being modeled.
 Primitive DFDs
 Lowest logical level of decomposition
 Decision has to be made when to stop decomposition

Advantages of using DFDs
 Easy to understand: DFDs are graphical representations that are easy
to understand and communicate, making them useful for non-technical
stakeholders and team members.
 Improves system analysis: DFDs are useful for analyzing a system’s
processes and data flow, which can help identify inefficiencies,
redundancies, and other problems that may exist in the system.
 Supports system design: DFDs can be used to design a system’s
architecture and structure, which can help ensure that the system is
designed to meet the requirements of the stakeholders.
 Enables testing and verification: DFDs can be used to identify the
inputs and outputs of a system, which can help in the testing and
verification of the system’s functionality.
 Facilitates documentation: DFDs provide a visual representation of a
system, making it easier to document and maintain the system over time.

Disadvantages of using DFDs
 Can be time-consuming: Creating DFDs can be a time-consuming
process, especially for complex systems.
 Limited focus: DFDs focus primarily on the flow of data in a
system, and may not capture other important aspects of the system,
such as user interface design, system security, or system
performance.
 Can be difficult to keep up-to-date: DFDs may become out-of-
date over time as the system evolves and changes.
 Requires technical expertise: While DFDs are easy to
understand, creating them requires a certain level of technical
expertise and familiarity with the system being analyzed.

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;
 Many CASE workbenches support data
dictionaries.

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
 Widely used in database design. Can readily be
implemented using relational databases.
 No specific notation provided in the UML but objects
and associations can be used.

Entity-Relationship Diagrams
 ER-modeling is a data modeling method
used in software engineering to produce a
conceptual data model of an information
system.
 Diagrams created using this ER-modeling
method are called Entity-Relationship
Diagrams or ER diagrams or ERDs.

Purpose of ERD
 The database analyst gains a better
understanding of the data to be contained in
the database through the step of constructing
the ERD.
 The ERD serves as a documentation tool.
 Finally, the ERD is used to connect the
logical structure of the database to users. In
particular, the ERD effectively communicates
the logic of the database to users.

Components of an ER Diagrams
 Entity
 Attributes
 Relationships

Entity
 An entity can be a real-world object, that can be
identifiable.
 An entity is denoted as a rectangle in an ER
diagram.
 All these entities have some attributes or
properties that give them their identity.
 For example, a Student set may contain all the
students of a school; likewise, a Teacher set may
include all the teachers of a school from all
faculties.

Entity Set
 An entity set is a collection of related types of
entities.
 An entity set may include entities with
attributes sharing similar values.
 Entity set need not be disjoint.

Attributes
 Entities are denoted utilizing their properties,
known as attributes.
 All attributes have values.
 For example, a student entity may have
name, class, and age as attributes.

Types of Attributes
 Key attribute: Key is an attribute or collection
of attributes that uniquely identifies an entity
among the entity set. Eg, Roll num
 Composite attribute: An attribute that is a
combination of other attributes is called a
composite attribute. Eg Address
 Single-valued attribute, eg id
 Multi-valued attribute eg Phone num
 Derived attribute, eg Age

Relationships
 The association among entities is known as
relationship.
 Relationships are represented by the
diamond-shaped box.
 For example, an employee works_at a
department, a student enrolls in a course.

Degree of a Relationship Set
 The number of participating entities in a
relationship describes the degree of the
relation
 Unary (degree1)
 Binary (degree2)
 Ternary (degree3)

Cardinality
 Cardinality describes the number of entities
in one entity set, which can be associated
with the number of entities of other sets via
relationship set.

Types of Cardinalities
 One to One:
 One to many:

Types of Cardinalities Contd…
 Many to One:
 Many to Many:

Key points
 A model is an abstract system view. Complementary
types of model provide different system information.
 Context models show the position of a system in its
environment with other systems and processes.
 Data flow models may be used to model the data
processing in a system.
 State machine models model system’s behaviour in
response to internal or external events

Key points
 Semantic data models describe the logical
structure of data which is imported to or
exported by the systems.
 Object models describe logical system
entities, their classification and aggregation.
 Sequence models show the interactions
between actors and the system objects that
they use.
 Structured methods provide a framework for
developing system models.

2.2. Software cycle Models-System_Models.ppt

More Related Content

Similar to 2.2. Software cycle Models-System_Models.ppt (20)

Recently uploaded (20)

2.2. Software cycle Models-System_Models.ppt