LEC-1 Intro

2024年8月12日 8:35

Software Engineering Activities:

分区 新分区 1 的第 1 页
LEC-2 Requirements Elicitation
2024年8月15日 13:46

Project Mission Statement:

A simple short statement of what you intend to accomplish in
your project
• A project should have a project mission statement that describes the project in 2-3 sentences:
Typically they define:
i. The problem: what will be done (scope and limits)
ii. The stakeholders, developers and users
iii. The outcomes and benefits of the project
• E.G.
The GoFast team will develop a website that enables airline travellers to rate their travel
experiences. This project will be considered complete when the website has been tested
and approved for release by the FactFinding Organisation. This project supports the
International Travel Watchdogs objective to ensure air passengers can openly compare
airlines.

Requirements Elicitation:
Eliciting stakeholder needs and desires through:
○ Interview
○ Observation
○ Workshop
○ Legacy Product Study
○ Competitive Product Study
○ Prototype
• Learn problem domain, Study user tasks

Documenting the Requirements:

• Good technical writing style:
○ Write complete, simple, precise, unambiguous sentences using active voice
○ Define terms clearly and use them consistently
○ Use clear layout and formatting (e.g. organizing the requirements in a hierarchy)
• Atomize the Requirements:
○ State requirements in an atomic manner, such that the specification is verifiable,
traceable and unambiguous

Types of Requirements:
• Functional requirements: (The things that the system must do)
Describe interactions between the system and the environment
i.e., to map program inputs to program outputs
○ E.G.
▪ System functionality to be performed:
□ The library member must be able to search the library catalog
□ The bank customer must be able to withdraw cash from the ATM
▪ Information to be processed:
□ The system must display the current time in 24 hour format
□ The system must display the temperature in degrees centrigrade in the
range -10°C to +130°C to one decimal place of accuracy
▪ Interface with other systems:
□ The system must be able to use wifi to communicate all transactions with a
clients secure database
□ The system must be able to control up to six robot arms simultaneously
• Non-Functional requirements:
Describe the properties the system must have
Not directly related to the functional behaviour of the system

分区 新分区 1 的第 2 页
 ○ Not directly related to the functional behaviour of the system
○ E.G.
Usability Help messages must be displayed in the local language
according to the user’s locale
i.e. User friendliness
Reliability After a system reboot, the full system functionality must be
restored within 5 minutes
Consistency, accuracy
Performance When a book is placed in the checkout pad, the system must
detect it within 2 seconds
i.e. Response time
Supportability The database must be replaceable with any commercial product
supporting standard SQL queries
Scalability Up capacity easily
Maintainability Easy to restart/restore
Security Authentication

Requirements Validation:
• Stakeholders – the system specified meets their needs and desires (i.e. correct) and
requirements are prioritized
• Development Team – requirements (and underlying assumptions) are properly understood
• Review:
○ Walkthrough, inspection, critical review
○ Checklist for completeness, consistency, unambiguity, correctness
• Prototype

User Interface Prototype:

Sketches or a model of what a system will look like
• Brings the requirements to life for all stakeholders
• Can be implemented using:
○ Story Boarding:
Sequence of graphics showing different views of the interface in a specific
interaction

○ Still images

分区 新分区 1 的第 3 页
 ○ Interactive prototype:
Illustrates some simulated dialogue

Data Dictionary:
The problem domain glossary
NO implementation terms
• Ensures consistent unambiguous terminology that all stakeholders can agree
○ E.G.
Programme of Study, Course, Degree Programme
• Ensures specialised terms are defined
○ E.G.
Lecture, Tutorial, Cohort, Laboratory, Seminar
• E.G.
Term Definition
Program of A university program that a student enrolls into. There are three levels of
Study programs: undergraduate, master, and PhD
Semester There are four semesters in an academic year. Semester 1 and Semester 4
have 13 teaching weeks. Semester 2 and Semester 3 have 5 teaching
weeks
Course A course is a basic unit of teaching. A course must be either compulsory
or elective. A course must include lectures and tutorials. Some courses
may have labs
Lecture The traditional form of class that are delivered in lecture theaters. Each
lecture will be video recorded and published in the learning management
system
Tutorial The interactive, small-size classes that are conducted in technology-
enhanced tutorial rooms. Tutorials will not be video recorded

分区 新分区 1 的第 4 页
LEC-3 Use Case Diagram
2024年8月18日 20:46

UML (Unified Modeling Language):

A graphical notation with textual annotation for specifying, documenting and
communicating various aspects of the structure, functionality and dynamic
behaviour of complex software systems.
• NOT a programming language
• NOT the answer to all your modelling and design problems

UML Diagram Types:

Use Cases: (activities)

Describes how a user uses a system to accomplish a particular goal

Functional Requirements vs. Use Cases:

• Both are about system functionalities
• Functional requirements:
what (user, external system, functionality, and information)
• Use cases:
how (actors interact with system functionality)
• Functional requirements are the staring points for use case modeling

Use Case Model:

Use Case Diagram (static) + Use Case Description (dynamic)

Use Case Diagram:

• Elements:
Name Notation Description
Actor An external entity that interacts with system

Use Case Unit of functionality performed by system,

which yields result / value for Actor

Association Connects Actor to Use Cases(s) in which

they participate
• E.G.

分区 新分区 1 的第 5 页
 • E.G.

Use Case Associations:

Represent dependencies between use cases
• Used to reduce complexity
• Two types of use case associations:
○ Includes:
Reuse of functionality
▪ Denotes a dependency on another use case
i.e. Included Use Cases are ALWAYS used in a parent Use Case
i. Functional Decomposition:
When a function in the original problem statement is too complex,
describe it as the aggregation of a set of simpler functions
□ E.G.

ii. Reuse Existing Functionality:

