Conceptual User Interface Patterns for Object-Oriented Conceptual

Conceptual User Interface Patterns for Object-Oriented Conceptual Models Oscar Pastor, Emilio Insfran, Vicente Pelechano Departamento de Sistemas Informáticos y Computación Universidad Politécnica de Valencia Camino de Vera s/n E-46022 Valencia (Spain) { opastor | einsfran | pele }@dsic.upv.es Phone + 34 96 387 9359 , fax: (+34) 63877359

Conceptual User Interface Patterns for Object-Oriented Conceptual Models Abstract Specification of user interfaces is not a trivial task and even less if we consider this specification as just an accessory of the conceptual model and not as an important component of it. Conventional object-oriented methods focus on the specification of static and dynamic properties of systems, and few or any techniques are offered to specify the semantic attached to presentation features. In this paper, a set of conceptual user interface patterns is introduced in order to specify essential user interfaces properties. These patterns are identified on the presentation properties of elements of the object-oriented model (attributes, services, arguments, etc.) and extends the information repository collected in the conceptual modeling step preserving the homogeneity of the model. This work was applied to an UML-based object-oriented method for OO software production – OO-Method. Following this approach, and applying a translation process on the extended conceptual model, a complete software product in the target environment can automatically be obtained including the specified user interface. These ideas are implemented in a CASE tool supporting OO-Method and applied to real-world problems in the context of a R&D project between the Valencia University of Technology and Consoft S.A. in Spain. Key Words Interfaces to databases and information systems, Object-oriented methods, User-interface, Patterns, Automatic code generation, Graphic environments

1. Introduction During the last two decades many object-oriented methods have been proposed to deal with the conceptual modeling of information systems [Booch94] [Rumbaugh91] [Coleman94]. These methods provide to analysts with techniques to represent static and dynamic properties of the System under Development (SuD). Following these software development methods, a lot of CASE tools have been developed, many of them syntactically compliant with the UML standard [UML97] and with some code generation capabilities [Platinum97] [Rational98]. Although, the lack of techniques for user interface properties specification, at the same level as the static and dynamic properties specification, is an important weak point of all these approaches. The way in which users perceive and want to interact with the system should be an important component of the system specific ation. In fact, many software implementations fail when they 2

are put into work just because users do not understand their interface (even if they are functionally correct). Normally, the database and the system functionality constitute a precise software representation of a set of requirements captured in an –OO in our case- Conceptual Schema. The user interface should behave in a similar way. Giving a Class Diagram, we have a corresponding Database representation. Following a Process Model, a precise functionality is implemented in the objects at the programming level. Within this context, if a clear Presentation Model is introduced, the attached software representation should be clearly determined. This assertion doesn’t mean that user interface must be static (it should be possible to change the presentation of an application) neither unique (it should be possible to describe many different interfaces depending on the target development environment). But we argue that, in the context of an automated software production process, a ready-to-use, functionally correct interface should be provided. This is what happens with the static and the dynamic systems views, and the presentation view is clearly as important, at least, as this other two system views. In a rigorous conceptual modeling context, specifying only static structure and dynamic behavior is not enough. Problem domain and user interface design are not independent since user interface should be based on the problem domain. Then we also have to include the presentation properties of the desired system. For this reason, in this work the classical conceptual model is enriched with the specification of the relevant interface properties. This enrichment is done keeping the consistency of the conceptual model as a whole. This is a basic feature of the approach that we are going to present: the specification of the presentation properties is done from the OO conceptual model throught a conservative process of expressive enrichment. We mean by conversative that the introduced interface characteristics are clearly specified in the context of precise, preexistent OO conceptual model building units. In this way, the Presentation Model is completely embedded in the Conceptual Schema seen as a whole, what assures its consistency. In this paper we apply the ideas of conceptual user interface specification to an object-oriented method for automatic code generation –OO-Method [Pastor97, 98 & 99]– by incorporating a new model –the Presentation Model. This model collects the relevant presentation properties related to user interfaces from a set of predefined conceptual user interface patterns as we will see in section 3. OO-Method has as main characteristic the fact that starting from a precise conceptual model, that is backed-up by a formal object-oriented specification language –OASIS [Pastor92], a concrete software representation is obtained in an automated way. This is done by implementing the mappings that relate conceptual patterns with their corresponding software representations in the target environment. Adding a Presentation Model to the current OO-Method models we

