Vous êtes sur la page 1sur 14

Object-Oriented Development of Interactive Systems with OMT

++
Juha-Markus Aalto and Ari Jaaksi Nokia Telecommunications, Cellular Systems Mobile Switching, Network Management Systems Hatanpäänvaltatie 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

1

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

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. 'Account'. OMT as described in [Rumbaugh et al. However. and how they are related. Object Analysis The purpose of analysis is to obtain an understanding of the application [Jacobson et al. In OMT++. 91] concentrates mainly on the modeling technique. The strength of object modeling is that it emphasizes the key concepts which are believed to be stable. OMT++ includes detailed procedures for the specification and design of user interfaces. OMT. i. we build our future applications. 92]. 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. 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. we have a completely seamless transition from analysis to implementation. The class declarations are written in C++ according to the design object model. 3 . 'Bank'. 88]. 'Bill'. It is of vital importance that we understand what these key concepts are. Based on these entities. The design process is divided into two stages: designing of the structure of the application. we use the object modeling notation of OMT as it is.. In particular. Event traces characterize the interaction of objects. and 'Terminal Connection' are illustrated in figure 2. The design object model is obtained directly from the analysis model using the guidelines of OMT++. the objects. it does not define precisely what kind of object classes should be included in the analysis object model.g. what they mean. 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. Part of the code for the class declarations and implementation of methods can be generated by automatic generators such as user interface builders. The relations of the concepts 'User'. to understand user requirements and the problem to be solved. we build models that highlight the most important issues of the problem domain and hide any unnecessary details. The object analysis process produces an analysis object model that documents the key concepts and their relations. e. To facilitate communication in the analysis phase.e. for instance. 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. 3. and state machines define the internal behavior of objects. 2: An object model for the Bank Terminal application The graphical user interfaces consist of UI objects such as push buttons and windows. The structure of applications is based on the analysis object model and the Model-View-Controller (MVC) paradigm [Krasner et al. The operation specifications define the requirements for the functionality. 'Creditor'. Thus. and the analysis object model determines the data that is to be included in the user interface. and specifying the way how the behavior is implemented in that structure. We define the behavior of the application in terms of the event traces and state machines. The class operations are specified according to the information provided by event traces and state machines. OOSE and Fusion.. In OMT++.Unlike most object-oriented development methods.

we define only the results and the preconditions. Implementation issues shall not be presented in the analysis object model. Therefore we must not disregard the specification of the behavior of the system.balance is decreased and Creditor's Account.amount. we do not use data flow diagrams for the specification of the functionality.amount Bill is settled and the User's Account. Instead. 92]. because this easily leads to the design of algorithms. The first task in the behavior analysis phase is to identify a list of the operations that the user carries out with the application. All operations are defined using the vocabulary provided by the class names of the object model. we must not forget that it is the functionality of the application that the customers pay for. This list should explain why the application exists. we specify user operations first without any user interface details.balance Bank Terminal Creditor Exceptions: illegal Account. unlike OMT. not the objects. Now that we know what kind of functionality is required.balance increase Account. the class operations are defined in the design phase.Description: Assumes: Result: Scenario: Settling a bill. For instance. 4. Instead. 2. we understand the key concepts of the problem domain and the information related to these concepts.balance increased by Bill. 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.balance > Bill. 94] in order to highlight system interfaces (see the dotted line in figure 2). and added the use of event traces with the definition of exceptions. and what tasks the user performs with the application. 4 . not enough money in user's Account Fig. although we deal with the user interface in a different way. It is worth noting that. 94]. In addition to the two main rules mentioned above. We have also adopted the concept of system boundary from Fusion [Coleman et al. After the object analysis has been carried out. 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 this way we ensure that the operation specifications and the object model are consistent. User settle bill decrease Account. In this respect. we have defined a set of rules for the documentation of the object model. but we have simplified the specifications. we can start designing how to provide this functionality to the user. The next step is to define the user operations for the manipulation of the information that we have obtained. 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. The basic structure of the specifications has been adopted from Fusion [Coleman et al. The list is built in parallel with the object analysis. our approach resembles the use case approach of OOSE [Jacobson et al. Behavior Analysis Although we want to use an object-oriented approach to software development. Account. After that we document each operation as in the example depicted in figure 3. In OMT++.

