ASSIGNMENT

COVER SHEET
Student Name & ID 1. Nur Asfia Binti Jamaluddin (B02170024)
2. Nusrah Nafi’ah Binti Headir (B02170027)
3. Adla Fikriyah Binti Ibrahim (B02170029)

Course Code & Name Formal Methods

Assignment No Final Assignment

Assignment Title Z-Specification

Prepared For Sir Nor Adnan

Due Date Monday, January 20, 2020

DECLARATION

This assignment is my own original work.

No part of this work has been copied from any other source or person except where due
acknowledgement is made, and no part of the work has been previously submitted for assessment
at this or any other institution. I have read the Student Academic Integrity Policy and understand its
implications. For the purposes of assessment and standards, I give the University permission to
retain this assignment; provide a copy to other assessors; and evaluate its academic integrity
through the use of a plagiarism checking service (which may store a copy of the assignment on its
database for future plagiarism checks).

Student’s Signature
(representative)

Date

To be filled by Lecturer

Marks

Comments

Date Received
 TEAM

Abbreviations
The table below shows the abbreviations that are going to be used in this document.

Abbreviation Explanation

GPM Global Personal Marketplace

The use case that will be chosen in this Z-specification is taken from the Global Personal Marketplace
System Requirements Specification (SRS). The chosen use case is Read Buyer Guidelines, Review
Personal History and Register Feedback About Seller.

1. Use Case Diagram

Figure 1.0 : Use case diagram for Buyer actor in GPM

Figure 1.0 shows the partial Use Case Diagram for Buyer actor in GPM, including the use cases
that are chosen and will be explained and specified in this document. Buyer is the role that is
played by any user who uses the GPM to purchase one or more items being sold by a Seller by
using the GPM.
2. UCD01 : Reads Buyer Guidelines

This use case enables buyers to read buyer guidelines from the GPM. This use case is activated
by the Buyer and communicates with the GPM to request for the GPM to display the Buyer
Guidelines for the Buyer to read. This use case is important in allowing Buyers to learn how to
buy before deciding if they want to buy at a sale.

2.1. Use Case Description

Use case name ReadBuyerGuidelines

Participating actors Initiated by ​Buyer

Communicates with ​GPM

Flow of events 1. Buyer ​sends request to the ​GPM​ to display buyer guidelines
2. GPM ​displays buyer guidelines on the screen
3. After ​Buyer ​has completed reading the buyer guidelines,
Buyer​ signals completion to the ​GPM​ by clicking exit.

Entry condition ● Buyer ​is already on the webpage on the browser where
he/she can request the display of buyer guidelines

Exit Condition ● Not applicable

Quality Requirements ● The buyer guidelines will be displayed on the screen within 10
seconds after the request has been done, depending on the
Buyer​’s machine’s internet connection.

2.2. Z-Specification

To specify the Read Buyer Guidelines use case, we first note down the properties of the actors
that are involved in this case. The actors involved are the Buyers and the GPM.

Request = mpage | bguide

Display = mainpage | buyerguidelines

The type Request have values of either mpage or bguide. These values are given by the Buyer
that indicates which display that they would like to see from the GPM. The type Display have
values of either mainpage or buyerguidelines. The Display type denotes the display that should be
shown to the user based on the user’s request.

The Buyer actor has one parameter which is request, which is of type Request. This indicator is
used to inform GPM on which display the Buyer would like to see. The request parameter should
not be null.

The GPMDisplay actor has only one parameter which is display. This display parameter defines
the display that is to be shown on screen, and depends on the request that is given by the Buyer.
The GPMDisplay is the Main Page by default.
 The DisplayBuyerGuidelines method involves the GPMDisplay and the Buyer actor. When the
Buyer requests for the buyer guidelines, the GPMDisplay will then display this to the Buyer.

3. UCD02 : Buyer Registers Feedback about Seller

This use case enables winning buyer to leave reviews about the seller regarding their experience
throughout the whole buying process. The purpose of this use case is to trace and report those
sellers who does not deliver purchased items or do not fulfill the item descriptions at the auction.

3.1. Use Case Description

Use case name BuyerFeedbackAboutSeller

Participating actors Initiated by ​Buyer

Communicates with ​GPM

