Object-Oriented Development of Interactive Systems with OMT++

Juha-Markus Aalto and Ari Jaaksi Nokia Telecommunications, Cellular Systems Mobile Switching, Network Management Systems Hatanpnvaltatie 36 B, 33100 Tampere, Finland juha-markus.aalto@ntc.nokia.com, ari.jaaksi@ntc.nokia.com

Abstract This paper presents the OMT++ methodology that provides an object-oriented approach for building graphical applications applying the paradigm based on the MVC approach. All the phases of system development from analysis to implementation are covered. OMT++ aims at getting the specification, design, and implementation correct at the outset. Iteration is reduced and maintainability of documentation is improved by delaying the decisions to the points where all essential information is available. This paper also presents a notation for specifying user interfaces. This notation makes the systematic specification of user interfaces possible, thereby decreasing the need of prototyping. This approach provides means for analyzing the user interface in order to detect problems in usability as early as possible. This approach also supports the design of reusable interface components. According to OMT++, applications are constructed from software components which each have a specific purpose and behavior. To enable the reuse of these components, we introduce a mechanism called 'abstract partner' to facilitate the implementation in C++. In R.Ege, M.Singh, B.Meyer, editors, TOOLS 14, Technology of Object-Oriented Languages & Systems, 205-218. Prentice Hall, 1994.

OMT++ is being applied in the development of a large network management system having over one million lines of C++ code running in X11 environment. 1. Introduction Object-oriented software development methods are either too general, or they do not cover the whole software process. We were not able to find any method that fulfilled our requirements for the development of large systems. In particular, we needed industrial-strength practices for the specification, design and implementation of graphical user interfaces. OMT++ was created to fulfill these requirements. It is an object-oriented software development methodology which provides a continuous path for the specification, design and implementation of applications. We use object modeling in order to understand the problem domain, and then specify the behavior of the application. OMT++ includes notation and practices for user interface specification. The design is based on the Model-View-Controller (MVC) paradigm [Krasner et al. 88], which we have adapted to C++ and to our specification process. Applications are constructed from reusable software components that each have a specific purpose and behavior. The predecessor of OMT++, OMT+ [Kuusela et al. 93], is an object-oriented software development methodology developed by Nokia Research Center and Nokia Telecommunications, Cellular Systems (NCS). OMT+ is based on OMT [Rumbaugh et al. 91], Fusion [Coleman et al. 94] and OOSE

CUSTOMER REQUIREMENTS

OOA

Object Analysis

Behavior Analysis

User Interface Specification

Analysis Object Model

Operation Specifications

Dialog Diagrams

Component Specifications

OOD

Object Design

Behavior Design

Design Object Model

Event Traces

State Machines

OOP

Class Specification

Class Implementation

Class Declarations

Implementation of Methods

Fig. 1: OMT++ Process [Jacobson et al. 92], and it provides a solid software process using the modeling facilities of OMT and Fusion. OMT++ is a superset of OMT+, extended with practices for the development of user interfaces (hereafter UI), database management, and communication solutions. It is now in operational use in our software production unit, which develops one of the leading network management systems, the Nokia OMC, for the digital GSM/DCS 1800 networks. The development is carried out using UNIX workstations, X Windows, OSF/Motif and C++ programming language. 2. Overview of OMT++ The applications that are designed by means of OMT++ are larger than textbook examples; they have graphical user interfaces, they communicate, and they also have persistent objects. Due to the huge size of the applications, the development process model must scale up [Aalto 93]. We have put a lot of effort in considering the artifacts produced in each phase in order to streamline the process. We have eliminated unnecessary diagrams which do not add value to the product, and delayed design decisions until there is enough information to make them "right" at the first time. Figure 1 illustrates the software development process by means of OMT++. The whole OMT++ process transforms customer requirements to program code. The process model specifies the artifacts, and includes guidelines for all phases from analysis through design to programming. Although we apply the objectoriented approach, we do not concentrate on objects only; we emphasize the specification of the behavior of applications. We use the analysis object model as a tool to clarify the key concepts of the problem domain and the relationships of these concepts. We carry out the behavior analysis in parallel with the object analysis. Once the complete list of end user operations and the analysis object model are available, we define each operation using the concepts of the analysis object model.

