Software Engineering Fundamentals

COC2073
Module 4: Software Architecture & Design
Muhammad Shahid
Department of Computer Science
National Textile University

[email protected]
Last Lecture Review

▪ Software Requirement Engineering

▪ Levels of Requirements
▪ Software Quality Factors
▪ Requirements Engineering Process
▪ Use-Case Modeling
▪ Activity Diagrams
▪ Data Flow Model
▪ Decision Tables & Decision Trees
▪ Requirements Validation Techniques
2 Software Engineering Fundamentals - COC2073
Agenda – What will you Learn Today?
Software Architectural Software Design
Styles Principles

Object-Oriented Design The Sequence Diagram

3 Software Engineering Fundamentals - COC2073

 Software Architecture

4 Software Engineering Fundamentals - COC2073

Architecture

5 Software Engineering Fundamentals - COC2073

Constructing Building

I need a
tower, with a
big clock

The king's
requirements

6 Software Engineering Fundamentals - COC2073

Constructing Building

I need a
tower, with a
big clock

Architecture
The king's
requirements Construction

7 Software Engineering Fundamentals - COC2073

Is Software Build the Same Way?

Software is different
▪ No physical natural order of construction (e.g.
start with the foundation of the house)
▪ Software is not tangible

Architecture

Requirements Implementation

8 Software Engineering Fundamentals - COC2073

What is Software Architecture?

The Software Architecture of a system consists

of a description of the system elements,
interactions between the system elements,
patterns that guide the system elements and
constraints on the relationships between system
elements.
[Shaw and Garlan]

9 Software Engineering Fundamentals - COC2073

 What is Software Architecture?

The software architecture of a program or

computing system is the structure or structures
of the system, which comprise software
components, the externally visible properties of
those components, and the relationships among
them.
[SEI]

10 Software Engineering Fundamentals - COC2073

 What is Software Architecture?

Architectural design: The process of defining a

collection of hardware and software
components and their interfaces to establish the
framework for the development of a computer
system.
[IEEE Glossary]

11 Software Engineering Fundamentals - COC2073

 Importance of Architecture

▪ Communication between Stakeholders

▪ A high-level presentation of the system
▪ Use for understanding, negotiation and
communication
▪ Early Design Decisions
▪ Profound effect on the systems quality
attributes, e.g. performance, availability,
maintainability etc.
▪ Large-Scale Reuse
▪ If similar system have common requirements,
modules can be identified and reused
12 Software Engineering Fundamentals - COC2073
 Architecture Attributes

13 Software Engineering Fundamentals - COC2073

 Performance

▪ Localize the operations to minimize subsystem

communication

Scale up …

Scale out …

14 Software Engineering Fundamentals - COC2073

 Security

▪ Use a layered architecture with critical assets

in inner layers
▪ Only authorized users can
Confidentiality read the information
▪ E.g. Military

Availability Integrity
▪ Right information is ▪ Only authorized users
available at the right time can modify, edit or delete
▪ Important for everyone data.
▪ E.g. bank systems

15 Software Engineering Fundamentals - COC2073

 Safety

▪ Isolate safe-critical components

The Whole System

Critical

Design so that all safety critical operations are

located in one or few modules / subsystems.

16 Software Engineering Fundamentals - COC2073

 Availability

▪ Include redundant components in the

architecture

17 Software Engineering Fundamentals - COC2073

 Maintainability

▪ Use fine-grain, self-contained components

18 Software Engineering Fundamentals - COC2073

 Partitioning the Architecture

19 Software Engineering Fundamentals - COC2073

 Partitioning the Architecture

▪ Distribute the responsibilities to different

subsystems

▪ A system that is easier to test and easier to

maintain

▪ Partitioning of an architecture may be

Horizontal and/or Vertical

20 Software Engineering Fundamentals - COC2073

 Problem Partitioning

▪ Principle of “Divide and Conquer” (Analyze

and Synthesis)

▪ Divide the problem into manageably small

pieces that can be solved separately

▪ The different pieces have to cooperate and

communicate to solve the larger problem and
cannot be entirely independent of each other

21 Software Engineering Fundamentals - COC2073

 Analyze & Synthesis
The process of
Problem Analysis

Sub-problem 1 Sub-problem 2 Sub-problem 3 Sub-problem 4

solution 1 solution 2 solution 3 solution 4

solution 1 The process of

Synthesis

22 Divide
Software & Conquer
Engineering Strategy
Fundamentals - COC2073
 Problem Partitioning

▪ Problem partitioning can be divided into two

categories:

Horizontal Vertical
Partitioning Partitioning

23 Software Engineering Fundamentals - COC2073

 Horizontal Partitioning

▪ Horizontal partitioning defines separate

branches of modular hierarchy for each major
program function

▪ The simplest approach to horizontal

partitioning defines three partitions:
a. Input
b. Data transformation (often called processing)
c. Output

24 Software Engineering Fundamentals - COC2073

 Horizontal Partitioning

Function 1 Function 3

Function 2

25 Software Engineering Fundamentals - COC2073

 Vertical Partitioning

▪ Vertical partitioning suggests that control and

work should be distributed from top-down in
the program structure

▪ Top-level modules should perform control

functions and do actual processing work

▪ Modules that reside low in the structure

should be the workers, performing all input,
compilation, and output tasks
26 Software Engineering Fundamentals - COC2073
 Vertical Partitioning

Decision
Making
Modules

"Working"
Modules

27 Software Engineering Fundamentals - COC2073

 Architectural Styles

28 Software Engineering Fundamentals - COC2073

 Architectural Styles

▪ The architectural model of a system may

conform to a generic architectural model or
style

▪ An awareness of these styles can simplify the

problem of defining system architectures

29 Software Engineering Fundamentals - COC2073

 Architectural Styles

▪ Each style describes a system category that

