Design Patterns

CT070-3-3-DPAT
a

Individual Assignment

Shopping Mall
Sree Prakash a/l Baskaran

| TP032890

Lecturer: Muhammad Ehsan Rana

Submission Date: 3rd December 2015

Contents
Overview of the application .......................................................................................................................... 3
Description ................................................................................................................................................ 3
Assumptions.............................................................................................................................................. 3
System Architecture...................................................................................................................................... 4
Use Case Diagram ..................................................................................................................................... 4
Use Case Specifications ............................................................................................................................. 5
User Interface Documentation ................................................................................................................... 10
Design Patterns ........................................................................................................................................... 15
Abstract Factory with Factory Methods Pattern .................................................................................... 15
Factory Method Pattern ..................................................................................................................... 15
Abstract Factory Pattern ..................................................................................................................... 15
Singleton Pattern .................................................................................................................................... 19
Observer Pattern..................................................................................................................................... 21
Command ................................................................................................................................................ 23
Refined Class Diagram ................................................................................................................................ 26
Critical Appraisal ......................................................................................................................................... 27
Limitations of the application ................................................................................................................. 27
Future Enhancements ............................................................................................................................. 27
Challenges Faced..................................................................................................................................... 28
Design Pattern Suitability for implementing Object Oriented solutions ................................................ 29
Abstract Factory with Factory Methods Pattern ................................................................................ 29
Singleton Pattern ................................................................................................................................ 30
Observer Pattern................................................................................................................................. 30
Command Pattern ............................................................................................................................... 31
References .................................................................................................................................................. 32
Appendix ..................................................................................................................................................... 33

Overview of the application

Description
This application models an actual shopping mall whilst also being a shopping mall management
system. The purpose of this application is to provide a soothing shopping experience for
customers whislt making use of design patterns. Using an object oriented programming language,
Java, the design patterns is applied appropriately in a realistic application such as the shopping
mall application.
In this application, customers can enter and exit any store, to add or remove items as they wish
from their shopping cart, even allowing for registeration for notifications when a new item is put
up for sale, and also to checkout and pay for their items. The store owner is able to add items in
the store and able to view the customers currently in the store. The shopping mall admin has the
ability to view the customers currently in the shopping mall.

Assumptions
1. Only 3 stores exist in the mall.
2. Only 5 items exist in each mall.
3. Every store has a unique ID.
4. Every item has a unique ID; the name and price of the item can be the same.
5. Every customer has auto generated unique ID; the name of the customer can be the same.
6. Once an item is added into the store, it is never removed.
7. Quantity of each item is unlimited; customers can add many of the same item to their
shopping cart.
8. A customer will use the same shopping cart throughout their time in the shopping mall.
9. When a customer checks out of the store and purchases the items, the customer also
exits the store.

System Architecture
A system architecture is the conceptual model that defines the structure, behavior, and views of
a system. An architecture description is a formal description and representation of a system,
organized in a way that supports reasoning about the structures and behaviors of the system
(Architecture-Driven Modelling Methodologies, 2011).

Use Case Diagram

A use case diagram is a graphic depiction of the interactions among the elements of a
system. A use case is a methodology used in system analysis to identify, clarify, and organize
system requirements (WhatIs.com, 2015). A use case diagram contains four components:

The boundary, which defines the system of interest in relation to the world around it.

The actors, usually individuals involved with the system defined according to their roles.

The use cases, are the specific roles played by the actors within and around the system.

The relationships between and among the actors and the use cases.

Figure 1 Use Case Diagram

Use Case Specifications

A use case specification is the most complete version of a use case. This written document
outlines the actors, preconditions, flow of events, and alternative flows of a use case (Lucidchart,
2014).
1) View Store
Actors
Use case name
Description
Precondition
Postcondition
Main flow
Alternative path
Includes
Extends
2) Enter Store
Actor
Use case name
Description
Precondition
Postcondition
Main flow

Customer
View Store
For customers to view all the stores in the shopping mall.
Customer has to open the application and login.
Customer is logged in to the system and the stores are displayed.
1. Customer enters their name and logs in.
2. The stores in the shopping mall is displayed.
2. Customer logs in with an empty field for name.
2a. Error message is shown to customer.
-

Alternative path
Includes
Extends

Customer
Enter Store
For customers to enter store and view items in that store.
Customer must be logged in to the system.
Customer selects a store and views the items in that particular store.
1. Customer selects a store.
2. The items in the store is displayed.
View Items in Store
-

3) Exit Store
Actor
Use case name
Description
Precondition
Postcondition

Customer
Exit Store
For customers to exit the store.
Customer must have been in a store.
Customer has exited the store.
5

Main flow
Alternative path
Includes
Extends

1. After possibly adding items to the shopping cart, customer

checks out and exits the store.
-

