CHAPTER ONE

Introduction to Software Engineering

1
Why Software Engineering?
Software development is hard!
Important to distinguish easy systems (one developer, one
user, experimental use only) from hard systems (multiple
developers, multiple users, products)
Experience with easy systems is misleading
One person techniques do not scale up
Analogy with bridge building:
Over a stream = easy, one person job
Over River Severn ? (the techniques do not scale)

The problem is complexity
Many sources, but size is key:
UNIX contains 4 million lines of code
Windows 2000 contains 10
8
lines of code
NB: Software engineering is about managing this complexity.
2
FAQs about software engineering

What is
software?
software process?
software engineering?
software process model?


3
What is software?
Computer programs and associated documentation



Software products may be developed for a particular
customer or may be developed for a general market
Software products may be
Generic - developed to be sold to a range of different
customers
Bespoke (custom) - developed for a single customer
according to their specification

4
What is software engineering?
Software engineering is an engineering discipline
which is concerned with all aspects of software
production

Software engineers should
adopt a systematic and organised approach to their
work
use appropriate tools and techniques depending on
the problem to be solved,
the development constraints and
the resources available
5
What is the difference between software
engineering and computer science?
Computer Science Software Engineering
is concerned with
Computer science theories are currently insufficient to
act as a complete underpinning for software
engineering, BUT it is a foundation for practical aspects
of software engineering
theory
fundamentals

Algorithms, date structures,
complexity theory, numerical
methods
the practicalities of developing
delivering useful software

SE deals with practical problems in
complex software products
6
Software Engineering Body of Knowledge
Source: http://www.sei.cmu.edu/pub/documents/99.reports/pdf/99tr004.pdf
7
SE history
SE introduced first in 1968 conference about
software crisis when the introduction of third
generation computer hardware led more complex
software systems then before
Early approaches based on informal
methodologies leading to
Delays in software delivery
Higher costs than initially estimated
Unreliable, difficult to maintain software
Need for new methods and techniques to manage
the production of complex software.
8
Software myths
Management myths
Standards and procedures for building software
Add more programmers if behind the schedule
Customer myths
A general description of objectives enough to start coding
Requirements may change as the software is flexible
Practitioner myths
Task accomplished when the program works
Quality assessment when the program is running
Working program the only project deliverable
9 9
Software failures
Therac-25 (1985-1987): six people overexposed during
treatments for cancer
Taurus (1993): the planned automatic transaction settlement
system for London Stock Exchange cancelled after five years of
development
Ariane 5 (1996): roket exploded soon after its launch due error
conversion (16 floating point into 16-bit integer)
The Mars Climate Orbiter assumed to be lost by NASA officials
(1999): different measurement systems (Imperial and metric)
However, important Progresses
Ability to produce more complex software has increased
New technologies have led to new SE approaches
A better understanding of the activities involved in software
development
Effective methods to specify, design and implement software
have been developed
New notations and tools have been produced

10 10
What is a software process?
SP is a set of activities whose goal is the development or evolution of software
Fundamental activities in all software processes are:
Specification - what the system should do and its development constraints
Development - production of the software system (design and implementation)
Validation - checking that the software is what the customer wants
Evolution - changing the software in response to changing demands
What is a software process model?: SPM is a simplified representation of a
software process, presented from a specific perspective
Examples of process perspectives:
Workflow perspective: represents inputs, outputs and dependencies
Data-flow perspective: represents data transformation activities
Role/action perspective: represents the roles/activities of the
people involved in software process
Generic process models
Waterfall
Evolutionary development
Formal transformation
Integration from reusable components

11 11
What are the costs of software engineering?
Roughly 60% of costs are development costs, 40%
are testing costs. For custom software, evolution
costs often exceed development costs

Costs vary depending on the type of system being
developed and the requirements of system attributes
such as performance and system reliability

Distribution of costs depends on the development
model that is used
12 12
What is CASE ?
(Computer-Aided Software Engineering)
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
Software systems which are intended to provide
automated support for software process activities,
such as requirements analysis, system modelling,
debugging and testing
13 13
What are the attributes of good
software?
Maintainability
Software must evolve to meet changing needs
reliability
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
The software should deliver the required functionality
and performance to the user and should be
maintainable, reliable and usable
14 14
What are the key challenges
facing software engineering?
Software engineering in the 21
st
century faces
three key challenges:
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
15 15
Object Oriented Concepts
Object-oriented
Means to organize the software as a collection of discrete
objects that incorporate both data structure and behaviour
Object concepts
We continue to explore the question what are good
systems like? by describing the object oriented
paradigm.
We shall answer these questions:
What is an object?
How do objects communicate?
How is an objects interface defined?
What have objects to do with components?
Finally we consider inheritance, polymorphism and
dynamic binding.


