===================================================

PRINCIPLES OF SOFTWARE ENGINEERING

REPORT

StorageforLondon Case Study

Group Name: One

Bsc: Computer Science
4/12/2023
University of Greenwich
Assessor: Mr. Nguyen Anh Tuan

Members: Vũ Minh Quang, Đào Mạnh Kiên, Nguyễn Phan Anh,

Ngô Đức Huy, Cao Minh Đức, Vũ Quang Huy Anh.

===================================================
1
Table of Contents
A) 5Ps .........................................................................................................................................3
i) Problem ..................................................................................................................................3
ii) Process ...................................................................................................................................4
iii) Project ..................................................................................................................................8
iv) Product ............................................................................................................................... 10
v) People .................................................................................................................................. 11

B) Functional and Non-functional .......................................................................................... 12

Functional requirements: ........................................................................................................ 12
Non-functional requirements:................................................................................................. 13

C) Structured designs .............................................................................................................. 14

i) Entity Relationship Diagram ............................................................................................... 14
ii) Data Flow Diagram ............................................................................................................. 17
iii) The Prototype Database .................................................................................................... 19

D) UML Diagrams ................................................................................................................... 28

E) GRASP Patterns ................................................................................................................. 34

References: .............................................................................................................................. 41
Self Assessment Form.............................................................................................................. 42
Contribution Form .................................................................................................................. 45

2
A) 5Ps
i) Problem
1) Declining Subscriptions:
 Increased Competition: Customers have more choices when competitors offer similar
storage services. This intensifying competition has led to a decline in
[Link] LTD's subscriber base.

 Market Saturation: The storage facilities market in London might be reaching saturation,
causing a struggle for customer acquisition and retention.

2) Inefficient Customer Service:

 Delayed Confirmations: Customers face a significant lag between arranging box
collections/returns online and receiving email confirmations. This delay causes
frustration and uncertainty about the status of their requests.

 Long Wait Times: The lengthy wait time (10-15 minutes) for customers to reach a CSR
when calling impacts customer satisfaction and suggests inadequate staffing levels to
handle the call volume.

3) Most orders arrive by phone instead of the software

Rich picture

3
ii) Process
The purpose is to implement an online mobile app that allows customers to customize their
storage subscription and do any procedure via an app.

Some of the headers’ perspectives (Mr Wolf or the general director) view it as a great solution to
potentially ease the staff workload, focusing more on extra customer inquiries.
→ Eventually leading to the expansion of a new customer base (mainly targeting young
audiences who are handful with gadgets)

In that case (with limited human resources, budget, and time), a waterfall model would be the
most suitable choice for the following reasons.

Waterfall: A sequential development process that flows like a waterfall through all phases of a
project

Pros: This method is simple, has stable requirements, and is easy to operate when the project
scale is small and not complex.

 Their company's requirement is well-defined and stable, so it fits well with the waterfall
process.

 The waterfall method can provide a stable structure to work with stable requirements,
especially if the company has a clear vision for the app.

 The method has a formed phase (Requirements, Design, Implementation, Testing,

Deployment), and it is suitable for this project when the company needs a structured and
systematic development process.

 Documentation for this method is crucial when it could be used to train employees.

 Staff can use the Documentation for reference purposes. Also, the waterfall method can
respond if the company has a fixed budget of £80,000 and wants a precise method of
spending money.

Cons: Limited flexibility, hard to get feedback soon, and it takes a long time to market

 Each phase should be done before moving on to the next phase to avoid confusion and
overload tasks.

 This method does not recommend making changes between phases, and if they are
looking for a solid foundation that fits their budget and timeline, the waterfall method is
the best option.

4
  While the Waterfall methodology offers these advantages, it is essential to realize that it
may not be suited if project requirements are likely to change frequently or if the
customer's early and continuous feedback is required.

Agile: The Agile methodology highly promotes collaboration as the key to success. This
method also helps Staff reduce the amount of work to do and split the project into many phases.
Moreover, it works based on continuous advancement throughout its life cycle and adjustment to
adapt quickly.

Pros: Flexibility, can respond quickly to customers and provide a small part of the process

 Agile methodology adapts requirements if the company wishes to progress in market

trends.

 This method can deliver a prototype product after a period, making it easy for customers
to check progress and adjust.

 They should implement this agile method if the company is looking for a quicker time-to-
market.

 Long-term cooperation is also an advantage of this model, but it is crucial to require

continuous feedback between end-users and stakeholders.

 Exchanging information frequently means the possibility of failure in the main project
will be reduced.

 Opinions need to be consistent and unified to avoid conflicts when the premise of this
model is communication.