Unlike most object-oriented development methods, e.g., OMT, OOSE and Fusion, OMT++ includes detailed procedures for the specification and design of user interfaces. In OMT++, the specification of the structure of the user interface and the visualization of the user interface are done after the object analysis and behavior analysis have been completed. The operation specifications define the requirements for the functionality, and the analysis object model determines the data that is to be included in the user interface. The designer's task is to design the user interface so that it fulfills the usability requirements and provides a user friendly access to the objects presented in the object model. The design process is divided into two stages: designing of the structure of the application, and specifying the way how the behavior is implemented in that structure. The structure of applications is based on the analysis object model and the Model-View-Controller (MVC) paradigm [Krasner et al. 88]. The design object model is obtained directly from the analysis model using the guidelines of OMT++. Thus, we have a completely seamless transition from analysis to implementation. We define the behavior of the application in terms of the event traces and state machines. Event traces characterize the interaction of objects, and state machines define the internal behavior of objects. The class declarations are written in C++ according to the design object model. The class operations are specified according to the information provided by event traces and state machines. Part of the code for the class declarations and implementation of methods can be generated by automatic generators such as user interface builders. 3. Object Analysis The purpose of analysis is to obtain an understanding of the application [Jacobson et al. 92]; to understand user requirements and the problem to be solved. To facilitate communication in the analysis phase, we build models that highlight the most important issues of the problem domain and hide any unnecessary details. The

strength of object modeling is that it emphasizes the key concepts which are believed to be stable. It is of vital importance that we understand what these key concepts are, what they mean, and how they are related. Based on these entities, i.e., the objects, we build our future applications. The object analysis process produces an analysis object model that documents the key concepts and their relations. In OMT++, we use the object modeling notation of OMT as it is. However, OMT as described in [Rumbaugh et al. 91] concentrates mainly on the modeling technique; it does not define precisely what kind of object classes should be included in the analysis object model. In particular, it does not give an answer to the commonly asked question: How should we model the user interface objects in the object model? Let us assume that we have a Bank Terminal application that provides the customer with the means for settling bills and checking the balance of his accounts through a terminal connection. The relations of the concepts 'User', 'Creditor', 'Bank', 'Account', 'Bill', and 'Terminal Connection' are illustrated in figure 2.
Person name

User banks-at Terminal Connection has settles

Creditor sends

belongs-to

Bank

Account balance number

drawn-on-by settled-to-by

Bill amount code

Fig. 2: An object model for the Bank Terminal application The graphical user interfaces consist of UI objects such as push buttons and windows. How should we deal with these objects? Should we inherit an 'AccountUI' object class from the 'Account' class and add it to the object model? Or should we add user interface operations to the 'Account' class? Some of these very fundamental questions have not been answered by OMT, for instance.

Description: Assumes: Result: Scenario:

Settling a bill. Account.balance > Bill.amount Bill is settled and the User's Account.balance is decreased and Creditor's Account.balance increased by Bill.amount.
User
settle bill decrease Account.balance increase Account.balance

Bank Terminal

Creditor

Exceptions:

illegal Account, not enough money in user's Account

