Design Patterns
CT070-3-3-DPAT
a
Individual Assignment
Shopping Mall
Sree Prakash a/l Baskaran |
TP032890
Lecturer: Muhammad Ehsan Rana
2
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
3
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
4
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.
5
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 Customer
Use case name View Store
Description For customers to view all the stores in the shopping mall.
Precondition Customer has to open the application and login.
Postcondition Customer is logged in to the system and the stores are displayed.
Main flow 1. Customer enters their name and logs in.
2. The stores in the shopping mall is displayed.
Alternative path 2. Customer logs in with an empty field for name.
2a. Error message is shown to customer.
Includes -
Extends -
2) Enter Store
Actor Customer
Use case name Enter Store
Description For customers to enter store and view items in that store.
Precondition Customer must be logged in to the system.
Postcondition Customer selects a store and views the items in that particular store.
Main flow 1. Customer selects a store.
2. The items in the store is displayed.
Alternative path -
Includes View Items in Store
Extends -
3) Exit Store
Actor Customer
Use case name Exit Store
Description For customers to exit the store.
Precondition Customer must have been in a store.
6
Main flow 1. After possibly adding items to the shopping cart, customer
checks out and exits the store.
Alternative path -
Includes -
Extends -
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.
7
Postcondition The selected item is removed from the shopping cart.
Main flow 1. Customer views the list of items in the shopping cart.
2. Customer selects an item and removes it from the shopping cart.
Alternative path -
Includes -
Extends -
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
8
9) Checkout
Actor Customer
Use case name Checkout
Description For customers to checkout and purchase their items.
Precondition There must be items in the shopping cart.
Postcondition Customer is checked out from the store and the items are purchased.
Main flow 1. The customers checks out from the store.
2. The price for the items is displayed. 3. Customer purchases the items.
Alternative path -
Includes Purchase Items
Extends -
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 -
9
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 -
10
User Interface Documentation
Starting View of the application11
Select a store and the corresponding items are displayed
12
When a new item is added to the store
Figure 4 When a new item is added to the store -1
13
Once a customer enters the store
Figure 6 Once a customer enters the store
Once a customer add an item to their cart
14
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
15
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 pattern’s 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 pattern’s intent is to provide an interface for creating families of related dependent objects without specifying their concrete classes.
16
• 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
17
Abstract Factory Pattern #3 - Book Store
Figure 12 Abstract Factory Pattern #3 - Book Store Factory screenshot
Abstract Factory Pattern #4 - Game Store
18
Abstract Factory Pattern #5 - ShoeStore
19
Singleton Pattern
The Singleton pattern’s 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
20
Singleton Pattern #2
Figure 16 Singleton pattern #2 screenshot
Singleton Pattern #3
21
Observer Pattern
The Observer pattern’s 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 don’t 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 don’t 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
22
Observer Pattern #2
Figure 19 Observer pattern #2 screenshot
Observer Pattern #3
23
Command
The Command pattern’s 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
24
Command Pattern #2
Figure 22 Command Pattern #2
Command Pattern #3
25 Command Pattern #4
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 isn’t 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.
28
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.
29
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.
30
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.
31
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.
32
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-example-and-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:
33