Cons: Limited flexibility, lack of Documentation, needs close cooperation

 Processes require vigilance during the management phase to avoid uncontrollable

situations that can significantly impact budgets and schedules.

 This method does not concentrate much on Documentation but primarily focuses on
customer and user feedback.

 Simultaneously, ask customers to cooperate and provide timely feedback and

contributions to enhance the project.

 Furthermore, they can take a while to pick up this method if they need background
knowledge.

5
Conclusion: For a project that needs well-defined and unchanging requirements, the Agile
methodology must respond to their requirements. In such cases, the Waterfall methodology
might be more reasonable.

The waterfall model:

It is a simple methodology, following a sequential and linear approach that applies well in
simple, straightforward projects. In the waterfall model, each phase would be done before
moving to the next one, though few backups might be allowed during the progress. In detail, a
waterfall model has well-defined phases. Plus, the model also ensures a consistent flow of
activities since each phase is built upon the output of the previous phase. Moreover, a waterfall
model is a documentary-driven process. Therefore, it emphasizes the documentation for each
stage: requirement specification, design document, implementation, test plan, deployment, and
maintenance. Clear documentation would facilitate the process of understanding and capturing
the essentials of the issues and boosting the implementation and maintenance process later.

Waterfall: This project follows a top-down sequence for 8 months

No Work 4 weeks 5 weeks 8 weeks 9 weeks 6 weeks
1 Requirements
2 Analysis
3 Designing
4 Coding
5 Integration

: means deadline finished.

These will include a few main stages:

1) Specification and analysis of requirements:

 The idea is to provide the most optimal experience for the customer and be able to deal
with the increase of competition in the specific storage facility market.

 Also, it helps with keeping track of the business progress and gaining more data
resources (customers find the current system not having enough info to solve their
problems)

2) Designing:

 Having a search bar that would help customers with browsing and searching for specific
required items.

6
  A function in which customers register for the first time to create an account where
detailed information about the customer would be well-recorded. Once users have an
account, proceed to offer the size of the boxes.

 A system to track the boxes so they can be delivered to the associated clients and ensure
doorstep collection and returns.

 Another system to calculate bills for boxes, purchases, and collections returned.

 The app also needs to drive the customer to formal procedures. When they want to settle
a bill, first they need to log in, then be able to proceed to payment (only credit card
allowed). The credit card part would be tackled by the company (by linking to a
VISACheck system).

3) Test plan:
The objective of the application is to bring up the best experience for customers, whether they
are browsing or customizing their orders. Therefore, a good test plan requires an overall test that
covers all the details.

4) User interface testing:

The system needs to ensure browsing and searching functionality and provide an attractive,
responsive interface to customers.

5) Registration interface testing:

 Ensuring customers can successfully register and see all their account info, which should
be automatically updated in the system.

 Storage deal request and box tracking process: verifying that the system can receive the
customer's chosen box information.

 Box tracking system: The system needs to be able to identify each box and accurately
associate them with the respective customer.

 Real-time bill settlement: Validate the ability to settle bills in real-time for customers.
Also, test the credit card payment function.

 Special offers: Creating a test to examine the functionality that assists sales
representatives in profiling customers based on the number of boxes they ordered. Ensure
that any special offer can be sent to associated clients via the app.

 Security testing: Test the security system to identify vulnerabilities related to user data
and any relevant performance around it.

7
6) Deployment:
 Mobile app: Deploy an application that provides a good-looking interface that contains
browsing and searching abilities and registration interfaces. Besides, all management
capabilities should be checked to see whether they can make storage deals, set bills, track
the box status, and create special offers.

 Server infrastructure: Set up an infrastructure to store a backend system, interpreted as

any structure that runs in the background to support back-office applications such as data
processing.

 Database system: Deploy a reliable, well-designed database system to ensure efficient

data retrieval and storage.

7) Maintenance:
 Bug fixes: Fixing bugs does not only include rewriting codes but also requires identifying
the root of troubles based on documentation of previous steps.

 Database maintenance: Conduct routine data maintenance to guarantee data backup and
smooth performance in real-time.

 Software update: Software updates must be implemented regularly to constantly enhance

the customer's experience.

iii) Project
Milestones:
 Improve customer experience.
 Operational efficiency
 Overtake changing trends.
 Business enhancement and innovation.

Deadlines: 8 months

Activity view:
1) Staff Training: workshop, online courses
 Customer data handling, navigation, troubleshooting common issues, and effectively
utilizing the app to enhance customer experiences.

2) Design Phase: Design documents, wireframes, ...

 Database design, defining system interfaces.