Fig. 3: Simplified operation specification for the operation of settling a bill OMT++ provides answers to these questions in the form of the following two rules that are designed for building the analysis object model: 1. Implementation issues shall not be presented in the analysis object model. For instance, the class operations are defined in the design phase. 2. User interface elements shall not be included in the object model since they are tied to the functionality and they are thus likely to change frequently. Instead, the connection between the user and the application is modeled by a class that represents the end user. The analysis object models in OMT++ are similar to the one presented in figure 2. In addition to the two main rules mentioned above, we have defined a set of rules for the documentation of the object model. We have also adopted the concept of system boundary from Fusion [Coleman et al. 94] in order to highlight system interfaces (see the dotted line in figure 2). 4. Behavior Analysis Although we want to use an object-oriented approach to software development, we must not forget that it is the functionality of the application that the customers pay for, not the objects. Therefore we must not disregard the specification of the behavior of the system. In this respect, our approach resembles the use case approach of OOSE [Jacobson et al. 92], although we deal with the user interface in a different way. After the object analysis has been carried out, we understand the key concepts of the problem domain and the information related to these concepts. The next step is to define the user operations for the manipulation of the information that we have obtained. In OMT++, we specify user operations first without any user interface details. The first task in the behavior analysis phase is to identify a list of the operations that the user carries out with the application. This list should explain why the application exists, and what tasks the user performs with the application. The list is built in parallel with the object analysis. After that we document each operation as in the example depicted in figure 3. The basic structure of the specifications has been adopted from Fusion [Coleman et al. 94], but we have simplified the specifications, and added the use of event traces with the definition of exceptions. All operations are defined using the vocabulary provided by the class names of the object model. In this way we ensure that the operation specifications and the object model are consistent. It is worth noting that, unlike OMT, we do not use data flow diagrams for the specification of the functionality, because this easily leads to the design of algorithms. Instead, we define only the results and the preconditions. Now that we know what kind of functionality is required, we can start designing how to provide this functionality to the user.

The End User manipulation feedback mental models

The User Interface requests responses

The Application

ok

cancel

Fig. 4: The user interface as an intermediate entity 5. User Interface Specification 5.1.The User Interface The user interface is seen as an intermediate entity between the end user and the application itself. The user interface must therefore be capable of communicating with both the end user and the application as depicted in figure 4. When in contact with the user interface, the end user uses mental models to describe, explain and predict the behavior of the system [Norman 83, Waern 89]. Mental models are representations of the reality, and they explain the objects and associations of the reality. An ideal mental model is accurate and sufficiently correct that the end user can solve problems, operate the system and learn more about it. In order to help the end user to tune his mental models, every meaningful manipulative action should provide immediate perceivable visual feedback. By operating and perceiving, the end user can reinforce and change his mental models towards the ideal ones [Neisser 80]. The user must be able to see the application in terms of metaphors, mental maps or other mental structures. 5.2.Constructing the Structure of the User Interface The main inputs to the user interface specification are derived from the object and behavior analysis. We must specify the user interface so that the end user can complete all the tasks presented in the operation specifications. We organize those tasks into dialogs in such a way that in each dialog the user can complete semantically meaningful tasks. Let us assume that we have the following user operations: 1. Checking the balance of an account. 2. Selecting an account. At this point we are only interested in the dialogs that form the framework of the user interface. We decide to organize these tasks into two dialogs: the 'Bank terminal' window and the 'Account selection' dialog. OMT++ provides the dialog diagram for modeling this.

start exit Bank terminal do: 1 select an account close

Account selection do: 2

Fig. 5: The dialog diagram of the Bank Terminal application The dialog diagram notation is modified from Harel's state chart notation [Harel 87]. A state stands for a dialog or a window, and an event refers to the selection made by the user. A line inside a dialog indicates the main window, and a 'do:' statement locates user operations into a dialog. A little black box denotes a modeless dialog, so we can see that in the diagram in figure 5, both the 'Bank terminal' window and the 'Account selection' dialog can be operated simultaneously. The dialog diagram thus gives us a visible image of the structure of the graphical user interface at a very early stage of the UI specification.

Dialog / window Bank terminal Account selection

Manipulation Tools -Select an account -Exit -Select an account -Apply an account -Close

Feedback Tools -Show balance -Show selected account -Show possible accounts