the end user uses mental models to describe. 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.1. 4: The user interface as an intermediate entity 5. The user must be able to see the application in terms of metaphors. and an event refers to the selection made by the user. OMT++ provides the dialog diagram for modeling this. By operating and perceiving.The End User manipulation feedback mental models The User Interface requests responses The Application ok cancel Fig. operate the system and learn more about it. start exit Bank terminal do: 1 select an account close Account selection do: 2 Fig. 5 . Checking the balance of an account. At this point we are only interested in the dialogs that form the framework of the user interface. mental maps or other mental structures. We decide to organize these tasks into two dialogs: the 'Bank terminal' window and the 'Account selection' dialog.2. User Interface Specification 5. We must specify the user interface so that the end user can complete all the tasks presented in the operation specifications. the end user can reinforce and change his mental models towards the ideal ones [Neisser 80]. every meaningful manipulative action should provide immediate perceivable visual feedback. In order to help the end user to tune his mental models. We organize those tasks into dialogs in such a way that in each dialog the user can complete semantically meaningful tasks. 2.The User Interface The user interface is seen as an intermediate entity between the end user and the application itself. 5: The dialog diagram of the Bank Terminal application The dialog diagram notation is modified from Harel's state chart notation [Harel 87]. so we can see that in the diagram in figure 5. A line inside a dialog indicates the main window. The user interface must therefore be capable of communicating with both the end user and the application as depicted in figure 4. A little black box denotes a modeless dialog. Let us assume that we have the following user operations: 1. and they explain the objects and associations of the reality. 5. Selecting an account. both the 'Bank terminal' window and the 'Account selection' dialog can be operated simultaneously. Waern 89]. An ideal mental model is accurate and sufficiently correct that the end user can solve problems. When in contact with the user interface.Constructing the Structure of the User Interface The main inputs to the user interface specification are derived from the object and behavior analysis. and a 'do:' statement locates user operations into a dialog. A state stands for a dialog or a window. Mental models are representations of the reality. explain and predict the behavior of the system [Norman 83.

We try to find tools that form semantically meaningful sets. are defined according to the operation specifications as illustrated in figure 6. We have not yet made a decision of the final layout of the user interface. such as push buttons and text fields. in the 'Account selection' dialog we find that the tools 'Select an account' and 'Show possible accounts' (fig. In every dialog the end user must be able to complete at least one meaningful task. For example. the user interface must provide visual clues. we draw components by using a simple notation: an ellipse stands for a manipulation tool and a rectangle denotes a feedback tool. 6) form a component that we may call 'Accounts' (fig. The tools are either manipulation tools that the user needs to control the application.Testing and Tuning the User Interface As many problems and errors as possible should be detected at the earliest possible stage. Every dialog is made of components. so that the end user can see and understand the connection of these tools. This is exemplified in figure 8. 6: The dialog tool listing 5. These explanations will guide the final implementation.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. i. such as too complicated objects. To depict the components of the dialogs. Written explanations about the behavior of the components must be provided. If this is the case.e. or objects with no purpose at all. Each component consists of tools. Likewise the tools 'Apply' and 'Close' form a component that we can call 'Dialog Control'. components. 7).Defining Components for the Dialogs During the design of the dialog diagrams we also think about the contents of the dialogs and windows. The contents for dialogs. or feedback tools that the application needs to present things to the user. 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. we may redesign parts of our user interface before starting the implementation. Check lists can be constructed for every phase of the UI specification and cognitive walkthroughs 6 . The evaluation of the user interface is based on the dialog diagrams and component specifications. such as these in figure 5.4. 7: Component specifications of the Bank Terminal application Figure 7 illustrates how the components are specified.3. and they may also indicate possible problems. It should be noted that in the final implementation the tools of a component are not necessarily located next to each other. If we detect problems. In the following we consider each dialog at a time. 5.

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. The first account is selected by default. Component Application Control Balance Manipulation The end user may exit the application. The account is selected by default. we gather up a library of highly reusable interface elements. In the top-down UI specification approach of OMT++. 5. Fig. Feedback - Fig. the visual design is carried out as the last step of the specification process. one account is available. 9: Visualized user interface 7 . the output of which is illustrated in figure 9. 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. Visualization can only be done well if the preceding steps are completed properly. The number of 'select an account' tool.5. This tool is disabled if only the selected account is shown. selection is shown. 8: Definition of the behavior of the UI components in the Bank Terminal application [Polson et al. The first All possible accounts are listed. This approach reduces iteration and helps us detect problems in usability early without expensive prototyping or massive field tests. we would more likely forget the most important main lines and concentrate on less meaningful details. 92] can be made.Visualization of the User Interface The last phase in the user interface specification is the visualization phase. By thoroughly designing all dialogs and UI components. dialog by using the 'close' -tool. If we started directly from this phase.The end user can select an account by using the The balance is shown. Accounts The end user can select a single account.

