Review of known methodologies

The mother of Qualities: Simplicity

• We recognize simplicity
• In clear and easy to understand speaking and writing
• In uncluttered (neat and organized) forms
• In a good teacher’s explanation
• In a leader’s setting of goals and strategies

• As we quickly grasp simple statements and forms,

we can easily use them as building blocks for our
thoughts and activities in work and play.
 Simplicity in Software
• The world around us is complex and the human activities increase the complexity.
• Achieving simplicity sometimes requires extra work.
• Work very hard to keep everything as simple as you can.
• Documentation written from the point of view of the writer is not nearly so
useful as document written from the point of view of the reader.
• Simpler programs are easier to use, review, document and modify with the result
of significantly reduced cost in all phases of the process
What is software?
• Computer programs and associated documentation
Software Products Categories
• Software products may be
• Generic - developed to be sold to a range of different customers
• Examples of this type of product include software for PCs such as databases, word processors,
drawing packages, and project management tools. It also includes so-called vertical applications
designed for some specific purpose such as library information systems, accounting systems, or
systems for maintaining dental records.
• Bespoke (custom) - developed for a single customer according to their
specification
• Examples of this type of software include control systems for electronic devices, systems written to
support a particular business process, and air traffic control systems.
Vertical application
• A vertical application is any software application that supports a specific business process and
targets a smaller number of users with specific skill sets and job responsibilities within an
organization.
• Enterprise Resource Planning (ERP) systems, such as the SAP system, are the best examples
of this approach. SAP is adapted for a company by incorporating information about their
business rules and processes, reports required, and so on.
Software Engineering (In general)

Software engineering is an engineering disciplinea which is

concerned with all aspects of software productionb
• Not only technical processes of software development, but
also
• Software project management
• Development of tools, methods and theories to support software production
a. Engineering Discipline
• Engineer make things work.
• Apply theories, methods and tools where appropriate
• Discover solutions to problems even in the absence of applicable
theories and methods
• Work and look for solutions within organizational and financial
constraints
Software Engineering Definitions
• Classic Definition (1969)
• “The establishment and use of sound engineering principles in
order to obtain economically software that is reliable and works
efficiently on real machines”
• IEEE Definition (1993)
• “Software engineering (1) The application of a systematic,
disciplines, quantifiable approach to the development, operation
and maintenance of software; that is the application of
engineering to software. (2) The study of approaches as in
(1).”
Difference between software engineering and computer
science
• Computer science is concerned with theory and fundamentals;
software engineering is concerned with the practicalities of
developing and delivering useful software.
• Computer science theories are currently insufficient to act as a
complete underpinning (foundation) for software engineering.
• Software engineers must often use ad hoc approaches to develop the
software. (Research is in progress and will remain in progress!)
What is a software process?
• A set of activities whose goal is the development or evolution of
software
• Mostly carried out by software Engineers
• Generic activities in all software processes are:
• Specification - what the system should do and its development
constraints
• Development (Design & Implementation) - production of the
software system
• Validation - checking that the software is what the customer
wants
• Evolution - changing the software in response to changing
demands
What are software engineering methods?
• A structured approach to software development whose aim is to
facilitate the production of high-quality software in a cost-effective
way.
• Methods such as Structured Analysis were first developed in the
1970s. These methods attempted to identify the basic functional
components of a system; function-oriented methods are still used.
• In the 1980s and 1990s, these function-oriented methods were
supplemented by object-oriented (OO) methods.
• These different approaches have now been integrated into a single
unified approach built around the Unified Modeling Language (UML).
What is CASE (Computer-Aided Software Engineering)

• Software systems which are intended to provide automated support

for software process activities. CASE systems are often used for
method support
• Upper-CASE
• Tools to support the early process activities of requirements and design
• Lower-CASE
• Tools to support later activities such as programming, debugging and testing
Attributes of good software
• The software should deliver the required functionality and
performance to the user and should be maintainable, dependable and
usable
• Maintainability
• Software must evolve to meet changing needs
• Dependability
• Software must be trustworthy
• Efficiency
• Software should not make wasteful use of system resources
• Usability
• Software must be usable by the users for which it was designed
Key challenges facing Software Engineering
• Coping with legacy systems, coping with increasing diversity and
coping with demands for reduced delivery times
• Legacy systems
• Old, valuable systems must be maintained and updated
• Heterogeneity
• Systems are distributed and include a mix of hardware and
software
• Delivery
• There is increasing pressure for faster delivery of software
1. The software process
• A structured (planned and organized) set of activities required to
develop or evolve(change) a software system.
• A software process model is an abstract representation of a process. It
presents a description of a process from some particular perspective
e.g. waterfall model
• Two major types of software processes:
• Plan-driven process and
• Agile process