Fig. 6: The dialog tool listing 5.3.Defining Components for the Dialogs During the design of the dialog diagrams we also think about the contents of the dialogs and windows. In every dialog the end user must be able to complete at least one meaningful task. Every dialog is made of components. Each component consists of tools, such as push buttons and text fields. The tools are either manipulation tools that the user needs to control the application, or feedback tools that the application needs to present things to the user. The contents for dialogs, such as these in figure 5, are defined according to the operation specifications as illustrated in figure 6. In the following we consider each dialog at a time. We try to find tools that form semantically meaningful sets, i.e. components. For example, in the 'Account selection' dialog we find that the tools 'Select an account' and 'Show possible accounts' (fig. 6) form a component that we may call 'Accounts' (fig. 7). Likewise the tools 'Apply' and 'Close' form a component that we can call 'Dialog Control'. To depict the components of the dialogs, we draw components by using a simple notation: an ellipse stands for a manipulation tool and a rectangle denotes a feedback tool. We have not yet made a decision of the final layout of the user interface. It should be noted that in the final implementation the tools of a component are not necessarily located next to each other. If this is the case, the user interface must provide visual clues, so that the end user can see and understand the connection of these tools.
bank terminal application control exit balance show balance show account number select an account

account selection account selection accounts show possible accounts select an account dialog control apply close

bank terminal

Fig. 7: Component specifications of the Bank Terminal application Figure 7 illustrates how the components are specified. Written explanations about the behavior of the components must be provided. This is exemplified in figure 8. These explanations will guide the final implementation, and they may also indicate possible problems, such as too complicated objects, or objects with no purpose at all. 5.4.Testing and Tuning the User Interface As many problems and errors as possible should be detected at the earliest possible stage. If we detect problems, we may redesign parts of our user interface before starting the implementation. The evaluation of the user interface is based on the dialog diagrams and component specifications. Check lists can be constructed for every phase of the UI specification and cognitive walkthroughs

The end user can select an account by using the The balance is shown. The number of 'select an account' tool. This tool is disabled if only the selected account is shown. one account is available. The first account is selected by default. Accounts The end user can select a single account. The first All possible accounts are listed. The account is selected by default. selection is shown. Dialog Control The end user may inform the application about his 'Apply' affects the balance component selection by using the 'apply' tool. He can close the in the 'Bank Terminal' window. dialog by using the 'close' -tool. Fig. 8: Definition of the behavior of the UI components in the Bank Terminal application [Polson et al. 92] can be made. This approach reduces iteration and helps us detect problems in usability early without expensive prototyping or massive field tests. 5.5.Visualization of the User Interface The last phase in the user interface specification is the visualization phase, the output of which is illustrated in figure 9. In this phase we can use a GUI builder such as X-Designer [IST 93] in order to construct the final layout and implement simple prototypes. If we started directly from this phase, we would more likely forget the most important main lines and concentrate on less meaningful details. In the top-down UI specification approach of OMT++, the visual design is carried out as the last step of the specification process. Visualization can only be done well if the preceding steps are completed properly. By thoroughly designing all dialogs and UI components, we gather up a library of highly reusable interface elements.

Component Application Control Balance

Manipulation The end user may exit the application.

Feedback -

Fig. 9: Visualized user interface

6. Object Design 6.1.The MVC Concept There have been attempts to create a standardized separation of the user interface and the rest of the application, such as the Seeheim model [Green 85], its extensions, such as in [Ege et al. 91], the PAC (Presentation-Abstraction-Control) model [Coutaz 87] and the MVC (Model-View-Controller) model [Krasner et al. 88]. In practice, difficulties have occurred, and the role and separation of the parts has been unclear. In OMT++, we have adopted the terminology of the MVC model, but the implementation differs e.g. from the one presented in [Krasner et al. 88]. We present a strict division of labor and define precisely what classes and methods are needed in each part of an application. In OMT++, there is a well-defined role for each part of an MVC application. The model represents "the real world" and it is based on the analysis object model. The model is managed by the controller, and the model is not "aware" of the view. The view is the outer layer which is visible to the end user, and it is created by the controller. The view contains the UI components and callback functions. It knows how to present things to the end user, and how to receive user's actions. The view does not decide how to respond to the user's actions; it passes them to the controller. The controller makes all the application-specific decisions, and knows how this application should work. The controller thus integrates the model and the view in an application-specific way.
Feedback