3) Analysis Phase: Requirement specifications, use cases, user stories

 Analyze existing systems, workflows, and customer feedback.

4) Development Phase: working app, test report, ...

8
  Writing code, implementing features, integrating APIs, ...

Resource view:
1) Staffing/Limitations: around 10-15
 1 manager: responsible for project, planning and ensuring.
 3 developers: responsible for developing the app.
 2 designers: responsible for creating wireframes, module.
 1 tester: testing and evaluating.
 1 business analyst: responsible for gathering requirements, analyzing business needs.
 2 supporters: responsible for supporting customers.
 1 trainer: responsible for training staff

2) Budget:

No Role Budget Allocation

1 Manager £15,000
2 Developers (3) £25,000
3 Designers (2) £8,000
4 Testers (2) £10,000
5 Business analyst £7,000
6 Supporters (2) £7,000
7 Trainer £4,000
8 Other costs incurred (apps, risks, living) £4,000
Total budget £80,000
3) Deadline:

No Role Allocated Task Deadline

1 Manager Project overseer and team coordinator 8 months
2 Developers (3) App development, backend/frontend 5 months
coding, bug fixing
3 Designers (2) UI/UX design, wireframing, graphic 8 weeks
design
4 Tester Test planning, execution, bug tracking, 13 weeks
quality assurance
5 Business analyst Analyze project requirements, 9 weeks
document specifications
6 Supporters (2) User support, issue resolution, 8 months
technical assistance
7 Trainer Training material creation, user 5 weeks
training sessions

9
4) Tools:
 Design apps.
 Development apps.
 Testing apps.

Product view:
 Type of system: app

Outcome view:
Risk assessments:
 Compatibility Issues (Incompatible operating system): testing on different platforms and
versions.
 Security Vulnerabilities: include rapid patching, isolating affected parts and notifying
customers.
 Overspending on the Budget: Evaluate the possibility that unexpected bills may cause the
budget to be exceeded.
 Unexpected Technical Difficulties: Assess the possibility of encountering issues and
schedule time for troubleshooting and addressing issues.

iv) Product
The main feature of the application:

 Provide a mobile app for both platforms (android and iOS) that has a friendly user
interface.

 The app has a search box to help users quickly find the items they want.

 Account registers and a profile management system to save user data. Visa should also be
provided for online payment.

 Having a real-time system that can help people manage products and box tracking.

 Our Staff will deliver the boxes quickly once deals are confirmed.

 AI systems respond to customer requests and help them to find their desired products.

 Implement a secure connection to VISACheck for credit card verification.

 Our app also has a firewall to enhance security and protect sensitive data from all users.

Implementation phase:

10
  With the help of automation software, manual steps are significantly reduced. Then, we
will manually check to ensure no errors occur and the programs work correctly.

 We also make a training schedule to ensure the outcome is guaranteed.

 Test Scripts: Automated scripts for executing repetitive and complex test scenarios.

 Doing tests to determine remaining problems, then collecting data from each fail and
pass.

Documentation:

 Staff will use documentation to train new employees and benefit as a reference tool when
problems arise.

 For end-users, we will train them to use the app correctly.

 We also run a diagnosis program to find and fix bugs immediately.

 To improve user experience, we will get their feedback to adjust later.

 The basic requirements of users are critical for us to develop our application.

v) People
The article identifies the project's primary stakeholders, such as the customers, representative
salespeople and staff, the senior management, executive people, the general, aka Mr Wolf and
the sales director, aka Mr Fox.

1) Customer:
The vital group of people that are mentioned most in the article. They can locate the business via
introduction, advertisement, magazine or accessing the company's website.

Half of them feel the CSRs did not have enough information to thoroughly understand their
issues and needs.

2) Representative sales and staff:

 Hesitant about the online system development.
 Expressing a preference for phone interactions over computer use
 Friendly approach is invaluable, resisting training due to concerns about potential job
insecurity in the future.

3) Senior management:
 Troubled by the drop in subscriptions, which is linked to heightened competition.
 Acknowledge the significance of innovation and enhancing the customer experience.

11
→ The absence of support time on the online platform results in delays for customers in getting
email confirmations for box collections, and the time spent waiting for customer service calls is
ascribed to a staff shortage.

4) Executive:
They hope that these applications, which empower customers to manage storage subscriptions,
request collections/returns, and make real-time payments will be done successfully to alleviate
the workload of customer sales staff, enabling them to focus on addressing other customer
inquiries.

Mr. Wolf – General Director:

 Considering the mobile application development to expand the subscriber base and forge
meaningful customer relationships.

 Particularly targeting a younger audience and business-focused individuals who are more