encompasses:
1) A set of components (e.g. database,
computational modules) that perform a
function required by a system
2) A set of connectors that enable
"communication, coordination and
cooperation" among components
3) Constraints that define how components can
be integrated to form the system

30 Software Engineering Fundamentals - COC2073

 Commonly Practiced Arch. Styles

▪ Repository Architecture

▪ Client - Server Architecture

▪ Pipe and Filter Architecture

▪ Layered Architecture

▪ Model View Controller Architecture

31 Software Engineering Fundamentals - COC2073

 Repository Architecture

32 Software Engineering Fundamentals - COC2073

 Repository Architecture

▪ All data in a system is managed in a central

repository that is accessible to all system
components

▪ Components do not interact directly, only

through the repository

▪ The majority of systems that use large

amounts of data are organized around a
shared database or repository
33 Software Engineering Fundamentals - COC2073
 Repository Architecture

▪ This model is therefore suited to applications

in which data is generated by one component
and used by another

▪ Examples of this type of system include:

‒ Command and control systems
‒ Management Information Systems
‒ CAD systems
‒ Interactive development environments for
software

34 Software Engineering Fundamentals - COC2073

 Repository Architecture

Client
Software

Client Client
Software Software
Data Store /
Repository
Client Client
Software Software

Client
Software

35 Software Engineering Fundamentals - COC2073

 Repository Architecture

Produce
Generate

Analyze Build/Test
Design

Enterprise Production
Modelling Software Maintenance
Repository

36 Software Engineering Fundamentals - COC2073

 Repository Model Characteristics

▪ Efficient way to - Subsystems must

share large amounts agree on a
of data repository data
▪ Sub-systems need model
not be concerned - Data evolution is
with how data is difficult and
produced expensive
▪ Centralized - Difficult to distribute
management e.g. efficiently
backup, security, etc.

37 Software Engineering Fundamentals - COC2073

 Client - Server Architecture

38 Software Engineering Fundamentals - COC2073

 Client - Server Architecture

▪ The application is modeled as a set of

services that are provided by servers and a
set of clients that use these services

▪ The servers which provide specific services

such as printing, data management, etc.

▪ Clients call these services

39 Software Engineering Fundamentals - COC2073

 Client - Server Architecture

▪ These clients and servers are connected

through a network which allows clients to
access servers

▪ Clients know the servers but the servers do

not need to know all the clients

40 Software Engineering Fundamentals - COC2073

 Client - Server Architecture

41 Software Engineering Fundamentals - COC2073

 Client - Server Architecture

42 Software Engineering Fundamentals - COC2073

 Client - Server Architecture

Client Client Client

The clients need to be

aware of the server Clients initiate
communication
Server

43 Software Engineering Fundamentals - COC2073

 Client - Server Architecture

The clients need to be

aware of the server Clients initiate
communication

44 Software Engineering Fundamentals - COC2073

 Representative Client/Server Sys.

▪ File Servers
- Client requests selected records from a file and
the server transmits records to client over the
network

▪ Database Servers
- Client sends requests, such as SQL queries, to
the database server, the server processes the
request and returns the results to the client over
the network

45 Software Engineering Fundamentals - COC2073

 Representative Client/Server Sys.

▪ Transaction Servers
- Client sends requests that invokes remote
procedures on the server side, server executes
procedures invoked and returns the results to
the client

▪ Groupware Servers
- Groupware servers provide set of applications
that enable communication among clients using
text, images, bulletin boards, video, etc.

46 Software Engineering Fundamentals - COC2073

 Client - Server Architecture

47 Software Engineering Fundamentals - COC2073

 Client/Server Configurations

48 Software Engineering Fundamentals - COC2073

 Client/Server Configurations

▪ Two-Tier, Thin-Client architecture

▪ Two-Tier, Fat-Client architecture

▪ Three-Tier architecture

▪ N-Tier architecture

49 Software Engineering Fundamentals - COC2073

 Two-Tier, Thin-Client Model

▪ Initially used to migrate legacy systems to

client server architectures

▪ The legacy system may act as a server in its

own right and the GUI may be implemented
on a client

50 Software Engineering Fundamentals - COC2073

 Two-Tier, Thin-Client Model

▪ Heavy load on server Client

▪ Significant network traffic Presentation

Layer

Server
Business
Layer

Data
Management

51 Software Engineering Fundamentals - COC2073

 Two-Tier, Fat-Client Model

▪ More processing is delegated to the client as

the application processing is locally extended

▪ Suitable for new client/server systems when

the client system capabilities are known in
advance

▪ More complex than thin client model with

respect to management issues

52 Software Engineering Fundamentals - COC2073

 Two-Tier, Fat-Client Model

+ Distribute workload on clients Client

Presentation
Layer
- System management Business
problem, update software on Layer

clients
Server
Data
Management

53 Software Engineering Fundamentals - COC2073

 Two-Tier

Data Source

Client Application

54 Software Engineering Fundamentals - COC2073

 Zero Install

▪ Develop a system where no installation on the

client side is needed
▪ Only be done when there is no or little
processing done at the client side
▪ A trade-off between using the computing
power available at the client machine versus
maintenance overhead
▪ Example
- Web-based application

55 Software Engineering Fundamentals - COC2073

 Three-Tier Architecture

▪ Each application architecture layers

(presentation, application, database) may run
on separate processors

▪ Allows for better performance than a Thin-

client approach

▪ Simpler to manage than Fat-client approach

and highly scalable

56 Software Engineering Fundamentals - COC2073

 Three-Tier Architecture
Client
+ Map each layer on separate
Presentation
hardware Layer

+ Possibility for load balancing

Middle-ware

Business
Layer

Server

Data
Management

57 Software Engineering Fundamentals - COC2073

 Three-Tier Architecture

Client HTTP Interaction

SQL Query
Web Server Database Server
Client Account Service SQL Custom
Provision Account
Database
Client

