1 2

Interface design
1. Graphical user interface design
ITSS SOFTWARE DEVELOPMENT/SOFTWARE DESIGN AND CONSTRUCTION
2. System/Device interface design
5. INTERFACE DESIGN
Nguyen Thi Thu Trang
[email protected]

1 2

3 4

References 1. Graphical user interface design

[1] Textbook for Software Design & Development 1.1. Standardizing the screen configuration
Engineers, No. 3 – System Development, Operations
and Maintenance, 2nd Edition; Japan Information 1.2. Creating screen images
Processing Development Corporation, Japan 1.3. Creating a screen transition diagram
Information-Technology Engineers Examination Center.
1.4. Creating screen specifications

3 4

1
 5 6

Standardizing Standardizing
uDisplay
• Control
• Physical size, resolution, and number of colors
supported by displays • Style, size, color, and characters displayed
uScreen: divided into displayed objects called • Input check process
windows (Window) • Sequence of moving the focus (e.g., defining the tab
• Location of standard buttons (e.g., OK, Cancel, sequence)
Register, Search) • Menu
• Display location of messages, etc. • Design menus with consideration of the standard
• Display of screen title and menus specification (common client area) of the screen
• Consistency in expression of alphanumeric characters
• Direct input from a keyboard
• Expression of sentences and detailed items
• Maintain consistency in the assignment of shortcut keys
• Color coordination

5 6

7 8

Standardizing 1. Graphical user interface design

• Messages 1.1. Standardizing the screen configuration
• Determine how messages are displayed when a time- 1.2. Creating screen images
consuming process is executed (busy).
• Error
1.3. Creating a screen transition diagram
• Execute standardized processing if an error occurs 1.4. Creating screen specifications
• Help
• Develop detailed Help information in accordance with
the manual, and maintain consistency in terminology,
descriptions, and explanations of methods.

7 8

2
 9 10

From use case GUI Design tools

• Based on use case and boundary classes which • Simple tools
interact with users • Notepad
• Map these boundary classes to screens • Microsoft Excel/Powerpoint/Word/FrontPage

• Based on input/output description in use case • Professional tools

specification/scenario • Free
• InVision
• IDEs: Eclipse, NetBean
=> Design screen using tools • Commercial
• Adobe Dreamweaver
• Axure RP
• Photoshop
• IDEs: Visual Studio

9 10

11

SKETCH, WIREFRAME, MOCKUP, PROTOTYPE

Example of wireframe
• Freehand drawings
Sketch • On paper or digital tool
• Very fast to represent concepts
• Wireframe:
üMostly black and white UI
Wireflow elements
üSkeleton for UI design: outline and
structure
• Userflow: Simulate steps
• Fast to represent concepts
• Detail design for UI
Mockup • Mocked data
• Color, logo, icon, image, style

12
• Working model with UX
Prototype • Simulate user interaction
• User journey, usability

11 12

3
 13 14

1. Graphical user interface design Display transition diagram

1.1. Standardizing the screen configuration • Summarize the correlation of screens in the
1.2. Creating screen images screen transition diagram
• Classify the screens into the four patterns by focusing
1.3. Creating a screen transition diagram on the transition pattern
1.4. Creating screen specifications • Link the screens in accordance with the classifications

13 14

15 16

Four transition patterns Four transition patterns (2)

u1. Simple screen transition: • 2. Transition to a dependent child screen:
• A conventional simple transition to an independent • Move to a pop-up screen
screen • When a child screen is displayed on the parent screen,
the underlying parent screen cannot be operated

View Slide Show

Edit Slide
(From Start)
Edit Slide Format Text

15 16

4
 17 18

Four transition patterns (3) Four transition patterns (4)

• 3. Transition to an independent child screen: • 4. Transition to a dependent screen:
• Move to a pop-up screen, • Start a dependent new screen with data
• Parent screen and other screens can be operated while
the child screen is displayed.
Selected
slide
Edit Slide Duplicate Slide

Edit Slide Replace Text

17 18

19 20

Link the screen: Screen transition diagram 1. Graphical user interface design
1.1. Standardizing the screen configuration
Edit Slide
1.2. Creating screen images
Show From Start
1.3. Creating a screen transition diagram
Format Text 1.4. Creating screen specifications
View Slide Master

