This document discusses system modeling techniques used in software engineering. It covers context models, behavioral models, data models, object models, and CASE workbenches. Different types of models present the system from external, behavioral, and structural perspectives. Common model types include data processing, composition, architectural, and classification models. The document provides examples of context models, state machine models, data flow diagrams, and object models. It also discusses semantic data models, object behavior modeling with sequence diagrams, and components of analysis and design workbenches.
3. System modelling
System modelling helps the analystanalyst to understand
the functionality of the system and modelsmodels are usedy y
to communicatecommunicate with customerscustomers..
Different models present the system from differentDifferent models present the system from different
perspectives
•• ExternalExternal perspectiveperspective showing the system’s context or
environment;
Beha io ralBeha io ral perspecti eperspecti e sho ing the beha io r of the s stem•• BehaviouralBehavioural perspectiveperspective showing the behaviour of the system;
•• StructuralStructural perspectiveperspective showing the system or data
architecture.architecture.
4. Model types
DataData processingprocessing modelmodel showing how the datadata isis
processedprocessed at different stages.
CompositionComposition modelmodel showing how entitiesentities areare
composedcomposed of other entitiescomposedcomposed of other entities.
ArchitecturalArchitectural modelmodel showing principal sub-systems.
ClassificationClassification modelmodel showing how entitiesentities havehave
commoncommon characteristicscharacteristics.
Stimulus/responseStimulus/response model/Statemodel/State showing the
system’s reaction to eventssystem s reaction to events.
5. Context models-External perspectiveExternal perspective
Context models are used to illustrate the
operationaloperational contextcontext of a system - they show whatpp y y
lies outsideoutside thethe systemsystem boundariesboundaries.
6. The context of an ATM system
Security
system
Account
da tabase
Branch
accounting
system
Auto-teller
system
Branch
M i t
Usage
database
Branch
counter
system
Maintenance
system
7. Behavioural models
Behavioural models are used to describe the overall
behaviour of a system.
Two types of behavioural model are:
•• DataData processingprocessing modelsmodels that show how data•• DataData processingprocessing modelsmodels that show how data
is processed as it moves through the system;
•• StateState machinemachine modelsmodels that show the systems
response to events.
8. Process models
Data flow models may be used to show the
processes and the flowflow ofof informationinformation fromfrom oneonep
processprocess toto anotheranother..
9. Data-processing models
Data flow diagrams (DFDs) may be used to model
the system’s data processing.y p g
These show the processing steps as data flows
through a systemthrough a system.
DFDs are an intrinsic part of many analysis
methods.
Simple and intuitive notation that customers canp
understand.
Sh d t d i f d tShow end-to-end processing of data.
10. Equipment procurement process
Equipment
Checked
spec
Deli very
note
Deli very
note
Get cost
estima tes
Accept
deli very of
equipment
Check
delivered
items
Valida te
specification
Specify
equipment
requir ed
spec.
spec.
Or der
Installa tion
i t ti
Spec. +
supplier +
estima teEquipment
Choose
supplier
Place
equipment
order
Install
equipment
Find
suppliers
Supplier
da tabase
Or der
notifica tion
instructions
Order
details plus
estima te
Supplier list
Equipment
spec.
Accept
deli vered
Installa tion
acceptance
Ch k d d
p
blank or der
for m
equipment
Equipment
details
Check ed and
signed or der f orm
Equipment
da tabase
11. State machine models
These model the behaviour of the system inThese model the behaviour of the system in
response to external and internal events.
They show the system’s responses to stimuli (Stimuli are
events in the environment that influence behavior.)so are often used for
modelling real-time systems.
State machine models show systemsystem statesstates asState machine models show systemsystem statesstates as
nodesnodes and eventsevents as arcsarcs between these nodes.
When an e ent occ rs the s stem mo es from oneWhen an event occurs, the system moves from one
state to another.
State charts are an integral part of the UML and are
used to represent state machine models.
12. State charts
Allow the decomposition of a model into sub-models
A brief description of the actions is includedA brief description of the actions is included
following the ‘do’ in each state.
Can be complemented by tablestables describingdescribing the
states and the stimuli.
13. Microwave oven state table description
State Description
Waiting The oven is waiting for input. The display shows the current time.g g p p y
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 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 top g p y y
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.
14. Microwave oven model
Full power
Full
pow er
do: set power
= 600
do: operate
Full
power
Number
Set time
do: get number
Operation
Waiting
do: display
time
Timer
do: operate
oven
Half
power
Half
power
p
Door
Door
closed
Start
do: get number
exit: set time
CancelTimer
Enabled
Door
open
Door
closed
Door
openHalf power
do: set power
= 3 00
Waiting
do: display
time
do: display
'Ready'
Disabled
do: display
'Waiting'
15. 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 closedDoor closed The oven door switch is closed
Start The user has pressed the start button
Cancel The user has pressed the cancel button
16. Microwave oven operation
C k
Checking
Time
Operation
Cook
do: run
generator
do: check
status
g
Turntable Emitter
OK
Timeout
Done
do: buzzer on
f 5
Alarm
do: display
Turntable
fault
Emitter
fault
Timeout
for 5 secs.
do: display
event
Door open Cancel
WaitingDisabled
17. Semantic data models
Used to describe the logicallogical structurestructure ofof datadata
processedprocessed by the system.pp y y
An entity-relation-attribute model sets out the
entities in the system the relationships betweenentities in the system, the relationships between
these entities and the entity attributes
Widely used in database design. Can readily be
implemented using relational databases.
19. Data dictionaries
Data dictionaries are listslists ofof allall of the names used
in the system models. Descriptions of the entities,y p ,
relationships and attributes are also included.
AdvantagesAdvantages
• Support name management and avoid duplication;
• Store of organisational knowledge linking analysis, design
and implementation;
Many CASE workbenches support data dictionaries.
20. Data dictionary entries
Name Description Type Date
Article Details of the published article that may be ordered by
people using LIBSYS.
Entity 30.12.2002
authors The names of the authors of the article who may be due Attribute 30 12 2002authors The names of the authors of the article who may be due
a share of the fee.
Attribute 30.12.2002
Buyer The person or organisation that orders a copy of the
article.
Entity 30.12.2002
fee-payable-
to
A 1:1 relationship between Article and the Copyright
Agency who should be paid the copyright fee.
Relation 29.12.2002
Address
(Buyer)
The address of the buyer. This is used to any paper
billing information that is required.
Attribute 31.12.2002
y g q
21. Object models
“Object", refers to a particular instance of a ClassClass
Object models describe the system in terms ofObject 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 producedj y p
• Inheritance models;
• Aggregation models;• Aggregation models;
• Interaction models.
22. Object models
Natural ways of reflecting the realreal--worldworld entitiesentities
manipulated by the systemp y y
Object class identification is recognised as a difficult
process requiring a deep understanding of theprocess requiring a deep understanding of the
application domain
Object classes reflecting domain entities are
reusablereusable acrossacross systemssystems
23. Inheritance models
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 classesfrom one or more super-classes.
24. Object models and the UML
Th UML i t d d t ti d i d b thThe UML is a standard representation devised by the
developers of widely used object-oriented analysis and design
methodsmethods.
It has become an effective standard for object-oriented
modellingmodelling.
Notation
Object classes are rectanglesrectangles ith the name at the top• Object classes are rectanglesrectangles with the name at the top,
attributesattributes inin thethe middlemiddle sectionsection and operationsoperations inin thethe bottombottom
section;
• Relationships between object classes (knownknown asas associationsassociations)
are shown as lines linking objects;
• Inheritance is referred to as generalisation and is shown
‘upwards‘upwards’ rather than ‘downwards’downwards’ in a hierarchy.
27. Multiple inheritance
Rather than inheriting the attributes and services
from a single parent class, a system which supportsg p , y pp
multiple inheritance allows object classes to inherit
fromfrom severalseveral supersuper--classesclassesfromfrom severalseveral supersuper--classesclasses..
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
reorganisation more complex.reorganisation more complex.
31. Structured methods
Methods define a set of models, a process for
deriving these models and rules and guidelines thatg g
should apply to the models.
CASE tools support system modelling as part of aCASE tools support system modelling as part of a
structured method.
32. Method weaknesses
They do not model non-functional system
requirements.q
They do not usually include information about
whether a method is appropriate for a givenwhether a method is appropriate for a given
problem.
The may produce too much documentation.
The system models are sometimes too detailed andy
difficult for users to understand.
33. CASE workbenches
A coherent set of tools that is designed to support
related software process activities such as analysis,p y ,
design or testing.
Analysis and design workbenches support systemAnalysis and design workbenches support system
modelling during both requirements engineering and
system design.
These workbenches may support a specific design
method or may provide support for a creating
several different types of system modelseveral different types of system model.
35. Analysis workbench components
Diagram editors
Model analysis and checking toolsModel analysis and checking tools
Repository and associated query language
Data dictionary
Report definition and generation toolsp g
Forms definition tools
I t/ t t l tImport/export translators
Code generation tools
38. Software project management
Concerned with activitiesactivities involved in ensuring
that software is delivered onon timetime and onon
scheduleschedule and in accordance with the
requirements of the organisations developingrequirements of the organisations developing
and procuring the software.
Project management is needed because software
development is always subject to budget and
schedule constraints that are set by the
organisation developing the software.g p g
39. Software Project Management activities
Proposal writing.
Project planning and schedulingProject planning and scheduling.
Project costing.
Project monitoring and reviews.
Personnel selection and evaluation.
Report writing and presentations.
40. Project staffing
May not be possible to appoint the ideal people to work
on a project
• Project budget may not allow for the use of highly-paid
staff;;
• Staff with the appropriate experience may not be
available;available;
• An organisation may wish to develop employee skills
on a software projecton a software project.
Managers have to work within these constraints
i ll h th h t f t i d t ffespecially when there are shortages of trained staff.
41. Project planning
Probably the most time-consuming project
management activity.g y
Continuous activity from initial concept through
to system delivery Plans must be regularly revisedto system delivery. Plans must be regularly revised
as new information becomes available.
Various different types of plan may be developed to
support the main software project plan that is
concerned with schedule and budget.
42. Types of project plan
Plan Description
Quality plan Describes the quality procedures and standards that will
b d i jbe used in a project. .
Validation plan Describes the approach, resources and schedule used for
system validation.
Configuration
management plan
Describes the configuration management procedures and
structures to be used.
Maintenance plan Predicts the maintenance requirements of the system,
maintenance costs and effort required.
Staff development Describes how the skills and experience of the projectp
plan.
p p j
team members will be developed.
43. Project planning process
E t bli h th j t t i tEstablish the project constraints
Make initial assessments of the project parameters
Define project milestones and deliverables
while project has not been completed or cancelled loop
Draw up project schedule
Initiate activities according to scheduleg
Wait ( for a while )
Review project progress
Revise estimates of project parametersRevise estimates of project parameters
Update the project schedule
Re-negotiate project constraints and deliverables
if ( problems arise ) then
Initiate technical review and possible revision
end if
end loop
44. The project plan
The project plan sets out:
• The resources available to the project;The resources available to the project;
• The work breakdown;
• A schedule for the work.
45. Project plan structure
Introduction.
Project organisationProject organisation.
Risk analysis.
Hardware and software resource requirements.
Work breakdown.
Project schedule.
M it i d ti h iMonitoring and reporting mechanisms.
46. Activity organization
Activities in a project should be organised to
produce tangible outputs for management to judgep g p g j g
progress.
Milestones are the end point of a process activityMilestones are the end-point of a process activity.
Deliverables are project results delivered to
customers.
The waterfall process allows for the straightforwardp g
definition of progress milestones.
47. Project scheduling
Split project into tasks and estimate time and
resources required to complete each task.q p
Organize tasks concurrently to make optimal
use of workforceuse of workforce.
Minimize task dependencies to avoid delays
caused by one task waiting for another to complete.
Dependent on project managers intuition andp p j g
experience.
49. Scheduling problems
Estimating the difficulty of problems and hence the
cost of developing a solution is hard.p g
Productivity is not proportional to the number of
people working on a taskpeople working on a task.
Adding people to a late project makes it later
because of communication overheads.
The unexpected always happens. Always allowp y pp y
contingency in planning.
50. Bar charts and activity networks
Graphical notations used to illustrate the project
schedule.
Show project breakdown into tasks. Tasks should
not be too small They should take about a week ornot be too small. They should take about a week or
two.
Activity charts show task dependencies and the the
critical path.
Bar charts show schedule against calendar time.
55. Risk management
Risk management is concerned with identifying risks and
drawing up plans to minimise their effect on a project.
A risk is a probability that some adverse circumstance will
occur
• Project risks affect schedule or resources;
• Product risks affect the quality or performance of the
software being developed;
• Business risks affect the organisation developing or
procuring the software.
56. Software risks
Risk Affects Description
Staff turnover Project Experienced staff will leave the project before it is finished.
Management change Project There will be a change of organisational management with
different priorities.
Hardware unavailability Project Hardware that is essential for the project will not be
delivered on schedule.
Requirements change Project and
product
There will be a larger number of changes to the
requirements than anticipated.
Specification delays Project and
product
Specifications of essential interfaces are not available on
schedule
Size underestimate Project and
product
The size of the system has been underestimated.
CASE tool under-
performance
Product CASE tools which support the project do not perform as
anticipated
Technology change Business The underlying technology on which the system is built is
superseded by new technology.
Product competition Business A competitive product is marketed before the system is
completed.
58. The risk management process
Risk identification
• Identify project, product and business risks;
Risk analysis
• Assess the likelihood and consequences of these risks;
Risk planning
• Draw up plans to avoid or minimise the effects of the risk;p p ;
Risk monitoring
• Monitor the risks throughout the project;Monitor the risks throughout the project;
60. Risks and risk types
Risk type Possible risks
Technology The database used in the system cannot process as many transactions per second
as expected.as expected.
Software components that should be reused contain defects that limit their
functionality.
People It is impossible to recruit staff with the skills required.
Key staff are ill and unavailable at critical times.
i d i i f ff i il blRequired training for staff is not available.
Organisational The organisation is restructured so that different management are responsible for
the project.
Organisational financial problems force reductions in the project budget.
Tools The code generated by CASE tools is inefficient.
CASE tools cannot be integrated.
Requirements Changes to requirements that require major design rework are proposed.
Customers fail to understand the impact of requirements changes.
Estimation The time required to develop the software is underestimated.
The rate of defect repair is underestimated.
The size of the software is underestimated.
61. Risk analysis
Assess probability and seriousness of each risk.
Probability may be very low low moderate high orProbability may be very low, low, moderate, high or
very high.
Risk effects might be catastrophic, serious, tolerable
or insignificant.
62. Risk analysis (i)
Risk Probability Effects
Organisational financial problems force reductions in Low CatastrophicOrganisational financial problems force reductions in
the project budget.
Low Catastrophic
It is impossible to recruit staff with the skills required
for the project.
High Catastrophic
Key staff are ill at critical times in the project. Moderate Serious
Software components that should be reused contain
defects which limit their functionality.
Moderate Serious
Changes to requirements that require major design
rework are proposed.
Moderate Serious
The organisation is restructured so that different
ibl f h j
High Serious
management are responsible for the project.
63. Risk analysis (ii)
Risk Probability Effects
The database used in the system cannot process as Moderate Serious
many transactions per second as expec ted.
The time required to develop the software is
underestimated.
High Serious
CASE tools cannot be integrated High TolerableCASE tools cannot be integrated. High Tolerable
Customers fail to understand the impact of
requirements changes.
Moderate Tolerable
Required training for staff is not available. Moderate Tolerableq g
The rate of defect repair is underestimated. Moderate Tolerable
The size of the software is underestimated. High Tolerable
The code generated by CASE tools is inefficient. Moderate Insignificantg y g
64. Risk planning
Consider each risk and develop a strategy to manage that risk.
Avoidance strategies
• The probability that the risk will arise is reduced;
Minimisation strategies
• The impact of the risk on the project or product will be
reduced;
Contingency plans
• If the risk arises, contingency plans are plans to deal with, g y p p
that risk;
65. Risk management strategies (i)
Risk Strategy
Organisational
financial problems
Prepare a briefing document for senior management
showing how th e project is making a very important
contribution to the goals of the business.
Recruitment
problems
Alert customer of potential difficulties and the
possibility of delays, investigate buying-in
components.
Staff illness Reorganise team so that there is more overlap of work
and people therefore understand each other’s jobs.
Defective Replace potentially defective components with bought-Defective
components
Replace potentially defective components with bought-
in components of known reliability.
66. Risk management strategies (ii)
Risk Strategy
Requirements
changes
Derive traceability information to assess requirements
change impact, maximise information hiding in the
design.
O i ti l P b i fi d t f i tOrganisational
restructuring
Prepare a briefing document for senior management
showing how th e project is making a very important
contribution to the goals of the business.
Database Investigate the possibility of buying a higherDatabase
performance
Investigate the possibility of buying a higher-
performance database.
Underestimated
development time
Investigate buying in components, investigate use of a
program generatordevelopment time program generator
67. Risk monitoring
Assess each identified risks regularly to decide
whether or not it is becoming less or more probable.g p
Also assess whether the effects of the risk have
changedchanged.
Each key risk should be discussed at management
progress meetings.
68. Risk indicators
Risk type Potential indicators
T h l L d li f h d f dTechnology Late delivery of hardware or support software, many reported
technology problems
People Poor staff morale, poor relationships amongst team member,
job availabilityjob availability
Organisational Organisational gossip, lack of action by senior management
Tools Reluctance by team members to use tools, complaints about
CASE tools demands for higher powered workstationsCASE tools, demands for higher-powered workstations
Requirements Many requirements change requests, customer complaints
Estimation Failure to meet agreed schedule, failure to clear reported
d f tdefects
69. Chapter Review Questions
1.Explain different types of system model in details.
2.Define Context model. Draw a context model for library system.
3.Explain semantic data model with suitable example.
4.Describe the state machine model with example.
5 W it h t t5. Write short note on
a. Ethnography b.Use case c.Sequence diagram d.CASE workbench
e. Risk planning f. Data dictionaryp g y
6. Describe the software project management activities in details.
7. Explain the importance of planning and scheduling in software project
management.
8. Discuss the importance of risk management in software project. Explain
various risk management strategiesvarious risk management strategies.