Client

58 Software Engineering Fundamentals - COC2073

 N-Tier Architecture

▪ A struggle to find a middle ground between

the Fat-client architecture and the Thin-client
architecture

▪ The idea is to enhance scalability and

performance by distributing both the data and
the application using multiple server machines

59 Software Engineering Fundamentals - COC2073

 N-Tier Architecture

▪ Involve different types of servers such as

application server, web server, and DB server

▪ Three-tier architecture is a specialized form of

N-Tier architecture

60 Software Engineering Fundamentals - COC2073

 Client-Server Characteristics

▪ Makes effective use ▪ No standard way of

of networked sharing data, so sub-
systems systems may use
▪ Easy to add new different data
servers or upgrade organization
existing servers ▪ Redundant
▪ Distribution of data is management in each
straightforward server
▪ No central register of
names and services

61 Software Engineering Fundamentals - COC2073

 Pipes & Filters Architecture

62 Software Engineering Fundamentals - COC2073

 Pipes & Filters Architecture

▪ Similar to data flow diagrams

▪ Used when the input data is processed

through a series of transformations to yield
the desired output

▪ Each processing step is called a Filter

▪ The connecting link from one process to the

other is called the Pipe
63 Software Engineering Fundamentals - COC2073
 Pipes & Filters Architecture

▪ The information flows from one process to the

other through pipes

▪ Each filter works independently of others and

does not require knowledge of the working of
any of the other filters including its neighbours

64 Software Engineering Fundamentals - COC2073

 Pipes & Filters Architecture

Filters
Pipes
Input Output

65 Software Engineering Fundamentals - COC2073

 Pipes & Filters Architecture

▪ If the dataflow has only a single sequence of

processes with no alternative or parallel
paths, then it is called Batch Sequential

Example: A Compiler

Intermediate
Semantic Code
lexer parser Code Optimization
analysis Generation
Generation

66 Software Engineering Fundamentals - COC2073

 Pipes & Filters Architecture

67 Software Engineering Fundamentals - COC2073

 Pipes & Filters Architecture

Pros Cons
▪ Understandable, easy ▪ Limited to batch
to reason about, in-out processing (not good
▪ Extendable - easy to for interactive apps)
add / remove filters ▪ Duplicated execution,
▪ Easy to simulate and e.g. format checking
analyze properties, ▪ Error handling – hard
e.g. throughput to produce
▪ Concurrent execution understandable error
(both in series and in messages
parallel)

68 Software Engineering Fundamentals - COC2073

 Layered Architecture

69 Software Engineering Fundamentals - COC2073

 Layered Architecture

▪ A layered architecture has many different

layers

▪ Example of a layered architecture is an

operating system where different layers are
used to provide services and functionality and
the inner layers are closer to the machine
hardware than the outer layers

70 Software Engineering Fundamentals - COC2073

 Layered Architecture

▪ Each layer isolates the outer layer from inner

complexities

▪ The outer layer only needs to know the

interface provided by the inner layer

▪ If there are any changes in the inner layer, as

long as the interface does not change, the
outer layer is not affected

71 Software Engineering Fundamentals - COC2073

 Layered Architecture

Layer 3
Layer 1 Layer 2

Highest
Abstraction
Layer 1

Layer 2
Define
Interfaces
Layer 3

72 Software Engineering Fundamentals - COC2073

 Layered Architecture

73 Software Engineering Fundamentals - COC2073

 Pipes & Filters Architecture

Pros Cons
▪ Easy reuse of layers ▪ Could give
▪ Support for performance penalties
standardization ▪ Layer bridging looses
▪ Dependencies are modularity
kept local -
modification local to a
layer
▪ Supports incremental
Layer 1 Layer 2 Layer 3
development and
testing

74 Software Engineering Fundamentals - COC2073

 Service-Oriented Architecture (SOA)

75 Software Engineering Fundamentals - COC2073

 Service-Oriented Architecture (SOA)

▪ Service-oriented architecture (SOA) is an

architectural paradigm provide a platform to
fulfill the needs of consumers and capabilities
of providers to interact through services
across different domains and technology

▪ SOA is essentially a collection of web

services, which are well-defined, self-
contained modules that provide standard
business functionality and are independent of
the state or context of other web services
76 Software Engineering Fundamentals - COC2073
 Service-Oriented Architecture (SOA)

▪ The SOA architecture encompasses web

service provider; web service consumer; and
Universal Description, Discovery and
Integration (UDDI) registry for handling
service request, service discovery, and
service invocation

77 Software Engineering Fundamentals - COC2073

 Service-Oriented Architecture (SOA)

UDDI

Fine/Retrieve Register/Publish

Web Service Web Service

Consumer Request/Response Provider

Service-oriented architecture

78 Software Engineering Fundamentals - COC2073

 Service-Oriented Architecture (SOA)

▪ The SOA allows users to access local

services as well as remote services over a
connected network

▪ Service-oriented applications examples

include sharing information, handling multi-
step processes such as reservation systems
and online stores, exposing industry-specific
data or services over an extranet

79 Software Engineering Fundamentals - COC2073

 Service-Oriented Architecture (SOA)

▪ Benefits of the SOA architectural style are

domain alignment for reuse of common
services, abstraction and loose coupling to
access services, discoverability,
interoperability, and rationalization

80 Software Engineering Fundamentals - COC2073

 Software Design

81 Software Engineering Fundamentals - COC2073

 What is Software Design?

▪ “The process of defining the architecture,

components, interfaces, and other
characteristics of a system or component”

82 Software Engineering Fundamentals - COC2073

 Design Activities

▪ Hierarchical decomposition of the system into

subsystems
▪ Determine components and assign to
subsystems
▪ Determine relationships between components
▪ Define communication between components
architecture

83 Software Engineering Fundamentals - COC2073

 Design Objectives/Properties