accustomed to using mobile devices for their purchases.

 Endorsing the new app, aiming to increase sales through customer profiling and exclusive
deals. → The initiative is geared towards significant cost reduction, efficient handling of
rapid expansion, and augmented revenues through customer profiling.

 To improve current customer satisfaction with the implementation of the app.

Mr. Fox – Sales Director:

 Having different opinions about the new app, attributing the limited use of the online
system to a lack of personal contact.

 Advocating for enhancing the existing online system to provide real-time support rather
than investing substantial funds in app development.

B) Functional and Non-functional

Functional requirements:
1) User registration and manageable profile:
 Users should be able to register their accounts, as well as create and manage their
information.

2) Browsing and searching storage deals:

 Users should be able to browse and search for boxes in storage and deals in the
application.

 The application must show available boxes (small, medium, large) in storage.

12
3) Creating deals:
 Users should be able to request deals by providing information.

 The system must differentiate whether users use their own boxes or want to purchase new
ones.

4) Box tracking and warehouse management:

 The application must provide the position and information of the users’ boxes.

5) Pick-ups and returns:

 Users should be able to schedule when the courier can collect or return their boxes.

6) Provide special offers:

 Creating special offers and giving them to the users.
 Users can redeem the special offers by entering the code.

7) Billing and payment:

 The application must calculate the bill monthly.
 Users should be able to pay the bill by credit card.

8) Real-time assistance and support:

 Provide a real-time support and assistance service in the application for the users.
 Collect users’ reports monthly.

9) Security
 Implement a secure authentication system and data encryption.
 Ensure credit card information is correct through VISA_Check.

Non-functional requirements:
1) Speed
 Provide a fast and responsive experience.
 Minimal response times for browsing, submitting requests, and processing payments.

2) Scalability
 The system should be able to handle the growing amount of people and demand.

3) Reliability
 The application should be available 24/7 with minimal downtime.

4) Usability
 Provide a user-friendly interface.

5) Compatibility
 The application should be able to run on most of the mobile devices and operating
systems.

13
6) Data integrity
 Maintain the integrity of users’ data and transaction records.

C) Structured designs
i) Entity Relationship Diagram
An ERD depicts the Relationship between entities. By playing a role as a starting point in
creating a database, ERD is the logical representation of how data is stored, organized, and
related to each other. Several functions could be served using an ERD.
 Communication: ERD plays a crucial part in conveying the data structures, and as a
result, it helps stakeholders and managers visualize the components that make up the final
product, as well as facilitates the design development and maintenance. Moreover,
developers and designers can easily document the process and find the root of the error.
Therefore, they can make informed decisions and other performance considerations.

 Normalization: can be interpreted as a process to reduce data redundancy and help

integrate data through representing other entities with extra related data that holds the
primary key of the considering entity. This forms a relationship that optimizes data
performance and ensures efficient data storage.

 Data Integrity and Accuracy: With clearly defined relationships, data will be ensured
with no duplication and inconsistency.
An ERD is composed of some key concepts, including:
 Entities: an object, collector of things that share common characteristics and properties)
that is often displayed in table form.

 Attributes: known as objects’ properties and characteristics. It can be interpreted as

relevant variables holding details of an object.
Example: Person(object) has name, age, and gender as attributes.

 Relationship: Show how objects link with each other. The Relationship is a meaningful
association that helps document the interaction between 2 entities. Also, a relationship
has its cardinality (like one-to-one, one-to-many).
Overall, ERD model data uses graphical tables or specialized symbols such as rectangular and
round shapes (not recommended) to illustrate a blueprint of the data system for further steps
later.

14
The ERD diagram of us shows the following entities and relationships:

1) Entities:

 Customer: A person who places orders.

 Ordering: a step to record customer's options (items for storage, containers)

 Items: Items that the customer wants to store

 Container: things used for storing customers ‘items

 Items storage: Place to store items.

 Warehouse recording system: to check items' status.

 Tracking system: to ensure items are collected and sent to associated warehouses as well
as returned to associated customers.

 Receipt: A confirmation of an order.

15
  Payment system: A method of paying for an order.

 Staff: An employee of the company.

 Sale Representative: A person who (within this case study scale), is responsible for
grasping the customers ‘profiles, managing and providing special offers.

 Special offer: A discount, that’s provided to customer with good profile.

 Bill-calculating system: A system that gives out bills based on the storage rate.

2) Relationships:

"Customer" and "Ordering" entity

 One customer can have one or many orders.

"Ordering" and "Container" entities

 One or many orders can use the same type of container.
 One or many types of containers can be used in one order.

"Ordering" and "Items" entity

 One order can include one or many items.

