1 2

Interface design
1. Graphical user interface design
ITSS SOFTWARE DEVELOPMENT
2. System/Device interface design
5. INTERFACE DESIGN

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
◆Display
• Control
• Physical size, resolution, and number of colors
supported by displays • Style, size, color, and characters displayed
◆Screen: 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
• Microsoft Excel/Powerpoint/Word/FrontPage
• Map these boundary classes to screens
• 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 12

1. Graphical user interface design

1.1. Standardizing the screen configuration
1.2. Creating screen images
1.3. Creating a screen transition diagram
1.4. Creating screen specifications

11 12

3
 13 14

Display transition diagram Four transition patterns

• Summarize the correlation of screens in the ◆1. Simple screen transition:
screen transition diagram • A conventional simple transition to an independent
• Classify the screens into the four patterns by focusing screen
on the transition pattern
• Link the screens in accordance with the classifications

View Slide Show

Edit Slide
(From Start)

13 14

15 16

Four transition patterns (2) Four transition patterns (3)

• 2. Transition to a dependent child screen: • 3. Transition to an independent child screen:
• Move to a pop-up screen • Move to a pop-up screen,
• When a child screen is displayed on the parent screen, • Parent screen and other screens can be operated while
the underlying parent screen cannot be operated the child screen is displayed.

Edit Slide Format Text

Edit Slide Replace Text

15 16

4
 17 18

Four transition patterns (4) Link the screen: Screen transition diagram
• 4. Transition to a dependent screen:
Edit Slide
• Start a dependent new screen with data
Show From Start

Selected Format Text

slide
Edit Slide Duplicate Slide View Slide Master

Selected
slide
Replace Text Duplicate Slide

Selected
slide
Show Current Slide

17 18

19 20

1. Graphical user interface design 4. Screen specification

1.1. Standardizing the screen configuration • Decide on a detailed format for a screen
1.2. Creating screen images specification
• Define field attributes based on the new screen
1.3. Creating a screen transition diagram
information identified while deciding on screen
1.4. Creating screen specifications images and the screen transition diagram

19 20

5
 21 22

Screen specification
• Screen image
Screen specification
• This is the screen image to be displayed. If screen
example
images are created in advance with the screen design
tool, attach a hardcopy.
• 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
[1]: Section 3.2.1, pp 3-54

21 22

23 24

Example: Defining the field attributes

Defining the field attributes [1]

• Decide on the field attributes of input and output

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-57

23 24

6
 25 26

Interface design 2. System/Device interface design

1. Graphical user interface design 2.1. Identify subsystem
2. System/Device interface design
2.2. Identify subsystem interfaces
2.3. Subsystem design

25 26

Subsystems and Interfaces (continued)

Subsystems and Interfaces • Subsystems :
• Realizes one or more interfaces that define its behavior • Completely encapsulate behavior
• Represent an independent capability with clear interfaces
<<interface>> (potential for reuse)
Interface Name
<<subsystem>> • Model multiple implementation variants
Subsystem Name
<<subsystem>>
Realization (Canonical form) SubsystemA
Interface Subsystem
ClassA1 ClassA2

<<subsystem>> <<Interface>> W() X()

InterfaceK
Interface Name Subsystem Name
X() <<subsystem>>
Realization (Elided form) W() SubsystemB

ClassB1 ClassB2 ClassB3

W() X() Z()

Y()

27 28

7
 29

Packages versus Subsystems

Subsystems Packages
• class ClientClass{ • Provide behavior ▪ Don’t provide behavior
• InterfaceK subsystem;
• Completely ▪ Don’t completely
encapsulate their encapsulate their
contents
contents
• m(){ ▪ May not be easily
• Are easily replaced replaced
• subsystem = new SubsystemA();
• subsystem.X(); Client Class

• subsystem.W();
• }
Package B
ClassB1
•}
ClassB2
<<subsystem>>
Subsystem A

Encapsulation is the key!

29 30

Subsystem Usage Candidate Subsystems

• Subsystems can be used to partition the system into parts • Analysis classes which may evolve into subsystems:
that can be independently: • Classes providing complex services and/or utilities
• ordered, configured, or delivered • Boundary classes (user interfaces and external system
• developed, as long as the interfaces remain unchanged interfaces)
• deployed across a set of distributed computational nodes • Existing products or external systems in the design
• changed without breaking other parts of the systems (e.g., components):
• Subsystems can also be used to: • Communication software <<subsystem>>
Subsystem A
• partition the system into units which can provide restricted • Database access support
security over key resources
• Types and data structures <<subsystem>>
• represent existing products or external systems in the Subsystem B