16 16
What is an object?
Conceptually, an object is a thing you can interact with:
you can send it various messages and
it will react
How it behaves depends on the current internal state of the
object, which may change
For example: as part of the objects reaction to receiving a
message.
It matters which object you interact with, an object has an
identity which distinguishes it from all other objects.
An object is a thing which has
behaviour,
state and
identity [Grady Booch, 1991]
17 17
State
The state of the object is all the data which it currently encapsulates
An object normally has a number of named attributes (or instance
variables or data members) each of which has a value
Some attributes can be mutable
An attribute ADDRESS
other attributes may be constant (immutable)
Date of birth
Identifying number

Behaviour
The way an object acts and reacts, in terms of its state
changes as message passing.
An object understands certain messages,
it can receive the message and act on them.
The set of messages that the object understands, like the set
of attributes it has, is normally fixed.
18 18
Identity - is a little more slippery
The idea is that objects are not defined just by
the current values of their attributes
An object has continues existence
For example the values of the objects attributes could
change, perhaps in response to a message, but it
would still be the same object.
An object is normally referred to by a name, but
the name of the object is not the same thing as
the object, because the same object may have
several different names
19 19
Example
Consider an object which well call myClock, which
understands the messages:
reportTime
resetTimeTo(07:43), resetTimeTo(12:30) or indeed more
generally resetTimeTo(newTime)
How does it implements this functionality?
The outside world doesnt need to know the information
should be hidden !!!
but perhaps it has an attribute time
Or perhaps it passes these messages on to some other
object, which it knows about, and has the other object
deal with messages
20 20
Object: classification
objects with the same data structure (attributes) and behaviour
(operations) are grouped into a class
each class defines a possibly infinite set of objects
Each object is an instance of a class
Each object knows its class
Each instance has its own value for each attribute (state) but
shares the attribute names and operations with other instances
of the class
also static i.e. class variables
class encapsulates data and behaviour, hiding implementation
details of an object


21
Deviation: why have classes????
Why not just have objects, which have state, behaviour and identity
as we require?
Classes in object oriented languages serve two purposes:
Convenient way of describing a collection (a class) of objects
which have the same properties
In most modern OO languages, classes are used in the same way
that types are used in many other languages
To specify what values are acceptable
Classes and types
Often people think of classes and types as being the same thing
(indeed it is convenient and not often misleading, to do so).
However, its wrong!
Remember that a class defines not only what messages an object
understand!
It also defines what the object does in response to the messages.
22
22
Object: inheritance
the sharing of attributes and operations among classes based upon
a hierarchical relationship
class can be defined broadly and then refined into successively
finer subclasses
each subclass incorporates or inherit all the properties of its super
class and its own unique properties
Subclass Superclass
A subclass is an extended, specialized version of its superclass.
It includes the operations and attributes of the superclass, and
possibly some more
Inheritance warning
(!) An object class is coupled to its
super-classes. Changes made to the attributes
or operations in a super-class propagate to all
sub-classes
23 23
Object: Polymorphism
it means that the same operation may behave differently on
objects of different underlying class while being referenced as a
superclass
OOPL automatically selects the correct method to implement an
operation based on the name of the operation (method signature)
and the objects class being implemented
Polymorphism example


