h.washizaki and y.fukazawa, tools pacific 2002, february 20, sydney, australia1 dynamic hierarchical...

H.Washizaki and Y.Fukazawa, TOOLS Pacific 2002, February 20, Sydney, Australia 1

Dynamic Hierarchical Undo Facility in

a Fine-Grained Component EnvironmentTOOLS Pacific 2002

　Waseda University, JAPAN

H.Washizaki Y.Fukazawa { washi, fukazawa }@fuka.info.waseda.ac.jp


Undo facility Definition of undo/redo operations

U ndo: U nex ec ute the last performed ac tionRedo: Re-execute the last undo ac tion(U ndo/redo several ac tions)

Effects of undo facilityImprov ement of usabili tySupport of complex G U I des ign

Undo facility is necessary for interactive application systems with Graphical User Interfaces (GUIs)


Conventional implementation Basic mechanism

Command: corresponding to user’s actions History list: storing executed commands

Types of undo facilities Restricted linear undo facility

Undo/redo operation in the order of user’s actions Most comprehensible for users

Non-linear undo facility Arbitrary past commands can be undone/redone Problem: internal states become complex for users

Selective undo facility Isolated commands can be undone/redone Problem: dependency settings is necessary

Hierarchica l undo facility Using predefined hierarchical commands Problem: definition of hierarchical commands is necessary corresponding to each specific application


Conventional implementation (Restricted linear undo facility)

Restricted linear undo facility is the most general Comprehensible for users

Object-oriented undo frameworks (UndoFW) Command Processor pattern Restoration target: user’s actions

FooEditSource

UndoManager

UndoableEditListener

UndoableEdit

ConcreteUndoableEdit

undo()redo()

*Stores/Undo/Redo

1

UndoableEditSupportGenerates

Executes/Re-executes

Notifies-user-action-performed

component.setData(v1)


undo()redo()

Passes-UndoableEdit

Command

SupplierConcreteCommandController

Command Processor (History List)

Command Processor


Problems in conventional implementation

Potential for an excessive number of command classes Necessity of command classes according to each user’s actions Example:

CopyCommand, PasteCommand, DeleteCommand, … (for text editing applications) Internal modification of the edit source class

Addition of procedures in the edit source class (in the original logic part) Incomplete separation of the original logic part and the UndoFW applied part


ComponentInterface

Coordination services

Component Framework

glue code

Targeted software components Common definition

Reusable/substitutable software artifacts In a narrow sense

A physical packaging of executable software with public interfaces An object-oriented class, reusable at the instance level

Distributed in the form of an object code, without source codes Systems: CORBA・EJB, JavaBeans・ActiveX/COM

Classification with granularity Coarse-grained: business components Medium-grained: application components with specific logic Fine-grained: GUI widgets, generic components


Fine-grained components Usage

Widespread with RAD tools, libraries JavaBeans, ActiveX, …

Feature Property (data)

Attribute by which component's behavior is decided

Readabl-property, writable-property Read method (getData)

Operation to observe the property’s value

Write method (setData) Operation to change the property’s val

ue Event method (fireEvent)

Operation for notification of events Starting point of the reactive control

-data : Data

#fireEvent(event: Event)+getData(newData: Data)+setData(newData: Data)

+doSomething(p:Param)

Facade

Facade

Sub system

FooBean


Additional implementation of undo facility

Target Type: restricted linear undo facility Environment: Fine-grained component environment

The behavior of the entire application is shown as sets of properties’ changes Restoration: all properties’ changes

Mechanism Undo function

resetting the old property’s value using the write method Redo function

resetting the new property’s value using the write method

Old State New StatesetData

redo

undo

setData(v2)

setData(v1)

data = v2

data = v1


Undoable extension Mechanism

Automatic generation of the subclass by Generator Separation of the logic part and the UndoFW applied part Overriding of methods with notification functions

Restricted restoration types PropertyChangeEdit: undo/redo setting property’s value PropertReferEdit: (getting property’s value) EventEdit: (firing events)

Component

UndoableComponent

- data : Data+setData(Data)+getData() : Data+fireEvent

UndoManager

UndoableEditListener

UndoableEdit

PropertyChangeEdit

undo()redo()

*Stores/Undo/Redo

1

UndoableEditSupportGenerates

Executes/Re-executes

PropertyReferEdit

EventEdit

Notifies-user-action-performed



undo()redo()

Passes-UndoableEdit