When there are overlaps among use cases, the include association
from use case A to B indicates that an instance of use case A
performs all the behaviour described in use case B ("A delegates to
B")
□ E.G.
Use case "View Map" describes behaviour that can be used
by use cases "Open Incident" and "Allocate Resources"

○ Extends:
Adding optional functionality
i.e. Extends the functionality in the original problem statement
▪ Extends are only used in the parent Use Case in exceptional or unusual
circumstances
▪ E.G.
"ReportEmergency" is complete by itself, but can be extended by

分区 新分区 1 的第 6 页
 "ReportEmergency" is complete by itself, but can be extended by
use case "Help" for a scenario in which the user requires help

E.G. (Functional Requirements of a Library Management System)

• Identify potential actors
• Identify potential use cases
• Identify potential associations between use cases
1. The library member must be able to search the system for library materials
2. The library member must be able to loan library materials
3. The library management system must verify the library membership with the
University Account System before the library member can loan library materials
4. The library member must return library materials via library dropoff kiosk
5. The library management system must send overdue notice using the CITS Email
Sever to the library member
6. When there are network issues to connect to CITS Email Server, the library
management system must log the event
• Use case diagram 1:

• Use case diagram 2:

• Use case diagram 3:

分区 新分区 1 的第 7 页
分区 新分区 1 的第 8 页
LEC-4 Use Case Description
2024年8月19日 16:40

Each Use Case Must have a Use Case Description that contains:
• Participating Actors (incl. Initiating Actor):
○ A use case can have more than one participating actors
○ Initiating actor triggers the use case
○ If the use case is triggered by a system event or another use case, the initiating actor is
NULL
• Entry conditions (Pre-condition):
The system state must be satisfied to execute a use case
• Exit Conditions (Post-condition):
The system state must be reached after executing a use case
• Flow of Events (AKA Normal or Main Successful Flow):
○ Step #1 - How Actor triggers the use case
○ Step #2 - How System responds
○ Step #3 - ...
• Alternative Flows:
○ Variations or errors in the interaction (e.g. wrong username/password)
○ Return back to the normal flow of events
• Exceptions:
Exceptional situations that cause the failure of the use case (e.g. network not available)

E.G.1 Bank Customer Withdraw Money Using ATM

• Participating actor:
Bank Customer (Initiating Actor), Bank
• Entry Conditions:
1. Bank Customer has a Bank Account with the Bank; and
2. Bank Customer has an ATM Card and PIN
• Exit Conditions:
1. Bank Customer receives the requested cash; or
2. Bank Customer receives an explanation from the ATM why the cash could not be
dispensed
• Flow of Events (Normal Flows):
1. The Bank Customer inputs the card into the ATM
2. The ATM requests the input of a six-digit PIN
3. The Bank Customer enters a PIN
4. The ATM verifies the card and PIN with the account information in the Bank
5. If the card and PIN is verified the ATM requests the amount to withdraw
6. The Bank Customer enters an amount
7. The ATM verifies the amount is available in the customer account
8. If the customer account has sufficient funds, the ATM outputs the money and card and a
receipt
9. The Bank Customer removes card, receipt and money
• Alternative Flows:
○ AF-S5: If the card and PIN are invalid
i. The ATM displays the message “Invalid card and PIN. Please try again!” for 2
seconds
ii. The ATM returns to the step 2
○ AF-S8: If the customer account has insufficient funds
i. The ATM displays the message “Insufficient funds in your account! Please enter a
smaller amount!” for 2 seconds
ii. The ATM returns to the step 6
• Exceptions:
EX1: If the Bank Customer enters invalid PIN for three times

分区 新分区 1 的第 9 页
 ○ EX1: If the Bank Customer enters invalid PIN for three times
i. The ATM displays the message “Card is suspended! Please call the customer
service (1633) to reactive the card” for 2 seconds
ii. The ATM outputs the card
○ EX2: If the ATM has insufficient funds
i. The ATM displays the message “This ATM is off-service due to insufficient
funds!” at the start screen
ii. The ATM does not accept the card

E.G.2 Course Registration System

• Use cases:
○ Registrar manages the course curriculum for a semester
○ Students select 4 primary courses and 2 alternate courses
○ Students use the system to add and drop courses till the end of the second week of the
semester
○ Once a Student registers courses for a semester, the registration system notifies the
Billing System so the student may be billed for the semester
○ Professors use the system to find their course schedule
○ All users of the registration system must login the course registration system with the
assigned password before performing the tasks

• Flow of Events (Manage Curriculum):

1. The system uses the included use case Login to verify the Registrar
2. On successful login, the system prompts the Registrar to select the current semester or a
future semester
3. The Registrar selects the desired semester
4. The system prompts the Registrar to select the desired activity: ADD, DELETE, REVIEW,
or QUIT
5. If the Registrar selects the activity ADD, then he uses the included use case AddCourse
to add a course
6. If the Registrar selects the activity DELETE, then he uses the included use case
DeleteCourse to delete a course
7. If the Registrar selects the activity REVIEW, then he uses the included use case
ReviewCourses to review existing courses
8. If the Registrar selects the activity QUIT, the system returns to the semester selection

分区 新分区 1 的第 10 页
 8. If the Registrar selects the activity QUIT, the system returns to the semester selection
screen.

Apply Use Case Template to Describe Each Use Case:

分区 新分区 1 的第 11 页
LEC-5 Conceptual Models
2024年8月20日 16:37

Requirements Analysis vs. Requirements Elicitation:

• Requirements Elicitation:
○ Purpose: finding out what customers want
○ Output: a description of the system in terms of actors and use cases
• Requirements Analysis:
○ Purpose: produce a system model that is correct, complete, consistent, unambiguous
based on use cases
○ Output: conceptual model (system structure) + dynamic model (system behavior)

Formalizing Requirements with Analysis Models:

• Clarifies structural and dynamic aspects of system to be build
• Validates requirements
• Underpins solution modelling

Requirement Analysis Goals (Outputs):

• Conceptual model (structural aspect):
○ Analyze use cases to identify the objects and roles of objects involved in the system
• Dynamic model (dynamic aspect):
○ Determine how to fulfill the processes defined in the use cases and which objects do
these processes

Conceptual Model:
• Objects:
Anything that has a state and exhibits behavior
○ E.G.
Bus, Dog, Company, LoginForm, UserVerifier, UserList
• Operations:
Procedures through which objects communicate amongst themselves
○ E.G.
Bus: Stop, Start
Dog: Bark, Growl
Company: Sell, Quote
LoginForm: submit
UserVerifier: autheticate
UserList: SearchUser
• Attributes:
Variables that hold state information
○ E.G.
Bus: Seats, Colour
Dog: Name, Breed
Company: Name, Employees

Class Diagrams:
• Represent the structure of the system
• The classes define the responsibilities for doing various activities
• Used during:
○ requirements analysis: model application domain concepts
○ system design: model subsystems
○ object design: specify the detailed behavior and attributes of classes
• Classes:
○ A class represents a concept
A class encapsulates states (attributes) and behaviour (operations)

分区 新分区 1 的第 12 页
 ○ A class encapsulates states (attributes) and behaviour (operations)
▪ Each attribute has a type
▪ Each operation has a signature

• Associations:
○ Denote relationships between classes
○ The multiplicity of an association end denotes how many objects the instance of a class
can legitimately reference:
▪ A number (e.g. 3)
▪ A range of numbers (e.g. 1..6)
▪ Unspecified number / Many (*)
○ E.G.1 (1-to-1)

○ E.G.2 (1-to-Many)

○ E.G.3 (Many-to-Many)

Class Relationships:
• Generalization:
Inheritance relationship
○ Inheritance between classes
○ Interface implementation
○ Hierarchies drawn top-down with arrows pointing upward to parent
○ Line/arrow styles differ:
▪ class: solid line, black arrow
▪ abstract class: solid line, white arrow
▪ interface: dashed line, white arrow

分区 新分区 1 的第 13 页
 • Association:
Usage relationship
○ Dependency ("uses temporarily"):
▪ Often is an implementation detail, not an intrinsic part of that object's state
▪ Dotted line

○ Aggregation ("is part of"):

▪ Clear white diamond

○ Composition ("is entirely made of"):

▪ Stronger version of aggregation
▪ The parts live and die with the whole
▪ Black diamond

Requirement Analysis and Conceptual Modeling:

Use case model → Class diagram
1. Identify the Classes:
a. Recurring nouns / concepts in the use cases
b. Real-world entities the system must track

分区 新分区 1 的第 14 页
 b. Real-world entities the system must track
c. Application (problem) domain terms in data dictionary
2. Find the attributes for each Class
3. Find the methods/operations for each Class
4. Find the associations between Classes

Stereotypes of Classes:
• Boundary Class <<boundary>>:
Interaction between Actor & System

• Control Class <<control>>:

Logic to realize use case

• Entity Class <<entity>>:

Information tracked by System

○ Types of Entity Classes:

▪ Things remembered or data that persists:
□ E.G.
UserInfo, Event, Course, Book
▪ Organisational units:
□ E.G.
Company, TutorialGroup
▪ Structures:
□ E.G.
OrderList

E.G. (EnterSecureFacility Use Case Description)

• Flow of Events:
1. User presses finger on FingerprintReader
2. FingerprintReader scans fingerprint and sends image to the FacilityAccessSystem
3. The FacilityAccessValidator finds fingerprint in the EmployeeList
4. The FacilityAccessSystem validates fingerprint and unlocks EntryGate
5. EntryGate sends a signal to the FacilityAccessSystem that it has opened
6. The FacilityAccessSystem locks EntryGate, logs entry event and increments occupant
count
• Possible Classes:

• Stereotyping to Indicate Class Responsibilities:

分区 新分区 1 的第 15 页
分区 新分区 1 的第 16 页
LEC-6 Sequence Diagram & Communication Diagram
2024年8月21日 15:18

Document and Visualize Dynamic Model:

Using the following types of diagrams:
○ Sequence diagram
○ Communication diagram
○ State machine
○ Activity diagram

Sequence Diagram:
Used during requirement analysis:
○ To refine use case descriptions
○ Find additional/missing objects
1. Objects are represented by rectangles
2. Messages are represented by arrows
3. Activations are represented by narrow bars
4. Lifelines are represented by dashed lines
• Captures how a group of objects (in a Class Diagram) interact or collaborate to achieve a use
case scenario
Usually captures the dynamics of a single scenario, the sequence of messages that are
passed between the objects, and the sequence of events that happen during the
scenario
• Emphasise the time ordering of calls and messages
• Types of Interaction Frames:
sd sequence diagram
ref reference another sequence diagram
loop the actions loop until guard condition is false
(as in while, for)
opt/alt optional/alternative flow
(as in if-then, if-then-else, switch-case)
par each action is run in parallel
• E.G. (EnterSecureFacility Use Case Description)
○ Identify important verbs in flow of events:
1. User presses finger on FingerprintReader
2. FingerprintReader scans fingerprint and sends image to the FacilityAccessSystem
3. The FacilityAccessValidator finds fingerprint in the EmployeeList
4. The FacilityAccessSystem validates fingerprint and unlocks EntryGate
5. …
○ Draw sequence diagram:

Refine Use Case Description:

分区 新分区 1 的第 17 页
 ○ Refine Use Case Description:
▪ Flow of Events:
1. User presses finger on FingerprintReader
2. FingerprintReader scans fingerprint and sends image to the
FacilityAccessSystem
3. The FacilityAccessValidator finds fingerprint in the EmployeeList
4. If the fingerprint image is found in the employee list, the
FacilityAccessValidator unlocks EntryGate
5. …
▪ Alternative Flows:
□ AF-4. If the fingerprint image is not found in the employee list
1. FingerprintReader displays a “Please try again” message
2. Go back to Step 1
○ Refine Sequence Diagram:

Communication diagrams:
• Emphasise the communication links between the objects
• Represents a combination of information taken from Class, Sequence, and Use-Case Diagrams
describing both the static structure and dynamic behavior of a system
• Messages are labeled with a chronological number

分区 新分区 1 的第 18 页
• E.G.1

• E.G.2

分区 新分区 1 的第 19 页
LEC-7 Dialog Map (FSM) & Activity Diagram (Flowchart)
2024年8月26日 18:01

State Machine Diagram (AKA Statecharts, Finite State Automata):

Models a system or an object based on the “States” it can be in
• A state machine diagram begins with a start node followed by a series of states connected by
transitions and finally an end node (unless the system is in an infinite loop and there is no end
node)
• State:
A stable condition of a system, that can exist for a period of time, or for all time, until
some ACTION drives the system into another stable state
○ UML:
Represented as a rounded rectangle with a name at the top and optionally a
description of the state and/or actions and activities performed while in that state
▪ E.G.

• Transition:
○ Assumed to be instantaneous in response to an event
○ Optionally have:
▪ event: event triggers the transition
▪ guard: the condition which must be true to take the transition
▪ action: action to do during the transition
○ UML:

• Most systems will have a finite number of states in which it can be depending on the previous
state AND actions which move it to another state
• E.G.
A 2-bit binary counter has 4 states and moves from one state to the next when a clock
signal drives it to the next state

Dialog Map (State Machine Diagram):

State Machine Diagrams in UI Prototyping
• Using a State Machine Diagram and a prototype, users can experiment with the navigation
options and preview the functionality available at each screen to assess the look and feel of
the system
• Many user interfaces can be thought of as finite state machines:
only one window active at a time (states), and defined conditions for moving from one
state to another (transitions)
• Helps us find missing or incorrect navigation pathways early, when they are cheap to fix
• Spot opportunities for reuse and redundancies in the user interface, without worrying about
the details of screen design prematurely
• E.G.1 (Dialog Map of Vending Machine)

分区 新分区 1 的第 20 页
 • E.G.2 (Dialog Map of Student Management System)

UML Activity Diagram (Flowchart):

Activities: The execution of one or more basic operations

Rounded
rectangle
Control flow between activities
Arrow
Control flow that has one input and multiple outputs (go to concurrent
activities)

Fork
Multiple control flows come together into a single control flow

Join
When control flow can go in one of several directions depending on a

分区 新分区 1 的第 21 页
 When control flow can go in one of several directions depending on a
condition

Decision box
(branch)
Merge several branches into one branch

Merge branches
• E.G.1 (Activity Diagram of Do Laundry)

• E.G.2 (Swim Lane Diagram)

分区 新分区 1 的第 22 页
• E.G.3

• E.G.4

分区 新分区 1 的第 23 页
State Machine Diagram vs. Activity Diagram:
• Activity diagrams:
○ Used as a flow chart of activities performed by the system
○ Describe the workflow behavior of a system in terms of activities
• State machine diagram:
○ Models a system or an object based on the “States” it can be in

Activity Diagram of Requirement Elicitation and Analysis:

Software Requirement Specification (SRS):

• Written in natural language, in an unambiguous manner that may also include diagrams as
分区 新分区 1 的第 24 页
• Written in natural language, in an unambiguous manner that may also include diagrams as
necessary
• The detailed functional and non-functional requirements need to be defined and understood
by the development team
• Development team members (programmers and managers) are seldom the best writers of
formal documents. However, they often have to write it!
• Good practice to involve a technical writer with the development team in the drafting of the
SRS because they are usually better at assessing and planning documentation projects and
better meet customer document needs
• Contents of the SRS:
1) Product Description
i. Purpose of the System (mission statement)
ii. Scope of the System
iii. Users and Stakeholders
iv. Assumptions Requirements
2) Functional Requirements
3) Non-Functional Requirements
4) Interface Requirements
i. User
ii. Hardware
iii. Software
5) Data Dictionary

