SDA Assignment

FORM 1
FACULTY OF COMPUTING AND INFORMATION TECHNOLOGY
Bachelor of Software Engineering (Honours)

Programme: RSW (Group: 3)
ASSIGNMENT
BACS2073 SOFTWARE DESIGN AND ARCHITECTURE
NAME (BLOCK LETTERS) REGISTRATION NO. SIGNATURE MARKS
1. HON SHU YING 22WMR04089
2. RENE CHOONG QIAN HUI 22WMR04096 RENE
3. TAN ZI YEE 22WMR04102 ZiYee
4. CHONG YEE YANG 22WMR06378 YANG
Lecturer/Tutor Name: LIM FUNG JI

FORM 2
FACULTY OF COMPUTING AND INFORMATION TECHNOLOGY

Plagiarism Statement and Guideline for Late Submission of Coursework
Read, complete, and sign this statement to be submitted with the written report.
We confirm that the submitted work is all our work and is in our own words.
NAME (BLOCK LETTERS) REGISTRATION NO. SIGNATURE DATE
1. HON SHU YING 22WMR04089

19/5/24
2. RENE CHOONG QIAN HUI 22WMR04096 RENE

19/5/24
3. TAN ZI YEE 22WMR04102 ZiYee 19/5/24
4. CHONG YEE YANG 22WMR06378 YANG

19/5/24
NAME MODULE
HON SHU YING Menu Module
RENE CHOONG QIAN HUI User Management Module
TAN ZI YEE Order Module
CHONG YEE YANG Payment Module

SOFTWARE DESIGN DOCUMENT (SDD)
TABLE OF CONTENTS
TABLE OF CONTENTS................................................................................................................................................1
1. Introduction........................................................................................................................................................2
1.1 Document Purposes............................................................................................................................................. 2
1.2 Product Scope......................................................................................................................................................2
1.3 Document Overview.............................................................................................................................................2
1.4 Objectives:............................................................................................................................................................3
1.5 Quality Attributes:................................................................................................................................................ 3
1.6 Architectural Pattern............................................................................................................................................ 5
2. INITIAL DESIGN................................................................................................................................................... 7
2.1 Architectural Design............................................................................................................................................. 7
2.2 Comparison of the 3 Architectural Pattern...........................................................................................................9
2.3 Selection of Architectural Pattern...................................................................................................................... 13
2.4 References.......................................................................................................................................................... 14
3. DETAILED DESIGN.............................................................................................................................................. 15
3.1 Module 1 : User Management Module.............................................................................................................. 15
3.1.1 Use Case Diagram..................................................................................................................................... 15
3.1.2 Design Class Diagram................................................................................................................................ 18
3.2 Module 2 : Menu Module.................................................................................................................................. 20
3.2.1 Use Case Diagram..................................................................................................................................... 20
3.3 Module 3 : Order Module...................................................................................................................................27
3.3.1 Use Case Diagram..................................................................................................................................... 27
3.4 Module 4 : Payment Module..............................................................................................................................33
3.4.1 Use Case Diagram..................................................................................................................................... 33
4. HUMAN INTERFACE DESIGN.............................................................................................................................. 39
4.1 Module 1 : User Management Module.............................................................................................................. 39
4.2 Module 2 : Menu Module.................................................................................................................................. 40
4.3 Module 3 : Order Module...................................................................................................................................41
4.4 Module 4 : Payment Module..............................................................................................................................42
1
1. Introduction
1.1 Document Purposes
This document shall serve as:
a. To Define Objectives: This document shall define the primary objectives of the project, outlining its scope
and expected outcomes.
b. To Establish Accountability: It will assign responsibilities to team members and stakeholders, ensuring clarity
in roles and expectations.
c. To Provide a Reference Point: Serving as a reference document throughout the project lifecycle, it will help
track progress and align activities with the overarching goals.
d. To Facilitate Communication: By laying out objectives and responsibilities, this document will facilitate
effective communication among team members, fostering collaboration and coordination.
1.2 Product Scope
The TAR UMT Cafeteria Ordering System is a system with the primary purpose of providing a user-friendly platform
that allows customers to place orders conveniently, enhancing the overall cafeteria experience. The goal of the
system is to make ordering food at the cafeteria better for everyone. The system consists of several modules, and in
this document, only four modules will be discussed: the user management module, menu module, order module,
and payment module.
The system shall be able to enable students and staff to place advance food orders, specify their preferred pick-up
time, and avoid long queues. The streamlined process helps to avoid long queues among students, saves time, and
provides convenience to students. The system's features, including order status notifications and digital payments,
contribute to a more efficient and error-free dining experience. By minimising wait times and providing a hassle-free
ordering process, the system aims to encourage increased sales for vendors while also providing students with a good
cafeteria ordering experience.
1.3 Document Overview
Chapter Contents Summary