3

obtain a powerful environment which includes automatic code generation for the static and dynamic properties as well as the specified user interface. The structure of this paper is the following: after this introduction, the main features of the OOMethod will be introduced, focusing specially on the Execution Model that will guide the user interaction with the resultant final software product, obtained in an automated way from the Conceptual Model. Next, the main characteristics of the new Presentation Model of the OOMethod will be presented. The interface patterns considered relevant to describe how the user should interact with the system will be introduced in the problem domain context. The conclusions, further works and references will end this work.

2. The OO-Method Approach OO-Method is an object-oriented method for automatic software generation. Its main phases are shown in Figure 1. Basically, we can distinguish two components: the Conceptual Model and the Execution Model. When dealing with the conceptual modeling step of the SuD, we have to determine the components of the object society without being worried about any implementation considerations. The problem at this level is to obtain a precise and complete system specification. The result of this phase is called Conceptual Model. Conceptual Model Business Model

Presentation Model Conceptual Interface Patterns

Object Model Dynamic Model Functional Model Automatic translation OASIS Repository Automatic translation VC++ RDB

...

Java RDB

...

Prolog OODB

Execution Model Figure. 1. Phases of OO-Method

2.1 The Conceptual Model In OO-Method the Conceptual Model is composed of a Business Model where we specify the static and dynamic properties of the system. OO-Method adopts the well-known OMT strategy1 1

We have preserved the model’s names as in OMT although the similarities are purely syntactic.

4

of dividing the conceptual modeling process into three complementary models (Object, Dynamic and Functional) but using a notation that is compliant with the UML standard. The components of the Business Model are: •

Object Model. It establishes structural and static relationship of the identified classes from the problem domain.

•

Dynamic Model. It is used to specify valid object lives and interobject interaction. To describe valid object lives, we use State Transition Diagrams (STDs, one for each class). To deal with object interaction, we introduce an Object Interaction Diagram (OID, one for the whole System).

•

Functional Model. It is used to capture the semantic attached to changes of state in an easy and an intuitive way.

From the Business Model a formal and object-oriented specification in OASIS [Pastor92] is obtained in an automated way applying an automatic translation process. This formal specification acts as a complete system repository where all the relevant properties of the SuD are included. 2.2 Execution Model Once we have an appropriate system specification, an Execution Model will fix the characteristics of the final software product in terms of user interface, access control, service activation, etc., in short, all the implementation-dependent properties depending on the target implementation environment. According to this Execution Model, an application that is functionally equivalent to the specification is built in an automated way. This may be done in both declarative (Prolog-based) [Canos95] and imperative environments (specially those visual OO programming environments that are currently widely used). At this moment, code generators for Visual C++ [Pastor97], Visual Basic combined with the Microsoft Transaction Server, and Java [Pastor98] have been implemented. Our idea, at this point, is to give an abstract view of an Execution Model that will fix the programming pattern to follow when implementing the conceptual model contents. This Execution Model has three main steps: 1. Access control: the user is logged into the system and identified as a member of the corresponding object society. 2. Object system view: it is the representation of which object attributes and services the user will be allowed to see or activate. 3. Service activation: finally, after being connected and having a clear object system view, the user will be able to activate any available service in his or her worldview. Any service activation is characterized by the following sequence of actions:

5

1. Object identification: the object acting as server has to be identified. The object identifier must be introduced except if we are dealing with the creation event. 2. Introduce event arguments: the arguments of the event being activated must be introduced. Once the message is sent, the service execution is characterized by the occurrence of the following sequence of actions in the server object: 1. Check state transition: verification in the object State Transition Diagram (STD) that a valid transition exists for the selected service in the current object state. 2. Precondition satisfaction: the precondition associated with the service must hold. If 1 or 2 don't hold, an exception will arise and the message is ignored. 3. Valuation fulfillment: the induced event modifications (specified in the Functional Model) take place in the involved object state. 4. Integrity constraint checking (in the new state): to assure that the service execution leads the object to a valid state, the integrity constraints are verified in the final state. If the constraint does not hold, an exception will arise and the previous change of state is ignored. 5. Trigger relationships test: after a valid change of state, the set of condition-action rules that represents the internal system activity is verified. If any of them hold, the specified service will be triggered. The previous steps guide the implementation of any program to assure the functional equivalence among the object system specification collected in the conceptual model and its reification in a programming environment.