Chapter 2 Software Processes 16

Plan-driven and agile processes
Plan-driven processes are processes where all of the process
activities are planned in advance and progress is measured against
this plan.
In agile processes, planning is incremental and it is easier to change
the process to reflect changing customer requirements.
In practice, most practical processes include elements of both plan-
driven and agile approaches.
There are no right or wrong software processes.

Chapter 2 Software Processes 17

2. Process activities
Real software processes are interleaved(mixed) sequences of
technical, collaborative and managerial activities with the overall
goal of specifying, designing, implementing and testing a software
system.
The four basic process activities of specification, development,
validation and evolution are organized differently in different
development processes. In the waterfall model, they are organized in
sequence, whereas in incremental development they are
interleaved.

Chapter 2 Software Processes 18

Generic Software process models
A. The waterfall model
• Plan-driven model. Separate and distinct phases of specification and
development.
B. Incremental development
• Specification, development and validation are interleaved. May be plan-driven
or agile.
C. Reuse-oriented software engineering
• The system is assembled from existing components. May be plan-driven or agile.
In practice, most large systems are developed using a process that
incorporates elements from all of these models.

Chapter 2 Software Processes 19

3A. The waterfall model

Chapter 2 Software Processes 20

Waterfall model problems
• This model is only appropriate when the requirements
are well-understood and changes will be fairly limited
during the design process.
• Few business systems have stable requirements.
• The waterfall model is mostly used for large systems
engineering projects where a system is developed at
several sites.
• In those circumstances, the plan-driven nature of the waterfall
model helps coordinate the work.

Chapter 2 Software Processes 21

3B. Incremental development

Chapter 2 Software Processes 22

Incremental development benefits
The cost of accommodating changing customer requirements is reduced. (as
users are almost involve in all phases)
◦ The amount of analysis and documentation that has to be redone is much less than is
required with the waterfall model.
It is easier to get customer feedback on the development work that has been
done.
◦ Customers can comment on demonstrations of the software and see how much has
been implemented.
More rapid delivery and deployment of useful software to the customer is
possible.
◦ Customers are able to use and gain value from the software earlier than is possible
with a waterfall process.
Chapter 2 Software Processes 23
Incremental development problems
The process is not visible.
◦ Managers need regular deliverables to measure progress. If systems are
developed quickly, it is not cost-effective to produce documents that reflect
every version of the system.
System structure tends to degrade as new increments are added.
◦ Unless time and money is spent on refactoring to improve the software,
regular change tends to corrupt its structure. Incorporating further software
changes becomes increasingly difficult and costly.

Chapter 2 Software Processes 24

Reuse-oriented software engineering
• Reuse-oriented software engineering has the obvious
advantage of reducing the amount of software to be
developed and so reducing cost and risks. It usually also
leads to faster delivery of the software.
• However, requirements compromises are inevitable and this
may lead to a system that does not meet the real needs of
users.
• Furthermore, some control over the system evolution is lost
as new versions of the reusable components are not under
the control of the organization using them.

Chapter 2 Software Processes 25

Rework
• Change adds to the costs of software development
because it usually means that work that has been
completed has to be redone. This is called rework.
• It may then be necessary to
• redesign the system to deliver the new requirements,
• change any programs that have been developed, and
• re-test the system.

Chapter 2 Software Processes 26

Reducing the costs of rework
Change avoidance, where the software process includes activities
that can anticipate (do in advance) possible changes before
significant rework is required.
◦ For example, a prototype system may be developed to show some key
features of the system to customers.
Change tolerance, where the process is designed so that changes
can be accommodated at relatively low cost.
◦ This normally involves some form of incremental development. Proposed
changes may be implemented in increments that have not yet been
developed. If this is impossible, then only a single increment (a small part of
the system) may have be altered to incorporate the change.

Chapter 2 Software Processes 27

 4A. Software prototyping
• A prototype is an initial version of a system used to demonstrate
concepts and try out design options.
• A prototype can be used in:
• The requirements engineering process to help with requirements elicitation
and validation;
• In design processes to explore options and develop a UI design;

