SELALE UNIVERSITY

COLLEGE OF NATURAL SCIENCE

DEPARTMENT OF COMPUTER SCIENCE

Software Engineering Tutorial

Tadesse Beyene (MSc)
Lecturer of Computer Science
Mobile: +251 913-1567-80
Email: [email protected]
1 Prepared by: Tadesse B. (MSc.) 05/08/2025
Course objectives
On completion of the course successfully, students will be
able to:
 Understand the basic principles of Software Engineering
 Write requirements specification documents
 Design a system, component, or process to meet desired needs.
 Verify and validate a Software system practice with effective
communication skill.
 Describe in detail the theory, concepts and methods pertaining to the UML.
 Create requirements using use case modeling concepts.
 Demonstrate conceptual and technical skills in the analysis, design and
implementation of a software system using Object Oriented Concepts.
 Employ tools and techniques for Object Oriented Software Engineering,
 Demonstrate an ability to adapt and solve problems in software
development
2 activities from specification to testing individually
SE Lecture Note 05/08/2025 and as part
of a team.
 SELALE UNIVERSITY
COLLEGE OF NATURAL SCIENCE
DEPARTMENT OF COMPUTER SCIENCE

Chapter-one

Introduction
3 SE Lecture Note 05/08/2025
Outline
Overview
The object-oriented paradigm
Object-Oriented concept and principles
Characteristics of OO Approach
Identify elements of an object model

4 SE Lecture Note 05/08/2025

 Software Processes
 These are four key process activities, These activities are:

 Software specifications: The functionality of the software and

constraints on its operation must be defined.
 Software development: The software to meet the requirement
must be produced.
 Software validation: The software must be validated to ensure that
it does what the customer wants.
 Software evolution: The software must evolve to meet changing
client needs.

5 SE Lecture Note 05/08/2025

 Cont. …
 Software engineering
It is a systematic approach for the development, operation and
maintenance of software system.
It is the combination of all the tools, techniques, and processes
that are used in SW production.
The main goal of SE is to develop a quality SW production which
satisfies users needs within budget and on time.

6 SE Lecture Note 05/08/2025

 Software Development Life Cycle (SDLC)
Stage1: Planning and requirement analysis
 Requirement Analysis is the most important and necessary stage in SDLC.
Stage2: Defining Requirements
 This is accomplished through "SRS"- Software Requirement Specification
document which contains all the product requirements to be constructed and
developed during the project life cycle.
Stage3: Designing the Software
This phase is the product of the last two, like inputs from the customer and
requirement gathering.
Stage4: Developing the project
The implementation of design begins concerning writing code.
Stage5: Testing
During this stage, unit testing, integration testing, system testing, acceptance
testing are done.
Stage6: Deployment
Once the software is certified, and no bugs or errors are stated, then it is
deployed.
7 SE Lecture Note 05/08/2025
 SDLC Models
 Software SDLC is a spiritual
model used in project
management that defines
the stages include in an
information system
development project, from
an initial feasibility study to
the maintenance of the
completed application.

8 SE Lecture Note 05/08/2025

 Cont. …
Waterfall Rapid Application Development
When to use SDLC Waterfall Model? Model
oA project is short When to use RAD Model?
oThe situation is calm oWhen the requirements are well-
oresources are well prepared & are known.
available to use. oWhen the technical risk is limited.
owhich modularized in 2-3 months of
Spiral Model
period.Model
Agile
When to use Spiral Model? When to use the Agile Model?
odeliverance is required to be
frequent. oWhen frequent changes are required.
oWhen the project is large oWhen a highly qualified and experienced
oWhen changes may require at
any time team is available.
oLarge and high budget projects oWhen project size is small.

9 SE Lecture Note 05/08/2025

 Cont. …
 Software Development approaches
 Conventional Approach
 Object oriented approach

 Conventional Approach
 Takes a distinct input-process-output view of requirements.
 Data are considered separately from the processes that transform
the data.
 System behaviour, although important, tends to play a secondary.
 Makes heavy use of functional decomposition (partitioning of the
DFD)

10 SE Lecture Note 05/08/2025

 Cont. …
 Object-oriented Approach:
 It is based on object technology that leads to reuse, and reuse
leads to faster software development and higher-quality
programs.
 Easier to maintain(because its structure is inherently decoupled)
 Reducing the propagation of side effect when change
occur(encapsulation).
 Easier to scale.