1) Correctness:
▪ The design of a system is correct if the system
built precisely according to the design satisfies
the requirements of that system
2) Verifiability:
▪ Design should be verified for correctness
▪ Verifiability is concerned with how easily the
correctness of the design can be checked
3) Completeness:
▪ All the different components of the design should
be verified
84 Software Engineering Fundamentals - COC2073
 Design Objectives/Properties

4) Traceability:
▪ Entire design element be traceable to the
requirements

5) Efficiency:
▪ Proper use of scarce resources by the system

6) Simplicity:
▪ The most important quality criteria for software
systems
85 Software Engineering Fundamentals - COC2073
 Software Design Principles

86 Software Engineering Fundamentals - COC2073

 Design Principles

▪ Design principles are guidelines for

decomposing a system’s required functionality
and behavior into modules

▪ The principles identify the criteria for

decomposing a system and deciding what
information to provide (and what to conceal)
in the resulting modules

87 Software Engineering Fundamentals - COC2073

 Design Principles

▪ Six dominant principles:

1. Modularity
2. Interfaces
3. Information hiding
4. Incremental development
5. Abstraction
6. Generality

88 Software Engineering Fundamentals - COC2073

 Design Principles – Modularity

▪ Modularity is the principle of keeping

separate the various unrelated aspects of a
system, so that each aspect can be studied in
isolation (also called Separation of Concerns)

▪ To determine how well a design separates

concerns, we use two concepts that measure
module independence: coupling and
cohesion

89 Software Engineering Fundamentals - COC2073

 Design Principles – Modularity

▪ If the principle is applied well, each resulting

module will have a single purpose and will be
relatively independent of the others
‒ Each module will be easy to understand and
develop
‒ Easier to locate faults (because there are fewer
suspect modules per fault)
‒ Easier to change the system (because a change
to one module affects relatively few other
modules

90 Software Engineering Fundamentals - COC2073

 Coupling - Dependency b/w Modules

Uncoupled – No dependences Loosely coupled - Few dependencies

What do we want?
Low coupling. Why?
▪ Replaceable
▪ Enable changes
▪ Testable - isolate faults
▪ Understandable
Highly Coupled - Many dependencies

91 Software Engineering Fundamentals - COC2073

 Coupling – Example

class Complex
{
public double real;
public double imaginary;

public Complex(double real, double imaginary);

public double getReal();
public double getImaginary();
public void Display();
} // End of class

92 Software Engineering Fundamentals - COC2073

 Coupling – Example

Complex Add (Complex a, Complex b)

{
Complex temp;
temp.real = a. real + b.real;
temp.imaginary = a.imaginary + b.imaginary;
return temp;
}
Complex Subtract (Complex a, Complex b)
{
Complex temp;
temp.real = a. real - b.real;
temp.imaginary = a.imaginary - b.imaginary;
return temp;
}
93 Software Engineering Fundamentals - COC2073
 Coupling – Example

class Complex
{
private double real;
private double imaginary;

public Complex(double real, double imaginary);

public double getReal();
public double getImaginary();
public void Display();
} // End of class

94 Software Engineering Fundamentals - COC2073

 Coupling – Example

Complex Add (Complex a, Complex b)

{
Complex temp;
temp.real = a. real + b.real;
temp.imaginary = a.imaginary + b.imaginary;
return temp;
}

95 Software Engineering Fundamentals - COC2073

 Coupling – Example

Complex Add (Complex a, Complex b)

{
Complex temp;
temp.real = a. getReal() + b.getReal();
temp.imaginary = a.getImag() + b.getImag();
return temp;
}

96 Software Engineering Fundamentals - COC2073

 Cohesion - Relation b/w Internal Parts
of the Module

Low Cohesion - The parts e.g. functions Medium Cohesion - Some logically
have less or nothing in common related function. e.g. IO related functions

What do we want?
High cohesion. Why?
▪ More understandable
▪ Easier to maintain
High Cohesion - Does only what it is
designed for?

97 Software Engineering Fundamentals - COC2073

 Cohesion – Example

class Order
{
private int OredrID;
private string CustomerName;
private Date OrderDate;
private float TotalPrice;
private int CustomerID;
private int CustomerPhone;

98 Software Engineering Fundamentals - COC2073

 Cohesion – Example

public int getOrderID();

public Date getOrderDate();
public float getTotalPrice();
public int getCustometId();
public string getCustomerName();
public string getCustometAddress();
public int getCustometPhone();
public void setOrderID(int id);
public void setOrderDate(Date date);
public void setTotalPrice(float price);
public void setCustometId(int cstmrID);
public void setCustomerName(string cName);
public void setCustometAddress(string address);
} // End of Order class

99 Software Engineering Fundamentals - COC2073

 Cohesion – Example

class Order
{
private int OrderId;
private Date OrderDate;
private float TotalPrice;
public int getOrderID();

public Date getOrderDate();

public float getTotalPrice();
public void setOrderID(int ordrID);
public void setOrderDate(Date date);
public void setTotalPrice(float price);
} // End of Order class

100 Software Engineering Fundamentals - COC2073

 Cohesion – Example

class Customer
{
private int CustomerID;
private string CustomerName;
private int CustomerPhone;

public int getCustometID();

public string getCustomerName();
public string getCustometAddress();
public void setCustometId(int cstmrID);
public void setCustomerName(string cName);
public void setCustomerAddress(string
address);
} // End of Customer class

101 Software Engineering Fundamentals - COC2073

 Design Principles – Interfaces

▪ An interface defines what services the

software unit provides to the rest of the
system, and how other units can access
those services
▪ An interface must also define what the unit
requires, in terms of services or assumptions,
for it to work correctly
Interface Name
+ Behavior1()
+ Behavior2()

102 Software Engineering Fundamentals - COC2073

 Design Principles – Interfaces

▪ A software unit may have several interfaces that

make different demands on its environment or that
offer different levels of service
Module
Data
_________________ Operation 3
_________________ _________________
Interface A
_________________ _________________
_________________ _________________ Operation 1 ()
_________________ Operation 2 ()
Operation 1
_________________
_________________ Operation 4
_________________ Interface B
_________________ _________________
_________________ _________________ Operation 3 ()
_________________ Operation 4 ()
Operation 2
_________________
_________________
_________________
_________________

103 Software Engineering Fundamentals - COC2073

 Design Principles – Interfaces

▪ A software unit may have several interfaces that

make different demands on its environment or that
offer different levels of service
Module
Data
_________________ Operation 3
_________________ _________________
Interface A
_________________ _________________
_________________ _________________ Operation 1 ()
_________________ Operation 2 ()
Operation 1
_________________
_________________ Operation 4
_________________ Interface B
_________________ _________________
_________________ _________________ Operation 3 ()
_________________ Operation 4 ()
Operation 2
_________________
_________________
_________________
_________________

104 Software Engineering Fundamentals - COC2073

 Design Principles – Interfaces

▪ The specification of a software unit’s interface

describes the externally visible properties of
the software unit
▪ An interface specification should
communicate to other system developers
everything that they need to know to use our
software unit correctly
▪ A software unit’s interface describes what the
unit requires of its environment, as well as
what it provides to its environment
105 Software Engineering Fundamentals - COC2073
 Design Principles - Information Hiding

▪ Information hiding is distinguished by its

guidance for decomposing a system:
‒ Each software unit encapsulates a separate
design decision that could be changed in the
future
‒ Then the interfaces and interface specifications
are used to describe each software unit in terms
of its externally visible properties

106 Software Engineering Fundamentals - COC2073

 Design Principles - Information Hiding

▪ Using this principle, modules may exhibit

different kinds of cohesion
‒ A module that hides a data representation may
be informationally cohesive
‒ A module that hides an algorithm may be
functionally cohesive

▪ A big advantage of information hiding is that

the resulting software units are loosely
coupled
107 Software Engineering Fundamentals - COC2073
 DP - Incremental Development

▪ Given a design consisting of software units

and their interfaces, we can use the
information about the units’ dependencies to
devise an incremental schedule of
development
▪ Start by mapping out the units’ uses relation
‒ relates each software unit to the other software
units on which it depends
▪ Uses graphs can help to identify progressively
larger subsets of our system that we can
implement and test incrementally
108 Software Engineering Fundamentals - COC2073
 DP - Incremental Development

▪ Uses graphs for two designs

1) Fan-in refers to the number of units that use a
particular software unit
2) Fan-out refers to the number of units used by
particular software unit