design (e.g. components) • Common utilities

• Application-specific products <<subsystem>>
Subsystem C
Subsystems raise the level of abstraction.

31 33

8
 35

Identifying Subsystems 2. System/Device interface design

“Superman
<<boundary>> 2.1. Identify subsystem
Class” ClassA

X()
2.2. Identify subsystem interfaces
W() 2.3. Subsystem design

<<Interface>>
<<subsystem>>
InterfaceK SubsystemA

ClassA1 ClassA2
X()
W() X() W()

34 35

Identifying Interfaces Interface Guidelines

• Purpose • Interface name
• To identify the interfaces of the subsystems based on • Reflects role in system
their responsibilities
• Interface description
• Steps
• Conveys responsibilities
• Identify a set of candidate interfaces for all
subsystems. • Operation definition
• Look for similarities between interfaces. • Name should reflect operation result
• Define interface dependencies.
• Describes what operation does, all
• Map the interfaces to subsystems. parameters and result
• Define the behavior specified by the interfaces.
• Package the interfaces.
• Interface documentation
• Package supporting info: sequence and
Stable, well-defined interfaces are key to a stable, state diagrams, test plans, etc.
resilient architecture.

36 37

9
 Example: Design Subsystems and Interfaces
Analysis Design Example: Analysis-Class-To-Design-Element Map
<<boundary>>
BillingSystem <<subsystem>> Analysis Class Design Element
Billing System

CourseCatalogSystem CourseCatalogSystem Subsystem

//submit bill()
IBillingSystem BillingSystem BillingSystem Subsystem
submitBill(forTuition : Double, forStudent : Student)
All other analysis classes map
<<boundary>> directly to design classes
CourseCatalogSystem
<<subsystem>>
Course Catalog System
//get course offerings()

ICourseCatalogSystem

getCourseOfferings(forSemester : Semester, forStudent : Student) : CourseOfferingList

initialize()

All other analysis classes map directly to design classes.

38 39

Modeling Convention: Subsystems and Example: Subsystem Context: CourseCatalogSystem

Interfaces <<control>>
RegistrationController
<<control>> Required interface
CloseRegistrationController
<<subsystem>> defined + getCurrentSchedule()
CourseCatalogSystem + deleteCurrentSchedule()
+ // is registration open?()
+ // close registration() + submitSchedule()

ICourseCatalogSystem + initialize () + saveSchedule()

0..1
+ getCourseOfferings () + getCourseOfferings()
+ setSession()
+courseCatalog 1
+ <<class>> new()
<<Interface>>
+ getStudent()
ICourseCatalogSystem
Interfaces start with an “I”
+ getCourseOfferings ( for Semester: Semester )
<<interface>> <<subsystem>>
+ initialize ()
ICourseCatalogSystem CourseCatalogSystem
CourseOfferingList
+ getCourseOfferings () + initialize ()
Provided
+ initialize () + getCourseOfferings () interface + new()
defined <<subsystem>>
+ add()

CourseCatalogSystem

+ initialize ()
+ getCourseOfferings ()

40 41

10
 43

Example: Subsystem Context: Billing System

<<control>>
2. System/Device interface design
CloseRegistrationController

+ // is registration open?()
2.1. Identify subsystem
+ // close registration()

0..1
2.2. Identify subsystem interfaces
+ Biller 1 2.3. Subsystem design
<<Interface>>
1
IBillingSystem <<entity>>
Student
+ submitBill(forStudent : Student, forTuition : double)

<<subsystem>>
BillingSystem

+ submitBill(forStudent : Student, forTuition : double)

42 43

Subsystem Guidelines Subsystem Design Steps

• Goals • Distribute subsystem behavior to subsystem elements
<<subsystem>>
• Loose coupling A

• Portability, plug-and-play compatibility • Document subsystem elements

• Insulation from change
• Independent evolution <<subsystem>>
B • Describe subsystem dependencies
• Strong Suggestions
• Do not expose details, only interfaces
• Checkpoints
• Depend only on other interfaces <<subsystem>>
C

Key is abstraction and encapsulation

44 45

11
 Subsystem Design Steps Subsystem Responsibilities
• Distribute subsystem behavior to • Subsystem responsibilities defined by interface
subsystem elements operations
• Model interface realizations
• Document subsystem elements
• Interface may be realized by
• Describe subsystem dependencies • Internal class behavior
• Checkpoints • Subsystem behavior
<<interface>>
ICourseCatalogSystem
getCourseOfferings () <<subsystem>>
Initialize () CourseCatalogSystem
getCourseOfferings ()
Initialize ()
Subsystem responsibility

