SFDC 1015
`SFDC 1015
`
`
`
`
`
`
`
`
`
`

`
`The JANUS Application Development
`Environment—Generating More than
`the User Interface
`
`Helmut Balzert, Frank Hofmann, Volker Kruschinski,
`and Christoph Niemann
`Lehrstuhl für Software-Technik, Ruhr-Universität Bochum, Universitätstraße,
`150, D-44780 Bochum, Germany
`Phone: +49-(0)234-700-{6880, 6791, 5918, 7982}
`Fax: +49-(0)234-700-6914
`E-mail: {hb, hofmann, krusch, niemann }@swt.ruhr-uni-bochum.de,
`janus@swt.ruhr-uni-bochum.de
`WWW:http://www.swt.ruhr-uni-bochum.de/forschung/veroeffentlichungen.html
`
`Abstract
`
`The increasing pressures of competition demand greater productivity and quality in
`the development of software. These goals are attainable by generating as much as
`possible and programming as little as necessary. Beginning with an OOA modeling
`of the problem domain component, this article will show how the user interface as
`well as the linkage to data keeping can be generated through an integrated ap-
`proach. In addition, a client/server configuration is also possible. A OOA model
`upon which two generator systems are installed is the basis for generating.
`
`Keywords
`User interface generation, OOA model, object oriented database, rapid prototyp-
`ing, application framework.
`
`Introduction
`The ever increasing demands on the productivity and quality of software develop-
`ment necessitates extensive automated support for application development. If one
`examines object oriented application development (figure 1), the way from the
`problem domain to an object oriented analysis model (OOA model) cannot be
`automated. This step shall continue to belong to one of the most ambitious tasks
`of software development.
`If an OOA model is created, it forms the basis for any additional steps of devel-
`opment. The concepts available today describing an OOA model (class, inheri-
`tance, association, aggregation, object life cycle, interaction diagrams, subsystems,
`see also [Coad91a, Booch94, Rumbaugh91]) allow close to real-world situation
`modeling of the problem domain.
`
`SFDC 1015
`
`

`
`184
`
`Computer-Aided Design of User Interfaces
`
`r o blem
`P
`Dom ai n
`
`D esig n e d b y th e
`Syst e m a n a lyst
`
`O O A
`
`G e n era tin g th e
`A p plic a tio n
`
`O O D
`
`S er vi ces
`
`G UI
`
`Fra m e
`D a t
`k e e p i
`
`Help
`
`a
`
`-
`n
`
`g
`
`C lie nt-
`Serv er
`
`O O P
`
`N o v. 93 Be nk
`Syst em
`
`
`Figure 1. The way to an application starting at the problem domain
`The following must be done to obtain a usable application from a OOA model:
`• Integration into the system software of the target system.
`• Design and connection of the user interface to the problem domain compo-
`nents.
`• Connection to the desired data base management system (DBMS).
`• Design and connection of the help system.
`• Creation and connection of various services (e.g., multiple user administration,
`client administration, etc.).
`Analyzing the jobs to be completed, one ascertains that a large part of these tasks
`can be automated by generators. The term "automated" is intentionally used in-
`stead of "automatic". Automated is intended to express that generating does not
`run fully automatically, but rather that the developer retains the possibilities to in-
`tervene and make decisions during the generating process.
`Therefore, the optimal goal consists of generating nearly all additional necessary
`tasks from an OOA model. The semantics of a problem domain component are
`principally incapable of being generated, i.e., the technical semantics have to be im-
`plemented by the software developer. He uses the desired programming language
`(inner column of figure 1).
`
`