Selected
slide
Replace Text Duplicate Slide

Selected
slide
Show Current Slide

19 20

5
 21 22

4. Screen specification Screen specification

• Decide on a detailed format for a screen • Screen image
specification • This is the screen image to be displayed. If screen
• Define field attributes based on the new screen images are created in advance with the screen design
tool, attach a hardcopy.
information identified while deciding on screen
images and the screen transition diagram • List of functions
• Defines the names of parts such as the buttons on the
screen, and summarizes their functions.
• Provide descriptions of events for individual screens,
attributes of parts, input check specifications and output
specifications, etc.
• Defining the field attributes

21 22

23 24

Defining the field attributes

Screen specification • Decide on the field attributes of input and output
example items
• Summarize them in descriptions of items for
screen display.
• The screen consists of multiple fields.
• Each field consists of a one-byte (equivalent to a
single character) attribute at the beginning and a
variable item

[1]: Section 3.2.1, pp 3-54

23 24

6
 25 26

Example: Defining the field attributes

[1]
Interface design
1. Graphical user interface design
2. System/Device interface design

[1]: Section 3.2.1, pp 3-57

25 26

27

2. System/Device interface design Subsystems and Interfaces

2.1. Identify subsystem • Realizes one or more interfaces that define its behavior

2.2. Identify subsystem interfaces <<interface>>

Interface Name
2.3. Subsystem design <<subsystem>>
Subsystem Name

Realization (Canonical form)

Interface Subsystem

<<subsystem>>
Subsystem Name
Interface Name
Realization (Elided form)

27 28

7
 30

Subsystems and Interfaces (continued)

• Subsystems :
• Completely encapsulate behavior • class ClientClass{
• Represent an independent capability with clear interfaces • InterfaceK subsystem;
(potential for reuse)
• Model multiple implementation variants
• m(){
<<subsystem>>
SubsystemA • subsystem = new SubsystemA();
• subsystem.X();
ClassA1 ClassA2
• subsystem.W();
<<Interface>> W() X() • }
InterfaceK

X() <<subsystem>>
W() SubsystemB •}
ClassB1 ClassB2 ClassB3

W() X() Z()

Y()

29 30

Packages versus Subsystems

Subsystem Usage
Subsystems Packages
• Provide behavior § Don’t provide behavior • Subsystems can be used to partition the system into parts
• Completely § Don’t completely that can be independently:
encapsulate their encapsulate their • ordered, configured, or delivered
contents • developed, as long as the interfaces remain unchanged
contents
§ May not be easily • deployed across a set of distributed computational nodes
• Are easily replaced replaced
• changed without breaking other parts of the systems
Client Class
• Subsystems can also be used to:
• partition the system into units which can provide restricted
Package B security over key resources
ClassB1 • represent existing products or external systems in the
ClassB2 design (e.g. components)
<<subsystem>>
Subsystem A
Subsystems raise the level of abstraction.
Encapsulation is the key!
31 32

8
 Candidate Subsystems Identifying Subsystems
• Analysis classes which may evolve into subsystems: “Superman
<<boundary>>
Class” ClassA
• Classes providing complex services and/or utilities
• Boundary classes (user interfaces and external system X()
W()
interfaces)
• Existing products or external systems in the design
(e.g., components):
• Communication software <<subsystem>>
Subsystem A
• Database access support <<Interface>>
<<subsystem>>
InterfaceK SubsystemA
• Types and data structures <<subsystem>>
Subsystem B
• Common utilities ClassA1 ClassA2
X()
• Application-specific products <<subsystem>>
W() X() W()
Subsystem C

34 35

36

2. System/Device interface design Identifying Interfaces

2.1. Identify subsystem • Purpose
• To identify the interfaces of the subsystems based on
2.2. Identify subsystem interfaces their responsibilities
• Steps
2.3. Subsystem design • Identify a set of candidate interfaces for all
subsystems.
• Look for similarities between interfaces.
• Define interface dependencies.
• Map the interfaces to subsystems.
• Define the behavior specified by the interfaces.
• Package the interfaces.

Stable, well-defined interfaces are key to a stable,

resilient architecture.

36 37

9
 Example: Design Subsystems and Interfaces
Interface Guidelines Analysis Design
• Interface name <<boundary>>
BillingSystem <<subsystem>>
• Reflects role in system Billing System