and it is created by the controller. we have adopted the terminology of the MVC model. The main controller controls the other controller object (e). Feedback we implement the applications in C++ instead of Smalltalk.The MVC Concept There have been attempts to create a standardized separation of the user interface and the rest of the application. The view pass the end user's actions to the controller (c). and the model is not "aware" of the view. there is no direct connection between the model and the view as depicted in figure 10. which communicates with the main controller (d). its extensions. 10: An MVC application developed according to OMT++ Unlike the MVC approach presented in [Krasner et al. The controller thus integrates the model and the view in an application-specific way. 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. We present a strict division of labor and define precisely what classes and methods are needed in each part of an application. callback methods associated with widgets) are used capture the user's actions. The model is managed by the controller. This is typically the controller of the main view class. which forms the main window such as the 'Bank terminal' window in figure 5. A typical method of a controller class has two parts. The model represents "the real world" and it is based on the analysis object model. feedback methods (FM) present things to the end user. such as in [Ege et al. first the controller makes the model act. 91]. The view is the outer layer which is visible to the end user.1. There is always one main controller class. the PAC (Presentation-Abstraction-Control) model [Coutaz 87] and the MVC (Model-View-Controller) model [Krasner et al. The view contains the UI components and callback functions. and knows how this application should work. 88]. The view does not decide how to respond to the user's actions.g. difficulties have occurred. Each part of the MVC triad is typically made of several classes. Action requests Results Interpreted actions Manipulation Decisions Action requests View Controller Model Fig. from the one presented in [Krasner et al. and then it asks the view to present the results. In practice. such as the Seeheim model [Green 85]. The controller knows what the view and the model are capable of doing. there is a well-defined role for each part of an MVC application. Object Design 6. In OMT++. and the role and separation of the parts has been unclear. and how to receive user's actions. we do not have any run-time assistance for managing the connections between objects. The communication between the parts of an MVC application is characterized in figure 11. 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. It knows how to present things to the end user. the controller controls the view (a) and the model (b). The methods of model classes typically have counterparts in the real world that was modeled. The main controller class also controls other controller classes. 88]. but it never knows how things are done inside the model and the view. The controller makes all the application-specific decisions. and query methods (QM) are designed for the controller to investigate the state of the view. Since 8 . 11: An MVC application with two view objects.6. There are three main categories of methods in a view class: manipulation methods (MM. 88]. In OMT++. but the implementation differs e. In OMT++. it passes them to the controller.

