Table of Contents

Abstract ..........................................................................................Error! Bookmark not defined.

Introduction ....................................................................................Error! Bookmark not defined.

Literature Review...........................................................................Error! Bookmark not defined.

Section 2 – Design & Implementation ............................................................................................ 2

2.1.0 Adapter Design Pattern .................................................................................................... 11

2.1.1 Design and Implementation using Simpler Solution ................................................... 11

2.1.2 Design and Implementation using Adapter Design Pattern based Solution ................ 12

2.2.0 Abstract Factory Design Pattern ...................................................................................... 15

2.2.1 Design and Implementation using Simpler Solution ................................................... 16

2.2.2 Design and Implementation using Abstract Factory Design Pattern based Solution .. 17

Section 3 – Analysis and Discussion ............................................................................................ 23

3.1 Simple Solution 1 and Adapter Design Pattern .................................................................. 24

3.2 Simple Solution 2 and Abstract Factory ............................................................................. 28

3.3 Discussion ........................................................................................................................... 33

References ..................................................................................................................................... 35

1
Abstract

The degree of portability of a software can be seen as a desirable attribute as portability is

brings forth increased value and lifespan of a software (Mooney, 1993). However, portability isn’t
addressed explicitly in the field of software engineering or software development methodologies.
More on that, there are substantial literature from academic research that are focused on design
patterns and its impact on portability of software system.

A study on the use of design patterns to improve the quality of object-oriented software
systems, particularly on portability was carried out. Our overall goal was to research on portability
and its implications on software architecture and looking into the effects of applying design
patterns in terms of portability. Design patterns from the book, Design Patterns: Elements of
Reusable Object-Oriented Software by Gang of Four were used as the basis or reference for design
patterns. The paper first describes briefly an introduction to portability based on the McCall’s
model. Then design patterns were chosen and implemented by considering its effect on portability.
Finally, empirical evidence is produced to support the claims of improved portability when
applying design patterns.

We argue the need for use of design patterns to improve portability. Further discussion to
formalize the concepts has been taken extensively.

2
Introduction

Portability has been recognized as a favourable quality factors in terms of international

standards. Portability is the “degree of effectiveness and efficiency with which a system, product
or component can be transferred from one hardware, software or other operational or usage
environment to another” (ISO/IEC, 2011). Software that were designed with portability as one of
the key main attributes can benefit from pro-longed lifecycle further extending its usefulness
(Mooney, 1993). In a utopian sense, universal computing environment is still envisioned by many,
but it wouldn’t be a reality anytime soon.

It’s been said that software outlived its hardware and portability would be the key in
unlocking its potential or viability. Thus, portability should be at the foundation of every software
development processes.

The purpose of this paper is to establish that grounds for improving portability in object-
oriented software systems through the use of design patterns. As portability can be a reoccurring
issue which relevant design patterns could help tackle. Design patterns are reused or put into use
during the design stage of requirement engineering. It makes design pattern crucial in determining
the outcome of a software system as quality of a software is often times associated with the
outcome. Concepts like objects, interfaces, inheritance, classes could be well understood by
majority of software engineers. But the challenge lies in applying these concepts to build reusable
software, flexible, and design patterns would be the key to solve them.

The paper is organized as follows: section 1 outlines the perspective from literature as part
of the research on portability. Design and implementation are considered in detail in sections 2.
Section 2 also features examples from 3 different use of design patterns with the help of UML for
visualization and Java for code implementation. Final section would outline the final analysis and
discussion on design patterns and its improvement on software portability. Specifications and
metrics would be required for the final section to evaluate the use of design patterns and its impact
on portability.

3
Literature Review

The McCall’s Model or also known as General Electrics Model of 1977 has since been
revised and which several quality factors were associated with it. McCall’s Model provided three
perspective that are essential in providing a high level definition in identifying the quality of a
software product. These three perspectives are product operation, product revision and product
transition (Jamwal, 2010). Portability is covered in the product transition category within the
model, whereby product transition is how a product adapts to new environment given that it also
experiences rapidly changing hardware (Jamwal, 2010). Quality as defined by ISO/IEC
25010:2011 is the “degree to which the system satisfies the stated and implied needs of its various
stakeholders and thus provides value” (ISO/IEC, 2011) . The definition implies that the quality of
a system would depend on the degree to which it satisfies a several set of characteristics, for
example usability, integrity, efficiency, portability etc. These quality characteristics Portability
was chosen as the quality attribute whereby an investigation of the effects applying design patterns
would be carried out.

Figure 1: Quality Model (ISO/IEC, 2011)

Portability, adapted from ISO/IEC 25010:2011, is the “degree of effectiveness and