Chapter 2 Software Processes 28

Incremental development and delivery
Incremental development
◦ Develop the system in increments and evaluate each increment before
proceeding to the development of the next increment;
◦ Normal approach used in agile methods;
◦ Evaluation done by user/customer proxy.
Incremental delivery
◦ Deploy an increment for use by end-users;
◦ More realistic evaluation about practical use of software;
◦ Difficult to implement for replacement systems (replacing an old system) as
increments have less functionality than the system being replaced.

Chapter 2 Software Processes 29

Incremental delivery

Chapter 2 Software Processes 30

Incremental delivery advantages
• Customer value can be delivered with each increment so
system functionality is available earlier.
• Early increments act as a prototype to help elicit requirements
for later increments.
• Lower risk of overall project failure.
• The highest priority system services tend to receive the most
testing.

Chapter 2 Software Processes 31

Incremental delivery problems
Most systems require a set of basic facilities that are used by
different parts of the system.
The essence of iterative processes is that the specification is
developed in conjunction with the software.
◦ However, this conflicts with the procurement (locating) model of many
organizations (e.g. government), where the complete system
specification is part of the system development contract.

Chapter 2 Software Processes 32

Risk
• Risk simply means something that can go wrong.
• For example, if the intention is to use a new programming language, a risk is
that the available compilers are unreliable or do not produce sufficiently
efficient object code.
• Risks lead to proposed software changes and project problems such
as schedule and cost overrun, so risk minimization is a very important
project management activity.

Chapter 2 Software Processes 33

5. The Rational Unified Process
A modern hybrid generic process model derived from the
work on the UML and associated process.
Hybrid because it brings together aspects of the 3 generic
process models discussed previously.
Phases in the RUP are more closely related to business rather
than technical concerns.
Normally described from 3 perspectives
◦ A dynamic perspective that shows phases over time;
◦ A static perspective that shows process activities;
◦ A practice perspective that suggests good practice.

Chapter 2 Software Processes 34

RUP phases (dynamic)
Inception
◦ Establish the business case for the system.
Elaboration
◦ The goals of the elaboration phase are to develop an understanding of the
problem domain, establish an architectural framework for the system,
develop the project plan, and identify key project risks. On completion of
this phase you should have a requirements model for the system, which may
be a set of UML use-cases, an architectural description, and a development
plan for the software.
Construction
◦ System design, programming and testing.
Transition
◦ Deploy the system in its operating environment.

Chapter 2 Software Processes 35

Requirements
• The requirements are the descriptions of the system
services and constraints that are generated during the
requirements engineering process.
• It may range from a high-level abstract statement of a
service or of a system constraint to a detailed
mathematical functional specification.

Chapter 4 Requirements engineering 36

Requirements engineering
• The process of establishing:
• the services that the customer requires from a system and
• the constraints under which it operates and is developed.

• The outcome is a requirements document, which may be

part of the system development contract.

Chapter 4 Requirements engineering 37

 Functional and non-functional
requirements
Functional requirements
Statements of services the system should provide, how the system should react to
particular inputs and how the system should behave in particular situations.
May state what the system should not do.
Non-functional requirements
Constraints on the services or functions offered by the system such as timing
constraints, constraints on the development process, standards, etc.
Often apply to the system as a whole rather than individual features or services.
Domain requirements
Constraints on the system from the application domain (e.g. medical domain)

Chapter 4 Requirements engineering 38

 Introduction: Software Architecture
A model of the fundamental structure and organization of a software system.
Design begins with a high-level architecture.
The design process for identifying the sub-systems making up a system and the framework
for sub-system control and communication is architectural design.
The output of this design process is a description of the software architecture.
So, it is an early stage of the system design process.
Represents the link between specification and design processes.
Often carried out in parallel with some specification activities.

Chapter 6 Architectural design 39

Architectural abstraction
Architecture in the small is concerned with the architecture of individual programs. At this
level, we are concerned with the way that an individual program is decomposed into
components.
Architecture in the large is concerned with the architecture of complex enterprise systems
that include other systems, programs, and program components. These enterprise
systems are distributed over different computers, which may be owned and managed by
different companies.

Chapter 6 Architectural design 40

