(발제) user interface modeling with uml +university of manchester -paulo pinheiro da silva...

-오재혁

User Interface Modeling with UML

오재혁

Sequence Diagram

Object

Timeline

Message

Object

Timeline

Message

Sequence Diagram UI Workflow

출처 : http://bitswiz.tistory.com/27

http://bitswiz.tistory.com/27


출처 : http://bitswiz.tistory.com/27

View(UI)

Control(Logic)

Model (Class, Object, Data)



Complex UI Workflow

3D Sequence Diagram

2008,

Patent

IBM

Three Dimensional Software ModellingJoseph (Yossi) Gil*

IBM T.J. Watson Research CenterP.O. Box 704

Yorktown Heights, NY 10598, [email protected]

Stuart Kent†

School of Computing and Math SciencesUniversity of Brighton

Lewes Road, Brighton, [email protected]

* Research done in part while the author was at the Technion Israel Institute of Technology.† Partially supported by the UK EPSRC under grant GR/K67304.

ABSTRACTTraditionally, diagrams used in software systems modelling havebeen two dimensional (2D). This is probably because graphicalnotations, such as those used in object-oriented and structuredsystems modelling, draw upon the topological graph metaphor,which, at its basic form, receives little benefit from threedimensional (3D) rendering. This paper presents a series of 3Dgraphical notations demonstrating effective use of the thirddimension in modelling. This is done by e.g., connecting severalgraphs together, or in using the Z co-ordinate to show specialkinds of edges. Each notation combines several familiar 2Ddiagrams, which can be reproduced from 2D projections of the3D model. 3D models are useful even in the absence of apowerful graphical workstation: even 2D stereoscopic projectionscan expose more information than a plain planar diagram.KeywordsModelling, visual formalism, object-oriented softwaredevelopment, CASE tools, formal methods, state charts.1 INTRODUCTIONThe advent of powerful and cheap graphical workstations,enables the use of 3D modelling in many softwareapplications. This trend is amplified with the introductionof standards such as OpenGL [13] and VRML [3]. Thereare also several systems for visualising software execution,for debugging and other purposes [22], [15]. Yet, perhapssurprisingly, 3D modelling has not yet made its way intothe domain of specification and design of software andinformation systems. Diagrams of various sorts are usedextensively in this domain. These include data flowdiagrams, state charts, flow charts, entity-relationshipdiagrams, and the diagrams in OPEN [8] and UML [21],which are all essentially 2D. It is only natural to ask: Howcan the introduction of 3D contribute to software andsystems modelling?This paper presents an alternative to current 2D diagramsin the form of a series of 3D graphical notations. It shouldbe emphasised at the outset that the third dimension is nota mere embellishment. The semantics it carriesconsiderably enhances the expressive power of graphicalnotations, without resorting to the clutter of textualannotations.

The notations presented here complement and arecompatible with existing 2D notations such as thosemaking up UML. In fact, each of our 3D models can bethought of as a seamless combination of several 2Ddiagrams. Conversely, the 2D diagrams can be extractedfrom the 3D model by its geometric projection onto aplane.3D software models enable visualisation of richersemantics than those of 2D models. For example, there are3D models that encompass both a static and a dynamicdescription of a system. Although we envisage a set of 3DCASE tools which support the creation, editing andmanipulation of models, 3D models are useful even in theabsence of such tools. A stereoscopic projection of such amodel is semantically richer than a 2D diagram, since the3D visual cues that the projection delivers, also carry asemantic meaning.Section 2 explains why many of the notations in currentuse are inherently 2D and elaborates on the rationale andtechniques of 3D modelling. Section 3 reviews a number of2D notations, mostly taken from UML, the latest standardin graphical languages for the modelling of softwaresystems. Section 4 reviews constraint diagrams [14], anewly proposed 2D notation, which plays a pivotal role inour 3D models. Section 5 introduces the 3D notations:contract boxes, 3D sequence diagrams, nested boxdiagrams, and a 3D extension of flow charts. Therelationship between the 3D and 2D notations is alsodiscussed, using the metaphor of geometric projection.Finally, Section 6 concludes the paper with a summary andoutline of future work, focusing on semantics and toolsupport.2 FROM 2D TO 3D MODELSThe immediate reason that diagrams used for softwaremodelling are 2D rather than 3D might seem to be thatdrawing on paper is much easier than sculpturing. Amoment’s reflection will reveal that there must also be adeeper reason. After all, paper has been used extensivelyfor depicting 3D models, and flat screens are effective forrendering 3D information, as in movies, TV, and incomputer screens.We attribute the prevalent use of 2D diagrams to the factthat most diagramming methods are based on graphs. Forexample, in flow charts the graph nodes are computationalsteps and edges represent control flow. Similarly, in E-Rand class diagrams nodes are entities and edges are the