efficiency with which a system, product or component can be transferred from one hardware,
software or other operational or usage environment to another”. It consisted of several sub-
characteristics such as replaceability, installability and adaptability (ISO/IEC, 2011). In other
words, portability is the ease with which the design pattern used when designing the software

4
architecture can be moved from one environment (software system) to another (Khosravi &
Guéhéneuc, 2004). Simply, portability allows an application to run on multiple environment while
considering the application’s performance. Some software performance might be hindered due to
underlying software layers that are concerned with the Input/Output scheduler (Shafer, et al.,
2010) .

The importance of it in software system would help software to be ported to an updated

and better systems if they are available, which means that this would help the software system to
scale more effectively. Portable software will be meaningful with respect to one or many
environments as it is an alternative to redevelopment. The aim is lower the cost to porting a
software. Aside from that, any software system that requires to hit the mass market while
leveraging on the cost in hand would definitely benefits from portability has it allows
implementations on as many platforms as possible. (Mooney, 1997). In modern day distributed
filesystem such as Hadoop, portability can reduce installation complexity because development is
simplified. This in turn, encourages the spread of parallel computing paradigm (Shafer, et al.,
2010).

As said, portability or the degree of portability can be associated with the function of the
porting and redevelopment costs, with respect to a specific target environment (Mooney, 1997).
Thus, programmers that aims for portability would tend to increase the degree of portability of a
software system, and this has significance effects on software designs. A way to try to achieve
portability is to forbid the use of constructs that would cause issues when ported to another
hardware or computer. This would effectively prevent system software from being written thus it
would be advisable in turn to isolate any necessary implementation-dependent pieces, in layman
terms, isolate dependencies. Portability can be said to be successful if any of the interfaces for a
given software unit could be made to appear identical in many different environments (Mooney,
1997). Another technique to achieve portability is by using levels of abstraction. The levels of
abstraction would help separate and allow only specific level to be rewritten when ported to a new
workstation if they do not interface with the actual hardware (Schach, 2008).

Some attributes associated with portability could be expressed in the its sub-
characteristics and the International Standard has a made a revision that incorporates the same
software quality characteristics with extra amendments. In the previous ISO/IEC 9126-1, “Co-

5
existence” has been moved and the current version states portability’s sub-characteristics as
adaptability, installability and replaceability (ISO/IEC, 2011). Adaptability by definition is “the
degree to which a product or system (software) can effectively and efficiently be adapted for
different or evolving hardware, software or other operational or usage environments” (ISO/IEC,
2011). More than that, installability states “the degree of effectiveness and efficiency with which
a product or system can be successfully installed and uninstalled in a specific environment. Last
but not least, replaceability is the degree to which a product can replace another specified software
product for the same purpose in the same environment” (ISO/IEC, 2011). These attributes greatly
affect which design patterns that are fit for portable purposes.

Design patterns can be said to pursue an intent, simply a way of doing something that
emphasize on using classes and their methods in an object-oriented language (Metsker, 2002).
These particular designs can be used to solve a problem that occurs over and over again by reusing
successful designs and architectures. Design patterns suggested by Gang of Four currently has 23
design patterns but no set of criteria establishes any number of patterns (Gamma, et al., 1995).
They are divided into 3 categories such as creational patterns, structural patterns and behavioral
patterns. How the patterns are categorized are based on their functionality (reflects what a pattern
does) and scope (specifies whether the pattern applies primarily to classes or to objects) (Gamma,
et al., 1995). Even though great emphasis has been put on design patterns by Gang of Four but
they are not the only software patterns.

Figure 1: Design Pattern Space (Gamma, et al., 1995)

In many cases, the use of design patterns usually is about trade-off. This has led to difficulty
in assessing the effect of patterns on software quality in a conventional way while not having the

6
context such as adaptability or flexibility etc. Thus, any designer would first consider what quality
factor is more crucial then decide which pattern to be used (Ampatzogloua, et al., 2013).
Nevertheless, in general, there are benefits of design patterns, first, it provided a proven solution
when solving problems related to software development that has occurred repeatedly multiple
times. Design patterns encourages discovery and learning that aims to help designers to use well-
known and proven designs by experts (Chih-HungChang, et al., 2011). Second, patterns make the
communication of development team easier (R.Subburaj, et al., 2015). This is because across
designers and programmers that has experience in software development, through their captured
experience, design patterns can be used as a communication tool (Cline, 1996). Third, successful
design patterns promote reusability and portability, and avoid alternatives that diminish reusability
(R.Subburaj, et al., 2015). Design patterns can be used in software architecture and it would
increase flexibility and reusability of a system, if used properly.