11 SE Lecture Note 05/08/2025

 Cont. …
 Three characteristics of OO systems make them unique
 Encapsulation
 Inheritance
 Polymorphism
 Class encapsulate data and the operations that work on the
data in a single package.
 This provides a number of important benefits:
 The internal implementation details of data and
procedures are hidden from the outside
world(information hiding)
 This reduces the propagation of side effects when
changes occur
12 SE Lecture Note 05/08/2025
Exercise
 Which is NOT a software characteristic?
A. Software does not wear out
B. Software is flexible
C. Software is not manufactured
D. Software is always correct
 Which of the following are umbrella activities of Software
Engineering.
A. Risk Management
B. Software quality assurance
C. Formal Technical Review
D. all of the mentioned

13 05/08/2025
Cont. ...
 Which software development methodology involves regular and
frequent communication b/n developers and stakeholders.
A. Waterfall
B. Agile
C. Iterative
D. Spiral
 If requirements are easily understandable and defined then which
model is best suited?
A. Spiral model
B. Waterfall model
C. Prototyping model
D. None of the above
14 SE Lecture Note 05/08/2025
Cont. …
 Which of these software engineering activities are not a part of
software processes ?
A. Software dependence
B. Software development
C. Software validation
D. Software specification

 Waterfall model is not suitable for ______

A. small projects
B. accommodating change
C. complex projects
D. none of the above
15 SE Lecture Note 05/08/2025
 SELALE UNIVERSITY
COLLEGE OF NATURAL SCIENCE
DEPARTMENT OF COMPUTER SCIENCE

CHAPTER TWO

Modelling with UML

16 SE Lecture Note 05/08/2025

Outline
Introduction
A Conceptual Model of the UML
An overview of UML Diagrams
 Use case diagram
 Class diagram
 Sequence diagram
 Activity diagram
 Deployment diagram

17 SE Lecture Note 05/08/2025

Introduction
Unified Modelling Language(UML)
UML is a model which has a collection of graphical notation.
A model is a simplification of reality and it helps to visualize
requirements, permit specifications, and document decision.
It is a language of visualizing, specifying, constructing and
documenting the arti-facts of software system.
UML is a notation that resulted from the unification of

18 SE Lecture Note 05/08/2025

Introduction(cont…)
 UML provides constructs for a broad range of systems and activities (e.g.,
real-time systems, distributed systems, analysis, system design,
deployment).
 System development focuses on three different models of the system:-
 The functional model- represented in UML with use case diagrams.
 describes the functionality of the system from the user’s point of
view.
 The object model- represented in UML with class diagrams.
 describes the structure of a system in terms of objects, attributes,
associations, and operations.
 Represents the static structure of the system
 The dynamic model- represented in UML with sequence diagrams,
state chart diagrams, and activity diagrams.
 describes the internal behaviour of the system.
19 SE Lecture Note 05/08/2025
Diagrams in UML
A UML diagram is a way to visualize systems and software using
Unified Modeling Language (UML).
 UML diagrams are classified into three categories that are given
below:
1. Structural Diagram
2. Behavioral Diagram
3. Interaction Diagram
 Structural Diagram: It represents the static view of a system by
portraying the structure of a system. It shows several objects
residing in the system.
 Class diagram
 Object diagram
 Component diagram
 Deployment Diagram
20 SE Lecture Note 05/08/2025
Cont. …
 Behavioral Diagram: It depicts the behavioral features of a
system. It deals with dynamic parts of the system. It encompasses
the following diagrams:
 Activity diagram
 State machine diagram
 Use case diagram
 Interaction diagram: It is a subset of behavioral diagrams. It
depicts the interaction between two objects and the data flow
between them. Following are the several interaction diagrams in
UML:
 Sequence diagram
 Collaboration diagram

21 SE Lecture Note 05/08/2025

Cont…
 Semantics of Diagrams
 Use case diagram
 Represent the functions of a system from the user’s point of
view
 Sequence diagrams:
 Represent the system’s behaviour in terms of interactions
among a set of objects.
 Collaboration diagrams
 A spatial representation of objects, links and interactions
 Emphasizes the structural organization of the objects.

22 SE Lecture Note 05/08/2025

Cont…
 Object Diagram
 Represent objects and their relationships and correspond to
simplified collaboration diagrams that does not represent
message broadcasts
 Class diagrams:
 are used to represent the structure of a system in terms of
objects, their attributes, and relationships.
 State chart diagrams:
 Represent the behavior of a class in terms of states
 Shows a state machine, consisting of states, transitions, events,