created and destroyed, a collaboration diagram completelyineffective. Various techniques to get around this problemhave been suggested including textual annotations (usedhere to show that a Loan object is created), colour codingmessage passes and rendering their effects in the samecolour, and animation in a CASE tool, where changes areshown as time progresses. None are ideal: textualannotations are not visually appealing and require muchdecoding of labels, there is only a limited number of clearlydistinguishable colours, and animation is transient - itloses the “whole picture”.The diagrams are also not good at showing conditionalstatements and looping, as emphasised by [9]:

“One of the principal features of either form of interactiondiagram is its simplicity … if you try to represent somethingother than a single sequential process without muchconditional or looping behaviour, the technique begins tobreak down.”

The edge denotation problem is the reason for thisdifficulty. A proper visual representation of operations withcontrol structures such as loops or parallelism requires twofundamentally different kinds of edges: one to indicate thedifferent execution paths the operation may take (similar toflow charts) and the other to show the inter-relationshipsbetween the participants. Collaboration diagrams onlyshow the relationships. Sequence diagrams whichconcentrate on time progression, make a less efficient useof 2D in using the X co-ordinate to denote objects, andtherefore cannot show the potential paths of control.In Section 5 we show how the third dimension may be usedto solve many of these problems.An object diagram is simply a collaboration diagram withthe message passing and parameter links removed. It givesa snapshot of (a part of) the system state at a point in time.It is useful for illustrating states that the system may andmay not be in, which can be helpful in deriving invariants,including constraints on associations. Snapshots can alsobe strung together in a sequence to form a filmstrip, toshow how the state of the system changes through time.This technique is used extensively in the UML compliantCatalysis method [5].3.4 Activity DiagramsAn activity diagram is a form of flowchart extended withnotation to show processes working in parallel. Itcomplements sequence and collaboration diagrams, as it isable to show iteration and choice, both of which are veryhard to show on those diagrams. On the other hand, it isdifficult to depict a message passing between objects usingan activity diagram. The diagrams are similar enough toflowcharts to make an example unnecessary.4 CONSTRAINT DIAGRAMS[14] introduces a new notation, called constraint diagrams,which derives its name from its ability to express a widerrange of sophisticated constraints on a model than ispossible with diagrammatic notations used for object-oriented and structured systems modelling. Constraintdiagrams can be thought of as an application of Harel’s hi-

graphs [10] in the domain of specification of object-oriented systems, with several important extensions, themain ones being the ability to show set membership, andthe ability to quantify both universally and existentiallyover set members, in addition to set plain containment.This is achieved in part by introducing notation forshowing singletons (and sets of other cardinalities).The notation is summarised here, using the example inFigure 5 for illustration.

Figure 5 documents an invariant which can not beexpressed using the diagrammatic notations of UML, evenenhanced with ideas from other OO notations such as [6].The only other way to express these precisely is throughthe use of a textual, mathematical language, such as thatsuggested for [4], [5], or [19]Informally, the invariant may be stated as follows:

For any library and any copy in that library’s collection, ifthe copy is on the shelf then it is available for borrowing toall active users registered with the library. If, however, thecopy is on hold for a particular reservation that had beenmade, then it is only available to the registered user thatmade the reservation.

Let us now proceed to explain how this invariant can beread from the diagram, and in so doing introduce the mainparts of the notation.Before we begin, it should be noted that the notation ishighly dependent on sets. Thus a type is treated as the setof objects of that type and is indicated by the same symbolas a type on a type diagram. A state is treated as the set ofobjects in that state, and is indicated by the symbol used torepresent states on a state diagram. Indeed, enclosing thestate diagram of Figure 2 in a type box labelled Copy, andremoving the transition arrows, would result in aconstraint diagram. Other sets are introduced below. Theother main piece of notation is the link, which correspondsto associations in type diagrams.The starting point for reading Figure 5 is x. This is anarbitrary singleton set (i.e., object) of the type Library. It isthe starting point because it is the least defined set on the

User

Copy

col l

ActiveOnShelfavai lab leTo

OnHold

Reservation

avai lab leTo

Library