“Ordering” and “receipt” entity

 One order can only have one receipt.

"Ordering" and "Payment_system" entity

 One order can only be associated with one payment system.

"Items" and "Item storage" entities

 One or many items can be stored in one storage.

"Item_storage" and "Warehouse recording system" entity.

 One item's storage can link with only one warehouse recording system.

"Receipt" and "Tracking System" entity

 One or many receipts can be gathered by one tracking system.

"Receipt" and "Calculating Bills" entity.

 One or many receipts can be gathered by one bill-calculating system.

"Staff" and "Tracking System" entity

 One tracking system can be accessed by one or many staff.

"Staff" and "Warehouse recording system" entity.

16
  One or many staff can manage only one warehouse recording system.
 One sales representative can provide zero or many special offers.

"Sale representative" and "Special offer" entity

 One or many special offers can be provided to only one customer.

"Special_offer" and "Customer" entity

 One or many customers can obtain the same special offer.

The ERD has done well in capturing most essentials of the London Storage facility scenario with
the proper ERD format. The entities are displayed well, and the relationships are meaningful.

Explain in detail:

 The “Customer” entity provides basic info enough to be identified and converted to a
customer profile for application usage.

 The “Ordering” entity plays a role as the hub, linking many service entities like “payment
system” entity, “container”, and “items” entity assisting customers in the ordering
process and proceeding to the next steps.

 The “Container” entity supplies containers for items storage.

 The “items” entity identifies the kinds of items that the customer wants to store.

 The “items storage” entity plays a role as the warehouse for items to be stored inside.

 The “warehouse recording system” entity is used to check items ‘status, whether it’s in
stock or already at the customer’s house.

 The “Receipt” entity is used to synthesize the ordering info, working as a bill.

 The “Tracking system” is linked to the “receipt” and “staff” entities, so that staff can
access and track the delivery status of the items.

 The “calculating bill” entity, used to calculate monthly bills based on storage rate.

 The “Staff” entity links to the “warehouse recording system” entity so that staff can grasp
the “items status” (whether they are at customers ‘s houses or remain in the warehouse )

 The “Sales representative” entity links to the “special offer” entity, allowing sales
representatives to provide special offers to customers.

17
  The “Special offer” entity has a “special offer content” attribute. This is useful for storing
the details of the special offer, such as the discount amount, expiration date, and any
other relevant information.

Overall, the ERD diagram is a good example of a well-designed database schema. It is clear,
concise, and easy to understand. , The cardinality constraints are all correct, and the relationships
are all meaningful. However, the “Sale Representative” does not have any direct relationship to
other entities, and only relates to the other entities through the Special offer entity.

ii) Data Flow Diagram

A DFD is a diagram that mainly focuses on data movement within the system by illustrating how
data is initiated, processed, and terminated within a picture. The DFD is often used in software
analysis as a tool to model interaction between components step by step using data flows. DFD
has different levels of detail; in the scenario, the requirement only specifies use at level 0, which
defines the system architecture in general.

DFD is composed using 4 key elements:

 Process: includes activities that deal with transformation and adjustment of data(output
data must be different from input data)

 Dataflow: the movement of data amongst entities, data stores, and processes

 External Entities: sources or destinations that are located outside of the system boundary
are places that initiate or terminate the flow of data.

 Datastore: The container that stores data.

DFD serves several key functions.

 Data modeling: Modelling the data flow and ensuring the most efficient system.

 Identifying processes and data stores (data store doesn’t appear in the DFD of this case
study scenario): Represent functions that transform data, and store data so that data can
be reserved and retrieved efficiently.

 System decomposition: allows for an easy approach in an analysis. Therefore, developers

can break down conceptual diagrams dealing with generality into processes and other
detailed parts in higher-level diagrams.

18
My DFD diagram shows the interaction between customers and the systems, partly operated by
staff.

Relationship of each entity:

1) Customer:
 Request to search for containers: Customer interacts with the system to request to search
for specific types of containers( help store their items) and then proceeds to make an
order
 Receive special offers provided by sales representatives.

2) Sale Representative:
 Profile customers based on a range of factors, such as the time of leasing, quantity of
items, or even special types of items that require distinctive storing methods... Then
special offers will be provided depending on the customers’ profile info.

3) Supplier:
 As the source of containers, the Supplier supplies containers (mostly boxes) for storage
purposes.

4) Staff:
 Record the warehouse using another proper system integrated with the mother system,
which works as a function to check the product status, whether in the warehouse or at
customers’ houses.

19
  Staff can also receive delivery status from another system to ensure a smooth delivery
process and promptly cope with any unexpected issue during the process.