MHC-PMS
• Used as a case study in several chapters.
• The MHC-PMS (Mental Health Care-Patient Management
System) is an information system that is intended for use
in clinics.
• A patient information system to support mental health
care is a medical information system that maintains
information about patients suffering from mental health
problems and the treatments that they have received.

Chapter 4 Requirements engineering 41

MHC-PMS: A case study

Chapter 4 Requirements engineering 42

MHC-PMS: Goals
• The MHC-PMS has two overall goals:
1. To generate management information that allows health
service managers to assess performance against local and
government targets.
2. To provide medical staff with timely information to support
the treatment of patients.

Chapter 4 Requirements engineering 43

Types of requirement
User requirements
 Statements in natural language plus diagrams of the services the
system provides and its operational constraints. Written for
customers.
System requirements
 A structured document setting out detailed descriptions of the
system’s functions, services and operational constraints. Defines
what should be implemented so may be part of a contract
between client and contractor.

Chapter 4 Requirements engineering 44

User and system requirements: example

Chapter 4 Requirements engineering 45

1. Functional and non-functional
requirements
Functional requirements
Statements of services the system should provide, how the system should
react to particular inputs and how the system should behave in particular
situations.
May state what the system should not do.
Non-functional requirements
Constraints on the services or functions offered by the system such as
timing constraints, constraints on the development process, standards, etc.
Often apply to the system as a whole rather than individual features or
services.
Domain requirements
Constraints on the system from the application domain (e.g. medical
domain)

Chapter 4 Requirements engineering 46

Functional requirements for the MHC-
PMS
A user shall be able to search the appointments lists for all
clinics.
The system shall generate each day, for each clinic, a list of
patients who are expected to attend appointments that
day.
Each staff member using the system shall be uniquely
identified by his or her 8-digit employee number.

Chapter 4 Requirements engineering 47

Non-functional requirements
implementation
Non-functional requirements may affect the overall architecture of a
system rather than the individual components.
 For example, to ensure that performance requirements are met,
you may have to organize the system to minimize communications
between components.
A single non-functional requirement, such as a security requirement,
may generate a number of related functional requirements that
define system services that are required.
Non-functional requirements may be more critical than functional
requirements. If these are not met, the system may be useless.

Chapter 4 Requirements engineering 48

Types of nonfunctional requirement

Chapter 4 Requirements engineering 49

Non-functional classifications
Product requirements
 Requirements which specify that the delivered product must behave in a
particular way e.g. execution speed, reliability, etc.
Organisational requirements
 Requirements which are a consequence of organisational policies and
procedures. Development requirements that specify the programming
language, the development environment or process standards to be used, and
environmental requirements that specify the operating environment of the
system.
External requirements
 Requirements which arise from factors which are external to the system and
its development process e.g. interoperability requirements, legislative
requirements, etc.

Chapter 4 Requirements engineering 50

Examples of nonfunctional requirements
in the MHC-PMS
Product requirement
The MHC-PMS shall be available to all clinics during normal working hours
(Mon–Fri, 0830–17.30). Downtime within normal working hours shall not
exceed five seconds in any one day.
Organizational requirement
Users of the MHC-PMS system shall authenticate themselves using their
health authority identity card.
External requirement
The system shall implement patient privacy provisions as set out in HStan-
03-2006-priv.

Chapter 4 Requirements engineering 51

Goals and requirements
• Non-functional requirements may be very difficult to state
precisely and imprecise requirements may be difficult to verify.
• Goal
• A general intention of the user such as ease of use.
• Verifiable non-functional requirement
• A statement using some measure that can be objectively tested.

Chapter 4 Requirements engineering 52

 Verifiable non-functional requirement

• The system should be easy to use by medical staff and should be

organized in such a way that user errors are minimized. (Goal)
• Medical staff shall be able to use all the system functions after four
hours of training. After this training, the average number of errors
made by experienced users shall not exceed two per hour of system
use. (Testable/verifiable non-functional requirement)

Chapter 4 Requirements engineering 53

Metrics for specifying nonfunctional
requirements
Property Measure
Speed Processed transactions/second
User/event response time
Screen refresh time
Size Mbytes
Number of ROM chips
Ease of use Training time
Number of help frames
Reliability Mean time to failure
Probability of unavailability
Rate of failure occurrence
Availability
Robustness Time to restart after failure
Percentage of events causing failure
Probability of data corruption on failure
Portability Percentage of target dependent statements
Number of target systems