109 Software Engineering Fundamentals - COC2073

 DP - Incremental Development

▪ We can try to break a cycle in the uses graph

using a technique called sandwiching
‒ One of the cycle’s units is decomposed into two
units, such that one of the new units has no
dependencies
‒ Sandwiching can be applied more than once, to
break either mutual dependencies in tightly
coupled units or long dependency chains

110 Software Engineering Fundamentals - COC2073

 Design Principles - Abstraction

▪ It describes the external behavior of the

component without bothering with the internal
details that produce the behavior

▪ The basic goal of system design is to specify

the modules in a system and their
abstractions

111 Software Engineering Fundamentals - COC2073

 Design Principles - Abstraction

▪ Two common abstraction mechanisms for

software systems
1) Functional Abstraction
2) Data Abstraction

112 Software Engineering Fundamentals - COC2073

 Design Principles - Abstraction

▪ In functional abstraction, a module is

specified by the function it performs

▪ For example, a module to sort an input array

can be represented by the specification of
sorting

113 Software Engineering Fundamentals - COC2073

 Design Principles - Abstraction

▪ There are certain operations required from a

data object, depending on the object and the
environment in which it is used

▪ Data abstraction supports this view

▪ From outside an object, the internals of the

object are hidden; only the operations on the
object are visible

114 Software Engineering Fundamentals - COC2073

 Design Principles - Generality

▪ Generality is the design principle that makes

a software unit as universally applicable as
possible, to increase the chance that it will be
useful in some future system

▪ We make a unit more general by increasing

the number of contexts in which can it be
used

115 Software Engineering Fundamentals - COC2073

 Design Principles - Generality

116 Software Engineering Fundamentals - COC2073

 Function Oriented vs. OO Design

117 Software Engineering Fundamentals - COC2073

 Function Oriented Design

▪ Data is decomposed according to functionality

requirements
▪ Decomposition revolves around function
F1 F2 F3 F4

DS1 DS2 DS3 DS4

118 Software Engineering Fundamentals - COC2073

 Object-Oriented Design

▪ OO paradigm focuses both on the

functionality and the data at the same time

119 Software Engineering Fundamentals - COC2073

 Why Object Oriented Design?

▪ Object-Oriented technology helps in software

modeling of real life objects in a direct and
explicit fashion

▪ Encapsulate data and processes related to a

real life object or process in a single software
entity

120 Software Engineering Fundamentals - COC2073

 Why Object Oriented Design?

▪ It also provides a mechanism so that the

object can inherit properties from their
ancestors, just like real-life objects

▪ An Object-Oriented software system consists

of objects which are:
‒ Hierarchical
‒ Highly Cohesive
‒ Loosely Coupled

121 Software Engineering Fundamentals - COC2073

 OO Design Components

122 Software Engineering Fundamentals - COC2073

 What is Object?

▪ An object can be defined as a tangible entity

that exhibits some well defined behavior
▪ An object has:
Identity
State All of the properties of the object and their
current values
Behavior How an object acts and reacts in terms of
its state changes and message passing

123 Software Engineering Fundamentals - COC2073

 What is Class?

▪ A representation of a type of object

▪ A class is the blueprint from which the