The DFD displays a well-functioning system that captures the essentials of the scenario at a
conceptual level. In detail, external entities and relationships are all present and interact well
without visual error when following all DFD standards. Overall, it is a transparent, well-designed
system that is easy to understand.

iii) The Prototype Database

1) Creation
Following the choice of Microsoft Access for its ease of use and swift prototyping, the database
implementation commenced with a meticulous analysis of the database design. This initial phase
focused on structuring tables, establishing relationships, and defining crucial entities vital for the
basic functioning of the prototype database system for [Link] LTD's operations.
The primary step involved creating multiple tables, each meticulously designed to ensure optimal
data integrity and coherence. These tables were structured to encompass essential information,
laying the groundwork for the prototype database system to process fundamental queries
effectively.

Attributes and relationships within these tables were carefully defined, ensuring that data
remained consistent and interlinked across various aspects of the database by establishing
referential integrity across all tables.

20
2) Database Functionality
Here, we will be testing the functionalities of the database to ensure that it can run basic queries
for the system. We will mainly be tackling these points:
1. Add a customer to the system.
2. Update/delete customer details.
3. Add a box type to the system.
4. List all boxes a customer is storing, including their ID, warehouse, and size.
5. Create a collection/return order for a customer.
6. Create a monthly bill for a customer.

1, 2. Adding/Updating/Deleting Customer Information:

For this function, we must first set up the form and add the fields we wish to include in the form.
For our prototype, we have built a basic version that employees can use to update their customer
information, add new records, and delete them, as well as an option to find available records.

21
To test the function of things, we will add information to the form and then check the control
source table to ensure it works properly.

The record will appear in the database once we have added the customer information and pressed
the “Add Customer” button.

22
Next, we can see that CustomerID 49 is missing information. We can then update their record in
the table using the search function in our form.

Or we can choose to delete the record if we no longer require it:

23
3. Adding another Box Type to the system:
Similar to the customer form, through the box type table, we can create another box to facilitate
adding another type of box to the preexisting ones on the database.

These are the current box types and their information.

Through similar steps to adding a customer, we can add another type of box like the previous one
using the form.

24
4. Listing all boxes a customer is storing, their ID, warehouse, and size.
To do this, first we need to make a query to show the relevant information for the form.

25
This query joins the `Boxes` and `BoxInfo` tables on the `BoxTypeID`, as well as other essential
data to display the boxes the customer has in storage, their ID, sizes and where they are located.
Afterwards, we can create a form to access the relevant data. First, we set the control source to
the query and then we used a combo box to find the customer. Afterwards, we can return to the
query and type in [Forms]![Form1]![Customercombo_Label], where Form1 is the form name,
and Customercombo_Label is the combo box name which we previously designated. Through
this, we can either scroll through to find the desired customer or enter their name / ID to access
their data.

After running the query, we can see the information in the datasheet.

26
5. Create a collection/return order for a customer:
For this function, first we created a form through the “Sale” Table. While creating this table, we
decided that it’s best if we use Lookup for order type.

Then we add simply add the basic features for this function including finding an order, creating
an order, and removing an order.

Testing the function:

6. Create a monthly bill for a customer.

Here firstly we must create a query to calculate the price of the bill the customer has to pay.

27
Here we joined the tables to the appropriate field. Then in a blank column in the query design
grid, clicked on the "Field" cell to add a calculated field using TotalCost:
[PerMonth]*[Duration]

Next, we created a form to display the result of this query:

We created a basic form for this operation that by typing in the Customer ID, it will show the
order date and duration based on pre-existing table information, and by pressing Create Bill, it
will display a myriad of data required to create a monthly bill for the customer.

28
D) UML Diagrams
UML diagrams offer a standardized method for depicting and conveying system designs.
Employed across the software development lifecycle, they play a crucial role in the analysis,
design, and documentation of system architectures. Various types of UML diagrams exist, each
with a distinct purpose, capturing different system edges. General types include class diagrams,
use case diagrams, sequence diagrams, activity diagrams, state machine diagrams, component
diagrams, and deployment diagrams.

i) Use case diagram

29
Our use case diagram illustrates the interactions among different entities and the system,
concentrating on a company providing box delivery services. It emphasizes the actions that
various actors, including customers, staff, and customer sales representatives, can undertake.
This diagram effectively portrays the connections between actors and the box delivery system,
showcasing the system's functionalities and tasks. It offers valuable insights into the system's
capabilities and the responsibilities of different users, aiding comprehension of the overall
system design and functioning.
 Association: The system is connected with different actors, demonstrating their
engagements and the features they employ.

 Include: The ‘Provide personal details’ is included by ‘Creat account’ means that the