分区 新分区 1 的第 25 页
LEC-8 Software Processes
2024年8月26日 20:11

Software Process Model:

A software process model is an abstract representation of a process
• Presents a description of a process from some particular perspective
• Composition:
○ Specification:
Defines what the system should do
○ Design and implementation:
Defines the organization of the system and implementing the system
○ Validation:
Checks that it does what the customer wants
○ Evolution:
Changes the system in response to changing customer needs

Software Process Descriptions:

• When we describe and discuss software processes, we usually talk about the activities in
these processes such as specifying a data model, designing a user interface, etc. and the
ordering of these activities
• Process descriptions may also include:
○ Products:
The outcomes of a process activity
○ Roles:
Reflect the responsibilities of the people involved in the process
○ Pre- and post-conditions:
Statements that are true before and after a process activity has been enacted or a
product produced

Plan-driven vs Agile Processes:

• Plan-driven processes:
Processes where all of the process activities are planned in advance and progress is
measured against this plan
• 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

Software Process Models:

• The waterfall model: Plan-driven model
Separate and distinct phases of specification and development
○ Waterfall Model Phases:
▪ Requirements analysis and definition
▪ System and software design
▪ Implementation and unit testing
▪ Integration and system testing
▪ Operation and maintenance
○ In principle, a phase has to be complete before moving onto the next phase
○ Problem:
▪ Difficulty of accommodating change after the process is underway
□ 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

分区 新分区 1 的第 26 页
 ○ 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

• Incremental development: May be plan-driven or agile

Specification, development and validation are interleaved
○ Cost of accommodating changing customer requirements is reduced:
The amount of analysis and documentation that has to be redone is much less
than is required with the waterfall model
○ 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
○ 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

• Integration and configuration: May be plan-driven or agile

The system is assembled from existing configurable components
○ Based on software reuse where systems are integrated from existing components or
application systems
○ Reused elements may be configured to adapt their behaviour and functionality to a
user’s requirements
○ Reduced costs and risks
since less software is developed from scratch
Faster delivery and deployment of system

分区 新分区 1 的第 27 页
 ○ Faster delivery and deployment of system
○ Reuse is now the standard approach for building many types of business system
○ Key Stages:
▪ Requirements specification
▪ Software discovery and evaluation
▪ Requirements refinement
▪ Application system configuration
▪ Component adaptation and integration
○ Types of reusable software:
▪ Stand-alone application systems (AKA COTS or Commercial-Off-The-Shelf
systems) that are configured for use in a particular environment
▪ Collections of objects that are developed as a package to be integrated with a
component framework like .NET or J2EE
▪ Web services that are developed according to service standards and which are
available for remote invocation
○ Problems:
▪ Requirements compromises are inevitable so system may not meet real needs of
users
▪ Loss of control over evolution of reused system elements

• In practice, most large systems are developed using a process that incorporates elements from
all of these models

Real-World Process Activities:

• Real software processes are interleaved 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
For example, in the waterfall model, they are organized in sequence, whereas in
incremental development they are interleaved.

分区 新分区 1 的第 28 页
LEC-9 Agile Software Development Process
2024年9月2日 12:38

Rapid software development:

• Now often the most important requirement for software systems
○ Businesses operate in a fast-changing requirement and it is practically impossible to
produce a set of stable software requirements
○ Software has to evolve quickly to reflect changing business needs
• Plan-driven development is essential for some types of system but does not meet these
business needs
• Agile development methods emerged in the late 1990s whose aim was to radically reduce the
delivery time for working software systems

Agile development:
• Program specification, design and implementation are interleaved
• The system is developed as a series of versions or increments with stakeholders involved in
version specification and evaluation
• Frequent delivery of new versions for evaluation
• Extensive tool support used to support development
○ E.G.
automated testing tools
• Minimal documentation
Focus on working code

Plan-driven vs. Agile development:

• Plan-driven development:
○ A plan-driven approach to software engineering is based around separate development
stages
○ Outputs to be produced at each of these stages planned in advance
○ Not necessarily waterfall model – plan-driven, incremental development is possible
○ Iteration occurs within activities
• Agile development:
○ Specification, design, implementation and testing are interleaved
○ Outputs from the development process are decided through a process of negotiation
during the software development process

Agile methods: (late 1990s)

• To reduce overheads in the software process (e.g. by limiting documentation) and to be able

分区 新分区 1 的第 29 页
 • To reduce overheads in the software process (e.g. by limiting documentation) and to be able
to respond quickly to changing requirements without excessive rework
• Focus on the code rather than the design
• Based on an iterative approach to software development
• Intended to deliver working software quickly and evolve this quickly to meet changing
requirements

Principles of agile methods:

Principle Description
Customer • Customers should be closely involved throughout the development
Involvement process
• Their role is provide and prioritize new system requirements and to
evaluate the iterations of the system
Incremental • The software is developed in increments with the customer specifying
Delivery the requirements to be included in each increment
People > Process • The skills of the development team should be recognized and exploited
Team members should be left to develop their own ways of working
without prescriptive processes
Embrace Change • Expect the system requirements to change and so design the system to
accommodate these changes
Maintain • Focus on simplicity in both the software being developed and in the
Simplicity development process
• Wherever possible, actively work to eliminate complexity from the system

Agile method applicability:

• Product development where a software company is developing a small or medium-sized
product for sale
○ Virtually all software products and apps are now developed using an agile approach
• Custom system development within an organization, where there is a clear commitment from
the customer to become involved in the development process and where there are few
external rules and regulations that affect the software

Applying agile methods in organizations:

• Project managers who do not have experience of agile methods may be reluctant to accept
the risk of a new approach
• Large organizations often have quality procedures and standards that all projects are
expected to follow and, because of their bureaucratic nature, these are likely to be
incompatible with agile methods
• Agile methods seem to work best when team members have a relatively high skill level.
However, within large organizations, there are likely to be a wide range of skills and abilities
• There may be cultural resistance to agile methods, especially in those organizations that have
a long history of using conventional systems engineering processes

Extreme programming: (late 1990s)

Extreme Programming (XP) takes an 'extreme' approach to iterative development:
○ New versions may be built several times per day
○ Increments are delivered to customers every 2 weeks
○ All tests must be run for every build and the build is accepted only if tests run
successfully
• Release cycle:

分区 新分区 1 的第 30 页
 • Practices:
Principle or Description
practice
Incremental Requirements are recorded on story cards and the stories to be
Planning included in a release are determined by the time available and their
relative priority. The developers break these stories into development
'Tasks'
Small The minimal useful set of functionality that provides business value is
Releases developed first. Releases of the system are frequent and incrementally
add functionality to the first release
Simple Design Enough design is carried out to meet the current requirements and no
more
Test-first An automated unit test framework is used to write tests for a new
Development piece of functionality before that functionality itself is implemented
Refactoring All developers are expected to refactor the code continuously as soon
as possible code improvements are found. This keeps the code simple
and maintainable
Pair Developers work in pairs, checking each other’s work and providing
Programming the support to always do a good job
Collective The pairs of developers work on all areas of the system, so that no
Ownership islands of expertise develop and all the developers take responsibility
for all of the code. Anyone can change anything
Continuous As soon as the work on a task is complete, it is integrated into the
Integration whole system. After any such integration, all the unit tests in the system
must pass
Sustainable Large amounts of overtime are not considered acceptable as the net
Pace effect is often to reduce code quality and medium term productivity
On-Site A representative of the end-user of the system (the customer) should
Customer be available full time for the use of the XP team. In an extreme
programming process, the customer is a member of the development
team and is responsible for bringing system requirements to the team
for implementation

User stories for requirements:

• In XP, a customer or user is part of the XP team and is responsible for making decisions on
requirements
• User requirements are expressed as user stories or scenarios
○ These are written on cards and the development team break them down into
implementation tasks
○ These tasks are the basis of schedule and cost estimates
• The customer chooses the stories for inclusion in the next release based on their priorities
and the schedule estimates
• E.G.
User story:

分区 新分区 1 的第 31 页
 ○ User story:

○ Task cards:

Refactoring:
• Conventional wisdom in software engineering is to design for change. It is worth spending
time and effort anticipating changes as this reduces costs later in the life cycle
XP, however, maintains that this is not worthwhile as changes cannot be reliably
anticipated
• XP proposes constant code improvement (refactoring) to make changes easier when they
have to be implemented
Programming team look for possible software improvements and make these
improvements even where there is no immediate need for them
• This improves the understandability of the software and so reduces the need for
documentation
• Changes are easier to make because the code is well-structured and clear
• However, some changes requires architecture refactoring and this is much more expensive
• E.G.
○ Re-organization of a class hierarchy to remove duplicate code
○ Tidying up and renaming attributes and methods to make them easier to understand
○ The replacement of inline code with calls to methods that have been included in a
program library

Test-first development:
• Testing is central to XP and XP has developed an approach where the program is tested after
every change has been made
• XP testing features:
○ Test-first development
○ Incremental test development from scenarios
○ User involvement in test development and validation
Automated test harnesses are used to run all component tests each time that a new
分区 新分区 1 的第 32 页
 ○
○ Automated test harnesses are used to run all component tests each time that a new
release is built
• Writing tests before code clarifies the requirements to be implemented
• Tests are written as programs rather than data so that they can be executed automatically
○ The test includes a check that it has executed correctly
○ Usually relies on a testing framework such as Junit
• All previous and new tests are run automatically when new functionality is added, thus
checking that the new functionality has not introduced errors
• E.G. (Test case description for dose checking)

Test automation:
• Test automation means that tests are written as executable components before the task is
implemented
○ These testing components should be stand-alone, should simulate the submission of
input to be tested and should check that the result meets the output specification
○ An automated test framework (e.g. Junit) is a system that makes it easy to write
executable tests and submit a set of tests for execution
• As testing is automated, there is always a set of tests that can be quickly and easily executed
○ Whenever any functionality is added to the system, the tests can be run and problems
that the new code has introduced can be caught immediately

Customer involvement in testing:

• The role of the customer in the testing process is to help develop acceptance tests for the
stories that are to be implemented in the next release of the system
○ The customer who is part of the team writes tests as development proceeds. All new
code is therefore validated to ensure that it is what the customer needs
• However, people adopting the customer role have limited time available and so cannot work
full-time with the development team. They may feel that providing the requirements was
enough of a contribution and so may be reluctant to get involved in the testing process

Pair programming:
• In pair programming, programmers sit together at the same computer to develop the software
• Helps develop common ownership of code and spreads knowledge across the team
○ The sharing of knowledge that happens during pair programming is very important as it
reduces the overall risks to a project when team members leave
• It serves as an informal review process as each line of code is looked at by more than 1 person
• Pairs are created dynamically so that all team members work with each other during the
development process
• Pair programming is not necessarily inefficient and there is some evidence that suggests that a
pair working together is more efficient than 2 programmers working separately

分区 新分区 1 的第 33 页
Scrum:
An agile method that focuses on managing iterative development rather than specific agile
practices
• Three phases in Scrum:
○ Outline planning phase:
▪ Establish the general objectives for the project
▪ Design the software architecture
○ Sprint cycles:
▪ Each cycle develops an increment of the system
○ Wrap-up:
▪ Completes required documentation
□ E.G.
System help frames and user manuals
▪ Assesses the lessons learned from the project

Scrum terminology:
Scrum term Definition
Development • A self-organizing group of software developers, which should be <= 7
team people
• Responsible for developing the software and other essential project
documents
Potentially • The software increment that is delivered from a sprint
shippable • "potentially shippable" means that it is in a finished state and no further
product work, such as testing, is needed to incorporate it into the final product
increment • In practice, this is NOT always achievable
Product • A list of "to do" items which the Scrum team must tackle
backlog • The single source of requirements for any changes to be made to the
product
• May be feature definitions for the software, software requirements, user
stories or descriptions of supplementary tasks that are needed, such as
architecture definition or user documentation
Product • An individual (or a small group) who identifies product features or
owner requirements, prioritize these for development and continuously review
the product backlog to ensure that the project continues to meet critical
business needs
• Can be a customer but might also be a product manager in a software
company or other stakeholder representative
Scrum • A daily meeting of the Scrum team that reviews progress and prioritizes
work to be done that day
• Ideally, this should be a short face-to-face meeting that includes the whole
team
ScrumMaster • Responsible for ensuring that the Scrum process is followed and guides the
team in the effective use of Scrum
• Responsible for interfacing with the rest of the company and for ensuring
that the Scrum team is not diverted by outside interference
• Scrum developers are adamant that the ScrumMaster should not be
thought of as a project manager. Others, however, may not always find it
easy to see the difference
Sprint • A development iteration
• Sprints are usually 2-4 weeks long
Sprint backlog • The set of Product Backlog items (PBls) selected for the Sprint, plus a plan
for delivering the product increment and realizing the Sprint Goal
• The sprint backlog is unchanged during the period of the Sprint
• Items not "Done" by end of the Sprint will be added back to the Product
分区 新分区 1 的第 34 页
 • Items not "Done" by end of the Sprint will be added back to the Product
Backlog and addressed during the next Sprint
• Any improvements needed can be put back to the Product Backlog:
Either add additional Sprints to the schedule or remove lower priority
items from the Product Backlog
Velocity • An estimate of how much product backlog effort that a team can cover in a
single sprint
• Understanding a team’s velocity helps them estimate what can be
covered in a sprint and provides a basis for measuring improving
performance

The Scrum Sprint Cycle:

• Sprints are fixed length, normally 2-4 weeks
• Starting point for planning:
Product backlog, the list of work to be done on the project
• Selection phase:
○ Involves all of the project team who work with the customer to select the features and
functionality from the product backlog to be developed during the sprint
○ Once these are agreed, the team organize themselves to develop the software
• The Sprint cycle:
○ During this stage the team is isolated from the customer and the organization, with all
communications channelled through ScrumMaster
○ The role of the Scrum master is to protect the development team from external
distractions
○ At the end of the sprint, the work done is reviewed and presented to stakeholders
○ The next sprint cycle then begins

Teamwork in Scrum:
• The ‘Scrum master’ is a facilitator who arranges daily meetings, tracks the backlog of work
to be done, records decisions, measures progress against the backlog and communicates with
customers and management outside of the team
• The whole team attends short daily meetings (Scrums) where all team members share
information, describe their progress since the last meeting, problems that have arisen and
what is planned for the following day
This means that everyone on the team knows what is going on and, if problems arise,
can re-plan short-term work to cope with them.

Scrum benefits:
• The product is broken down into a set of manageable and understandable chunks
• Unstable requirements do NOT hold up progress
• The whole team have visibility of everything and consequently team communication is
improved
• Customers see on-time delivery of increments and gain feedback on how the product works
• Trust between customers and developers is established and a positive culture is created in
which everyone expects the project to succeed.

分区 新分区 1 的第 35 页
LEC-10 UMLs
2024年9月9日 14:14

Requirement Elicitation and Analysis Process:

• E.G. (A security door access system)