Vehicle v = null;
v = new Car();
v.startEngine();
v = new Boat();
v.startEngine();
24 24
CHAPTER TWO
The Unified Process
2
5
Grady Booch speaks
People are more important than any
process.
Good people with a good process will
outperform good people with no
process any time.
26
Overview
Unified Process is component based
system is built using software components
interconnected using well defined interfaces
Unified Process uses Unified Modelling Language
(UML)
Unified Process is distinguished by being
use-case driven
architecture-centric
iterative and incremental
Based around the 4Ps - People, Project, Product,
Process
27
Cont...
Provides disciplined approach to assigning
tasks and responsibilities
Guide for how to use Unified Modelling
Language (UML) effectively
Activities create and maintain (UML) models
Is a configurable process
28
Characteristics of Modern Systems
Volatile business environment subject to constant
change - BPR; rapid IS development needed
Wide range of more complex system types CAD/CAM,
GIS, Office Automation, CASE tools
Increased use of complex data types - text documents,
video, sound, graphics, spatial data
Sophisticated user interfaces (GUIs)
Client-Server environments / distributed systems
Tendency for larger systems with complex and varied
interrelationships among software components
29
Effective Deployment of 6 best practices
Develop software iteratively
Manage requirements
Use component-based architectures
Visually model software
Verify software quality
Control changes to software
30
Unified Process : Use Case Driven
Use Case
A description of a set of sequence of actions, including variants,
that a system performs which yields an observable result of
value to a particular actor.
(Jacobson et.al. 1999)
i.e. A piece of functionality that gives a user a result of value
Development process follows a flow
proceeds through a series of workflows derived from the use
cases
use cases are specified, designed and are the source for test
cases
they drive system architecture which in turn influences use
case selection
both mature as the development lifecycle continues
31
Unified Process : Architecture-Centric
Software architecture shows different views of the
system being built and embodies the static & dynamic
aspects of the system (design framework)
Also influenced by the computer architecture,
operating system, DBMS, network protocols etc.
Related as function (use case) and form (architecture)
The form must allow the system to evolve from initial
development through future requirements (i.e. the
design needs to be flexible)
Key use cases influence the design of the architecture
which may in turn influence development of other use
cases
32
Unified Process : Iterative and Incremental
Systems development is frequently a large undertaking -
may be divided into several mini-projects each of which is
an iteration resulting in incremental development of the
system
Iterations must be selected & developed in a planned way
i.e. in a logical order - early iterations must offer utility to
the users
iteration based on a group of use cases extending the
usability of the system developed so far
iterations deal with the most important risks first
not all iterations are additive - some replace earlier
superficial developments with a more sophisticated
and detailed one.
Concepts of use case driven, architecture centric and
iterative & incremental are of equal importance
33
An iterative and incremental process
Initial
Planning
Analysis & Design
Evaluate
Implementation
Management
Environment
Planning
Requirements
Deployment
Test
Each iteration
results in executable
release
34
Benefits of an iterative approach
Risks are mitigated earlier
Change is more manageable
Higher level of reuse
Project team can learn along the way
Better overall quality
35
Life Cycle of the Unified Process
Unified Process repeats over a series of cycles each
concluding with a product release to the users
Each cycle has 4 phases (each with a number of
iterations)
Inception, Elaboration, Construction & Transition
Delivered products will be described by related models
each with trace dependencies which chain backwards
and forwards
Use Case Model; Analysis Model; Design Model
Deployment Model; Implementation Model;
Test Model
36
Cont
The Unified Software Process has four phases:
Inception - Define the scope of project
Elaboration - Plan project, specify features,
baseline architecture
Construction - Build the product
Transition - Transition the product into end
user community
37
Core Workflows & Phases
38
The 4Ps in Software Development
Process
Product
People Project Tools
Participants
Template
Automation
Result
39
People
People are an integral part of the lifecycle of a software
product, therefore, the process that guides the
development must be people orientated
Actual development process affects people
project feasibility / risk management / team
structure
project schedule / project understandability /
sense of achievement
In modern large and complex systems developers will
be part of a team and will be playing varying and
changing roles within it
Allocation of tasks should maximise project experience
40
Project
The first project in the lifecycle (green-field
project) develops & releases the initial system;
successive cycles extend the life of the system
over many releases
The project team will have to be concerned
with:
A sequence of change
A series of iterations
An organisational pattern
41
Product
The product is the developed system and comprises:
Software system (executables, machines, procedures)
Artifacts developed (UML models, prototypes etc.)
A collection of models and relationships between
them
Use Case Model; Analysis Model;
Design Model
Deployment Model; Implementation Model; Test
Model
In the Unified Process the set of models illuminate the
system from the perspective of all people involved in the
project (users, developers, project managers)
42
Process
The Unified Software Development Process is a
definition of a complete set of activities to transform
users requirements through a consistent set of
artefacts into a software product
Unified Process is a template and each project is a
process instance of the template (i.e. the template is
the definition of the set of activities not the execution
of them)
A process is described in terms of workflows where a
workflow is a set of activities with identified artifacts
that will be created by those activities
43
Static Structure of Processes
A process describes who, what, when how
Workers (who)
Activities (how)
Artifacts (what)
Workflow (when) - sequence of activities
Designer
Use Case Analysis Use Case Design
responsible for
Use case
realisation
44
Requirements engineering
Requirements engineering is the process of
establishing:
the services that the customer requires from a
system
the constraints under which it operates and is
developed
Requirements
The descriptions of the system
services and constraints
that are generated during the
requirements engineering process
45
What is a requirement?
It may range from a high-level abstract
statement of a service or of a system constraint
to a detailed mathematical functional
specification
This is inevitable as requirements may serve a
dual function
May be the basis for a bid for a contract - therefore must be
open to interpretation
May be the basis for the contract itself - therefore must be
defined in detail
Both these statements may be called requirements
46
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 services. Written as a
contract between client and contractor
Software specification
A detailed software description which can serve as a
basis for a design or implementation. Written for
developers
47
Requirements readers
Client managers
System end-users
Client engineers
Contractor managers
System architects
System end-users
Client engineers
System architects
Software developers
Client engineers (perhaps)
System architects
Software developers
User requirements
System requirements
Software design
specification
48
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.
Non-functional requirements
constraints on the services or functions offered by
the system such as timing constraints, constraints on
the development process, standards, etc.
Domain requirements
Requirements that come from the application
domain of the system and that reflect characteristics
of that domain