and activities.

23 SE Lecture Note 05/08/2025

Cont…
 Activity diagrams:
 are flow diagrams used to represent the data flow or the control
flow through a system.
 Component diagrams:
 Represent the logical components of an application.
 Shows the organization and dependencies among a set of
components
 Deployment diagrams:
 Represent the deployment of components on particular pieces of
hardware.
 Shows the configuration of run-time processing nodes and the
components that live on them.
24 SE Lecture Note 05/08/2025
Cont…
 In UML, a system is represented using five different “views” that describe
the system from distinctly different perspectives.
 Each views is defined by a set of diagrams
 User model view: it represents the system(product) from user’s (called

actors in UML) perspective

 Structural model view: the data and functionality are viewed from

inside the system. That is, static structure (classes, objects, and
relationships) is modeled.
 Behavioural model view: it represent dynamic or behavioural aspects

of the system. It depicts the interactions or collaboration between

various structural elements.
 Implementation model view: Structural and behavioural aspect of the

system as they are to be built.

 Environmental model view: The structural and behavioural aspects of

the environment in which the system to be implemented.

25 SE Lecture Note 05/08/2025
Cont…
 Readability guideline of UML
 Avoid crossing line
 Depict crossing line as a jump
 Avoid diagonal or curved lines
 Arrange symbols symmetrically
 Apply consistently sized symbols
 Include white space in diagrams
 Organize diagrams left to right , top to bottom

26 SE Lecture Note 05/08/2025

Use case Diagram
 A UML use case diagram shows the relationships among actors and
use cases within a system.
 Components of use case diagrams
 Use case
 Actor
 System Boundary
 Relationship
 Actor Relationship

27 SE Lecture Note 05/08/2025

Use case diagram (cont…)
 Guide lines of use case diagram
 Begin Use Case Names with a Strong Verb
 Example:

 Withdraw Funds, Register Student in Seminar, and Deliver

Shipment because it is clear what each use case does.
 Use case names beginning with weak verbs such as
“process,” “perform,” and “do” are often problematic
 Create communication difficulties with your project
stakeholders

28 SE Lecture Note 05/08/2025

Class diagram
 Class diagram are used to represent the structure of a
system in terms of:-
 Objects,
 Their attributes, and
 Relationships.
 It used for a variety of purpose, that is from understanding
your requirements to describing your detailed design.

29 SE Lecture Note 05/08/2025

Cont…
 Guidelines for Class diagram
 Identify Responsibilities on Domain Class Models
 When creating a domain class diagram, often as part of your

requirements modeling efforts, focus on identifying

responsibilities for classes instead of on specific
attributes or operations
 Indicate Visibility Only on Design Models
 The visibility of an operation or attribute defines the level of
access that objects have to it, and the UML supports four types
of visibility that are summarized in the following table

30 SE Lecture Note 05/08/2025

Sequence Diagram
 It describe behaviour as a sequence of messages exchanged
among a set of objects.
 The sequence diagram represents the flow of messages in the
system and is also termed as an event diagram.
 It portrays the communication between any two lifelines as a time-
ordered sequence of events, such that these lifelines took part at
the run time.
 In UML, the lifeline is represented by a vertical bar, whereas the
message flow is represented by a vertical dotted line that extends
across the bottom of the page.

31 SE Lecture Note 05/08/2025

Cont…
 Typically, we use a sequence diagram to:
 Describe the event flow of a use case.
 Identify the objects that participate in the use case
 Assign pieces of the use case behaviour to the objects in the form of
services.
 This process often leads to refinements in the use case (e.g., correcting
ambiguous descriptions, adding missing behaviour) and consequently, the
discovery of more objects and more services.
Purpose of a Sequence Diagram
 To model high-level interaction among active objects within a system.
 To model interaction among objects inside a collaboration realizing a use
case.
 It either models generic interactions or some certain instances of
interaction.
32 SE Lecture Note 05/08/2025
Cont…
Notations of a Sequence Diagram
Lifeline
 An individual participant in the sequence diagram is represented by a lifeline.
 It is positioned at the top of the diagram.

Actor
 A role played by an entity that interacts with the subject is called as an actor. It is
out of the scope of the system.

Activation
 It is represented by a thin rectangle on the lifeline.

33 SE Lecture Note 05/08/2025

Cont…
Messages
 The messages depict the interaction between the objects and are
represented by arrows. They are in the sequential order on the
lifeline.
Following are types of messages enlisted below:
Call Message:
Return Message: Self Message:

Destroy Message:

34 SE Lecture Note 05/08/2025

Collaboration Diagram
 Like UML sequence diagrams, it used to explore the dynamic nature of a software.
 Collaboration diagrams show the message flow between objects in an object-
oriented application, and also imply the basic associations (relationships)
between classes
 Unlike sequence diagram the time is not explicitly represented in these diagram
 The sequence of messages is indicated by numbering the messages.
 Components of collaboration diagram
 Named objects
 Links: by a continuous line between objects, and indicates the exchange of
messages
 Messages has following attributes

Sequence number

Message labels

Message direction
35 SE Lecture Note 05/08/2025
Activity diagrams
 It is the UML for modeling the dynamic aspects of systems.
 An activity diagrams is essentially a flowchart, showing flow of
control from activity to activity.
 The activity diagram helps in envisioning the workflow from one
activity to another
 It is also termed as an object-oriented flowchart.
 In UML, the activity diagram is used to demonstrate the flow of
control within the system rather than the implementation.

36 SE Lecture Note 05/08/2025

Cont…
Notation of an Activity diagram
 Initial State: It depicts the initial stage
or beginning of the set of actions.
 Action Box: It represents the set of
actions that are to be performed.
 Decision Box: It makes sure that the
control flow or object flow will follow only
one path.
 Final State: It is the stage where all the
control flows and object flows end.

37 SE Lecture Note 05/08/2025

Deployment diagrams
 Visualizes the physical hardware on which the software will be
deployed.
 It show the configuration of run-time processing elements and the
software components, processes, and objects that execute on them.
 It provides the necessary environment for the components to
execute in.
 A UML deployment diagram representing the allocation of
components to different nodes and the dependencies among
components

38 SE Lecture Note 05/08/2025

Cont…
Purposes of deployment diagram
 To visualize the hardware topology of the system.
 To represent the hardware components on which the software components are
installed.
 To describe the processing of nodes at the runtime.
 Symbol and notation of Deployment diagram

 The deployment diagram

notations:
 A component
 An artifact
 An interface
 A node

39 SE Lecture Note 05/08/2025

Exercise
 Techniques used to model data & process in scenario based
modelling is________.
A. Use case diagram
B. Activity diagram
C. Both a & b
D. None

 Which model in system modelling depicts the static nature of the

system ?
A. Behavioral Model
B. Context Model
C. Data Model
D.40 Structural Model SE Lecture Note 05/08/2025
Cont. …
 Which UML diagram describes the interactions among classes in
terms of an exchange of messages over time?
A. Use case diagram
B. Sequence diagram
C. Class diagram
D. Deployment diagram
 Which of the following diagram is not supported by UML considering
Data-driven modeling ?
A. Activity
B. Data Flow Diagram (DFD)
C. State Chart
D. Component

41 SE Lecture Note 05/08/2025

 CHAPTER-THREE
Requirement Elicitation
42 SE Lecture Note 05/08/2025
Outlines
 Requirement elicitation
 Requirement validations
 Types of requirements
 Functional requirement
 Non-functional requirement

43 SE Lecture Note 05/08/2025

 Introduction
A requirement: is a feature that the system must have or a constraint
that it must satisfy to be accepted by the client.
Requirements engineering: is the process of identifying
stakeholders and their needs, modeling and documenting them.
Requirements engineering includes two main activities:-
 Requirements elicitation: is the process of discovering
specification of the system that the client understands .
 Requirement Analysis: which results into an analysis model that
the developers can unambiguously interpret the requirement.

44 SE Lecture Note 05/08/2025

Software Lifecycle Activities

Requirements System Detailed Implemen-

Analysis Testing
Elicitation Design Design tation

Implemente
Expressed in d
Structured Realized By By
Terms Of By Verified
By

class...
class...
class... ?
class.... ?
Use Case Applicatio Solution
n Subsystems Source Test
Model Domain
Domain Code Cases
Objects
Objects
45 SE Lecture Note 05/08/2025
 Requirements elicitation
 Requirements elicitation: focuses on describing the purpose of the
system.
 The client, the developers, and the users identify a problem area
and define a system that addresses the problem.
 Such a definition is called a system specification and serves as a
contract between the client and the developers.
 The system specification is structured and formalized during
analysis to produce an analysis model.
 Both system specification and analysis model represent the same
information.

46 SE Lecture Note 05/08/2025

 Cont. …
 They differ only in the language and notation they use.
 The system specification is written in natural language, where as the