3. Patterns for user interface specification in OO-Method 3.1 Presentation Model The Presentation Model extends the Conceptual Model in order to capture concrete HumanComputer Interfaces requirements. The user interface properties collected at problem space level clearly separate the what from the how using a pattern-driven approach. This specification simplifies in a significant way the automatic generation of the application’s user interface and increases its quality. Patterns are easy mechanisms for analysts to detect and supply user interface requirements. 3.2 Capturing User Interface Patterns The set of user interface patterns will describe what kind of information must be gathered in the conceptual model. This information will be used to generate a user interface layer for an application that is automatically obtained following the OO-Method approach. The interface patterns or interaction techniques [Foley82] [Foley90] appear on information systems that offer

6

a user interface. Classifying these interaction techniques in patterns and gathering the associate information we can enrich the Conceptual Model of an information system. According to the execution model presented before, we have 3 kinds of presentation patterns to be declared: those related with step 2 (object system view), those related with step 3 (service activation), and those fixing a generic style guide to precise the set of conventions that will share the whole application from the presentation point of view. In terms of concrete patterns we are going to introduce: 1.- For the object system view step: •

Action Selection Pattern

2.- For the service activation step: •

Introduction Pattern

•

Selection (Defined or Population Selection) Pattern

•

Dependency Pattern

•

Complementary Information Pattern

•

Status Recovery Pattern

3.- A generic style guide, including presentation guidelines for the complete application In next paragraphs we introduce each interface pattern using as an example a conventional library information system.

a) Action Selection Pattern The way the user view and use the system is an important topic to assure the ergonomics of the final user interface. From early command-line interpreters to current WIMP 2 interfaces, the system must show, in some way, all the actions that he or she can activate. In an interactive system [Barfield93], once the user knows what he o she can do, he or she selects an action and executes it. This pattern addresses how to arrange the services of the system in the user interface. Actions can be grouped in order to obtain user menus following several criteria [Foley90]: Hierarchic Organization, Sorting (Alphabetical, Frequency of use or Logic). These criteria may be combined at different deep level in order to conform a balanced and coherent action tree. The resulting action tree has to reproduce the user’s mental image of the system functionality. This pattern is applied on the conceptual schema and defines the action tree that will be shown to the user log into the system and to interact with it. This action tree will be built using the services specified in the system classes of the object model, keeping in this way the whole model consistency. 2

(Window, Icon, M enu, Printer)

7

b) Introduction Pattern If we enter the service activation step of the OO-Method execution model, special properties must be declared for the arguments of the relevant events. With this pattern, we are going to fix this properties. In our library system a return event is declared for the book class. Attached to the event, the list of its arguments is specified. In this case we have the following arguments: reader, book and return_date. From the structural point of view, we have the specific ation of the event (event name and arguments). From the dynamic point of view, the Dynamic and Functional OO-Method models state the correct event behavior. And, from the presentation point of view we have to specify how the user should introduce the correct arguments. The Introduction pattern must address the problem of identifying the pieces of information that the user must provide to describe correctly the interface properties related with the introduction of data for event occurrence. The information related to this pattern is the following: •

Alias

Visible label in user interface.

•

Edit Mask

Disallows the introduction of invalid data.

•

Value Range

Maximum and minimum values that can be taken.

•

Maximum size

Number of characters allowed for an item.

•

Default value

Initial value.

•

Can be null?

Can the user leave empty the item?

•

Validation message

Message to show the user if the data is wrong.

The basic idea is that the presentation modeling is linked to conceptual modeling by specifying for every argument of an event, the visual properties attached to the introduction of data for arguments while executing the event. Alternatively, we can attach this pattern to any attribute of the class in such a way that any argument of an event associated with this attribute will Figure. 2. Introduction Pattern

use this attached pattern. Figure 1

shows the template to specify the Introduction Pattern for the argument return_date.

8