54
Chapter 4 Requirements engineering
Domain requirements
• The system’s operational domain imposes requirements
on the system.
• For example, a train control system has to take into account
the braking characteristics in different weather conditions.
• If domain requirements are not satisfied, the system
may be unworkable.

Chapter 4 Requirements engineering 55

Train protection system
• This is a domain requirement for a train protection system:
• The deceleration of the train shall be computed as:
• Dtrain = Dcontrol + Dgradient
• where Dgradient is 9.81ms2 * compensated gradient/alpha and where the values of
9.81ms2 /alpha are known for different types of train.
• It is difficult for a non-specialist to understand the implications of this
and how it interacts with other requirements.

Chapter 4 Requirements engineering 56

The software requirements document
The software requirements document is the official
statement of what is required of the system developers.
Should include both user requirements and system
requirements.
It is NOT a design document. As far as possible, it should
set of WHAT the system should do rather than HOW it
should do it.

Chapter 4 Requirements engineering 57

Users of a requirements document

Chapter 4 Requirements engineering 58

Requirements document variability
Information in requirements document depends on type
of system and the approach to development used.
For example, systems developed incrementally will have less
detail in the requirements document.
Requirements documents standards have been designed
e.g. IEEE standard. These are mostly applicable to the
requirements for large systems engineering projects. A
sample from a company is shown in next slides who
followed IEEE standard:

Chapter 4 Requirements engineering 59

 The structure of a requirements document

Chapter Description
Preface This should define the expected readership of the document and describe its
version history, including a rationale for the creation of a new version and a
summary of the changes made in each version.
Introduction This should describe the need for the system. It should briefly describe the
system’s functions and explain how it will work with other systems. It should also
describe how the system fits into the overall business or strategic objectives of
the organization commissioning the software.
Glossary This should define the technical terms used in the document. You should not
make assumptions about the experience or expertise of the reader.
User requirements Here, you describe the services provided for the user. The nonfunctional system
definition requirements should also be described in this section. This description may use
natural language, diagrams, or other notations that are understandable to
customers. Product and process standards that must be followed should be
specified.

System architecture This chapter should present a high-level overview of the anticipated system
architecture, showing the distribution of functions across system modules.
Architectural components that are reused should be highlighted.

Chapter 4 Requirements engineering 60

The structure of a requirements
document
Chapter Description
System requirements This should describe the functional and nonfunctional requirements in more detail. If
specification necessary, further detail may also be added to the nonfunctional requirements.
Interfaces to other systems may be defined.
System models This might include graphical system models showing the relationships between the
system components and the system and its environment. Examples of possible models
are object models, data-flow models, or semantic data models.

System evolution This should describe the fundamental assumptions on which the system is based, and
any anticipated changes due to hardware evolution, changing user needs, and so on.
This section is useful for system designers as it may help them avoid design decisions
that would constrain likely future changes to the system.

Appendices These should provide detailed, specific information that is related to the application
being developed; for example, hardware and database descriptions. Hardware
requirements define the minimal and optimal configurations for the system. Database
requirements define the logical organization of the data used by the system and the
relationships between data.

Index Several indexes to the document may be included. As well as a normal alphabetic
index, there may be an index of diagrams, an index of functions, and so on.

Chapter 4 Requirements engineering 61

3. Requirements specification
The process of writing down the user and system
requirements in a requirements document.
Ways of writing a system requirements specification
A. Natural language
B. Structured

Chapter 4 Requirements engineering 62

A. Natural language specification
Requirements are written as natural language sentences
supplemented by diagrams and tables.
It is expressive, intuitive and universal. This means that the
requirements can be understood by users and customers.

Chapter 4 Requirements engineering 63

 Guidelines for writing requirements

Invent a standard format and use it for all requirements.

Use text highlighting to identify key parts of the requirement.
Avoid the use of computer jargon(vocabulary).
Include an explanation (rationale) of why a requirement is necessary.

Chapter 4 Requirements engineering

Example requirements for the insulin
pump software system
3.2 The system shall measure the blood sugar and deliver insulin, if
required, every 10 minutes. (Changes in blood sugar are relatively
slow so more frequent measurement is unnecessary; less frequent
measurement could lead to unnecessarily high sugar levels.)

3.6 The system shall run a self-test routine every minute with the
conditions to be tested and the associated actions defined in Table 1.
(A self-test routine can discover hardware and software problems
and alert the user to the fact the normal operation may be
impossible.)