we implement the applications in C++ instead of Smalltalk, we do not have any run-time assistance for managing the connections between objects. In OMT++, our aim is to make each part of the MVC triad as independent and as reusable as possible by supporting a strict division of labor and implementing a minimal set of connections. Each part of the MVC triad is typically made of several classes. There is always one main controller class. This is typically the controller of the main view class, which forms the main window such as the 'Bank terminal' window in figure 5. The main controller class also controls other controller classes. The communication between the parts of an MVC application is characterized in figure 11.
Main View Object a Main Controller Object e b Model Objects (= the bank) b c d Account Selection Controller Object Account Selection View Object a c

Fig. 11: An MVC application with two view objects; the controller controls the view (a) and the model (b). The view pass the end user's actions to the controller (c). The main controller controls the other controller object (e), which communicates with the main controller (d). There are three main categories of methods in a view class: manipulation methods (MM, callback methods associated with widgets) are used capture the user's actions, feedback methods (FM) present things to the end user, and query methods (QM) are designed for the controller to investigate the state of the view. A typical method of a controller class has two parts; first the controller makes the model act, and then it asks the view to present the results. The controller knows what the view and the model are capable of doing, but it never knows how things are done inside the model and the view. The methods of model classes typically have counterparts in the real world that was modeled.

Action requests

Results

Interpreted actions Manipulation

Decisions

Action requests

View

Controller

Model

Fig. 10: An MVC application developed according to OMT++ Unlike the MVC approach presented in [Krasner et al. 88], there is no direct connection between the model and the view as depicted in figure 10. Since

6.2.Design of Model Classes The model class design produces the basis for the design object model as depicted in figure 12. Model classes are obtained directly from the analysis object model. The design of the model classes starts by transforming the analysis object model to the basis for the design object model. The construction of the model consists of three main phases: 1. Identification of persistent and transient classes. We go through each class and consider whether we have to design the database implementation for the class, or whether we have a class that is to be implemented with transient data structures. 2. Design of system interface classes. We consider each of the classes that are outside the system boundary (such as Terminal Connection in fig. 2), in order to determine whether we need a counterpart for them in the object model. The classes that represent the user are typically replaced by the view and controller classes that comprise the user interface. 3. Object model refinement. We refine the object model according to the requirements set by the controller class design and the optimization of data access paths.
Account balance number drawn-on-by settled-to-by Bill amount code

'accounts' (fig. 7) is available. The 'account selection' view of the dialog found in figure 5 is illustrated in figure 13.
accountsVC

accountSelectionView

Fig. 13: The account selection view class and a view component (VC) 6.4. Design of Controller Classes There is a single controller class for every view class. Controller classes are connected to view and model classes as in figure 14. The controller may have relations with multiple model classes; on the other hand, the same model may be connected to multiple controllers.
accountsVC

mainView

accountSelection View

View Classes

main Controller

accountSelection Controller

Controller Classes

is-used-by Account Bank balance number drawn-on-by settled-to-by Bill amount code

Model Classes

Fig. 14: Classes of the Bank Terminal application 7. Behavior Design 7.1.Finding the Operations for the Classes The main problem in the design of the class interfaces is finding the operations for the classes. We have successfully applied the use of event traces for this purpose. We design the class interfaces by drawing event traces for each operation of the application. The participants of the event traces are the classes of the design object model. When we have drawn the event traces, we can pick the operations for each class by examining the messages (method calls) they receive. A similar approach has been adopted in the OOSE methodology [Jacobson et al. 92].

Bank

Fig. 12: The model; a bank with multiple accounts 6.3.Design of View Classes Typically, every dialog of the dialog diagram (fig. 5) forms a view class. If a dialog is extremely simple, we may sometimes want to join it with another view class and call it a view component. A view component can be either a dialog or a UI component that forms an independent class and does not have a controller of its own. Each view class contains the components that have been specified in the user interface specification phase. Our intentions is to make components of the dialogs reusable. By doing so, we can construct views from components, instead of separate UI tools. Let us suppose that the view component class

User