individual objects are created

▪ Class is composed of three things:

- Name
- Attributes
- Operations

124 Software Engineering Fundamentals - COC2073

 What is Class?

▪ A class specifies an interface and defines an

implementation

▪ The interface consists of the declaration of all

the operations applicable to instances of this
class

▪ The implementation of a class consists of the

implementation of all the operations

125 Software Engineering Fundamentals - COC2073

 Class vs. Object

Class

Objects

126 Software Engineering Fundamentals - COC2073

 What is Class - UML Notation
Attributes Class Name

Student
Visibly
+ public - Name:string Return Type
- private - Discipline:string
# protected - CGPA:float
~ package + takeClasses():Integer
+ getCourseRegister():String
+ prepareNotes():String

127 Software Engineering Fundamentals - COC2073

 Abstract Classes

▪ An abstract class Abstract Class

Name
implements an abstract
concept
▪ Main purpose is to be Attributes Vehicle
inherited by other classes - Color
+ Accelerate()
▪ An abstract class cannot be
instantiated
Methods
▪ If any class contains any
abstract functions, then that
class is also abstract
128 Software Engineering Fundamentals - COC2073
 Abstract Classes

Vehicle
- Color
- Model
+ Accelerate()
+ ApplyBrakes()

Car Bus Truck

129 Software Engineering Fundamentals - COC2073

 Abstract Classes

Shape

+ Draw()

Line Circle Triangle

+ Draw() + Draw() + Draw()

130 Software Engineering Fundamentals - COC2073

 Interfaces

▪ Interfaces are much like abstract

Interface
classes Name
▪ Interface is a contract - a class
that implements it is required to <<interface>>
implement all of the methods IDoor
and properties + Open()
▪ No instances of interfaces can
be created Method

▪ In interfaces the definition of the

method is not allowed
131 Software Engineering Fundamentals - COC2073
 Why We Need Interfaces?

Vehicle

+ Door()
+ FillFuel()

Car

+ Reverse()

132 Software Engineering Fundamentals - COC2073

 Why We Need Interfaces?

Vehicle

+ Door()
+ FillFuel()

Car Motorcycle

+ Reverse() + TurnAround()

133 Software Engineering Fundamentals - COC2073

 Why We Need Interfaces?

Vehicle
<<interface>>
IDoor
+ Door()
+ Open() + FillFuel()

Car Motorcycle

+ Reverse() + TurnAround()

134 Software Engineering Fundamentals - COC2073

 Abstract Class vs. Interface

What is the difference between an interface and an

abstract class?

<<interface>> SomeVehicle
Door
+ Open() + drive()
+ open()
Interface
Abstract class

Non of them can be instantiated

Cannot contain implementation Can (but need not to) contain

implementation

135 Software Engineering Fundamentals - COC2073

 Relationship among Classes/Objects

136 Software Engineering Fundamentals - COC2073

 Relationships Among Classes

▪ Association
▪ Aggregation
▪ Composition
▪ Inheritance

137 Software Engineering Fundamentals - COC2073

 Association

▪ It represents a linkage between two classes

▪ Associations are bi-directional i.e. both

classes are involved in a relationship

▪ The line is drawn from the containing to the

contained class

138 Software Engineering Fundamentals - COC2073

 Association - Example

Teacher Course
teaches
+ Salary():int * * + Salary():int
+ Leaves():int + Leaves():int
+ Medical():int + Medical():int

139 Software Engineering Fundamentals - COC2073

 Aggregation

▪ The relationship between the container and

the contained object is called aggregation

▪ Aggregation is “has - a” relationship

▪ A weak Association

▪ Aggregate object can exist independently

140 Software Engineering Fundamentals - COC2073

 Aggregation - Example

Car Wheel
4

141 Software Engineering Fundamentals - COC2073

 Aggregation - Example
Word
Processing
Document

* Picture

Folder

142 Software Engineering Fundamentals - COC2073

 Aggregation - Example
Tables

1..6 White Board

Chair * Class

1
Multimedia

143 Software Engineering Fundamentals - COC2073

 Composition

▪ The relationship between the “part” objects

and the “whole” object is known as
Composition

▪ It’s a strong association

▪ It contains Objects that live and die together

▪ It is represented by a filled diamond shape

from child to parent class with association
144 Software Engineering Fundamentals - COC2073
 Composition

▪ The child class's instance lifecycle is

dependent on the parent class's instance
lifecycle

▪ The part class can only be related to one

instance of the parent class

145 Software Engineering Fundamentals - COC2073

 Composition - Example

Company Department
1 ..
*

146 Software Engineering Fundamentals - COC2073

 Composition - Example

Building

Room

147 Software Engineering Fundamentals - COC2073

 Composition - Example
Head

2 Person 2 Leg
Arm

1
Body

148 Software Engineering Fundamentals - COC2073

 Inheritance

▪ It implies the functionality of data sharing

between Base and Derived class

▪ All the data members and methods of base

class are available for use in derived class but
not vice-versa

▪ Derive class extends the functionality of super

class to use the base class methods

149 Software Engineering Fundamentals - COC2073

 Inheritance - Example
Person
- Name
- Age
- Gender
+ EatFood()
+ Walk()

Student Teacher
- Program - Designation
- StudyYear - Salary
+ Study() + TakeClasses()
+ HeldExam() + takeExam

150 Software Engineering Fundamentals - COC2073

 Inheritance - Example
Person
- Name
- Age
- Gender
+ EatFood()
+ Walk()

Student Teacher
- Program - Designation
- StudyYear - Salary
+ Study() + TakeClasses()
+ HeldExam() + takeExam

151 Software Engineering Fundamentals - COC2073

 Inheritance - Example
Person Doctor
- Name - Designation
- Age - Salary
- Gender
+ CheckUp()
+ EatFood()
+ Prescribe()
+ Walk()