Chapter 4 Requirements engineering 65

Problems with natural language
Lack of clarity
 Precision is difficult without making the document difficult to read.
Requirements confusion
 Functional and non-functional requirements tend to be mixed-up.
Requirements amalgamation
 Several different requirements may be expressed together.

Chapter 4 Requirements engineering

B. Structured specifications
An approach to writing requirements where the freedom of the
requirements writer is limited and requirements are written in a
standard way.
This works well for some types of requirements e.g. requirements for
embedded control system but is sometimes too rigid for writing
business system requirements.
Possible sub-divisions are:
a) Form-based
b) Tabular

Chapter 4 Requirements engineering 67

a) Form-based specifications
Definition of the function or entity.
Description of inputs and where they come from.
Description of outputs and where they go to.
Information about the information needed for the computation and
other entities used.
Description of the action to be taken.
Pre and post conditions (if appropriate).
The side effects (if any) of the function.

Chapter 4 Requirements engineering

A structured specification of a
requirement for an insulin pump –(a)

Chapter 4 Requirements engineering 69

A structured specification of a
requirement for an insulin pump –(b)

Chapter 4 Requirements engineering 70

b) Tabular specification
Used to supplement natural language.
Particularly useful when you have to define a number of
possible alternative courses of action.
For example, the insulin pump systems bases its
computations on the rate of change of blood sugar level
and the tabular specification explains how to calculate
the insulin requirement for different scenarios.

Chapter 4 Requirements engineering

Tabular specification of computation for
an insulin pump
Condition Action

Sugar level falling (r2 < r1) CompDose = 0

Sugar level stable (r2 = r1) CompDose = 0

Sugar level increasing and rate of increase CompDose = 0

decreasing
((r2 – r1) < (r1 – r0))
Sugar level increasing and rate of increase CompDose =
stable or increasing round ((r2 – r1)/4)
((r2 – r1) ≥ (r1 – r0)) If rounded result = 0 then
CompDose = MinimumDose

Chapter 4 Requirements engineering 72

Requirements engineering processes
The processes used for RE vary widely depending on the
application domain, the people involved and the
organisation developing the requirements.
However, there are a number of generic activities common
to all processes
 Requirements elicitation;
 Requirements analysis;
 Requirements validation;
 Requirements management.
In practice, RE is an iterative activity in which these
processes are interleaved(enclosed).
Chapter 4 Requirements engineering 73
The requirements elicitation and analysis
process

Chapter 4 Requirements engineering 74

Process activities
Requirements discovery
Interacting with stakeholders to discover their requirements.
Domain requirements are also discovered at this stage.
Requirements classification and organisation
Groups related requirements and organises them into coherent clusters.
Prioritisation and negotiation
Prioritising requirements and resolving requirements conflicts.
(Usually, stakeholders have to meet to resolve differences and
agree on compromise requirements.)
Requirements specification
Requirements are documented.

Chapter 4 Requirements engineering

 What Is a Model?
• A model is “a complete description of a system from a particular perspective.” A
model is a simplification of reality.
Usage of system models
Models for existing system during requirements engineering are used to
clarify these systems’ functionalities. These models can be used as a basis
for discussing systems’ strengths and weaknesses, leading to requirements
for the new system.
Models of the new system are used during requirements engineering to
help explain the proposed requirements to other system stakeholders.
Engineers use these models to discuss design proposals and to document
the system for implementation.
In a model-driven engineering process, it is possible to generate a complete
or partial system implementation from the system model.

Chapter 5 System modeling 77

Behavioral models
• Behavioral models are models of the dynamic behavior of
the system as it is executing.
• They show what happens or what is supposed to happen
when a system responds to a stimulus from its
environment.
• Stimuli can be of two types:
1. Data: Some data arrives that has to be processed by the
system.
2. Events: Some event happens that triggers system processing.
Events may have associated data but this is not always the case.

78
Chapter 5 System modeling
Behavioral model types
A. Data-driven
B. Event-driven

79
A. Data driven behavioral model
• Many business systems are data processing systems that
are primarily driven by data. They are controlled by the
data input to the system with relatively little external
event processing. Their processing involves a sequence of
actions on that data and the generation of an output.
• For example, a phone billing system will accept information
about calls made by a customer, calculate the costs of these
calls, and generate a bill to be sent to that customer.