Flow of events 1. Buyer​ requests to send an ‘update seller’s feedback history’

request containing the following information to the​ GPM​:
a. Type of comment
b. The comment
2. GPM​ responds by displaying a webpage containing the
following information :
a. ‘Seller Feedback History Updated’ message
3. Buyer​ uses webpage to acknowledge the entering of the
seller​ feedback to the ​GPM

Entry condition ● GPM​ displays

○ ‘Register Seller Feedback’ message
○ The following output fields :
■ Winning buyer’s alias
■ Date and time of the comment
■ Seller’s alias
■ Sale identifier
■ Item title
○ The following input fields :
■ Type of comment
■ The comment
● Buyer​ has bought one or more items from the ​seller

Exit Condition ● GPM​ stores the ​buyer​’s feedback about the seller in the
seller’s feedback history

Quality Requirements ● N/A

3.2. Z-Specification

To specify the ‘Buyer Registers Feedback about Seller’ use case, we first identify the actors that
are involved in this case. The actors involved are the Buyers and the GPM.

This first GPM Schema states the database that stores the seller’s feedback histories. This
database is the main component in this use case. This database stores all the reviews that buyers
have left for the seller.

The Buyer actor has one parameter which is request, which is of type Request. This indicator is
used to inform GPM on which display the Buyer would like to see. The request parameter should
not be null.

The GPMDisplay method enables user to choose certain actions from the GPM main page. Only
winning buyers from the bidding are allowed to submit feedback to the sellers that they have
 purchased items from. Only if the buyer has bought an item with the seller, only then the
‘Register Seller Feedback’ will be available for the buyer. Once buyers have selected the
‘Register Seller Feedback’ they will be redirected to the feedback form.

This schema describes the feedback form that the buyer will receive in order to leave reviews for
the sellers. The form displays the buyer alias, comment date and time, seller alias, sale identifier
and item title. There will be 2 inputs section which buyers can fill in, which are ; comment type,
and the comment they wish to provide. Once the buyer has submit the form, the comments will be
stored in the seller feedback history database.

4. UCD03 : Buyer Reviews Personal History

This use case enables buyer to communicate with GPM to display a history of buyer’s personal
transactions such as bids, sealed offers, and purchases. There are two use case paths which
consists of Normal path (Bid History displayed) and Exceptional path (No Bid History). This use
case allows buyer to view all transactions history in GPM.
4.1. Use Case Description

Use case name BuyerReviewsPersonalHistory

Participating actors Initiated by​ Buyer

Communicates with ​GPM

Flow of events 1. Buyer sends request his/her bid history in GPM webpage
2. GPM responds by displaying the following information on the
browser:
● The auction status (open, closed, cancelled)
● The type of auction (regular, reserve, Dutch)
● The item number
● The current high bid
● The current high buyer
● The type of bid (single bid, automatic proxy bid)
● The bid amount
● The desired quantity
● For automatic proxy bids:
○ The bid increment
○ The maximum bid
3. If the buyer has never bid, GPM responds by displaying the
‘No Bid History’ message.

Entry condition ● Buyer is already in the webpage to request his/her bid history

Exit Condition ● Buyer can navigate to either selected sale or return to the
previous page

Quality Requirements ● The personal history page will be displayed 10 seconds after
buyer requested from GPM.

4.2. Z-Specification

Mainpage and phistory are the values for type Request given by the Buyer to indicate which
display he/she would to access on the GPM. The Display type consists of main page and
personalhistory where Buyer can request to either of these displays to be displayed.

Request = mainpage | phistory

Display = mainpage | personalhistory
Type Request is an indicator used to inform GPM on which display the Buyer would like to see.
The request parameter should not be null.

The GPMDisplay actor has only one parameter which is display. GPMDisplay is a parameter
used to display on screen based on the request by the Buyer. The GPMDisplay is the Main Page
by default.

The DisplayPersonalHistory method involves the GPMDisplay and the Buyer actor. When the
Buyer requests for the personal history, the GPMDisplay will then display this to the Buyer which
consists of previous auction and bid status.
 INDIVIDUAL (ADLA FIKRIYAH)

The use case that have been chosen for this individual assignment is the Online Shopping Diagram.

1. Use Case Diagram

Figure 2.0 : Use case diagram for Online Shopping