Chapter 1 Introductory to the project
Chapter 2 Initial Design
Chapter 3 Detailed Design
Chapter 4 Human Interface Design
2
1.4 Objectives:
1. Provide User-Friendly Experience
The TAR UMT Cafeteria Ordering System aims to provide a user-friendly interface for students and staff to
place food orders seamlessly. This objective focuses on incorporating principles of user-centred design into
the software architecture, ensuring that the ordering process is easy to navigate and minimises the time and
effort required for users to place their orders.
2. Ensure Accommodation to Fluctuating User Growth

The TAR UMT Cafeteria Ordering System aims to be capable of accommodating increasing demands and
growing user populations without compromising performance or functionality. This objective focuses on
designing a system architecture that can seamlessly handle spikes in user activity and adapt to changing user
loads, such as fluctuations in peak hours. The system aims to ensure that it can efficiently serve the entire
user base without experiencing downtime or degradation in service quality to meet the needs of the
students and staff of the university.
3. Consistent and Reliable System Operation

The TAR UMT Cafeteria Ordering System aims to operate consistently and predictably, without unexpected
failures or downtime. This objective focuses on ensuring that the system remains stable and available,
supporting both cafeteria staff and users in their tasks. For cafeteria staff, a reliable system means they can
depend on it to manage orders effectively without encountering technical issues. For users, reliability ensures
a seamless and uninterrupted ordering experience, leading to increased satisfaction and trust in the system.
1.5 Quality Attributes:

1. Usability
Software architecture plays a crucial role in achieving usability by incorporating user-centred design
principles. This includes conducting user research, creating personas, and designing intuitive user workflows
to meet users' needs effectively.
In the Cafeteria Ordering System, usability is about making the software user-friendly. This involves designing
an intuitive interface and incorporating user-friendly functions to enhance the overall user experience. By
offering a simple interface for placing orders on various devices, the system improves usability, allowing
students and staff to navigate the platform effortlessly without extensive training or support.
Usability trade-offs usually focus on simplification versus functionality. Simplifying user interfaces and
processes can improve usability by making the system more intuitive, but it may mean sacrificing features
that could enhance the user experience. For instance, removing advanced options might streamline the
experience but limit flexibility for power users. Balancing these trade-offs means understanding the user
base and prioritising usability features that enhance the overall experience without compromising essential
functionalities.
2. Scalability
Scalability for the Cafeteria Ordering System means it can handle more people ordering food without slowing
down or crashing. It's like adding more tables when a restaurant gets busier. This helps make sure the system
keeps working well even when lots of people are using it at once.
3
Making the system scalable means it can keep running smoothly even when more people start using it, like
during lunchtime rushes. This helps avoid any problems like the system getting slow or crashing when lots of
people are trying to order food.
Scalability is important because it ensures that everyone can order their food without any issues, even on
peak hours where the cafeteria staff is flooded with orders. It's like making sure there are enough seats for
everyone at a big event. This helps keep customers happy and makes sure the system can keep running
smoothly as more people start using it.
Scalability trade-offs often pit performance against resource usage. Growing a system to handle more users
means allocating more resources like servers or bandwidth, but this can increase resource consumption and
complexity. For instance, adding more servers to scale horizontally can boost performance but may bring
added overhead in managing data across instances. Balancing these trade-offs means fine-tuning resource
allocation and scalability methods to meet performance needs while keeping resource usage low and system
simplicity intact.
3. Reliability
Reliability refers to the system's ability to operate consistently and predictably, without unexpected failures
or downtime. In the context of the Cafeteria Ordering System, reliability ensures that the system remains
stable and available, supporting both cafeteria staff and users in their tasks. For cafeteria staff, a reliable
system means they can depend on it to manage orders effectively without encountering technical issues. For
users, reliability ensures a seamless and uninterrupted ordering experience which leads to increased
satisfaction and trust in the system.
Reliability is aligned with both objectives of supporting cafeteria operations and enhancing user satisfaction.
For supporting cafeteria operations, reliability ensures that the system remains available and functional
during peak hours, minimising disruptions and downtime. This reliability gains confidence in staff members
and helps maintain smooth operations. For enhancing user satisfaction, reliability ensures consistent system
performance without disruptions or errors during the ordering process. This reliability builds trust among
users and contributes to a positive experience.
Reliability trade-offs often balance robustness against flexibility. Adding robust error handling and fault
tolerance can boost reliability by maintaining consistent operation and reducing downtime. However, these
measures may complicate system design and make it less flexible. For instance, strict error handling might
enforce rigid data validation, limiting flexibility. Balancing these trade-offs means implementing reliability
measures that find the right mix of robustness and flexibility, ensuring the system operates consistently while
still adapting to changing needs.
4
1.6 Architectural Pattern
1. Model-View-Controller (MVC)
The Model-View-Controller (MVC) framework is an architectural / design pattern that divides an
application into three logical components: model, view, and controller. Each architectural component
is designed to deal with certain development issues of an application. It separates the business logic
from the presentation layer (Kaalel, 2022). The model component represents the system’s core
including its major processing capabilities and data, the view component represents the output
representation of the system while the controller component handles user inputs.
Since MVC separates the user interface from the business logic and user input handling, it provides a
user-friendly interface since the developers can focus on the presentation layer without being
concerned with data processing and manipulation thus promoting usability. Along with the
separation of concerns, any updates or modifications to one component will not affect the
functionality of the others, thus ensuring the system remains reliable. And since the layers are
separated, the system can easily scale a component independently. For example, if there's a need to
handle increased user interactions, additional controllers or views can be added without necessarily
impacting the underlying data model, thus facilitating horizontal scalability.
The Model-View-Controller (MVC) architectural pattern is selected for its capacity to tackle crucial
development challenges while advancing usability, reliability, and scalability. One notable advantage
lies in its facilitation of user-friendly interfaces. By segmenting concerns, MVC permits developers to
concentrate solely on the presentation layer, thereby yielding interfaces that are intuitive and
user-friendly. Additionally, the pattern ensures system reliability through component isolation.
Updates or alterations to one component have no bearing on the functionality of others, thus
safeguarding system reliability. Furthermore, MVC promotes scalability by enabling the independent
scaling of components. This facilitates horizontal scalability, empowering the seamless addition of
controllers or views to accommodate heightened user interactions without disrupting the underlying
data model.
2. Layered Architecture
Layered architecture is a common architectural style where modules or components sharing similar
functionalities are arranged into horizontal layers within an application. The main idea behind this
architecture is to encourage the separation of roles, with each layer performing a specific function.
There is no strict limit on the number of layers, as the goal is to create layers that facilitate
modularity and ease of maintenance. This architectural style abstracts the entire system while
providing detailed insights into each layer's responsibilities and their interconnections. Regarding
components and connectors, connectors between layers can vary, including function calls, query
requests, or data objects. Typically, layered architectures include a presentation layer for user
interface rendering and browser communication, a business layer for application logic and data
handling, and a data or persistence layer for storing retrievable information with logical and physical
schema components. This structured layering approach enhances clarity, scalability, and
manageability in software design and development (Cheriton School of Computer Science).
Layered architecture is chosen for its emphasis on modularity, clarity, and scalability within software
design. One notable advantage is its facilitation of the separation of roles. By structuring components
into distinct layers, this architectural approach encourages the delineation of responsibilities, thereby
enhancing modularity and simplifying maintenance tasks. Moreover, layered architecture promotes
5
clarity and manageability through its provision of detailed insights into each layer's specific duties.
This transparency aids in comprehending the system's overall design and fosters ease of
management throughout the development process. Additionally, the structured layering approach
supports scalability by allowing individual components to scale independently as needed. This
flexibility enables the system to adapt to changing demands efficiently, ensuring that it can grow and
evolve in tandem with evolving requirements and user needs.
3. Broker Architecture
The broker pattern serves as an architectural blueprint for organising distributed software systems
where independent components interact through remote procedure calls with minimal
interdependence. In this pattern, a central broker component manages communication by
forwarding requests and transmitting outcomes and errors (Alosaimi, 2021).
The broker architecture is suitable for the TAR UMT Cafeteria Ordering System due to its ability to
streamline communication between distributed components, facilitate scalability, and enhance
reliability. With a centralised broker managing message routing and communication protocols, the
complexity of interactions among various system components is abstracted away which leads to a
simpler and more intuitive interface for developers. This simplification improves system usability and
reduces cognitive load during system development and maintenance. Additionally, the broker
architecture enables horizontal scalability by decoupling components and allowing for the
deployment of additional brokers to handle increased message traffic efficiently. As the cafeteria
ordering system experiences fluctuations in user demand, the ability to scale seamlessly ensures
consistent performance without sacrificing reliability. Moreover, the centralization of control and
coordination provided by the broker architecture enhances system reliability by ensuring message
integrity, queuing management, and error handling, even in the face of component failures or
disruptions. This fault-tolerant communication infrastructure ensures that critical order information
is reliably processed, contributing to overall system reliability and user satisfaction in the TAR UMT
Cafeteria Ordering System.
6
2. INITIAL DESIGN
2.1 Architectural Design
7
The architectural design diagram above illustrates the Model-View-Controller (MVC) pattern that is applied to the
TAR UMT University Cafeteria Ordering System. The system includes a Browser which is the interface through which
users interact with the system. Its responsibility is to send user requests to the system and display the responses
received from the View component.
Next, we have the Controller component which acts as an intermediary between the View and the Model
components. It is composed of the following sub-components:
● User Controller – Manages user-related actions such as login, registration, and profile management
● Order Controller – Handles actions related to order processing
● Cart Controller – Manages the shopping cart operations
● Payment Controller – Manages payment transactions and processing
Its responsibilities are handling user input and application logic, receiving user interactions from the View, and
executing tasks such as authentication, authorization, and error handling. It updates the Model based on user
interactions and business logic and selects the appropriate View to present to the user.
The Model represents the application's data and business logic. Similar to the Controller, it also has sub-components.
The user model manages user data, the order model handles order information and processing, the cart model
manages data related to the user's cart, and the payment model manages payment details and transactions. These
models handle data management, including menu items, orders, and inventory, and communicate with the Database
for data storage and retrieval.
The View component is the graphical interface through which users interact with the system. It consists of pages like
Home, Order, Cart, Payment, and User, and provides the graphical interface for users to browse the menu, customise
orders, view summaries, and proceed with checkout. It updates in response to changes notified by the Controller,
ensuring the user interface reflects the current state of the system.
8
2.2 Comparison of the 3 Architectural Pattern
Architectural
Quality Attributes Characteristics Strengths Limitations Most Common Use Case
Pattern
Model-View- ● Modifiability – easy to Systems are decomposed ● Separation of ● Lack of Specialisation: ● It is most commonly
Controller exchange, enhance or into three main Concerns: MVC enables Development team used for web
(MVC) add additional user components: separation of concerns, lacks specialisation in applications, although
interfaces ● Model - components making it easier to frontend or backend; it can also be applied to
● Usability – by allowing that represents the modify presentation or developers are various other types of
easy exchangeability of system’s core including data without affecting full-stack, requiring applications, including
user interfaces, systems its major processing the other parts and skills in both areas. desktop applications.
can be configured with capabilities and data simplifying testing. ● Proficiency in Multiple (Davis, 2008)
different user ● View - components ● Challenges in Complete Technologies: Full-stack ● For example, Ruby on
interfaces to meet that represents the Separation: Achieving developers need Rails, ASP.NET MVC,
different usability output representation complete separation proficiency in multiple and Spring MVC
needs of particular of the system (e.g. can be challenging; technologies to handle
groups of customers. graphical output or modifications often both frontend and
● Reusability – by console based) require adjustments in backend tasks.
separating the ● Controller - both data and ● Excessive View
concerns of the model, components(associated presentation layers. Updates: Active models
view and controller with a view) that ● Increased Reusability: directly notifying views
components, they all handles user inputs Presentation objects may cause excessive
can reused in other (Respond to user action become more reusable view updates with
systems and direct the with MVC, as UI frequent model
application flow) components are changes.
separated from data,
allowing models to be
reused with multiple
views.
● Specialisation in
Development:
Separation of
presentation from
9
business logic and data