80
B. Event-driven behavioral model
• By contrast, real-time systems are often event driven
with minimal data processing.
• For example, a landline phone switching system responds to
events such as ‘receiver off hook’ by generating a dial tone, or
the pressing of keys on a handset by capturing the phone
number, etc.

81
Data Flow Diagrams (DFDs)
• Used for data-driven modelling
• Data flow diagrams (DFDs) are one of the diagramming
techniques(graphical models) used in structured systems
analysis and design

82
DFD Elements
• Process
• Activity/function that is performed for some specific business
reason. Names start with a verb and ending with a noun (e.g.,
“Determine request quantity”).
• Data Flow
• A data flow is a single piece of data (e.g., quantity available) (also
called a data element), should be named with a noun.
• Data Store
• collection of data that is stored in some way, named with a noun
and is assigned an identification number.
• External Entity
• a person, organization, organization unit, or system that is external to
the system, but interacts with it. 83
Data Flow
Diagram
Symbols

84
 85

DFD Levels
 Decomposition is the process of modeling the system and
its components in increasing levels of detail.
 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.

85
Context Diagram

NOTE: only one process symbol, and no data stores shown. Major 86
information flows are shown between entities and the system.
 Level-0 DFD

Processes are labeled 1.0, 2.0, etc. These will be decomposed into more primitive
(lower-level) DFDs. Depletion means reduction.
87
 Level-1 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.
88
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
Processes are labeled 4.3.1, 4.3.2, etc. If this is the lowest
4.3.
level of the hierarchy, it is called a primitive DFD.

89
 90

Balancing
 Balancing involves insuring that information
presented at one level of a DFD is accurately
represented in the next level DFD.

90
Balanced DFD

These are balanced because the

numbers of inputs and outputs
of context diagram process
equal the number of inputs and 91
outputs of Level-0 diagram.
Balanced DFD (cont.)

These are balanced because the numbers of

inputs and outputs to Process 1.0 of the
Level-0 diagram equals the number of
inputs and outputs to the Level-1 diagram.

1 input
4 outputs
92
 Unbalanced DFD

This is
1 input unbalanced
1 output because the
process of the
context
diagram has
only one input
but the Level-
2 inputs 0 diagram has
1 output two inputs.

93
Balancing the DFD

94
3. System modeling using UML
• System modeling has now come to mean representing a system using some kind of
graphical notation, which is now almost always based on notations in the Unified
Modeling Language (UML).

Chapter 5 System modeling 95

 UML
• The Unified Modeling Language is a set of 14 different diagram types that may
be used to model software systems.
• It emerged from work in the 1990s on object-oriented modeling where similar
object-oriented notations were integrated to create the UML. A major revision
(UML 2) was finalized in 2004.
• The UML is universally accepted as the standard approach for developing models
of software systems. Variants have been proposed for more general system
modeling.

Chapter 5 System modeling 96

 Why DFDs aren’t used in O-O
• In DFDs a clear separation is made between processes and stored data.
• It is assumed that all data is ‘visible’ to any process that needs to access it.
• In an O-O system the processes that operate on data are the methods of the classes that
contain the data as attributes.
• Data is encapsulated within objects, and may be hidden too.

97
97
Chapter 5 System modeling
UML diagrams
• Fortunately, four UML diagramming techniques have come to dominate object-oriented
projects:
• Use case diagrams,
• Class diagrams,
• Sequence diagrams, and
• Behavioral state machine diagrams.
• The other diagramming techniques are useful for their particular purposes, but these four
techniques form the core of UML as used in practice today

98
UML diagrams
• The use case diagram is always created first, but the order in which the other diagrams are created
depends upon the project and the personal preferences of the analysts.
• Then class diagrams, sequence diagrams, and behavioral state machine diagrams are used to further
define the evolving system from various perspectives.
• Most analysts start either with the class diagrams (showing what objects contain and how they are
related, much like ERDs) or the sequence diagrams (showing how objects dynamically interact, much
like DFDs), but in practice, the process is iterative.
• Developing sequence diagrams often leads to changes in the class diagrams and vice versa, so analysts
often move back and forth between the two, refining each in turn as they define the system. Generally
speaking, behavioral state machine diagrams are developed later, after the class diagrams have been
refined.