4) View Shopping Cart

Actor
Customer
Use case name
View Shopping Cart
Description
For customers to view the items they have in the shopping cart.
Precondition
Customer has entered a store.
Postcondition
Customer can view the items in the shopping cart.
Main flow
1. When customer enters a store, the shopping cart is still empty.
2. Once an item is added, the list is updated.
3. A list of items in the shopping cart is displayed.
Alternative path
Includes
Extends
5) Add Items to Shopping Cart
Actor
Customer
Use case name
Add Items to Shopping Cart
Description
For customers to add items from stores into their shopping cart.
Precondition
Customer has to enter a store.
Postcondition
Items are added in to the shopping cart.
Main flow
1. Customer enters a store and a list of items are displayed.
2. Customer selects an item and adds it into the shopping cart.
Alternative path
Includes
Extends
6) Remove Items from Shopping Cart
Actor
Customer
Use case name
Remove Items from Shopping Cart
Description
For customers to remove items from their shopping cart.
Precondition
An item(s) must be added to the shopping cart.
6

Postcondition
Main flow
Alternative path
Includes
Extends

The selected item is removed from the shopping cart.

1. Customer views the list of items in the shopping cart.
2. Customer selects an item and removes it from the shopping cart.
-

7) Undo Previous Action

Actor
Customer
Use case name
Undo Previous Action
Description
For customers to undo their previous action, the action being adding or
removing items from the shopping cart.
Precondition
The customer must either have added or removed an item from the
shopping cart.
Postcondition
Either action of adding or removing an item from the shopping cart is
undone.
Main flow
1. Customer adds an item in to the shopping cart or removes an
item from the shopping cart.
2. The customer then undoes the action.
Alternative path
Includes
Extends
8) Register for Notification
Actor
Customer
Use case name
Register for Notification
Description
For customers to register to receive notifications when a store owners
adds an item in their store for sale.
Precondition
Customer enters the store.
Postcondition
Customer registers for the notification.
Main flow
1. Customer enters the store.
2. Customer registers for the notification.
3. When a store owner adds a new item, the customer then
receives a notification.
Alternative path
Includes
Notification
Extends
7

9) Checkout
Actor
Use case name
Description
Precondition
Postcondition
Main flow

Alternative path
Includes
Extends

Customer
Checkout
For customers to checkout and purchase their items.
There must be items in the shopping cart.
Customer is checked out from the store and the items are purchased.
1. The customers checks out from the store.
2. The price for the items is displayed.
3. Customer purchases the items.
Purchase Items
-

10) View No. Of Customers in Mall

Actor
Mall Admin
Use case name
View No. Of Customers in Mall
Description
For the mall admin to view the number of customers currently in the
mall.
Precondition
Customer has entered the store.
Postcondition
Mall admin can view the number of customers in the mall.
Main flow
1. As customers enter a store, the mall admin views the total
number of customers in the mall which is the sum of customers
in each store.
Alternative path
Includes
Extends
-

11) Add Items in Store

Actor
Store Owner
Use case name
Add Items in Store
Description
For store owners to add new items in their store and notify any
registered customers.
Precondition
Customer has to register for the notification.
Postcondition
Item is added in the store and the customer is notified.
Main flow
1. A store owner adds a new item in the store.
2. Registered customers are notified of the new item added.
Alternative path
Includes
Notification
Extends
12) View No. of Customers in Store
Actor
Store Owner
Use case name
View No. of Customers in Store
Description
For store owners to view the number of customers currently in the
store.
Precondition
Customer has entered the store.
Postcondition
Store owner can view the number of customers in the store.
Main flow
1. As customers enter a store, the store owner views the number of
customers in the store.
Alternative path
Includes
Extends
-

User Interface Documentation

Starting View of the application

Figure 2 Starting View of the application

10

Select a store and the corresponding items are displayed

Figure 3 Select a store and the corresponding items are displayed

11

When a new item is added to the store

Figure 4 When a new item is added to the store -1

Figure 5 When a new item is added to the store -2

12

Once a customer enters the store

Figure 6 Once a customer enters the store

Once a customer add an item to their cart

Figure 7 Once a customer add an item to their cart

13

Once a new item is added and customer is notified

Figure 8 Once a new item is added and customer is notified

Once a customer checks out

Figure 9 Once a customer checks out

14

Design Patterns
The design patterns used in this application are Abstract Factory with Factory Methods,
Singleton, Observer, and Command.

Abstract Factory with Factory Methods Pattern

There is actually 2 design patterns used here, Abstract Factory and Factory Method.

Factory Method Pattern

The Factory Method patterns intent is to define an interface for creating an object, but to let the
subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to
subclasses.
The Factory Method pattern can be applied when:

You want to define the interface for creating a new object so that a service provider
decides which class to instantiate instead of clients.