allows specialisation in
frontend or backend
development,
potentially expediting
development through
parallel task execution.
● Efficiency
Enhancement: For
instance, one
developer can focus on
UI while another
developer works on
business logic,
enhancing efficiency.
Layered ● Modifiability – Layered architecture is a ● Abstraction: Layered ● Performance Impact: ● Building new facilities on
Architecture dependencies are kept design approach that architecture abstracts Data passing through top of existing systems
local within layer organises the functionality the system as a whole, multiple layers can ● The development is
components of an application into providing clear details reduce performance. spread across several
● Portability – services distinct layers stacked about individual layers Open layered teams with each team
deal directly with a vertically on top of each and their relationships. architecture, intended responsibility for a layer
platform’s application other. Each layer represents ● Encapsulation: to address this, of functionality.
programming interface a different level of Designers don't need to increases coupling ● There is a requirement
(API) abstraction and provides make assumptions while decreasing for multi-level security.
● Security – encrypt and services to the layer(s) about data types or simplicity and
decrypt incoming or above while utilising implementation details information hiding.
outgoing data. services from the layer(s) at layer boundaries, as ● Debugging Complexity:
● Reusability – easier to below. This architectural these features are not Multi-layered programs
use style facilitates the flow of exposed. can be challenging to
requests, answers, and ● Clearly Defined debug due to
data/events between layers. Functional Layers: Each operations being
It is commonly used when layer's functionality is implemented through
building new facilities on distinct, with upper calls across layers.
existing systems, when layers sending ● Difficulty in Layer
development is distributed commands to lower Design: Getting the
10
among multiple teams, or layers and reacting to layers right can be