analysis model is usually expressed in a formal or semiformal
notation.
 The system specification supports the communication with the
client and users.
 The analysis model supports the communication among developers.
 Requirements elicitation and analysis focus only on the user’s view of
the system:-
 The system functionality.
 The interaction between the user and the system.
 The errors that the system can detect and handle.

47 SE Lecture Note 05/08/2025

 :problem
statement

Requirements Requirements
elicitation Specification

:nonfunctional
requirements

:functional
model

Analysis Analysis Model

:dynamic model

UML Activity Diagram :analysis object

model
Elicitation Techniques
Observation:
 To understand the activity, task, tools used, and events performed by others.
Questionnaires:
 an incredible method to find solutions to questions you can’t answer by yourself.
Interviewing:
 To Talk with stakeholders who you think can give essential knowledge into the
requirements
Brainstorming:
 To generate new ideas and find a solution for a specific issue
Prototyping:
 Valuable device for business analysts to decide whether the solution being
created is actually what the stakeholder’s demand
Document analysis:
 Extremely valuable requirements elicitation method which is generally utilized in
the IT industry.

49 SE Lecture Note 05/08/2025

 Requirement validation
 It is a quality assurance step, usually performed after requirements
elicitation or after analysis
Correctness : A specification is correct if it represents the client’s
view of the system.
Completeness: all possible scenarios through the system are
described.
Consistency: the system specification is consistent if it does not
contradict itself.
Clarity: there are no ambiguities in the requirements.
Realism: requirements can be implemented and delivered.
Traceability: Each system function can be traced to a corresponding
50 SE Lecture Note 05/08/2025
set of functional requirements.
 Type of Requirements
Functional requirements:
describe the interactions between the system and its environment.
The environment includes the user and any other external system
that interact with the system.
 Describe user tasks that the system needs to support
Example: the following is an example of functional requirements
Example # 1
A user shall be able to log into the system using their username and
password.
 In this example, the function is “login” and the behavior is “The system
shall allow a user to login using their username and password.”

51 SE Lecture Note 05/08/2025

 Cont. …
Non-functional requirements:
user visible aspects of the system not directly related to functional
behavior. It includes quantitative constrains such as response time,
accuracy etc.
The response time must be less than 1 second
The accuracy must be within a second
The system should be available 24 hours of a day
Example of non-functional requirements for SatWatch is:
The battery life of SatWatch is limited to 5 years.

52 SE Lecture Note 05/08/2025

Types of Nonfunctional Requirements
Quality requirements Constraints or Pseudo requirements
 Usability
 Implementation
 Reliability
 Interface
 Robustness
 Operation
 Safety
 Performance  Packaging
 Legal
 Response time
 Scalability  Licensing
 Throughput  Certification
 Availability  Regulation
 Supportability
 Adaptability
 Maintainability
53 SE Lecture Note 05/08/2025
Exercise
 Why is Requirements Elicitation a difficult task ?
A. Problem of scope
B. Problem of understanding
C. Problem of volatility
D. All of the mentioned
 Starting from least to most important, choose the order of stakeholder.
i. Managers
ii. Entry level Personnel
iii. Users
iv. Middle level stakeholder
A. i, ii, iv, iii
B. i, ii, iii, iv
C. ii, iv, i, iii
D. All of the mentioned

54 SE Lecture Note 05/08/2025

Cont. …
 What is the first step of requirement elicitation ?
A. Identifying Stakeholder
B. Listing out Requirements
C. Requirements Gathering
D. All of the mentioned
 “Consider a system where, a heat sensor detects an intrusion and
alerts the security company.” What kind of a requirement the
system is providing ?
A. Functional
B. Non-Functional
C. Known Requirement
D. None of the mentioned
55 SE Lecture Note 05/08/2025
Cont. …
 Which one of the following is a functional requirement ?
A. Maintainability
B. Portability
C. Robustness
D. None of the mentioned
 Which one of the following is a requirement that fits in a developer’s
module ?
A. Availability
B. Testability
C. Usability
D. Flexibility

56 SE Lecture Note 05/08/2025

 CHAPTER -FOUR

Object oriented system analysis

57 SE Lecture Note 05/08/2025

OUTLINE
 Introduction
 An overview of Analysis
 Analysis concepts and activities

58 SE Lecture Note 05/08/2025

Introduction
 Requirement Analysis: which results into an analysis model that