• Interface description //submit bill()

• Conveys responsibilities IBillingSystem

• Operation definition submitBill(forTuition : Double, forStudent : Student)

• Name should reflect operation result <<boundary>>

CourseCatalogSystem
• Describes what operation does, all <<subsystem>>
Course Catalog System
parameters and result
//get course offerings()
• Interface documentation
ICourseCatalogSystem
• Package supporting info: sequence and
getCourseOfferings(forSemester : Semester, forStudent : Student) : CourseOfferingList
state diagrams, test plans, etc. initialize()

All other analysis classes map directly to design classes.

38 39

Modeling Convention: Subsystems and

Example: Analysis-Class-To-Design-Element Map
Interfaces
Analysis Class Design Element <<subsystem>>
CourseCatalogSystem
CourseCatalogSystem CourseCatalogSystem Subsystem
ICourseCatalogSystem + initialize ()
+ getCourseOfferings ()
BillingSystem BillingSystem Subsystem
All other analysis classes map
directly to design classes
Interfaces start with an “I”
<<interface>> <<subsystem>>
ICourseCatalogSystem CourseCatalogSystem

+ getCourseOfferings () + initialize ()
+ initialize () + getCourseOfferings ()

40 41

10
 Example: Subsystem Context: CourseCatalogSystem Example: Subsystem Context: Billing System
<<control>>
<<control>>
RegistrationController
<<control>> Required interface CloseRegistrationController
CloseRegistrationController
defined + getCurrentSchedule() + // is registration open?()
+ // is registration open?() + deleteCurrentSchedule() + // close registration()
+ // close registration() + submitSchedule()
+ saveSchedule() 0..1
0..1 + getCourseOfferings()
+ setSession() + Biller 1
+courseCatalog 1
+ <<class>> new() <<Interface>>
1
<<Interface>> + getStudent() <<entity>>
IBillingSystem
ICourseCatalogSystem
Student
+ submitBill(forStudent : Student, forTuition : double)
+ getCourseOfferings ( for Semester: Semester )
+ initialize ()

CourseOfferingList
Provided
interface + new()
<<subsystem>>
defined <<subsystem>>
+ add()
BillingSystem
CourseCatalogSystem

+ submitBill(forStudent : Student, forTuition : double)

+ initialize ()
+ getCourseOfferings ()

42 43

44

2. System/Device interface design Subsystem Guidelines

2.1. Identify subsystem • Goals <<subsystem>>
2.2. Identify subsystem interfaces • Loose coupling A

2.3. Subsystem design • Portability, plug-and-play compatibility

• Insulation from change
• Independent evolution <<subsystem>>
B
• Strong Suggestions
• Donot expose details, only interfaces
• Depend only on other interfaces <<subsystem>>
C

Key is abstraction and encapsulation

44 45

11
 Subsystem Design Steps Subsystem Design Steps
• Distribute subsystem behavior to subsystem elements • Distribute subsystem behavior to
subsystem elements
• Document subsystem elements • Document subsystem elements
• Describe subsystem dependencies
• Describe subsystem dependencies • Checkpoints

• Checkpoints

46 47

Subsystem Responsibilities Distributing Subsystem Responsibilities

• Identify new, or reuse existing, design elements (for
• Subsystem responsibilities defined by interface example, classes and/or subsystems)
operations • Allocate subsystem responsibilities to design elements
• Model interface realizations • Incorporate applicable mechanisms (for example,
persistence, distribution)
• Interface may be realized by • Document design element collaborations in “interface
• Internal class behavior
realizations”
• One or more interaction diagrams per interface
• Subsystem behavior operation
<<interface>> • Class diagram(s) containing the required design
ICourseCatalogSystem element relationships
<<subsystem>> • Revisit “Identify Design Elements”
getCourseOfferings ()
Initialize () CourseCatalogSystem • Adjust subsystem boundaries and dependencies,
getCourseOfferings () as needed
Initialize ()
Subsystem responsibility

48 49

12
 What Are Gates? Subsystem Interaction Diagrams
• A connection point in : Client Subsystem : Supplier Subsystem

an interaction for a sd example

message that comes : ClassName

performResponsibility( )
Internal
into or goes outside subsystem
the interaction. Input gate
interactions