accountSelection View
State: Visible

account VC

accountSelection Controller

main Controller

bank

account

main View

ApplyPressedMM() GetSelectedQM() nbr AccountSelected(nbr) AccountSelected(nbr) GetBalance(nbr) GetBalance() balance balance ShowBalanceFM(nbr, balance)

Fig. 15: An event trace for the operation 'Show balance for the account' From the event trace presented in figure 15 we can see, for instance, that the class 'bank' needs to have an operation 'GetBalance' with argument 'nbr' (account number) to satisfy our design. For classes with complex dynamic behavior we build state machines using Harel's state chart formalism [Harel 87]. State machines capture the dynamic behavior of the objects of a class, and they can be constructed from event trace diagrams. An advantage with this kind of use of event traces and state machines is that there is no need to invent any operations from scratch; all operations are the result of a systematic design process. 7.2.Model Operations For each model class we define a set of standard operations such as 'Get', 'Set', 'Query', and 'Destroy'. The rest of the operations come from event traces as depicted above. Typically, the model classes are highly reusable. Therefore a suitable operation for a class may already exist. We always need to check the existing operations of a class before we define operations for our own needs. 7.3.View Operations We get the skeleton for the view class directly from the UI component specifications (fig. 5 and 7). The view operations are either manipulation, feedback or query methods as in figure 16. The methods are obtained from the event traces (fig. 15) and from the definitions of behavior of the UI components (fig. 8).
accountSelectionView applyButton closeButton ApplyPressedMM ClosePressedMM ShowAccountsFM(nbrs) accountsVC accountList GetSelectedQM : nbr ShowAllFM(nbrs)

Fig. 16: The account selection view classes 7.4.Controller Operations The controller gets the interpreted actions of the end user from the view. Typically, every manipulation method of the view, such as 'ClosePressedMM()', has a corresponding method of the controller, such as 'DialogCloseAsked()'. The view interprets user's actions such as the pressing of a button, and tells what the user has desired by calling the methods of the controller such as 'AccountSelected()'. Then the controller decides upon the necessary actions and makes the model classes perform these actions. After that, the controller asks the view to update itself accordingly. The methods which are capable of receiving interpreted actions from the view are added to the controller classes, as illustrated in figure 17.
accountSelectionView applyButton closeButton ApplyPressedMM ClosePressedMM ShowAccountsFM(nbrs) accountsVC accountList GetSelectedQM : nbr ShowAllFM(nbrs)

accountSelectionController AccountSelected (nbr) DialogCloseAsked

Fig. 17: The account selection controller and the view

10

is-used-by

uses

Main View Abstract Main View Partner Abstract Controller Partner Main Controller

Some View Abstract Some View Partner

is-used-by

Some Controller

Model

is-used-by

Fig. 19: C++ implementation of an MVC application. The abstract partners describe what is expected from the users. Answers to those expectations are finally implemented in the classes that inherit those abstract partners. 8. Mapping the Design into C++ 8.1.Abstract Partners The MVC approach of OMT++ strongly supports reusable view classes. The views should be designed so that they can be used by another controller. This allows us to change the behavior connected to a view by changing the controller only. As one can see in figure 17, since the controller has the view as an object member, it may directly call the public methods of the view. However, the view also needs to call the methods of the controller in order to pass the user's requests to the application. Let us take an example. When the user presses the 'Apply' button in our 'Account dialog' example, the controller must have methods to handle this. In order to make reusable view classes, we cannot use static binding here. view class and inherited by a controller class. When the view wants to call a method of the controller, the view calls a pure virtual method of the abstract view partner class (e.g. accountSelectionAbsVP-> AccountSelected(nbr)). Any controller that wants to use the view must inherit its abstract view partner and implement the abstract methods as illustrated in figure 18.
accountsVC accountList GetSelectedQM : nbr ShowAllFM(nbrs)

is-used-by accountSelectionAbsVP AccountSelected(nbr) {abstract} DialogCloseAsked {abstract}

accountSelectionView applyButton closeButton ApplyPressedMM ClosePressedMM ShowAccountsFM(nbrs)