49
Functional Requirements
Describe functionality or system services

Depend on the type of software, expected users
and the type of system where the software is
used

Functional user requirements may be high-level
statements of what the system should do BUT
functional system requirements should describe
the system services in detail
50
Examples of functional requirements
The user shall be able to search either all of the
initial set of databases or select a subset from
it.
The system shall provide appropriate viewers
for the user to read documents in the
document store.
Every order shall be allocated a unique
identifier (ORDER_ID) which the user shall be
able to copy to the accounts permanent
storage area.
51
Requirements imprecision
Problems arise when requirements are not
precisely stated
Ambiguous requirements may be interpreted
in different ways by developers and users
Consider the term appropriate viewers
User intention - special purpose viewer for each
different document type
Developer interpretation - Provide a text viewer that
shows the contents of the document
52
Requirements completeness and consistency
In principle requirements should be both
complete and consistent
Complete
They should include descriptions of all facilities
required
Consistent
There should be no conflicts or contradictions in the
descriptions of the system facilities
In practice, it is very difficult or impossible to
produce a complete and consistent
requirements document
53
Non-functional requirements
Define system properties and constraints e.g.
reliability, response time and storage
requirements. Constraints are I/O device
capability, system representations, etc.
Process requirements may also be specified
mandating a particular CASE system,
programming language or development method
Non-functional requirements may be more
critical than functional requirements. If these
are not met, the system is useless
54
Non-functional Requirements 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 e.g. process standards used,
implementation requirements, etc.
External requirements
Requirements which arise from factors which are external to
the system and its development process e.g. interoperability
requirements, legislative requirements, etc.
55
Examples
A system goal
The system should be easy to use by experienced
controllers and should be organised in such a way that user
errors are minimised.
A verifiable non-functional requirement
Experienced controllers shall be able to use all the system
functions after a total of two hours training. After this
training, the average number of errors made by
experienced users shall not exceed two per day.

56
Requirements measures
Prope rty Measure
Speed Processed transactions/second
User/Event response time
Screen refresh t ime
Size K Byt es
Number of RAM chips
Ease of use Training t ime
Number of help frames
Reliability Mean time t o failure
Probabilit y of unavailability
Rate of failure occurrence
Availabilit y
Robustness Time to restart after failure
Percent age of events causing failure
Probabilit y of dat a corruption on failure
Port abilit y Percent age of t arget dependent statements
Number of t arget syst ems
57
Domain requirements
Derived from the application domain and
describe system characteristics and features
that reflect the domain

May be new functional requirements,
constraints on existing requirements or define
specific computations
If domain requirements are not satisfied, the
system may be unworkable
58
Domain requirements problems
Understandability
Requirements are expressed in the language of the
application domain
This is often not understood by software engineers
developing the system
Implicitness.... /indirectness
Domain specialists understand the area so well that they
do not think of making the domain requirements explicit
59
User requirements
Should describe functional and non-functional
requirements so that they are understandable
by system users who dont have detailed
technical knowledge

User requirements are defined using natural
language, tables and diagrams
60
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/ mix
Several different requirements may be expressed together
61
System requirements
More detailed specifications of user
requirements

Serve as a basis for designing the system

May be used as part of the system contract