The consequences or impacts are the trade-offs in applying any design patterns. Reusability
is a prime factor in object-oriented design whereby the impact of a pattern on systems includes
portability, flexibility or adaptibility. Achieving portability across hardware and software
platforms is a major issue in system design. Portability has an obstacle which is the myriad
diversity in look and feel standards. Thus, the design pattern used, must allow the application to
run on more than one various platform while conforming to the user interface style. Another impact
on portability would be on the windowing environment a software runs in. Some software would
need to run on multiple operating systems such as Macintosh and Windows. A platform's window
system creates the illusion of multiple overlapping windows on a bitmapped display (Gamma, et
al., 1995).

The beauty of design patterns is where patterns can interact with other patterns. Thus, in
practice, it would be unusual for a product to only use one pattern (Schach, 2008). Several design
patterns are used to improve portability which are Reactor, Adapter and Abstract Factory pattern.
The Reactor pattern’s intent is to dispatch handlers automatically as soon as events occur from
multiple sources such as communication software (Schmidt, 1995). More than that, if an individual
event handler has characteristics such as the ability to preprocess received messages in a short
amount of time and exchanging fixed sized messages without blocking the I/O. By using Reactor
pattern, it improves application portability as it allows interface to be reused independently of the

7
underlying OS system calls that perform even demultiplexing (Schmidt, 1995). Beside that,
Adapter pattern improves portability by complementing the interface on the clients through
converting the interface of the adaptee. It proves useful when it allows classes work together
despite incompatible interfaces (Gamma, et al., 1995). For example, a given toolkit class designed
for reuse would be deemed not reusable because incompatible interface with the client. The class
Adapter would override some of adaptee’s behavior thus converting it and making it compatible
again. This permits communication between two objects with incompatible interfaces. The
Adapter design also provided a way for object to access internal implementation without coupling
to structure. Lastly, Abstract Factory pattern provided an interface for creating sets of related or
dependent objects without specifying the concrete classes (Gamma, et al., 1995). Each look and
feel standards are considered challenges in portability but Abstract Factory pattern can declare an
interface for creating basic kind of look and feel classes (widgets), and these widgets for specific
look-and-feel could be implemented by the concrete subclasses (Gamma, et al., 1995).

Metrics define “a basis for quantitative measurements of significant properties of software

and of software development and maintenance activities” (Mooney, 1993). There are metrics that
are related to portability where it can be used when evaluating myriad techniques and document
properties of the software system. During development, standard cost estimation techniques are
used to calculate the cost penalties incurred when porting a software. Where else, during
maintenance phase, given the product and the specific target environment, cost of both porting and
redevelopment may be estimated. Thus, porting cost would involve the match between interface
of software and the target environment (Mooney, 1997). Metrics related to portability can help
characterize the costs and benefits of incorporating portability when designing software (Mooney,
1993). There are very few attempts to measure portability. But portability testing are related and
derives from its sub-characteristics which are installability, adaptability, and replaceability. One
was suggested by Mooney but it was not derived based on international standards and no
distinction was made between the measure itself in relation to the cost estimation model which is
linked to portability, the degree of portability can be computed using (Mooney, 1993):

𝑫𝑷 = 𝟏 – (𝒄𝒐𝒔𝒕 𝒕𝒐 𝒑𝒐𝒓𝒕 / 𝒄𝒐𝒔𝒕 𝒕𝒐 𝒓𝒆𝒅𝒆𝒗𝒆𝒍𝒐𝒑)

If DP is greater than zero, then the porting is more cost effective than redevelopment. A value of
one means it has “perfect portability”. Where else, another paper by Alain et al provided a

8
standards-based reference framework for system’s portability requirement. Based on international
standard from ECSS, IEEE-830, ISO 9126, ISO 24765 and ISO 2382-1 with different point of
view. The framework can be used for identification of system portability requirements (Abran, et
al., 2013). Suggested by Yang H. et al, it uses a Goal Question Metric approach as a process-
oriented metrics for software architecture adaptability. It is a form of quantitative metrics that
revolves around its goal. The metrics implementation phase includes data collection, analysis and
interpretation (Yang, et al., 2010). However, a new reusability model for black-box components
from the viewpoint of component users was defined. It was based on the McCall’s Factor-Criteria-
Metrics. Which it also complies to international standards like ISO (ISO 9126) to asses software
quality.

Figure 2: Black-box component reusability model (Washizaki, et al., 2003)

For portability, the Self-Completeness of Component’s Return Value (SCCr) and Self-
Completeness of Component’s Parameter will be the main metrics used for measuring portability
(Washizaki, et al., 2003). The SCCr is the percentage of business methods without any return value
in all business methods implemented within a component c:

9
 Figure 3: SCCr (Washizaki, et al., 2003)

SCCP, the percentage of business methods without any parameters in all business methods
implemented within a component c:

Figure 4: SCCp (Washizaki, et al., 2003)