registered

col lect ion

onHo ldFor

x

y

z

Figure 5 - Constraint Diagram

diagrams - one for the pre-condition and one for the postcondition. Making this layering explicit might be necessaryfor complex specifications.The constraint diagram notation is extended slightly with aspecial symbol for input parameters of the operation. Inthis stereoscopic projection a diamond symbol has beenused*.In Figure 6, two parameters of the actions are shown, acopy and a user. The pre-condition constraint representedby this diagram is that the copy, which must be anavailable one in the collection of the library on which theoperation is being invoked, must be available to a set ofusers including the parameter to the operation, which inthis model is the one borrowing the copy.The object on which the operation is being invoked isshown by a message send which is depicted by a “lightningbolt” to that object, labelled with operation being invoked.The post-state diagram shows the change in state that theoperation has caused. Object lifelines are used to show thatan object taking part in the post-state is the same asanother depicted in the pre-state. In general, lifelines canbe used to connect sets. Here, the effect of the operation isto:• change the state of the input copy object to Out, which

is shown by moving the object from the projection ofthe Available state to the projection of the Out state;

• ensure that the set of objects the copy is availableTois empty ( );

• create a new loan object in the OnGoing state(indicated by a ); and

• associate the loan object with the user and the copy.This illustrates a further extension to the constraintdiagram notation, specifically to indicate the creation ofobjects. The creation of a single object is indicated throughthe use of a , of a set with 0 or 1 objects by , and of a

set with an arbitrary number of objects by .Some of this behaviour, namely the pre condition that thecopy object must be in the available state and the fact thatit changes state during the operation could be shown by astate diagram in UML. Indeed a projection of this diagramwould be a part of the state diagram for Copy given inFigure 2. It would be constructed as follows. Focus on thecopy object that changes state (if there was more than one,then repeat the process for each). Draw a state diagramwith a single transition labelled library.borrow(u.this) (theoperation being performed is borrow on the library objectobtained by navigating backwards down the collection linkfrom the copy object under consideration). The source ofthe transition is the state in which the copy object appearsin the pre-state diagram, and the target is the state inwhich it appears in the post-state diagram. Finally, place a * In a true 3D rendering, we envisage using “pits” in the topplane for input parameters, and “pegs” sticking out of the bottomplane for output parameters.

guard on the transition to the effect that the copy (this)must be available for lending to u.A textual (informal or formal) version of the contract couldalso be derived from the diagram in a similar way to the

derivation of invariants from constraint diagrams.5.2 3D Sequence DiagramsThis section shows how the third dimension can usefullybe employed to provide much richer visualisations ofaction designs, than is possible with UML sequence andcollaboration diagrams. Indeed, we contend that both ofthese kinds of diagram are projections of a single 3Dsequence diagram.Figure 7 gives an example of the 3D sequence diagram forthe borrow action. Each plane represents the state of thesystem at which an object is sent a message. As before,lightning bolts represent message sends. A constraintdiagram may be used at each plane to show the context ofinput parameters, and, if desired, pre-condition

Copy

Available

Library

User

Loan

ava i l ab leTo

Borrow

col lec t ion

addLoan

addUser

takeOut

Figure 7 - 3D sequence diagram

+ sequence diagram =

3D Visualization of Complex Software Models: Practical Useand Limitations

Joacim Alvergren!

IT University of Gothenburg

Jonatan Granqvist†


ABSTRACT

Model Driven Development is becoming a popular method-

ology when developing large software systems. 3D visualiza-

tions has been proposed as an aid for the developers trying to

comprehend large amounts of complex diagrams present in

model driven development. But how effective is it in practice,

and how will it scale when applied on large complex system?

The purpose of this study is to validate if 3D visualization in-

creases comprehensibility of large, complex diagrams and to

explore what limitations there are to the technique. A tool

that can visualize diagrams was constructed and validated

through a technical validation and a qualitative interview

study at Ericsson AB. The results show that 3D aids the user

to get a better understanding of the structure and compo-

nent relationships of the diagrams, something that is a highly

complex task when using the present 2D tools. The 3D visu-

alization makes it more intuitive for the user to see how dif-

ferent parts in the model relate to each other. The study also

shows that 3D has potential to be used as an alternative to

the file tree-browser present in most modeling tools: the user

can find diagram parts easier, see interconnections and nav-

igate faster between different sections of the model. Several

limitations that are needed to be solved before the technique

can be put in to use in production were identified and these

