a Model-driven development methodology for 3D User Interface for Information Systems in a Principle based way
•Download as PPT, PDF•
2 likes•724 views
The document summarizes a PhD thesis that proposes a model-driven approach for developing 3D user interfaces for information systems. It presents the state of the art in 3D user interface development methodologies. The thesis introduces a methodology composed of models, a method, and a language for structuring the development process. It validates the approach through several case studies and software tools developed to support the methodology.
Recommended
Recommended
More Related Content
Similar to a Model-driven development methodology for 3D User Interface for Information Systems in a Principle based way
Similar to a Model-driven development methodology for 3D User Interface for Information Systems in a Principle based way (20)
More from Juan Manuel Gonzalez Calleros
More from Juan Manuel Gonzalez Calleros (20)
Recently uploaded
Recently uploaded (20)
a Model-driven development methodology for 3D User Interface for Information Systems in a Principle based way
- 1. Unused Section Space 1 A Model-Driven Approach for Developing 3D User Interfaces of Information Systems in a Principle–Based Way Juan Manuel González Calleros PhD Public Defense February 4, 2010 - LLN
- 2. February 4, 2010 - LLN PHD Public Defense Virtual Reality Augmented Reality
- 3. February 4, 2010 - LLN PHD Public Defense Windows Vista
- 6. What is a 3D User Interfaces? February 4, 2010 - LLN PHD Public Defense Augmented Reality Virtual Reality 3D User Interface 3D desktop environments
- 15. February 4, 2010 - LLN PHD Public Defense 3D Rendering of a 2D GUI VUITOOLKIT [Moli08]
- 18. February 4, 2010 - LLN PHD Public Defense Support for different representations Support for basic Haptic Interaction 3DUIs
- 20. Method Outline February 4, 2010 - LLN PHD Public Defense Task and Domain Model Model to Model Abstract UI Model Model to Model Concrete UI Model Code Generation Final UI Control Task and Domain Model Physical Control Software Control Physical interaction object 2D 3D
- 28. February 4, 2010 - LLN PHD Public Defense
- 37. February 4, 2010 - LLN PHD Public Defense Task and Domain Model Based on Guidelines Model to model Abstract UI Model Based on Guidelines Model to Model Concrete UI Model Usability Advisor Automatic Evaluation Refined Concrete UI Model Code Generation 3D User Interface
- 38. February 4, 2010 - LLN PHD Public Defense
- 39. February 4, 2010 - LLN PHD Public Defense
- 41. February 4, 2010 - LLN PHD Public Defense Case Study Complexity Man/Month LOC Context Polling System + 6 6, 000 VRML Information Systems Student Trainer System + 6 3, 000 X3D Information Systems Haptic Browser ++ 4 (collaboration) 0 Information Systems Visual Impair users AHMI +++ 48 2, 000 X3D 10, 000 + Open GL Information Systems Aeronautics
- 49. External evaluation February 4, 2010 - LLN PHD Public Defense
- 54. February 4, 2010 - LLN PHD Public Defense Domain Model AUI Model Integrates 3DUI in the context of MBUI development Incubator group Integrates new concepts to their ontology based on UsiXML http://www.w3.org/2005/Incubator/model-based-ui/wiki/Main_Page http://forge.morfeo-project.org/wiki_en/index.php/Interactive_Application_Models
- 58. February 4, 2010 - LLN PHD Public Defense
- 59. Benefits from our methodology February 4, 2010 - LLN PHD Public Defense MDA Expected Benefits Reducing the gap between requirements and implementation Developer coordination. Dividing the system into several parts and defining interfaces between them Well-structured systems. This facilitates implementation itself as well as maintenance. Planning on adequate level of abstraction Improved communication by visual models Validation: (Semi-)Formal modeling languages enable automatic validation of the design Documentation: Models can be used as documentation when maintaining the system. Platform-independence. At least serve as starting point when implementing the system for a different platform Enhanced productivity. Expert knowledge can be put into the code generator Reduction of errors Knowledge about creation of modeling languages Frameworks and tools Maintenance of modeling language and transformations Reuse of meta-models and transformations
- 62. Q&A February 4, 2010 - LLN PHD Public Defense
Editor's Notes
- My motivation. Since I was a kid I always dream about being in a virtual reality. Of course at the time I did not refer to those spaces as they are technically known. I did my studies in computer sciences always with the goal of reaching my dream. So far, I think that I put the first stone to build that dream.
- Nowadays, I am glad to see that 3D interaction is not anymore present in research labs and that we could virtually interact with other people by means of the virtual space. Several are the examples of the increasing presence of the 3D metaphor in desktop based systems such as the 3D effect in windows vista or web browsers. However, I do not like the fact that those metaphors are suddenly broke while interacting. For instance Space Time 3D shows a preview of the different web sites corresponding to your search but when you want to access to the web site, the metaphor in not consitant anymore and suddenly your are pop out the application and obliged to continue the interaction in 2D.
- Even when we have pure 3D interaction, such as in this example of purchasing a sit in a stadium, a high detailed 3D object which can be generated only manually. Notice that the controls for buying the ticket need some work and can not be created by relying on a toolkit. The controls for such objects need some work that if you start from scratch would be time consuming. In order to contribute to build this kind of solutions we contruct a methodology for developing 3DUI.
- First, we need to locate you in the context of the definitions. Whhat is a 3DUI. A user interface is know as the communication Channel for the Human to interact with a device. When it refers to 3D we meant that such interaction is by means of a 3D representation. They have been associated to different domain of application such as those in virtual reality, mixed reality, augmented reality, and 3D desktop environments. Similarly as a 2D UI a 3DUI can assist you in your daily life it is just a difference in the representation but of course relying on a 3D representation to replace its 2D counterpart has some pros and cons.
- Let’s review first the advantages: They increase user satisfaction because they are really appreciated by a specific category of users, is a subjective preference that sometimes has been proved with statistical data. Also, cognitive perception of 3D objects are better comppared to 2D obejcts, users tend to remember better 3D than 2D UI, is part of our daily life to intereact in a 3D world so it is normal to have better understanding of a 3DUI rather than a 2DUI. 3D primitives are better compared to 2D representations [Carr03] Users tend to remember better objects shapes and location in 3D [Robe00]
- Unfortunately there are also cons when using 3DUIS as a solution: studies have revelaed that they decrease user performance (oclusion, deep perception), among other reasons bacause they increase the manipulation complexity for an avarahe user, gain this is not for everybody, and neiteher for every task. As Bowman says « we are still looking for the problem to solve and the type of user interested in this. This is why we attemp to characterize the problem we want to solved and the population as follows:
- The information Systems for the organization, addressing problems for administrative tasks, which are characterized by the routine and repetition. For this kind of task different interaction styles have identified, most of them has been depply explored but 3DUI has been poorly explored.
- Always three axis are around my work, models, a method and a language, This is the case of the state of the art:
- A series of comparative analysis were conducted on development methodologies, languages, transformational approaches, 3D Toolkits from which we learn in different proportions about the models, the laguage, the method and the software tool for the methodology.
- Even more important from this review a series of shortcomings were identified which we wanted to addressed in the context of this dissertation vie a set of requirements, which were grouped into categories accordingly to the axis of the methodology.
- When we first look at creating an intolgoy for 3DUIs our first impression was to specialized existing knowledge of 2D Uis because what is the difference between 2D and 3D? Our first impresion was that the second was just an specilization of 2D which means just adding
- Then we got the model of what was known as 3d rendering of a 2D GUI, that corresponds to most of existing solution for 3D Uis. Being our model then we start to explore other dimmension for developing 3DUIs. An soon we realize that this model was good for this category of 3DUIs but was not accurate in other contexts.
- Particularly because we wanted to explore the use of other modalities of interaction and multiple representations something that was not naturally possible with the existing model and more important crontavened the principle of separation of concerns.
- So, after some iterations and exploration of different models and in collaboration with the a researcher of a greek lab of HCI
- we create the 3DUI model that include concepts to express haptic interaction and different representations for 3D UIs
- So, we have the models now we now a method to operate over the models, and for that
- Implementation on specific devices (e.g. HTML, SVG or Java)
- Thanks to the models all the layers can express concepts related to 3DUIs, including the transformations needed a round 85 transformations rules (25 old, 15 adapted, 45 new) Then we have the method for forward engineering development but we considered that we needed more deatils on how to operate the method, in which condisions take the correct design decision, when it was realted to 3DUI development. Even more, how to evaluate the results while progressing in the design?
- Evaluation of the UI is a key step for achieving usable UI, without testing them, Still in 3D evaluation is a cost and hard to assess task, this is why we introduce the notion of relying on principles to reduce the cost for evaluation and yet trying to get as a result a usable UI.
- At the task model level to assist you on the correct selection of task attributes, based on examples and namespaces
- For the selection of interaction facets, whether it is input, output, control, navigation or a combinatio of them.
- Assistance for the correct selection of the concretization of the task but also to select the desirable representation.
- For the selection of interaction facets, whether it is input, output, control, navigation or a combinatio of them.
- There are some guidelines that can be encoded using a computer based format and that can be tested in order to prevent the code generation and time wasted while evaluating a 3DUI with usability problems
- So, we have the models now we now a method to operate over the models, and for that
- Our contribution could be added to other UIDLs, such as XIML, UIML, but this requires that the consortium leading these languages (companies) will adhere to that. Companies are often reluctant to do this because of Ownership
- So, we have the models now we now a method to operate over the models, and for that
- Evaluation of the UI is a key step for achieving usable UI, without testing them, Still in 3D evaluation is a cost and hard to assess task, this is why we introduce the notion of relying on principles to reduce the cost for evaluation and yet trying to get as a result a usable UI.
- Evaluation of the UI is a key step for achieving usable UI, without testing them, Still in 3D evaluation is a cost and hard to assess task, this is why we introduce the notion of relying on principles to reduce the cost for evaluation and yet trying to get as a result a usable UI.
- Evaluation of the UI is a key step for achieving usable UI, without testing them, Still in 3D evaluation is a cost and hard to assess task, this is why we introduce the notion of relying on principles to reduce the cost for evaluation and yet trying to get as a result a usable UI.
- Evaluation of the UI is a key step for achieving usable UI, without testing them, Still in 3D evaluation is a cost and hard to assess task, this is why we introduce the notion of relying on principles to reduce the cost for evaluation and yet trying to get as a result a usable UI.
- Evaluation of the UI is a key step for achieving usable UI, without testing them, Still in 3D evaluation is a cost and hard to assess task, this is why we introduce the notion of relying on principles to reduce the cost for evaluation and yet trying to get as a result a usable UI.
- What it makes difference is that we did not just implement some replication of 2D GUI but there are some innovation on the representation of different 3DUI widgets
- So, we have the models now we now a method to operate over the models, and for that
- clearly explain the difference between normal user (see virtual reality scene made of widgets) and sight-impaired user (manipulate the haptic part of each widget or hapget). In other words, say that you have introduced here the concept of hapget, haptical extension of a widget.
- Show the layout of the FMS as it is today, the main goal is to change the interface of this alphanumeric UI into a GUI wityh 3D effects
- Show the layout of the FMS as it is today, the main goal is to change the interface of this alphanumeric UI into a GUI wityh 3D effects
- Show the layout of the FMS as it is today, the main goal is to change the interface of this alphanumeric UI into a GUI wityh 3D effects
- So, we have the models now we now a method to operate over the models, and for that
- (To reinfor(Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams)ced the systematic design of task models and provide substantial information to support the transformational approach) (Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams) (A sanity check of the AUI model that end in a consolidated version)
- The Domain model is a description of the classes of objects manipulated by a user while interacting with a system. The domain model is composed of DomainSubModel, which is a way to represent a domain model that at the same time can be composed of a different domain sub-model. For instance, Java packages where different submodels can be within a model and they can be associated to different domain facets. A DomainElement describes the characteristics of a set of objects sharing a set of common properties. It can ca composed of DomainItem and DomainCollections. A DomainItem is an atomic unit of data, i.e. which cannot be decomposed further. The DomainItem has an attribute called itemType denoting a data type, such as, but not limited to: Boolean, hour, date, natural, integer, real, character, string. A DomainCollection expresses the notion of data collection, i.e. how to collect individual domain items into a structured format; it can be composed of DomainCollections . A concrete example of a collection of collections is a table. The DomainCollection can be composed of DomainItems . A concrete example of a collection of items is a comboBox. The DomainCollection attribute called collectionType denotes any data structure, such as, but not limited to: set, list, stack, tree, binary tree, shared tree, matrix. The DomainRelationship describes various types of relationships between domain elements. They can be classified in two types: Constraint and FunctionalDependency . The Constraint relationship is self descriptive as it refers to constraints that affect to DomainElements. The Constraint is described with the condition attribute that specifies a condition attached to a constraint, i.e., a rule that must be fulfilled in the specification before or after the application of a Constraint. The Constraint is specialized in: Existence denoting the constraint for one DomainElement to consider the existence of another DomainElement, this is specialized in a ValueConstraint, for instance , to pay a flight ticket the user must have inserted their payment method . Relevance denoting the relevance or importance of a DomainElement compared to another DomainElement. For instance, in a webmail site the login box is more relevant than the welcome box. CardinalityConstraint denoting the cardinality constraint from one DomainElement to another. For instance, on an ecommerce application the shopping cart has a cardinality constraint to have at least one item when passing to the check out section. ReplicationConstraint denoting the constraint of replicating one DomainElement into another DomainElement. The FunctionalRelationship denotes the relationship between two DomainElements A and B bounded by a functional dependency if and only if for each value of A, there is at most one value of B. A is called the determinant element, while B is called determined element. This relationship is described with the attribute semanticFunction that is the name of a method belonging to the semantic core of the interactive application, such as any method from a class.
- (To reinfor(Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams)ced the systematic design of task models and provide substantial information to support the transformational approach) (Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams) (A sanity check of the AUI model that end in a consolidated version)
- (To reinfor(Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams)ced the systematic design of task models and provide substantial information to support the transformational approach) (Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams) (A sanity check of the AUI model that end in a consolidated version)
- (To reinfor(Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams)ced the systematic design of task models and provide substantial information to support the transformational approach) (Extending the domain of data that was supported to a more abstract set of concepts not just attached to UML class diagrams) (A sanity check of the AUI model that end in a consolidated version)
- In the state of the art we have identify some significant work, and we now have explicit trnaformation accordingly to MDA which was our goal
- Usually, we can say that expected benefits of Model-Driven Engineering (MDE) can be subsumed as follows: 1. Benefits resulting from the existence of a design phase: • Reducing the gap between requirements and implementation: A design phase aims to ensure in advance that the implementation really addresses the customer’s and user’s requirements. • Developer coordination: Previous planning of the developed system enables the developers to coordinate their work e.g. by dividing the system into several parts and defining interfaces between them. • Well-structured systems: A design phase provides explicit planning of the system architecture and the overall code structure. This facilitates implementation itself as well as maintenance. 2. Benefits resulting from the use of visual abstract models: • Planning on adequate level of abstraction: Modeling languages provide the developer concepts for planning and reasoning about the developed system on an adequate level of abstraction. • Improved communication by visual models: The visual character of modeling languages can lead to increased usability (understanding, perceiving, exploring, etc.,) of design documents for both author and other developers. • Validation: (Semi-)Formal modeling languages enable automatic validation of the design. • Documentation: Models can be used as documentation when maintaining the system. • Platform-independence: Platform-independent models can be reused or at least serve as starting point when implementing the system for a different platform. This includes development platforms like a programming language or component model, as well as deployment platforms like the operating system or target devices. 3. Benefits resulting from code generation: • Enhanced productivity: Generating code from a given model requires often only a teeny part of time compared to manual mapping into code. • Expert knowledge can be put into the code generator: Expert knowledge – e.g. on code structuring, code optimizations, or platform-specific features – can once be put into the code generator and then be reused by all developers. • Reduction of errors: Automatic mapping prevents from manual errors. 4. Meta goals: Easier creation and maintenance of development support • Knowledge about creation of modeling languages: MDE concepts and definitions reflect existing knowledge about modeling, modeling languages, and code generation. • Frameworks and tools: Tools like Eclipse Modeling Tools (p. 27) provide sophisticated support for all steps in MDE like creating and processing metamodels, creating modeling editors, and defining and executing transformations. • Maintenance of modeling language and transformations: Systematic and explicit definition of metamodels and transformations facilitates maintenance of modeling languages and code generators. • Reuse of metamodels and transformations: MDE compliant explicit metamodels and transformations can easily be understood and reused by others.