`
`
`
`The JANUS Application Development Environment-Generating More than the User Interface
`
`185
`
`Even in this area, however, much can be generated. Today’s OOA/OOD tools al-
`low the corresponding program frameworks to be generated from the OOA
`model, e.g., the tools Together/C++, Paradigm Plus and ObjectiF. To have a prac-
`tical benefit of generating system components the developer needs an integrated
`system which will combine all fragments.
`Furthermore, it is not enough to generate all components from the same starting
`point (e.g., an OOA-model) an integration of all generated parts can be done auto-
`mated. Therefore we have developed the JANUS Application Development Frame-
`work (JADE1). It is a further development of the JANUS-system [Balzert93, Balzert-
`94, Balzert95a, Balzert95b]. The JANUS-system was capable of generating and ani-
`mating a graphical user interface from an OOA model using the capabilities of an
`UIMS.
`The advanced system now produces the user interface, the code frame for the ap-
`plication domain, the database schema, further services (e.g., a help system, print-
`ing facility) and ‘last but not least’ the connection between all these parts. The start-
`ing point is still an OOA-Model. JANUS requires the model in a well defined input
`language, the JDL (JANUS Definition Languages) which is an extension of ODL
`and IDL. To avoid that the user has to code his OOA model using this language
`directly, we have built interfaces to some popular OO CASE tools. Currently JDL
`can be exported by the case tools Paradigm Plus and Together C++.
`The result of the generation process is a ready-to-work-with application offering
`basic functionality. The user is able to create and modify objects of classes defined
`in OOA by using entry forms. If a corresponding relationship (association or ag-
`gregation) exists in the OOA model the user can establish links between objects,
`too. Additionally a list view of all objects that have been created for each class is
`provided.
`Functionality for sorting and deleting objects is also generated. All data entries are
`kept persistent in an underlying database. Until now the software developer has not
`written a single line of code. The only work that has been done was defining an ex-
`act OOA model of the application’s problem domain.
`The generated program will however be the fundamental frame of a final system. A
`programmer will have to complete the application. He has to implement the opera-
`tions defined in the OOA model to provide the application’s core functionality.
`Additional features—especially regarding the GUI—can be added to the generated
`code. To ease this JANUS generates C++ source code for all parts of the program.
`These can be edited and compiled the normal way. This paper describes the con-
`cepts of integrating all parts. It gives examples of the transformation process and
`its results.
`
`
`1 This JADE system has nothing in common with JADE [VanderZanden90] but the name. It seems
`that we have no luck in choosing the right name for our system.
`
`

`
`186
`
`Computer-Aided Design of User Interfaces
`
`1 As to the Situation
`
`The situation today is characterized by increasing attempts to automate separate ar-
`eas of the software development process. Class libraries in combination with a
`graphical editor are used today in the development of GUIs. GUI class libraries are
`hierarchically organized and provide predefined interface objects at higher abstrac-
`tion levels. The activation of the underlying window system is undertaken by inter-
`nal operations and remains hidden from the developer. The design of the GUI us-
`ing this technique leads to two results:
`(cid:120) A code frame will be generated in the desired programming language (usually
`C++). The combined interface objects can be created dynamically using this
`code. The I/O operations of these objects have to be manually linked to the
`OOA model.
`(cid:120) Characteristics of interface objects such as position, size, labeling, and shape
`will be placed in resource files. Each resource object contains an identification
`through which the connection to the objects implemented in the programming
`language is made. A special resource translator transforms the resources into
`object code, which will later be linked to the application.
`It was shown under the JANUS system [Balzert93, Balzert94, Balzert95a, Balzert-
`95b] that a GUI can be generated and subsequently animated from an OOA model
`based upon expert knowledge of software ergonomics.
`However, the linkage to data keeping in particular is missing in order to attain a us-
`able application. When using an object oriented database (OODB), the object
`model is defined in an Object Definition Language (ODL). The developer sepa-
`rates the declaration (data and interfaces) of an application from the implementa-
`tion. A declaration preprocessor for the ODL takes over the following tasks:
`(cid:120) The ODL is transformed into a declaration conforming to a programming lan-
`guage which then can be translated by a compiler together with the implementa-
`tion of the application.
`(cid:120) A database with the database schema obtained from the ODL declaration is
`created in which the object model of the application is also established as a
`meta schema.
`The implementation of the technical semantics of the OOA model occurs in the
`selected programming language. To handle persistent objects, an Object Manipula-
`tion Language (OML) is provided by an external library. This library comes with
`the chosen database management system. With this, the programmer can manipu-
`late persistent objects with the same concepts (pointer, list,...) known from the
`programming language as usual.
`The declarations transformed in the programming language and the implementa-
`tion are translated by the compiler into object code. The runtime system ODBMS
`is added to the object code during linkage so that the finished application can ac-
`
`

`
`
`
`The JANUS Application Development Environment-Generating More than the User Interface
`
`187
`
`cess the predefined database. To allow the generation of persistent classes, all per-
`sistent classes have to be marked in the OOA model. All other information is al-
`ready present to generatively couple an object oriented database.
`A corresponding coupling to a relational database is similarly possible by utilizing
`the respective class libraries, e.g., DBtools.h++. Appropriate transformation rules
`are describe (e.g., in [Blaha94]).
`A three-layered-architecture comprising a GUI layer, the actual application layer,
`and data keeping layer arises as the software architecture. The application layer not
`only contains the implementation of the technical semantics but also contributes
`the connection between the GUI layer and data keeping. In particular, the overall
`goal is to encapsulate the layers as closely to one another as possible in order to
`make an appropriate client-/server distribution feasible.
`It has now been shown that a partial generation does not appropriately take the
`global aspects of the application environment into consideration. If, for example,
`solely the interface is generated without taking the coupling of data into considera-
`tion, it will lead to problems in subsequent application development. The commu-
`nication between the GUI level, application level, and data keeping level has to be
`manually established. This requires detailed knowledge of the code at all levels and
`is costly. An integrated overall plan is therefore necessary.
`
`2 An Integrated, Technical, and Comprehensive Plan
`
`As mentioned above a OOA model is the basis for the generation process. In the
`moment the JANUS generator system uses only information given by a class dia-
`gram representing the application’s object model of the problem domain. The ele-
`ments of these class diagram (classes, attributes, operations, relations, etc.) have to
`be specified in detail.
`To provide this information to the generator system, the OOA meta model in fig-
`ure 2 has been developed. The OOA model of a specific application is a single in-
`stance of the OOA meta model. The meta model can be instantiated by a special
`file using the JDL grammar. JDL input files describe an OOA model CASE tool
`independent and implementation language independent.
`Not only problem domain and database specific characteristics but also GUI rele-
`vant properties are represented by the OOA meta model. It is important to men-
`tion that all GUI relevant properties have default values which work very well in
`most cases. But the OOA analyst (or a consulted GUI specialist) should have the
`possibility to override these values to customize the generated GUI whenever
`needful.
`The meta model was expanded with characteristics of the object models of the
`OMG [OMG91] and ODMG [Loomis93]. As before, the most important common
`concepts of the object oriented methods according to Rumbaugh [Rumbaugh91],
`Coad/Yourdon [Coad91a] and Booch [Booch94] are found in this model.
`
`

`
`188
`
`Computer-Aided Design of User Interfaces
`
`Subsystem
`Description
`UIRelevant
`
`Operation
`Description
`ClassGlobal
`Polymorph
`ReadOnly
`UIRelevant
`
`Parameter
`In
`Out
`ByReference
`
`Model
`Description
`
`Class
`Description
`Persisten
`Abstract
`Extent
`UIRelevant
`
`Subclass
`
`Relation
`Description
`Persisten
`
`Superclass
`
`2
`
`Path
`Description
`Type
`Cardinality
`UIRelevant
`
`Attribute
`Description
`Persisten
`ClassGlobal
`Primary
`ReadOnly
`WriteOnly
`UIRelevant
`Mandatory
`Unit
`
`Returntyp
`
`Type
`DefaultValue
`
`EmbeddedType
`
`NumericType
`TypeSpec
`LowerBoun
`UpperBound
`ConstraintExp
`
`StringTyp
`MinLength
`MaxLength
`RegularExpr
`
`EnumTyp
`SelectableElem
`SelectMin
`SelectMax
`Extensibl
`ExtentPersisten
`ExtentScope
`
`
`
`Figure 2. Meta model as the generator’s base
`The information contained in the meta model is utilized by a GUI- and an App-
`generator (application generator). The meta model's operations (not included in
`figure 2) take over the control and coordination of these generator systems.
`The App-generator creates the code frames for the OOA model as well as the
`connection to the database and, if requested, additionally the client-server distribu-
`tion. In addition to the code frames, the operations for read and write access to all
`attributes are also generated. On the one hand, for each attribute, one operation is
`created for read and write access to the attribute value. On the other hand, each
`class contains one operation which assists in reading and/or writing each attribute
`belonging to this class irrespective of its type. If the systems analyst has set restric-
`
`

`
`
`
`The JANUS Application Development Environment-Generating More than the User Interface
`
`189
`
`tions (e.g. ranges or dependencies between attributes), they will be checked for the
`applicable attribute before write access.
`The GUI generator similarly rests upon the meta model. The previously mentioned
`JANUS system [Balzert93, Balzert94, Balzert95a, Balzert95b] was expanded and
`modified for this. Only the generation of static layout and some aspects of dialog
`dynamics have been supported up until now. This information is placed in a re-
`source file.
`It is additionally necessary to create GUI code, which accesses the resources and
`connects the individual interface objects with the objects and attributes of the
`OOA model. For each dialogue identified in the OOA model a class is generated
`in order to automatically couple the created interface with the OOA model. By
`coupling with the App-generator, the operations supplied there become available
`for access to the attribute values irrespective of type. Thus, it only then becomes
`possible to generate an interface closely coupled to the OOA model with justifiable
`expense, and therefore, to obtain a complete, detailed application.
`In the next section we will describe a simple example that shows the input and the
`output of a generated application and explains some important actions that have to
`be taken to get a running application
`
`3 A Simple Example
`
`Figure 3 depicts the OOA model of a simple sample application. The OOA model
`had to be entered into a CASE tool manually. Generally a complete OOA model
`consists of at least the graphical class diagram and the textual specification of all at-
`tributes and services.
`
`Person
`{abstract}
`Last name
`First name
`Date of birth
`Sex
`
`Company
`
`Name
`Legal form
`
`Employer
`
`Staff
`
`Employee
`
`Positon
`Salary
`Employed since
`
`
`Figure 3. OOA model of the simple example
`In order to support a systems analyst in this task, a form was drafted that makes
`the information accessible by the generator system. As an example, one can indi-
`cate the following specifications for the some attributes of the class Company:
`
`

`
`190
`
`Computer-Aided Design of User Interfaces
`
`Attribute Name:
`
`Ergonomic Name: Company Name
`
`Type: String, 30 characters maximum
`
`Mandatory Attribute
`
`Part of the Primary Key
`
`persistent
`Attribute Legal_Form:
`
`Type: Enumeration, not expandable,
`
`
`0 to N selections
`
`Selection Possibilities: inc, ltd, corp, co-op
`
`no default value
`
`persistent
`If the system analyst has finished his work he can export the OOA model form the
`OOA CASE tool in form of a JDL file. Appendix A shows the JDL file corre-
`sponding to the OOA model of figure 3. Now the generation can be carried out
`with this JDL file. The result is an application whose generated code for the prob-
`lem domain component corresponds to the OOD model depicted in figure 4.
`
`PDObject
`
`Persistent Object
`
`Company
`
`Name
`
`LegalFormT
`
`SexT
`
`Person
`
`Name
`FirstName
`Birthdate
`
`Employee
`
`Salary
`Begin
`
`EmployeeStatic
`
`EmployeeList
`
`FunctionT
`
`FunctionTStatic
`
`Value
`
`Valid
`
`
`
`Figure 4. Simplified OOD model of the generated application
`Each class of the OOA model inherits PDObject, an abstract base class. The opera-
`tions provided by PDObject for typeless access to the attributes are of course rede-
`fined in the classes of the OOA model. They serve primarily to connect to the user
`interface and are described later.
`All classes with persistent attributes or relations have to inherit from the class
`d_Object. This is a mixin-class which implements the manipulation components of
`the ODMG conforming database. As a general matter, each class has to know the
`instances it produced. Therefore, each class is assigned a list which collects refer-
`ences to all objects of that class. This list is implemented as a class attribute. Since
`the ODMG standard does not support persistent class attributes, an aid must be
`constructed. An object of the EmployeeStatic class saves the persistent class attrib-
`
`