1. A door access system is needed to allow employees to enter a secure area using their
fingerprint
2. When an employee needs to open the door he/she must place their index finger on a
fingerprint reader located beside the door
3. The scanned fingerprint is compared and validated against a company database of
employee fingerprints
4. If a fingerprint match is found the message “Please enter” is displayed and the door is
opened to allow the employee to enter
5. If the fingerprint match fails the message “Access Denied” is displayed and the access
system reverts to waiting for a new fingerprint to scan
6. Every time a door access is attempted a record log is maintained. The information
recorded for a successful access is the Time of Access and the name of employee
allowed access. The information recorded for a failed access is the Time of Unsuccessful
Attempted Access
7. The company’s Human Resources department maintains a database of employee
fingerprints. These are collected once during the new employee enrolment process and
are removed when an employee leaves the company
8. The Human Resources department can view the record log of accesses and attempted
accesses and update the employees fingerprint data if necessary
I. Generate initial Use Case diagram
i. Identify the Actors

分区 新分区 1 的第 36 页
 ii. Identify the main Use Cases (action verbs)
II. Generate initial Use Case descriptions

III. Refine Use Case model

Questions will arise as detailed Use Cases are written. These need to be clarified
with the customer reflected in changes in the Use Case diagrams and descriptions
▪ E.G.
 What is the detailed process when a fingerprint is validated?
 What if the gate is opened and no one enters?
 What if the gate is opened and does not close?
 Is there a timeout?
 What if more than one person enters?
 Is there a particular format the Employee data is to be recorded in the
log?
 Does it need to be exported to another system or printed?
i. Refine the main Use Cases

分区 新分区 1 的第 37 页
 ii. Refine Use Case descriptions
□ E.G.
ValidateDoorEntry Use Case Description
Flow of Events:
1. Employee presses finger on FingerprintReader.
2. FingerprintReader scans fingerprint (using use case Scan
fingerprint) and sends image to the FacilityAccessManager.
3. The FacilityAccessManager validates the fingerprint
4. If fingerprint is valid display the message “Please enter” and
unlock the EntryGate.
1. 4.1 The EntryGate sends a signal to the
FacilityAccessManager that it has opened and closed.
2. 4.2 The FacilityAccessManager locks the EntryGate, and
logs the entry time and name of the employee who
entered in the entry log.
Alternative Flow:
1. AF-S4. If fingerprint is not valid display the message “Access
denied” and log the attempted entry time in the entry log.
IV. Generate Class Diagram
i. Identify Classes

ii. Add properties and operations

分区 新分区 1 的第 38 页
 V. Add Sequence Diagrams

VI. Add State Diagrams

▪ E.G. (FingerprintReader)

VII. Add Activity Diagrams

▪ E.G. (ValidateDoorEntry Use Case)

分区 新分区 1 的第 39 页
VIII. Review Requirements and Refine Use Cases & Diagrams
▪ Iteratively refine the Class Diagram and Sequence Diagram
▪ This may involve some refinement of the Use Cases
▪ Repeat until the Functional Requirements of the System are fully specified

分区 新分区 1 的第 40 页
LEC-11 Data Access Object Pattern
Tuesday, 1 October 2024 1:24 pm

Data Access Object Pattern:

Used to separate low level data accessing API or operations from high level business services
• DAO layer is responsible for Data access from persistence storage and manipulation of Data in
the persistence storage
• Decouple the persistent storage implementation from the rest of your app

分区 新分区 1 的第 41 页
LEC-12 System Architecture Design
2024年9月30日 19:39

Software Architecture: {Components, Connectors}

Software architecture involves the description of elements from which systems are built,
interactions along those elements, patterns that guide their composition, and constraints on
these patterns.
• Components:
A unit of software that performs some functions at run-time
○ E.G.
programs, objects, processes, clients, servers, databases
• Connectors:
Interactions among components:
Communication, coordination, or cooperation among components
○ E.G.
Shared variable access, procedure calls, remote procedure calls, communication
protocols, data streams, transaction streams
○ Implementations of connectors are usually distributed over many system components
often do NOT correspond to discrete elements of the running systems.
• Note:
○ Architecture is abstract:
▪ The details of the components and connectors are hidden
○ Architecture is about structure and interactions:
▪ Focus on the topology
▪ Components
▪ Data and control communication
○ Architecture is purposeful:
▪ Demonstrate or analyse the properties of interest
▪ Design documentation, as transferable knowledge about software design,
evaluation, and so on
• E.G. (WWW Client-Server Architecture)

How to develop a system architecture:

• Functional Requirement:
○ E.G.
▪ Dynamic Models
▪ Analysis Object Models
• Non-functional Requirement:
○ E.G.
▪ Efficiency
▪ Reliability
▪ Robustness

分区 新分区 1 的第 42 页
 ▪ Robustness
▪ Security
▪ Maintainability
• Design Principles:
○ E.G.
▪ Modularity
▪ Abstraction
▪ Open-Closed
▪ Reusability
• Design Patterns:
○ E.G.
▪ Layered Architecture
▪ Client and Server
▪ Data Centered
• Constraints:
○ E.G.
▪ Languages
▪ Libraries
▪ Communications

Software Architectural Styles:

Defines a family of systems in terms of a pattern of structural organization:
○ A set of component types:
▪ Filters in pipe-and-filter styles

▪ MVC

○ A set of connectors:
▪ Subroutine calls, remote procedure calls, data streams, and sockets
○ A topological structure
○ A set of semantic constraints:
▪ Specifies how to determine a system's overall properties from the properties of its
parts
▪ Filters in a pipe-and-filter architecture do not share states with each other
▪ One layer can only call the service provided by the lower layer in a layered system
• One of the hallmarks of software architectural design is the use of idiomatic patterns of
system organization
• Ambiguity in a Software Architectural Style:
○ Number of components involved:
▪ E.G. (pipe-and-filter architecture)
□ 2 filters connected by 1 pipe; or
□ 20 filters connected by 19 pipes
○ Mechanism of interaction:
▪ E.G. (layered system)
□ The call to the lower layer can be:

分区 新分区 1 的第 43 页
 □ The call to the lower layer can be:
local procedure calls, or remote procedure calls, or other process
communication mechanisms
○ Function of the system and components:
One of the components in an architectural style may be a database, but the kind
of data may vary

Catalogue of Software Architectural Styles:

• Independent components:
○ Communicating processes – client & server
○ Event systems:
▪ Implicit invocation
▪ Explicit invocation
• Data flow:
○ Batch sequential
○ Pipe-and-filter
• Data-centered:
○ Repository
○ Blackboard
• Virtual machine:
○ Interpreter
○ Rule-based system
• Call and return:
○ Main program and subroutine
○ Object-oriented
○ Layered system

Pros and Cons of Independent Components:

• Pros:
○ Modifiability by decoupling the computation
○ Concurrent execution
○ Scalability
○ Easy integration
• Cons:
○ Components are independent
▪ Message received?
▪ Solution: complicated protocols
○ Correctness is hard to achieve

Layered Architecture:
• Pros:
○ Better security
○ Scalability
○ Simple maintenance
○ Easily enhanced
• Cons:
○ Dependency Issue:
One layer can only call the service provided by the lower layer
• E.G. (3-Layered Arch)

分区 新分区 1 的第 44 页
 • E.G. (Android)

Generic Process Model of Designs:

分区 新分区 1 的第 45 页
LEC-13 Object Design Patterns
Tuesday, 1 October 2024 12:20 pm

Object Design:
• Interface Specification:
Operations, arguments, type signatures, and exceptions
• Reuse:
Existing libraries and Design Patterns
• Restructuring:
To meet the design goal maintainability, flexibility…
• Optimization:
Speed or memory

Design Pattern:
A proven solution to a problem in a context
• Abstracts a recurring design structure
• A template with class and/or object:
○ Dependencies
○ Structures
○ Interactions; or
○ Conventions
• Four Elements of a Design Pattern:
○ Name:
Describes the pattern
▪ Adds to common terminology for facilitating communication (i.e. not just sentence
enhancers)
○ Problem:
Describes when to apply the pattern
○ Solution:
Describes elements, relationships, responsibilities, and collaborations which make
up the design
○ Consequences:
Results of applying the pattern

分区 新分区 1 的第 46 页
 Results of applying the pattern
▪ Benefits and Costs
▪ Subjective depending on concrete scenarios

Gang of Four (GoF) Patterns:

• Creational Patterns:
○ Abstract Factory
○ Builder
○ Factory Method
○ Prototype
○ Singleton
• Structural Patterns:
○ Adapter
○ Bridge
○ Composite
○ Decorator
○ Façade
○ Flyweight
○ Proxy
• Behavioural Patterns:
○ Chain of Responsibility
○ Command
○ Interpreter
○ Iterator
○ Mediator
○ Memento
○ Observer
○ State
○ Strategy
○ Template Method
○ Visitor

Strategy Pattern:
• Design Problem:
A set of algorithms or objects should be interchangeable
• E.G.

• Pros:
○ Provides encapsulation
○ Hides implementation
○ Allows behavior change at runtime
• Cons:
○ Results in complex, hard to understand code if overused

Observer Pattern (AKA Subscriber-Publisher / Consumer-Producer Pattern):

• Design Problem:
When you need many objects (observers) to receive an update when another object
(subject) changes
○ Subject does NOT know/care about who the observers are / how many observers there
are / how observers will do with the changes

分区 新分区 1 的第 47 页
 are / how observers will do with the changes