Figure below will show the comparison between measurement values and only SCCr and SCCp
are taken into consideration for portability.

Figure 5: Comparison of measurement values (Washizaki, et al., 2003)

As a conclusion, it is crucial to incorporate portability when designing software because of

its benefit but there aren’t much emphasis on software portability. Portability can be seen as an
additional quality factor, but it should deserve equal importance compared to other quality factors.
This has led it to be viewed as a side objective during software development. Based on the work
reported, using design patterns for improving portability should be explored using real world
implementation. Besides that, more measuring technique should be available for to measure
portability in future research.

10
Section 2 – Design & Implementation

In section two, two different design patterns (Adapter and Abstract Factory) would be
applied on two different application respectively. But before applying it, a simpler solution or brute
force solution would be used first. The selection of design patterns was made based on Portability
as its main quality attribute.

2.1.0 Adapter Design Pattern

Adapter design pattern – “Convert the interface of a class into another interface that clients
expect. The adapter pattern lets classes work together that couldn’t otherwise because of
incompatible interface” (Gamma, et al., 1995).

Application

A life insurance company recently wanted to update their insurance policies whereby in
the past, it depended on both the age and gender of a person to determine if a person is eligible for
premiums but it has decided that certain policies would be gender neutral. Currently, the premiums
have been computed by using method (getPremium) in a class called Insurance by just passing the
age and gender. But the new system would only require an age input for certain policies. This
poses an interfacing issue.

2.1.1 Design and Implementation using Simpler Solution

Simpler solution can be achieved by using a Wrapper Solution.

11
2.1.2 Design and Implementation using Adapter Design Pattern based Solution
To deal with this kind of incompatibility between those interfaces, we may need to introduce
adapters.

12
Figure 3: UML Class Diagram

Figure

13
14
2.2.0 Abstract Factory Design Pattern
Abstract factory – “Provide an interface for creating families of related or dependent
objects without specifying their concrete classes (Gamma, et al., 1995)”. As software that are
requires portability as its main quality factor would face issues in standardizing its look-and-feel
when ported to another user environment. User want to use software that are easier to use due to
consistent standards and it also looks more professional. This includes standardizing button sizes,
fonts, background and foreground colours, border widths and many other component attributes
(Metsker, 2002).

Application

Based on the problem surround standardizing look and feel, taking as an example the use
of widget generator. A software organization would like to use the widget generator, which is a
tool that assists developers in constructing the graphical user interface. Without redeveloping the
widgets (windows, buttons and scroll bars), it can reuse a set of classes created by the widget
generator that define the widgets to be utilized within the application program. In this case, the
application program would be required to run in different operating systems such as Linux, Mac
OS and Windows. For example, under Linux, when createLinux menu or createWindow is sent, a
menu should be generated but under Mac OS, every instance should be replaced by Mac OS menu.

15
2.2.1 Design and Implementation using Simpler Solution
The widget generator hard-codes routines that run under one specific system into an
application program. This will make it difficult to modify that application program in the future,
replacing the generated routines with different routines that run under a different operating system.
For example, suppose that the application program is to run under Linux. Then, every time a menu
is to be generated, message getLinuxMenuName is sent. However, if that application program now
needs to run under Mac OS, every instance of create Linux menu must be replaced by
getMacMenuName. For a large application program, such a conversion from Linux to Mac OS is
laborious and fault prone.

16
2.2.2 Design and Implementation using Abstract Factory Design Pattern based
Solution

Figure

17
18
19
20
21
22
Section 3 – Analysis and Discussion

Through the research conducted, the Black-box component reusability model would be
used as the model for evaluating the solutions (Washizaki, et al., 2003).. The solutions featured
two design pattern, which are Adapter and Abstract Factory, followed by their simple solutions
respectively.

Figure 2: Black-box component reusability model (Washizaki, et al., 2003)

External dependency would be the main focused as it leads to portability, which is the key quality
factor. External dependency is the component’s degree of independence from the rest of the
software which originally used the component (Washizaki, et al., 2003). By calling the method
from the class, the function could be provided. Thus the method business method implemented
within the class or component will have an effect on the external dependency. It can be said that
methods without parameters or return value would provide function that are self-completed within
the component.

SCCr and SCCp will be the preferred measuring technique for portability and will be
applied to both design patterns and their simple solution.

23
3.1 Simple Solution 1 and Adapter Design Pattern
Self-Completeness of Component’s Return Value (SCCr)

SCCr is the component’s degree of self-completeness and the low degree of external
dependency for users of the components. The smaller the number of methods without return value,
the small the possibility of component having external dependency. With high SCCr value, it leads
to high portability (Washizaki, et al., 2003).

SCCr will be used to evaluate Adapter and Abstract Factory:

Figure 3: SCCr (Washizaki, et al., 2003)

Based on the formula given, calculation will be performed below:

1) Simple solution 1

1
𝑆𝐶𝐶𝑟(𝐼𝑛𝑠𝑢𝑟𝑟𝑎𝑛𝑐𝑒) = {1
1
1
𝑆𝐶𝐶𝑟(𝑊𝑟𝑎𝑝𝑝𝑒𝑟) = {1
1
1
𝑆𝐶𝐶𝑟(𝑁𝑒𝑢𝑡𝑟𝑎𝑙𝐴𝑝𝑝𝑙𝑖𝑐𝑎𝑡𝑛𝑡) = {1
1

24
 2) Adapter Design Pattern

0
𝑆𝐶𝐶𝑟(𝐼𝑛𝑠𝑢𝑟𝑟𝑎𝑛𝑐𝑒) = {1
1
0
𝑆𝐶𝐶𝑟(𝐼𝑛𝑠𝑢𝑟𝑎𝑛𝑐𝑒𝐴𝑑𝑎𝑝𝑡𝑒𝑟) = {1
1
0
𝑆𝐶𝐶𝑟(𝑁𝑒𝑢𝑡𝑟𝑎𝑙𝑃𝑟𝑒𝑚𝑖𝑢𝑚) = {1
1

Design Patterns Number of Class Average SCCr

Simple Solution 1 3 1
Adapter Design Pattern 3 1

Simple solution 1 and Adapter design pattern has the same average SCCr score. This is
given that they have small number of class to provide a significant value. In Java language, void
represents no value, thus simple solution 1 has three methods with zero return value. But in Adapter
Design Pattern, it doesn’t have any void methods but the number of methods present was too small
to provide an accurate calculation. It would be difficult to judge the portability only using the value
of SCCr, thus SCCp will be used in the next section.

25
Self-Completeness of Component’s Parameter

Self-Completeness of Component’s Parameter (SCCp) indicates the component’s degree

of self-completeness, and low degree of external dependency for users of the component. Less
number of methods with without parameters, results in smaller external dependency (Washizaki,
et al., 2003).

Figure 4: SCCp (Washizaki, et al., 2003)

Based on the formulas given, calculation will be carried out below:

1) Simple solution 1:

0
𝑆𝐶𝐶𝑝(𝐼𝑛𝑠𝑢𝑟𝑟𝑎𝑛𝑐𝑒) = {1
1

0
𝑆𝐶𝐶𝑝(𝑊𝑟𝑎𝑝𝑝𝑒𝑟𝐶𝑙𝑎𝑠𝑠) = {1
1

0
𝑆𝐶𝐶𝑝(𝑁𝑒𝑢𝑡𝑟𝑎𝑙𝐴𝑝𝑝𝑙𝑖𝑐𝑎𝑛𝑡) = {1
1

26
 2) Adapter Design Pattern

0
𝑆𝐶𝐶𝑝(𝐼𝑛𝑠𝑢𝑟𝑟𝑎𝑛𝑐𝑒) = {1
1

0
𝑆𝐶𝐶𝑝(𝐼𝑛𝑠𝑢𝑟𝑟𝑎𝑛𝑐𝑒𝐴𝑑𝑎𝑝𝑡𝑒𝑟) = {1
1

0
𝑆𝐶𝐶𝑟(𝑁𝑒𝑢𝑡𝑟𝑎𝑙𝑃𝑟𝑒𝑚𝑖𝑢𝑚) = {1
1

Design Patterns Number of Class Average SCCp

Simple Solution 1 3 1
Adapter Design Pattern 3 1

Analysis of the results

SCCp has a similar result compared to SCCr, due to small number of class present,
significant result could not be obtained to show the usage of design patterns would improve
portability. But in terms of Adapter design patterns, it is more useful than that, it provided a way

27
for an object to permit access to its internal implementation in such a way that clients are not
coupled to the structure of the internal implementation. This promotes information hiding without
having to hide any implementation detail.

3.2 Simple Solution 2 and Abstract Factory

Using Self-Completeness of Component’s Return Value (SCCr)

1. Simple Solution 2

2
𝑆𝐶𝐶𝑟(𝑊𝑖𝑑𝑔𝑒𝑡𝐺𝑒𝑛𝑒𝑟𝑎𝑡𝑜𝑟) = {2
1

2. Abstract Factory Pattern

28
 2
𝑆𝐶𝐶𝑟(𝐴𝑏𝑠𝑡𝑟𝑎𝑐𝑡𝑊𝑖𝑑𝑔𝑒𝑡𝐹𝑎𝑐𝑡𝑜𝑟𝑦) = {2
1

2
𝑆𝐶𝐶𝑟(𝐿𝑖𝑛𝑢𝑥𝑊𝑖𝑑𝑔𝑒𝑡) = {2
1

2
𝑆𝐶𝐶𝑟(𝑊𝑖𝑑𝑔𝑒𝑡𝑊𝑖𝑑𝑔𝑒𝑡) = {2
1

2
𝑆𝐶𝐶𝑟(𝑀𝑎𝑐𝑊𝑖𝑑𝑔𝑒𝑡) = {2
1

2
𝑆𝐶𝐶𝑟(𝐿𝑖𝑛𝑢𝑥𝑊𝑖𝑑𝑔𝑒𝑡) = {2
1

1
𝑆𝐶𝐶𝑟(𝑊𝑖𝑛𝑑𝑜𝑤𝑠𝑀𝑒𝑛𝑢) = {1
1

29
 1
𝑆𝐶𝐶𝑟(𝐿𝑖𝑛𝑢𝑥𝑀𝑒𝑛𝑢) = {1
1

1
𝑆𝐶𝐶𝑟(𝑀𝑎𝑐𝑀𝑒𝑛𝑢) = {1
1

2
𝑆𝐶𝐶𝑟(𝑊𝑖𝑛𝑑𝑜𝑤𝑠𝑊𝑖𝑛𝑑𝑜𝑤) = {2
1

2
𝑆𝐶𝐶𝑟(𝑀𝑎𝑐𝑊𝑖𝑛𝑑𝑜𝑤) = {2
1

2
𝑆𝐶𝐶𝑟(𝐿𝑖𝑛𝑢𝑥𝑊𝑖𝑛𝑑𝑜𝑤) = {2
1

Design Patterns Number of Class Average SCCr

Simple Solution 1 1 1
Adapter Design Pattern 11 1

Using Self-Completeness of Component’s parameter:

1. Simple Solution 2

0
𝑆𝐶𝐶𝑝(𝑊𝑖𝑑𝑔𝑒𝑡𝐺𝑒𝑛𝑒𝑟𝑎𝑡𝑜𝑟) = {2
1

30
2. Abstract Factory Design Pattern

0
𝑆𝐶𝐶𝑝(𝐴𝑏𝑠𝑡𝑟𝑎𝑐𝑡𝑊𝑖𝑑𝑔𝑒𝑡𝐹𝑎𝑐𝑡𝑜𝑟𝑦) = {2
1

0
𝑆𝐶𝐶𝑝(𝐿𝑖𝑛𝑢𝑥𝑊𝑖𝑑𝑔𝑒𝑡) = {2
1

0
𝑆𝐶𝐶𝑝(𝑀𝑎𝑐𝑊𝑖𝑑𝑔𝑒𝑡) = {2
1

0
𝑆𝐶𝐶𝑝(𝑊𝑖𝑛𝑑𝑜𝑤𝑠𝑊𝑖𝑑𝑔𝑒𝑡) = {2
1

0
𝑆𝐶𝐶𝑝(𝑊𝑖𝑛𝑑𝑜𝑤𝑠𝑀𝑒𝑛𝑢) = {1
1

31
 0
𝑆𝐶𝐶𝑝(𝐿𝑖𝑛𝑢𝑥𝑀𝑒𝑛𝑢) = {1
1
0
𝑆𝐶𝐶𝑝(𝑀𝑎𝑐𝑀𝑒𝑛𝑢) = {1
1
0
𝑆𝐶𝐶𝑝(𝑀𝑎𝑐𝑀𝑒𝑛𝑢) = {1
1
0
𝑆𝐶𝐶𝑝(𝑊𝑖𝑛𝑑𝑜𝑤𝑠𝑊𝑖𝑛𝑑𝑜𝑤) = {1
1
0
𝑆𝐶𝐶𝑝(𝐿𝑖𝑛𝑢𝑥𝑊𝑖𝑛𝑑𝑜𝑤) = {1
1
0
𝑆𝐶𝐶𝑝(𝑀𝑎𝑐𝑀𝑒𝑛𝑢) = {1
1

Design Patterns Number of Class Average SCCr

Simple Solution 1 1 1
Adapter Design Pattern 11 1

Analysis of result
The simple solution wouldn’t be viable for large scale application program, as it will be
difficult to modify it in the future, as replacing the generated routines with different routines that
run under a different operating system wouldn’t be considered portable. Such conversion from
another operating system to another is laborious and fault prone.

32
3.3 Discussion
In solution 1 which involves the adapter design pattern, for its simple solution, a class
Wrapper was use. It managed to solve the interfacing problems but after generalizing the solution,
it has led to the adapter design pattern. Although it produces similar result, the adapter design
pattern has shown to increase portability at a bigger scale. It decouples the client from the
implemented interface and overtime, interfaces are expected to change. The adapter is able to
encapsulates the change, so the client doesn’t have to modified each time it needs to operate against
a different interface which can be seen in the simple solution. The act of decoupling the client from
the implemented interface will increase portability as the adapter can help transfer the encapsulated
changes from one environment to another environment.

In solution 2 which involves the abstract factory design pattern helps to design the widget
generator in such a way that the application program is uncoupled from the specific operating
system. The abstract factory also solves interfacing issues by creating families of related or
dependent objects without specifying their concrete classes. Portability was increase because of
the dependency inversion principle. This principle defines that the dependency to concrete classes
should be reduce while depend upon abstraction is recommended. High level components should
not depend on low level components rather both should depend on abstraction (Freeman, et al.,
2004). For this case, widget generator is a high-level component because its behaviour is defined
in terms of the widget because it creates different widget object while the Linux widget or
Windows widget uses low level components. The code is decoupled from the actual use thus
different factories or widgetgenerator could be used to generate different widget. This satisfy the
definition of portability whereby in different environment the look and feel of the widget could be
similarly used.

33
3.4 Conclusion
The use of design patterns leads to increase portability as one of its products. But there are
weaknesses in using design pattern, because there is no specific way to determine when and how
to apply design patterns. Design patterns are usually described informally and through natural
language such as texts or words. More than that, another drawbacks comes from trying to increase
the maximal benefit from design patterns. To achieve that, multiple interacting patterns are
required. But due to the fact that there is no systematic way of knowing when and how to use one
pattern, multiple interacting patterns would be difficult. But when multiple interacting patterns are
used, it could bring out different quality factor not just portability but reliability etc.

34
References

Abran, A., Al-Sarayreh, K. T. & Cuadrado-Gallego, J. J., 2013. A standards-based reference

framework for system portability requirements. Computer Standards & Interfaces, 35(2013), pp.
380-395.

Aggarwal, S., 2014. Flask Framework Cookbook. 1 ed. Birmingham: Packt Publishing Ltd..

Ampatzogloua, A., Charalampidou, S. & Stamelosa, I., 2013. Research state of the art on GoF
design patterns: A mapping study. The Journal of Systems and Software.

Chih-HungChang, Lu, C.-W. & Hsiung, P.-A., 2011. Pattern-based framework for modularized
software development and evolution robustness. Information and Software Technology, 53(4), pp.
307-316.

Cline, M. P., 1996. The pros and cons of adopting and applying design patterns in the real world.
Communications of the ACM, 39(10), pp. 47-49.

Copperwaite, M. & Leifer, C., 2015. Learning Flask Framework. 1 ed. Birmingham: Packt
Publishing Ltd..

Dragoni, N. et al., 2017. Microservices: Yesterday, Today, and Tomorrow. s.l.:Springer

International Publishing AG 201.

Fowler, M. & Lewis, J., 2014. Microservices. [Online]

Available at: https://martinfowler.com/articles/microservices.html
[Accessed 6 March 2019].

Freeman, E., Freeman, E., Sierra, K. & Bates, B., 2004. Head First Design Patterns. 1 ed. New
York: O'Reilly Media, Inc.

Gamma, E., Helm, R., Johnson, R. & Vlissides, J., 1995. Design Patterns: Elements of Reusable
Object-Oriented Software. Indianapolis: Addison-Wesley.

Ghosh, S., 2007. Distributed Systems An Algorithmic Approach. 1 ed. New York: Taylor & Francis
Group, LLC.

35
Gital, A. Y. et al., 2014. Performance analysis of cloud-based CVE communication architecture in
comparison with the traditional client server, P2P and hybrid models. The 5th International
Conference on Information and Communication Technology for The Muslim World (ICT4M), pp.
1-6.

Goscinski, A., 1991. Distributed Operating Systems: The Logical Design. 1 ed. Boston: Addison-
Wesley Longman Publishing Co., Inc.

Grinberg, M., 2014. Flask Web Development. 1 ed. Sebastopol: O’Reilly Media, Inc.

Ismail, L., Hagimont, D. & Mossire, J., 2000. Evaluation of the mobile agents technology:
Comparison with the client/server paradigm. Information Science and Technology (1ST), Volume
19.

ISO/IEC, 2011. Systems and software engineering — Systems and software Quality Requirements
and Evaluation (SQuaRE) — System and software quality models. ISO/IEC 25010:2011(E).

Jamwal, D. D., 2010. Analysis of Software Quality Models for Organizations. International
Journal of Latest Trends in Computing , 1(2).

Khosravi, K. & Guéhéneuc, Y.-G., 2004. A Quality Model for Design Patterns.

Kshemkalyani, A. D. & Singhal, M., 2007. DISTRIBUTED COMPUTING: PRINCIPLES,

ALGORITHMS, and SYSTEMS. Chicago: Cambridge University Press.

Macero, M., 2017. Learn Microservices: A Practical Approach to RESTful Services using
RabbitMQ, Eureka, Ribbon, Zuul and Cucumber. 1 ed. New York: pringer Science+Business
Media New York.

Maia, I., 2015. Building Web Applications with Flask. 1 ed. Birmingham: Packt Publishing Ltd..

Maioriello, J., 2002. What Are Design Patterns and Do I Need Them?. [Online]
Available at: https://www.developer.com/design/article.php/1474561/What-Are-Design-Patterns-
and-Do-I-Need-Them.htm
[Accessed 10 February 2019].

Marco, L., 2001. EJB & JSP: Java On The Edge,. Unlimited Edition ed. s.l.:Wiley.

Metsker, S. J., 2002. Design Patterns Java™ Workbook. 1 ed. s.l.:Addison Wesley.
36
Metsker, S. J., 2002. Design Patterns Java™ Workbook. s.l.:Addison Wesley.

Mooney, J. D., 1993. Issues in the Specification and Measurement of Software Portability. 15th
International Conference on Software Engineering, Volume 15.

Mooney, J. D., 1997. Bringing Portability to the Software Process. West Virginia University Dept.
of Statistics and Computer Science.

Namiot, D. & Sneps-Sneppe, M., 2014. On Micro-services Architecture. International Journal of

Open Information Technologies ISSN: 2307-8162, 2(9).

Newman, S., 2015. Building Microservices: Designing Fine-Grained System. 2 ed. California:
O’Reilly Media, Inc..

Perry, B. W., 2004. Java Servlet & JSP Cookbook. 1 ed. s.l.:O'Reilly.

R.Subburaj, Jekese, G. & Hwata, C., 2015. Impact of Object Oriented Design Patterns on Software
Development. International Journal of Scientific & Engineering Research, 6(2).

Reddy, K. S. P., 2017. Beginning Spring Boot 2: Applications and Microservices with the Spring
Framework. 1 ed. Hyderabad: Springer Science+Business Media New York.

RV, R., 2016. Spring Microservices: Build scalable microservices with Spring, Docker, and Mesos.
1 ed. Birmingham: Packt Publishing Ltd..

Salah, T. et al., 2016. The Evolution of Distributed Systems Towards Microservices Architecture.
The 11th International Conference for Internet Technology and Secured Transactions (ICITST-
2016).

Sarcar, V., 2016. Java Design Patterns. 1 ed. New York: Springer Nature.

Schach, S. R., 2008. Object-Oriented Software Engineering. New York: McGraw-Hill .

Schmidt, D. C., 1995. Using design patterns to develop reusable object-oriented communication
software. Communications of the ACM - Special issue on object-oriented experiences and future
trends, 38(10), pp. 65-74.

37
Shafer, J., Rixner, S. & Cox, A. L., 2010. The Hadoop Distributed Filesystem: Balancing
Portability and Performance. 2010 IEEE International Symposium on Performance Analysis of
System & Software.

Steen, M. v. & Tanenbaum, A. S., 2017. Distributed Systems. 3 ed. s.l.:Maarten van Steen.

Villamizar, M. et al., 2017. Cost comparison of running web applications in the cloud using
monolithic, microservice, and AWS Lambda architectures. Service Oriented Computing and
Applications, 11(2), pp. 233-247.

Walls, C., 2016. Spring Boot In Action. 1 ed. New York: Manning Publications Co..

Washizaki, H., Yamamoto, H. & Fukazawa, Y., 2003. A Metrics Suite for Measuring Reusability
of Software Components. Proceedings. 5th International Workshop on Enterprise Networking and
Computing in Healthcare Industry.

Wetherbee, J., Nardone, M., Rathod, C. & Kodali, R., 2018. Beginning EJB in Java EE 8: Building
Applications with Enterprise JavaBeans. 3 ed. New York: Springer Science+Business Media New
York.

Wolf, D., 2017. Java EE Web Application Primer Building Bullhorn: A Messaging App with JSP,
Servlets. JavaScript, Bootstrap and Oracle. 1 ed. NewYork: Springer Science+Business Media
New York.

Wolff, E., 2016. Microservices: Flexible Software Architecture. 1 ed. Boston: Pearson Education,
Inc.

Wong, G., 2019. Screenshot of Code Snippets. Kuala Lumpur: s.n.

Yang, H., Chen, R. & Liu, Y.-q., 2010. A Metrics Method for Software Architecture Adaptability.
JOURNAL OF SOFTWARE, 5(10).

Zambon, G., 2012. Beginning JSP, JSF and Tomcat. 1 ed. New York: Springer Science+Business
Media New York.

38
39