`
`
`
`The JANUS Application Development Environment-Generating More than the User Interface
`
`191
`
`utes of employees, being the necessary lists in this case. The generated code en-
`sures that only one instance of EmployeeStatic exists in the database at any given
`time (depicted only for the Employee class in figure 4).
`Another aid is necessary for the description of enumeration types. A new class has
`to be generated for each enumeration type since the characteristics of the enumera-
`tion types (multiple choice, expandability) go beyond the concepts provided by the
`programming languages.
`If one examines the attribute Function of the class Employee, another problem be-
`comes apparent. This enumeration type is to be expandable, and the expansions are
`to be persistently cared for in the entire application. Therefore, the lists of the ex-
`pansions have to be a persistent class attribute of the data type FunctionT and, thus,
`have to be administered in a further help class, FunctionTStatic.
`The GUI generator creates the user interface itself as well as its linkage to the
`problem domain component. First, an interaction object corresponding to the at-
`tribute type in OOA is selected for each attribute to appear on the user interface.
`Further, the generator first evaluates the information prepared in an instance of the
`meta model. If the selected interaction objects would not fit into the window, the
`generator decides to use either less space consuming interaction objects (if such al-
`ternatives exist in its knowledge base) or to split the window into sub windows.
`The position of the individual interaction objects in the dialogue windows is de-
`termined by the class definition in the object model and by the evaluation of inheri-
`tance hierarchies [Balzert93].
`Associations and aggregations are transformed in lists. Figure 5 depicts two entry
`forms generated for the example described above. The class Person is abstract and
`therefor does not appear as an own dialog. It is however visible as a group in the
`entry form of Employee. Since an aggregation with the employees exists in the fun-
`damental specification of the class Company, a list of the employees employed by
`the company is found in the Company dialog.
`Conversely, the class Employee is the part-of class of this aggregation. Therefore, the
`employer does not appear in an employer’s entry form. The transformation of a re-
`lationship to the GUI selected here is just one of the many possibilities. Software
`ergonomics can both globally prescribe the transformation to be used as well as
`subsequently change it in particular cases. Of course, this not only applies to the
`depiction of relationship, but also applies to other aspects of user interface genera-
`tion (color preferences [Heintzen95], fonts, selection of interaction objects [Bo-
`dart94c],...).
`The generator system additionally connects the GUI with the code frame repre-
`senting the problem domain. When selecting ”Employee create...“ from the appli-
`cation’s main menu the entry form for employee is opened. In the same moment a
`new problem domain object employee is created and linked to the entry form.
`
`

`
`192
`
`Computer-Aided Design of User Interfaces
`
`Now the user is able to enter the new employee’s data. By clicking the OK button
`the entered data will be transferred from the GUI to the linked problem domain
`object. If all values are valid (as specified in the OOA model) the entry form closes
`and the linked object receives the message to store itself in the database.
`
`
`
`Figure 5. Generated dialog windows for the sample application
`The connection GUI-problem domain works even in the other direction. If the
`user wants to modify the former entered data he has first to select the special em-
`ployee via a list view. When selected a single employee the employee’s entry form
`opens. The entry form is linked with the corresponding problem domain object.
`The data are now transferred from this object to the controls of the entry form.
`The user is able to access the previously entered data for further processing.
`
`4 Technical Solution: Designing the User Interface
`
`Before generating the source code for the application, the data keeping, the inter-
`face and the binding, the user interface has to be designed. The starting point is the
`OOA model. Combining the model’s semantics with the selected design strategy
`will produce all necessary windows including their controls. The standard trans-
`formation of a model is described in [Balzert95a, Balzert95b]. The dialog design
`strategy gives information which additional and standard functionality is taken into
`consideration, including its appearance.
`Additionally the decision is made which possibility is chosen when there are differ-
`ent theoretical possibilities. For example, displaying an association as a table or
`simply making it a menu entry that calls a connection window when selected. Most
`
`

`
`
`
`The JANUS Application Development Environment-Generating More than the User Interface
`
`193
`
`strategies are adjustable, so using a different strategy will lead to several different
`user interfaces of the same problem domain.
`The basic controls are chosen from the attribute specification of the OOA model.
`Normally each attribute is transformed into an control with a belonging label, ex-
`ceptions are elements that are marked as non UI relevant. Supported controls are:
`edit field, text field, combo boxes, drop-down combo boxes, list box, drop-down
`list box, check boxes, radio buttons and tables. The result of the transformation, is
`an object network with windows and their elements. They have to be arranged for
`generating the source of the user interface.
`
`Figure 6a. Different layout by choosing different settings: window A
`
`
`
`
`
`Figure 6b. Different layout by choosing different settings: window B
`JANUS uses several placement strategies and has access to ergonomic knowledge.
`So once again, different static layouts can be produced for a single application, be-
`cause the user working with JANUS can change aspects of the layout strategy to
`change the layout. Finally the version fitting the user’s needs best can be chosen for
`the application.
`The main goal of the layout component of JANUS is to get a well balanced layout.
`So there is a special focus on alignment of the elements. To get equilibrium mask
`the two column placement [Vanderdonckt94d] gives the best results. The different
`
`

`
`194
`
`Computer-Aided Design of User Interfaces
`
`between the strategy of GENIUS [Janssen93] is the involving of groups to combine
`equal information. The benefit is a more compact layout.
`Groups result from inheritance or embedded types (structs) in the OOA model. So
`there is the possibility for arranging all elements into two columns or placing the
`groups into two column. One column layout is also possible, it will depend on the
`number of interaction elements and the setting of the layout component.
`All interaction elements will be left justified. There will be an overall alignment of
`interaction elements, whether they are in groups or not. The push button for navi-
`gation or for the operations can be placed left or at the bottom. It is adjustable if
`they are centered, set in a block or if they are set from left/top with equal dis-
`tances.
`In addition to the placement strategy the over grid, and all distances between inter-
`action elements are to be set. All settings are saved in initialization files, so a simple
`reuse is possible. It is also possible to define parts of style guide in the settings.
`Figures 6a and 6b show a result of choosing different settings. Further examples
`are shown in figures 4, 10 and 11.
`
`5 Technical Solution: Connecting the GUI with the Problem
`Domain Component
`
`In all of the later mentioned approaches, the automated linkage of the generated
`user interface to the core of the application is not taken into consideration. This
`problem is solved by the improved JANUS system envisaged here with the help of
`the JANUS Application Framework (JAF). This is a highly specialized class library
`which serves the preparation of the basic functionality in the considered environ-
`ment.
`The environment is characterized by an ODMG conforming, object oriented data-
`base, a GUI development system, and an object oriented programming language
`(C++). The research prototypes of PICASSO [Rowe91] and ACE [Johnson93, Zar-
`mer92] as well as the commercial products like zApp [Inmark94] contributed to the
`draft of the JANUS Application Framework.
`The user interface constitutes a limited number of various elementary interface ob-
`jects or GUI widgets which differ substantially by their position, appearance, as
`well as relationship to one another. The GUI generator has to first select the ap-
`propriate interface objects and see to the technically correct placement and appear-
`ance from the objects' parameterization.
`Conventional GUI development systems require a programmer to couple the final
`user interface with the technically specific portion of the application using Callback
`mechanisms. The tasks of Callback procedures may be assigned to various catego-
`ries [Myers91].
`
`

`
`
`
`The JANUS Application Development Environment-Generating More than the User Interface
`
`195
`
`• The interaction object's internal representation often differs from the expected
`representation the application object's attribute. The type conversions have to
`be expressly carried out by a programmer.
`• It must be checked whether the application satisfies the restrictions specified in
`the problem domain component before an application further processes data
`entered from an end user.
`• The links among the interface objects have to be established to let the user
`navigate through the application
`To solve this problem, JAF provides special operations at higher abstraction levels.
`Access operations automatically created by the App-generator are used on the at-
`tributes of the OOA objects in these operations. This results in a significant reduc-
`tion of the complexity of the user interface specific code.
`These facts are reflected in the generated source code. The code fragments for the
`implementation of the same interface objects in miscellaneous contexts vary sub-
`stantially by a different parameterization in their dynamic creation. The generated
`code is significantly shorter than previously since a large portion of the aforemen-
`tioned tasks are encapsulated in the classes of the application framework.
`In most cases, controls function on a string basis. To keep the costs on the GUI
`side low and to ease the adaptation to various GUIs, the linkage of the interaction
`objects to an OOA model's attribute of a random type was solved with the param-
`eterization.
`An interaction object only has to know the name of the appropriate attribute and a
`reference to the respective object. The type of the attribute bound to the interac-
`tion object does not need to be known although the type, of course, has an impact
`on the parameterization of the interaction object. For example Boolean types are
`represented by two radio buttons etc.
`Therefore, each class of the OOA model has to provide a single operation which
`allows read and/or write access to all attributes. Since a strict type concept is to be
`at the target language's disposal but the interaction objects do not have the type in-
`formation, a data type has to be found upon which random types can be repro-
`duced. Therefore, the use of strings and/or lists of strings is ideal for an exchange
`format between the GUI and the OOA model. An operation's declaration in C++
`for reading a random attribute of a class can be expressed as follows:
`bool GetAll(const char *name, String &val) const;
`The first parameter serves to select the attribute. The second parameter is a place
`holder which receives the value of the attribute converted to a string. Whether an
`attribute with the desired name exists or not is shown by the Boolean return value
`of the operation. If the attribute does not exist in the class requested, all of the base
`classes must naturally be consulted first. The failure of the operation will be re-
`ported only if the attribute searched for is not present here.
`
`

`
`196
`
`Computer-Aided Design of User Interfaces
`
`GUI - layer
`
`GUI
`class library
`
`Janus
`Application
`Framework
`(JAF)
`
`...
`
`...
`
`...
`
`UIView
`
`GetPDObject
`routeEvent
`
`UIContainer
`
`ActivateGetControlData
`ActivateSetControlData
`
`UIControl
`
`GetControlData
`...
`SetControlData
`
`part of the
`meta model
`(see fig 2)
`
`Class
`
`Attribute
`
`UIWorkspace
`
`UIGroup
`
`...
`
`UIObjectTable
`
`UIEdit
`
`UIDialog
`
`UIPushbutton
`
`Operation
`
`
`
`Figure 7. Communication between GUI - and application layer
`Another (overloaded) version of these operations supports the reading and writing
`of an attribute with the help of a list of strings where such a list makes sense. Lists
`can be used, for example, for accessing an enumeration type which allows several
`simultaneous selections.
`Figure 7 demonstrates the effects of these technical solutions on the architecture of
`the Janus Application Framework. Conventional GUI class libraries are expanded by
`subclasses. The new classes are attached as leafs to the inheritance hierarchy of the
`class library. By multiple inheritance from the abstract classes of UIView,
`UIContainer, and UIControl, they obtain operations which produce a connection to
`the attribute (and/or the operation) of the OOA class and/or of the object.
`The cost of expanding a GUI class library with the desired functionality depends
`upon its structure. A UIMS with a C based API (Open Interface [Neuron91, Neu-
`ron93]) as well as the purely object oriented implemented UI builder (zApp) [In-
`mark94] and StarView [Star93] were expanded to meet the additional requirements.
`UIView presents an abstract base class for all visible elements of the user interface.
`It expands its derived classes to concepts for the connection of the OOA model’s
`objects.
`
`

`
`
`
`The JANUS Application Development Environment-Generating More than the User Interface
`
`197
`
`All GUI classes that inherit characteristics from UIView have the possibility to
`communicate with the OOA model objects by the polymorph (virtual) operation
`GetPDObject(). Every UIView class can be directly linked to an object of an OOA
`class by subclassing. The newly