DESIGN PATTERN Page |1

MODULE Design Pattern

INTAKE CODE UC3F1801SE

LECTURER Muhammad Ehsan Rana

DUE DATE 03-May-2018

STUDENT NAME Md Naim Chowdhury

TP NUMBER TP040274
DESIGN PATTERN Page |2

Table of Contents
Section 2: Implementation ....................................................................................................... 3
2.1 Design and Implementation using Simpler Solution ................................................................... 4
2.1.1 UML Diagram ................................................................................................................ 4
2.1.2 Source Code ................................................................................................................... 5
2.2 Design and Implementation using Factory Design Pattern based Solution .................................... 7
2.2.1 UML Diagram ................................................................................................................ 7
2.2.2 Source Code ................................................................................................................... 8
2.3 Design and Implementation using Proxy Design Pattern based Solution .................................... 11
2.3.1 UML Diagram .............................................................................................................. 11
2.3.2 Source Code ............................................................................................................. 12
Section 3: Analysis and Discussion ........................................................................................ 14
3.1 Measuring technique for the Selected Quality Attribute: .......................................................... 15
3.2 Analysis of the Results: ........................................................................................................ 17
3.2.1 Shape Maker’s system analysis: ...................................................................................... 17
3.2.2 Image View’s system analysis: ........................................................................................ 17
3.3 Discussion: ......................................................................................................................... 18
3.4 Conclusion: ........................................................................................................................ 19
DESIGN PATTERN Page |3

Section 2:
Implementation
DESIGN PATTERN Page |4

2.1 Design and Implementation using Simpler Solution

2.1.1 UML Diagram
Simple System 1:

Simple System 2:
DESIGN PATTERN Page |5

2.1.2 Source Code

Simple System 1:

Main Class:

Interface class:

Child classes:
DESIGN PATTERN Page |6

Simple System 2:

Main Class:
DESIGN PATTERN Page |7

Interface class:

Child Class:

2.2 Design and Implementation using Factory Design Pattern based Solution
2.2.1 UML Diagram
DESIGN PATTERN Page |8

2.2.2 Source Code

Main Class:
DESIGN PATTERN Page |9

Interface class:

Child classes:
DESIGN PATTERN P a g e | 10

Factory Class:
DESIGN PATTERN P a g e | 11

2.3 Design and Implementation using Proxy Design Pattern based Solution
2.3.1 UML Diagram
DESIGN PATTERN P a g e | 12

2.3.2 Source Code

Main Class:

Interface class:

Child Classes:
DESIGN PATTERN P a g e | 13
DESIGN PATTERN P a g e | 14

Section 3:
Analysis and Discussion
DESIGN PATTERN P a g e | 15

3.1 Measuring technique for the Selected Quality Attribute:

An external software reliability metric of ISO/IEC 9126 (ISO/IEC, n.d.) should be able to
measure attributes related to the software failure times. Software reliability consists of the
maturity metrics, fault tolerance metrics, recoverability metrics, reliability compliance metrics.
Also, Maturity metrics consist of the estimated latent failure density, estimated latent fault
density, failure density etc.
But, we can calculate this measure by using the software failure time distribution. It is difficult
to get the software failure time data. So, we try to the survey for measuring of software
reliability metrics.
We present our result the number of failure for one month. For example, the questions as
follows;
The product analysed in this paper is a data through the survey. Respondents were asked to
answer the satisfaction of the software product quality on the seven categories rating scale:
“Very Very Dissatisfied”, “Very Dissatisfied”, “Dissatisfied”, “Neutral”, “Satisfied”, “Very
Satisfied”, “Very Very Satisfied”
• How many failures were detected during one month?
• How many faults were detected during one month?
• How many failure conditions are resolved?
• How often the software product causes the break down?
Also, we predict the quality of software product by using the satisfaction survey. If the causes
of failure occur according to a Poisson distribution. The times between failures are independent
exponential variables, and the data constitutes a random sample of sample size from
exponential with parameter 1/φ. A variable or distribution would arise if one discusses the
number of occurrences in some time interval. For each interval the number of failures follows
a poisson distribution with parameter µ=φt. For example, specifically the Goel & Okumoto
model assumes that the failure process is modelled by Nonhomogeneous Poisson Process
model with mean value function m(t) given by
m(t)=a(1-exp(-φt)), a>0, b>0
where a and b are parameters to be determined using collected failure data. Note that for Goel
& Okumoto model, we have
m (∞) = a, and m (0) = 0.
DESIGN PATTERN P a g e | 16

Since m (∞) is the expected number of faults which will eventually be detected, the parameter
a is the final number of faults that can be detected by the testing process.
Table 1. Frequency Table
Number of Failure Frequency Probability
0
1
2
3
4
5

The value of φ is unknown, but sample mean is a good estimate of E(T)=1/φ. We estimate the
mean, parameter a, and φ after the one-month test period.

Table 2. Mean and Estimation of parameters

Mean
Φ
a