include issues relating to information overload and problems

distinguishing relationships between hierarchies.

Keywords: 3D Visualization, UML, RSART, Model Com-prehension, Software Visualization, MDD

1 INTRODUCTION

Model driven development (MDD) is a software develop-ment methodology where models represented as visualizedabstractions are used to develop software systems. Thismethodology is normally applied so that the developers cre-ate diagrams using the Unified Modeling Language (UML)with connoted model data and then a modeling tool generatesparts or all code for the software system. MDD combines thesoftware design and software implementation activities and

!e-mail: [email protected]†e-mail: [email protected]

aims to increase productivity and make the software morecomprehensible (Selic 2003).

However, with ever larger and more complex software sys-tems the present visualization of the model diagrams havebeen found to have problems with comprehensibility. Whendeveloping large software systems it is vital to have a men-tal model: a comprehension of the structure of the system’sdifferent components and their relations to each other. Work-ing with the complex hierarchical models present in MDD,gaining such a mental model has become a highly challeng-ing task (Krolovitsch & Nilsson 2009).

The way the present MDD modeling tools allow for theuser to comprehend the structure is by traversing betweenthe different components in the model represented by 2-dimensional diagrams. This is a complex task that demandsmemorizing large parts of the model to gain an understand-ing of the hierarchic structure and that puts a high cognitiveload on the user trying to comprehend the model.

To increase the comprehensibility and reduce the cognitiveload of the user, a suggested solution has been to also visual-ize the models in 3-dimensional diagrams (McIntosh et al.2005, von Pilgrim & Duske 2008, Krolovitsch & Nilsson2009). The increased spatial expressiveness in a 3D visual-ization compared to 2D allows the user to view and explorelarge amounts of information at once and could therefore in-crease the comprehensibility of the model, something previ-ous studies in this area have found evidence for (Lange &Chaudron 2007).

However the studies that have made functional prototypesin this area have not validated the prototypes against a largereal-world industry model. Testing the technique on a largecomplex model naturally increases the complexity of thevisualization and could expose challenges, weaknesses andlimitations not visible in small models.

The purpose of this paper is to test if the ideas of increasedcomprehensibility using 3D visualization can scale to a large,complex, real-life software model and uncover what limita-tions there are. It will also investigate how a tool can beconstructed to automatically generate an aesthetic 3D visu-alization of hierarchical UML models.

2 RESEARCH APPROACH

To be able to validate if 3D visualization indeed increasescomprehension of large, complex models we have created a


Joacim Alvergren!




ABSTRACT



























1 INTRODUCTION









2 RESEARCH APPROACH


Figure 2: Comparison between 2D and 3D view

3.3 User validation

During the user validation we identified several limiting fac-tors of the 3D visualization technique in software modelingof large complex systems — and what steps are needed totake before the technique can be truly useful in everydaypractice. We also identified in what areas of practice thetechnique have the biggest potential to have a positive im-pact.

3.3.1 Visualization of abstract information

The 3D visualization is seen as something that is usefulmainly to people working with development. The use fornon-technical people that are involved in the developmentprocess is seen as limited but could provide a visual expe-rience of the size of the system that is otherwise hard toconvey. Seeing something as a picture is seen as generallypositive and the informant gives an example relating to theDNA-spiral: people had been working with DNA for yearsand knew it was there but until someone made a visual repre-sentation of it people did not share an image of it. The sameis certainly true about something as abstract as software, butit also poses a challenge as there is no natural link betweenthe 3D visualization and the artifact that is created. Softwaredo not have a shape, form or color compared to for instancehardware modeling where the link between what you visual-ize and the artifact you create are much more natural.

Since many people are acquainted to the UML 2D diagrams,switching to see the software visualized as a 3D image wouldnaturally take some habituation. An important step to sim-plify this and to avoid confusion between the 2D and 3D vi-sualization is to minimize the need to switch between the dif-ferent types of visualization as the switching between viewswould put a strain on the user having to readjust his thinkingto fit with the visualization type.

3.3.2 Information overload

One major limiting factor for the scalability of visualizationof complex models identified in the user validation is infor-mation overload. When trying to interpret complex struc-tures, getting too much details presented at once severely af-fects the comprehensibility. The informant expressed thatthe process for the investigation of a complex model shouldbe to go from a simple overview with limited detail level.Then from this view identify the section of the model whichis of interest depending on the task and then focus on thissubset and build up a view of the model with the specificdetails needed.