You want to introduce a parallel class hierarchy.

You want to connect parallel hierarchies by letting subclasses in one hierarchy determine
which class to instantiate in the corresponding hierarchy.

Abstract Factory Pattern

The Abstract Factory patterns intent is to provide an interface for creating families of related
dependent objects without specifying their concrete classes.
The Abstract Factory pattern can be applied when:

15

You want to return one of several related classes of objects, each of which can return
several different objects on request.

The Abstract Factory pattern is one level of abstraction higher than the factory pattern. It is
basically a factory that creates factories.
For the shopping mall application, the researcher created all stores using factories. Below are
some screenshots:
Abstract Factory Pattern #1

Figure 10 Abstract Factory Pattern #1 screenshot

Abstract Factory Pattern #2 - Factory Producer

Figure 11 Abstract Factory Pattern #2 - Factory Producer screenshot

16

Abstract Factory Pattern #3 - Book Store

Figure 12 Abstract Factory Pattern #3 - Book Store Factory screenshot

Abstract Factory Pattern #4 - Game Store

Figure 13 Abstract Factory Pattern #4 - Game Store Factory screenshot

17

Abstract Factory Pattern #5 - ShoeStore

Figure 14 Abstract Factory Pattern #5 - ShoeStoreFactory screenshot

18

Singleton Pattern
The Singleton patterns intent is to ensure that a class has only one instance, and to provide a
global point of access to it.
The Singleton pattern can be applied when:

There must be exactly one instance of a class, and it must be accessible to clients from a
well-known access point.

When the sole instance should be extensible by subclassing, and clients should be able to
use an extended instance without modifying their code.

For the shopping mall application, the researcher used the Singleton pattern in each store
factory to allow only one instance of any created factory type. Below are some screenshots:
Singleton Pattern #1

Figure 15 Singleton pattern #1 screenshot

19

Singleton Pattern #2

Figure 16 Singleton pattern #2 screenshot

Singleton Pattern #3

Figure 17 Singleton Pattern #3 screenshot

20

Observer Pattern
The Observer patterns intent is to define a one-to-many dependency between objects so that
when one object changes state, all its dependents are notified and updated automatically.
The Observer pattern can be applied when:

An abstraction has two aspects, one dependent on the other. Encapsulating these aspects
in separate objects let you vary and reuse them independently.

A change to one object requires changing others, and you dont know how many objects
need to be changed.

An object should be able to notify other objects without making assumption about who
these objects are. In other words, you dont want these objects tightly coupled.

In the shopping mall application, the observer pattern is used to notify registered customers
when a new item is added to a store. Below are some screenshots:
Observer Pattern #1

Figure 18 Observer pattern #1 screenshot

21

Observer Pattern #2

Figure 19 Observer pattern #2 screenshot

Observer Pattern #3

Figure 20 Observer Pattern #3 screenshot

22

Command
The Command patterns intent is to encapsulate a request as an object, thereby letting you
parameterise clients with different requests, queue or log requests, and support undoable
operations.
The Command pattern can be applied when:

You want to parameterise objects by an action to perform.

For the shopping mall application, the Command pattern is used to provide the customer with
the ability to undo a previous action. Below are some screenshots:
Command Pattern #1

Figure 21 Command Pattern #1 screenshot

23

Command Pattern #2

Figure 22 Command Pattern #2

Command Pattern #3

Figure 23 Command Pattern #3

24

Command Pattern #4

Figure 24 Command Pattern #4

25

Refined Class Diagram

After applying the design patterns, the class diagram was refined.

Figure 25 Refined Class Diagram

**It is important to note that the application and class diagram above differ. Therefore the classes here do not reflect the classes in
the application. This is the initial class diagram drawn up by the reseacher.

Critical Appraisal
Limitations of the application
The limitations of the application is as such:
1. The application is unable to add new stores.
2. The application is unable to remove stores.
3. The application is unable to edit current stores.
4. The application is unable to remove items.
5. The application is unable to edit items.
6. The application is not very user interactive.
7. The application takes up most of the screen size of a standard computer.
8. There isnt any layer of security.
9. No login and logout features.
10. There is essentially no store owner in this application, only customer and mall admin.
11. There is not helpful text to guide the user on how to use this application.

Future Enhancements
The future enhancements of the system could be:
1. To implement a login feature which is the 1st layer of security.
2. To allow for different views for each type of user.
3. To allow for new stores to be added.
4. To allow for editing of stores.
5. To allow stores to be removed.
6. To allow for items to be removed.
7. To allow for editing of items.
8. To make the application more user interactive by adding some helpful text throughout
the application to guide the user.
9. To properly design the GUI of the application to suit any computer and still look good.