c) Selection Patterns Another type of user input interaction is selection. It is characterized by a subset of data that the user can select from a given set. Following our line of argument, it is not enough to declare the event arguments in the object model. It is necessary to indicate –if this is the case- which are the right values that the event actor can select in the context of an event argument (remember that we are specifying patterns in the context of the service execution step, for all the involved service arguments). We can distinguish two kinds of selection: single selection (the user is allowed to select an item) or multiple selection (the user is allowed to select more that one item). Depending on the nature of the selection set, two new subtypes of selection appear: Defined Selection and Population Selection. •

Defined Selection Pattern

The selection set is a fixed subset in a given domain. The analyst knows this fixed subset at analysis time. In this way, the user interface restricts the user interactions limiting them only to the valid ones. Continuing with the previous example, when the librarian needs to register a new book in the library, he or she has to provide the arguments for the create service on the book class. One of the arguments corresponds to the type of the book. The attribute type in the class book has a fixed set of values, which are: Book, Magazine and Newspaper. The information related to this pattern is the following: •

Alias

Visible label in user interface.

•

Selection Set

Enumeration of the valid entries.

•

Default value

Initial value.

•

Minimum selection

If zero: the item can be null.

•

Maximum selection

If one: single selection.

•

Validation message

Message to show the user if the data selected is not

valid.

9

Figure. 3. Defined selection pattern

• Population Selection Pattern The second type of selection is based on a dynamic subset. In OO models, we often need to select an object from a well-known class but the object identity is unknown at analysis time. In these situations the analyst cannot fix the subset at analysis time. The subset itself is dynamic by its own nature and cannot be fixed. However, the analyst can provide the source of the set and filter-criteria to facilitate the searching. For example, the librarian needs to select a reader in order to return a book. The reader is here modeled as an instance of the class Reader. Population Selection Pattern is applicable to arguments requesting object references. This pattern is composed of a display set and a filter. The display set contains what attributes will be shown for each object and the order among these attributes. The filter is a logic condition built using the class attributes that restricts the population class. Without filter, the selection set is equals to the population of the class. But, applying a filter, the selection set is then restrained to the objects that fulfil the condition settled by the filter. We can apply several population patterns to arguments requesting objects. By this way, we provide a powerful mechanism to search and select instances of objects.

d) Dependency Pattern The arguments involved in an event execution are not independent. Often, depending on the value that an argument has, others argument’s values are constrained. To specify such a dependency this pattern is introduced. Coming back to the example, the librarian has to catalogue every new book or magazine in the library. Depending of the type of publication, he or she has to provide ISBN for type book, or ISSN for type periodic publications. This is a common example of dependency pattern. As we have quoted before, input data items provided by users are not always independent of each other. The values taken by some items may determine the values or constraint the possible

10

values in others items. The user interface must take into account these restrictions, leading the user during the introduction of data in order to minimize user mistakes. To gather this type of pattern the analyst must provide a set of dependency rules that apply on the service that is working on. A dependency rule is an ECA3 rule evaluated in Abstract Interface Objects (AIO4 ) [Bodart94][Bodart96]. These AIOs represents the service arguments and act as a mediator between systems and final users. The example could be described as follows:

On Event type.SetValue() If type.value=”Book” then isbn.active=true , issn.active=false , issn.value=”” If type.value=”Magazine” then issn.active=true , isbn.active=false , isbn.value=””

Type, isbn and issn are the AIOs that represent the arguments of the same name in the create service of class Book. This type of rules allow to express a large amount of the dynamic behavior of the user interface without giving details of the appearance of the final interface.

e) Complementary Information Pattern User needs feedback in order to assure that a correct object selection has been made. This pattern deals with the information that must be provided to the user when he or she selects an instance of a class. This information is needed to identify the involved object from a descriptive point of view. In many situations the attributes used to identify an object are not clear enough (i.e. if it is a numeric code) to recognize that the correct object was chosen. Descriptive attributes of the class should be offered as additional feedback in order to assure that the correct object was selected. For instance, the class Reader has a numeric OID that identifies each reader. When a user needs to select a reader, a unique numeric field is not a good output data to the user to assure that he or she is choosing the desired object. In a typical scenario, we should provide more

3

Event - Condition - Action rules with the same semantic as in Active Database Systems.

4

An AIO is an abstraction of the object interface that must be filled by the user to provided data. AIOs correspond to