46 47

Distributing Subsystem Responsibilities What Are Gates?

• Identify new, or reuse existing, design elements (for • A connection point in
example, classes and/or subsystems) an interaction for a sd example

• Allocate subsystem responsibilities to design elements message that comes : ClassName

• Incorporate applicable mechanisms (for example, into or goes outside
persistence, distribution) the interaction. Input gate
• Document design element collaborations in “interface
realizations” • A point on the
• One or more interaction diagrams per interface boundary of the
operation sequence diagram Output gate
• Class diagram(s) containing the required design • The name of the
element relationships connected message
• Revisit “Identify Design Elements” is the name of the
• Adjust subsystem boundaries and dependencies, gate
as needed

48 49

12
 Subsystem Interaction Diagrams Internal Structure of Supplier Subsystem
: Client Subsystem : Supplier Subsystem • Subsystem Manager
performResponsibility( )
coordinates the internal Supplier Subsystem

Internal
subsystem behavior of the
: Subsystem Manager
interactions
subsystem.
Subsystem
responsibility
: Design : Design
• The complete subsystem Element1 Element2

behavior is distributed
amongst the internal
Design Element classes.
Black box view of subsystems

50 51

Modeling Convention: Internal Subsystem Example: Billing System Subsystem In Context

subsystem interface
Interaction : Registrar
: CloseRegistration : CloseRegistration : ICourseCatalog : Course : Schedule : Student. : Ibilling
sd PerformResponsibility Form Controller System Offering System

1. // close registration( )
: Subsystem : Design : Design 1.1. // is registration open?( ) Retrieve a list of course
offerings for the current
Manager Element1 Element2 semester
2. // close registration( )
performResponsibility( ) Close
2.1. getCourseOfferings(Semester) registration for
doThis( ) 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
doThat( ) realistically, an alternate course offerings).
indefinite number
of iterations could
occur) 2.3. // level( )
thisAgain( )
Finally commit or
2.4. // close( ) Currently assuming tuition based on
cancel the course
offering once all number of offerings taken and certain
thatAgain( ) leveling has occurred attributes of students. If different offerings
get different prices this will change slightly.
2.5. getTuition( )
Send student and tuition to
the Billing System, which will
do the actual billing to the 2.6. submitBill(Student, double)
student for the schedule.

subsystem responsibility
White box view of Supplier Subsystem
52 53

13
Example: Local BillingSystem Subsystem Interaction
Subsystem Design Steps
Subsystem
Billing System
Client
: BillingSystem : StudentBillingTransaction : Student :BillingSystemInterface : Billing System • Distribute subsystem behavior to
1. submitBill(Student, double) subsystem elements
Retrieve the

1.1. create(Student, double)

information that must
be included on the bill • Document subsystem elements
1.1.1. // get contact info( )
• Describe subsystem dependencies
1.2. submit(StudentBillingTransaction)
• Checkpoints
1.2.1. // open connection( )

1.2.2. // process transaction( )

1.2.3. // close connection( )

54 55

Example: Billing System Subsystem

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

create(forStudent : Student, forAmount : double)

• Document subsystem elements
Subsystem Interface
• Describe subsystem dependencies
<<Entity>>
<<subsystem>>
BillingSystem
Student
(from University Artifacts)
• Checkpoints
submitBill(forStudent : Student, forTuition : double)
// get contact info()
1

Subsystem
0..1
Component
BillingSystemInterface

submit(theTransaction : StudentBillingTransaction)

56 57

14
 Example: BillingSystem Subsystem
Subsystem Dependencies: Guidelines
Dependencies
• Subsystem dependency on a subsystem

Flexible, <<subsystem>>
<<subsystem>> <<subsystem>> BillingSystem
Client Support Server Support
Preferred (from Business Services)
Server

• Subsystem dependency on a package

External System University Artifacts

Supporting Interfaces
Use with care (from Business Services) (from Business Services)
<<subsystem>>
Types
Client Support

58 59

Subsystem Design Steps Checkpoints: Design Subsystems

• Is a realization association defined for each
• Distribute subsystem behavior to
interface offered by the subsystem?
subsystem elements • Is a dependency association defined for each
• Document subsystem elements interface used by the subsystem?
• Are you sure that none of the elements within
• Describe subsystem dependencies the subsystem have public visibility?
• Checkpoints • Is each operation on an interface realized by
the subsystem documented in a interaction
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?

60 61

15
 63

Review: Subsystem Design Question?

• What is the purpose of
Subsystem Design?
• What are gates?
• Why should dependencies
on a subsystem be on the
subsystem interface?

62 63

16