The way the informant currently is working, the only possi-bility to get an overview of the model is to traverse betweenmany fully detailed views showing small components of themodel. These views provides information that are importantwhen doing detailed implementation work in a specific partof the model but become too expressive when the user is try-ing to get a grip of structure and to assess how changes inone part of the system will impact other parts of the system.As a complement to these detailed diagrams a 3D view pro-vides substantial practical improvement to the way of work-ing with large complex models. Both being able adjust thelevel of detail shown and to have the ability to select and vi-sualize a specific subset of the model is seen as important toavoid the negative effects of information overload.

3.3.3 Visual coherence

Having high visual coherence between the different visual-ization views of the model is expressed as very important byour informant. 2D and 3D views should share the same vi-sual representation to make it easy for the user to connect anobject in one view to the other. This is true within the 3Dview as well. If one object exist is several places, one shouldbe able to get a natural connection between them. Visual


Joacim Alvergren!




ABSTRACT



























1 INTRODUCTION









2 RESEARCH APPROACH


Cons.Visualization of abstract information: 2D UML 에 익숙한 사람들에게 3D 를 제공하기 위해 적용한 상징들을 이해시키기 어려웠다.Information overload: 복잡한 대상을 단계적으로 이해해 갈 수 있도록 적정한 Level of Detail 조정, 손쉬운 부분 선택 등의 기능이 필요하다. Visual coherence: color, position, shape, relative size 등으로 긴밀하게 연동된 2D, 3D view 를 함께 보여주는 것이 필요하다.

새로운 3D View 가 전체 시스템에 대한 이해를 넓히는데 도움을 줄 수 있지만, 아직 기존 일선의 사람들에게 직접 적용하기에는 넘어야할 단계들이 많다.

http://www.x3d-uml.org/

http://youtu.be/gcgQajTXVrA

http://www.eclipse.org/gef3d/

https://www.youtube.com/watch?v=fD5QLuPo-uE









User Interaction and Interface Design with UML

Jesús M. Almendros-Jiménez and Luis Iribarne Dpto. de Lenguajes y Computación. Universidad de Almería

{jalmen,liribarne}@ual.es

Abstract This chapter is devoted to show how to use and specialise UML diagrams for describing the user interfaces of a software system. In order to accomplish the description of user interfaces, the proposed technique considers three specialised UML diagrams called user-interaction, user-interface and GUI-class diagrams, which will be built following a model-driven development (MDD) perspective. These diagrams can be seen as the UML-based UI models of the system. In addition, this paper concerns with code-generation to implement the user interfaces of the system by using GUI-class diagrams and user-interaction diagrams. A case study of an Internet book shopping system is introduced in this chapter to proof and illustrate the proposed user interaction and interface design technique. Key words: UML 2.0, Use Cases, Model-Driven Development, Visual Languages, Interactive Computing, Interaction Design.

INTRODUCTION

The emergence of the Unified Modelling Language (UML) (OMG, 2005) as an industry standard for modelling systems has encouraged the use of automated software tools that facilitate the development process from analysis through coding. The user interface (UI), as a significant part of most applications, should also be modelled using UML. UML diagrams could be used to model user interfaces, and automatic CASE tools could help to generate code for user interfaces from UML designs. In general terms, visual modelling allows the developers to visualize source code in a graphical form: graphical abstractions, such as flow charts to depict algorithmic control flows and structure charts or simple block diagrams with boxes representing functions and subprograms, and so on. UML provides system architects with a visual language for specifying, constructing and documenting the artefacts of software systems. In particular, user interfaces should be visually modelled in order to describe the behaviour of the window system in response to user interactions. This chapter is firstly devoted to show how to use and specialise UML diagrams in order to describe the user interface and user interactions of a software system, following a particular model-driven development (MDD) perspective. Model-driven development involves creating models through a methodological process that begins with requirements and looks into a high-level architectural design. Model-driven development facilitates and improves the software analysis and design and code generation facilities from models prevent the loss of substantial information during the transition of a model to its implementation. In our MDD perspective, we consider the following steps for user interface design and modelling: (a) Firstly, we use a UML use case diagram for extracting the main user interfaces. (b) Secondly, we describe each use case by means of a special kind of UML activity

diagrams, called user-interaction diagrams, whose states represent data output actions

UML-based User Interface modeling 의 장점

1) rapid prototyping2) model validation and refinement3) model-based code generation4) start-point for implementers

UWE (UML-based Web Engineering Approach)