○ Observer does NOT constantly check the changes
○ Defines a one-to-many dependency between objects so that when one object changes
state, all of its dependents are notified and updated automatically
▪ Easy Subscription and Automatic Notification
• How:
○ Subscription mechanism:
▪ Observers freely register/unregister their interests in Subject
○ Notification mechanism:
▪ Subject propagates the change to Observer when the change occurs
• Pros:
○ Abstracts coupling between Subject and Observer
○ Supports broadcast communication
○ Enables reusability of subjects and observers independently of each other
• Cons:
○ Slower performance
○ If not used carefully the observer pattern can add unnecessary complexity
• Pull Update Template:

• Push Update Template:

• Pull + Push Update Template:

分区 新分区 1 的第 48 页
• Pull Update vs Push Update:
○ Pull update:
▪ Subject sends simple notification (via Observer.update())
▪ The Observer calls back (via Subject.getData()) for details explicitly (if
Observer is interested)
▪ Two way communication
○ Push update:
▪ Subject sends detailed information about the change (or update), regardless of
Observer wants it (interested) or not
▪ Observer does NOT need to call back
▪ One way communication
• Interest Subscription + Selective Notification Template:

• Event Handling:
An implementation of observer pattern
○ E.G. (Java Swing Event Handling)

分区 新分区 1 的第 49 页
分区 新分区 1 的第 50 页
LEC-14 Factory & Façade Design Patterns
2024年10月9日 14:46

Factory Pattern (AKA Static Factory Pattern):

Defines an interface for creating different objects, without knowing beforehand what type of
objects it needs to create or how the object is created
Let subclasses decide which class to instantiate
○ Greater flexibility in object creation
• What To Do When System Starts Up (no factory):
Create objects, and associate them up according to the class diagram

• When To Use?
○ When you have a set of classes but don't know exactly which one to instantiate until
runtime
○ When you need to create one of several classes that implement a common superclass
without exposing the creation logic to the client
○ When you want to localize the logic to instantiate objects
• Design Problems:
Decouple class selection and object creation (abstract instantiation process) from the
client where the object is used
○ Existing subclasses can be replaced, and new subclasses can be added
○ Process of selecting subclass to use and creating object can be complex
○ Client does not know in advance which class will be used, and the class can be chosen at
runtime
• "Standard" Version (Template):
Context uses StaticFactory to obtain an object that implements
AbstractProduct interface

○ E.G.

分区 新分区 1 的第 51 页
• Benefits:
○ Encapsulate object creation:
▪ Remove duplicate object creation code from clients
▪ Centralize class selection and object creation code
○ Easy to extend, replace, or add new subclasses:
▪ Replace MySQLImpl1 with MySQLImpl2
▪ Support new OracleImpl
○ Easy to change object creation logic:
▪ Support Singleton单例 object
▪ Support lazy initialization
• Strategy + Factory + Dynamic Loading:
○ Create any subclass object without specifying the class name in the code
○ No need to change a single line of code to use new classes
○ Provide the foundation for modern software frameworks to load application-specific
classes
○ E.G. (Extending Eclipse IDE)

○ E.G. (Java Swing Framework LookandFeel)

分区 新分区 1 的第 52 页
 ○ E.G. (JDBC Database Driver)

Façade Pattern:
Provides a unified interface for a set of interfaces in a subsystem
Defines a higher level interface that makes the subsystem easier to use

• Design Principles:
○ Identify the aspects of your application that vary then separate them from what stays
the same
○ Program to an interface, not an implementation
○ Favor composition over inheritance
○ Strive for loosely coupled designs between objects that interact
○ Classes should be open for extension, but closed for modification
○ Principle of least knowledge – talk only to your immediate friends
• Pros:
Makes code easier to use and understand

分区 新分区 1 的第 53 页
 ○ Makes code easier to use and understand
○ Reduces dependencies on classes
○ Decouples a client from a complex system
• Cons:
○ Results in more rework for improperly designed Façade class
○ Increases complexity and decreases runtime performance for large number of Façade
classes
• E.G.
○ Non-Façade:

○ Façade:

分区 新分区 1 的第 54 页
LEC-15 MVC Design Pattern
2024年10月9日 15:56

Interactive Event-Driven Systems:

• Design Challenges:
○ UIs are prone to change:
▪ The same data can be presented differently (Observer Pattern)
▪ Changes to UI must be easy and even possible at runtime (Observer Pattern)
▪ The application display and behavior must reflect data changes immediately
(Observer Pattern)
▪ The same presentation can have different look and feel (Strategy Pattern -
interchangeability)
▪ The application reacts to user input differently (Strategy Pattern -
interchangeability)
○ UI should NOT be tightly coupled with core functionality and data in order to allow for
the above changes
• E.G. (Excel)
○ Excel Layered Architecture (w/o observer pattern):

○ Excel needs many views to receive an update when worksheet changes

▪ Loose coupling between an worksheet (subject) and its dependent views
(observers)

○ Update Worksheet:

分区 新分区 1 的第 55 页
Model-View-Controller (MVC) Architecture:
• Main Goal:
○ To facilitate and optimize the implementation of interactive intensive systems,
particularly those that use multiple synchronized presentations of shared information
• Key Idea:
○ The separation of the Model from View and Controller components allows multiple
Views of the same Model
It separates presentation and interaction from the data
▪ If the user changes the Model via the Controller of one View, all other Views
dependent on this data should reflect the changes
• Separation of UI from the core data model:
○ Need to support multiple different UI's and core functionality should be reusable across
all different interfaces
▪ E.G.
desktop GUI, browser, PDA, cell phone, etc.
○ Interface details changes frequently:
▪ Changing UI details should not affect core functionality
○ It should be easy to add a new UI
• MVC Components:
○ Encapsulate core Functionality (App Logic) + Data in Model
○ Implement UI in View (present data) + Controller (react to user input)
Model Contains the processing (operations) and the data involved
View Presents the output – Defines and manages how the data is presented to
the user
• Each View provides specific presentation of the same Model
• Each View "observes" the Model Whenever the data Model changes,
all Views immediately notified and so they can update their graphical
presentation
Controller Manages user interaction – Captures user input (events -> mouse clicks,
key presses, etc.) and passes these interactions to the View and the Model
• Each View is associated to a Controller that captures and processes
user input and modifies the data Model
• The user interacts with the system solely through Controllers
• Controllers typically implement event-handling mechanisms that are executed when
corresponding events occur
• Changes made to the Model by the user via Controllers are directly propagated to the

分区 新分区 1 的第 56 页
• Changes made to the Model by the user via Controllers are directly propagated to the
corresponding Views
The change propagation mechanism can be implemented using the observer pattern
(via subscribe/notify protocol)
• MVC architecture style is non-hierarchical (triangular):
○ View subscribes for changes to the Model (via Observer subscription mechanism)
○ Controller gathers input (or change) from the users and updates the Model
○ Model updates the change and notifies all subscribers (the Views) of the change (via
Observer notfication mechanism)
○ View is notified and updates its display; the user sees the change
• Design Patterns in MVC:
○ Observer Pattern (View-Model, Controller-Model):
▪ Model uses the Observer Pattern to keep the View(s) updated
▪ When Model (Subject) data is changed, it updates all the Views (Observers, via
notification mechanism)
▪ Allows multiple Views to the same Model
○ Strategy Pattern (View-Controller, View-Look & Feel):
▪ View and Controller use the Strategy Pattern as the View is concerned with the
visual aspects (display data) and delegates the interface behaviors to the
Controller
▪ The View (Context) uses the Controller (Strategy Interface) to implement a specific
type of response (or strategy objects)
▪ The Controller can be changed to allow View to respond differently to user input
○ Abstract Factory:
▪ Create Controller or Look & Feel for a View
○ Composite:
▪ Nested views
▪ E.G.
Panel containing Button; Nested Panels
○ Decorator:
▪ Attach additional UI functionalities to a view
▪ E.G.
Scrolling
○ Command:
▪ Support undo/redo user actions

• E.G. (Excel MVC Architecture)

分区 新分区 1 的第 57 页
• Pros:
○ Simultaneous development
○ Multiple views for a model
○ High cohesion:
▪ MVC enables logical grouping of related actions on a controller together
The views for a specific model are also grouped together
○ Low coupling:
▪ The very nature of the MVC framework is such that there is low coupling among
models, views or controllers
• Cons:
○ Code navigability and pronounced learning curve:
▪ The framework navigation can be complex because it introduces new layers of
abstraction and requires users to adapt to the decomposition criteria of MVC
○ Multi-artifact consistency:
▪ Decomposing a feature into three artifacts causes scattering
▪ Thus, requiring developers to maintain the consistency of multiple representations
at once

分区 新分区 1 的第 58 页
LEC-16 Testing
Tuesday, 15 October 2024 9:44 am

Software Bug:
An error, flaw, failure or fault in a computer program or system that causes it to produce an
incorrect or unexpected result, or to behave in unintended ways

Testing:
• To show the presence of bug
• To reduce the perceived risk of system not working to an acceptable value
• To result in low-risk software without much testing effort
• NOT to show the absence of bug
• NOT equals debugging
• NOT to show that software works

Levels Of Testing:
• Unit testing:
Test an unit individually
• Integration testing:
Test units in combination
• System testing:
Test everything (functionality, usability, reliability, performance, portability, security, ...)
• Acceptance testing (UAT, User Acceptance Testing):
Customer accepts the software and give us money