the developers can unambiguously interpret the requirement.
An investigation of the problem (rather than how a solution is
defined)
During OO analysis, there is an emphasis on finding and describing
the objects (or
concepts) in the problem domain.
For example, concepts in a Library Information System include Book,
and Library.

 Analysis — understanding, finding and describing concepts in the

problem domain.

59 SE Lecture Note 05/08/2025

Cont…
 The client, developers, and users identify a problem area and
define a system that addresses the problem.
 Such a definition is called a system specification and serves as a
contract between the client and the developers.
 The system specification is structured and formalized during
analysis to produce an analysis model.
 The system specification supports the communication with the
client and users.
 The analysis model supports the communication among
developers.
 Requirements elicitation and analysis focus only on the user’s view
of the system:-
 The system functionality.
60 SE Lecture Note 05/08/2025
 The interaction between the user and the system.
An Overview of Analysis
 Analysis focuses on producing a model of the system, called the
analysis model, which is correct, complete, and consistent.

Products of requirements elicitation and analysis (UML activity diagram).

61 SE Lecture Note 05/08/2025
Cont…
 The analysis model is composed of three individual models: -
 The functional model- represented by use cases and
scenarios.
 The analysis object model- represented by class and
object diagrams.
 The dynamic model- represented by state chart, activity
diagram and sequence diagrams.

62 SE Lecture Note 05/08/2025

Entity, Boundary, and Control Objects
 The analysis object model - consists of entity, boundary, and control objects.
Entities are objects representing system data: Customer, Transaction,
Cart, etc.
 Boundaries are objects that interface with system actors: user
interfaces, gateways, proxies, etc.
 Controllers are objects that mediate between boundaries and entities.
 They orchestrate the execution of commands coming from the boundary.

 Analysis activities include:-

 Identifying entity ,boundary and control objects
 Mapping use cases to objects
 Identifying associations among objects
 Identifying object attributes
 Modelling object’s behaviour with state charts
 Modelling generalization relationships

63 SE Lecture Note 05/08/2025

Exercise
 Which of the following is the understanding of software
product limitations, learning system related problems or
changes to be done in existing systems beforehand,
identifying and addressing the impact of project on
organization and personnel etc?
A. Software Design
B. Feasibility Study
C. Requirement Gathering
D. System Analysis

64 SE Lecture Note 05/08/2025

 Chapter-Five
Object Oriented System Design

65 SE Lecture Note 05/08/2025

Out line

 Introduction
 An overview of system design
System design concepts and activities

66 SE Lecture Note 05/08/2025

 Introduction
 System design is the transformation of the analysis model
in to system design model.
 It focuses on the solution domain rather than on the problem
domain
 The deliverable of this phase is a system design model which
serves as a blueprint for the implementation of the system.
 During system design, developers define:-
 The design goals of the project
 Decompose the system into smaller subsystems that can
be realized by individual teams.
67 SE Lecture Note 05/08/2025
 Cont…
 The analysis model describes the system completely from the actors’
point of view and serves as the basis of communication between the
client and the developers.
 The analysis model, however, does not contain information about
the internal structure of the system, its hardware configuration, or,
more generally, how the system should be realized.

68 SE Lecture Note 05/08/2025

 Cont…
 System design fill the gap between the system specification,
produced during requirements elicitation and analysis, and the
system that is delivered to the users.
 It is the first step in this process and focuses on decomposing the
system into manageable parts.
 During requirements elicitation and analysis, we concentrated
on the purpose and the functionality of the system.
 But, in system design, we focus on :-
 The processes
 Data structures, and
 Software and hardware components necessary to implement
it.
69 SE Lecture Note 05/08/2025
 An overview of system design
 The analysis model does not contain information about the
internal structure of the system, how the system should be
realized.
 System design is the first step in this direction by
considering the following products.
 List of design goals- describing the qualities of the
system that developers should optimize. The design
goals are derived from the non-functional
requirements.

70 SE Lecture Note 05/08/2025

 Cont…
 Software architecture- describing the subsystem by
decomposition in terms of :-
 Subsystem responsibilities
 Dependencies among subsystem
 Subsystem mapping to hardware and
 Major policy decisions such as control flow, access control,

and data storage.

 Design goals: are constraints that should be considered
throughout the designing process.

71 SE Lecture Note 05/08/2025

 Cont…
 Examples of potential design goals:
Reliability
Maintainability
Fault tolerance
Backward-compatibility
High-performance
Reuse of components
Rapid development
Minimum # of errors
Low-cost