customer must fill in their personal information to create their account.

 Extend: The 'Purchase Box' use case expands upon the 'Creat deals' use case, signifying
that it is a particular action that customer can chose to do or not.

ii) Interaction diagrams

UML diagrams offer a standardized method for depicting and conveying system designs.
Employed across the software development lifecycle, they play a crucial role in the analysis,
design, and documentation of system architectures. Various types of UML diagrams exist, each
with a distinct purpose, capturing different edges of the system. General types include class

30
diagrams, use case diagrams, sequence diagrams, activity diagrams, state machine diagrams,
component diagrams, and deployment diagrams.

1) Sequence diagram of customer

The Unified Modeling Language (UML) diagram of us represents a sequence diagram,

illustrating the order of interactions among objects within a system, specifically a box delivery
service. This sequence diagram outlines that the customer initiates the interaction with the
system by submitting a request to browse and find available boxes and deals. Subsequently, the
system responds by furnishing the customer with a list of available selections. The customer can
then make a choice and proceed to the checkout phase. During checkout, the customer is
prompted to create a new account or sign in to an existing one, providing personal and shipping
details. The system then computes the total delivery cost based on weight and the distance
parameter's distance. The customer has the option to make a payment using a credit card or
another chosen method. The system verifies the number of credit cards when making a payment
via credit card. When the payment is successful, the system will send a confirmation message to
the customer and dispose of the delivery schedule.

In summary, the sequence diagram offers a straightforward and succinct summary of the actions
required to initiate a box delivery order. Additionally, it illustrates the connections among
different entities within the system.

2) Sequence diagram of sales representatives

31
This our Sequence diagram depicting a system that enables sales representatives to generate,
modify, and revise their documents. The diagram delineates the series of interactions among
diverse entities within the system when a sales representative initiates the creation of a new
document. Based on the sequence diagram, the sales representative's first interaction relates to
sending a request to the system to create a new document. Next, the system exhales a new
document object and transmits it to the sales representative. The sales representative is then able
to change the document object by incorporating, removing, or altering text. Towards completing
the document edits, the sales representative can request the system to save the document. The
system, in turn, preserves the document object in a persistent storage location.

In summary, the sequence diagram describes an explicit and brief outline of the procedures for
generating a new document within the system. In addition, it depicts the interfaces among
different entities in the system.

3) Sequence diagram of staff

32
Our sequence diagram shows how a staff member records a warehouse. According to this
diagram, the staff initiates interaction with the system by submitting a request to discover the
items in the warehouse. Next, the system responds by messaging a list of available items to the
staff, and from that, the staff can choose an item and check the item's position and condition.

In conclusion, the sequence diagram offers a transparent and succinct summary of the processes
for recording the warehouse.

iii) Design UML Class Diagram

The class diagram delineates the arrangement and interfaces among different classes within a
system responsible for overseeing the services. It embodies the data attributes and methods
linked to each class, offering a lucid comprehension of the system's data model and
functionalities.

33
• Staff: This class represents the storage’s staff, who have their personal information such as
Name, Email, .... and have methods like RecordWarehouse and Login.

• CustomerSalesRepresentatives: This class has the same features as the Staff class but have
different methods.

•Customer: This class represents the users of the application, who also have specific attributes
such as Name, Email, Address, ..., and methods like BrowseAndSearch, CreatDeals, ...

• ProfileCustomer: This class signifies a customer's profile list, storing personal details like
name, email, address, age, and gender. It encompasses methods like ReturnCusinfo() to retrieve
customer information.

• SaleInterface: This class furnishes specific functionalities for these interactions of

SalesRepresentatives, such as ProfileCustomers() for creating customer profiles .

34
• StaffInterface: This class depicts specific functionalities for the interactions of Staff, such as
RecordWarehouse() and Login().

• MySpecialOffer: This class represents a special offer generated by the system or customer
sales representatives. It includes an Offernumber attribute for unique identification and a method,
ReturnBillCost(), to retrieve customer information integrated with the offer.

• DealCalculator: This class computes the total price of box delivery relying on weight and
distance parameters. It features the method CalculateTotal(weight, distance) to ascertain the
delivery cost.

• VISACheck: Responsible for verifying the validity of a credit card number, the attribute
CheckValidation: bool denote this one.

• TrackingSystem: Managing the tracking of box deliveries, this class may include
functionalities like real-time tracking, notifications, and location updates.

• MyDeals: Representing a collection of special offers created or redeemed by a customer, it

comprises an AnswerDealInformation: str attribute to store specific deal information. The
DisplayDealDetail() method showcases detailed information about a selected deal.