Comparison of command granularity

Conventional undo facility One command represents one action

TextField [C1]

TextField [C2]

Button [C3]

Copy action1: User push the Button[C3] 1-1: getting value on TextField[C1]1-3: setting value of TextField[C2]

Application composition

History list (conventaional)

represents text copy action(Ea) TextCopyEdit

(F1) FireEventEdit

History list (our)

(P2) PropertyReferEdit(P3) PropertyChangeEdit

reperesents event notification

Represents gettiing value

represents setting value

Our undo facility One or more commands represents one action

Proposal of dynamic hierarchization Organizing commands dynamically into a hierarchy Three types: Basic, Pattern, Container


Preparation for definition

v n {(k,i)} ::= ( v : hierarchical level on the history tree, Level,

n : sequence number, (k,j) : pair of the generator C_id and the generator I_id )

Component’s ID ::= (Unique identification value of component, C_id ）Method’s ID ::= （ Unique identification value of method in component, I_id ）

Component Xdata : DatasetData(Data)getData() : DatafireEvent()

I_id=1, generation of Pc(1,1) at the invocation time

C_id=1

E ::= （ Single command ） , E ::= Pc | Pr | E | SPc ::= (Property change command)Pr ::= (Property refer command)E ::= (Event command)S ::= { E } (compound command)

E

Component

Command

I_id=2, generation of Pr(1,2) at the invocation time

I_id=3, generation of E(1,3) at the invocation time


Basic hierarchization Policy

Use of the reactive control (event-driven) Making compound commands

event commands as their parents

C3:Button

C1:TextField

C2:TextField

1.1: fires event

:User

1: Push

1.3: reads property value

1.4: writes property value

adapter

1.2: notifies event

Realization of undo/redo operations correspondingto the event-driven behavior

2: Push

2.1: notifies event

C5:Button

Demand

Undo/redo the firing event (1.1)～ the writing property value (1.4)collectively


Basic hierarchization (mechanism)

E1(3,3)

Pr2(1,1)

E 4(5,3)

Pr5(4,2)

Pc3(2,6)

E 6(6,0)

History list

[time]

E1 1(3,3)

Pr2 2(1,1)

E1 4(5,3)

Pr2 5 (4,2)

Pc2 3 (2,6)

E1 6(6,0)

Basic-hierarchizedHistory tree

Basichierarchization

objective-state

current-state

[time]

S1 (3,3)(1,1)(2,6)

S2 (5,3)(4,2)

S3 (6,0)

Basic-hierarchizedHistory list (Level=1)

Undo

Undo

objective-state

current-state

Undo

Undo

Undo

Undo

Adding property change/refer commands (Pc,Pr) as children of event commands (E)

root


Pattern hierarchization Policy

The same kind of compound commands series as a pattern Making compound commands

New command as their commands

Realization of undo/redo operations for the repeated series of actions

C3:Button

C1:TextField

C2:TextField

1.1:

:User

1: Push

1.3:

1.4:

adapter

1.2:

2: Push

2.1:

C5:Button

3: Push

4: Push

5: Push

4.1:

4.2:

4.3:

4.4:

3.1: 5.1:

Demand

Undo/redo the repeated series of actions (push C3 ～ push C5)collectively


Pattern hierarchization (mechanism)

S1 1(3,3)(1,1)(2,6)

S1 2(5,3)(4,2)

S1 4(3,3)(1,1)(2,6)

S1 3(6,0)(4,2)

S1 5(5,3)(4,2)

Addition

S’1 8 (6,0)(4,2)

Addition

S’1 1

S’2 2 (3,3)(1,1)(2,6)

S’1 4 (6,0)(4,2)

S’2 3 (5,3)(4,2)

S’1 5

S’2 6 (3,3)(1,1)(2,6)

S’2 7 (5,3)(4,2)

S’’2 2

S’’3 3 (3,3)(1,1)(2,6)

S’’2 5 (6,0)(4,2)

S’’3 4 (5,3)(4,2)

S’’2 7

S’’3 8 (3,3)(1,1)(2,6)

E’’3 9 (5,3)(4,2)

S’’1 1

S’’1 6

S’’2 10 (6,0)(4,2)

S’’’1

(3,3)(1,1)(2,6) (5,3)(4,2)(6,0) (4,2)

S’’’2

(3,3)(1,1)(2,6) (5,3)(4,2)(6,0) (4,2)

Pattern hierarchizedHistory list (Level=1)

Undo

objective-state

Undo

Decision of commands equivalence with pairs of C_id ant I_id Retrieval of same set of id pairs

root root rootHistory tree

PatternHierarchi-zation(A)

Patternhierarchization(B)


Container hierarchization Policy

Inclusive relation of parent components of generator components Effects of commands are localized inside those parent component

Panel

Realization of undo/redo operations corresponding to components composition

TextField

MainPanel

CopyPanelButton

CheckGroupButton

Button TextField

Cz

C6 Cx

C3 C2 C1 Cy

C5 C4

Inclusive relations: Cz ⊃ C6, Cx Cx ⊃ C1, C2, C3, Cy Cy ⊃ C4, C5

Demand

Undo/redo the repeated series of actions localized in Cx ・ Cy ・ Cz


Container hierarchization (mechanism)

S1 2(5,3)(4,2)

S1 4(3,3)(1,1)(2,6)

S1 5(5,3)(4,2)

S1 3(6,0)(4,2)

S1 6(6,0)(4,2)

S1 1(3,3)(1,1)(2,6)

con(E1)=x

con(E2)=y

con(E3)=z

History list

S1 1(3,3)(1,1)(2,6)

S2 2(5,3)(4,2)

S1 3(6,0)(4,2)

S2 4(3,3)(1,1)(2,6)

S3 5(5,3)(4,2)

S1 6(6,0)(4,2)

in(con(S1),con(S2)) = (Cx⊃Cy) = TRUE

[time]

S’1 (3,3)(1,1)(2,6) (5,3)(4,2)

S’2

(6,0)(4,2)(3,3) (1,1)(2,6)(5,3) (4,2)

S’3 (6,0)(4,2)

Container hierarchizedHistory list (Level=1)

Undo

Undo

current-state

Undo

objective-state

in(C_id1,C_id2) ::= TRUE | FALSE (C_id1 contains C_id2)

con(E) ::= C_container ( ∀C_id | in(C_container, C_id), C_id ∈( E’s { (C_id,I_id) } )

Decision of the parent component which includes all parent components of generator components Using component ids Checking the component composition at each time

root root

Containerhierarchi-zation


Implementation environment Component system

JavaBeans: Java based component system Treats fine-grained components

Undo framework javax.swing.undo package (in JFC)

Undo extension and hierarchization system UndoableBean

<<framework>>UndoFW

<<framework>>UndoableBean

JavaBeans

Our development


Hierarchization framework Three types of dynamic hierarchization

Strategy pattern Encapsulation of hierarchization algorithms

Decorator pattern Extensible hierarchization classes Dynamic combination of hierarchization objects(e.g. new PattenStrategy(new BasicStrategy()); )

<<pattern>>Strategy

<<framework>>Hierarchization

<<pattern>>Decorater

deployment UndoableEdit

HierarchizeStrategy

BasicStrategy AdvancedStrategy

PatternStrategy ContainerStrategy

process(edit)Manages

Delegates-process

1

*

1 1

1

1

Composites

UndoManager

UndoableBeanManager


Evaluation Methods

Conventional method: [Con] javax.swing.undo package

Our method: [Non] no-hierarchization [Basic] Basic hierarchization [Patt] Basic+Pattern hierarchization [Ctan] Basic+Container hierarchization

Samples Sample A: LunchApplet Sample B: Test Sample C: FontViewer Sample D: extended FontViewer

FontViewer


Development cost Necessary development costs for implementation of undo facility

Types of cost Codes/classes which programmer writes (hand coding) Codes/classes which can be generated automatically

Result of our method Codes which programmer writes, 78.4% has been reduced

Effect of Generator in our method Lower values in number of classes


Usability (preparation) Environment

Athlon 800MHz, Memory 256MB, Java2 RE1.3, Windows 2000 Usability test

Four testers executed 20 tasks with Five sample D: [Con], [Non], [Basic], [Patt], [Ctan] Task:

Each task has target strings (e.g. task1: “Sample”, task2: “Sample code” ) Testers can perform specific operations (add, delete, change size, change style, change name) Testers can perform undo/redo (+ advanced undo/redo at our methods)

Measure: Number of specific/undo,redo operation times Execution time Relative usability score score[x]=100 * total_operation[Con] / total_operation[x]


Usability (evaluation) Results of our methods

[Non]: large number of undo/redo operation times, low usability [Basic]:large number of undo/redo operation times, low usability [Patt] (Basic+Pattern hierarchization)

The number of undo/redo operation times was smaller than [Con](but, more experience in advanced undo/redo operation is necessary)

[Ctan] (Basic+Container hierarchization) The number of total operation times was smaller than [Con] The relative usability score exceeds 100 point Effect of container-hierarchized undo/redo operations

Type [Con] [Non] [Basic] [Patt] [Ctan]

Execution time [ms]

Specific operation times

Undo/redo operation times

Total operation times

Relative usability score

5082 6402 5409 5246 5385

2.98 3.73 3.33 3.31 3.82

3.38 7.88 4.72 3.17 2.41

6.37 11.61 8.05 6.48 6.23

－ 54.8 79.1 98.2 102.1


Conclusion We propose a new implementation technique of the dynamic hierarchical undo facility

Low implementation cost High usability with container hierarchization

Future works Limitation in usage

Target applications should be based on fine-grained component All behavior should be performed by properties’ changes

Solution by introspecting all elements of application, and decomposing into fine-grained components


Maintenance cost Necessary adaptation costs for specification change

Types of cost Modification in original logic part Modification in UndoFW applied part by handcoding Modification in UndoFW applied part by autogeneration

Data structure change: StringBuffer to String, Sample C was used

Results of our method Programmer actually need not modify UndoFW applied part Impacts of specification change were localized in generated UndoableComponent

Type[Con]

codes (classes)[Ours]

codes (classes)

UndoFW applied part (handcoding)UndoFW applied part (autogeneration)

Original logic part 6 (1)14 (3)

- (-)

6 (1)

0 (0)80 (1)


UndoableBean Additional framework for JavaBeans

adapter

Bean1 Bean2

UndoableBean1UndoableBean2

UndoableBeanManager

ApplicationOriginal application

Storing commands Undo/redo operation

UndoableBeanEdit

Taken-out, undo/redo

Changes-property/Fires-event

Notifies, stores

Resets-property

1

*

1

*

1*

*1

Undo/redo operations

Pre generates

Creates

UndoManager

<<abstract>>HierarchizeStrategyDelegates-

hierarchization process

Generator


Preparation for definition (diagram)

(E1) Edit

(E2) Edit

(E3) Edit

(E4) Edit

Hierarchization

E1(3,3)

E2(1,1)

E3(2,6)

(2,6)E4

1

2

1

2

E1(3,3)

E2(1,1)

E3(2,6)

1

1

(2,6)E41

1

E4 was undone

E1(3,3)

E2(1,1)

E4

E3(2,6)

[time]

Current state

History list

Initial state

Command

(2,6)

State

Undo

E’2

E’1Undo

[time]

Compoundcommand(E1,E2,E3)

(3,3)(1,1)(2,6)

(2,6)

Diagram representation History list: set of commands actually used History tree: internal representation of hierarchized commands

History treeHistory list(Level=1)

root root


Support of flexible undo/redo operations

Flexible undo/redo operations Change and selection of the tree’s level at run time

S1 1(3,3)(1,1)(2,6)

S2 2(5,3)(4,2)

S1 3(6,0)(4,2)

S2 4(3,3)(1,1)(2,6)

S3 5(5,3)(4,2)

S1 6(6,0)(4,2)

History tree

[time]

S’1 (3,3)(1,1)(2,6) (5,3)(4,2)

S’2

(6,0)(4,2)(3,3) (1,1)(2,6)(5,3) (4,2)

S’3 (6,0)(4,2)

History list

(Level=1)

Undo

Undo

Undo

[time]

S’’1 (3,3)(1,1)(2,6)

S’’3 (6,0)(4,2)

S’’5 (6,0)(4,2)

Undo

S’’2 (5,3)(4,2)

S’’4 (3,3)(1,1)(2,6) (5,3)(4,2)

Undo

Undo

Undo

Undo

[time]

S’’’1 (3,3)(1,1)(2,6)

S’’’3 (6,0)(4,2)

S’’’6 (6,0)(4,2)

S’’’2 (5,3)(4,2)

S’’’4 (3,3)(1,1)(2,6)

S’’’5 (5,3)(4,2)

Undo

Undo

Undo

Undo

Undo

Undo

History list

(Level=2)

History list

(Level=3)root

h.washizaki and y.fukazawa, tools pacific 2002, february 20, sydney, australia1 dynamic hierarchical...

Documents