when multi-level security is events, facilitating difficult. Too few layers
required. Each layer bidirectional data flow. may result in low
functions as a module, ● Reusability: Lower cohesion, complexity,
offering a cohesive set of layers have no and discourage reuse.
services through dependencies on higher Too many layers may
well-defined interfaces and layers, making them lead to high interlayer
can be open (providing potentially reusable in coupling and degraded
services to/making use of other scenarios. performance.
services from multiple ● High Cohesion: Each
layers) or closed (limited layer has well-defined
interaction with adjacent responsibilities,
layers). maximising cohesion
within the layer by
containing only
functionality directly
related to its tasks.
● Loose Coupling:
Communication
between layers relies on
abstraction and events,
promoting loose
coupling and flexibility in
the system.
Broker ● Interoperability – ● Software that acts as ● Simplifies Security ● Single Point of Failure: ● Financial Market Data
Architecture allows clients on an intermediate Management: Broker Broker pattern Distribution: Brokers
different platforms to between the client and pattern simplifies introduces a single disseminate real-time
interoperate with the server. security management point of failure and stock market data to
servers of different ● Provides mechanisms for both clients and potential bottleneck in different clients for
platforms for achieving better servers by delegating the system. If the analysis and trading
● Modifiability - allows flexibility between security mechanisms to broker is compromised decisions.
centralised changes in clients and servers in a the broker. This allows or overloaded, the ● Message Queue
the server and quick distributed for consistent and entire system may be Management: Brokers
distribution among environment. centralised policies, affected. oversee message
many clients ● Instead of accessing reducing complexity, ● Latency and Overhead: distribution among
11
● Portability – by porting servers directly, clients redundancy, and Using a broker multiple components,
the broker to different access their maintenance costs. increases latency and assisting asynchronous
platforms, services functionality via a ● Additional Features: overhead in communication.
provided by the system broker component, Brokers can provide communication, as ● Internet of Things (IoT)
can be easily acquired which locates extra functionalities like each message must go Hub Connectivity:
by new clients on appropriate servers, load balancing, fault through an extra hop Brokers facilitate
different platforms. forwards requests, and tolerance, scalability, and processing time. communication
● Reusability – when relays responses back and performance This can impact system between IoT devices and
using brokers, many to clients. optimization by routing responsiveness and cloud services.
complex services can ● Decreases coupling requests and responses efficiency, especially
be reused on other between clients and among multiple servers. with distant brokers.
applications that servers.
require similar
distributed operations.
12
2.3 Selection of Architectural Pattern
After comparing the 3 architectural patterns, we have decided to choose Model-View Controller (MVC) as our
architecture pattern. Firstly, MVC's separation of presentation, business logic, and user interaction control enables
the creation of a user-friendly interface, meeting the system's objective of providing a seamless ordering experience.
Secondly, MVC's modular structure supports scalability, allowing the system to handle fluctuating user growth
without compromising performance, aligning with the objective of accommodating increasing demands. Lastly, MVC
promotes consistent and reliable system operation by providing clear boundaries between components, ensuring
uninterrupted service and efficient order management, thus addressing the objective of operating predictably
without unexpected failures. These aspects make MVC the suitable choice for fulfilling the system's objectives and
quality attributes effectively.
Layered Architecture provides modifiability through localised dependencies within layers and promotes high
cohesion and loose coupling, yet it introduces notable performance overhead due to multiple-layer traversal,
impacting system responsiveness. Conversely, MVC's direct component interaction enables efficient request handling
and a faster user experience. Additionally, while Layered Architecture is modular, it may lack MVC's flexibility in
independently scaling specific components. MVC's distinct separation of model, view, and controller components
allows for more targeted scalability, alongside simplifying maintenance through clear separation of concerns. This
contrasts with the complexity of maintaining a layered system, which can arise from interdependencies and
challenging layer designs. MVC further enhances reusability by separating presentation from data, facilitating the
reuse of models with different views. Moreover, MVC promotes specialisation in development, enabling developers
to focus on frontend or backend tasks, potentially expediting development through parallel task execution, a feature
less pronounced in Layered Architecture.
Broker Architecture offers high interoperability and flexibility by acting as an intermediary between clients and
servers, facilitating platform-independent communication. However, it introduces a single point of failure and
potential bottleneck, compromising the entire system's performance and reliability if the broker fails or becomes
overloaded. Unlike Broker Architecture, MVC does not have this single point of failure, as its components interact
directly, reducing the risk of a system shutdown due to a single component's failure. Furthermore, using a broker
increases communication latency and overhead, impacting system responsiveness and efficiency, particularly in
real-time systems or applications requiring low latency. In contrast, MVC's direct interaction model avoids this
additional overhead, resulting in better performance and faster user interactions. Additionally, while Broker
Architecture simplifies security management by centralising security mechanisms within the broker, it also centralises
the risk of a significant security breach if the broker is compromised. In contrast, MVC distributes security concerns
across different components, reducing the risk of a single point of security failure. Moreover, implementing and
maintaining a broker system can be complex, involving tasks such as load balancing, fault tolerance, and performance
optimization. MVC’s simpler structure avoids these complexities, making it easier to implement and maintain.
13
2.4 References
1. Alosaimi, L. (2021, July 25). Broker pattern. Retrieved March 27, 2024, from Medium website:
https://medium.com/@lalosaimi/broker-pattern-297ac3cff6c5
2. Cheriton School of Computer Science. (n.d.). Layered architecture.
https://cs.uwaterloo.ca/~m2nagapp/courses/CS446/1195/Arch_Design_Activity/Layered.pdf
3. Software Solution Architecture. (2023, March 21). What are the benefits and drawbacks of using a broker
security pattern in a distributed system? Retrieved March 27, 2024, from LinkedIn website:
https://www.linkedin.com/advice/1/what-benefits-drawbacks-using-broker
4. Ingeno, J. (2018). Software Architect’s Handbook: Become a successful software architect by implementing
effective architecture concepts. Birmingham, England: Packt Publishing.
5. Gupta, R., & Sahu, A. (2023, October 15). Software architecture patterns: What are the types and which is the
best one for your project. Retrieved March 27, 2024, from Turing website
https://www.turing.com/blog/software-architecture-patterns-types/
6. Davis, I. (2008, December 9). What are the benefits of MVC?. Internet Alchemy.
https://blog.iandavis.com/2008/12/what-are-the-benefits-of-mvc/
7. Kaalel. (2022, March 21). MVC framework introduction. Retrieved March 27, 2024, from GeeksforGeeks
website: https://geeksforgeeks.org/mvc-framework-introduction/
14
3. DETAILED DESIGN
3.1 Module 1 : User Management Module