Figure 1.1 shows the use case diagram for online shopping. There are 4 actors which consists of
Web Customers, Customer Authentication, Identity Provider, Credit Payment Service and
Payment Methods. ​Top level use cases are View Items, Make Purchase and Client Register.
Checkout use case is ​included use case which not available by itself. The reason is because
checkout is part of making purchase.
2. Use Case Description

Use case name ViewItems

Participating Initiated by ​Web Customer

actors Communicate with ​Customer​ ​Authentication

Flow of events 1. Web Custome​r access to the websites

2. Web Customer​ may search for items listed in the catalog
3. Customer Authentication​ display the recommended Item
to the​ Web Customer
4. Web Customer​ adds items to a shopping cart or wish list

Entry condition Web Customer ​search keyword of the desired Item

Exit condition ● Web Customer ​is able to add and delete of the item in the
shopping cart or wish list
● Web Customer​ has proceed to payment to purchase

Quality ● The items will be displayed 5 seconds after Item’s keyword is

requirements entered
● Add and Delete Item will automatically updated in the shopping
cart

Figure 2.1 : Use case description for ViewItem

 3. Class Diagram

Figure 2.2 : Class diagram for ViewItem

4. Z-Specification

ItemStocks == SoldOut | InStock | NewArrival | Recommendation

Partial functions :
ItemID ItemDetails
 INDIVIDUAL (NUSRAH NAFI’AH)

The use case that have been chosen for this individual assignment is the Bank ATM UML Diagram.

1. Use Case Diagram

Figure 3.0 : Use case diagram for bank ATM

Figure 3.1 shows the use case diagram of a bank ATM. There are 3 actors that are involved which
are the user, ATM technician and also the bank. There are 4 functions that the users are able to
perform which are check balance, withdraw cash, deposit and transfer funds. Meanwhile, the
ATM technician are only able to repair or perform maintenance on the machine. All actions from
both actors require communication with the bank.
2. Use Case Description (Check balance)

Use case name CheckBalance

Participating Initiated by ​Customer

actors Communicates with ​Bank

Flow of events 1. Customer​ selects ​CheckBalance​ from the ATM menu

2. Bank​ responds by displaying account options that customer would
like to check
3. Customer​ selects desired ​Account
4. Bank​ responds by fetching data of customer ​Account ​from
database
5. Bank​ displays bank balance of ​Customer

Entry condition ● The ​Customer​ is logged into their bank ​Account

Exit condition ● Customer​ is able to access bank balance, OR

● Customer​ is notified of why the action could not be performed

Quality ● The ​Customer​’s bank balance is to be displayed within 20

requirements seconds after selecting the desired account to check

Figure 3.1 : Use case description for CheckBalance

Extend = optional || include = repetitive process that can’t stand alone

3. Class Diagram
 Figure 3.2 : Class diagram for CheckBalance

The class diagram in figure 3.2 describes the components that are involved in this use case. User
is only able to perform the ‘Check Balance’ action once the system has verified it as one of the
bank’s customers. This is done by the system by checking the match between the user’s
credentials and the credentials available in the bank database. We can see from the class diagram
that when the customer chooses to check the balance of their account, they are required to choose
what type of bank they wish to check, as one bank account has a savings account and a current
account. The system then communicates with the bank to check from the database and display the
user’s chosen bank balance.

4. Z-Specification

Basic types :​ [AccountType, AccountInfo, UserId, Status]

Status == log_in | log_out
Partial functions :
UserId AccountInfo
 INDIVIDUAL (NUR ASFIA)

The use case that will be chosen in this Z-specification is taken from the Ticket Vending Machine UML
Diagram. The chosen use case is Purchase Ticket.

1. Use Case Diagram for Ticket Vending Machine

​ Figure 4.0 : Use Case Diagram for Ticket Vending Machine

Figure 4.0 shows the use case diagram for the Ticket Vending Machine. There are two actors in
this use case, which is the commuter who buys tickets from the ticket vending machine and the
bank that the vending machine communicates with when the commuter chooses to pay with either
a credit or debit card.

2. Purchase Tickets Use Case Description

Use case name PurchaseTicket

Participating actors Initiated by ​Commuter

Communicates with ​Bank