Student Teacher
- Program - Designation
- StudyYear - Salary
+ Study() + TakeClasses()
+ HeldExam() + takeExam

152 Software Engineering Fundamentals - COC2073

 Inheritance - Example
Person
- Name
- Age
- Gender
+ EatFood()
+ Walk()

Student Doctor Teacher

- Program - Designation - Designation
- StudyYear - Salary - Salary
+ Study() + CheckUp() + TakeClasses()
+ HeldExam() + Prescribe() + takeExam

153 Software Engineering Fundamentals - COC2073

 Abbot’s Textual Analysis

154 Software Engineering Fundamentals - COC2073

 Abbot’s Textual Analysis

▪ “Textual Analysis” is a working technique used

to extract model element information from
unstructured information systematically.”
▪ It was initially developed by Abbot and then
extended by Graham and others

▪ In this technique different parts of speech are

identified within the text of the specification
and these parts are modeled using different
components
155 Software Engineering Fundamentals - COC2073
 Abbot’s Textual Analysis

1) A common noun in the informal strategy

suggests a data type

2) A proper noun suggests an object

3) A verb, attribute, predicate, or descriptive

expression suggests an operator

4) The control structures are implied in a

straightforward way by the English
156 Software Engineering Fundamentals - COC2073
 Abbot’s Textual Analysis
Part of Speech Model Component Example
Proper Noun Instance, Object Ahmad
Common Noun Class, Type, Role Student, Teacher
Doing Verb Operation buy
Being Verb Classification is a horse, is a book
Having Verb Composition Fan has wings
Adjective Phrase Association, The customer with
Operation children.
The customer who
bought the Kite.
Intransitive Verb Exception or Event depend

157 Software Engineering Fundamentals - COC2073

 Abbot’s Textual Analysis - Example

▪ The customer enters the store to buy a toy. He

has to be a toy that his daughter likes and it
must cost less than 50 Euros. He tries a video
game, which uses a data glove and a head-
mounted display. He likes it. An assistant helps
him. The suitability of the game depends on the
age of the child. His daughter is only 3 years
old. The assistant recommends another type of
toy, namely the board game “Monopoly".

158 Software Engineering Fundamentals - COC2073

 Abbot’s Textual Analysis - Example

Example Part Of Speech UML Model

Component
“Monopoly” proper noun object
toy improper noun class
buy doing verb operation
recommend doing verb operation
is-a being verb inheritance
has-a having verb aggregation
must be modal verb constraint
dangerous adjective attribute
enter transitive verb operation
depends on intransitive verb constraint, association

159 Software Engineering Fundamentals - COC2073

 Abbot’s Textual Analysis - Example
Customer Store

+ enter()

Daughter
- age

Videogame
suitable

Toy
- price
Boardgame +buy()
+ like()

160 Software Engineering Fundamentals - COC2073

 Interaction Diagrams

161 Software Engineering Fundamentals - COC2073

 Interaction Diagrams

▪ Interaction Diagrams depict the dynamic

behavior of the system

▪ A set of messages exchanged among a set of

objects

▪ Often used to model the way a use case is

realized through a sequence of messages
between objects

162 Software Engineering Fundamentals - COC2073

 Purpose of Interaction Diagrams

▪ Model interactions between objects

▪ Assist in understanding how a system (a use

case) actually works

▪ Verify that a use case description can be

supported by the existing classes

▪ Identify responsibilities/operations and assign

them toSoftware
classesEngineering Fundamentals - COC2073
163
 Mechanisms for Dynamic Behavior

1) Sequence Diagrams: Provide a time-based

view

2) Collaboration Diagrams: Provide an

organization-based view of the system’s
dynamics

164 Software Engineering Fundamentals - COC2073

 The Sequence Diagram

▪ Illustrate how objects interacts with each

other and emphasize time ordering of
messages by showing object interactions
arranged in time sequence

▪ These can be used to model simple

sequential flow, branching, iteration, recursion
and concurrency

165 Software Engineering Fundamentals - COC2073

 The Sequence Diagram

▪ The focus of sequence diagrams is on objects

(and classes) and message exchanges
among them to carry out the scenarios
functionality

▪ The objects are organized in a horizontal line

and the events in a vertical time line

166 Software Engineering Fundamentals - COC2073

 Sequence Diagram - The Notation

▪ The boxes denote objects (or classes)

▪ The solid lines depict messages being sent

from one object to the other

▪ The dotted lines are called life-lines of objects

‒ The life line represents the object’s life during
interaction

167 Software Engineering Fundamentals - COC2073

 Sequence Diagram - The Notation

▪ The syntax used for naming objects in a

sequence diagram is as follows:
Syntax:[instanceName]:[ClassName]
▪ Name classes consistently with your class
diagram (same classes)

▪ Include instance names when objects are

referred to in messages or when several
objects of the same type exist in the diagram

168 Software Engineering Fundamentals - COC2073

 Sequence Diagram - The Notation

▪ If object obj1 sends a message to another

object obj2 an association must exist between
those two objects

▪ A message is represented by an arrow

between the life lines of two objects

▪ Self calls are also allowed. These are the

messages that an object sends to itself

▪ The time required by the receiver object to

169 Software Engineering Fundamentals - COC2073
 Sequence Diagram - The Notation

▪ If object obj1 sends a message to another

object obj2 an association must exist between
those two objects

▪ A message is represented by an arrow

between the life lines of two objects

▪ Self calls are also allowed. These are the

messages that an object sends to itself

▪ The time required by the receiver object to

170 Software Engineering Fundamentals - COC2073
 Sequence Diagram - The Notation
Object
Message
Role :Interface
:CoffeeCustomer

insertCoin()

Activation-box
Life line
machineReady() of object
Time
pressButton(b1)

pourCoffee()

171 Software Engineering Fundamentals - COC2073

 Sequence Diagram - The Notation