• MyAccount: This class encapsulates a customer's account, storing personal and account-related
data such as CusName, CusEmail, CusAddress, and CusCredit. Its solutions, including
CreateAccount(), ArrangeCollectionsAndReturns(), SettleBills(), and UseSpecialOffers(), deal
with various account-related tasks.

• CustomerInterface: This class furnishes specific functionalities for these interactions of

customers, such as BrowseAndSearch(): str for perusing available boxes and deals.

• Application: This class represents the overarching system application, overseeing interactions
among various classes and addressing user requests.

•StorageForLondon: This class is the company who use the application to operate.

E) GRASP Patterns

Coupling: is the measure of the degree of interdependence between the modules

 Low Coupling: is not dependent on too many classes. It has enough classes to operate. A
good software design surely needs low coupling design for several reasons such as
minimal impact on changes, encouraging little reliance.
 High Coupling: on the other hand, high coupling contains dependence on several other
classifications. It is hard to change, reuse and understand in isolation.

35
Cohesion: a measurement of the degree of functional relationship between the module's parts. It
is the extent to which a component includes every part used to carry out a certain activity.

 Low Cohesion: it contains numerous contents between parts in class. Therefore, it has no
concentration, it can lead to overwhelming responsibility, hard to reuse and maintain.
 High Cohesion: a group of closely connected tasks that don't need a lot of labor. This is
good for software design when it maintains the object's focus, comprehension, and
manageability.

However, we need to balance between low coupling and high cohesion wisely. This is our DCD
that illustrates coupling and cohesion:

As can be seen, we try to make low coupling and high cohesion as possible, but it still has
various high coupling or low cohesion.

36
 Low Coupling: class MySpecialOffer, ProfileCustomer and MyAccount

 High Cohesion: MySpecialOffer, ProfileCustomer, DealCalculator, VISACheck,

MyDeals and TrackingSystem

37
38
Information Expert: is the class that possesses the data required to fulfill the obligation.
Basically, a class only needs to fulfill the responsibility for the information that is related to its
name. These are our Information Experts:

39
Creator: is a class linked to the newly generated class or object in order to keep coupling low.
Here is our Creator:

 Application plays a role in being creator of SaleInterface, CustomerInterface and

StaffInterface.

● SaleInterface is also a creator of MySpecialOffer and ProfileCustomer

40
  CustomerInterface is a creator of MyDeals

Controller: is a class that runs beneath the user interface layer and distributes events to different
objects. Controller represents the overall system or use case. However, controller should not
have much responsibility or manage system activity These are the 3 controllers of DCD:
SaleInterface, CustomerInterface and StaffInterface

41
References:

Josikakar (2023), ‘Software Engineering | Coupling and Cohesion’, GeeksforGeeks. Available

at: [Link] (Accessed: 11/2023)

Rahul Awati (2020), ‘polymorphism’, TechTarget. Available at: [Link]

(Accessed: 11/2023)

Chat GPT, budget and deadline for staffs, December 4 2023

42
 A B C D E F Comments
the 5 Ps X
 Problem: We have provided 3 main problems
of the StorageForLondon company,
and a rich picture of the whole
problem.

 Process X The most suitable model was

depicted with a comparison of
another model to explain our
choice, and a schedule with well-
detailed stages.

 Project X We have given detailed project

with milestones, deadline, activity
view, ..., the budget allocation, and
a timetable for each phase.

 Product X All the specifications of the

required product were given.

 People X We have shown all the people

involved with their roles or desire.

43
 functional and X All the main function of the app
non-functional were illustrated with other
requirements: necessary functions

Structured design,

 Entity Relationship X
Diagram

The ERD and DFD diagram’s

images were given with clear
explanation of the role of each class
or entity.

 Data Flow Diagrams. X

 SQL queries X The explanation of the creation and

of the test results were shown.

UML Design

Use Case Diagram X

44
 X
Design Class diagrams
The three diagrams were given with
their clear explanations of the
interactions between actors and
classes.

X
Sequence Diagrams

Use of patterns X The GRASP pattern such as low

coupling, high cohesion, ... were
applied and shown with
explanation.

45
Contribution Form
Group/Team Name: One

Team member name Student ID individual overall work Signature

contribution (%)
Student1: Vũ Minh GCH230200 16.67%
Quang

Student2: Nguyễn Phan GCH230207 16.67%

Anh

Student3: Đào Mạnh GCH230235 16.67%

Kiên

Student4: Ngô Đức Huy GCH230154 16.67%

Student5: Vũ Quang Huy GCH230069 16.67%

Anh

Student6: Cao Minh Đức GCH230132 16.67%

Total 100%

46