We design the class interfaces by drawing event traces for each operation of the application. Our intentions is to make components of the dialogs reusable. 2. 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. 92]. The 'account selection' view of the dialog found in figure 5 is illustrated in figure 13. we may sometimes want to join it with another view class and call it a view component. The controller may have relations with multiple model classes. Controller classes are connected to view and model classes as in figure 14. Model classes are obtained directly from the analysis object model. Design of Controller Classes There is a single controller class for every view class. every dialog of the dialog diagram (fig. we can pick the operations for each class by examining the messages (method calls) they receive.3.Finding the Operations for the Classes The main problem in the design of the class interfaces is finding the operations for the classes.2. on the other hand. 3. we can construct views from components. 14: Classes of the Bank Terminal application 7. 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. The design of the model classes starts by transforming the analysis object model to the basis for the design object model. in order to determine whether we need a counterpart for them in the object model. 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.1.Design of View Classes Typically. Design of system interface classes. The classes that represent the user are typically replaced by the view and controller classes that comprise the user interface. By doing so. 2). We consider each of the classes that are outside the system boundary (such as Terminal Connection in fig. 12: The model. Let us suppose that the view component class 9 . accountsVC accountSelectionView Fig. Object model refinement. 7) is available. If a dialog is extremely simple. the same model may be connected to multiple controllers.Design of Model Classes The model class design produces the basis for the design object model as depicted in figure 12. Each view class contains the components that have been specified in the user interface specification phase. a bank with multiple accounts 6.4. Bank Fig. The participants of the event traces are the classes of the design object model. When we have drawn the event traces. A similar approach has been adopted in the OOSE methodology [Jacobson et al. The construction of the model consists of three main phases: 1. 13: The account selection view class and a view component (VC) 6. Account balance number drawn-on-by settled-to-by Bill amount code 'accounts' (fig. We refine the object model according to the requirements set by the controller class design and the optimization of data access paths. instead of separate UI tools. Behavior Design 7.6. 5) forms a view class. Identification of persistent and transient classes. We have successfully applied the use of event traces for this purpose.

For classes with complex dynamic behavior we build state machines using Harel's state chart formalism [Harel 87]. as illustrated in figure 17.Model Operations For each model class we define a set of standard operations such as 'Get'. 15: An event trace for the operation 'Show balance for the account' From the event trace presented in figure 15 we can see. accountSelectionView applyButton closeButton ApplyPressedMM ClosePressedMM ShowAccountsFM(nbrs) accountsVC accountList GetSelectedQM : nbr ShowAllFM(nbrs) accountSelectionController AccountSelected (nbr) DialogCloseAsked Fig. such as 'ClosePressedMM()'. and 'Destroy'. all operations are the result of a systematic design process.View Operations We get the skeleton for the view class directly from the UI component specifications (fig. the model classes are highly reusable. After that. 'Set'. 17: The account selection controller and the view 10 . feedback or query methods as in figure 16.2. We always need to check the existing operations of a class before we define operations for our own needs. 5 and 7). The rest of the operations come from event traces as depicted above. accountSelectionView applyButton closeButton ApplyPressedMM ClosePressedMM ShowAccountsFM(nbrs) accountsVC accountList GetSelectedQM : nbr ShowAllFM(nbrs) Fig. Typically.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. the controller asks the view to update itself accordingly. such as 'DialogCloseAsked()'.4. 'Query'. The methods which are capable of receiving interpreted actions from the view are added to the controller classes.3. has a corresponding method of the controller. 7. 15) and from the definitions of behavior of the UI components (fig. 8). that the class 'bank' needs to have an operation 'GetBalance' with argument 'nbr' (account number) to satisfy our design. The view operations are either manipulation. and tells what the user has desired by calling the methods of the controller such as 'AccountSelected()'. every manipulation method of the view. Then the controller decides upon the necessary actions and makes the model classes perform these actions. for instance. The methods are obtained from the event traces (fig. State machines capture the dynamic behavior of the objects of a class. The view interprets user's actions such as the pressing of a button. 7. 16: The account selection view classes 7. Therefore a suitable operation for a class may already exist. 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. Typically.Controller Operations The controller gets the interpreted actions of the end user from the view. balance) Fig. and they can be constructed from event trace diagrams.