72 SE Lecture Note 05/08/2025

 Cont…
 Subsystems and classes
 To reduce the complexity of the solution domain, it is better to
decompose a system into simpler parts, called subsystems
 which are made of a number of solution domain classes.
 Subsystem
Collection of classes, associations, operations, events and constraints
that are interrelated with each other.
Core for subsystems: UML Objects and Classes.
 Service
Group of operations provided by the subsystem.
core for services: Subsystem use cases.

73 SE Lecture Note 05/08/2025

 Cont…
 Subsystem interface
The set of operations of a subsystem that are available to other
subsystems.
 Grouping objects into subsystems
 Assign objects identified in one use case into the same
subsystem.
 Create a dedicated subsystem for objects used for moving data
among subsystems.
 Minimize the number of associations crossing subsystems
boundaries.
 All objects in the same subsystem should be functionally related

74 SE Lecture Note 05/08/2025

 Cont…
 Object oriented software design has two parts.
 System design: decompose a system into interacting subsystems
and focuses on defining the services provided by each subsystem
that is:-
 Enumerating the operations
 Their parameters, and
 Their high-level behaviour.
 Object design: specifies each of the classes and how they interact
and focuses on defining the subsystem interfaces, that is:-
 The type of the parameters and
 The return value of each operation.

75 SE Lecture Note 05/08/2025

 Cont…
 Purpose of system design
 Abstract solution to conquer complexity
 Supports reuse: Subsystem can be re-used in different products,
similar product (i.e., product line)
 Facilitates (integration) testing: Subsystems are the “chunks ” that
are integrated
 Parallel development: Subsystems can be developed in parallel by
different teams
 Supports system evolution: Clear description of the capabilities of
each subsystem and how the subsystems interact .

76 SE Lecture Note 05/08/2025

 Cont…
 Coupling and Cohesion: its goal is to reduce sub system complexity
while change occurs.
 Cohesion measures the dependence among classes.
 High cohesion: The classes in the subsystem perform similar tasks
and are related to each other (via associations).
 Low cohesion: Lots of miscellaneous and auxiliary classes, no
associations
 Coupling measures dependencies between subsystems
 High coupling: Changes to one subsystem will have high impact
on the other subsystem (change of model, massive recompilation,
etc )
 Low coupling: A change in one subsystem does not affect any
other subsystem
77 SE Lecture Note 05/08/2025
 Cont…
 Subsystems should have as maximum cohesion and minimum
coupling as possible:
 How can we achieve high cohesion?
 How can we achieve loose coupling?
 Partitions and Layers: They are techniques to achieve low coupling.
 A large system is usually decomposed into subsystems using both,
layers and partitions.
 Partitions vertically divide a system into several independent (or
weakly-coupled) subsystems that provide services on the same level
of abstraction.
 A layer is a subsystem that provides subsystem services to a higher
layers (level of abstraction).
 Each layer can only depend on lower level layers and has no
78
knowledge of the layers above it. SE Lecture Note 05/08/2025
 Cont…
 There are two types of layering:
 Closed architecture: a layer can call the immediate lower layer only.
 Open architecture: a layer can call other layers even in depth

79 SE Lecture Note 05/08/2025

Exercise
 The importance of software design can be summarized in a
single word which is:
A. Efficiency
B. Accuracy
C. Quality
D. Complexity
 A module is said to be functionally independent if it has
_________
A. Low cohesion and high coupling
B. high cohesion and Low coupling
C. Low cohesion and Low coupling
D. High cohesion and high coupling
80 SE Lecture Note 05/08/2025
 Chapter-Six
Software Quality Assurance
Tadesse Beyene (MSc.)

81 SE Lecture Note 05/08/2025

Out line
 An overview of testing
 Testing activities
 Types of Testing

82 SE Lecture Note 05/08/2025

 Introduction
 Quality Assurance: A set of activities designed to ensure that the development and/or
maintenance process is satisfactory to ensure a system will meet its objectives.
 Quality Assurance’s objective is to minimize the cost of guaranteeing quality by a

variety of activities performed throughout the development / manufacturing processes

/ stages.
 Activities prevent causes of errors; detect and correct them early in the
development process
 QA substantially reduces the rate of products that do not qualify for shipment and/at

the same time, reduce the costs of guaranteeing quality in most cases.
 Quality Control is defined as a set of activities designed to evaluate the quality of a

developed or manufactured product.

 We have QC inspections during development and before deployment
 QC activities are only a part of the total range of QA activities.