accountSelectionController

At this stage in our example we implement the view, but we do not know what the controlling controller is. Therefore we cannot write lines such as accountSelectionController-> AccountSelected(nbr) in a method of the view class in figure 17. In order to circumvent this, we introduce a new concept: an abstract partner. We must create an abstract view partner to describe what the view expects from the controller. The abstract view partner is a C++ class that contains only pure virtual methods; it is used by a

AccountSelected(nbr) DialogCloseAsked

Fig. 18: Figure 17 with the abstract view partner. (In a complete example there could also be a view partner between the accounts view component and the account selection view. For the sake of simplicity, they are excluded from this figure.) A similar partnership exists between the view and the view component, as well as the main controller

11

and other controllers. The main controller can directly call the methods of any subcontroller, but abstract controller partners are used to explain what the subcontroller expects from the main controller. The subcontroller calls the main controller through the abstract controller partner. By using abstract partners we can create reusable M, V, VC and MVC collections that can be connected with any future application. This is illustrated in figure 19.

9. Conclusions In this paper we have shown how the objectoriented approach of OMT++ can benefit the designer of interactive systems. OMT++ includes detailed procedures for all the phases of system development. It provides a continuous path from customer requirements to C++ code, and it is successfully used in the development of a large network management system. The separation of the user interface in analysis, design and programming phases has a number of advantages. Customers' requirements are better met when we first understand what the user operations are, before we begin designing the user interface. This decreases the need for iteration in the software process. Our approach for the user interface specification also decreases the need for iteration and prototyping. The usability of the user interface can be evaluated on the basis of the UI specifications. Our approach facilitates the compiling of the library of high quality user interface components. Our implementation of the MVC approach provides powerful tools for the reuse of software components. Applications are made of parts that each have their own role and behavior. That makes the software robust for changes and easy to comprehend. All the benefits of the MVC approach can be obtained in a standard C++ environment. We do appreciate that certain aspects of OMT++ such as the complexity of the process still need to be improved. Although we have streamlined the process model and the use of the modeling notations, the institutionalization of OMT++ is a time-consuming task. In addition, the objectoriented CASE tool technology is finally maturing and our aim is to convert our design rules to a format understood by the computer.

8.2.Class Specification and Implementation The C++ class declarations are written according to the design object model, and the methods are implemented as illustrated in figures 20 and 21. The methods of the view classes are typically fairly simple, as in figure 20. The constructor creates the link between the view and the controller. It also creates all the view components. Manipulation methods (MM) are callback methods that are associated with tools, such as widgets. They capture and interpret the end user's actions, and forward these actions to the controller through an abstract view partner. Feedback methods (FM) are used by the controller. They affect the tools of the dialog by e.g. writing or drawing on them. Figure 21 illustrates the 'account selection' controller. Because the 'account selection' controller is not the main controller, it needs to use the main controller through the abstract controller partner by means of dynamic binding. We write abstract partners above class declarations as illustrated in figure 20. This is how we also document what is expected from controller classes. The constructor of the controller class creates the view. It also sets links to the main controller and the model classes. A typical method of the controller, such as AccountSelected() in figure 21, makes the model act, and then tells the result to the view and the main controller.

12