When the view wants to call a method of the controller. we cannot use static binding here. Therefore we cannot write lines such as accountSelectionController-> AccountSelected(nbr) in a method of the view class in figure 17.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. as well as the main controller 11 . 8. Answers to those expectations are finally implemented in the classes that inherit those abstract partners. the controller must have methods to handle this. We must create an abstract view partner to describe what the view expects from the controller. the view calls a pure virtual method of the abstract view partner class (e. Mapping the Design into C++ 8. since the controller has the view as an object member.g. but we do not know what the controlling controller is. 19: C++ implementation of an MVC application. The views should be designed so that they can be used by another controller.1. The abstract view partner is a C++ class that contains only pure virtual methods.Abstract Partners The MVC approach of OMT++ strongly supports reusable view classes. However. The abstract partners describe what is expected from the users. For the sake of simplicity. As one can see in figure 17. In order to make reusable view classes. 18: Figure 17 with the abstract view partner. we introduce a new concept: an abstract partner. Let us take an example. the view also needs to call the methods of the controller in order to pass the user's requests to the application. accountSelectionAbsVP-> AccountSelected(nbr)). This allows us to change the behavior connected to a view by changing the controller only.) A similar partnership exists between the view and the view component. When the user presses the 'Apply' button in our 'Account dialog' example. 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. it is used by a AccountSelected(nbr) DialogCloseAsked Fig. it may directly call the public methods of the view. (In a complete example there could also be a view partner between the accounts view component and the account selection view. In order to circumvent this. Any controller that wants to use the view must inherit its abstract view partner and implement the abstract methods as illustrated in figure 18. they are excluded from this figure. view class and inherited by a controller class.

This decreases the need for iteration in the software process. 9. The methods of the view classes are typically fairly simple. and forward these actions to the controller through an abstract view partner. The separation of the user interface in analysis.g. Customers' requirements are better met when we first understand what the user operations are. The subcontroller calls the main controller through the abstract controller partner. Our approach facilitates the compiling of the library of high quality user interface components. but abstract controller partners are used to explain what the subcontroller expects from the main controller. and then tells the result to the view and the main controller. Feedback methods (FM) are used by the controller. Our approach for the user interface specification also decreases the need for iteration and prototyping. It also sets links to the main controller and the model classes. such as AccountSelected() in figure 21. They capture and interpret the end user's actions. We write abstract partners above class declarations as illustrated in figure 20. The constructor of the controller class creates the view. It provides a continuous path from customer requirements to C++ code. A typical method of the controller. The main controller can directly call the methods of any subcontroller. as in figure 20. Figure 21 illustrates the 'account selection' controller. it needs to use the main controller through the abstract controller partner by means of dynamic binding. All the benefits of the MVC approach can be obtained in a standard C++ environment. Our implementation of the MVC approach provides powerful tools for the reuse of software components. V. the institutionalization of OMT++ is a time-consuming task. 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. writing or drawing on them. Manipulation methods (MM) are callback methods that are associated with tools. That makes the software robust for changes and easy to comprehend. They affect the tools of the dialog by e. before we begin designing the user interface. VC and MVC collections that can be connected with any future application. and the methods are implemented as illustrated in figures 20 and 21. such as widgets.2. and it is successfully used in the development of a large network management system.Class Specification and Implementation The C++ class declarations are written according to the design object model.and other controllers. Applications are made of parts that each have their own role and behavior. Although we have streamlined the process model and the use of the modeling notations. In addition. makes the model act. This is illustrated in figure 19. We do appreciate that certain aspects of OMT++ such as the complexity of the process still need to be improved. It also creates all the view components. By using abstract partners we can create reusable M. design and programming phases has a number of advantages. 8. the objectoriented CASE tool technology is finally maturing and our aim is to convert our design rules to a format understood by the computer. This is how we also document what is expected from controller classes. The constructor creates the link between the view and the controller. The usability of the user interface can be evaluated on the basis of the UI specifications. Because the 'account selection' controller is not the main controller. 12 .

// a tool Widget closeButton. count). char **accNbrs = 0. virtual void DialogCloseAsked() = 0. 20: Declaration and implementation of a view class class accountSelectionController : public accountSelectionAbsVP { public: accountSelectionController(accountSelectionAbsCP *cntrlPartner. accountsVC *accountsViewComponent . accountSelectionAbsCP *controllerPartner. } private: void ApplyPressedMM() { viewPartner->AccountSelected(accountsViewComponent->GetSelectedQM()). } private: accountSelectionView *view. class accountSelectionView { public: accountSelectionVie w(accountSelectionAbsVP *vPartner) { viewPartner = vPartner. } void ShowAccountsFM(char **accNbrs. if (!err) controllerPartner->AccountSelected(accNbr). else view->ShowErrorFM(err). count ). int count) { accountsViewComponent->ShowAllFM(accNbrs. bank *crrntBank) { view = new accountSelectionView( this ). bank *currentBank. controllerPartner = cntrlPartner. err = bank->TestAccount(accNbr). }. currentBank = crrntBank. }. view ->ShowAccountsFM( accNbrs. Widget applyButton. 21: Declaration and implementation of a controller class 13 . } void DialogCloseAsked() { view->Hide(). int count = bank->GetAccountNbrs(accNbrs). // a tool }. } void ClosePressedMM() { viewPartner->DialogCloseAsked().class accountSelectionAbsVP { public: virtual void AccountSelected(char *accNbr) = 0. } accountSelectionAbsVP *viewPartner. Fig. Fig. accountsViewComponent = new accountsVC(). } void AccountSelected(char *accNbr ) { error err.

Acknowledgments This paper has been reviewed by Ilkka Haikala. Joop. Cognition Reality. pages 9-20.A. [Green 85] 14 . [Waern 89] Y. 3 User's Guide. Finland. 88] [Kuusela et al. W. Neisser.L. 1980. Christerson. Prentice Hall. 1994. (Internal document) U. Finland. Kuusela. Aalto. August/September. P. Object-oriented Modeling and Design. Polson. Coleman. P. Addison-Wesley.E. [Harel 87] D. M. Lorensen. X-Designer rel. Övergaard. PrenticeHall. Experiences on Applying OMT to Large Scale Systems. W. P. C. C. 1987. Wharton.Shackel. Stevens. W. Ege. Nokia Research Center. J. Some Observations on Mental Models. 1992 G. Lawrence Erlbaum Associates. Krasner. International Journal of Man-Machine Studies. 1993. editors. 1988. J-M. 1987. Järvinen.Jeremaes. and and [IST 93] [Jacobson et al. Gilchrist. PAC. M. 1993. HumanComputer Interaction INTERACT '87. Norman. F.a Visual Formalism for Complex Systems. Eddy. November 5. 36. Reino Kurki-Suonio and Kari Systä from the Tampere University of Technology and by Ari Aalto. We would like to thank them all for their valuable comments on earlier versions of this paper. Jonsson. Tim Rowe and Eija Tervonen from our own organization. 1983. J. 91] J. A Cookbook for Using the ModelView-Controller User Interface Paradigm in Smalltalk-80. C.E. 11. Aalto. Hayes. G.Stary. Pfaff. Green. In M. In D. Proceedings of Human Jobs and Computer Interfaces Conference. editor. A. Freeman Company. References [Aalto 93] J-M. Science of Computing Programming 8. [Polson et al. In Gunther E. Workshop on User Interface Management Systems. M. 92] [Ege et al. Elsevier Science Publishers. pages 431-436. P. Rumbaugh. 91] [Rumbaugh et al. Dollin. I. The Fusion Object-Oriented Analysis and Design Method. Finnish Artificial Intelligence Society. Tampere. 1992. Pasi Rajala. Weir. Imperial Software Technology Ltd. Jacobson. 1989. Lewis.J.I. Bullinger. H. 1985. Gentner. Waern. 1991. 92] [Krasner et al. Springler Verlag. Reiman. Objectoriented Software Engineering a Use Case Driven Approach. John Wiley & Sons. F. editors. Bodoff. J. S. Cognitive walkthroughs: A method for theory-based evaluation of user interfaces. Premerlani. Cognitive Aspects of Computer Supported Tasks.H. Pope. D. pages 223-237. Statecharts . Coutaz. an Object Oriented Model for Dialog Design. Task and Object-Oriented User Interface Spesification. S. 1993. 94] [Neisser 80] [Norman 83] [Coutaz 87] D. C. Nurminen. Conceptual Modeling and Object-Oriented Programming Symposium. University of Tampere. pages 714.10. Mental Models. In H.T. editors. G. K. Harel. Report on Dialog Specification Tools. B. pages 741 . 1993.773. P. 1991. OMT+ ohje. 93] [Coleman et al. Blaha. Arnold.