83 SE Lecture Note 05/08/2025

 Cont…
 Note that Software Quality Assurance must include not only process for
development but for (hopefully) years of maintenance.
 So, we need to consider quality issues affecting development and
maintenance within the overall SQA concept.
 SQA activities must also include scheduling and budgeting as essential.
 SQA must address issues that arise when time constraints are encountered
 are features eliminated?
 Budget constraints may force compromise when/if inadequate resources are

allocated
 to development and/or maintenance.

84 SE Lecture Note 05/08/2025

Testing
 Testing: The process of executing a system with the intent of
finding defects.
The Software testing process has 2 distinct objectives
 Execute a program with the intent of finding errors to
o Determine whether system meets specifications
o Determine whether system meets user‘s needs
What is defect?

o A defect is any error found by testing and reviewing
activities (All errors found by internal reviewer, external
reviewer and customer).

85 SE Lecture Note 05/08/2025

Testing Activities

86 SE Lecture Note 05/08/2025

Cont. …

87 SE Lecture Note 05/08/2025

 Testing Approaches
Black box testing (Function Testing)
 Also known as behavioral testing
 Focuses more on the functional requirements of the software
 To determine if input is properly accepted and output is
correctly produced
 It has little regard for the internal logical structure of the
software and is applied at the later stages of software testing

88 SE Lecture Note 05/08/2025

 Cont. …
 Black-boxtesting attempts to find errors in the following
categories:
 incorrect or missing functions,
 interface errors,
 errors in data structures or external database access
 behaviour or performance errors,
 System initialization and termination errors.

89 SE Lecture Note 05/08/2025

Cont. …
 White Box testing (Unit Testing)
 Logical paths through the software are tested by providing test
cases that exercise specific sets of conditions and/or loops.
 The "status of the program" may be examined at various
points.

 Although exhaustive testing is not possible, an adequate

number of important logical paths and data structures can be
selected and validated

90 SE Lecture Note 05/08/2025

Testing Stages
There are 4 stages of Testing:
 Unit Test
 Integration Test
 System Test
 Acceptance Test

91 SE Lecture Note 05/08/2025

Cont. … Unit testing
 Purpose: to verify that the component/module functions properly
 Check:
o internal data structures
o Logic
o boundary conditions for input/output data
Normally: White box oriented
Doer: Development team
Metrics: Test coverage:
o Statement
o Branch
o Path
o Condition
 Individualsubsystem
 Confirm that subsystems is correctly coded & carries out the
intended
92 functionality SE Lecture Note 05/08/2025
Cont. … Integration testing
 Purpose:
 To ensure that code is implemented and designed properly
o to take unit tested modules and build a program structure that
has been dictated by design
 Combining the individual components to uncover errors
associated with interfacing
 Normally: Black box oriented
 Doer: independent Test team
 Groups of subsystems (collection of classes) and eventually
the entire system
 Test the interface among the subsystem

93 SE Lecture Note 05/08/2025

Cont. … System Testing
Purpose:
 To ensure that the system does what the requirement
specifies
 Types
o Function Testing
o Performance Testing
o Installation Testing
 Normally: Black box oriented
 Doer: independent Test team
 The entire system
 Determine if the system meets the requirements (functional
and global)
94 SE Lecture Note 05/08/2025
Cont. …Acceptance testing
 Customer‘s way to verify that what was wanted is what is built
 Allows the customers to determine what they really want, whether
specified in the document or not.
 New problems may arise
 Customers may decide that the problem as changed and different
solution is needed
 Normally: Black box oriented
 Doer: Customer/independent Test team
 Evaluates the system delivered by developers
 Demonstrate that the system meets customer requirements and is
ready to use
 Implementation (Coding) and testing go hand in hand

95 SE Lecture Note 05/08/2025

Exercise
 Software Requirement Specification (SRS) is also known as
specification of _______.
A. White box testing
B. Acceptance testing
C. Integrated testing
D. Black box testing
Customers typically carry out which one of the following types
of testing?
E. Unit testing
F. Integration testing
G. Acceptance testing
H. Regression testing.
96 SE Lecture Note 05/08/2025
Cont. …
 Why is it necessary to test a large program at three different
levels: unit, integration, as well as system levels, rather than
testing only at the system level?
A. It reduces the number of test cases that can be designed
B. It reduces the test execution effort
C. It reduces the debugging effort
D. It reduces test case design effort

97 SE Lecture Note 05/08/2025

98 SE Lecture Note 05/08/2025