problem domain. On the other hand CIOs (Concrete Interface Objects) correspond to solution domain, the so-called widgets or controls.

11

feedback. The value of other attributes accessible from the class could be useful to accomplish this kind of task. In this case, the value of the attributes name, surname and address should also be shown when the reader OID is provided, making easier the event execution. This pattern fixes the user feedback that must be provided in response to a selection of an object by the user. Therefore, the pattern must be applied to object-valued arguments of OO-Method services. An instance of the pattern is specified by giving a list (ordered set) of attributes of the involved class. f) Status Recovery Pattern Status Recovery is based on the essence of service execution in OO-Method. Every object involved in a service execution, moves from an initial state to a final state when the postconditions are fulfilled. When the user requires the execution of a service, the user interface shows a form-like request window allowing the user to introduce the values for the service arguments. In the situations where this pattern makes sense, these arguments always can be initially set to the appropriate values. If an argument changes the value of an attribute by direct assignation we can initially set the value of the argument to the current value of the attribute and show it to the user. By this way, the argument acts as a mediator between the user and the object attribute, letting us to show the value of the attribute before the induced change. For example, if we want to change the data associated to a reader, we call the update service on the corresponding reader object. Then, we expect to see a form containing the data that we can modify (the current data values). In this example, the update service has six arguments defined, that are: reader_code, name, surname, address, telephone and email. The class Reader is identified by the integer attribute reader_code. If the user provides a valid reader_code, the system can fill the others arguments with the current values of the object (name, surname, address, telephone and email) and show them to the user. Finally, the user is allowed to send the event with all the arguments (some of them maybe modified) or to cancel the event execution. The conceptual model has all the necessary information for this pattern. The functional model of OO-Method relates event arguments to the corresponding object attributes that are changed with the previous arguments. For this reason, this pattern is defined as an implicit pattern in OOMethod.

g) A Style Guide To complete this presentation, it is important to introduce the generic appearance that an application will have from the user point if view. Even if in this case we are not facing a

12

concrete pattern of presentation, it is widely accepted that the user interface obtained from the specified conceptual model must follow a set of conventions fixed by the selected platform at the solution domain level, such as the arrangement of graphical components in a screen, error or help messages, reports format, etc.. Depending on the target platform (Windows, X11, Java), there are guidelines that must be followed in each environment. These guidelines are style guides that fix ergonomics aspects that every application should follow in order to assure the easy-of-use and consistency with the environment. The style guide fix details as the typography, color palette, standard accelerators and shortcuts, controls, error formats, help messages, etc. Style guides are available for each environment: for Windows an industrial standard is CUA [CUA89], for X11 it exists style guides for Motif, CDE, KDE and Gnome environments and Swing Style Guide for Java. Although there are guidelines to create reports and standards of presentation these guidelines cannot be generalized in the same way that we have made with input interaction techniques. The following problems must be taken into account: •

In two different presentations of the same information one can be more useful than the other.

•

Another problem is related with the psychology of users: a kind of presentation can be better to some users whereas other users could prefer another.

Keeping in mind these problems, every final software software must have its own guidelines in addition to the set of patterns that we have introduced in the previous sections. OO-Method does not require the use of any particular set of guidelines but stresses the necessity of having one as the basis of any human-computer interaction for real-world applications.

4. Conclusions In this paper, the OO-Method software production method has been enriched with a Presentation Model where the user-interface properties considered relevant are introduced as another component of a Conceptual Schema specification. OO-Method generates a software product that, starting from the Conceptual Model (what we have called Business Model in this paper), generates a final software product representing properly the conceptual patterns into their corresponding software representations. This product is functionally complete (i.e. it includes all the functionality specified in the Conceptual Model) but did not treat presentation features till now. Taking into account that the computer representation (final software product) should be closer to the idea of the world the user has in mind, the main contribution of the presented approach is to consider that the user-interface specification must be an important part of the Conceptual Modeling phase, and not only a final adornment faced in the solution space notation.

13