3.1.1 Use Case Diagram
The above is the use case diagram of the TAR UMT cafeteria ordering system’s user management module.
Based on the module, five activity diagrams were identified. Both customers and staff can sign up, log in, edit
profile, and delete accounts, while update points are only for customers.
15
3.1.1.1 Activity Diagram for Sign Up
3.1.1.2 Activity Diagram for Log In
16
3.1.1.3 Activity Diagram for Redeem Points
3.1.1.4 Activity Diagram for Edit Profile
17
3.1.1.5 Activity Diagram for Delete Account
3.1.2 Design Class Diagram
18
3.1.2.1 Rationale for Selected Design Pattern

A Facade class design was chosen for the user management module. This pattern offers a consolidated
interface for a set of functions, making the system more user-friendly and comprehensible. By bundling
intricate operations like user registration, login, and email notifications, the UserManagement class ensures
these tasks can be executed effortlessly and prevent the system becoming too complicated for the users. This
approach enhances code clarity and maintainability, while also simplifying testing and debugging as codes
from the complexity of a subsystem will be isolated.
Strategy pattern was considered, which allows for diverse approaches to executing tasks, such as different
authentication methods like username and password logins or social login. However, this pattern needs the
main codebase to be aware of and select between these various strategies, thereby complicating the system.
Since the primary aim was to streamline the user management interface, the Strategy pattern was deemed
less suitable.
The Singleton pattern was also considered, which guarantees that a class has only one instance and provides
a solitary access point to it. This could be beneficial for managing the UserService or AuthenticationService,
ensuring the existence of only one instance of these services. However, the Singleton pattern can introduce
issues like concealed dependencies and testing difficulties due to its impact on the global state. Multiple
services needed to collaborate seamlessly without exposing their intricacies.
With that in mind, Facade pattern is a better choice as it not only conceals these intricacies but also fosters
improved modularity and separation of concerns, aligning well with the design objectives.
19
3.2 Module 2 : Menu Module
20
3.2.1.1 Activity Diagram for Add Item
21
3.2.1.2 Activity Diagram for Categorising Item
22
3.2.1.3 Activity Diagram for Add Promotion
23
3.2.1.4 Activity Diagram for View Menu
3.2.1.5 Activity Diagram for Filter Item
24
25
The Observer pattern is particularly suitable for the menu module because it addresses the critical
issue of real-time updates. In this module, it is essential that customers receive immediate notifications
whenever there are changes to the menu, such as new promotions. By implementing the Observer pattern,
the module ensures that any updates are automatically notified to all registered customers. This real-time
update mechanism enhances user experience by providing accurate and timely information, thereby allowing
customers to make informed decisions about their orders.
Another significant advantage of the Observer pattern is its ability to decouple the subject (in this
case, the Menu) from its observers (the Customer). This decoupling promotes low coupling and high
cohesion within the system's architecture. The Menu does not need to have detailed knowledge of the
Customer class or its instances. Instead, it simply maintains a list of observers and notifies them when a
change occurs. This separation of concerns makes the system more modular and easier to maintain or extend
in the future. For instance, new types of observers can be added without altering the existing menu logic,
fostering scalability and flexibility.
The scalability of the Observer pattern is another crucial factor in its selection. As the cafeteria
system expands and the number of customers increases, the pattern efficiently handles the notification
process. Each customer registers as an observer and receives updates independently, which means that the
system does not bog down with direct communication to each customer individually. This leads to a more
streamlined and manageable notification mechanism that can scale with the growing user base.
While the Observer pattern was chosen for its ability to provide real-time updates and maintain
decoupling, other patterns were also considered. The Factory Method pattern was also considered for
creating instances of MenuItem, Category, and Promotion. This pattern would ensure a consistent and
centralized way of creating objects. While useful, it was not as critical to the core functionality of real-time
updates, and thus was not selected as the primary pattern.
Lastly, the Composite pattern was evaluated for managing the relationship between Category and
MenuItem. This pattern would allow a Category to contain multiple MenuItem objects and potentially other
Category objects, creating a hierarchical tree structure. However, the complexity introduced by this pattern
was not justified given the system's requirements, which are more focused on updates and notifications
rather than managing nested hierarchies.
26
3.3 Module 3 : Order Module
The diagram above is the use case diagram for the Order Module of the TAR UMT Cafeteria Ordering System.
Based on the diagram, we will create activity diagrams of the “Order Items”, “View Order History”, and
“Manage Orders” use cases.
27
3.3.1.1 Activity Diagram for Use Case Order Items
28
3.3.1.2 Activity Diagram for Use Case View Order History
29
3.3.1.3 Activity Diagram for Use Case Manage Orders
30
The observer design pattern was used for the class diagram of Order Module of TAR UMT Cafeteria Ordering System
31
The Observer pattern was chosen for the order module of the TAR UMT Cafeteria Ordering System. This is
because the system requires real-time updates to inform customers and cafeteria vendors about the order statuses,
the Observer pattern efficiently handles this requirement by notifying all observers (customers and cafeteria vendors)
whenever the order status changes. Other than that, the system has to promote the quality attribute of scalability to
handle multiple orders and multiple observers, the Observer pattern supports scalability by allowing multiple
observers to register with an order. It simplifies the process of adding or removing observers without modifying the
subject. Furthermore, tight coupling between order management and user interfaces can lead to a rigid system that
is difficult to maintain and extend. Thus, the Observer pattern was chosen to decouple the Order class from the
Customer and Vendor classes. This allows changes to be made to the Cafeteria Ordering System without impacting
how updates are received and processed by customers and cafeteria vendors.
The trade-off for using the Observer pattern is that it introduces additional classes and interfaces which
might potentially increase the system's complexity. However, the benefits of real-time updates and low coupling
outweigh the additional complexity. Moreover, the design is still manageable and improves overall system
maintainability. Another trade-off is that notifying a large number of observers could lead to performance overhead.
To mitigate this, the system can be optimised to ensure that notification overhead is minimised, such as by
minimising the amount of data that is sent during updates.
The Command Pattern was considered to be used as the design pattern for the order module of the TAR UMT
Cafeteria Ordering System. This is because the Command pattern could encapsulate requests as objects which could
potentially provide a robust way to handle operations related to orders. However, the Command pattern is more
suited for scenarios where operations need to be parameterized and queued. For the simple requirement of notifying
users about order status changes, this pattern would be overkill and add unnecessary complexity.
The State Pattern was also considered to be used as the design pattern for the order module of the TAR UMT
Cafeteria Ordering System. This is because the State pattern could manage the state transitions of an order by
encapsulating behaviours associated with different states. While managing state transitions is important, the primary
requirement here is notifying users of state changes, not encapsulating state-specific behaviour. The Observer
pattern is more directly aligned with this requirement.
In a nutshell, the Observer pattern was selected due to its alignment with the requirements for real-time
updates, decoupling of components, and scalability.
32
3.4 Module 4 : Payment Module
The diagram above is the use case diagram for the Payment Module of the TAR UMT Cafeteria Ordering
System. Based on the diagram, we will create activity diagrams of the “Make Payment”, “View Receipt” and
“View Payment History” use cases.
33
3.4.1.1 Activity Diagram for Use Case Make Payment
34
3.4.1.2 Activity Diagram for Use Case View Payment History (Customer)
35
3.4.1.3 Activity Diagram for Use Case View Payment History (Staff)
36
3.4.1.4 Activity Diagram for Use Case View Receipt
37
The selected design pattern for the payment module, the Facade design pattern, was chosen based on
several factors that make it well-suited for the requirements and constraints of the system. The payment module
involves interactions between multiple classes such as Customer, Payment, Receipt, PaymentHistory and Staff. Using
the Facade pattern allows us to provide a simplified interface (PaymentFacade) that encapsulates the complex
interactions and presents a unified interface to clients. This simplification makes the system easier to understand, use
and maintain.
By encapsulating the payment-related functionalities within the PaymentFacade, the system becomes more
maintainable. Changes or updates to the internal implementation of payment processing or receipt generation can
be made within the PaymentFacade without affecting the client code. This modular approach facilitates easier
maintenance and updates.
The Facade pattern promotes reusability by providing a single point of access to the subsystem's
functionalities. Other modules or systems within the application can also utilise the PaymentFacade to perform
payment-related operations, promoting code reuse and reducing redundancy.
The Facade pattern is also well-suited for systems with complex interactions and multiple subsystems. In the
case of the payment module, which involves interactions between customers, staff, payments, receipts, and payment
histories, the Facade pattern helps manage and coordinate these interactions effectively.
In conclusion, the Facade design pattern was selected for the payment module due to its ability to simplify
the interface, improve maintainability, enhance reusability and support complex interactions.
38
4. HUMAN INTERFACE DESIGN
4.1 Module 1 : User Management Module
39
4.2 Module 2 : Menu Module
40
4.3 Module 3 : Order Module
41
4.4 Module 4 : Payment Module
42