on the Unified Process [JBR99]. The UML is extended to model Web applicationsand the Unified Process is tailored for the development of these applications (cf.[Ko00]).The objective of the conceptual design is to build a conceptual model of theapplication domain taking into account the functional requirements captured with usecases. Traditional object-oriented techniques are used to construct the conceptualmodel, such as finding classes and associations and defining inheritance structures.The conceptual model is represented by an ordinary UML class diagram.Based on the conceptual model the navigation design proposes a set of guidelines toconstruct a navigation model which represents the navigation space and the accesselements that can be used for navigation (see Figure 1). We briefly summarize a set ofstereotyped modeling elements for navigation design, like indexes, guided tours,queries and menus. The presentation modeling aims at the design of abstract user interfaces and thedesign of the user interaction with the Web application. It consists of two steps:storyboarding user interfaces and building the presentation model which provides thesource for an implementation. In contrast to [HK00] we focus in this work on theprecise specification of the steps needed for a systematic design of the presentation.For this purpose stereotyped modeling elements which are suited for storyboardingand for modeling the concrete design of the presentation are included in our WebProfile. Our goal was also to show how these stereotypes can be used together withthe WAE stereotypes of Conallen [Cj99] such that both approaches can benefit fromeach other.The first step in the presentation design defines user interface views which sketch thecontent and the look and feel of the nodes. These user interface views can then becombined to storyboarding scenarios that are an excellent basis for developing apresentation model and constructing a pure HTML prototype. Sketching andstoryboarding are common techniques of user interface designers, but usually theydon’t have a unique and precise notation [Pj94,Sb98]. Our approach providesmethodological guidelines and modeling elements for storyboarding.The next step of our method goes towards an implementation (Figure 1). Based on thestoryboard model the designer can decide whether he wants to choose a multiple-window technique and/or whether he wants to use frames and/or dynamic pagegeneration. The objective of the presentation model is to show where the userinterface views of the storyboard model are presented to the user, i.e. in which frameor window they are displayed. This also shows which contents are replaced when theuser interacts with the system. In addition to the client pages, constructed inaccordance with the user interface views, server pages in the sense of Conallen areidentified when they are required for the dynamic generation of client pages.

Conceptual Model

NavigationModel

PresentationModel

«trace» «trace»

Fig. 1: Models of the UWE design process

Modeling the User Interface of Web Applicationswith UML

Rolf Hennicker1, Nora Koch 1,2

1 Institute of Computer ScienceLudwig-Maximilians-University of Munich

Oettingenstr. 67D-80538 München, Germany

{kochn,hennicke}@informatik.uni-muenchen.de

2 F.A.S.T. Applied Software Technology GmbHArabellastr. 17

D-81925 München, [email protected]

Abstract. Today's User Interfaces (UIs) are complex software components,which play an essential role in the usability of an application. The developmentof UIs requires therefore, not only guidelines and best practice reports, but alsoa development process including the elaboration of visual models and astandardized notation for this visualization.Based on a UML extension for Web applications of previous work, we arefocusing in this paper on the user interface design of Web applications,describing in detail the methodological steps – part of the UWE design process– to transform a model of the navigation into a user interface model. Wepropose a UML profile for the Web, which supports sketching andstoryboarding (techniques that are widely used by UI designers without aprecise notation). The strength of the UML models presented is given by thefact that they provide a precise notation and can be used as a basis for a semi-automatic generation of UI templates for Web applications.

Keywords. User Interface Design, Web Engineering, Development Method,UML Profile, Systematic Software Development, Web Applications

1 Introduction

Designing user interfaces for Web applications is a complex task which needs, in thesame way as other aspects of system development, methodological guidelines andmodeling techniques. In previous work (cf. e.g. [HK00]) we proposed a designmethodology for Web applications which consists of conceptual, navigation andpresentation design. These steps are part of the UML-based Web EngineeringApproach (UWE). UWE is based on the Unified Modeling Language [UML01] and

2.3 The Method

Our methodology for the design – part of the UWE approach – presented in [HK00]identifies a set of steps and guidelines for the construction of the navigation model.The main steps are summarized as follows:

1. Classes of the conceptual model that are relevant for the navigation are includedas navigation classes in the navigation model (i.e. those classes that are not avisiting target in the use case model are excluded).

?

Project

Employee

head

projects

ByProjectNameByEmployee

ByProjectNameByDepartment

ByEmployeeNameByDepartment

employees

ByProyectName