• A point on the Subsystem

boundary of the responsibility
sequence diagram Output gate
• The name of the
connected message
is the name of the
gate

Black box view of subsystems

50 51

Internal Structure of Supplier Subsystem Modeling Convention: Internal Subsystem

Interaction
• Subsystem Manager sd PerformResponsibility

coordinates the internal Supplier Subsystem

: Subsystem : Design : Design
behavior of the Manager Element1 Element2

: Subsystem Manager performResponsibility( )

subsystem. doThis( )

doThat( )
: Design : Design
• The complete subsystem Element1 Element2
thisAgain( )

behavior is distributed
amongst the internal thatAgain( )

Design Element classes.

White box view of Supplier Subsystem

52 53

13
 Example: Billing System Subsystem In Context Example: Local BillingSystem Subsystem Interaction
subsystem interface
: Registrar
: CloseRegistration : CloseRegistration : ICourseCatalog : Course : Schedule : Student. : Ibilling Subsystem
Form Controller System Offering System
Billing System : BillingSystem : StudentBillingTransaction : Student :BillingSystemInterface : Billing System
1. // close registration( ) Client
1.1. // is registration open?( ) Retrieve a list of course
offerings for the current 1. submitBill(Student, double)
semester
2. // close registration( ) Retrieve the
Close information that must
2.1. getCourseOfferings(Semester) registration for 1.1. create(Student, double) be included on the bill
each course
offering If the maximum number of
Repeat twice this selected primary courses have
is for simplicity; 2.2. // close registration( )
not been committed, select
1.1.1. // get contact info( )
realistically, an alternate course offerings).
indefinite number
of iterations could
occur) 2.3. // level( )
1.2. submit(StudentBillingTransaction)

Finally commit or 1.2.1. // open connection( )

2.4. // close( ) Currently assuming tuition based on
cancel the course
offering once all number of offerings taken and certain
leveling has occurred attributes of students. If different offerings 1.2.2. // process transaction( )
get different prices this will change slightly.
2.5. getTuition( )
Send student and tuition to 1.2.3. // close connection( )
the Billing System, which will
do the actual billing to the 2.6. submitBill(Student, double)
student for the schedule.

subsystem responsibility

54 55

Example: Billing System Subsystem

Subsystem Design Steps Elements
• Distribute subsystem behavior to <<Interface>>
IBillingSystem
subsystem elements (from External System Interfaces)

submitBill() StudentBillingTransaction
• Document subsystem elements create(forStudent : Student, forAmount : double)
Subsystem Interface
• Describe subsystem dependencies
<<Entity>>
• Checkpoints <<subsystem>>
BillingSystem Student
(from University Artifacts)

submitBill(forStudent : Student, forTuition : double) // get contact info()

1

Subsystem
0..1
Component
BillingSystemInterface

submit(theTransaction : StudentBillingTransaction)

56 57

14
 Subsystem Design Steps Subsystem Dependencies: Guidelines
• Distribute subsystem behavior to • Subsystem dependency on a subsystem

subsystem elements Flexible,

<<subsystem>> <<subsystem>>
Preferred
• Document subsystem elements Client Support
Server
Server Support

• Describe subsystem dependencies • Subsystem dependency on a package

• Checkpoints

Supporting
<<subsystem>>
Types
Use with care
Client Support

58 59

Example: BillingSystem Subsystem

Dependencies Subsystem Design Steps
• Distribute subsystem behavior to
<<subsystem>> subsystem elements
BillingSystem
(from Business Services)
• Document subsystem elements
• Describe subsystem dependencies
• Checkpoints
External System University Artifacts
Interfaces
(from Business Services) (from Business Services)

60 61

15
 Checkpoints: Design Subsystems Review: Subsystem Design
• Is a realization association defined for each
• What is the purpose of
interface offered by the subsystem?
• Is a dependency association defined for each
Subsystem Design?
interface used by the subsystem? • What are gates?
• Are you sure that none of the elements within
the subsystem have public visibility? • Why should dependencies
• Is each operation on an interface realized by on a subsystem be on the
the subsystem documented in a interaction subsystem interface?
diagram? If not, is the operation realized by a
single class, so that it is easy to see that there
is a simple 1:1 mapping between the class
operation and the interface operation?

62 63

64

Question?

64

16