Types Of Testing:
• Black Box Testing:
○ What to analyze:
Requirements and specifications
▪ E.G.
"The income of an applicant must be between $1500 and $8000 per month"
○ Black Box Testing Process:
• The tester:
1. Analyzes requirements or specifications
equivalence classes and boundary values
2. Chooses valid inputs and invalid inputs
3. Determines expected outputs (oracle) for chosen inputs
4. Constructs tests with the chosen inputs
▪ E.G.
write JUnit program
• The testing engine:
1. Executes the tests
2. Compares actual outputs (log) with the expected outputs (oracle)
3. Determines whether the SUT (System Under Test) functions properly
○ Types of black box testing:
▪ Equivalence class testing and boundary value testing
▪ State-based testing
○ Applicability:
All testing levels (Unit, Integration, System, Acceptance)
○ Pros:
○ Directs the tester to a very small subset of test inputs that can highly likely find the
bugs
○ Cons:
○ Cannot know how much of the implementation have been tested
○ No notion of testing coverage like in white box testing
• White Box Testing:

分区 新分区 1 的第 59 页
 • White Box Testing:
○ What to analyze:
Implementation details, internal paths and structure
○ White Box Testing Process:
• The tester:
1. Analyzes SUT's (System Under Test) implementation
▪ Control Flow Graph or Data Flow Graph
2. Identify execution paths through the SUT
3. Chooses inputs to cause the SUT to execute selected paths
4. Determines expected outputs (oracle) for chosen inputs
5. Constructs tests with the chosen inputs
• The testing engine:
1. Executes the tests
2. Compares actual outputs (log) with the expected outputs (oracle)
3. Determines whether the SUT (System Under Test) functions properly
○ Type of white box testing:
▪ Basis Path Testing (Control flow testing, structured testing)
▪ Data flow testing
○ Applicability:
All testing levels (Unit, Integration, System, Acceptance)
○ Pros:
○ Ensure that every path through the SUT has been identified and tested
○ Cons:
○ Testing all execution paths is generally infeasible
▪ E.G.
loop, number of decision points
○ May not detect data and arithmetic bugs
▪ E.G.
a = a - 1 // should be a = a + 1
a/b // b cannot be zero
○ Never find paths that are not implemented
▪ E.G.
paths in requirements are missing in implementation

Elements of Test Cases:

• Name:
Distinct name of test case
• Location:
Path to test program and its inputs
• Input:
Input data or commands
• Oracle:
Expected test output
• Log:
Actual output produced by the test
• E.G. (Mortgage App)

• E.G. (Android Unit Test Case)

分区 新分区 1 的第 60 页
 • E.G. (Android Unit Test Case)

Order Of Test Case Execution:

• Cascading test cases:
○ Smaller and simpler test cases
○ One fails, the subsequent test may be invalid
○ E.G.
1. Create an order
2. Read the order
3. Update the order
4. Delete the order
5. Read the deleted order
• Independent test cases:
○ Parallel test execution
○ NOT for larger and more complex test cases
○ E.G.
Self-contained test cases for the above features

分区 新分区 1 的第 61 页
LEC-17 Equivalence Class Testing
2024年10月21日 20:21

Defensive Testing:
Create test cases for both valid and invalid inputs
▪ NEVER assume that users will use your code in your expected way
▪ Test the module to see whether it behaves as expected for invalid inputs
i.e. NOT cause unexpected errors or abnormal behavior (sudden program termination)

Equivalence Class Testing:

• Assumptions:
1. Verifiable requirements and API specification exists
▪ Make software more testable from its inception
▪ E.G. (unverifiable requirements)
□ The company must not hire too-young or too-old people
□ The company can hire juniors on part-time basis
□ The company can hire adult as full-time employees
2. Code must be testable
▪ E.G. (untestable code)
□ if (age==0) hire=NO;
if (age==1) hire=NO;
...
if (age==16) hire=PART;
if (age==17) hire=PART;
if (age==18) hire=FULL;
...
□ if (age==35 && name==“xingzc”) hire=CEO;
if (age==35 && name!=“xingzc”) hire=FULL;
• Equivalence Classes:
A set of input values forms an equivalence class (EC) if:
▪ They all are supposed to produce the same output
▪ If one value catches a bug, the others probably will too
▪ If one value does not catch a bug, the others probably will not either
○ E.G.
▪ Requirements:
0 - 15, 55 - 99 Do not hire
16 - 17 Part-time
18 - 54 Full-time
▪ Valid equivalence classes:
□ 0 ≤ age ≤ 15 (do not hire)
□ 16 ≤ age ≤ 17 (hire part-time)
□ 18 ≤ age ≤ 54 (hire full-time)
□ 55 ≤ age ≤ 99 (do not hire)
▪ Invalid equivalence classes:
□ age ≤ -1
□ age ≥ 100
▪ Test only one value for each valid equivalence class, one invalid value below 0, and
one invalid value above 99
• Testing Process (tester):
1. Identify the valid and invalid equivalence classes that partition the input values
2. Choose at least one input values for each equivalence class of each input parameter
3. Determine expected outputs (oracle) for chosen inputs
4. Construct tests with the chosen inputs
• Design Test Cases Using ECs:

分区 新分区 1 的第 62 页
• Design Test Cases Using ECs:
1. Test valid inputs of several parameters at the same time
i.e. each test case can have multiple valid inputs
▪ Choose one valid input for each input parameter from an equivalence class
2. Test ONLY one invalid input from an equivalence class of one input parameter at the
same time
i.e. each test case should have no more than one invalid input
▪ Choose valid inputs from an equivalence class of all other input parameters
▪ In this way we can focus on the only possible error caused by the single invalid
input
▪ E.G. (inappropriate test case)

• Test Valid Inputs Using ECs:

○ You may test valid input values of several input parameters at the same time
○ You may create test cases for all the values in an valid equivalence class if the set of
valid values in the equivalence class is small
○ E.G.
▪ The number of mortgages (0, 1, 2, 3, 4, 5)
▪ Property type (HDB, Condo)
▪ NOT for income range, or characters of password

• Test Invalid Inputs Using ECs:

○ You must test ONLY one invalid input value from an equivalence class of one input
parameter per test case
○ You may create test cases for all the values in an invalid equivalence class if the set of
invalid values in the equivalence class is small
○ E.G.

分区 新分区 1 的第 63 页
LEC-18 Boundary Value Testing
2024年10月24日 11:02

Boundary Value Testing (BVT):

Focus on boundaries of the equivalence classes of range of values
• Select a minimal set of valid and invalid inputs (values on-the-boundary [valid input], just-
below, or just-above boundaries [invalid inputs]) to test
• Applicable Scope:
BVT is ONLY applicable to continuous values (range of values)
• Testing Process:
○ The tester:
1. Identify the lower and upper boundaries of equivalence classes of the range-of-
values parameters
2. Choose three input values for each boundary:
□ One values on-the-boundary, one value just-below and one value just-
above
□ Just-below and just-above values are relative to the value's unit
□ No need to duplicate the test cases if the just-below or just-above values fall
into other ECs (including current EC)
3. Determines expected outputs (oracle) for chosen inputs
4. Constructs tests with the chosen inputs

E.G.1
Income range valid equivalence class (1500 ≤ x ≤ 80000):
○ Lower boundary: 1499, 1500, 1501
○ Upper boundary: 79999, 80000, 80001
○ Valid boundary values (on-the-boundary):
{1500, 80000}
○ Invalid boundary values (just-below and just-above):
{1499, 80001}

E.G.2
Number of mortgage valid equivalence class (0 ≤ x ≤ 5)
○ Lower boundary: -1, 0, 1
○ Upper boundary: 4 , 5, 6
○ Valid boundary values: {0, 5}
○ Invalid boundary values: {-1, 6}

E.G.3
Length of password valid equivalence class (4 ≤ x ≤ 8)
○ Lower boundary: 3, 4, 5
○ Upper boundary: 7, 8, 9
○ Valid boundary values: {4, 8}
○ Invalid boundary values: {3, 9}

E.G.4
0 - 15, 55 - 99 Do not hire
16 - 17 Part-time

分区 新分区 1 的第 64 页
 18 - 54 Full-time
Do not hire (0 ≤ age ≤ 15):
○ Lower boundary: -1, 0, 1
○ Upper boundary: 14, 15, 16
Part time (16 ≤ age ≤ 17):
○ Lower boundary: 15, 16, 17
○ Upper boundary: 16, 17, 18
Full time (18 ≤ age ≤ 54):
○ Lower boundary: 17, 18, 19
○ Upper boundary: 53, 54, 55
Do not hire (55 ≤ age ≤ 99):
○ Lower boundary: 54, 55, 56
○ Upper boundary: 98, 99, 100
• Valid boundary values: {0, 15, 16, 17, 18, 54, 55, 99}
• Invalid boundary values: {-1, 100}

Equivalence Class Testing vs. Boundary Value Testing:

• In one test case:
○ Test combination of valid inputs (i.e. on-the-boundary values), one from each EC; or
○ Test ONE invalid input from an EC combining with valid inputs from other ECs
• Possible input combinations of BV testing:
○ E.G. (two parameters A and B, each has a range of values)
1. Combination of valid inputs:
□ Valid A + Valid B
2. Combination of boundary values:
□ Valid A + Invalid B
□ Invalid A + Valid B