class accountSelectionAbsVP { public: virtual void AccountSelected(char *accNbr) = 0; virtual void DialogCloseAsked() = 0; }; class accountSelectionView { public: accountSelectionVie w(accountSelectionAbsVP *vPartner) { viewPartner = vPartner; accountsViewComponent = new accountsVC(); } void ShowAccountsFM(char **accNbrs, int count) { accountsViewComponent->ShowAllFM(accNbrs, count); } private: void ApplyPressedMM() { viewPartner->AccountSelected(accountsViewComponent->GetSelectedQM()); } void ClosePressedMM() { viewPartner->DialogCloseAsked(); } accountSelectionAbsVP *viewPartner; accountsVC *accountsViewComponent ; Widget applyButton; // a tool Widget closeButton; // a tool };

Fig. 20: Declaration and implementation of a view class

class accountSelectionController : public accountSelectionAbsVP { public: accountSelectionController(accountSelectionAbsCP *cntrlPartner, bank *crrntBank) { view = new accountSelectionView( this ); controllerPartner = cntrlPartner; currentBank = crrntBank; char **accNbrs = 0; int count = bank->GetAccountNbrs(accNbrs); view ->ShowAccountsFM( accNbrs, count ); } void AccountSelected(char *accNbr ) { error err; err = bank->TestAccount(accNbr); if (!err) controllerPartner->AccountSelected(accNbr); else view->ShowErrorFM(err); } void DialogCloseAsked() { view->Hide(); } private: accountSelectionView *view; accountSelectionAbsCP *controllerPartner; bank *currentBank; };

Fig. 21: Declaration and implementation of a controller class

13

10.Acknowledgments This paper has been reviewed by Ilkka Haikala, Reino Kurki-Suonio and Kari Syst from the Tampere University of Technology and by Ari Aalto, Pasi Rajala, Tim Rowe and Eija Tervonen from our own organization. We would like to thank them all for their valuable comments on earlier versions of this paper. 11. References
[Aalto 93] J-M. Aalto. Experiences on Applying OMT to Large Scale Systems. Conceptual Modeling and Object-Oriented Programming Symposium, November 5, 1993, Tampere, Finland. Finnish Artificial Intelligence Society, 1993. D. Coleman, P. Arnold, S. Bodoff, C. Dollin, H. Gilchrist, F. Hayes, P.Jeremaes. The Fusion Object-Oriented Analysis and Design Method. Prentice Hall, 1994. J. Coutaz. PAC, an Object Oriented Model for Dialog Design. In H.J. Bullinger, B.Shackel, editors, HumanComputer Interaction INTERACT '87, pages 431-436. Elsevier Science Publishers, 1987. K.E. Ege, C.Stary. Task and Object-Oriented User Interface Spesification. In M.I. Nurminen, P. Jrvinen, G. Weir, editors, Proceedings of Human Jobs and Computer Interfaces Conference, pages 223-237. University of Tampere, Finland, 1991. M. Green. Report on Dialog Specification Tools. In Gunther E. Pfaff, editor, Workshop on User Interface Management Systems, pages 9-20. Springler Verlag, 1985.

[Harel 87]

D. Harel. Statecharts - a Visual Formalism for Complex Systems. Science of Computing Programming 8, 1987. Imperial Software Technology Ltd. X-Designer rel. 3 User's Guide, 1993. I. Jacobson, M. Christerson, P. Jonsson, G. vergaard. Objectoriented Software Engineering a Use Case Driven Approach. Addison-Wesley, 1992 G.E. Krasner, S.T. Pope. A Cookbook for Using the ModelView-Controller User Interface Paradigm in Smalltalk-80. Joop, August/September, 1988. J. Kuusela, J-M. Aalto. OMT+ ohje. Nokia Research Center, 1993. (Internal document) U. Neisser. Cognition Reality, W.H. Freeman Company, 1980. and and

[IST 93]

[Jacobson et al. 92]

[Krasner et al. 88]

[Kuusela et al. 93]

[Coleman et al. 94]

[Neisser 80]

[Norman 83]

[Coutaz 87]

D.A. Norman. Some Observations on Mental Models. In D. Gentner, A.L. Stevens, editors, Mental Models, pages 714. Lawrence Erlbaum Associates, 1983. P. Polson, C. Lewis, J. Reiman, C. Wharton. Cognitive walkthroughs: A method for theory-based evaluation of user interfaces. International Journal of Man-Machine Studies. 36, pages 741 - 773, 1992.

[Polson et al. 92]

[Ege et al. 91]

[Rumbaugh et al. 91] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen. Object-oriented Modeling and Design. PrenticeHall, 1991. [Waern 89] Y. Waern. Cognitive Aspects of Computer Supported Tasks, John Wiley & Sons, 1989.

[Green 85]

14