Challenges Faced
The challenges faced by the researcher during the development of this application is as such:
1. The researcher only has basic knowledge of Java language therefore the researcher had
to discover new concepts to fulfill the requirements of this application.
2. The researcher has not been programming in Java for almost a year therefore the
researcher had to brush up on a lot of the Java syntax and programming concepts.
3. The researcher had to resort to manually creating the GUI rather than the more
preferable way of drag-and-drop to create the GUI as the codes would be more complex
if the latter method was used.
4. The researcher had to relearn a lot of the design patterns and really analyze them so as
to fit them in this application.
5. The researcher had to constantly solve minimal errors in the code by looking through
forums and books thus wasting precious development time.
6. As the GUI was created manually, the researcher had to do a lot of iteration to make
sure the GUI looks and functions properly.

28

Design Pattern Suitability for implementing Object Oriented solutions

Abstract Factory with Factory Methods Pattern
Firstly, the Factory Methods pattern is one of most commonly used design pattern in Java. The
Factory Methods pattern comes under the creational pattern as this pattern provides one of the
best ways to create an object. In the Factory Methods pattern, objects are created without
exposing the creation logic to the client and refer to newly created object using a common
interface.
The advantages of the Factory Methods pattern is:

Factory Method Pattern allows the sub-classes to choose the type of objects to create.

It promotes the loose-coupling by eliminating the need to bind application-specific classes

into the code. That means the code interacts solely with the resultant interface or abstract
class, so that it will work with any classes that implement that interface or that extends
that abstract class.

Secondly, the Abstract Factory pattern works around a super-factory which creates other
factories. This factory is also called as factory of factories. The Abstract Factory pattern comes
under creational pattern as this pattern also provides one of the best ways to create an object.
In Abstract Factory pattern, an interface is responsible for creating a factory of related objects
without explicitly specifying their classes. Each generated factory can give the objects as per the
Factory pattern.
The advantages of a Abstract Factory pattern is:

Abstract Factory Pattern isolates the client code from concrete (implementation) classes.

It eases the exchanging of object families.

It promotes consistency among objects.

In the shopping mall application, this pattern is used to create the store factories while
providing multiple layers of abstraction and also a form a security. Furthermore, this pattern
helped with keeping the objects consistent.

29

Singleton Pattern
The Singleton pattern is one of the simplest design patterns in Java. Just like Factory Method
pattern and Abstract Factory patter, this type of design pattern comes under creational pattern
as this pattern provides one of the best ways to create an object. This pattern involves a single
class which is responsible to create an object while making sure that only single object gets
created. This class provides a way to access its only object which can be accessed directly without
need to instantiate the object of the class.
The advantages of the Singleton pattern is:

Saves memory because object is not created at each request. Only single instance is
reused again and again.

In the shopping mall application, this pattern is used to saved memory during runtime.
Furthermore, the researcher had an easier time to refer to objects.

Observer Pattern
The Observer pattern is used when there is one-to-many relationship between objects such as if
one object is modified, its depenedent objects are to be notified automatically. Observer pattern
falls under behavioral pattern category.
The advantages of of the Observer Pattern are:

Can reuse subjects without reusing their observers and vice versa.

Observers can be added without modifying the subject.

Subject and observer can belong to different abstraction layers.

Subject sends notification to all subscribed observers

Observers can be added/removed at any time

In the shopping mall application, this pattern is used to notify the registered customers when
a new item is added to a store.

30

Command Pattern
The Command pattern is a data driven design pattern and falls under behavioral pattern
category. A request is wrapped under an object as command and passed to invoker object.
Invoker object looks for the appropriate object which can handle this command and passes the
command to the corresponding object which executes the command.
The advantages of the Command Pattern are:

It separates the object that invokes the operation from the object that actually performs
the operation.

It makes easy to add new commands, because existing classes remain unchanged.

In the shopping mall application, the command is pattern is used to undo a previous action
making the application more user interactive.

31

References
Architecture-Driven Modelling Methodologies. (2011). In: Proceedings of the 2011
conference on Information Modelling and Knowledge Bases XXII. Amsterdam,
Netherlands: IOS Press, p.98.
Deitel, P. and Deitel, H. (n.d.). Java how to program.
Gamma, E. (1995). Design patterns. Reading, Mass.: Addison-Wesley.
Holzner, S. (2006). Design patterns for dummies. Hoboken, N.J.: Wiley.
Lucidchart, (2014). Use Case Specification - Example and Template (UML). [online]
Available at: https://www.lucidchart.com/pages/use-case-specification-exampleand-template-UML [Accessed 2 Dec. 2015].
WhatIs.com, (2015). What is use case diagram (UML use case diagram)? - Definition
from WhatIs.com. [online] Available at:
http://whatis.techtarget.com/definition/use-case-diagram [Accessed 2 Dec. 2015].

32

Appendix
The program can be added to Netbeans IDE as a new project and run from there.

33