1
SOFTWARE DESIGN AND CONSTRUCTION
Assignment 02-Interface Design
Lecturer: NGUYEN Thi Thu Trang,
[email protected]1. SUBMISSION GUIDELINE
When you want to submit your individual work of in-class tasks for the Case Study,
you have to push your work to your individual GitHub repository, complied with
the naming convention “TeamName-StudentID.StudentName” (e.g.
TKXDPM.KHMT.20231.20192012.HoangNghiaPhu or TKXDPM.VP.20231-
20192122.LuongHongHai).
2. IN-CLASS ASSIGNMENT
In this section, we will get familiar with the software detailed design process and
start with interface design for the Case Study.
You are asked to work individually for this section, and then put all your file(s) and
directories to a directory, namely “DetailedDesign/InterfaceDesign”. After that,
push your commit to your individual repository before the announced deadline.
2.1. USER INTERFACE DESIGN
Boundary classes are used to model the interaction between a system and its
surroundings, i.e., its actors. Hence, they can be utilized to capture the
requirements on a user interface. The interactions between people and systems
might be through various kinds of user interfaces (UI) such as batch interface,
command-line interface (CLI), and graphical user interface (GUI).
In this subsection, we use GUI to illustrate how to design UIs step by step.
2.1.1. Standardizing the screen configuration
Display
Number of colors supported: 16,777,216 colors
Resolution: 1366 × 768 𝑝𝑖𝑥𝑒𝑙𝑠
HANDS-ON LAB GUIDELINES
© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
2
Screen
Location of standard buttons: At the bottom (vertically) and in the middle
(horizontally) of the frame
Location of the messages: Starting from the top vertically and in the middle
horizontally of the frame down to the bottom.
Display of the screen title: The title is located at the top of the frame in the middle.
Consistency in expression of alphanumeric numbers: comma for separator of
thousand while strings only consist of characters, digits, commas, dots, spaces,
underscores, and hyphen symbol.
Control
Size of the text: medium size (mostly 24px). Font: Segoe UI. Color: #000000
Input check process: Should check if it is empty or not. Next, check if the input is in
the correct format or not
Sequence of moving the focus: There will be no stack frames. Each screen will be
separated. However, the manual is considered a popup message, as the main
screen cannot be operated while the manual screen is shown. After the opening
screen, the app will start with splash screen, and then the first screen (home
screen) will appear.
Sequences of the system screens:
1. Splash screen (first screen)
2. Home screen
3. View cart screen – view items in the cart
4. Delivery form – fill delivery information
5. Invoice screen – view order details
6. Payment form – fill payment information
7. Result screen
Direct input from the keyboard
There will be no shortcuts. There are back buttons to move back to the previous
screen. Also, there is the close button “X” located at the title bar to the right to close
the screen.
HANDS-ON LAB GUIDELINES
© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
3
Error
A message will be given to notify the users what is the problem.
2.1.2. Creating screen images
Creating screen images or mockup designs can be done by using applications such
as https://moqups.com/, http://draw.io/, Figma, InVision Studio, Paint, Adobe
Graphic design software, Adobe XD, or Scene Builder.
The following figures are made with Scene Builder.
HANDS-ON LAB GUIDELINES
© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
4
HANDS-ON LAB GUIDELINES
© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
5
HANDS-ON LAB GUIDELINES
© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
6
2.1.3. Creating a screen transition diagram
Creating screen transition diagram can be done by using draw.io or any drawing
applications as specified in the previous section. In case you choose to use Moqups,
you need to use the UML Class Diagram template of Moqups.
HANDS-ON LAB GUIDELINES
© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
7
To illustrate, an example of the screen transition diagram for AIMS Software, made
with http://draw.io/, is shown as follows.
2.1.4. Creating screen specification
Screen specification
AIMS Software Date of creation Approved Reviewed Persion in charge
by by
Screen specification View cart screen 30/10/2020 Đỗ Minh Hiếu
Control Operation Function
Area for Initial Display the subtotal
displaying the
subtotal
Area for display Initial Display the media with the
items in the cart corresponding information
Place order Click Display the Delivery form
button
Delete button Click Remove the item from the cart
HANDS-ON LAB GUIDELINES
© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
8
Defining the field attributes
Screen name View cart
Item name Number of Type Field attribute Remarks
digits (bytes)
Media title 50 Numeral Blue Left-justified
Price 20 Numeral Blue Right justified
Subtotal 20 Numeral Blue Left-justified
You are asked to design GUIs step by step for UC “Place Rush Order.”
2.2. SYSTEM INTERFACE DESIGN
2.2.1. Identify subsystems
As can be seen, the InterbankBoundary class in the analysis class diagram provides
complex services related to the communication between AIMS Software and the
Interbank while representing an independent capability with clear interface.
Hence, we evolve the Interbank Boundary from an analysis class into a subsystem.
2.2.2. Identify subsystem interface
Based on the responsibilities of a payment system, we can identify the interface for
our subsystem as follows.
HANDS-ON LAB GUIDELINES
© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
9
2.2.3. Subsystem design
Distribute subsystem behavior to subsystem elements
HANDS-ON LAB GUIDELINES
© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
10
HANDS-ON LAB GUIDELINES
© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
11
Document subsystem elements
Describe subsystem dependencies
HANDS-ON LAB GUIDELINES
© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
12
Checkpoints
HANDS-ON LAB GUIDELINES
© SOICT – HUST
ITSS SOFTWARE DEVELOPMENT – IT4945E