System requirements may be expressed using
system models (will be discussed in Chapter 3
& 4)
62
The requirements analysis document
The requirements document is the official
statement of what is required of the system
developers

Should include both a definition and a
specification of 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
63
CHAPTER THREE
USE Case Design
64

Why Use Cases?

Use Case
A set of scenarios related by a common actor and a goal
A description of sequences of actions performed by a given
system to produce a result for an actor
Use cases specify the expected behavior [what], and not
the exact method of making it happen [how]
Use cases are created based on identified functional
requirements but are not mapped one-to-one to
requirements
Use cases once specified can be denoted using a clear
and precise visual modeling language such as UML
65
Terms and Concepts
Actors
Represent roles that humans, hardware devices, or external
systems play while interacting with a given system
They are not part of the system and are situated outside of the
system boundary
Actors may be both at input and output ends of a use case
Primary or Secondary
Notation:
66
Cont
Use case
A set of interactions between a system and an external
person or system that achieves a goal.
defines a goal-oriented set of interactions between external
actors and the system under consideration
is initiated by a user with a particular goal in mind, and
completes successfully when that goal is satisfied
capture who (actor) does what (interaction) with the system,
for what purpose (goal), without dealing with system
internals.
use case steps are written in an easy-to-understand
structured narrative using the vocabulary of the domain
Notation:

Use case Name
67
Cont
Scenarios
instance of a use case, and represents a single path through
the use case
Specify behavior of use case by description, not modeling
Examples include informal structured text, formal
structured text with conditions, and pseudo-code
Typically specifies:
How and when the use case starts and ends
Interaction with the actors and the exchange of objects
Flow of events: main / typical (success and exceptional
(failure) flows
68
Cont
Scenarios Example:
In a human resources system, for the Hire
Employee use case, the following scenarios may
apply:
Typical success scenario: Hire a person from
outside of the company, for example, from
another company
Alternative success scenario: Hire a person from
within the same company, for instance, from
another division
Exceptional failure scenario: No qualified person
could be hired
69
Cont
Entry and Exit Conditions
Entry conditions describe the environment under
which the use case is invoked
Exit conditions reflect the impact of the use case on
the environment through its execution
Quality Requirements
Describe quality attributes in terms of a specific
functionality
For example, requires system response in < 30
seconds
70
Cont.
Relationships
Organize use cases by grouping them in packages
Generalization: The child use case exhibits a more
specific variation in behavior than as specified for its
parent
Include: Common behavior of more than one use case
is referenced as a separate instance to avoid
repetition
Extend: Implicit integration of the behavior of
another use case by declaring the extension points /
events in the base
71
Identifying Actors, Use Cases, and Scenarios
Identifying Actors:
Define system boundary to identify actors correctly
Identify users and systems that depend on the
systems primary and secondary functionalities
Identify hardware and software platforms with which
the system interacts
Select entities that play distinctly different roles in
the system
Identify as actors external entities with common
goals and direct interaction with the system
Denote actors as nouns
72
Cont
Identifying Use Cases:
Business / Domain Use Cases:
Interactions between users and the business (or domain)
System Use Cases:
Interactions between users and the system
One business use cases contains a set of system use cases
To name the use cases, give it a verb name to show the
action that must be performed
Describe a transaction completely
No description of user interface whatsoever
Capture use cases during requirements elaboration
73
Cont
Identifying Scenarios
Extract the functionality that is available to each actor
Establish specific instances and not general
descriptions
Denote situations in the current and future systems
Identify:
Tasks to be performed by the user and the system
Flow of information to the user and to the system
Events that are conveyed to the user and to the system
For the events flow, name steps in active voice
74
UML Use Cases Example
75
Courseware System Description
Informal Description:
For this case study, the task is of constructing the design elements for a
system that can be used to manage courses and classes for an organization
that specializes in providing raining. The name of the system is Courseware
System. The organization offers courses in a variety of areas such as
learning management techniques and understanding different software
languages and technologies. Each course is made up of a set of topics.
Tutors in the organization are assigned courses to teach according to the
area that they specialize in and their availability. The organization publishes
and maintains a calendar of the different courses and the assigns tutors
every year. There is a group of course administrators in the organization
who manage the courses including course content, assigning courses to
tutors, and defining the course schedule. The training organization aims to
use the Courseware System to get a better control and visibility to the
course management and to also streamline the process of generating and
managing schedules for different courses
76
Courseware Overview
The following terms and entities are specific to the
system:
Courses and Topics that make up courses
Tutors that teach courses
Course Administrators who manage the assignment
of courses to tutors
Calendars and Course Schedules that are generated
as a result of the work performed by the course
administrators
Students who refer to Calendars and Course
Schedules to decide which courses they wish to
take up for study
77
Courseware Actors and Use Cases
Actors: Tutor, Student, Course Administrator
(main actor)
Use Cases (primary business: secondary user)
Manage courses: View courses, Manage topics for a
course, and Manage course information
Manage tutors: View course calendar, View tutors,
Manage tutor information, and Assign courses to
tutors
78
79
80
Courseware Scenarios Example /1
Use Case: Manage Course Information (UC_ID1)
Participating Actors: Course Administrator
Entry Conditions: Course Administrator is logged
into CourseWare
Exit Conditions: Course Administrator has received
an acknowledgement from the system that the
selected transaction is complete, or if not
complete, a message explaining the failure
Quality Requirements: (Performance) Course
Administrator receives a response from the system
in less than 3 seconds
Related Requirements: Create, Modify, and Delete
Course
81
Courseware Scenarios Example /2
Use Case: Manage Course Information
(UC_ID1)
Typical flow of events:
1. Course Administrator selects Create New Course
a) System invokes Create New Course use case
2. Course Administrator selects Modify Existing Course
a) System invokes Modify Existing Course use case
82
Courseware Scenarios Example /3
Use Case: Create New Course (UC_ID2)
Participating Actors: Course Administrator
Extends: Manage Course Information (UC_ID1)
Entry Conditions: Course Administrator has selected
Create New Course option
Exit Conditions: Course Administrator has received an
acknowledgement from the system that a course has
been created, or if not, a message explaining the
failure
Quality Requirements: (Performance) Course
Administrator receives a response from the system in
less than 3 seconds
Related Requirements: Create Course
83
Courseware Scenarios Example /4
Use Case: Manage Course Information (UC_ID2)
Typical flow of events:
1. Course Administrator enters New Course Information
a) System invokes Validate Course Information use case
b) For a valid response, system creates a new course
entry and sends an acknowledgment back to the
actor
Exceptions:
1. Course Administrator enters New Course Information
a) Invalid response received, so system reports
failure with a message indicating invalid course
information
84
Courseware Scenarios Example /5
Use Case: Modify Existing Course (UC_ID3)
Participating Actors: Course Administrator
Extends: Manage Course Information (UC_ID1)
Entry Conditions: Course Administrator has selected
Modify Existing Course option
Exit Conditions: Course Administrator has received an
acknowledgement from the system that a course has
been modified, or if not, a message explaining the
failure
Quality Requirements: (Performance) Course
Administrator receives a response from the system in
less than 3 seconds
Related Requirements: Modify and Delete Course
85
Courseware Scenarios Example /6
Use Case: Modify Existing Course (UC_ID3)
Typical flow of events:
1. Course Administrator selects Find Existing Course
option
a) System searches for a selected course and
returns existing course information
2. Course Administrator enters new course
information
a) System invokes Validate Course Information
use case
b) For a valid response, system updates the
existing course entry and sends an
acknowledgment back to the actor
86
Courseware Scenarios Example /7
Use Case: Modify Existing Course (UC_ID3)
Alternatives:
1. Course Administrator selects Delete Existing Course
option
a) System invokes Delete Existing Course use case
Exceptions:
1. Course Administrator selects Find Existing Course option
a) System searches for a selected course and returns
failure stating that the course could not be found
2. Course Administrator enters New Course Information
a) Invalid response received, so system reports failure
with a message indicating invalid course information
87
Courseware Scenarios Example /8
Use Case: Delete Existing Course (UC_ID4)
Participating Actors: Course Administrator
Extends: Modify Existing Course (UC_ID3)
Entry Conditions: Course Administrator has selected
Delete Existing Course option
Exit Conditions: Course Administrator has received an
acknowledgement from the system that a course has
been deleted, or if not, a message explaining the
failure
Quality Requirements: (Performance) Course
Administrator receives a response from the system in
less than 3 seconds
Related Requirements: Delete Course
88
Courseware Scenarios Example /9
Use Case: Delete Existing Course (UC_ID4)
Typical flow of events:
a) System deletes a selected course and sends an
acknowledgment back to the user
Exceptions:
a) System cannot delete a selected course so it
returns failure stating that the course could not
be deleted
89