99
Interaction models
Modeling user interaction is important as it helps to identify user requirements.
Modeling system-to-system interaction highlights the communication problems that may
arise.
Modeling component interaction helps us understand if a proposed system structure is
likely to deliver the required system performance and dependability.
Use case diagrams and sequence diagrams may be used for interaction modeling.

Chapter 5 System modeling 100

Use case modeling
Use cases were developed originally to support requirements elicitation and now
incorporated into the UML.
Each use case represents a discrete task that involves external interaction with a system.
Actors in a use case may be people or other systems.

Chapter 5 System modeling 101

Usages of a Use Case Model

102
Transfer-data use case
A use case in the MHC-PMS

Chapter 5 System modeling 103

Tabular description of the ‘Transfer data’ use-case
MHC-PMS: Transfer data

Actors Medical receptionist, patient records system (PRS)

Description A receptionist may transfer data from the MHC-PMS to a general patient record
database that is maintained by a health authority. The information transferred may
either be updated personal information (address, phone number, etc.) or a
summary of the patient’s diagnosis and treatment.

Data Patient’s personal information, treatment summary

Stimulus User command issued by medical receptionist

Response Confirmation that PRS has been updated

Comments The receptionist must have appropriate security permissions to access the patient
information and the PRS.

Chapter 5 System modeling 104

Use cases in the MHC-PMS involving the role
‘Medical Receptionist’

Chapter 5 System modeling 105

Sequence diagrams
Sequence diagrams are part of the UML and are used to model the interactions between
the actors and the objects within a system.
A sequence diagram shows the sequence of interactions that take place during a particular
use case or use case instance.
The objects and actors involved are listed along the top of the diagram, with a dotted line
drawn vertically from these.
Interactions between objects are indicated by annotated arrows.

Chapter 5 System modeling 106

107
Elements of a Sequence Diagram
• Actors and objects participating in the sequence are placed across the top of the diagram,
depicted by actor symbols from the use case diagram or unlabeled rectangles.
• For each of the objects, the name of the class that they are an instance of is given after the
object’s name.
• A dotted line runs vertically below each actor and object to denote the lifeline of the
actors/objects over time.

108
Elements of a Sequence Diagram
• A thin, rectangular box, called the execution occurrence, is overlaid onto the lifeline to
show when the classes are sending and receiving messages.
• A message is a communication between objects that conveys information, with the
expectation that activity will ensue, and messages passed between objects are shown
by solid lines connecting two objects, called links.
• The arrow on the link shows which way the message is being passed, and any argument
values for the message are placed in parentheses next to the message’s name. The
order of messages goes from top to bottom, so messages located higher on the
diagram represent messages that occur earlier in the sequence, versus the lower
messages that occur later.

109
Elements of a Sequence Diagram
• There are times that a message is sent only if a condition is met. In those cases, the
condition is placed between a set of [], such as [Authorization Ok]
• It is possible to explicitly show the return from a message, with a return link, a dashed
message. However, adding return links tends to clutter the diagram. Therefore, unless the
return links add a lot of information to the diagram, they should be omitted.
• The interaction operator alt means that the combined fragment represents a choice or
alternatives of behavior.

110
Sequence diagram for “View patient information”

Chapter 5 System modeling 111

Description of the sequence diagram

a. The medical receptionist triggers the ViewInfo method in an instance P

of the PatientInfo object class, supplying the patient’s identifier, PID. P is
a user interface object, which is displayed as a form showing patient
information.
b. The instance P calls the database to return the information required,
supplying the receptionist’s identifier to allow security checking.
c. The database checks with an authorization system that the user is
authorized for this action.
d. If authorized, the patient information is returned and a form on the
user’s screen is filled in. If authorization fails, then an errormessage is
returned.
Chapter 5 System modeling 112
Sequence diagram for Transfer Data

Chapter 5 System modeling 113

Chapter 5 System modeling
Description of the sequence diagram
1. The receptionist logs on to the PRS.
2. There are two options available. These allow the direct transfer of updated
patient information to the PRS and the transfer of summary health data
from the MHC-PMS to the PRS.
3. In each case, the receptionist’s permissions are checked using the
authorization system.
4. Personal information may be transferred directly from the user interface
object to the PRS. Alternatively, a summary record may be created from the
database and that record is then transferred.
5. On completion of the transfer, the PRS issues a status message and the user
logs off.
Chapter 5 System modeling 114