departments

projects

employees

ByEmployeeName

ByDepartmentName

projects

1

1..*

1

1..*

1..*

1

1..*

1

1..*

1

1

1

1

1..*

searchEmployees

searchByEmployeeNameByDepartment

{xor}

1

Company

Department

1

1

0..1

CompanyMenu

DepartmentMenu

EmployeeMenu

1

Fig. 5: Navigation Model

3.3 The Method

To model an abstract user interface we assume given a navigation model of theapplication. Each abstract user interface model is represented as a composition ofclasses. The following rules can be used as guidelines for the construction of theabstract user interface model:

1. Construct a presentation class for each navigation class occurring in thenavigation structure model. The presentation class defines a template suited topresent the instances of the class by taking into account the given attributes.Stereotyped interface elements, such as «text», «image», «audio», «video» areused for attributes of primitives types and «collections» are used for lists, etc.Figure 7 shows the presentation class for a company.

2. Construct a presentation class for each menu and index occurring in thenavigation structure model. The presentation of a menu or an index classconsists usually of a list of anchors. Use stereotypes «anchor» or «anchoredcollection» for this purpose. An example for the presentation of a menu is theCompanyMenu in Figure 7.

3. Construct a presentation class for each query and guided tour. For queries use a«form» stereotype and for guided tours use a menu with items “next” and“previous” (which make it possible to navigate to the next and to the previousobject within a guided tour).

«presentation class»CompanyMenu

«presentation class»

Company

Head

Departments

Projects

Employees

«UI view»CompanyView

Employee

«UI view»HeadView

DepartmentIndex

«UI view»DepartmentIndex

«UI view»DepartmentView

HeadMenu

Head

Departments

Projects

Employees

Home

Head

Departments

Projects

Employees

Home

«presentation class»DepartmentMenu

«presentation class»DepartmentMenu

Head

Departments

Projects

Employees

Home

«anchoredcollection»

*

...

Department





1

1

1

Fig. 8: Storyboard Scenario for Head and Department

models. A presentation model must be built conform to the composition structure ofclasses shown in Figure 9. Consequently, these stereotypes are restrictive stereotypesin the sense of [BGJ99].

4.2 Example

Figure 10 shows (part of) the presentation model for the Web site of the servicecompany. Figure 11 shows (using a UML sequence diagram) a presentation flowrepresenting a scenario for a sequence of possible navigation activities that can beperformed by a user of the application.

4.3 The Method

The presentation model requires that the designer takes some decisions, such asnumber of windows to be used and number of frames each frameset is divided into.

Head

Departments

Projects

Employees

«client page»CompanyMenu

«client page»MainMenu

Head

Departments

Projects

Employees

Home

«window» TopWindow

«frameset» CompanyFrameset

«frame» Left

«frame» Right

«client page» Company «frameset»

MainFrameset

«frame» MainLeft

«frame» MainRight

«links»

«displays»

«links»

«client page» Employee

«server page» DeptartmentIndex

«client page» DepartmentIndex

«builds»

«links»

«displays»

«displays»

«displays»

«displays»

«displays»

«displays»

{xor}

«targets»

«targets»

Fig. 10: View of the Presentation Model of the Company Web Site

Hence the construction of the presentation structure cannot be fully automated, butthere are certain guidelines that the designer can follow:

1. Select between a single or multiple-window technique. In case of a multiple-window technique plan how many windows will be used.

2. Decide whether frames will be used for the realization. If this is the case specifyhow many frames each frameset has. Typically the partitions of the userinterface views of the abstract user interface model will be realized by frames.

3. Transform the presentation classes of the abstract user interface model into Webpages of the presentation model. In most cases this is straightforward since onlythe anchors and forms have now to be directed to appropriate Web pages orserver scripts by using associations stereotyped by «link» or «submits»,respectively. If a client page should be dynamically generated a correspondingserver page and an association stereotyped by «builds» must be introduced.

4. Decide in which frame (of a frameset) or in which window a Web page is to bepresented to the user. This will be modeled by the target associated to an anchor.

If many windows and/or frames are used, it is advisable to construct partial views ofthe presentation model to avoid an overloaded notation.The construction of the presentation flow can follow the guidelines listed below. Notethat in this representation it is not relevant whether the pages are static HTML pagesor they are generated dynamically.

1. Set the scenario for the interaction model, i.e. define which navigation path ofthe navigation structure diagram will be modelled.

: User window1 :Window

: Left : Right