In this way, another important advantage is that the users can participate in the project from the very beginning, when the Conceptual Model is being constructed. The Execution Model provided by OO-Method fixes the way in which users will perceive the system, and opens the door to the automated generation of a final product including not only structure and behavior, but also the user-interface. This is done by introducing through the corresponding so-called interface patterns, the properties needed to state the main interface characteristics in a declarative way. These ideas have been implemented in a CASE tool supporting OO-Method, and are being applied at the moment in non-trivial real-world problems. Even if we accept that to generate a final product including user-interface can be considered an utopia due to its dependency on the users expectations, what we address with this work is to provide in an automated way a user-interface reasonably adequate to be directly put into work. Current work is strongly focused on the treatment of the user-interface patterns, trying to define a catalogue of them including only those really needed for obtaining a usable and friendly system.

5. References [Barfield93] Lon Barfield. The User Interface. Concepts & Design. Addison-Wesley 1993. [Bodart94] Bodart F.; Hennebert A.M.; Leheureux J.M.; Provot I.;Vanderdonckt J. A Model-based Approach to Presentation: A Continuum from Task Analysis to Prototype. Proceedings of the Eurographics Workshop on Design, Specification, Verification of Interactive Systems. Carrara, Italy, June 1994, Focus on Computer Graphics, Springer-Verlag, Berlin, pp.77-94 [Bodart96] Bodart F., Vanderdonckt J. Widget Standardisation through Abstract Interaction Objects. Institut d’Informatique, Facultés Universitaires Notre-Dame de la Paix. Namur, Belgium. 1996. [Booch94] Booch G. OO Analysis and Design with Applications. Addison-Wesley, 1994. [Coleman94] Coleman D.; Arnold P.; Bodoff S.; Dollin S.; Gilchrist H.; Hayes F.; Jeremaes P. Object-Oriented Development. The Fusion Method. Prentice-Hall 1994. [Canos95] Canós J.H.; Penadés M.C.; Ramos I. A Knowdledge-Based Arquitecture for Object Societies. In Proceedings of the 6th Internatinal Conference on Database and Expert Systems Applications DEXA-95 (Workshop), pp: 18-25, London, 1995. [CUA89] Common User Access, Advanced Interface Design Guide. IBM, 1989. [Foley82] Foley J., Van Dam A. Fundamental of Interactive Computer Graphics. Chapter 6, The Design of User Computer Graphics Conversation. pp: 217-244, Addison-Wesley. 1982. [Foley90] Foley J., Wallace V., Chan P. Human-Computer Interaction. Chapter 4, The Human Factors of Computer Graphics Interaction Techniques. pp: 67-121, British Open University, Prentice Hall. 1990. [Pastor92]] Pastor O., Hayes F., Bear S. OASIS: An OO Specification Language. Proceedings of the 4th International Conference on Advanced Information Systems Engineering (CAiSE-92), Lecture Notes in Computer Science (593), Springer-Verlag 1992, pp: 348-363.

14

[Pastor97] Pastor O.; Insfran E.; Pelechano V.; Romero J.; Merseguer J. OO-METHOD: An OO Software Production Environment Combining Conventional and Formal Methods. Proceedings of the 9th International Conference on Advanced Information Systems Engineering (CAiSE’97), Barcelona, Spain. (1250) Springer-Verlag, pp: 145-159. [Pastor98] Pastor O.; Insfran E.; Pelechano V.; Gómez J. From Object Oriented Conceptual Modeling to Automated Programming in Java. Proceedings of the 17th International Conference on Conceptual Modeling (ER'98), Singapore, 1998. Lecture Notes in Computer Science (1507), Springer-Verlag pp: 183-197. [Pastor99] Pastor O.; Canos J.H., Ramos I. From CASE to CARE (Computer-Aided Requirements Engineering).

Proceedings of the 18th International Conference on Conceptual Modeling (ER'99),

Paris, 1999. Lecture Notes in Computer Science (1728), Springer-Verlag, pp: 278-293. [Platinum97] Platinum Technology, Inc., Paradigm Plus: Round-Trip Engineering for JAVA, White Paper. 1997. [Rational98] Rational Software Corporation. Rational Rose User's Manual. 1998. [Rumbaugh91] Rumbaugh J. et al. W. Object Oriented Modeling and Design. Englewood Cliffs, Nj. Prentice-Hall. 1991. [UML97]] Booch G.; Rumbaugh J.; Jacobson I. Unified Modeling Language. Version 1.0 January 1997. Rational Software Corporation.

15