We estimated the mean, parameter a, and φ using the homogeneous poisson distribution. So,
we can calculate the value of mean value function m(t) and hazard rates r(t) on based true mean
value M(t).

Table 3. Mean value and hazard rate

M(t)
m(t)
r(t)

We apply the simple homogeneous poisson software reliability model. By using the mean φ,
we can calculate the software reliability by software GOMMA-LOMAX model (Jung & Yang,
2005).
DESIGN PATTERN P a g e | 17

3.2 Analysis of the Results:

3.2.1 Shape Maker’s system analysis:

Table 1. Frequency Table

Simple System With Factory Simple System With Factory
Number of Frequency Frequency Probability Probability
Failure
0 8 3 0.21052632 0.03256659
1 15 1 0.39646568 0.02634864
2 7 0 0.18465965 0.00000000
3 7 2 0.18465965 0.02856564
4 8 2 0.21052632 0.02856564
5 1 0 0.02634864 0.00000000

Table 2. Mean and Estimation of parameters

Simple System With Factory
Mean 1.447368421 2.154656898
Φ 0.048245614 0.052656464
a 71091313439 85565965636

Table 3. Mean value and hazard rate

Simple System With Factory
M(t) 55 45
m(t) 54.1640112 44.1644817
r(t) 0.43344567 0.38344596

3.2.2 Image View’s system analysis:

Table 1. Frequency Table

DESIGN PATTERN P a g e | 18

Simple With Simple System With Proxy

System Proxy
Number of Frequency Frequency Probability Probability
Failure
0 7 1 0.18465965 0.02634864
1 1 1 0.02634864 0.02634864
2 7 0 0.18465965 0.00000000
3 8 3 0.21052632 0.03256659
4 8 2 0.21052632 0.02856564
5 15 4 0.39646568 0.04569865

Table 2. Mean and Estimation of parameters

Simple System With Proxy
Mean 1.596526565 3.266565457
Φ 0.056526565 0.089656595
a 54864756646 7926713564

Table 3. Mean value and hazard rate

Simple System With Proxy
M(t) 57 49
m(t) 55.15652656 46.985632145
r(t) 0.475646456 0.3569784569

3.3 Discussion:
In our simple shape maker system, chances of failure are higher. This can be depicted in table
which is used to identify frequencies and probabilities of system failure by comparing simpler
solution and factory design pattern for our shape maker system. In a simpler shape maker
system, the system failed to run 15 times when it was run for the first time. In order for our
system to run better, I have applied factory design pattern which clearly indicates from our
frequency table in figure 1. The results clearly indicate that using factory design pattern, our
DESIGN PATTERN P a g e | 19

system has improved significantly. Only two times our system failed when it was run fourth
time consecutively as compared to 8th time while using simpler solutions. Factory method
helped system to hide implementation which is a core interface that make up the application.
It also shows the design of your application more readily which is also known as loose
coupling. Overall using factory method has been very useful for shape maker system.

In image viewer system, simpler solutions are not useful. From the statistical analysis, it shows
that the system has failed 5 times when it is executed 15 times. There were seven occasions
when system did not fail. After applying the proxy design pattern, system becomes much
improved as acknowledged by frequency table. As compared to simpler solution, the chances
of failure are much reduced and image viewer run smoothly using proxy design pattern. Proxies
have helped to improve the performance of our system by caching frequently accessed objects

3.4 Conclusion:

In software development, design pattern is generally a reusable solution to problems which

commonly occurs in software design. It gives developer a common vocabulary to talk about
software solutions. Design patterns are used to represent some of the best practices adapted by
experienced object-oriented software developers. It can speed up the development process by
providing tested and proven development paradigms. Reusing design patterns helps to resolve
issues which can cause major problems and improves code readability for programmers and
architects familiar with the patterns.

For this project I have used proxy and factory for the solution of Image Viewer and Shape
Maker respectively. Proxy provides a placeholder for an object to control reference to it and
factory design pattern defines an interface for creating objects but let subclasses to decide
which class to instantiate and refers to the newly created object through common interface
DESIGN PATTERN P a g e | 20

References
Engineering, B. P. S., 2018. Best Practice Software Engineering. [Online]
Available at: http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/facade.html
[Accessed 1/5/18 May 2018].
ISO/IEC, 9., n.d. Information Technology -Software Quality Characteristics and metrics Part 1,2,3.
[Online]
Available at: https://sci-hub.tw/https://link.springer.com/chapter/10.1007/11424857_81
[Accessed 01 May 2019].
Jung, H.-J. & Yang, H.-S., 2005. Software Reliability Measurement Use Software. [Online]
Available at: https://sci-hub.tw/https:/link.springer.com/chapter/10.1007/11424857_81
[Accessed 01 May 2018].
Umair, M., 2016. What Are Software Design Patterns Hiding From You?. [Online]
Available at: https://simpleprogrammer.com/software-design-patterns-hiding/
[Accessed 1/5/18 May 2018].