SDA Assignment

Uploaded by

SDA Assignment

Uploaded by

FORM 1

FACULTY OF COMPUTING AND INFORMATION TECHNOLOGY

Bachelor of Software Engineering (Honours)

BACS2073 SOFTWARE DESIGN AND ARCHITECTURE

NAME (BLOCK LETTERS) REGISTRATION NO. SIGNATURE MARKS

1. HON SHU YING 22WMR04089

2. RENE CHOONG QIAN HUI 22WMR04096 RENE

3. TAN ZI YEE 22WMR04102 ZiYee

4. CHONG YEE YANG 22WMR06378 YANG

Lecturer/Tutor Name: LIM FUNG JI

FACULTY OF COMPUTING AND INFORMATION TECHNOLOGY

NAME (BLOCK LETTERS) REGISTRATION NO. SIGNATURE DATE

1. HON SHU YING 22WMR04089

2. RENE CHOONG QIAN HUI 22WMR04096 RENE

3. TAN ZI YEE 22WMR04102 ZiYee 19/5/24

4. CHONG YEE YANG 22WMR06378 YANG

RENE CHOONG QIAN HUI User Management Module

TAN ZI YEE Order Module

CHONG YEE YANG Payment Module

1.1 Document Purposes

This document shall serve as:

1.2 Product Scope

1.3 Document Overview

Chapter Contents Summary

2. Ensure Accommodation to Fluctuating User Growth

3. Consistent and Reliable System Operation

1.5 Quality Attributes:

2.2 Comparison of the 3 Architectural Pattern

business logic and data

among multiple teams, or layers and reacting to layers right can be

3.1 Module 1 : User Management Module

3.1.1.2 Activity Diagram for Log In

3.1.1.4 Activity Diagram for Edit Profile

3.1.2 Design Class Diagram

3.1.2.1 Rationale for Selected Design Pattern

3.2.1.5 Activity Diagram for Filter Item

3.4.1 Use Case Diagram

3.4.2.1 Rationale for Selected Design Pattern

4. HUMAN INTERFACE DESIGN

4.1 Module 1 : User Management Module

You might also like