X-axis (objects)
Object
Message
Role :Interface
:CoffeeCustomer

insertCoin()

Activation-box
Life line
machineReady() of object
Time
pressButton(b1)

pourCoffee()

Y-axis (time)
172 Software Engineering Fundamentals - COC2073
 Sequence Diagram - Message Types

▪ Synchronous

▪ Asynchronous
<<create>>
▪ Create

<<destroy>>
▪ Destroy

173 Software Engineering Fundamentals - COC2073

 Synchronous Messages

▪ Synchronous messages are “call events”

▪ Denoted by the full arrow

▪ They represent nested flow of control which is

typically implemented as an operation call

▪ The caller waits for the called routine to

complete its operation before moving forward
174 Software Engineering Fundamentals - COC2073
 Synchronous Messages

:object1 :object2
Caller Blocked

areYouOK( ) Return

yes

175 Software Engineering Fundamentals - COC2073

 Asynchronous Messages

▪ Asynchronous messages are “signals”

▪ They are denoted by a half arrow

▪ They do not block the caller

▪ Occurs in multi-threaded or multiprocessing

applications where different execution threads
may pass information to one another by
sending asynchronous messages to each
other
176 Software Engineering Fundamentals - COC2073
 Asynchronous Messages

▪ Asynchronous messages typically perform the

following actions:
‒ Create a new thread

‒ Create a new object

‒ Communicate with a thread that is already

running

177 Software Engineering Fundamentals - COC2073

 Object Creation & Destruction

▪ An object may create another object via a

<<create>> message

▪ An object may destroy another object via a

<<destroy>> message

▪ An object may also destroy itself

▪ Should be use only when memory

management is critical
Software Engineering Fundamentals - COC2073
178
 Object Creation & Destruction

courseForm CurManage aCourse

:Registrar
:CourseForm :CurriculmManager :Course

1:setCourseInfo

2: process

3: addCourse

4: <create>>

179 Software Engineering Fundamentals - COC2073

 Object Creation & Destruction

:object1 :object2

<<destroy>>

180 Software Engineering Fundamentals - COC2073

 Practice Task - Statement

▪ Draw a class diagram representing a book

defined by the following statement: “A book is
composed of a number of parts, which in turn
are composed of a number of chapters ,
which in turn are composed of a number of
Sections.

181 Software Engineering Fundamentals - COC2073

 Practice Task - Statement

▪ Draw a class diagram representing a book

defined by the following statement: “A book is
composed of a number of parts, which in turn
are composed of a number of chapters ,
which in turn are composed of a number of
Sections.

182 Software Engineering Fundamentals - COC2073

 Practice Task - Solution

Book Parts

Chapters Sections

183 Software Engineering Fundamentals - COC2073

 Software Design Practice

184 Software Engineering Fundamentals - COC2073

 Practice Task 1 - Statement

▪ “Consider the world of libraries. A library has

books, videos, and CDs that it loans to its
users. All library material has an ID and a title.
In addition, books have one or more authors,
videos have one producer and one or more
actors, while CDs have one or more
entertainers.”

185 Software Engineering Fundamentals - COC2073

 Practice Task 1 - Statement

▪ “Consider the world of libraries. A library has

books, videos, and CDs that it loans to its
users. All library material has an ID and a title.
In addition, books have one or more authors,
videos have one producer and one or more
actors, while CDs have one or more
entertainers.”

186 Software Engineering Fundamentals - COC2073

 Practice Task 1 - Statement

▪ “Consider the world of libraries. A library has

books, videos, and CDs that it loans to its
users. All library material has an ID and a title.
In addition, books have one or more authors,
videos have one producer and one or more
actors, while CDs have one or more
entertainers.”

187 Software Engineering Fundamentals - COC2073

 Practice Task 1 - Statement

LibraryItem Person
- id - name
- title

1..* author
1..* entertainer
1 producer
Book Video CD

1..* actor
0..* 0..* 0..*

188 Software Engineering Fundamentals - COC2073

 Practice Task 2 - Statement

▪ A hockey league is made up of at least four hockey

teams. Each hockey team is composed of six to
twelve players, and one player captains the team.
A team has a name and a record. Players have a
number and a position. Hockey teams play games
against each other. Each game has a score and a
location. Teams are sometimes lead by a coach. A
coach has a level of accreditation and a number of
years of experience, and can coach multiple
teams. Coaches and players are people, and
people have names and addresses.

189 Software Engineering Fundamentals - COC2073

 Practice Task 2 - Statement

▪ A hockey league is made up of at least four hockey

teams. Each hockey team is composed of six to
twelve players, and one player captains the team.
A team has a name and a record. Players have a
number and a position. Hockey teams play games
against each other. Each game has a score and a
location. Teams are sometimes lead by a coach. A
coach has a level of accreditation and a number of
years of experience, and can coach multiple
teams. Coaches and players are people, and
people have names and addresses.

190 Software Engineering Fundamentals - COC2073

 Practice Task 2 - Solution
Person
name
address

Game Coach Player

Score Level Number
location Experience position

League Team Captain

name
record

191 Software Engineering Fundamentals - COC2073

 Practice Task 2 - Solution
Person
name
address

Game Coach Player

Score Level Number
location Experience position

* 0..1 6..12
1
1 2 *
4..*
League Team Captain
name 1 1
record

192 Software Engineering Fundamentals - COC2073

 Recap

▪ Software Architecture Attributes

▪ Partitioning the Architecture
▪ Architectural Styles
– Repository Architecture, Client - Server
Architecture, Pipes & Filters Architecture, Layered
Architecture
▪ Software Design Principles
– OO Design Components
– Relationship among Classes
▪ Abbot’s Textual Analysis
▪ The Sequence Diagram
193 Software Engineering Fundamentals - COC2073
 Questions

194 Software Engineering Fundamentals - COC2073