Flow of events 1. ​Commuter​ uses the ticket vending machine and starts the
session on the vending machine
2. The vending machine responds by showing the trip info to the
Commuter
3. Commuter​ will then define a trip information, such as the
number and type of tickets
4. Based on the provided information, the vending machine will
calculate the payment and request payment options from the
Commuter​.
 5. Commuter ​provides payment info. If the user decides to :
5.1. Pay by cash, continue with Step 6
5.2. Pay by card, the vending machine will connect with
Bank​ to authorize the card payment
6. The vending machine will process the payment and dispense
the ticket to the ​Commuter
7. Commuter ​will get ticket from the vending machine
7.1. If the ​Commuter ​chooses to pay by cash during
Step 5, the vending machine will dispense change to
the ​Commuter
7.2. Commuter ​will then get change from the vending
machine
8. The vending machine will show “Thank You” to the
Commuter

Entry condition ● Not applicable

Exit Condition ● Commuter c​ licks cancels anytime during the process

● Commuter h​ as completed a transaction at the vending
machine

Quality Requirements ● The payment details will be displayed on the vending machine
within 5 seconds after it has been processed
● The vending machine will dispense the tickets within 5
seconds after payment has been completed
3. Class Diagram

Figure 4.1 : Class diagram for PurchaseTickets

Figure 4.2 shows the class diagram for PurchaseTickets where each actors that are involved is
noted down. The actors involved in the method are the Commuter who makes the purchase, the
Vending Machine where the Commuter makes the purchase and the Bank that the Vending
Machine communicates with to approve Commuter’s request to perform payment using credit or
debit card. After the Commuter has provided their trip information, the Vending Machine will use
the Trip Information to calculate the price of the ticket, and send this over to the Payment
Information. The Payment Information will then compile this information with the payment type
and inform it back to the Vending Machine.
4. Z-Specification for PurchaseTickets

In the Z-Specification for PuchaseTickets we first define the actors and objects that are involved
inside the system, this includes the Vending Machine, Commuter and Bank for the Actors and
Trip Information and Payment Information for the objects.

We also define the types of data and assumed examples to be used in this Z-Specification.

​ = ​locA |​ ​locB |​ ​locC

​Location =

TicketType ​== ​monthlypass ​| o​ newayticket |​ r​ oundticket

​ =​ cash |​ ​creditcard |​ ​debitcard

PaymentMethod =

The type Location has values locA, locB and locC to assume the possible locations that the
Commuter can access using the ticket. The type TicketType refers to the type of the ticket, which
can be either a monthly pass, a one-way ticket or a round trip ticket. The type PaymentMethod
indicates the ticket payment method which is either by cash, credit card or debit card.

The Commuter actor has several parameters which includes the inputs that it gives to the Vending
Machine. These inputs include :

● startlocation : indicates the Commuter’s departure location

● endlocation : indicates the Commuter’s destination
● nooftickets : indicates the number of tickets the Commuter is purchasing
 ● tictype : indicate the type of tickets the Commuter is purchasing
● paymethod : indicate the payment method that is used by the Commuter to pay for the
tickets

The VendingMachine actor has two parameters, the displaytext parameter which defines the text
that is displayed on the vending machine screen and the tickettext parameter which defines what
is printed on the dispensed ticket. This actor communicates with the Bank to get approval of
Commuter’s payment method when Commuter chooses to pay using a credit or debit card.

ApprovalStatus = approved | rejected

The Bank actor has one parameter that defines the approval status of the user’s payment method.
It can be either approved or rejected.
Trip Information defines the information needed to calculate the ticket price while Payment
Information defines the information needed to inform the user and complete the ticket purchase.
After all of this has been defined, we can then write the Z-Specification for the methods that are
involved in the Purchase Tickets use case.

The Calculate method calculates the price of the tickets based on the information that has been
given by the Commuter. The price is then informed to Payment Informations.
The ReturnDetails method returns the payment value and the payment method information to the
VendingMachine for it to communicate with the bank for approval and to display the payment
details to the Commuter.

PaymentStatus = paid | unpaid

The PurchaseTickets method will then use all this information to allow Commuter to purchase
tickets from the Vending Machine. After the payment has been completed, the Vending Machine
will then dispense the tickets that has been purchased by the Commuter.