分区 新分区 1 的第 65 页
LEC-19 Control Flow Testing
2024年11月2日 18:43

Control Flow Graph (CFG):

A directed graph, consists of nodes and edges, where:
○ Each node represents a process block or a decision point
○ Each edge represents control flow
i.e. what happens after what
• E.G.
int computeP(int a, int b) {
1 int q, x, p;
2 q = 1;
3 x = 2;
4 if (a > 0) {
5 x = x + 1;
6 }
7 p = q / x;
8 if (b == 3) {
9 p = max(q, x);
10 }
11 return p;
12 }

Process Block:
A sequence of statements execute sequentially
• NOT contain if/while/for/switch/goto statements
They will manipulate the control flow and break the sequential execution
• Contains any number of sequentially executed statements in the process block
• One control flow edge directed into the process block
• One control flow edge directed out of the process block
• E.G.

Binary Decision Point:

分区 新分区 1 的第 66 页
Binary Decision Point:
Control flow can change at the decision point
• Two control flow edges directed out of the decision point:
○ True branch
○ False branch
• Loop back to the decision point from the last statement
• if statement:

• if-else statement:

• while statement:

• for statement:

N-ary Decision Point:

分区 新分区 1 的第 67 页
N-ary Decision Point:
Control flow can change at the decision point
• One control flow edge directed into the decision point
• N control flow edges directed out of the decision point
• switch statement:
○ E.G.

Execution Path Through the CFG:

A sequence of process blocks and decision points through the CFG of the program
• E.G. (computeP(int, int))
2 binary decision points
Total 2²= 4 execution paths

Code Coverage Levels:

• Level 1 - 100% Statement Coverage:
Create test cases such that all statements are executed at least once under test
i.e. Select execution path(s) to cover all the CFG nodes at least once
○ E.G.

分区 新分区 1 的第 68 页
 • Level 2 - 100% Branch Coverage:
Create test cases such that all branches (edges) directed out of the decision points are
executed at least once under test
▪ Binary decision points all evaluate to TRUE and FALSE outcome once for each
○ E.G.

• Level 3 - Basis Path Coverage:

Create test cases such that the minimum number of basis paths are executed at least
once under test
○ Basis Path (Linear Independent Path):
▪ Each basis path traverses at least one new control flow edge (i.e. at least one new
node) that has NOT been traversed before the path is defined
○ Basis Set:
A set of basis paths (linearly independent paths)
▪ The basis set is NOT unique
• Level 4 - 100% Path Coverage:
Create test cases such that all execution paths are executed at least once under test
○ May NOT be feasible in general
○ Every binary decision point doubles the number of paths
i.e.
○ Every loop multiplies the paths by the number of iterations

Basis Path Testing:

A white box testing method used for designing test cases intended to examine all possible
paths of execution in a program at least once
• An effective mechanism to deal with exponential combination of branches
• Basis Path Testing Process:
○ The tester:
i. Construct the control flow graph (CFG) of the SUT (System Under Test)
ii. Identifies execution paths through the CFG of the SUT
1) computes the CFG’s Cyclomatic Complexity (CC)
2) selects a set of CC basis paths to obtain linearly independent paths
iii. Chooses inputs to cause the SUT to execute selected paths
iv. Determines expected outputs (oracle) for chosen inputs

分区 新分区 1 的第 69 页
 iv. Determines expected outputs (oracle) for chosen inputs
v. Constructs tests with the chosen inputs
○ The testing engine:
i. Executes the tests
ii. Compares actual outputs (log) with the expected outputs (oracle)
iii. Determines whether the SUT (System Under Test) functions properly
• Cyclomatic Complexity of a CFG:
Measures how complex your program is in terms of the number of decision points
i.e. if/while/for/switch
CC = |edges| - |nodes| + 2
CC = |decision| + 1, if all decision points are binary
○ CC ∝ # of decision points ∝ # of basis paths to test
▪ E.G.
If the program has CC value 6, then the tester has to identify 6 basic paths to
test

E.G.1
CC = |edges| - |nodes| + 2 = 8 - 7 + 2 = 3
CC = |decision| + 1 = 2 + 1 = 3

1) Select a Set of Basis Paths:

i. Pick a "baseline" path:
▪ Reasonably "typical" path of execution
▪ Most important path from the tester's view

ii. Change the outcome of the one decision point

Keep the maximum number of other decision points the same

分区 新分区 1 的第 70 页
 2) Create a Test Case for Each Basis Path:
○ One set of basis paths:
▪ 2-3, 4, 5, 7, 8, 11 (Baseline)
▪ 2-3, 4, 7, 8, 11
▪ 2-3, 4, 5, 7, 8, 9, 11
○ Three test cases:
▪ a = 4; b = 2
▪ a = 0; b = 5
▪ a = 7; b = 3
• The basis set is NOT unique, but each basis set has the same number of basis paths:
○ Another set of basis path:
▪ 2-3, 4, 7, 8, 11 (Baseline)
▪ 2-3, 4, 5, 7, 8, 11
▪ 2-3, 4, 7, 8, 9, 11
○ Three test cases:
▪ a = 0; b = 0
▪ a = 1; b = 0
▪ a = 0; b = 3

E.G.2 (Contains Infeasible Execution Paths)

CC = |decision| + 1 = 2 + 1 = 3

分区 新分区 1 的第 71 页
 • Not All Basis Paths are Feasible:
○ One set of basis paths:
▪ 1, 2, 3, 4, 5, 6, 8 (Baseline)
▪ 1, 2, 4, 5, 6, 8 (infeasible)
▪ 1, 2, 3, 4, 5, 7, 8 (infeasible)
○ One feasible test case:
▪ a=4
▪ Infeasible basis path
▪ Infeasible basis path
• We need to minimize infeasible Basis Paths:
○ Another set of basis paths:
▪ 1, 2, 3, 4, 5, 6, 8 (Baseline)
▪ 1, 2, 4, 5, 6, 8 (infeasible)
▪ 1, 2, 4, 5, 7, 8 (change both decision points at the same time)
○ Two test case:
▪ a=4
▪ Infeasible basis path
▪ a=0

E.G.3 (Contains Loops)

• When selecting basis paths:
select loop only zero and once (no need to consider iteration)
• When selecting baseline paths:
select false branch first at loop decision point
i.e. do NOT enter the loop
• When choosing input values to execute the path, the real execution path may execute loop
several times

CC = |decision| + 1 = 2 + 1 = 3
Three basis paths:
○ 1, 2, 10 (Baseline, select false branch first)
○ 1, 2, 3, 4, 8, 2, 10
○ 1, 2, 3, 6, 8, 2, 10
Three test cases:

分区 新分区 1 的第 72 页
Three test cases:
○ n=0
○ n=1
○ n=4
Real execution paths:
○ 1, 2, 10
○ 1, 2, 3, 4, 8, 2, 10
○ 1, 2, 3, 4, 8, 2, 3, 4, 8, 2, 3, 4, 8, 2, 3, 6, 8, 2, 10

分区 新分区 1 的第 73 页
LEC-20 Software Maintenance
2024年11月5日 16:26

Causes of Maintenance Problems:

• Unstructured code:
○ E.G.
▪ Numerous GOTO statements (Spaghetti code): hard to read, understand, and
maintain
□ Improve by using structured programming such as IF-ELSE statements
▪ Poor and inconsistent naming, long procedures, strong coupling, weak cohesion,
deeply-nested IF statements, etc.
• Insufficient domain knowledge:
○ To gain a sufficient understanding of a system from its source code
○ The more spaghetti-like the code is, the less easy it becomes to disentangle it
• Insufficient documentation:
○ No documentation, out-of-date documentation, or insufficient documentation

Software Maintenance:
The process of modifying a software system after delivery to:
correct faults, improve performance or other attributes, or adapt to a changed
environment
• Changes are implemented by modifying existing system components and/or adding new
components to the system
• Maintenance Effort Distribution:

Types of Software Maintenance:

• Fault repairs:
Changing a system to fix bugs/vulnerabilities and correct deficiencies in the way meets
its requirements
• Environmental adaptation:
Maintenance to adapt software to a different operating environment
○ Changing a system so that it operates in a different environment from its initial
implementation
▪ E.G.
New computer, OS, etc.
• Functionality addition/modification:
○ Modifying the system to satisfy new requirements

Software Refactoring:
The process of making improvements to a program to slow down the structure and code
degradation through change. It means modifying a program to:
○ Improve its structure
○ Reduce its complexity
○ Make it easier to understand
• Refactoring does NOT change the behaviour or add functionalities to the software

分区 新分区 1 的第 74 页
 • Refactoring does NOT change the behaviour or add functionalities to the software
• Refactoring is a continuous process of improvement throughout the development and
evolution process
• Refactoring is intended to avoid the structure and code degradation that increases the costs
and difficulties of maintaining a system

Signals for Program Code Improvements:

• Duplicate code
• Long methods
• Large class
• Temporary field
• Switch (case) statements
• Lazy class
• Data clumping (same group of data reoccur in several places)
• Tight coupling of two classes

分区 新分区 1 的第 75 页