display (CompanyFrameset)display(CompanyMenu)

display(Company)

select(Head)

display(MainMenu)

select(Department Índex)display(DepartmentIndex)

display(MainFrameset)

display(Employee)

Fig. 11: Presentation Flow for a Scenario of the Company Web Site

2 Pedro F. Campos and Nuno J. Nunes

seamlessly supporting multiple levels of abstraction (in terms of UI detail). The

following section describes the languages and the semantic model of our tool. Section

3 briefly explains some of the tool’s features and Section 4 draws some conclusions

and future lines of research.

Figure 1: Prototyping techniques from inception to construction (adapted from [1]).

2. CanonSketch: the Languages

CanonSketch’s main language is an extension to the UML for the design of

interactive systems: the Wisdom profile [7]. The Wisdom UML view is at the highest

level of abstraction: it is useful for drawing navigation and containment relationships

without concern for details of layout or spatial positioning.

The HTML concrete view is at the lowest level of abstraction: it shows a partially-

functional HTML prototype rendered in an embedded browser, thus allowing fast

testing of the UI. The intermediate view is the Canonical Abstract Prototype view.

The symbolic notation underlying Canonical Abstract Prototypes is built from two

generic, extensible universal symbols or glyphs: a generic material or container,

represented by a square box and a generic tool or action, represented by an arrow.

Materials represent content, information, data or other UI objects manipulated or

presented to the user during the course of a task. Tools represent operators,

mechanisms or controls that can be used to manipulate or transform materials [1]. By

combining these two classes of components, one can generate a third class of generic

components, called a hybrid or active material, which represents any component with

characteristics of both composing elements, such as a text entry box (a UI element

presenting information that can also be edited or entered).

Figure 2 shows a screenshot of a document being edited in CanonSketch. The left

part shows the UML view and the right view shows the corresponding, synchronized,

Canonical Abstract Prototype. We can see, for instance, that a containment

relationship between two «interaction space» classes corresponds to a Canonical

material nested inside a Canonical container. The complete, precise mapping between

the three views can be found in [2].

A UML-Based Tool for Designing User Interfaces

Pedro F. Campos and Nuno J. Nunes

University of Madeira – Dep. of Mathematics and Engineering

Campus Universitário da Penteada

9000-930 Funchal – Portugal

Abstract. Existing software modeling tools are widely recognized to be hard to

use and, hence, to adopt. We believe those usability problems are related to a

legacy of formalism-centric tools that don’t promote the new challenges of

modern software development. In this short paper, we briefly describe a new

tool, under development, that tries to promote usability in modeling tools to

support collaborative development of interactive software. It focuses on usable,

real-world languages and a developer-centered design.

1. Introduction

Many different approaches have been proposed to capture the presentation aspects

of interactive systems [5]. These include sketches, content inventories, wire-frame

schematics and class stereotypes. UML class stereotypes have become a very popular

alternative to structure the presentation aspects of interactive systems. Popular object-

oriented methods extend the concept of a class to convey the important presentation

elements, those concepts are know as “views” in Ovid, “interaction contexts” in

UsageCD, “interaction spaces” in Wisdom and “boundaries” in RUP (more recently

“screens” in the new profile for web applications). For a comprehensive review of

those concepts, please refer to [7].

However, all of the aforementioned techniques still leave a considerable gap

between the inception level models of user intentions (task cases, use cases, scenarios

and other requirements level models) and the concrete user interface. The center

ellipse in Figure 1 illustrates this gap. A growing awareness of this conceptual gap

lead Constantine and colleagues to develop a new language for User Interface (UI)

specification, called Canonical Abstract Prototypes [1]. This language fills the gap

between existing inception level techniques, such as the illustrated UML-based

interaction spaces or visual content inventories, and construction level techniques

such as concrete prototypes, as Figure 1 shows.

Informal tools supporting natural input (such as sketching) also allow faster

modeling while communicating unfinished designs to clients and developers. This

encourages exploration and promotes a systematic approach to building a UI. Two

examples of this class of tools are SILK [4] and DENIM [6].

Our approach differs from others like [4, 6, 8] in the sense that we began with a

simple, easy to use drawing application and then added the necessary formalisms,

applying real-world notations (UML and Canonical Abstract Prototypes) while also

Task models

Detailed prototypes

이를 극복하기 위해, Task model 에 대응하는 Detail 의 규범을 정의하는 언어를 적용하기도 하지만, 자연스럽지 않다.