Software System Modelling
Transcript of Software System Modelling
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 1/46
Software system modelling
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 2/46
Requirements Analysis
• Requirement analysis• Specifies sw’s operational characteristics
• Indicates sw’s interface with the other system elements
• Establishes constraints that sw must meet
• Requirements analysis allow the sw engineer (calledanalyst or modeler in his role) to
• Elaborate on basic requirements established during earlier
requirement engineering tasks
• Build models that depict user scenarios, functional activities,
problem classes and their relationships, system and class behavior,
and the flow of data as it is transformed.
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 3/46
System Modelling• Used in two development phases
• Analysis (what)
– High level of abstraction
• Design (what and how)
– In more detail terms
– low level of abstraction
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 4/46
System Modeling Methods
• Process Oriented methods (process-driven
systems):
• Flowcharts
• Data Flow Diagrams (DFD)
• Data oriented methods( data- driven system)
• Entity relationship diagram(ERD)
• Data Dictionary (DD)
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 5/46
System models weaknesses
• They do not model non-functional system
requirements
• They do not usually include information aboutwhether 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
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 6/46
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
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 7/46
Context models
• Context models are used to illustrate the
boundaries of a system
• Social and organisational concerns may
affect the decision on where to position
system boundaries
• Architectural models show the a systemand its relationship with other systems
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 8/46
The context of an ATM system
Auto-teller
system
Security
system
Maintenance
system
Account
da tabase
Usage
database
Branch
accounting
system
Branch
counter
system
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 9/46
ATM stakeholders
• Bank customers
• Representatives of other banks
• Bank managers
• Counter staff
• Database administrators
• Security managers
• Marketing department
• Hardware and software maintenance engineers
• Banking regulators
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 10/46
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
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 11/46
Equipment procurement process
Get costestimates
Acceptdelivery of equipment
Check delivered
items
Validatespecification
Specifyequipmentrequired
Choosesupplier
Placeequipment
order
Installequipment
Findsuppliers
Supplier database
Acceptdelivered
equipment
Equipmentdatabase
Equipment
spec.Checked
spec.
Deliverynote
Deliverynote
Order
notification
Installation
instructions
Installationacceptance
Equipmentdetails
Checked andsigned order form
Order details +
Blank order form
Spec. +supplier +estimate
Supplier listEquipmentspec.
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 12/46
Behavioural models
• Behavioural models are used to describe the
overall behaviour of a system
• 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
• Both of these models are required for a
description of the system’s behaviour
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 13/46
Data-processing models
• Data flow diagrams are used to model the
system’s data processing
• These show the processing steps as data flowsthrough a system
• IMPORTANT part of many analysis methods
• Simple and intuitive notation that customers
can understand
• Show end-to-end processing of data
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 14/46
DFD
• A traditional way of system requirement structuring• DFD is a picture of the movement of data between external
entities and the processes and data stores within a system
• In particular, analysing and designing e IPOSC
requirements of a system• Input
• Processing
• Output
• Storage
• Control
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 15/46
Data flow diagrams
• DFDs model the system from a functional perspective
• Tracking and documenting how the data
associated with a process is helpful todevelop an overall understanding of the
system
• Data flow diagrams may also be used inshowing the data exchange between a
system and other systems in its environment
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 16/46
Order processing DFD
Completeorder form
Order details + blank
order form
Validateorder
Recordorder
Send tosupplier
Adjustavailable budget
Budgetfile
Ordersfile
Completedorder form
Signedorder form
Signedorder form
Checked andsigned order
+ order notification
Order amount
+ accountdetails
Signedorder form
Order details
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 17/46
Slide 17
DFD Shapes from Visio
From Flow Chart /Data Flow Diagram
Process
Data Store
External Entity
From Software Diagram /Gane-Sarson DFD
Process
ID #
ID#
ExternalEntity
Data Store1
External
Entity
Data Store
Process
From Flow Chart /
Data Flow Diagram
Visio 5.x Visio 2000
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 18/46
Insulin pump DFD
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 19/46
Context Diagram
• Highest level view of the system
• Contains ONLY one process which
represents the ENTIRE system
• Also contains external data soures/sinks
• Plus data flows between external entities
and processes
• It contains NO data storage
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 20/46
DFD Guidelines
• Always begin with a context level diagram (also called level 0)
• Always show external entities at level 0
• Always label data flow arrows
• Do not represent procedural logic
• DFD evolves through a number of levels in
detail
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 21/46
Rules for Using DFD Symbols
• Data Flow That Connects
YES NOA 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
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 22/46
Slide 22
Relationship Among DFD levels
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 23/46
Decomposition Diagram
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 24/46
Example of DFD
Precision Tools sells a line of high-qualitywoodworking tools. When customers place orders on
the company’s Web site, the system checks to see if
the items are in stock, issues a status message to the
customer, and generates a shipping order to the
warehouse, which fills the order. When the order is
shipped, the customer is billed. The system also
produces various reports.• Draw a context diagram for the order system
• Draw DFD diagram 0 and 1 for the order system
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 25/46
ACCOUNTING
WAREHOUSECUSTOMER
0
Order
System
Order
Payment
In-Stock
Request
Status
Message
Invoice Shipping Confirmation
Shipping
Order
InventoryReports
Context Diagram of Order System
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 26/46
Lower-Level Diagrams• Functional Decomposition
– An iterative process of breaking a system descriptiondown into finer and finer detail
– Uses a series of increasingly detailed DFDs to describe
an IS
• Balancing
– The conservation of inputs and outputs to a data flowprocess when that process is decomposed to a lower
level – Ensures that the input and output data flows of the
parent DFD are maintained on the child DFD
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 27/46
0
Order
System
SALES
REP
CUSTOMER WAREHOUSE
BANK ACCOUNTING
Order
Order
Reject
Notice
Picking
List
CompletedOrder
Payment Invoice
Commission BankDeposit
CashReceipts
Entry
Level-0 DFD of
Order System
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 28/46
1.0
FillOrder
2.0
Create
Invoice
3.0
Apply
Payment
SALES
REPBANK ACCOUNTING
CUSTOMER WAREHOUSE
Order
Order
Reject
Notice
Picking List
Accounts
ReceivableD1
Invoice
Invoice
Invoice
DetailPayment
Detail
Payment
Commission Bank Deposit Cash Receipts Entry
Completed
Order
Level-1 DFD of
Order System
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 29/46
Entity Relationship Diagram (ERD)
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 30/46
DFD and ERD
DFD ERD
Process/
Relationship
Data store/
Attribute
External Entity/
Entity
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 31/46
Data Dictionary
• It is the repository of various data flowsdefined in DFD. The DD states precisely
the structure of each data flow in DFD. DD
stores details description of all elements thatcompose the DFD such as data flows, data
stores, processes.
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 32/46
Why DD is important
• To manage details in large system
• To communicate common meaning for all
system elements
• To document features of the system
• To analyse the system characteristics
• To locate errors and omissions in the system
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 33/46
Data dictionary entries
Name Description Type Date
has-labels1:N relation between entities of type Node or Link and entities of type Label. Relation 5.10.1998
LabelHolds structured or unstructured informationabout nodes or links. Labels are represented byan icon (which can be a transparent box) andassociated text.
Entity 8.12.1998
Link A 1:1 relation between design entitiesrepresented as nodes. Links are typed and maybe named.
Relation 8.12.1998
name (label)Each label has a name which identifies the typeof label. The name must be unique within theset of label types used in a design.
Attribute 8.12.1998
name (node)Each node has a name which must be uniquewithin a design. The name may be up to 64
characters long.
Attribute 15.11.1998
Data dictionaries are lists of all of the names used in thesystem models.
Descriptions of the entities, relationships and attributes arealso included
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 34/46
State machine models
• State Machine models the behaviour of thesystem in response to external and internalevents
• They show the system’s responses to stimuli soare 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 fromone state to another
• Statecharts are an integral part of the UML
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 35/46
Microwave oven modelFull power
Enabled
do: operateoven
Full
power
Half power
Half power
Full power
Number
Timer Door open
Door closed
Door closed
Door
open
Start
do: set power = 600
Half power
do: set power = 300
Set time
do: get number exit: set time
Disabled
Operation
Timer
Cancel
Waiting
do: displaytime
Waiting
do: display
time
do: display'Ready'
do: display'Waiting'
State machine model doesnot show flow of data
within the system
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 36/46
Microwave oven stimuli
Stimulus DescriptionHalf power The user has pressed the half power buttonFull power The user has pressed the full power button
Timer The user has pressed one of the timer buttonsNumber The user has pressed a numeric keyDoor open The oven door switch is not closedDoor closed The oven door switch is closedStart The user has pressed the start buttonCancel The user has pressed the cancel button
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 37/46
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 s et 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 timer countdown. On
completion of cooking, the buzzer is sounded for 5 s econds. Oven light is on. Display
shows ÔCooking completeÕ while buzzer is sounding.
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 38/46
Statecharts
• Allow the decomposition of a model into sub-models (see a figure)• 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
Cook
do: rungenerator
Done
do: buzzer on
for 5 secs.
Waiting
Alarm
do: displayevent
do: check status
Checking
Turntablefault
Emitter fault
Disabled
OK
Timeout
TimeOperation
Door open
Cancel
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 39/46
Finite state machinesFinite State Machines (FSM), also known as
Finite State Automata (FSA)
are models of the behaviours of a system or a
complex object, with a limited number of defined conditions or modes, where mode transitionschange with circumstance.
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 40/46
Finite state machines - Definition
A model of computation consisting of – a set of states,
– a start state,
– an input alphabet , and
– a transition function that maps input symbols and current states to a next
state
• Computation begins in the start state with an input string. Itchanges to new states depending on the transition function.– states define behaviour and may produce actions
– state transitions are movement from one state to another
– rules or conditions must be met to allow a state transition
– input events are either externally or internally generated, which may possibly trigger rules and lead to state transitions
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 41/46
Variants of FSMs
• There are many variants, for instance,
– machines having actions (outputs) associated with
transitions ( Mealy machine) or states ( Moore
machine),
– multiple start states,
– transitions conditioned on no input symbol (a null) or
more than one transition for a given symbol and state
( nondeterministic finite state machine),
– one or more states designated as accepting states
( recognizer), etc.
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 42/46
Finite State Machines with Output (Mealy and
Moore Machines)
• Finite automata are like computers in that
they receive input and process the input by
changing states. The only output that wehave seen finite automata produce so far is a
yes/no at the end of processing.
• We will now look at two models of finiteautomata that produce more output than a
yes/no.
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 43/46
Moore machine• Basically a Moore machine is just
a FA with two extras.
1. It has TWO alphabets, an input and output alphabet.
2. It has an output letter associated with each state. The
machine writes the appropriate output letter as it enters each
state.
The output produced by the machine contains a 1 for each
occurrence of the substring aab found in the input string.
This machine might be
considered as a
"counting" machine.
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 44/46
Mealy machine• Mealy Machines are exactly as powerful as Moore machines
– (we can implement any Mealy machine using a Moore machine, and viceversa).
• However, Mealy machines move the output function from the
state to the transition. This turns out to be easier to deal with inpractice, making Mealy machines more practical.
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 45/46
A Mealy machine produces output on a transition
instead of on entry into a state.
Transitions are labelled i/o where – i is a character in the input alphabet and
– o is a character in the output alphabet.
• Mealy machine are complete in the sense that there is atransition for each character in the input alphabet leavingevery state.
• There are no accept states in a Mealy machine because it isnot a language recogniser, it is an output producer. Itsoutput will be the same length as its input.
The following Mealy machine takes the one's
complement of its binary input. In other words, it
flips each digit from a 0 to a 1 or from a 1 to a 0.
7/31/2019 Software System Modelling
http://slidepdf.com/reader/full/software-system-modelling 46/46
Thank You